Vlákno názorů k článku Předvídatelné pojmenování síťových karet v Linuxu: kam se podělo eth0 od jouda - Za me minus, default bych rozhodne nemenil, protoze: Drtiva...
-
jouda (neregistrovaný)
Za me minus, default bych rozhodne nemenil, protoze:
Drtiva vetsina pocitacu ma jednu sitovku (+pripadne 1 wifinu), tady mi pripada ze zcela deterministicke wlan0/eth0 je to prave orechove. (navic porad vidim tooly co ma tu eth0 zadratovanou, sice je to cunarna, ale "do ted to chodilo" a "kdyz to funguje, tak do toho nehrab")
Pak tu mame servery, embeeded hracky, virtualy s vice sitovkama, prehazovani disku, PXE/iSCSI s vice kartami,LACP, prehazovani disku, ... - ve vsech pripadech se da rict, ze jsou:
0.V celkovem poctu v mensine.
1.Naprosto netrivialni na reseni.
2.Co admin, to jiny nazor na optimalni reseni
3.Obvykle ten co to resi vi co dela. -
Lol Phirae (neregistrovaný)
Povšimněte si, že zatímco u systému s jednou síťovou kartou (případně jednou ethernet a jednou bezdrátovou - drtivá většina notebooků) jsem měl praktickou jistotu, že prostě eth0 a/nebo wlan0 a tečka, tak nyní po velikém Lennartově vylepšení absolutně netuším, jak se ta síťová karta bude v systému jmenovat (viz diskuse, ta pravidla popsaná v článku prakticky nikomu nefungují), přičemž některé případy tam jsou evidentně pouze proto, aby to vypadalo jakože "entrprajs" řešení (WWAN -> ww: to jako fakt, jakpak to asi ten udev pozná, že je to WAN?). Takže nainstaluju systém a nechám se překvapit, jak se asi ta síťová karta v závislosti na tom, co LP vyvěští z firmwaru/BIOSu a jak to LP kódem proleze). Ale hlavně že mám (dez)informaci o tom, jako jestli si udev myslí, že je to onboard nebo ne a ve kterém je "slotu", to je opravdu pro daný účel klíčové.
A tenhle paskvil má ještě autor tu neskonalou drzost nazvat "predictable network interface names." Svět se opravdu definitivně zbláznil.
-
Petr Neni (neregistrovaný)
Souhlas. Uz vidim jak se meni kickstart jenom kvuli tomu abych vedel kterou sitovku vlastne v serveru mame a jak ji nastavit. Ne, eth0 a eth1 bylo na Lennarta slozite, tak ted tomu sice on rozumi, ale naproste vetsine lidi zadelal na praci. A ano, muzu si to docasne zakazat, jenom 1k+ serveru je zapotrebi zmenit...
-
Lol Phirae (neregistrovaný)
Ono se to navíc chová úplně pomateně, např. mějme Hyper-V virtuál s jednou síťovkou a natvrdo nastavenou sítí (ne přes DHCP). Nabootuju, vyleze z toho něco ve smyslu
enpXs0. Odeberu, přidám místo toho legacy síťovku, nastavím jí stejnou MAC jako měla ta původní, člověk by si myslel, že se nemůže nic rozbít. No kdepak, síť vůbec nenaběhne, protože výsledkem je rozhraníenpYs0. Přidám tu síťovku k té původní a výsledkem je, že se přejmenují obě. Vyměním/přidám/odeberu nějaký jiný virtuální HW, který se sítí naprosto nesouvisí (příklad v diskusi) - opět se to rozjebe! Nabootuju jiné distro (opět příklad z diskuse) -> jooo hošánku kdepak enp?s?, u nás je zase všechno jinak, delší název je víc kchůůůl a in - legacy síťovka se jmenujeenp0s10f0!Mě by zajímalo, jestli ten vocas LP někdy reálně něco adminoval (krom svého notebooku, ze kterého promítá frikulínské psychoprezentace na konferencích). Nejspíš ne, jinak by si musel urazit už dávno obě pazoury.
-
Lol Phirae (neregistrovaný)
No samozřejmě, to je totiž jediný argument zastánců téhle výsledné hrůzy. Totiž, tzv. Lennartware trpí tím, že není navrhován podle reálného světa, ale paradigmatem je, že svět začne zničeho nic rotovat kolem osvíceného LP. On to má správně a všichni ostatní to dělají blbě. A že jsme to rozbili uživatelům? No co je nám do toho, to přece není naše chyba.
-
Lol Phirae (neregistrovaný)
Ano, samozřejmě že to je problém systemd. Protože navrhnout něco vědomě s tím, že to reálně nebude vůbec fungovat (viz diskuse nebo Google - prostě a stručně je to z hlediska predikovatelnosti/persistence/nerozbíjení zcela nefunkční), to vážně napadne pouze Lennarta. Soudného člověka to nemůže vůbec napadnout, něco takového vypustit do světa, natož to pak vydávat za zlepšení a nazval to "predictable".
Zvolené atributy sloužící k přidělování těch názvů jsou prostě reálně nepoužitelné. Stávající systémy nikdo nikdy neopraví a do budoucna se na LP (snad krom několika málo výrobců serverů, kde je Linux podporovaným systémem) taky zvysoka a vydatně víš co... A i kdyby někdo nakrásně tohle všechno opravil, tak to bude stále nefunkční, protože ty použité parametry nejsou stabilní v případě změn hardwaru (naprosto nesouvisejícího se sítí) - opět mnohokrát zmíněno v diskusi.
-
ja. (neregistrovaný)
Lenze ono to funguje. Pokial ma niekto problem napriklad s Hyper-V alebo so stabilnym cislovanim slotov na fyzickom hw, tak nech to riesi s dodavatelom. Pokial je ich fakt tak vela, bude to high-impact bug a dodavatel to bude riesit.
A to ze kopec ludi nadava na LP? To je taky folklor. Kopec ludi nadavalo na prechod z BSD init na SysV init, ze je moc bloated. Kopec ludi nadavalo na prechod z libc5 na glibc2. Ti tiez pochopili, ze to malo svoj ucel. Aj tito casom pochopia pointu systemd.
-
Protože navrhnout něco vědomě s tím, že to reálně nebude vůbec fungovat
Ano, tohle je přesně systemd styl. Viz třeba journal, který v určitých situacích neloguje veškeré informace o procesu. Oni se vymlouvají na to, že kernel nemá nějakou jimi vysněnou funkci. Ale to ten kernel neměl ani během návrhu journal. To jim ovšem nezabránilo to takto naimplementovat a potom křičet, že to bude fungovat až po té, co se něco dopíše do kernelu.
https://bugs.freedesktop.org/show_bug.cgi?id=50184
https://github.com/systemd/systemd/issues/2913Od roku 2012. Nevyřešeno. Prostě kernel bug a nazdar.
-
null null (neregistrovaný)
@Tomáš Crhonek
No, já se teď ve volných chvílích bavím tím, že mi síť prostě jednou za čas, nepravidelný interval 1h až 1/2 den občas prostě na třeba 5 -10 min vypadne. Mám na to chvilku denně po večerech, když se mi vůbec chce. V logu přes journal jsem zatím samozřejmě nenašel nic. Log čistý ... Ostatní zařízení v domě jedou normálně ... Samozřejmě nepredikuji zatím nic, ale jeden společný jmenovatel se tam v dáli rýsuje ...
-
@Kentan z Montargi 9:44
Jaký používáš nástroj pro nastavení sítě?
Osobně používám systemd-networkd i na produkčních serverech a žádný problém. Nasazení je jednoduché, hromada adres je mnohem jednodušší než původní řešení s network-scripts a funguje to zatím spolehlivě. Nezažil jsem (na rozdíl třeba od Network Manageru), že by systemd-networkd síť shodil. Takže příčinu bych hledal nejprve jinde.
-
null null (neregistrovaný)
@Tomáš Crhonek
Mám to na notebooku. Blbé je že ani na jednom routeru jsem nic v logu nenašel - ale to je IMO logické, protože jiné zařízení (tel., další notebook s Win 10, ...) tímto netrpí. Mám to na Debianu 9.(tuším 4 ještě, ale nemůžu se teď podívat a potvrdit to). Shazovalo mi to i wifi - to teda poněkud znatelně časteji - proto mě to teď už tak netlačí ...
Zkusím se večer na systemd-networkd podívat jestli mi to pomůže, nemám takto z hlavy ponětí co to přesně dělá > krom teda mrknutím na název '*network*' ;-) :-) -
@Kentan z Montargi
Nejsem si jist, co používá Debian 9 jako výchozí ovládátko sítě (tuším, že pořád ty jejich staré interfaces skripty, ale po instalaci DE je možné, že to nasadí NetworkManager - už jen pro GUI nastavovátko a lepší správu wifi apod.). sd-networkd se pro notebook příliš nehodí, ale vyzkoušet jej můžeš. Je docela dobře možné, že se ti hádá třeba wifi a kabel a NM přepíná mezi tím, co vyhodnotí jako lepší připojení.
Já jej (systemd-networkd) používám na serverech zejména pro jednotné nastavení sítě, bridge případně bondu, všechno ve stejném duchu ini-like souborů. Vypadá to jednotně a funguje to. Všechno statická sít.
-
anon (neregistrovaný)
To je ale 100% presny popis.
A ocividne jim to v Red Hatu silene zerou, visco, udelaj hezkou prezentaci, produkuji silene mnozstvi kodu a manazer jede na os x tak je mu to jedno, jemu nic nerozbijou :).
Muj oblibeny flatpak je taky krasny priklad lennartware, idea super, na papire vypada genialne a v realu z toho je produkt co vse rozbije, tretine planety vstup z klavesnice, cele planete bezpecnostni updaty. A ten jejich sandbox co funguje jen na papire ..
A stejne jak systemd ma svoje not-a-bug tak flatpak ma fix na stupidni local root exploit jako minor security fix.
Za obojim stoji red hat :(.
-
dustin (neregistrovaný)
Peníze kazí lidi a peníze kazí střídmost softwaru. Kdyby vaty nebyl nadbytek, nikoho by ani nenapadlo dát draze placeným vývojářům volnou ruku, ať si vymyslí nějaký projekt, který by třeba možná mohl být užitečný, a pak jim ho schválit a nechat je tlačit takový projekt komunitě. Přece musí být nějaká jasně daná roadmap - tohle potřebujeme, tohle ne, tohle je jenom nice to have - škrt. Ale asi má omezenou fantazii realitou malé firmy....
