Skip to content

By Тодор in Uncategorized

Ползвал съм собственоръчно направени НАС-ове, било то полу-готови с Freenas, изградени от стандартна Linux дистрибуция или напълно готови хардуерни решения, за които съм писал и преди. В крайна сметка най-доволен останах от Synology. Не защото е перфектно, а защото има най-малко проблеми и бъгове.
Разбира се че е пълно с бъгове! Пакетът му с основни приложения е абсолютен качамак! Нито снимките можеш да си архивираш по някакъв полезен начин, нито файловете. Но целта на поста не е да правя ревю на продукта, а да споделя един особено дразнещ и неприятен дефект.

Притежавам един от малките модели – DS218+. Машинката е закачена за APC UPS, има и комуникационен кабел между нея и UPS-a, за да ѝ е по-ясно каква е ситуацията с тока. Включена е 24/7, като е разрешено единствено да гаси дисковете, ако не се ползват известно време.
Няколко пъти намирам НАС-а загасен. Ама все едно съм му натиснал копчето и се е изключил. А още по-неприятното е, че не може и да се включи. След натискане на бутона, светва, развърта вентилатора, но не развърта дисковете и след 10сек се изключва отново. После пак натискам бутона и стискам палци. И така понякога от 5-тия, понякога от 10-тия опит, вземе, че развърти дисковете и тръгне.

Актуализирах софтуера. Сканирах за грешки. Проверявах захранващия блок. Не открих проблем.
Единствената закономерност, която открих е, че, ако извадя единия или и двата диска, след като се е самозагасил, и натисна копчето, зарежда веднага. Не открих в Интернет някой да е писал за дискова несъвместимост, а и ползвам доста стандартни дискове – 4TB HGST (HDN726040ALE614).
Все още не се предавам и не звъня в гаранционния сервиз за рекламация!

След поредната проверка на конфигурацията и търсене на скрити детайли или каквито и да е улики за проблема из интерфейса на устройството се натъквам на следната опция:
DS218+ Problem

Естествено това беше включено. Даже кой би си помислил, че такава екстра няма да си я има бай-дизайн вградена и ще се налага ръчно да я пускаш и спираш!?

Ами изключих я и проблемите изчезнаха! Вече повече от година не се е самоизключвало.

Наздраве!

Tags: , , , , , , , , , , , , , , ,

By Тодор in Linux

Натъкнах се на неочаквана мотика при комуникацията от контейнер към самия себе си, но през публичния му адрес.

Очаквано тук трябва да се случат някои гимнастики с iptables, за да има двупосочна транслиране, известно още като nat reflection или hairpin nat. Да, обаче пак не работи!

В крайна сметка се оказва, че Docker си прави всичко сам, ама само, ако си поискаме 🙂

Вградената userland proxy услуга трябва да бъде спряна, за да се получи това, което желаем, а именно, ако контейнера ни е с адрес 172.17.0.2, който от Интернет е достъпен на 70.80.90.100, да можем от самия контейнер да се свържем към адреса 70.80.90.100 и това да бъде правилно транслирано от хоста обратно към контейнера.

На кратко:

Създаваме файл /etc/docker/daemon.json със следното съдържание:

{
"userland-proxy": false
}

И рестартираме докер услугата:

systemctl restart docker

Дали се е получило можем да видим от следния параметър на ядрото на ОС съдържаща контейнерите (трябва да е със стойност 1):

# sysctl net.ipv4.conf.docker0.route_localnet
net.ipv4.conf.docker0.route_localnet = 1

Tags: , , , , , , , , , , , ,

By Тодор in Фун

Като млад, зелен и бесен метъл пишех разни щуротии на Паскал и Делфи. Прости инструментчета или шеговити програми от сорта на тази в чиято памет е този пост. Писана е някъде 1999-2000-та година – сиреч преди ДВАЕСЕ години! Т.е. аз съм вече чичка…

Компютъра ми по онова време беше Cyrix 6×86 PR166 с 16MB RAM и чернобял монитор. Уиндоуса беше ’95, а линукса – Red Hat 5 (Hurricane) с ядро 2.0. Най бързата връзка с Интернет беше 2.5КБ/с през домашния телефон на дядо ми и съм чакал по цяла нощ, за да сваля новата песен на Гуано Ейпс от Напстера…

Качвам си играта ТУК, да ми седи за спомен, че хостинга на официалния ѝ сайт фалира преди години. Бахур Хак Тийм също се оказаха няк’ви несериозници…

