systemd-networkd (diskuse)

[potato]

No, aspoň to vypadá jako věc, kterou snad půjde -- narozdíl od networkmanageru -- nastavit statickou konfiguraci, která statická i zůstane. Nemá to ve výchozím stavu řídit žádná zařízení, nicméně ‚use systemd-networkd by default‘ tuším jako feature Fedory, hned jakmile to půjde...

[pavlix]

Tak statická konfigurace bude u systemd-networkd úplně první věc, je to i v tom mailu. Ale už si vyžádali od vývojářů connmanu vyčlenění jejich interní DHCP knihovny, což mimochodem považuju za dobrý nápad, protože dhclient i dhcpcd jsou zlo.

Jako z pohledu vývojáře networking věcí mě každý nový projekt zajímá, a teď když za NetworkManager nenesu žádnou zodpovědnost v práci, tak je to i docela zábavné.

Ale musím se trochu pobavit i na účet Lennarta, protože kdyby s tím přišel o půl roku dříve a měl naimplementovány všechny základní věci, měl by reálnou šanci se prosadit třeba i na úkor NetworkManageru a cílit na RHEL7. Jenže Lennart bohužel pro něj musel počkat na někoho, kdo rozumí sítím a nebo by se o tom musel nejdřív něco naučit a spatlat něco úplně bez zkušeností.

Nicméně jestli budu ještě někdy přednášet o síťových démonech, můj seznam těch zajímavých tímto narostl na sedm kousků. Bude zajímavé sledovat, kam to povede dál.

[marbu]

To naznačuješ, že zahodit NetworkManager a přespsat to celé odznova jako součást systemd není úplně špatný nápad? Já do toho sice tolik nevidím, ale tohle bych zrovna nečekal.

Btw můžeš aspoň nahodit seznam těch daemonů?

[15as]

NM sa nebude zahadzovat, pre notebooky apod to neni urcene. Hlavne na servery.

[pavlix]

pre notebooky apod to neni urcene.

Zdroj?

[pavlix]

To naznačuješ, že zahodit NetworkManager a přespsat to celé odznova jako součást systemd není úplně špatný nápad?

To úplně ne. Musíš pochopit, že ta otázka je natolik složitá a souvislosti jsou natolik komplikované, že i kdybych na ní měl jednoznačnou odpověď, jakože nemám, nedala by se shrnout do pár vět.

Já si myslím, že se potřebujeme vrátit k otevřenému vývoji, kdy jednotlivé komponenty jsou znovupoužitelné a nad nimi se dá postavit cokoliv. To by při teoreticky mohlo accelerovat vývoj všech network démonů, eliminovalo by to vznik chyb specifických pro některé z nich, a zvýšilo by to počet vývojářů motivovaných řešit chyby v těch společných knihovnách.

Jednotlivá řešení by se pak posuzovala ne z hlediska toho, jak moc dobře ohackovávají netlink, DHCP a takovéhle věci, ale prakticky jen z hlediska konfigurace, která má byt hlavní úlohou těch projektů. Mohlo by to pomoci ozdravit i kernelové API a implementaci a přitáhnout pozornost lidí, kteří rozumějí low-level síťování, ale k smrti nesnášejí high-level tooly typu NetworkManager nebo connman.

Teoreticky by to mohlo vést i k tomu, že by se vytvořila podvrstva společná pro několik konfiguračních služeb, která by zajišťovala integraci všech low-level nástrojů a zpřístupňovala jednoduché a přehledné API pro konfiguraci síťovách rozhraní. Ale to už bych byl moc velký vizionář :D. Člověk musí rozlišovat vize a reálné cíle, pokud dosáhnout alespoň dílčího úspěchu.

Btw můžeš aspoň nahodit seznam těch daemonů?

1. NetworkManager
2. connman
3. WICD
4. netifd (OpenWRT)
5. netcfg (Archlinux)
6. wicked
7. systemd-networkd

Ne všechny mají úplně blízké cíle, ale zatím si nejsem vědom, že by některý z těch projektů definitivně umřel.

[Josef Kufner]

Myslím, že by mohlo stačit standardizovat DBus API, nebo alespoň jeho podstatnou část a přidat jednotný mechanismus detekce toho nestandardního. Takže by bylo možné používat jedno GUI pro různé démony. Tím by se odbouraly problémy, kdy kvalitní démon má mizerné GUI a naopak.

[pavlix]

Myslím, že by mohlo stačit standardizovat DBus API, nebo alespoň jeho podstatnou část a přidat jednotný mechanismus detekce toho nestandardního.

