Gentoo, init, konfigurace sítě a další...

28.2.2015 02:08 | Přečteno: 2023× | linux/unix | | poslední úprava: 28.2.2015 02:08

Začínám mít docela různorodý ekosystém, který zahrnuje různé nástroje, jejichž funkcionalita se do značné míry překrývá. Tento zápisek je spíše změtí mých dojmů z poslední doby.

Dosud narážím na to, že mě často lidé z oboru dokonce i tady na ábíčku znají především v souvislosti s vývojem NetworkManageru. Nějakou dobu jsem se tomu projektu věnoval na fulltime, ale před časem jsem se dostal k novým příležitostem. Stále se považuju za kontributora a v nedávné době jsem si sáhnul i na nm-applet, kde jsem zapracoval na možnosti kompilovat applet proti libappindicator na základě předchozích patchů z Ubuntu.

NetworkManager stále používám jako hlavní software pro připojení k sítím na svém laptopu s Gentoo a od vyřešení kompatibility s novějšími verzemi jiných projektů jako BlueZ nevidím zatím pro NM žádnou vážnou konkurenci. To ale neznamená, že je oblast síťových démonů nezajímavá. Mimochodem na stejném laptopu používám systemd, ale tam je hlavním důvodem přiblížení Fedoře a odvozeným distribucím, které jsou teď hlavní náplní mojí práce.

Změna je život

Laptop s Gentoo, systemd a NetworkManagerem, to je taková moje náhrada vývojové instalace Fedory. K tomu mám router na OpenWRT, kde místo systemd běží procd a místo NetworkManageru netifd. A teď jsem si k tomu přidal malé úložiště a server na testování distribucí ve virtuálech, přičemž obojí běží momentálně na Gentoo s OpenRC a síť se konfiguruje s pomocí dhcpcd.

Na dhcpcd mě baví hned několik věcí. Jednak to umí zcela jednoduše fungovat bez zasahování do systému, což jako síťař hračička velmi oceňuju. Ale můžu říct, že mě začalo bavit používat na drátem připojených zařízení dhcpcd místo NetworkManageru. Zatím jsem to nezkoumal do hloubky, ale IPv6 se zjevně konfiguruje v userspace, což osobně stejně jako v případě DHCP považuju za jedinou správnou možnost™.

Zatím jsem to moc nezkoumal, ale výchozím nastavení dynamické konfigurace IPv6 v dhcpcd moc užitečné není a už vůbec ne pro server. Mezi automaticky konfigurovanými adresami nevidím ani jednu pevnou, například odvozenou od MAC adresy. Taky bych ten projekt přejmenoval, aby neměl v názvu DHCP, což navozuje mylný dojem, že se jedná o pouhého DHCP klienta.

Server na DHCP

To už je takový folklór, mnozí administrátoři dynamickou konfiguraci adres moc neuznávají. Já zase nejsem moc nakloněný statické konfiguraci, považuju ji za nepohodlnou. Dynamická konfigurace mi umožňuje ovládat přidělení adres centrálně a to po celou dobu života stroje, tedy od instalace až po ostrý provoz. To jsem si přinesl z dob, kdy jsem trochu víc adminoval a hlavně čas od času dělal nějakou tu instalaci doma a stroj pak přesouval do sítě, kde dostal novou konfiguraci.

Síťový démon pro server

Osobně nejsem zastáncem toho, že je nutné redukovat množství běžících démonů. Líbí se mi koncept toho, že se o konfiguraci sítě stará systémový proces, který je schopný reagovat na události. Pokud člověka zajímá jen připojení pomocí ethernetu, jsou možnosti docela široké. Dostupný software se liší především přidanou hodnotou, tedý tím, co dělá navíc.

Zrovna dhcpcd mi přijde takový minimalistický, vedle konfigurace síťových adres v podstatě nic dalšího nenabízí. Zajímavější mi přijde netifd vyvinutý pro OpenWRT, který disponuje funkcionalitou potřebnou pro plnohodnotný IPv4 a IPv6 router. Na komentování rychle se rozvíjejícího networkd je podle mě ještě brzo. NetworkManager stále vnímám jako průkopníka v mobilitě a ConnMan v individuální konfiguraci aplikací.

V konečném důsledku nemůžu jednoznačně říct, který z projektů je technicky pro nasazení na serveru nejvhodnější. Připomínám, že považuju za normální, že vytrhnu server ze sítě, kam patří, a zapojím si ho kvůli testování nebo opravě jinde a nemám problém se k němu připojit. Především se tady nebavíme o žádném profi nasazení. Intuice mi říká, že bych měl dát šanci právě netifd.

