Archiv pro rubriku: Mini-howto

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

Mikroslužba ipinfo.io

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.

Ukázka a více na http://ipinfo.io/developers.

ip@ip:~$ curl ipinfo.io/8.8.8.8
{
  "ip": "8.8.8.8",
  "hostname": "google-public-dns-a.google.com",
  "city": "Mountain View",
  "region": "California",
  "country": "US",
  "loc": "37.3860,-122.0838",
  "org": "AS15169 Google Inc.",
  "postal": "94035"
}

http://ipinfo.io/developers/tools

http://ipinfo.io

ipinfo-io-blog-header-2016

Pěkná služba, děkujeme.
MOJEservery.cz

Linux mini-howto: Diagnostický nástroj Traceroute

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

Diagnostický nástroj Traceroute


Info: Následující krátký jednoduchý text vznikl na základě praktické zkušenosti dotazů a z workshopů, je cílen na mladší generaci síťařů/adminů pro objasnění, že i za tak jednoduchým nástrojem traceroute není žádná magie, není cílem nikoho urazit, pouze osvěta. Děkuji.

Nástroj traceroute umožňuje základní analýzu počítačové sítě formou textového výpisu směrovačů (uzlů) na cestě paketu od zdroje v cíli, jde tedy o velmi efektivní nástroj pro rychlé zobrazení aktuálních cesty (routování) v sítí, standardně je tento nástroj obsažen ve většině Linux/Unix systémech, ve světě Windows má svoji implementaci v podobě nástroje tracert. Pokračování textu Linux mini-howto: Diagnostický nástroj Traceroute

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/

Video: František Havel #7: Hierarchie souborového systému Linux

Hierarchie souborového systému Linux


Základní úvod do uspořádání hierarchie souborového systému v operačních systémech Linux/Unix.

Další díl našeho mini-seriálu je na světě, pohodlně se usaďte, uvařte škopek kafe, odpoutejte se, kuřte a startujem. :-).

Líbilo se? Dejte like, komentář nebo odběr kanálu a sdílejte.
Děkujeme za Vaši podporu. MOJEservery.cz