Archiv pro štítek: mini-howto

Linux mini-howto: Systemd automatický restart služby při selhání.

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é.

Pokračování textu Linux mini-howto: Systemd automatický restart služby při selhání.

Android-sysadmin-tools: Nástroje systém administrátora #1

Android sysadmin-tools ?
Krátce o nástrojích ze života sysadmina.

Nástroje systém administrátora pro Android


Co není v hlavě, musím být v nohách říká klasické pravidlo ! Systém admin je však tvor od přírody líný a proto šetří své podrážky jak to jen jde a pokud může, tak má ve svém kapesním “android stopaři” pár více či méně šikovných “švýcarských nožů”.

Následující minisérie s předem nedefinovaným počtem dílů ukazuje pár užitečným nástrojů, začněme však od konce, ty provařené (ssh klienti, rdp, vnc, nmap, cidr calc, atd.) jsou důvěrně známe a nebudeme nosit sovy do athén.

Pokračování textu Android-sysadmin-tools: Nástroje systém administrátora #1

Linux mini-howto: Bash history a HISTTIMEFORMAT

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 history je 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

Mikrotik mini-howto: Hlavní a záložní zavaděč RouterBOOT

Mikrotik mini-howto?
Krátce ze života sysadmina s RouterOS.

Hlavní a záložní zavaděč RouterBOOT


Zavaděč (bootloader) RouterBOOT je v zařízeních značky Routerboard software (firmware, kód) zodpovědný za inicializaci hardware po sepnutí napájení, vyhledání dostupného úložiště (NAND flash) a následné načtení operačního systému RouterOS do paměti a předání mu řízení. Pokračování textu Mikrotik mini-howto: Hlavní a záložní zavaděč RouterBOOT

Linux mini-howto: Postfix queue lifetime

Linux mini-howto?
Krátce o nástrojích ze života sysadmina.

Postfix jako jeden z nejrozšířenějších opensource SMTP 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.

/etc/postfix/main.cf:

queue_run_delay = 5m
minimal_backoff_time = 5m
maximal_backoff_time = 30m
maximal_queue_lifetime = 8h

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.

To bylo snadné, užívejte moudře. MOJEservery.cz

Mikrotik mini-howto: EoIP a šifrování s IPsec

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é.

Článek: 
Jak funguje EoIP a je možný proti Linux serveru ?
www.mojeservery.cz/linux-eoip-tunel-proti-mikrotik/

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.

Příklad síťové topologie:

mikrotik-minihowto-eoip-ipsec-2016

Konfigurace:

Router R1:
/interface eoip add name="EOIP-R2" local-address=1.1.1.2 remote-address=2.2.2.2 tunnel-id=10 allow-fast-path=no ipsec-secret=ozCafWutIvFikamNekUlhedeipdobus5
Router R2:
/interface eoip add name="EOIP-R1" local-address=2.2.2.2 remote-address=1.1.1.2 tunnel-id=10 allow-fast-path=no ipsec-secret=ozCafWutIvFikamNekUlhedeipdobus5

A to je vše, snadné, tak šifrujte !

Děkujeme za Váš čas, MOJEservery.cz

Linux mini-howto: Let’s Encrypt snadno s ACME.sh

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.

Let’s Encrypt obsluhované cert.

 

"Chain of Trust", řetězec důvěry Let's Encrypt
“Chain of Trust”, řetězec důvěry Let’s Encrypt

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.shhttps://github.com/Neilpang/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.

https://github.com/Neilpang/acme.sh
https://github.com/Neilpang/acme.sh/wiki

Tak pojďme šifrovat, Let’s Encrypt ! 


Chcete pomoci s nasazením HTTPS na Vaše servery ?

MOJEservery.cz
Technické konzultace, implementace, kontaktujte nás.
Kontaktní e-mail:  podpora@mojeservery.cz
Kontaktní telefon: +420 725 714 669

Instalace VMware ESXi z USB disku

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: Simulace zpoždění a ztrátovosti paketů v IP sítích

Linux mini-howto?
Krátce o nástrojích ze života sysadmina.

Simulace zpoždění a ztrátovosti paketů


V předchozím Linux-mini howto (Je tunelování TCP skrz TCP dobrý nápad ?) jsme na konci článku zmínili formou odkazů informace k této problematice i přes tento fakt a existenci Google přišlo pár dotazů jak na to, pojďme to v rychlosti proběhnout.

Diagnostika sítí je komplexní, rozsáhlá a složitá disciplína plná záludností, složitých software nástrojů a sofistikovaných drahých měřících přístrojů, přesto se hodí umět si vyrobit kontrolovaně svůj vlastní problém na stole (nemluvíme teď o “muchlání” a kroucení kabelů či nucení kolegů na chodbě běhat skrze bezdrátový spoj ;-) ) a to zcela zdarma díky Linux jádru.