Články

Mimochodem uvažuju, že bych zase napsal nějaký článek, ale nějak se pořád nemůžu rozhodnout, jakým směrem se vydat. Třeba mi trochu pomůžete s inspirací. Ale nic neslibuju!

       

Komentáře

[xkucf03]

Dynamická konfigurace mi umožňuje ovládat přidělení adres centrálně

Druhá strana mince je, že jsi na tom centru závislý. Proto mám např. doma všechno¹ nastavené staticky. Takže i kdyby vypadl stroj, kde běží brána do Internetu, DHCP atd., nebo se stal nedostupným z důvodu výpadku nějakého kabelu nebo switche, tak stále spolu budou moci libovolná dvě zařízení komunikovat.²

Dynamická konfigurace dává smysl u virtualizovaných serverů, kde jsi tak jako tak závislý na hypervizoru – pak se dá brát DHCP server jako jeho součást a tudíž vlastně nevzniká další závislost na nějakém novém centrálním bodu.

U fyzických zařízení se ale radši držím statické konfigurace. Nejvíc by se mi líbila kombinace obojího – centrální autorita by měla veřejný a soukromý klíč a podepisovala by instrukce pro ostatní stroje – např. „teď budeš mít tuhle IP adresu“ nebo „teď si nastav bránu A a DNS server B“. Jednotlivé stroje by si svoje instrukce pamatovaly a pokud by centrální autorita vypadla, řídili by se poslední instrukcí.

který z projektů je technicky pro nasazení na serveru nejvhodnější

Chybí mi tu zmínka o klasické debianí (potažmo ubuntí) konfiguraci přes /etc/network/interfaces – je to velice jednoduché a celkem³ funkční. Chápu ale, že už to není moc cool a in.

považuju za normální, že vytrhnu server ze sítě, kam patří, a zapojím si ho kvůli testování nebo opravě jinde a nemám problém se k němu připojit

Se statickou konfigurací to není problém, s IPv6 LL adresami taky ne.

_{[1] až na počítače návštěv
[2] za předpokladu, že je mezi nimi natažený ethernetový kabel a případné switche jsou zapojené do zásuvky
[3] dovedu si představit i lepší způsob konfigurace, ale to zatím nikdo nenapsal – takže na serverech zůstávám právě u této metody}

[pavlix]

Druhá strana mince je, že jsi na tom centru závislý.

To jsem v mém případě za všech okolností.

Takže i kdyby vypadl stroj, kde běží brána do Internetu, DHCP atd., nebo se stal nedostupným z důvodu výpadku nějakého kabelu nebo switche, tak stále spolu budou moci libovolná dvě zařízení komunikovat.

Takovou situaci v mém případě nemá smysl řešit jinak než vrátit síť opět do plně funkčního stavu.

Chybí mi tu zmínka o klasické debianí (potažmo ubuntí) konfiguraci přes /etc/network/interfaces

Možná proto, že zápisek nebyl o sto jedna způsobech jak spustit DHCP klienta nebo sérii příkazů pro konfiguraci sítě. Nehledě na to, že do blogu píšu, co se mi chce, nehraju si na pokrývání nějaké oblasti. Viz citace.

Tento zápisek je spíše změtí mých dojmů z poslední doby.

Se statickou konfigurací to není problém, s IPv6 LL adresami taky ne.

Možnosti znám, ale nemůžu říct, že by mi plně vyhovovaly.

[rbc]

Nevim, pro me je NetworkManager nekoncepcni a nesystemovej pristup k reseni konektivity, neco jako v drevnich dobach Windows kdy se pribastlil k ovladacum sitovky nejakej spravce pripojeni, ktery fungoval nezavisle na obecnem systemovem rozhrani a konfigurace a pripojeni fungovaly az po prihlaseni uzivatele pod kterym to bylo nastaveny. Omezeny a na desktop orientovany pohled, hlavne ze je ikonka v trayi na kterou jde kliknout.

Testoval jsem NM v OpenSUSE i Debianu, kde kolidoval s klasickym nastavenim sitovek a clovek si musel dat sakra pozor aby aktivaci mimo NM blokoval. Taky byly caste vypadky u bezdratoveho pripojeni, kdy na stejnem stroji ale s vypnutym NM to bezelo bez problemu.

Tim nechci tvrdit ze se od te doby problemy nevychytaly a nezacalo se resit i serverove pouziti, ale porad nevidim jediny rozumny duvod pro jeho existenci. Model bumbrlicek vse v jednom. Pri tom na vetsinu problemu staci klasicke dhcpd, ifconfig/ip, pppd a iwconfig/wpa_supplicant a pro bfu graficke nadstavby jako wicd, kppp nebo primo obecne konfiguratory jako YAST apod. Synator (11 let) ma openSUSE a bez problemu se pohybuje mezi domaci LAN, skolni, hotelovou WIFI a pres USB modem dial-up sitich naprosto bez problemu a NM k tomu nikdy nepotreboval.

