Linux mini-howto?
Krátce o nástrojích ze života sysadmina.
Postfix MTU a lost connection after …
Podivné chování poštovního serveru Postfix nemusí být nutně způsobené chybnou konfigurací služby samotné, problémy s velikostí MTU jsou o to zákeřnější díky své relativně skryté povaze a “chaotickému” chování, na problém s doručování pošty ve vztahu k MTU jsme nedávno narazili u zákazníka a proto tento mikro-post, ať to neztratíme a třeba to i pomůže někomu dalšímu. Pokračování textu Linux mini-howto: Postfix MTU lost connection→
Linux mini-howto?
Krátce o nástrojích ze života sysadmina.
Debian 9 rc.local a Systemd
V systému Debian 9 (8) a pravděpodobně i v dalších distribucích používající init Systemd byl skript rc.local, který se spouští na konci celého procesu bootování označen jako zastaralý (obsolete) a není již spouštěn (soubor neexistuje) i přes fakt, že se těší/těšil velké popularitě, ale pokrok nezastavíme a snaha o “kompaktní” init v prostředí systému Linux je jasným cílem a těžko se ubráníte jeho používání, tedy je dobré ho ovládnout. Pokračování textu Linux mini-howto: Debian 9 rc.local ?→
Linux mini-howto?
Krátce o nástrojích ze života sysadmina.
Systemd a restart služby při selhání
Systemd je “nový” init systém pro správu služeb navržený exkluzivně pro Linux s cílem nahradit původní SysV init scripty pocházející z System V unix větve a i přes jistou kontroverzi se stává (stal) novým standardem ve světě Linuxu, najdeme ho v drtivě většině mainstream distribucí a je potřeba naučit se s ním žít.
Jednou z operací, která se často řeší je automatický restart služby po jejím zhavarování, jsou služby, které požadujeme aby běželi na serveru neustále, tedy v případě jejich výpadku chceme zkusit automaticky restart, někdo si na to píše vlastní scripty nebo nasazuje nástroj Monit, daemontools či další, Systemd tuto funkci intergruje do sebe, proč ji nevyužit, pojďme na to, je to velmi jednoduché.
Linux mini-howto?
Krátce o nástrojích ze života sysadmina.
Dnes krátce, ale o to možná užitečněji. :-).
Bash history a HISTTIMEFORMAT
Příkaz historyje jeden z mnoha vestavěných (buildin) nástrojů populárního interpretu příkazového řádku (shell) Bash, za normálních okolností je historie provedených příkazů uchována v souboru ~/.history (~/.bash_history) každého uživatele a příkaz history přečte a zobrazí soupis provedených povelů, to je fajn, hodí se to, používá se, chceme to. Pokračování textu Linux mini-howto: Bash history a HISTTIMEFORMAT→
Linux mini-howto?
Krátce o nástrojích ze života sysadmina.
Postfix jako jeden z nejrozšířenějších opensourceSMTP serverů na světě má trochu “nesmyslně” (z pohledu uživatelů) nastavenou výchozí hodnotu fronty pro doručování pošty a to na hodnotu 5 dní a proto tento malý krátký fix. Co to znamená ? Pokud se odeslaný email nepodaří doručit a jako odpověď přijde chyba 4XX, tedy dočasný problém (např. přeplněná schránka příjemce, chybný email, problém na serveru příjemce, …) náš Postfix si ji uloží do fronty deffered a pokouší se ji doručit v intervalech po dobu 5 dnů, pokud se to nezdaří dostane odesílatel zprávu o nedoručení pro X dnech což pro může být značně matoucí.
V Postfix konfiguraci je tedy možné zkrátit maximální dobu fronty.
V ukázce je nastavení doby na 8 hod (maximal_queue_lifetime), nezkracujte tuto dobu příliš, můžete poté mít potíže s greylistováním a také je dobré ponechat příjemci nějaký čas pokud má problémy dočasného charakteru, nastavení na 0 lze tuto funkci úplně vypnout, tedy jeden pokus o doručení a nic více.
Hodnoty minimal_backoff_time, maximal_backoff_time definují interval opětovného odeslání zprávy, Postfix si uměle prodlužuje čas u každé zprávy po každém pokusu až po maximal, queue_run_delay je poté interval jak často “obíhat” frontu.
Mikrotik mini-howto?
Krátce ze života sysadmina s RouterOS.
EoIP a šifrování s ipsec
Proprietární EoIP protokol Mikrotiku pro tunelování L2 provozu je na systému RouterOS velmi populární zejména pro svojí velmi snadnou konfiguraci, prakticky přidáte pouze na každé stráně (zařízení) remote-address a shodné tunnel-id a můžete začít tunelovat, jednoduché, nekomplikované.
Jednou z nevýhod EoIP je nešifrovaný provoz, přirozeně je možné zabalit celý provoz a transparetně šifrovat oba konce přes IPsec, který je podporován v Mikrotiku, bohužel většina administrátorů tuto konfiguraci neřeší, mají k IPsecu “odpor”, vetšinou z důvodu neznalosti jeho problematiky, lidé se bojí toho co neznají.
Proto Mikrotik přidal podporu šifrování do EoIP skrze IPsec (dle informací k 15. výročí protokolu), a to tak snadno, že pouze vyplníte ipsec-secret (pre-shared key, heslo, ideálně netriviální), Mikrotik následně sám nakonfiguruje dynamické ipsec peery (strany tunnelu), nakonfiguruje policy s výchozím šifrováním na sha1/aes128cbc, hotovo a máte šifrováný L2 tunnel, jednodušší už to nebude, takže šifrujte !
Ukázka konfigurace EoIP s IPsec
Používáme RouterOS version: 6.37.1 (stable)
Pozn.:
IPsec u EoIP potřebuje explicitně specifikovat local-address u EoIP tunelu kvůli konfiguraci ipsec peerů a také vypnout fastpath funkcionalitu jinak není možné IPsec povolit na EoIP.
Linux mini-howto?
Krátce o nástrojích ze života sysadmina.
Let’s Encrypt a ACME.sh
Let’s Encrypt je “nová raketově rostoucí” certifikační autorita nabízející zdarma HTTPS (resp. obecně lze podepsat např. SMTP/IMAP,…), v současné době zatím není Let’s Encrypt kořenová certifikační autorita, proto jsou mezilehlé certifikáty podepsané autoritou IdenTrust (DST Root CA X3), tak jak je popsáno v “Chain of Trust“, na tomto kroku se pracuje, ale nebude to hned, navíc chvíli potrvá než se kořenové certifikáty rozdistribuují do prohlížečů, zařízení, atd.
Velká myšlenka výzvy Let’s Encrypt (“pojďme šifrovat”) je zlepšení situace internetové bezpečnost a masivní přechod na šifrované komunikační kanály, s tímto cílem je poskytována zcela zdarma pro každého kdo vlastní doménu, je plně automatizována (klient nasazený na Vašem serveru komunikuje s infrastrukturou Let’s Encrypt za účelem získání/prodloužení/revokování certifikátu), transparetní a otevřená. https://letsencrypt.org/about/
Let’s Encrypt obsluhované cert.
ACME a ACME.sh
ACME (Automatic Certificate Management Environment) je v jednoduchosti řečeno protokol pro komunikaci s infrastrukturou Let’s Encrypt, pro manipulaci s certifikáty je nutné použít na své straně klienta, který korektně implementuje právě protokol ACME.
Certifikáty pro každého ?
Jedním z klíčových požadavků pro vystavení certifikátu je ověření identity žadatele, předpoklad je, že pokud žádám o certifikát pro doménu mojedomena.cz, tak jsem schopen ji kontrolovat, nejčastější kontrola je pomocí techniky webroot , do speciálního adresáře (/.well-known/) je umístěna výzva/žádost, pro výzvu si na www.mojedomena.cz/.well-known si sáhne robot Let’s Encrypt a pokud je vše v pořádku realizuje akci (např. vystavení certifikátu), tímto mechanismem dokazuji, že jsem schopen kontrolovat svoji doménu, tedy nejsem např. schopen udělat (za normálních okolností) tento trik s cizí doménou a tím si nechat vystavit certifikát např. pro seznam.cz.
Toto nejčastější postup ověření identity žadatele, nikoliv však jediný, další možnost je DNS mode, který funguje velmi podobně, z principu je patrné, že vše je vymyšleno tak, aby bylo možné masivně a hlavně zcela automatizovaně nasazovat certifikáty, což je cílem, protože vlastní certifikáty mají platnost pouze 90 dní, takže automatická “recyklace” je v nasazení nutnost.
ACME.sh
Existuje oficiální ACME klient Let's Encrypt certbot.
Certbot je napsán v jazyce Python, který toho umí opravdu hodně, ale zároveň jde o poměrně velký kus software se spoustou závislostí, který si na serveru “builduje” vlastní prostředí pro Python, v některých případech, ale toto nechcete a třeba ani nemůžete použít (např. menší servery, embedded,…) v tomto případě sáhněte po scriptu ACME.sh.
ACME.sh je malý shell script (unix shell) implementující plně protokol ACME, jednoduchý, snadný na použití i instalaci, kompatibilní s bash, nevyžaduje root práva.
ACME.sh a podporované ověření identity:
web root
standalone
DNS
Standalone mode je velmi zajímavý pro servery, kdy nemáte spuštěn www server (Apache/Nginx/…), tedy např. FTP/SMTP servery, acme.sh Vám na dobu nezbytně nutnou emuluje chování web serveru na portu 80 nástrojem netcat (nc), zde již přirozeně je nutné mít práva root.
Instalace a použití je velmi snadné a přímočaré, viz oficiální stránky projektu, dokonce je možné skrze Cygwin provozovat ACME.sh i na Windows.
Linux mini-howto?
Krátce o nástrojích ze života sysadmina.
Instalace VMware ESXi z USB disku
Standardní distribuce VMware je ve formě ISO obrazu (např. VMware-VMvisor-Installer-6.0.0-XXXXXX.x86_64.iso), je primárně určena k instalaci přes CD-ROM, “vypálit”, založit placku a instalovat. Bohužel velmi často dnes narazíme na servery s absencí CD/DVD mechaniky a protože nechce shánět externí USB mechaniku (i médiu může a bude jednou problém shánět), musíme si poradit jinak, VMware podporuje také instalaci ze sítě přes PXE, tato metoda může představovat opět jiné komplikace. Pokračování textu Instalace VMware ESXi z USB disku→
Linux mini-howto?
Krátce o nástrojích ze života sysadmina.
Mikroslužba ipinfo.io
Pro menší projekt jsme hledali jednoduché řešení realizace IP address look/whois/geolokace a to nejlépe formou služby s jednoduchým API, k ruce nám velmi vhod přišla právě mikroslužba ipinfo.io, zřejmě by to šlo vše realizovat svépomocí, ale máme rok 2016 tak proč se trápit.
Protože na více místech používáme RabbitMQ (message broker, fronty, zprávy) a opravdu čas se s tímto konceptem naučit se již vyplatil, nebyl velký problém napsat si vlastní službu na vyřizování požadavků z fronty “rabbit whois” nad ipinfo.io, hlavní app je neinteraktivní a pouze přehazuje do fronty požadavky a nepotřebuje okamžitě odpověd, triviální.
ipinfo.io
Pohodlná služba s jednoduchým API, vrací výsledky v JSON (lze se i ptát v JSON), k dotazům lze použít vše co rozumí http protokolu (v placené variantě i https), základní verze je zdarma do 1000 dotazů/den, prostě super, nic více nepožadujeme, máme max. pár desítek požadavku za den a pokud se neplatu ipinfo běží na AWS.