Хав фун! 😉

Tags: , , , ,

By Тодор in Linux

Онлайн скенерите, с които Интернет е претъпкан са основна отправна точка за „втвърдяването“ (hardening) на всеки уеб сървър. Много от препоръките, които дават са ясни, точни и лесни за изпълнение. Голяма част от тях обаче правят така, че някои уеб страници спират да работят или в най-добрия случай започват да се държат неадекватно.

Едни от най-популярните са internet.nl и ssllabs.

Основни настройки на Apache

ServerSignature Off
ServerTokens Prod
Header set X-Frame-Options: "sameorigin"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "no-referrer"
Header set X-Content-Type-Options: "nosniff"
SSLStrictSNIVHostCheck On
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
SSLOpenSSLConfCmd DHParameters /etc/apache2/dhparam
Options -Indexes -FollowSymLinks
SSLProtocol TLSv1.2

А следното трябва да фигурира в конфигурацията на всеки виртуален сайт:

SSLProtocol TLSv1.2
Protocols h2 http/1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Изтегляне на правилните Дифи-Хелман параметри (файла вече сме го посочили по-горе):
curl https://ssl-config.mozilla.org/ffdhe4096.txt > /etc/apache2/dhparam

Изтеглянето на този файл наистина е важно и има значение. По последни данни саморъчното генериране на DH е пълна скръб и не трябва да се практикува. Задълбано инфо по темата има тук.

Примера е за Апач, но хедърите са същите какъвто и да е уеб сървъра. Разлика има единствено в това, как се подават в конфигурацията.

 

Tags: , , , , , , , , , ,

By Тодор in Linux

Що пък да не си направим LAMP (linux+apache+mysql+php) в докер контейнер?

  • Портативно
  • Съвместимо
  • Лесно за размножаване и разкрасяване
  • Винаги подходящата версия за претенциозни приложения

Започнах с Alpine Linux, като един от най-подходящите за подобни цели, но се оказа че пакета на Апач има редица проблеми, а и разнообразието от готови допълнителни пакети е леко бедно и щеше да се наложи ръчна компилация на това-онова.

В крайна сметка се спрях на последния наличен Ubuntu Server, който към този момент е 18.04. А до няколко дни ще излезе 20.04 и ще актуализирам.

Готов контейнер качвам в Docker Hub. А изходния код и рецептата за забъркване, в Github.

На кратко:

  • Файловете на уеб сайтовете, базата данни, логовете и сертификатите са съхранени извън контейнера.
  • Контейнера онаследява часовата зона на основния сървър.
  • Ползва се PHP-FPM. Процеса е сравнително оптимизиран за стандартно ползване.
  • MariaDB работи в режим TCP/IP, като поддържа SSL/TLS криптиране на трафика. Конфигурацията е оптимизирана.
  • Ежедневна крон задача проверява сертификатите на уеб сайтовете и автоматично издава Letsencrypt сертификати при нужда.
  • Конфигурацията на Апач е оптимизирана по всички основни препоръки за сигурност и съвместимост.

Ще се радвам, ако свърши работа и на някой друг, освен мен 🙂

Tags: , , , , , , ,

By Тодор in Мрън-мрън

След многобройни промени през годините и подскачане от шрифт на шрифт, винаги с частичен и никога задоволителен успех, попаднах на подходящ, който мога да приема за стандарт в сайта. Шрифта се нарича Iosevka и е с отворен код. Чист, ясен и лесен за очите.
Изглежда ми много добре! Доволен съм!

By Тодор in Linux

Според издателя на квалифицирания електронен подпис, инсталацията му в линукс е предизвикателство от различно ниво. Приемам, че подписа е коректно инсталиран според заводската му документация, и че плъгина на Firefox работи.

Това е достатъчно, за да се влезе в почти всеки сайт искащ удостоверяване с КЕП. Включително и в портала с електронни услуги, предоставяни от Националната Агенция по Приходите (НАП).

За да свършим някаква работа в този портал, обаче, само удостоверяването при влизане не е достатъчно. Всичко, което се попълва и изпраща, трябва да е допълнително подписано. А това става с… Java приложение разбира се 🙂

В Linux Mint 19.03 е необходимо да се инсталира icedtea-netx:

sudo apt install icedtea-netx

След това вече jnlp-то може да се изпълни, за да видим това:

StampIT LocalServices cannot start: access denied („java.util.PropertyPermission“ „com.sun.net.httpserver.HttpserverProvider“ „read“)

И тук приказката свършва.

Всичкото търсене води до стари документи обясняващи как да ползваме вече не съществуващи плъгини и методи. Firefox ликвидира Java плъгина преди време, защото е твърде голяма дупка.

Необходимо е да се инсталира „оригиналният“ пакет Oracle Java.

Изтегляме актуалната Жава от https://java.com/en/download/linux_manual.jsp

След, като се разкомпресира пакета, се мести на подходящо място:

sudo mkdir -p -v /opt/java/64
sudo mv -v jre1.* /opt/java/64

Правим новото JRE по подразбиране:

sudo update-alternatives --install "/usr/bin/java" "java" "/opt/java/64/jre1.8.0_241/bin/java" 1
sudo update-alternatives --set java /opt/java/64/jre1.8.0_241/bin/java

Добра идея е да ограничим размера на дисковия кеш след това:

/opt/java/64/jre1.8.0_241/bin/ControlPanel

 

И сега, най-ключовия момент – да кажем на icedtea да ползва новата Жава, вместо вградената:

Това е всичко.

Приятно подаване и подписване!

Tags: , , , , , , , , , , ,

By Тодор in Linux

Най-бързия начин за генериране на частен ключ и SSL сертификат известен на човечеството:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -nodes -days 42000 -subj "/C=BG/ST=Plovdiv/L=Plovdiv/O=Kamenitza.ORG/OU=IT Department/CN=kamenitza.org"
И съответно да се конвертира във формат разбираем от Windows:
openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
А за да може да се ползва и от MySQL/MariaDB, личният ключ трябва да се превърне във формат PKCS#1:
openssl rsa -in key.pem -out key.pem

By Тодор in Mikrotik

Вероятно много „колеги“ ще си помислят, че да се конфигурира IPSec/L2TP тунелче е далеч по-съвместимо откъм клиентксата част – поддържа се „извън кутията“ от всичко от Windows XP насам. Андроид, IOS, Windows имат вграден клиент за такъв тип тунел, което значи, че не е необходимо да се инсталира допълнителен софтуер. Не, че не може, но не е задължително.
Напрактика обаче, не е толкова сладко, колкото звучи 🙂
Ще го обясня максимално разбираемо и минимално подробно – ipsec-esp, ike и l2tp трафика е гаден за рутиране и често нещата изобщо не се случват, ако в мрежата има NAT. Най-обичайната ситуация е да седнете в заведение с наличен свободен безжичен Интернет, който изглежда като да работи, обаче VPN тунела не успява да се закачи. И всичко това, защото са сложили рутер, който се е паднал от пакет зрънчо или нарочно са блокирали nat-traversal, без който ще видим ipsec само през крив макарон.

И така, следващото достатъчно съвместимо, достъпно, безплатно и т.н. решение се явява OpenVPN. Има клиенти за всякакви устройства и операционни системи. Може да се ползва в режим dial-up за пътуващи „работници“, а може и като site-to-site, свързвайки цели мрежи. Изключително гъвкав протокол, може да работи по TCP или по UDP на порт по избор. Минава през всякакви рутери, нескопосано маршрутизиране и куци NAT-ове.
Сървър може да се конфигурира на OpenWRT, Mikrotik и други достъпни решения, както за вкъщи, така и за офиса.

Ще опиша пример със сървър на Mikrotik.

Създаване на пул от адреси за клиентите:
/ip pool add name=remote-pool ranges=10.10.10.100-10.10.10.120

Добавяме профил:
/ppp profile add local-address=10.10.10.1 name=openvpn remote-address=remote-pool use-encryption=required
10.10.10.1 е ИП-то на LAN (вътрешния) интерфейса.

Създаваме си потребител:
/ppp secret add name=todor password=p4ssW00 profile=openvpn

Без сертификат, обаче няма да минем:

/certificate add name=vpn-cert common-name=vpn.kamenitza.org days-valid=3650
/certificate sign 0
/certificate export-certificate 0

С тези команди ще бъде издаден, подписан и експортнат 10 годишен сертификат за домейна vpn.kamenitza.org. Изнесения сертификат е съхранен във файл на рутера.

Вземаме публичния ключ:

/file print detail
 0 name="flash" type="disk" creation-time=jan/01/1970 02:00:03
 1 name="cert_export_vpn-cert.crt" type=".crt file" size=1192 
   creation-time=nov/28/2018 22:34:18 contents=
     -----BEGIN CERTIFICATE-----
     MIIDQzCCAiugAwIBAgIIS74buY1yHXAwDQYJKoZIhvcNAQELBQAwHDEaMBgGA1UE
     AwwRdnBuLmthbWVuaXR6YS5vcmcwHhcNMTgxMTI4MjAzMzIyWhcNMjgxMTI1MjAz
     MzIyWjAcMRowGAYDVQQDDBF2cG4ua2FtZW5pdHphLm9yZzCCASIwDQYJKoZIhvcN
     AQEBBQADggEPADCCAQoCggEBAMBP8cDeknHKYPXCvgZkT+KeNXmjazXmcShNtGY6
     uUcuVbPBOn6FcqA/VwSAdVeNnkY0IqZM1zHCr/kXtgWVGNld2/GnkGCoNgm6SrkZ
     O6dZraC/B3LRIRLp0OR0aZ8/vTO3TwSP+/M/3rWKcs5LdpS8SoheHZBbcK43/qB1
     dR2si5sWJ4l34ketjuJrduzxxD+TE4QLwovMzNyE9S+tKidBBN+/PEJDv3njUZwe
     II+CN0JwosEZ2FfW7MYsx1kUyYZtrBUjCjxerMom9iQR9gWUpsey3yhNKGCDHe/v
     z1h3vkZ5znDAjf/uRbnwGRHkUbIiZ1XKIhmOnPnlgqw4qasCAwEAAaOBiDCBhTAP
     BgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBtjAdBgNVHSUEFjAUBggrBgEF
     BQcDAQYIKwYBBQUHAwIwHQYDVR0OBBYEFBHDtmEAUdv54tr/tRHkHWu9BA5lMCQG
     CWCGSAGG+EIBDQQXFhVHZW5lcmF0ZWQgYnkgUm91dGVyT1MwDQYJKoZIhvcNAQEL
     BQADggEBACa76JK+oUgYddfrfABWGEQDDvSUv37Sfo4WqqokM1r4xuQsF8V+/oEO
     ifdTTX4r/48tohct+jRBCW5vh6Jkx5mVie8MlhFG5oY1dxtd/M9F1Kc6PpyRipCw
     yvuJFOU8ESxEQSwFsElckvaamc09fw55rUgaFmMebuhleXUuyg7WAPUlLSgeGqyd
     RB4lOitA4qmOgEBIUs7Y6jiUe44orWzgGrQGP9zoI8aPwRGvKJoe11PCocrEJvIM
     xMcHyOdrqECY4LlgNLoDGRXJYASWSqTzPvl4TAH1ffKhdp+aUP3/EoHYaF2nu8fD
     wYHuD/lP0Cy21zbobDaFPF4iKdAk2qc=
     -----END CERTIFICATE-----

Всичко между BEGIN CERTIFICATE и END CERTIFICATE, включително, ще ни трябва за конфигурирането на клиента.

Остана и интерфейса:

/interface ovpn-server server
set auth=sha1 certificate=vpn-cert cipher=aes256 default-profile=openvpn 
    enabled=yes mode=ip netmask=24 port=1194 require-client-certificate=no

Евентуално ще трябва да отворим tcp/1194 на фиревала.

Харесва ми възможността отдалечените клиенти да са в същата мрежа, в която са и LAN клиентите, но за да работи изобщо тази екстра, която е на ръба на стандартите, трябва да се активира proxyarp на вътрешния интерфейс.

Клиенската конфигурация изглежда по следния начин:

dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
auth-user-pass
resolv-retry infinite
remote vpn.kamenitza.org 1194 tcp-client
verb 3
<ca>
-----BEGIN CERTIFICATE-----
MIIDQzCCAiugAwIBAgIIS74buY1yHXAwDQYJKoZIhvcNAQELBQAwHDEaMBgGA1UE
AwwRdnBuLmthbWVuaXR6YS5vcmcwHhcNMTgxMTI4MjAzMzIyWhcNMjgxMTI1MjAz
MzIyWjAcMRowGAYDVQQDDBF2cG4ua2FtZW5pdHphLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMBP8cDeknHKYPXCvgZkT+KeNXmjazXmcShNtGY6
uUcuVbPBOn6FcqA/VwSAdVeNnkY0IqZM1zHCr/kXtgWVGNld2/GnkGCoNgm6SrkZ
O6dZraC/B3LRIRLp0OR0aZ8/vTO3TwSP+/M/3rWKcs5LdpS8SoheHZBbcK43/qB1
dR2si5sWJ4l34ketjuJrduzxxD+TE4QLwovMzNyE9S+tKidBBN+/PEJDv3njUZwe
II+CN0JwosEZ2FfW7MYsx1kUyYZtrBUjCjxerMom9iQR9gWUpsey3yhNKGCDHe/v
z1h3vkZ5znDAjf/uRbnwGRHkUbIiZ1XKIhmOnPnlgqw4qasCAwEAAaOBiDCBhTAP
BgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBtjAdBgNVHSUEFjAUBggrBgEF
BQcDAQYIKwYBBQUHAwIwHQYDVR0OBBYEFBHDtmEAUdv54tr/tRHkHWu9BA5lMCQG
CWCGSAGG+EIBDQQXFhVHZW5lcmF0ZWQgYnkgUm91dGVyT1MwDQYJKoZIhvcNAQEL
BQADggEBACa76JK+oUgYddfrfABWGEQDDvSUv37Sfo4WqqokM1r4xuQsF8V+/oEO
ifdTTX4r/48tohct+jRBCW5vh6Jkx5mVie8MlhFG5oY1dxtd/M9F1Kc6PpyRipCw
yvuJFOU8ESxEQSwFsElckvaamc09fw55rUgaFmMebuhleXUuyg7WAPUlLSgeGqyd
RB4lOitA4qmOgEBIUs7Y6jiUe44orWzgGrQGP9zoI8aPwRGvKJoe11PCocrEJvIM
xMcHyOdrqECY4LlgNLoDGRXJYASWSqTzPvl4TAH1ffKhdp+aUP3/EoHYaF2nu8fD
wYHuD/lP0Cy21zbobDaFPF4iKdAk2qc=
-----END CERTIFICATE-----
</ca>

Съхранява се във файл с разширение .ovpn и се импортира в желания клиент или устройство. При свързване ще попита за име и парола.

С тази конфигурация през тунела ще има връзка единствено до отдалечената вътрешна мрежа.
Към момента Микротик не поддържа „route-push“ – възможността да изпрати към клиента маршрути за допълнителни мрежи, които да се рутират през тунела. И така, ако има нужда от рутиране на допълнителни мрежи през тунела или изобщо за целия Интернет трафик, ще трябва към клиентската конфигурация да се добавят следните редове:
route 10.0.0.0 255.0.0.0
или
route 0.0.0.0 0.0.0.0 vpn_gateway 0

Дано не съм забравил нещо 🙂

By Тодор in Mikrotik

След купищата натрошени Микротици трябва на всички да е станало ясно, че тая работа не е като оная работа 🙂 Полянката си трябва малко косене и поливане.
Как да си направим фиревала вече писах. Ето още един копи/пасте мурафет, който ще върже гащите за известно време:

/ip service disable telnet,ftp,www,api,api-ssl
/ip service set ssh port=2222
/tool mac-server set allowed-interface-list=none
/tool mac-server mac-winbox set allowed-interface-list=none
/tool mac-server ping set enabled=no
/ip neighbor discovery-settings set discover-interface-list=none 
/tool bandwidth-server set enabled=no 
/ip proxy set enabled=no
/ip socks set enabled=no
/ip upnp set enabled=no
/ip cloud set ddns-enabled=no update-time=no
/ip ssh set strong-crypto=yes
/user set [find name=admin] name=mincho

Главното за отбелязване, което се случва след изпълнението на тези команди за който не му се чете е:
– спира се всякакъв достъп до рутера/свича освен за SSH и Winbox
– SSH порта се сменя от 22 на 2222
admin потребителското име се сменя на mincho (на галено от админчо)

Наздраве!

By Тодор in Linux, Mikrotik

Все по-често започнах да се сблъсквам с динамични ИП адреси, което понякога прави някои мероприятия като GRE/VPN тунели, предизвикателство,
Ще опиша основно конфигурацията на сървърната част (bind). Клиентските скриптове са въпрос на фантазия, но по-късно ще добавя няколко.
– Дистрибуция CentOS и вградения bind9
– Зоната, в която ще се добавят динамичните записи е dyn.kamenitza.org