Za me naprosto zbytecny software, ktery se snazi znovuobjevit kolo.

[kolcon]

zajimave, ze wicd, ktery vlastne dela to same, ti nevadi...

[rbc]

wicd dela zlomek toho co NM a i kdyz vidim wpa_supplicant jako dostatecny a i jeho GUI konfiguraci treba pres YAST (umi sam prechazet mezi AP vcetne automaticke rekonfigurace IP, vyber specifickeho AP), porad to je mensi zlo nez NM.

[xkucf03]

Nevim, pro me je NetworkManager nekoncepcni a nesystemovej pristup k reseni konektivity, neco jako v drevnich dobach Windows kdy se pribastlil k ovladacum sitovky nejakej spravce pripojeni, ktery fungoval nezavisle na obecnem systemovem rozhrani a konfigurace a pripojeni fungovaly az po prihlaseni uzivatele pod kterym to bylo nastaveny.

Úplné začátky si moc nepamatuji, ale tohle minimálně hodně dlouho není pravda – spojení v NM můžeš mít i systémová, tzn. platná pro všechny uživatele a samozřejmě se aktivují hned po startu počítače – ne až po přihlášení uživatele. Bez GUI se obejdeš, dá se to spravovat z příkazové řádky, dají se upravovat konfiguráky. A systémové mi to právě přijde, protože je to společné pro různé distribuce – ne že to budeš konfigurovat v SUSE jinak než v Mandrivě a jinak než v Ubuntu.

Na serveru jsem NM sice nikdy nepoužil, ale teoreticky by to mělo jít. A na desktopu mi to přijde jako užitečný software.

[pavlix]

Úplné začátky si moc nepamatuji, ale tohle minimálně hodně dlouho není pravda – spojení v NM můžeš mít i systémová.

Posledních několik let reálně existuje jen jeden typ spojení a to jsou systémová. Vše ostatní je řešeno pomocí oprávnění, včetně automatické aktivace spojení. Zrovna nedávno jsem se v tom kódu hrabal, když jsem začleňoval změny kvůli možnosti kompilovat NetworkManager s podporou jak systemd-logind, tak consolekitu, a pak ještě jednou, když jsem řešil, aby mi to dobře fungovalo i v případě, že nekompiluju podporu ani pro jeden z nich.

A systémové mi to právě přijde, protože je to společné pro různé distribuce

To nemusí zítra platit. Osobně vidím systémovost spíše v jednotném přístupu k různým typům spojení.

[pavlix]

Nevim, pro me je NetworkManager nekoncepcni a nesystemovej pristup k reseni konektivity

Na mě je někdy naopak až příliš koncepční, ale tak to bylo vždycky, ať už jsem na něm pracoval nebo ne.

konfigurace a pripojeni fungovaly az po prihlaseni uzivatele pod kterym to bylo nastaveny

Tuhle schopnost vůbec nepoužívám, už jen proto, že se na žádné reálně víceuživatelské stroje nepřihlašuju.

Omezeny a na desktop orientovany pohled

To už docela dlouho neplatí.

Taky byly caste vypadky u bezdratoveho pripojeni, kdy na stejnem stroji ale s vypnutym NM to bezelo bez problemu.

To byl pokud vím známý problém wifi driverů, který se projevoval při průběžném scanování sítě kvůli roamingu. Docela dlouho už na to existuje workaround, že se roaming vypne zafixováním spojení na jedno BSSID. Sám jsem naštěstí nikdy neměl hardware, který by tím trpěl.

Tim nechci tvrdit ze se od te doby problemy nevychytaly a nezacalo se resit i serverove pouziti, ale porad nevidim jediny rozumny duvod pro jeho existenci.

Tak jeho existenci naštěstí na triku nemám. :)

Pri tom na vetsinu problemu staci klasicke dhcpcd, ifconfig/ip, pppd a iwconfig/wpa_supplicant a pro bfu graficke nadstavby jako wicd, kppp nebo primo obecne konfiguratory jako YAST apod.

Osobně nemůžu říct, že by mi všechny uvedené nástroje vyhovovaly, a ani u těch, které NetworkManager používá, nemůžu říct, že by mi vždy vyhovovalo je spouštět přímo.