Pro konfiguraci sítí existuje pokud vím standardů několik (ptej se lidí od OpenLMI) a všechny jsou více či méně špatné a nepokrývají ani současné potřeby, natož aby se přizpůsobovaly budoucím. Proč asi?

Takže by bylo možné používat jedno GUI pro různé démony. Tím by se odbouraly problémy, kdy kvalitní démon má mizerné GUI a naopak.

Teorie krásná, ale podle mě je jediný způsob, jak toho docílit vytvořit společnou mezivrstvu. Ale i tak bude API relativně komplikované, protože musí zpřístupňovat nejen síťovou konfiguraci, ale i informace o tom, které její části jsou podporované. S něčím takovým typicky vývojáři GUI vůbec neumí pracovat a nelze to smysluplně otestovat. Tudíž to nelze reálně udělat, aniž by si vývojáři jednotlivých démonů takřka sedli k jednomu stolu a vyrobili a následně udržovali nový standard.

Když se podíváš, jaký je někdy problém udržet pohromadě API jednotlivé implementace, zjistíš, že ani tohle není za současné situace tak úplně možné.

[Josef Kufner]

Tou mezivrstvou by měl být právě síťový démon. Takže nezbývá, než se podívat, co je špatně na stávajících standardech, jak vypadají současná API a udělat to pořádně. Jiná cesta prostě není. A než někdo začne v tomhle hnoji pořádně kopat, tak se ho nezbavíme.

[pavlix]

Tou mezivrstvou by měl být právě síťový démon.

S tím bych i souhlasil, jenže NetworkManager neřeší jen konfiguraci síťových rozhraní, ale i správu profilů, autorizaci uživatelů a pár dalších relativně high-level věcí. Nástroje, které chtějí měnit konfiguraci sítě takové věci často vůbec nepotřebují a tím pádem vůbec nejsou potřeba na některých instalacích.

V takovém případě by se NetworkManager mohl zbavit většiny low-level věcí a sedět nad takovým network démonem a být instalován třeba jen na mobilních zařízeních nebo na strojích, které se potřebují dynamicky připojovat k VPN. Tuhle myšlenku mám v hlavě už delší dobu, ale takhle NM nadesignovaný není a v tuhle chvíli k něčemu takovému vývoj ani nesměřuje.

Takže nezbývá, než se podívat, co je špatně na stávajících standardech, jak vypadají současná API a udělat to pořádně. Jiná cesta prostě není. A než někdo začne v tomhle hnoji pořádně kopat, tak se ho nezbavíme.

Přeju ti hodně štěstí.

[coder]

Na chvilku jsem se zasnil ... bylo by to pěkné

[prOm3TheuS]

Drobná korekce. V Arch Linuxu již netcfg není. Namísto něj je v základním base repozitáři Netctl.

[pavlix]

Je k tomu někde bližší info? I když ono to začíná být z hlediska Archlinuxu dost jedno v době systemd-networkd.

[little.owl]

Zde.

[pavlix]

Hmm, hrubý nedostatek informací o tom, co je za tím. Píšou tam něco o systemd, ale nic konkrétního. Dle wiki je netctl commandline utilita, tudíž nepatří do stejné kategorie.

[Petr Ježek]

Trochu mi není jasné, proč connman není základním síťovým démonem, když úspěšně zvládá dost divoká dynamická nastavení a statiku drží také. Osobně jej používám k plné spokojenosti v Archu. A hodnotit něco podle toho zda to je či není v RHEL mi přijde dost provinční...

[mirec]

Connman je totálne totálne nestabilný. Používam ho na jednom embedded dotykovom zariadení. Ešte pripojiť za bežných okolností zvládne, ale s trochu divokejšou wifinou ktorá nie vždy dobre spolupracuje s wpa-supplicant to občas padne (segmentation fault). O niečo horšie sú záseky pri odpojení v nesprávnom momente (zrušenie connect requestu).

[pavlix]

Trochu mi není jasné, proč connman není základním síťovým démonem, když úspěšně zvládá dost divoká dynamická nastavení

Ani vývojáři connmanu pokud vím netvrdí, že chtějí být náhradou NetworkManageru v plné šíři jeho funkcionality. A vzhledem k tomu, že ani věci, které já považuju za základní nejdou rozumně se současnou verzí Linuxového kernelu udělat a vývojáři NetworkManageru úzce spolupracují s kernelovými vývojáři na nápravě, není těžké uhodnout, který projekt v této oblasti proráží cestu divočinou.

a statiku drží také.