Генериране на ключа за актуализацията:
dnssec-keygen -a hmac-md5 -b 128 -n HOST dyn.kamenitza.org.
Ще създаде 2 файла, от които взимаме ключа и го добавяме в named.conf следното:

key "my-key" {
    algorithm hmac-md5;
    secret "4SHxlLTukl587eafb4wxvg==";
};

В named.conf ще добавим и зоната:
zone "dyn.kamenitza.org" IN {
        type master;
        file "dyn.kamenitza.org";
        allow-update { key my-key; };
};

Това е съдържанието на файла със зоната:
$ORIGIN .
$TTL 86400      ; 1 day
dyn.kamenitza.org          IN SOA  ns1.kamenitza.org. admin.kamenitza.org. (
                                2018051200 ; serial
                                7200       ; refresh (2 hours)
                                900        ; retry (15 minutes)
                                1209600    ; expire (2 weeks)
                                3600       ; minimum (1 hour)
                                )
                        NS      ns1.kamenitza.org.
                        NS      ns2.kamenitza.org.

Файла със зоната, както и директорията, в която се намира трябва да са с достатъчни права, за да може bind/named потребителя да пише.

Проба може да направим със следния скрипт:

nsupdate -y 'my-key:4SHxlLTukl587eafb4wxvg==' -d
>update add test.dyn.kamenitza.org 300 A 1.2.3.4
>send

На екрана би трябвало да излезе детайлна информация за това, какво се случва. Ако няма грешки, това ще създаде А запис test.dyn.kamenitza.org, с живот 5 минути, сочещ към 1.2.3.4.

Скриптче за Микротик:

:local ownip [ /ip address get [/ip address find interface=WAN ] address ]
:local ownip [:pick $ownip 0 [:find $ownip "/"]]
/tool dns-update name=mikrotik zone=dyn.kamenitza.org address=$ownip key-name=dyn-key key="4SHxlLTukl587eafb4wxvg==" dns-server=1.1.1.1
:log info ("Dynamic DNS updated to $ownip") ttl=300

By Тодор in Windows

Алгоритъм    Win7  Vista  WinXP
40-bit RC4   no    no     yes
56-bit RC4   no    no     yes
128-bit RC4  yes   yes    yes
DES          no    no     yes
3DES         yes   yes    yes
128-bit AES  yes   *      no
196-bit AES  yes   *      no
256-bit AES  yes   *      no
MD5          no    no     yes
SHA1         yes   yes    yes
256-bit SHA  yes   *      no
384-bit SHA  yes   *      no

* Означава, че конфигурацията е възможна смао с netsh.

DHT library bugs

27.01.2018
By Тодор in Arduino/Espressif

DHT библиотеката на Adafruit има дефект от доста време, който все още не е поправен. Резултата е твърде много грешки при четенето на DHT сензори.
Решението е във файла dht.cpp, където е декларирана функцията boolean DHT::read(bool force), да се закоментират редовете:

// End the start signal by setting data line high for 40 microseconds.
//digitalWrite(_pin, HIGH);
//delayMicroseconds(40);

И да се промени точно след тях:
// Now start reading the data line to get the value from the DHT sensor.
pinMode(_pin, INPUT_PULLUP);
delayMicroseconds(50);  // Delay a bit to let sensor pull data line low.

By Тодор in Linux

Конкретния пример е с Centos 7.3 64bit и mongodb 3.4
При инсталацията по подразбиране демона се стартира, но следните предупреждения лъсват при влизане в mongo през конзолата:

** WARNING: Access control is not enabled for the database.
**          Read and write access to data and configuration is unrestricted.
** WARNING: You are running on a NUMA machine.
**          We suggest launching mongod like this to avoid performance problems:
**              numactl --interleave=all mongod [other options]
** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
**        We suggest setting it to 'never'
** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
**        We suggest setting it to 'never'

За да се оттървем от последните 3 от тези предупреждения правим следното:
Във файла /usr/lib/systemd/system/mongod.service променяме:
User=mongod
да стане:
User=root
И още:
ExecStart=/usr/bin/mongod $OPTIONS run
да стане:
ExecStart=/usr/bin/numactl --interleave=all runuser -s /bin/bash mongod -c '/usr/bin/mongod --quiet -f /etc/mongod.conf run'
Презареждаме промените с:
# systemctl daemon-reload
Във файла /etc/sysctl.conf добавяме:
vm.zone_reclaim_mode = 0
Във файла /etc/security/limits.d/20-nproc.conf добавяме реда:
mongod       soft    nproc     unlimited
Файла /etc/rc.local по подразбиране вече не е изпълним, но все пак е оставен за съвместимост. Правим го изпълним с:
# chmod +x /etc/rc.local
И в него добавяме:
echo "never" > /sys/kernel/mm/transparent_hugepage/enabled
echo "never" > /sys/kernel/mm/transparent_hugepage/defrag