Základní kvalitativní parametry sítě

Zpoždění (latency)
https://cs.wikipedia.org/wiki/Latence#V_informatice

Ztrátovost paketů (packet loss)
https://cs.wikipedia.org/wiki/Ztráta_paketů

Linux kernel, IP stack, fronty, netem NIC

Linux jádro má již od verze 2.6 (dobře, vlastně od 2.4.37) implementovanou funkcionalitu pro network emulaci (netem), pokud máte kernel 2.6 a novější, zakompilovanou podporu Network emulatoru do jádra či jako modul a k tomu nainstalovaný obslužný nástroj tc (traffic control) z balíku iproute2 máte vše potřebné.

Networking -->
   Networking Options -->
     QoS and/or fair queuing -->
        Network emulator

CONFIG_NET_SCH_NETEM=m
Jak funguje netem (linux network emulator) ?

Popišme si alespoň základní koncept síťování v Linux, jednoduchá ilustrace nám dobře pomůže k pochopení, na jedné straně máme aplikace komunikující prostřednictvím systémových volání jádra (syscall) s IP stackem, chtějí komunikovat s hostem a.b.c.d, navazovat spojení, posílat data a o moc více se nestarat.

simulate-latency-pktloss-network-linux-network-qdisc-2016

IP stack předává pakety do qdisc (Queueing discipline), což není nic jiného než scheduler (plánovač, kód v jádře systému) fronty, který rozhoduje o tom v jakém pořadí zpracovat pakety, každé výstupní rozhraní má alespoň jeden qdisc (scheduler, frontu), po průchodu frontou přes ovladač síťové karty putují data ven.

Výchozí fronta v Linuxu je většinou FIFO (First-in, First-Out).

root@netem-machine:~# tc -s qdisc
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap
 Sent 14757932 bytes 163954 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0 

root@netem-machine:~# tc qdisc show
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap

Výpisem pomocí nástroje tc jsme si ověřili aktuálně nastavený qdisc na zařízení eth0 (ethernet), je patrné, že máme nastavenou frontu typu pfifo (packet FIFO) z následující obrázku je vidět, že pfifo interně implementuje i jednoduchý priority mapping a obsahuje uvnitř tři různé fronty pro přednostní zpracování.

pfifo qdisck

Pokud je fronta plná (linka je zatížená) a nemůže být přijmut další paket ke zpracování, dojde k jeho zahození, frontu lze pro tento účel zvětšit, následkem je většinou zvýšení latence, ale můžeme pozorovat i lepší využití linky.

Pro doplnění představ, v Linux jádře je dnes přes 20 různých schedulerů paketů (red, qfq, prio, mq, cbq, htb, sfq ,…) a nic Vám nebrání napsat si svůj vlastní unikátní pro Vaše potřeby. (http://lxr.free-electrons.com/source/net/sched/ )

Netem, skrze dlouhou okliku a vysvětlení qdisc se vraťme zpět k našemu emulátoru, z předchozích informací je zřejmé, že netem je implementován jako další plánovač paketů se schopností přidávat ke zpracování latence včetně náhodné distribuce, generovat ztrátovost, duplikovat i měnit pořadí paketů(reordering).

Použití je opravdu triviální, ukážeme si, nahrajeme modul netem do jádra, nastavíme na rozhraní eth0 qdisc netem, nastavíme parametry zpoždění, náhodného rozptylu, ztrátovosti a otestujeme.

root@netem-machine:~# modprobe sch_netem
root@netem-machine:~# tc qdisc show
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap
root@netem-machine:~# 
root@netem-machine:~# tc qdisc add dev eth0 root netem
root@netem-machine:~# tc qdisc show
qdisc netem 8004: dev eth0 root refcnt 2 limit 1000

Zpoždění 200ms , host 10.0.200.1 je součástí directly connected sítě, okamžitě lze vidět nárůst latence zde pomocí ping nástroje.

root@netem-machine:~# tc qdisc change dev eth0 root netem delay 200ms

root@test-machine:~$ ping 10.0.200.1
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
64 bytes from 10.0.200.1: icmp_seq=1 ttl=64 time=0.295 ms
64 bytes from 10.0.200.1: icmp_seq=2 ttl=64 time=0.268 ms
64 bytes from 10.0.200.1: icmp_seq=9 ttl=64 time=0.230 ms
64 bytes from 10.0.200.1: icmp_seq=10 ttl=64 time=200 ms
64 bytes from 10.0.200.1: icmp_seq=11 ttl=64 time=200 ms
64 bytes from 10.0.200.1: icmp_seq=12 ttl=64 time=200 ms

Zpoždění 500ms ± 100ms, je vidět zpoždění ± s velkým rozptylem (ne realtime jádro s tím asi dost bojuje).

root@test-machine:~# tc qdisc change dev eth0 root netem delay 500ms 100ms
root@test-machine:~$ ping 10.0.200.1
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
64 bytes from 10.0.200.1: icmp_seq=24 ttl=64 time=0.242 ms
64 bytes from 10.0.200.1: icmp_seq=25 ttl=64 time=0.272 ms
--- aplikace netem ---
root@test-machine:~$ ping 10.0.200.1
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
64 bytes from 10.0.200.1: icmp_seq=1 ttl=64 time=453 ms
64 bytes from 10.0.200.1: icmp_seq=2 ttl=64 time=479 ms
64 bytes from 10.0.200.1: icmp_seq=3 ttl=64 time=502 ms
64 bytes from 10.0.200.1: icmp_seq=4 ttl=64 time=491 ms
64 bytes from 10.0.200.1: icmp_seq=5 ttl=64 time=553 ms
64 bytes from 10.0.200.1: icmp_seq=6 ttl=64 time=532 ms
64 bytes from 10.0.200.1: icmp_seq=7 ttl=64 time=534 ms
64 bytes from 10.0.200.1: icmp_seq=8 ttl=64 time=490 ms
64 bytes from 10.0.200.1: icmp_seq=9 ttl=64 time=450 ms

Ztrátovost  10% (10% paketů bude náhodně zahazováno) + latence 100ms, náhodu lze ještě ovlivňovat korelací kdy je závislá na předchozím výsledku v %, je to trochu chaotické, ale vlastně méně chaotické, protože zmenšujeme náhodnost generátoru).