Statickou konfiguraci do určité míry umí všechny linuxové síťové konfigurační nástroje, které znám. Co do možností konfigurace mezi nimi v tuto chvíli kraluje balík iproute, který pokrývá velkou část toho, co se od kernelu v této oblasti může chtít. Co do příjemnosti použití a robustnosti si to v tuto chvíli netroufám hodnotit (snad kromě toho, že v tomto ohledu je nutností deklarativní zápis), žádný z nástrojů osobně nepovažuju za vyhovující.

A hodnotit něco podle toho zda to je či není v RHEL mi přijde dost provinční...

Doufám, že dokážeš toto obvinění podložit něčím víc než mým zaměstnaneckým poměrem, a nejedná se o laciný trolling.

[lertimir]

A vzhledem k tomu, že ani věci, které já považuju za základní nejdou rozumně se současnou verzí Linuxového kernelu udělat

Mohl bys to trochu blíže specifikovat?

[pavlix]

Je toho strašně moc. Ani nastavení adres nefunguje správně, i když pokud by ses omezil na IPv4, tak by to celkem šlo. Dál kernel neposílá notifikace pro velkou část důležitých konfiguračních změn. Informace o bridgích v kernelu trpí race condition, takže nejen, že jsou chybné, ale ještě se dost komplikovaně řeší korekce. Vývojáři narážejí stále na další, ale o těch už si nestíhám udržovat takový přehled jako když jsem na tom pracoval já.

[little.owl]

Tento navrh a kod dodal Tom Gundersen, coz je mimochodem core vyvojar prave Arch. On sam pise, ze zkouseli ruzne alternativy, vcetne connman a zadna z nich nesplnovala jejich pozadavky. Dalsi vyvojar Arch, Marcel Holtmann, se to snazi vysvetlit zde.

V posledni dobe mam pocit, ze Arch hraje ve vyvoji systemd stejne aktivni roli jako Fedora.

[pavlix]

Hezké. Budu muset to vlákno trošku sledovat...

[little.owl]

Jenže Lennart bohužel pro něj musel počkat na někoho, kdo rozumí sítím a nebo by se o tom musel nejdřív něco naučit a spatlat něco úplně bez zkušeností.

Bohudik pro nas. Me pobavilo, ze jedine co k tomu mel jsou pripominky ke coding style.

[pavlix]

Let the flame begin...

[Michal Vyskočil]

No, většina lidí to pochopí tak, že Lennart zahodí NM, který stejně nemají rádi. Takže bych se na žádný velký flamewar moc netěšil.

Bývalo by to chtělo údernější titulek - něco jako Šok! Po rozbití eth0 přichází systemd s změnou - od teď musíte mít dva démony na nastavení sítě.

[pavlix]

Můžeš zkusit někde, kde zprávička ještě není :).

[reb]

Má to nějaký vztah k wicked? Vypadá to podobně.

[pavlix]

Pokud vím, tak žádný, ale informací mám jenom málo.

[kavol]

a kdy se dočkáme systemd-httpd, systemd-sqld a systemd-xwaymird?

[R]

A systemd-emacs.

[pavlix]

a kdy se dočkáme systemd-httpd

Já myslel, že to už je v kernelu ;).

[Pali]

Pre Kristove rany, naco daemona na spravu siete? A preco siet musi riesit init daemon?? To uz su tu vsetci chori, ci co? Som zvedavy kedy nejakeho debila napadne natlacit wpa_supplicant do systemd... Takymto tempom uz nebudeme potrebovat ani filesystem. Bude stacit jeden systemd a journald rozsireny na ukladanie aj niecoho ineho...

[pavlix]

Pre Kristove rany, naco daemona na spravu siete?

Na to, aby nemusela být veškerá logika dynamické konfigurace v kernelu, kde se hrozně špatně udržuje či nahrazuje jinou implementací. Nedávno se kernelovým vývojářům podařilo připravit specializovaného démona pro teaming, aby narozdíl od původního bondingu nemuselo být všechno nasrané do kernelu. Mimochodem skvělý počin v době, kdy je trend spíše opačný (propadání kódu z vyšších vrstev do nižších).

A preco siet musi riesit init daemon??

Nemusí a ani to žádný mně známý přímo nedělá. systemd-networkd je z technického hlediska samostatný síťový démon, stejně jako NetworkManager, connman, WICD, netifd, netcfg, wicked a další. I v případě sysvinit a jiných systémů se init jen volá síťové skripty.

Som zvedavy kedy nejakeho debila napadne natlacit wpa_supplicant do systemd

wpa_supplicant je samostatný démon volaný snad ze všech implementací, které podporují běžně používané vlastnosti wifi. Solidní straw man.