Сега е необходим рестарт на сървъра и след влизане в mongo, всико би трябвало да изглежда по-добре.

By Тодор in LZ5AE (LZ1ETE)

Текстът, който следва не е нещо, което аз съм съчинил или измислил, а по-скоро компилация от материали, които съм намирал из чужди писания. Това е моят опит да го “преведа” на по-лаишки език, така, че и аз самия да го разбера 🙂

Всяка 1/4λ вертикална антена всъщност е половин антена. Другата половина от антената е системата от радиали или противовеси, които са необходими, за да внесат баланс в цялата схема. Ако може да се обясни с прости думи, вероятно би звучало ето така: Върха на антената бива зареждан ту положително, ту отрицателно. За да запазим точката на захранване електрически неутрална, то нещо друго трябва да се зарежда еквивалентно на върха на антената, но с обратен заряд. Ако такова нещо няма, то зарядът ще се трупа в другият край на захранващата линия – този, който влиза в трансивъра. И така, за да работи както трябва един вертикален 1/4λ радиатор, той трябва да има противовес.

За всеки наземно монторан верикал, Земята се явява естествен противовес. Но в различни условия Земята може да е от лош до съвсем никакъв проводник – това зависи от състава на почвата, влажността ѝ и т.н. Тук на помощ идват радиалите или т.нар. система от радиали – могат да са 4, могат да са и повече. Те ще имат грижата да създадат капацитивната връзка с нисък импеданс между антената и Земята. Едната плоча на кондензатора ще са радиалите, а другата – почвата. За да получим нисък импеданс ни трябва голям капацитет, а капацитета зависи от площта на плочите на кондензатора. Радиалите контактуват само със Земята около тях и при по-суха и не-проводима почва биха били нужни повече на брой. Дължината им не е критична стига да е по-малка от 1/4λ. При 1/4λ дължина, те биха се превърнали в излъчващи радиатори, които могат да повлияят на параметрите на антената.

Радиалите са нещо много хубаво, но не всеки може да си позволи да ги има – заемат огромна площ, трябва да имат директен контакт със Земята, в някои случаи може да се наложи да са заровени няколко сантиметра.

Просто и лесно решение на този проблем са резонантните противовеси, които за антената ще бъдат нещо. като самата Земя.

Няколко съвета при направата на противовеси:
1. Нека са малко по-дълги от 1/4λ. Настройте антената на минимум КСВ.
2. Прегънете няколко см от краищата на противовесите в обратна посока (прегънатото за антената е като отрязано) и проверете пак КСВ. Прегъвайте различна дължина, докато настроите до минимално КСВ.
3. Отрежете прегънатите краища и ги изолирайте.

Всичко хубаво, но ако искате да работите на друг обхват? Има няколко варианта:
1. За всеки обхват да се направят отделни противовеси.
2. Да направите противовесите резонантни на най-ниската честота (за да са най-дълги) и след това ги прегъвате на маркирани места, когато работите на по-висока честота. Прегънатите в обратна посока краища са като отрязани/невидими за антената.
3. Да направите най-късите противовеси, които в последствие да удължавате чрез някаква бърза връзка за съответния обхват.

Приблизителни дължини на противовеси:
7МХц – 9м
14МХц – 4м
28МХц – 2.5м

Да се има предвид, че диаграмата на излъчване на антената се променя в зависимост от броя и разположението на противовесите. Ако радиатора се издигне, а противовесите се пуснат да висят надолу, се получава 1/2λ дипол. Ако антената има един противовес, разпънат в една посока, то антената би имала сравнително насочена диаграма в същата посока.

Извод: Радиалите и противовесите не са едно и също нещо.
Радиалите осигуряват капацитивната връзка между антената и Земята.
Противовесите осигуряват необходимия баланс на 1/4λ вертикал без необходимостта от връзка със Земята.

Двата термина се ползват произволно от всички, без много от хората да си дават сметката, че са различни. Надявам се да съм успял да внеса мъничко яснота 🙂