Synator (11 let) ma openSUSE a bez problemu se pohybuje mezi domaci LAN, skolni, hotelovou WIFI a pres USB modem dial-up sitich naprosto bez problemu a NM k tomu nikdy nepotreboval.

Osobně mám na open source rád právě možnost volby. Každý software, pro který existuje alternativa, je svým způsobem zbytečný.

[Odin1918]

Take preferuji centralni spravu adres. Mam doma jedno pc, ktere slouzi jako jakysi domaci server. Je na nem uloziste, nekolik disku v raidu, ktere mam dostupne pres nfs a sshfs. Stara se to i o pridelovani adres. Vsechny mam pridelovane dle mac adresy a pro nezname stroje mam vyhrazeno nekolik adres, aby fungovali i pocitace navstev. Kdyz by toto pc umrelo, v rychlosti nastavim dhcp server na routeru a jede se dal.

Jinak diky za pekny blogpost.

[pavlix]

Díky.

[Jezekus]

Pěkný zápis, jsem zvědav na to případné pokračování.

Osobně mám velkou averzi k manuální konfiguraci sítě, největší peklo byla síť cca 120 strojů (stanice, servery, tiskárny), kde běžel DHCP server a přiděloval stanicím dynamické IP (případně někdy statické leasy), ale zárověň náhodné stroje měly náhodně nastavené adresy manuálně z adresního rozsahu - samozřejmě bez dokumentace. Brrr...

S NM jsem trošku bojoval na serveru, to cli mi přišlo trochu neohrabané, i když se hodně vylepšilo.

[pavlix]

Pěkný zápis, jsem zvědav na to případné pokračování.

Pokračování jsem nesliboval, spíš šlo o to, jestli se mi někdy nebude chtít zpracovat nějaké ucelené téma jako článek, ale to nemůžu nabídnout k vydání takovouhle snůšku plků, že :).

[trekker.dk]

Síťový démon pro server

Osobně nejsem zastáncem toho, že je nutné redukovat množství běžících démonů. Líbí se mi koncept toho, že se o konfiguraci sítě stará systémový proces, který je schopný reagovat na události

A je to k něčemu dobré? Zatím u všech serverů, co mi kdy prošly pod rukama, je jediná potřebná konfigurace sítě nastavit (jasně a předem dané) IP adresy při startu. Případně ještě možnost přebírat adresy HA služeb, ale o to se nestará žádný síťový démon ale (pro mě) pacemaker, který narozdíl od toho systémového procesu pro správu sítě ví, kde ta IP adresa má být.

Proto by mě zajímalo, o jaké události na serveru se jedná...

[pavlix]

Stejné události jako na kterémkoli jiném stroji. Nechápu lidi, co jsou přesvědčeni o tom, že je něco zbytečné, a přitom se stále dokola ptají, k čemu to je. Nejsem od toho, abych měnil něčí světonázor.

[pavlix]

s/nejsem od toho/nejsem tu od toho/

[trekker.dk]

Stejné události jako na kterémkoli jiném stroji.

... což jsou?

[pavlix]

Z hlavy mě napadají události síťových rozhraní, jak je reportuje kernel, a pak všudypřítomné časování, například pro DHCP a router discovery. Pak jsou různá síťová připojení, která vyžadují větší péči v userspace jako wifi nebo PPP. Pokud nic z toho neznáš, tak nechápu tvou sebejistotu :).

[trekker.dk]

Přiznám se, že neznám. Na serverech nepoužívám DHCP, protože adresy jsou nastavené staticky a DHCP server navíc je jenom něco, co by se mohlo rozbít (z pohledu jednoduchosti konfigurace mi to přijde stejné, tak jako tak se někde něco musí nastavit.) To samé pro router discovery (což mi připomíná, že jsem chtěl povypínat accept_ra.)

Pak jsou různá síťová připojení, která vyžadují větší péči v userspace jako wifi nebo PPP.

Na serveru...?

Jako já neříkám, že všechny procesy jsou špatně. Pokud existuje proces (děj), nechť k němu existuje i proces (z pohledu systému). Proto nemám nic proti nástrojům typu Network Manager na deskopech a zejména na laptopech, kde se s tím člověk pohybuje a nastavení sítě se od zapnutí stroje po vypnutí několikrát změní. Na druhou stranu na serveru je nastavení sítě stav, do kterého se přejde po startu a pak už to tak zůstane. Tam fakt není potřeba, aby běžel proces, který sedí a nic nedělá (ale je potřeba, aby se o něj někdo staral.)

Samozřejmě, i na serveru se stav sítě může něčím změnit (umře síťovka, port na switchi), ale to je chybový stav a jako takový mi ho nahlásí Nagios.