[trekker.dk]

Nedávno se kernelovým vývojářům podařilo připravit specializovaného démona pro teaming, aby narozdíl od původního bondingu nemuselo být všechno nasrané do kernelu.

Zrovna tohle jako velkou výhodu nepovažuju. Proč mít v systému další běžící (ok, většinou spící, snad) hovadinu, když - jak je vidět na již existujícím bondingu - to jde i bez démonů.

[little.owl]

Diky za cokoliv, co se dostane z kernelu ven.

[pavlix]

Důvody pro kód v userspace:

* Kernelový vývoj (až po začlenění patche) je násobně zdlouhavější. Tím pádem z komerčního hlediska dražší a z komunitního hlediska odrazující.

* Chyby v kernelu jsou provozně mnohem dražší. Oprava vyžaduje reboot.

* Bezpečnostní dopady takových chyb jsou větší. Bezpečnostní chyby zůstávají v provozních systémech déle, protože není vždy možnost je rebootovat do nového kernelu. Případné prolomení má dopad přímo na kernel.

* Userspace software lze lehce nahradit jiným, je přijatelné mít v userspace více implementací, které jsou samostatnými projekty.

* Na userspace software nejsou kladeny takové nároky na zpětnou kompatibilitu.

(přidej dle potřeby)

Důvody pro kód v kernelu:

1) Neuvidím to v ps.

2) Konkrétní kód by trpěl problémy s výkonem.

Proto jsou všecky rozumně psané síťové věci rozdělené mezi kernel a userspace. V případě teamingu, ipsec a podobných věcí je typicky v kernelu vše, co zajišťuje provoz (nakládání z pakety apod) a v userspace konfigurační protokoly, dynamické změny konfigurace a podobné.

[pavlix]

Přidejte další důvody dle potřeby.

[Michal Kubeček]

Kernelový vývoj (až po začlenění patche) je násobně zdlouhavější.

No, když srovnám své zkušenosti s jádrem a glibc… A i když nebudu brát podobné extrémy, přijde mi, že reakce upstreamu na patche je u jádra rychlejší než u většiny userspace projektů. Ale možná jsem jen zhýčkaný tím, jak to funguje u síťového subsystému, třeba tenhle fix je maintainerem ignorován už skoro pět měsíců.

[pavlix]

No, když srovnám své zkušenosti s jádrem a glibc…

Zapomněl jsem na glibc jako na nejukázkovější výjimku ;). A to bych neměl, vzhledem k tomu, že jsem si napsal vlastní knihovnu na resolving.

A i když nebudu brát podobné extrémy, přijde mi, že reakce upstreamu na patche je u jádra rychlejší než u většiny userspace projektů.

Tož reakce jsou rychlé, problém je v tom, jak moc se drží zpětná kompatibilita, ale to tobě nemusím povídat. Zatímco jiné projekty se vehementně snaží udržet funkcionalitu, kernel se snaží udržet i zjevné chyby.

[little.owl]

A to bych neměl, vzhledem k tomu, že jsem si napsal vlastní knihovnu na resolving.

Hezke.

Jen poznamka - pouzivas dve ruzne email adresy a pouzivani ruznych a stejne pojmenovanych struct priv dela problemy pri staticke analyze kodu, skutecne bych psal spise struct priv_nss ci struct priv_dns.

[pavlix]

Jen poznamka - pouzivas dve ruzne email adresy

Opraveno.

stejne pojmenovanych struct priv dela problemy pri staticke analyze kodu, skutecne bych psal spise struct priv_nss ci struct priv_dns.

Popravdě řečeno jsem to na základě feedbacku měnil z typedefů, kde ten problém není. Opraveno.

[Michal Kubeček]

Proti tomu, jaké vylomeniny musím občas vymýšlet, abych zachoval kABI, jsou upstreamové požadavky na zpětnou kompatibilitu prkotina. :-)

[Josef Kufner]

Protože kernel si nevycucá konfiguraci VPN z prstu

[Pali]

Kde som pisal, ze by to malo byt v kerneli?

Myslel som tym, naco mat jeden monoliticky daemon na spravu siete, ktory by musel stale behat. Na staticku konfiguraciu siete nepotrebujem ziadneho daemona. Staci konfiguracia a nacitat ju (ci uz skriptom alebo programom). A pre dynamicku konfiguraciu: opat nepotrebujem centralneho daemona. Staci spravne pospustat dhcp klienta, wpa supplicanta (ci vpn daemona)...

[pavlix]

Myslel som tym, ...

Křišťálové koule jsou vzácné zboží a většina diskutujících zde žádnou nevlastní.