root@test-machine:~# tc qdisc change dev eth0 root netem delay 100ms loss 10%

root@test-machine:~$ ping -q -c 10 10.0.200.1
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
--- 10.0.200.1 ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 9026ms
rtt min/avg/max/mdev = 100.222/100.298/100.371/0.163 ms

root@test-machine:~$ ping -q -c 10 10.0.200.1
PING 10.0.200.1 (10.0.200.1) 56(84) bytes of data.
--- 10.0.200.1 ping statistics ---
10 packets transmitted, 6 received, 40% packet loss, time 9013ms
rtt min/avg/max/mdev = 100.197/100.239/100.295/0.185 ms

Základní představu o konceptu netem a jeho využití jsme snad představili, studujte dokumentaci, další pěknou věcí, která stojí za vyzkoušení je poškozování paketů (netestovali jsme bohužel), není špatné si pro přehled projít i zdrojový kód netem, pěkné je nasazení netem i na příchozí provoz pomocí modulu IFB (pouze otočí in přes pseudo device na out a na něm udělat netem) v ukázkách dokumentace nejdete jak netem protáhnout i jen specifický traffic přes tc filter, omezit rychlost apod … prostě studujte.

V našem případě při testování a hledání problémů s TCP over TCP jsem si postavili script který měnil hodnoty zpoždení a ztrátovosti od malých až po extrémní, tak aby jsme donutili TCP prodlužovat adaptivní timeout a sledovat pomocí tcpdump/wireshark co se děje uvnitř spojení.

Děkuji za pozornost.
František Havel, MOJEservery.cz

Zdroje:

http://man7.org/linux/man-pages/man8/tc-netem.8.html

http://lxr.free-electrons.com/source/net/sched/sch_netem.c

http://www.linuxfoundation.org/collaborate/workgroups/networking/netem

http://info.iet.unipi.it/~luigi/dummynet/

Linux mini-howto: Základní pravidla bezpečnosti serverů

Linux mini-howto?
Krátce o nástrojích ze života sysadmina.

Základní pravidla bezpečnosti serverů

Proč? Základní představa o bezpečnosti serverů je často mylná nebo žádná, tímto soupisem praxí ověřených pravidel se jí pokusme nastínit, v některých případech jde obecná pravidla platná napříč světem IT v jinde cílíme přímo na UNIX systémy, znovu připomínáme jde o takový dobrý základ od čeho se odrazit a v případě zájmu můžeme pokračovat dalším dílem.

Bezpečnost IT systémů není stav, je to neustálý proces a i z toho důvodu je 100% zabezpečení přelud, kterého nelze dosáhnout, ale můžeme se k němu zkusit přiblížit, jediný bezpečný systém je ten který nemáte ala jediné auto které Vám nezestárne je to které jste si nekoupili.

Pokračování textu Linux mini-howto: Základní pravidla bezpečnosti serverů