A pre dynamicku konfiguraciu: opat nepotrebujem centralneho daemona. Staci spravne pospustat dhcp klienta, wpa supplicanta (ci vpn daemona)...

Uživatelů, které baví hrát si na network démona a spouštět si jednotlivě komponenty a řešit jejich závislosti a konflikty je naprosté minimum. Dokonce i mě to baví jenom občas, většinou je mým hlavním přáním, aby se to připojilo, fungovalo to, a já už řešil jenom to, co na té síti chci dělat.

[pc2005]

Tak zase výhoda, že když nebude fungovat síť, tak stačí uživateli prudit jen vývojáře jednoho projektu. I když to pak zas lituju ty vývojáře .

[Mordae]

Mam daemona, ktery bezi v pres sit bootnutem systemu. Protoze pxelinux je stedry a obdari me informaci o tom, ze ktereho interfacu jsem startoval, ten zkonfiguruji, zeptam se well-known hosta na siti na dalsi konfiguracni detaily, zrusim konfiguraci site (aniz bych zabil 0MQ socket pres ktery si povidame), nahodim na patricnych interfacech bondy, nad nimi vlan interfacy, bridge, vlan interfacy a ve finale se zkusim zeptat znovu, jestli se porad jeste vidime.

Udelat tohle pres NetworkManager je porod (nebo jsem proste jen neschopny), pres nativni rozhrani Linuxu o neco lepsi, ale stale daleko od idealu (je potreba si povidat najednou pres rtnl a sysfs zpusobem, ktery je plny race conditions). Jestli nekdo napise daemona, ktery mi rekne jaka mam rozhrani a necha me je nastavit nejak lidsky, budu opravdu rad.

[pavlix]

Udelat tohle pres NetworkManager je porod (nebo jsem proste jen neschopny), pres nativni rozhrani Linuxu o neco lepsi

Co vím, tak vývoj 0.9.10 směřuje k tomu, aby to (1) porod nebyl, a (2) jsi mohl co nejvíc věcí řešit i přes nativní rozhraní a NetworkManager tvé změny přijal. Docela rád bych si někdy poslechl o konkrétních požadavcích, které na to máš, tedy co to vlastně přesně obnáší.

Jestli nekdo napise daemona, ktery mi rekne jaka mam rozhrani a necha me je nastavit nejak lidsky, budu opravdu rad.

Zdá se, že budeme mít možná i více konkurenčních řešení.

[little.owl]

Me se to libi, hlavne tim, ze je to v pocatecni fazi, je to relativne jednoduche a nemaka na tom primo Lennart.

Po tomhle a tancovani kolem network-online.target jsem nejakou zmenu cekal.

[Lol Phirae]

a nemaka na tom primo Lennart.

Asi proto to bude jednoduché.

[little.owl]

Ono je to hlavne jednoduche nebot je to v pocatecni fazi.

[pavlix]

Po tomhle a tancovani kolem network-online.target jsem nejakou zmenu cekal.

Nojo, jenže tam taky píše sračky. Spousta věcí tam je sice pravdivých, ale naprosto irelevantních. A udělat krok typu network.target nefunguje, udělejme network-online.target, který bude znamenat to stejné, co dřív znamenal network.target, to je řešení jak u debilů. Nula práce, nula výsledků, ale odškrtnuto, že zase opravil kus světa.

[little.owl]

A udělat krok typu network.target nefunguje, udělejme network-online.target, který bude znamenat to stejné, co dřív znamenal network.target, to je řešení jak u debilů.

O to mi v podstate slo, nebot tohle reseni bylo IMHO nebylo udrzitelne.

Chvili jsem si drive myslel, ze si Lennart spise ochoci NM, a na paralelni a lepe integrovane reseni se systemd si netroufne, ale postupne jsem zacal mit dojem, ze tomu tak nebude.

[pavlix]

Chvili jsem si drive myslel, ze si Lennart spise ochoci NM

Vzhledem k tomu, jakým způsobem se stavěl k řešení problémů v systemd, které se týkaly NetworkManageru, bylo víc než zřejmé, že mu ten projekt nějakým způsobem překáží.

[little.owl]

Timhle krokem zacal countdown pro NM, rekl bych.

[pavlix]

O politiku se nezajímám :).

[Lol Phirae]

Timhle krokem zacal countdown pro NM, rekl bych.

http://www.youtube.com/watch?v=oZxnbBWtGR4

[little.owl]

Tak nejak.

[AsciiWolf]

[Tomáš Bžatek]

Prvni CNB a ted toto... :-O