Názory k článku Předvídatelné pojmenování síťových karet v Linuxu: kam se podělo eth0
-
- integrované síťové karty jsou pojmenovány eno0, eno1 …
- karty ve slotech PCI Express jsou pojmenovány ens0, ens1 …
- karty s více konektory přidávají k názvům ještě pozici: enp1s0
- (volitelné) název odvozený z MAC adresy: enx78e7d1ea46da
- klasické nepředvídatelné pojmenování podle jádra jako eth0
Síťová karta integrovaná na základní desce mého desktopu s jedním konektorem má název enp4s0 a na notebooku enp8s0 a wifi wlp9s0, co dělám blbě, podle tohoto bych očekával u obou PC eno0 a WiFi u notesu wlo0? Osobně jsem to takto ještě neviděl, podle mě si naopak systemd nepredikovatelně vymýšlí a je v tom větší bordel než předtím. Když jsem potřeboval trvalé pojmenování (např. u serveru s více síťovkami), řešil jsem to utilitou ifrename. Na desktopu a notebooku je v grafických klikátorech pojmenování zbytečné, málokdy je k dispozici více síťovek a když, tak se to dá i v těch klikátorech nastavit na konkrétní (ale dnes již jak vidno stejně nic neříkající název). Za mě další nekompatibilní zbytečnost, která se dostala do systemd.
A co se týká toho názvu s MAC, to je úplná debilita, nedivím se, že je to radši vypnuté. -
VS (neregistrovaný)
Nefunguje to vždy dokonale, ale z větší části je to bordelem v informacích poskytovaných "BIOSem".
Za mě je to ale pro embedded a serverové nasazení jednoznačně plus. Persistence podle MAC adres je peklo při přehazování disků mezi zařízeními, a u moderních systémů k zamíchání pořadí eth0,1,2... bez toho docházelo v nezanedbatelném počtu případů.
I když nefunguje vždy ani to, že k přejmenování nedojde při přidání karty do slotu. Už jsem se setkal s tím, že došlo k přeznačení při vložení nové karty, ale to byl poměrně speciální systém, kde daný slot byl multifunkční, a dané PCIe linky se aktivovaly až při vložení karty do něj, a informace přes biosdevname zřejmě nebyly také úplně OK.
Na stejném HW se vyskytuje název "enp0s31f6" pro jeden z onboard portů - WTF?
-
Adam KaliszStříbrný podporovatelTaky mám takový systém. Jde o desku SuperMicro SAEX11-F, která má dvě Intel síťovky on board, jedna z toho je kombinovaná s IPMI-Ethernetem (který může běžet např. jako tagged nebo se po bootu vypnout)
Potom dvě síťovky, jedna Intel desktop adaptér a druhá Intel 2x GbE Port serverová síťovka. Váš název enp0s31f6 taky vidím. -
Lol Phirae (neregistrovaný)
Síťová karta integrovaná na základní desce mého desktopu s jedním konektorem má název enp4s0 a na notebooku enp8s0 a wifi wlp9s0, co dělám blbě, podle tohoto bych očekával u obou PC eno0 a WiFi u notesu wlo0?
Ještě jsem snad nenarazil na stroj, kde by ten název neobsahoval pXsY (ani u virtuálů)... Asi dělá něco špatně spíš LP. Celé to hodnotím jako úplnou hovadinu a jako řešení (převážně neexistujícího) problému to stejně nefunguje, vůbec to předvídatelné není.
-
Ještě jsem snad nenarazil na stroj, kde by ten název neobsahoval pXsY (ani u virtuálů)...
Tak já už na to pojmenování enoX narazil, ale nebylo zjevné proč to tak někdy je a jindy ne. A zkoumat to zdlouhavě se mi nechce. Kdyby chtělo podívám se do zdrojaků, ale pojmenování je prostě nepredikovatelně a mám stejný názor i na to, že to řeší problém, který neexistuje, bohužel způsobem škrábání se pravou rukou za levým uchem a vytváří problémy jiné, které by bez toho neexistovaly.
-
Ondřej CaletkaZlatý podporovatelTak koukejte, jak to vypadá, když máte server s netriviálním množstvím síťových karet a funkčním firmwarem:
# dmidecode System Information Manufacturer: Dell Inc. Product Name: PowerEdge R430 # ip l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 18:66:da:88:b4:44 brd ff:ff:ff:ff:ff:ff 3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 18:66:da:88:b4:45 brd ff:ff:ff:ff:ff:ff 4: enp4s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether a0:36:9f:d8:49:86 brd ff:ff:ff:ff:ff:ff 5: eno3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 18:66:da:88:b4:46 brd ff:ff:ff:ff:ff:ff 6: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 18:66:da:88:b4:47 brd ff:ff:ff:ff:ff:ff 7: enp5s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether a0:36:9f:d7:c3:08 brd ff:ff:ff:ff:ff:ff 8: enp4s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether a0:36:9f:d8:49:87 brd ff:ff:ff:ff:ff:ff 9: enp5s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether a0:36:9f:d7:c3:0a brd ff:ff:ff:ff:ff:ffZejména si povšimněte v jakém pořadí se karty seřadily. Při pojmenování starým způsobem, byly onboard síťovky pojmenované
eth0,eth1,eth3(!) aeth4, první přídavná karta měla portyeth2aeth6a druhá přídavná karta portyeth5aeth7. Tohmuhle uspořádání se nijak slušně říct nedá.Na svém notebooku, kde mám jednu síťovou kartu drátovou a jednu bezdrátovou, je situace samozřejmě úplně jiná; tady mi nové pojmenování nic nepřináší a jen zbytečně znepřehledňuje situaci, takže ho mám vypnuté.
-
DannyStříbrný podporovatelProblem je prave v tom, ze to cele zavisi na (ne)funkcnosti firmware. Na nekterych platformach se to chova predikovatelne, na nekterych ne (a pak lidi nadavaji celkem opravnene). Uz jsem se setkal i s pripadem, kdy snaha o prediktivni pojmenovani rozhrani skoncila neumerne dlouhym bootem... tim, ze se prediktivni pojmenovani - presneji receno prejmenovani - deje az na urovni initrd (podobne, jako funguji persistentni pojmenovani znama z udevu). Na konci byl bordel, kde pulka sitovek mela oznaceni "renameX"... a pak co je lepsi :)
-
Ondřej CaletkaZlatý podporovatel
To, že se to zaseklo a pak ti zbyly síťovky pojmenované jako renameX je právě důkaz toho, že starý systém perzistentního přejmenovávání síťovek podle MAC adres nefungoval vždy dobře a bylo potřeba ho nahradit.
-
DannyStříbrný podporovatel
Naopak, zadratovani do persistent rules udevu to v danem pripade spolehlive vyresilo. Ano, vazba na MAC muze komplikovat treba vymeny sitovych karet - na druhou stranu, jak casto tohle clovek v praxi dela? Uz prave ta vazba na MAC v udevu resila ten problem, ze se sitova rozhrani inicializuji v ruznem poradi v zavislosti na HW i poradi zavedeni ovladacu...
Muzu zminit jiny pripad, kdy mi pridani sitovky do (do te doby volneho) PCIe slotu rozhazelo pojmenovani rozhrani vsech rozhrani... a z enp3s0, ktera se nikam nehnula byla najednou enp5s0. Proste wtf. Vysledkem je, ze nepredelavas jen nastaveni site, ale treba i firewally svazane na rozhrani... Vyvojar tehle veci se vymluvi na spatny firmware a tim to pro nej skonci. Na "chybu toho druheho" se rado svadi vsechno.
Problem noveho systemu je vzdy to, ze jeho autor si mysli, ze problem vyresi - nevyresi, naopak na mnoha mistech zpusobi problemy nove (a to autora novinky obvykle netrapi). Ja jen doufam, ze za rok neprijde nekdo s nejakou dalsi "kreaci", ve ktere bude zase vsechno jinak... protoze jestli neco opravdu prusvih je, tak je to snaha menit fungujici veci a neochota autora resit problemy zmenou zpusobene.
-
Petr M (neregistrovaný)
Problém je, že ať vymyslíš co vymyslíš, vždycky to bude o spolupráci HW a SW. Každý řešení má svoje mouchy a je na tobě, aby sis vybral to míň blbý.
Pokud to svážeš s MAC, můžeš dokonce i prohazovat karty ve slotech, ale při výměně desky za jinou se ti to rozbije. Jak často cvičně v serveru prohazuješ fošny? Normální to je asi jenom ve výrobě síťovek, jinde ne.
Pokud to svážeš s rozhraním, je to konzistentní, ale závisí to na tom, jak nižší vrstva reportuje topologii systému. Hlásí BIOS on-board kartu jako en nebo eo? Hlásí několik portů na jednoportovce? Hlásí existenci nevyužívaných PCI slotů (a přidáním karty na nižší PCIe lane se to rozbije)? Atd. Závislosti na výrobci a jeho vychytávkách se nevyhneš...P.S. koupil jsem si nový auto a ono na D1 drncalo. To je strašný, jak blbý se dneska dělají auta...
-
dustin (neregistrovaný)
====
Pokud to svážeš s MAC, můžeš dokonce i prohazovat karty ve slotech, ale při výměně desky za jinou se ti to rozbije.
====Pro obyč. gigabit stačí použít víceportovou PCI-e Intel za pár desítek dolarů a interní vůbec nepoužívat, jenom na IPMI/ILO. Pak opravdu stačí jen přehodit disky a nastavit bootovací. V pár strojích to pro snadné přehození mám, triviální.
-
dustin (neregistrovaný)
Nevím, z jaké distribuce tento výpis pochází, ale v debianu jsem vždy záznamy těch přeskočených čísel síťovek našel v 70-persistent-net.rules , protože došlo k výměně síťovky a nová měla jinou MAC adresu. Stačilo ze souboru odstranit záznamy pro staré karty a nové přečíslovat tak, jak jsem potřeboval. Po rebootu (či udevadm trigger) byly vždy pojmenované dle mého nastavení.
-
Petr M (neregistrovaný)
Aha, takže ve slotu 1 klekne síťovka. Postup:
1) Vypneš stroj
2) Vytáhneš síťovku
3) Vrazíš tam novou, rozdíl jenom v MAC
4) Zapneš stroj a prohlídneš chyby, upravíš ručně skripty
5) RebootuješPostup, kde se 4) a 5) stanou automaticky je špatně, protože se v /dev u rozhraní liší pár znaků? Zajímavá teorie...
-
dustin (neregistrovaný)
Ano, s tím rozdílem, že bootnu z live distribuce a opravím ten net-persistence záznam na novou MAC adresu. Po ostrém bootu vše OK.
Síťovky vyměňuji výjimečně. Daleko častěji potřebuju přehodit disky do jiného stroje. Některé síťovky použiji z původního, nové přidám do net-persistence před ostrým bootem. Vím naprosto přesně, jak to bude po bootu na novém stroji vypadat.
Samozřejmě mluvím o serverech s více rozhraními, kde se něco řeší.
-
Petr M (neregistrovaný)
Aha. Takže ještě boot na live distro (to máš povoleno v BIOSu, nebo 2x rekonfigurace BIOSu?) s tím, že live distro prostě najde na serveru nějaký síťovky a neřeší, kam který fous vede... A v případě zapomenuté FLASHky s live distrem se ještě pěkně proběhneš. No tys to narovnal jak šilhavej geometr silnici.
-
dustin (neregistrovaný)
Obávám se, žes to nepochopil. To live distro je potřeba jen pro přístup k disku s /etc, MAC adresy samozřejmě znám, nic detekovat nebude. Navíc si to mohu přenastavit ještě před shozením na stávajícím běžícím stroji.
Ty nechodíš do serverovny s otestovaným live linuxem v tašce? Jinak není problém si je kdekoliv na place vyrobit, net je dnes běžně dostupný. Řekl bych, že žádné servery nespravuješ...
-
Trident (neregistrovaný)
Ja kvuli vymene blbe sitove karty teda vetsinou moc serveru neeviduju na vypnuti. Technici to delaji vetsinou za behu. Vyjma nejake entry level masinky kde to je na motherboardu. To se spis bojim toho ktery mamlas na tech x86kach zase delal podporu hotplugu. Ne veskery hw bezny na certifikovanych konfiguracich(vetsinou pokud jsme koupili nejake startupisty...).
-
j (neregistrovaný)
Starym zpusobem se to seradi podle toho v jakym poradi system karty najde, a protoze jsou pripojeny prevazne k pci(e) tak to odpovida logickymu (nikoli nutne fyzickymu) poradi slotu.
A pokud ma system vic integrovanych karet a jsou pripojeny k vice linkam sbernice, tak je kupodivu muze najit i po kartach ve fyzickcyh slotech, jednoduse proto, ze ten slot ma linku s nizsim ID.
V kazdym pripade dokud se nemenila konfigurace HW, tak byla pravdepodobnost ze se ethX prideli jine karte v realnym provozu prakticky nulova. A to pomijim prosty fakt, ze spousta distribuci po prvnim startu automaticky vygenerovala prislusny pravidlo udevu a nazvy zafixovala pomoci MAC.
Kazdopadne to bylo asi tak miliardkat prehlednejsi, a kdyz nic jinyho, tak kazdej vedel, ze sit = ethX. Nektery appky dodnes neumi najit sit, pokud se ethX rozhrani nejmenuje.
-
Petr M (neregistrovaný)
Na jiným místě zase argumentuješ tím, že chceš, aby se po změně pořadí/typu karet nic na označení nezměnilo. Což postaru s /dev/eth* nefunguje ani omylem... Tak co teda chceš?
Jsou tři řešení problému s rozhraníma:
1) Postup postaru podle pořadí hledání:
+ víš, že je to /dev/eth*,
+ nemusíš nic nastavovat,
- změna HW to rozhodí,
- update to potenciálně rozhodí (protože není jednoznačně definován způsob, jak to natahování ovladačů udělat a nová verze jádra se může chovat trochu jinak),
- nemáš rozlišený porty podle karty
2) Postup podle MAC adresy:
+ stejná karta má kdekoliv stejný označení,
+ určíš si sám, pod čím má být v /dev,
- musíš se s tím babrat ručně,
- složitější a delší výměna karty,
- u víc strojů se stejným železem musíš individuálně konfigurovat každý interface (zkus to při instalaci stovky serverů po devíti síťovkách)
3) Postup podle toho, co je v článku
- nezvyklý označení v /dev/ (jenom věc zvyku, na reálnou použitelnost nemá vliv)
- změna konfigurace HW to může změnit
+ nic nemusíš nastavovat
+ na stejným HW máš zaručený stejný jména rozhraní
+ výměna karty se omezí na prostou výměnu železa, netřeba cokoliv konfigurovat
+ protože to jede paralelně, zrychlí se ti boot -
To co popisuje v reálu je jinak, takže hezká teorie, ale neodpovídající realitě. Ale přesně tímhle způsobem jsou prezentovány funkce systemd:
systemd developer: "Funguje to takhle a takhle"user: "Ale mi to rozbíjí to a to"
systemd developer: "Chyba je jinde ne u nás, my to máme dobře"
user: "Ale předtím to fungovalo"
systemd developer: "To jiné, co jsme nekompatibilním chováním rozbili je třeba upravit, aby to fungovalo s naším novým nekompatibilním chováním, takže chyba není u nás"
user: "Ale vy tvrdíte, že to má fungovat tak a tak, ale nefunguje to a proto ten problém, který tvrdíte, že to má řešit, vůbec neřeší"
systemd developer: "To není pravda, nám to funguje správně, to všechno ostatní funguje blbě a je třeba to opravit tam"
:D
Pro tyhle podivíny mám vzkaz: Když se ti zdá, že všichni jedou v protisměru, jsi nejspíš ty sám ten debil, co jede v opačném pruhu!
-
Tak koukejte, jak to vypadá, když máte server s netriviálním množstvím síťových karet a funkčním firmwarem
A kde je eno0? :D Předvídatelně bych první onboard síťovku čekal s indexem 0 nikoli jedna. Stejně jako se to děje u enpXsY, kde je 0 normální hodnota, ale u onboard už to pro změnu neplatí? Myslím, že to vypovídá o tom, jak uvažují vývojáři systemd.
Jinak na jiném takovém serveru to jde i jinak, např. takto:
$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: lan4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 50:e5:49:55:2c:4f brd ff:ff:ff:ff:ff:ff
3: lan5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether 00:1f:1f:fa:77:79 brd ff:ff:ff:ff:ff:ff
4: wan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:30:4f:29:4f:3f brd ff:ff:ff:ff:ff:ff
5: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:08:a1:8b:b9:78 brd ff:ff:ff:ff:ff:ff
6: lan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:1b:21:c5:ed:4b brd ff:ff:ff:ff:ff:ff
7: lan2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:1b:21:c5:ec:2f brd ff:ff:ff:ff:ff:ff
8: lan3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:1b:21:c5:f0:26 brd ff:ff:ff:ff:ff:ff
9: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 3
link/ppp -
Ondřej CaletkaZlatý podporovatel
Jak někdo poznamenal, číslování
enoodpovídá značení na krabici a na krabici jsou porty označeny čísly 1 až 4.Výpis s rozhraními
lanawanje hezký, ale to určitě nevzniklo samo, že ne? Takové nastavení samozřejmě můžete udělat, šlo to i dřív a jde to i teď. Jediné, co se změnilo je, že vývojáři nahradili kód pro udržování pořadí karet, který ne vždy fungoval dobře (a uživatelé si na to oprávněně stěžovali), něčím, co namísto snahy o zachování pořadí nastavuje jména tak, aby byly nastaveny pokaždé stejně. Což je nejen výrazně jednodušší, ale v mém případě i mnohem funkčnější, protože pořadíethrozhraní tak jak je jádro na mém serveru při prvním startu nadetekovalo bylo v zásadě náhodné, bez jakékoli logiky. -
Výpis s rozhraními lan a wan je hezký, ale to určitě nevzniklo samo, že ne? Takové nastavení samozřejmě můžete udělat, šlo to i dřív a jde to i teď
Ne nevzniklo to samo, stejně jako samo nevzniklo nové (ne)předvídatelné pojmenování síťových karet. Nějak ten argument nechápu, co má říct. Věci samy od sebe nevznikají.
Konkrétně na výše zmíněném serveru, ze kterého ten výpis pochází to přežilo několik různých HW obměn/upgradů a také už minimálně třetí generaci Debianu, jen se upgraduje a server jak vidno žije vesele dál. Takže nějak nemůžu souhlasit s prezentovaným problémem - že je původní chování špatně a k ničemu a nové je záchrana světa, proto je třeba to ve výchozím stavu všem pro jejich dobro změnit.
-
Ondřej CaletkaZlatý podporovatel
Dobře tak ještě jinak:
- Pojmenování síťových karet vlastními názvy pomocí udev pravidel fungovalo už minimálně 10 let a funguje nadále. Dokonce je to, aspoň z mého pohledu, preferovaná varianta, protože rozhraní
lan,wanadmzjsou mnohem přehlednější než cokoli jiného. - Pokud nejsou zavedena žádná pravidla, síťové karty dostávají název
eth<číslo>v pořadí, jak jsou detekovány. Pro většinu uživatelů to není problém, protože buď:- mají jen jednu kartu daného typu, nebo
- prodleva mezi detekcí jednotlivých karet je tak velká, že jsou nadetekovány vždy ve stejném pořadí.
- udev dříve obsahoval kód, který se pokoušel zachovávat pomocí vzájemného přejmenovávání pořadí síťových karet tak, jak byly nadetekovány při prvním startu. Tento kód se sám o sobě uplatnil jen pro menšinu uživatelů (těm, pro které neplatí výše zmíněné body), v určité části případů přitom nefungoval správně.
- Vývojáři udevu se rozhodli tento obtížně udržovatelný a debuggovatelný kód zahodit a nahradit něčím, co půjde udržovat snadněji. Pořád ale platí, že většina uživatelů tu službu nepotřebuje, protože nepotřebovala ani tu starou, částečně nefunkční službu.
- Pojmenování síťových karet vlastními názvy pomocí udev pravidel fungovalo už minimálně 10 let a funguje nadále. Dokonce je to, aspoň z mého pohledu, preferovaná varianta, protože rozhraní
-
Vývojáři udevu se rozhodli tento obtížně udržovatelný a debuggovatelný kód zahodit a nahradit něčím, co půjde udržovat snadněji.
Jo takhle, vývojáři to nedělají pro to, aby to co nejlépe fungovalo, ale pro to, aby se to snadno udržovalo. Takové vývojáře poslat k šípku a nabrat ty, pro které je funkčnost a bezproblémovost jejich díla prestiž a ne otrava, vedoucí vlastní leností ke krokům, které jsou pro ně samotné jednoduché, protože to těžké tak přenášejí na chudáky uživatele!
-
DannyStříbrný podporovatel
Takovych prepisu kodu jsme byli svedky uz nekolikrat na mnoha mistech a vzdycky to skonci u toho, ze po case je ten kod opet obtizne udrzovatelny a debugovatelny. Vysledkem je sice kod novy, ktery ale nepokryje do te doby odladene a vychytane detaily, ktere se tam postupne dopisuji... a nakonec mame obtizne udrzovatelny kod. Nekonecny pribeh :-)
Jinak samozrejme "puvodni" rules z udevu se parsuji i nadale (stav s udev 239) - ten kod tam porad je, tzn. ve vysledku neplati ani ta treti velka odrazka (jinymi slovy jde mit "eth0" i na systemu, kde kernelu "net.ifnames=0" neposilas)...
-
null null (neregistrovaný)
@Danny
IMO pokud se každý refactoring nakonec opět stane některým z kruhů pekla, tak z mé zkušenosti bývá chyba v architektuře - jako např. na danou komponentu se klade příliš mnoho nároků a je potřeba to oddělit nebo změnit, případně revidovat možné stavy a kombinace se kterými pracuje a pod., nějaká kombinace faktorů ... ale mnohokrát jsem došel k tomu, že se takové problémy vyřeší až větší změnou než je pouhá implementace komponenty.
No je mi jasné co to obnáší, ale .... -
j (neregistrovaný)
"Vývojáři udevu se rozhodli tento obtížně udržovatelný a debuggovatelný kód zahodit a nahradit něčím, co půjde udržovat snadněji."
Snadneji pro koho? Pro toho idiota poetteringa a jeho squadru? Protoze VSEM ostatnim to prineslo jen neustale dokola se objevujici problemy a naprosto nulovy uzitek.
-
DannyStříbrný podporovatel
Vypis s rozhranimi "lan" samozrejme "sam" vzniknout muze... U rozhrani, ktere se do systemu propisou z distribuovanyho switche (DSA) je to naprosto bezne k videni :-)
Jinak zadny system nefunguje dobre. Jisteze mohly byt teoreticke problemy s persistent-net-rules u udevu, ale obvykle to fungovalo bez potizi a poradi (a tedy pojmenovani) karet se od instalace nikdy nezmenilo (a pripadne zmenit poradi take nebylo tezke). S prediktivnimi jmeny to je zdanlive vyresene - teoreticky, jen na papire, praxe ukazuje, ze i s tim jsou (jine) problemy a vyresene to (opet) spolehlive neni. Dilem diky tomu, ze fakticky nejde o vychozi pojmenovani, ale uz jen prejmenovani behem bootu (ktere ne vzdy dobehne, jak by melo), dilem diky tomu, ze se ruzne firmware chovaji ruzne - viz problemy treba se zmenou/preskladanim cisel bus i pri vlozeni noveho hardware do prazdneho slotu... to, ze onboard sitovky mnohych desek vubec nejsou rozpoznane jako onboard je uz jen tresnicka na dortu (mam treba desktop, kde onboard sitovka je bus 3, a pcie karty bus 1,5 - logika zadna).
Samozrejme se muzes stale dokola vymlouvat na vyvojare firmwaru a jejich chyby - ale ten problem tu proste bude, protoze ani zadny firmware neni a nikdy nebude bez chyb. Zrovna linuxovy kernel je plny ruznych quirku, kterymi se vselimozne chyby ve firmware obchazi - aby hardware vubec fungoval. A je jich tam fakt spousta. Spolehat plne na firmware zrovna pri pojmenovani sitovych rozhrani s odkazem na tuto letitou zkusenost neni zrovna stastne, nemyslis?
Navic, kdyz vezmes celou teoreticky moznou delku nazvu pro PCI device ([P<domain>]p<bus>s<slot>[f<function>]n<phys_port_name>) nebo i USB device ([P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]), tak je pomerne neprehledne, stejne jako mozny tvar odvozeny z MAC (x<MAC>- to je take ve specifikaci)... tak to v konecnem dusledku zrovna prehledne neni a nejspis i bude zdrojem sedivych vlasu v dusledku ruznych preklepu.
-
Lol Phirae (neregistrovaný)
Paradoxně, ta metoda pojmenování podle MAC adresy (
enx<mac_addr>), které je z pohledu predikovatelnosti a možného rozjebání při změnách (jiného) hardwaru zdaleka nejméně problémová, je defaultně vypnutá. Smyslu půl to nedává, jako ostatně mraky dalších věcí v Poetteringlandu. :-X -
samalama (neregistrovaný)
tie nazvy su asi tak predikovatelne ako moje prdy.
1. integrované síťové karty jsou pojmenovány eno0, eno1 …
2. karty ve slotech PCI Express jsou pojmenovány ens0, ens1 …
3. karty s více konektory přidávají k názvům ještě pozici: enp1s0
4. (volitelné) název odvozený z MAC adresy: enx78e7d1ea46da
5. klasické nepředvídatelné pojmenování podle jádra jako eth0cize sietovka vo virtuali bude mat aky nazov? ci nebude?
pomenovanie na zaklade mac adries cez udev mi nefugoval len v jedinom pripade, ked system nevedel premenovat sietovku eth0 na eth1 (a naopak), pretoze eth1 uz existovala. ale vyskytlo sa to iba raz a iba na jednom konkretnom hw. vyriesilo sa to nakoniec tak, ze sa premenovali na wan0 a lan0 (co sme potom zacali aplikovat aj na ostatne servery).
ked viem, ze tato sietovka ma takuto mac, tak viem, ze bude mat takyto nazov. ked tu sietovku vymenim, tak ju proste vymenim a zmenim aj udev. menim sietovku, tak menim aj konfiguraciu. co je na tom zle/nesystemove/antihipsterske/...?
ak instalujem nejaky server (hw alebo vm), tak viem, ze jedna sietovka bude mat stale nazov eth0, mozem ju teda nakonfigurovat a stroj startnut a viem, ze mi siet pojde. takto len mozem hadat, ako sa sietovka bude volat a v podstate ju ani neviem nakonfigurovat...
-
Petr M (neregistrovaný)
Jak často vlastně jenom tak ze srandy sestřelíš server, vytaháš z něho kabely, prohodíš síťovky a pak přetaháš kabely k jiným slotům, zapojíš do původních konektorů, vysvazkuješ a znovu nabootuješ? A nepřijde ti to zbytečný?
A když máš předpřipravených 10 serverů, kde v 2. PCI je čtyřportová karta pro DMZ, tak pro 10 serverů přepisuješ konfigurák jenom proto, aby se dala karta přehodit do 3. slotu, když dostaneš záchat přepojování? Pozdravuj služebnictvo v bílých pláštích, co ti ráno a večer nosí lentilky...
-
j (neregistrovaný)
Narozdil od magoru jako ses ty a ten kreten Poettering adminuju skutecnej HW a v nem se kupodivu cas od casu neco prida, a neco jinyho je treba posunout aby se to veslo, nebo se neco odebere, a porad od toho ocekavam, ze po startu vsechno pojede a ne ze stravim mesic rekonfiguraci uplne vseho protoze nejakej kokot vymysel ze je uzasnej napad davat HW nazvy podle toho kam je pripojenej. Kabely ze sitovek kvuli tomu nemusim vubec odpojovat, ale to trotl co vzivote server nevidel nemuze tusit.
-
Petr M (neregistrovaný)
Jasně, a abys to nemusel po změně překonfigurovávat, tak to pro změnu konfiguruješ rovnou ručně při instalaci. A pak stejně po změně HW, protože se síťovka vymění (= jiná MAC), prohodí (máš dvě stejný a neohlídáš si MAC a prohodíš je ve slotech), přidá (potřebuješ další síťovku), odebere (spíš než jednu ze síťovek potřebuješ na jejím místě SAS)...
A když to necháš postaru a na části produkčních serverů se to po update jádra rozbije a protože updatuješ postupně, tak máš různý mašiny v různé konfiguraci a neřve to, že je někde problém. Jenom se nějak domotají sítě a jak tydýt hledáš, kde a čím to je.
Gratuluji k tomu, jak se ti krásně daří si kakat do gumáků.
-
Petr Neni (neregistrovaný)
Petre, obvykle se nadefinuje konfigurace jednou a pak se udrzuje. Jako admin chcete mit jistotu ze dana sitovka bude mit pristup k dane siti. Obcas potrebujete sitovku pridat a nechcete kvuli tomu menit pul konfigurace jenom proto ze system si rekl ze to rozjebe. Obcas chcete sitovku odstranit a taky necekate ze vam system rozjebe konfiguraci. A obcas nejakou sitovku vymenite, pak vite ze minimalne musite udelat zmenu rozhrani a mac adresa. System obsahujici eth0 a MAC adresu je ve vetsine usecase funkcni bez zasahu. Pridam sitovku, zmenim pozici, odstranim nejakou sitovku, ostatni konfigurace zustava funkcni. V pripade tohodle “predvidatelneho” reseni v kazde situaci ma admin imho praci navic.
-
samalama (neregistrovaný)
"pomenovanie na zaklade mac adries cez udev mi nefugoval len v jedinom pripade..."
aby som to uviedol na pravu mieru - tento pripad sa vyskytol PO zavedeni systemd (centos 7), kedy sme chceli zachovat povodne nazvy sietoviek. skusali sme rozne kombinacie nastaveni (udev, kernel parameter), a stale to neslo. takze asi tak je to s tou moznostou v systemd, zachovat povodne nazvy (hej, povodne nazvy ostali, ale uz ich sme nedokazali prehodit medzi sietovkami. bez systemd si fakt nepamatam pripad, kedy by to nefungovalo).
-
> cize sietovka vo virtuali bude mat aky nazov? ci nebude?
Virtuální počítač má v sobě síťovou kartu která buď emuluje reálnou kartu která existovala/existuje (e1000, rtl8139), nebo se jedná o paravirtualizaci (virtio-net). V prvním případě se emuluje PCIe a tedy bude to "ens", ve druhém případě je to stejný případ protože musí fungovat hotplug. Případy dávám pro QEMU/KVM, na jiné platformě (VMWare) to budou jiné názvy karet i ovladačů.
Problém je, že ten seznam co napsal Petr do článku kdysi dávno vyšel někde na Lennartově blogu a nyní to věšichni od sebe navzájem opisují. A to včetně Red Hat dokumentačního týmu, poslal jsem jim BZ aby to tam dodali ať je to jasné pro všechny:
-
ona nejcastejsi situace je ze: mam 1 sitovou kartu, je mi jedno kam ji zapojim, zda bude interni nebo externi...
chci aby se vzdy jmenovala stejne, takze co udelam?
=> ano tu "genialni" predikci proste vypnu pomoci net.ifnames=0 kernel parametru...kdyz vymenim kartu upravim si sam podle sebe pravidla pojmenovani dle MAC v /etc/udev/rules.d/70-persistent-net.rules, tedy JEN pokud sem si ho predtim sam vytvoril, pokud ne, neresim nic - automaticky se jiz nevytvari...
resp. nejen s 1 kartou, delam to takto i kdyz mam 10 ethernet sitovek ;-)
-
Ondřej CaletkaZlatý podporovatel
Takže se možná čas od času síťovky při restartu přehází jinak. Pokud jsou třeba všechny bridži, tak to asi nevadí, ale ve většině případů je to fatální problém.
-
Ondřej CaletkaZlatý podporovatel
Aha tak to je ten druhý případ, kdy riskuješ, že se ti čas od času některé síťovky budou jmenovat ve stylu
rename_eth2, protože došlo k souběhu během jejich přejmenování. Ale je z toho snadná pomoc, která navíc ušetří i psaní – síťové karty přejmenovávat naet0,et1,… nebo v zásadě cokoli jiného, jen neetha podobná slova, která přiděluje jádro. -
Ondřej CaletkaZlatý podporovatel
To je přesně ten problém souběhu. Někomu se to nestane nikdy za život, někomu se to bude stávat pětkrát do roka a někomu každý den – záleží totiž na mnoha faktorech.
A teď si představte programátora, kterému uživatelé reportují problém a on ho u sebe není schopen reprodukovat, protože zrovna patří do té šťastnější části populace. Jak má takový problém opravit? Je potom jasné, že raději navrhne něco, co takový souběh zcela vylučuje, byť za cenu porušení zpětné interoperability.
-
Aha tak to je ten druhý případ, kdy riskuješ, že se ti čas od času některé síťovky budou jmenovat ve stylu rename_eth2, protože došlo k souběhu během jejich přejmenování.
Co si pamatuju, tak tohle se stávalo hodně dávno a jen v tom případě, že už bylo něco nastaveno a přišlo se s novou síťovkou, která se bila s původním nastavením. U čistého nikdy a i ten souběh velmi rychle v některé z novějších verzí udev upravili a pak už se to nevyskytovalo nikdy.
A komu nestačí to co umí pravidla udev, tak se od nepaměti dá použít již výše zmíněná utilita ifrename, která fungovala daleko dříve než vůbec někoho napadl udev neřkuli systemd. Bonusem navíc je, že ifrename umí přejmenovávat/pojmenovávat podle hromady jiných kritérií. Když admin není klikoš a své kroky si předem promýšlí, dá se to lehce nachystat dopředu a po upgrade/změně/výměně (whatever) nastartuje v novém tak, že vše jede jak má rovnou a nemusí se koukat, jakpak se přejmenovaly nepředvídatelně síťovky podle křišťálové koule integrované v systemd. Protože největší potíž s tou věcí v systemd je, že tvrdí (stejně jako někteří tady v diskuzi), že když uděláte změnu (přidáte síťovku třeba), tak že se s původníma nic nestane a budou mít stejný název, což je ale z praxe mnohokrát ověřeno, že to není pravda.
Takových pastí je v systemd více, bezvadný je třeba ten timeout na ukončování služeb při shutdown/reboot. Když jsem tu kdysi někde psal, že to nefunguje, byl jsem přesvědčován, že to ne naopak jasně definovaná věc, která nikdy rozbitá nebyla a jediné co je jinak, že ten timeout je ve výchozím nastavený 90 s, což může být zbytečně dlouho. Byl jsem přesvědčován, jak jsem blbej a že s tím neumím ap. Zrovna dneska jsem opakovaně ukazoval kolegovi, jak si ten drzý systemd je schopen ten timeout zvedat, když se odpočet přiblíží té 1:30 min a najednou je třeba čekat 2 min nebo 3 a tak furt dál. A ne prvního dubna ten komp nastavený neměl.
-
ja. (neregistrovaný)
Semantika SIGHUP (teda to, co riesi tmux, screen, et al) nikdy nedefinovala, ze dany proces ma prezit odlogovanie z GUI session. Ona definovala, ze ma prezit stratu terminalu, co nadalej funguje, ked zavries v GUI session terminal, proces ti bezi dalej. Ono to bude tym, ze ked sa SIGHUP definoval, tak GUI sessions ani neexistovali.
Historickym vyvojom preslo, ze prve window managery nejako user session neriesili. Az prisiel consolekit/logind a riesit sa to zacalo. Pre tmux/screen/et al urobili API, aby mohli spustat svoje procesy v samostatnom scope. To, ze to upstream tmux nechce pouzivat z tvrdohlavosti, je len ich problem.
-
Ona definovala, ze ma prezit stratu terminalu, co nadalej funguje
Nefunguje a vůbec nevím, proč do tohoto problému taháš GUI. To, že systemd s defaultním
KillUserProcesses=yeszabije všechny uživatelské procesy po odhlášení platí i pro ssh a dokonce někdo nedávno řešil případ, kdy mu systemd zabil procesy, které spouštěl z cronu.Tedy tato změna postihla zejména serverové nasazení a žádné GUI s tím nemá nic společného.
Takže rozhodně nestačí "opravit" tmux, tahle změna toho rozbila daleko víc.
To, ze to upstream tmux nechce pouzivat z tvrdohlavosti, je len ich problem.
Ano, systemd rozbil něco, co roky fungovalo ale opravit to mají všichni ostatní. Klasický přístup.
(Bez ohledu na to, že všude používám
KillUserProcesses=yesa věci se snažím řešit přes prostředky systemd, jako user services apod. Nařizovat to direktivně všem a potom ještě ukazovat na projekty, které tady byly dávno před systemd, není správné.) -
ja 14.9. 11:54 [...] nikdy nedefinovala, ze dany proces ma prezit odlogovanie z GUI session. [...]
priklad. uzivatel "ja" je prihlasen lokalne na plochu, uzivatel "ja" se prihlasi vzdalene pres SSH a pusti s tmux, po nejake dobe (z jakehokoliv duvodu) restartuje lightdm s prihlasenou plochou z ktere se zadny tmux nepoustel...
- "pred systemd" - tmux na ssh bezel dal
- "pri systemd" - tmux na ssh je (ve vychozim chovani/nastaveni) zabitpodobne treba mount a /etc/fstab... mas tam definovan datovy disk, kterej (za jakehokoliv duvodu) neni dostupny, das pres ssh vzdalene reboot
- "pred systemd" - system nabehl, datovy disk nepripojen, mohl si s tim neco delat/ignorovat, nebo smazat zaznam z fstab
- "pri systemd" - system prerusi startovani, hodi te do maintenance PRED startem SSH demona, takze se na to vzdalene nedostanes, a to presto ze datovy disk NEni potrebny pro start systemu
=> musis pridat do fstab volbu nofail, coz bylo predtim default -
ja. (neregistrovaný)
Priklad 1 (tmux, lightdm): Pouzival ma rozbity system, bud to urobil sam, alebo jeho distribucia. By default (=ked nikto nic aktivne nepos**e) ssh sessny su vzdy samostatne sedenia, v samostatnych cgroupach.
Priklad 2: nie som si isty, ci bol predtym nofail default, ale ak ano, tak je to dost problem. Ak sa ti nenamontuje disk, ktory je potrebny pre beh systemu, tak to je dost pruser (ja mam napr. kopec veci v /srv a keby nenabehol, tak ani servisy co s nim pracuju nemaju ako). Ked admin explicitne uvedie nofail, tak potvdrzuje, ze nie je pre beh systemu nutny.
-
DannyStříbrný podporovatel
Presne do tohohle stavu se soubehem se teoreticky dostanes i s prediktivnimi nazvy sitovych rozhrani. Jednoduse proto, ze to neprovadi kernel pri inicializaci ovladace (to se vsechna rozhrani vytvori postaru - tedy jako ethX), ale provadi se az v ramci initu formou obligatniho prejmenovani... jak uz jsem zminil, sam jsem se dostal (na systemu, kde prediktivni jmena byla zapnuta) do stavu, kdy po dlouhem cekani bylo v systemu par sitovek "renameX"...
Proste je to zase jen bastl nekde za kernelem - jen pojaty trosku jinak. Systemove reseni by bylo toto pojmenovani mit uz na urovni kernelu - ale to se bohuzel nedeje.
-
U virtualu to taky neni predikovatelny. Potrebuju vymenit SATA radic a ejhle, misto “ens192” koukam na “ens224”. Tedy az pote co vlezu na konzoli, protoze sit je mrtva.
Ne nadarmo je “how to predict predictable network interface name” v googlim top10 :-(
Co se tyce VMek, puvodni eth0, eth1, ... bylo znatelne predikovatelnejsi. Stacilo v hw u VM odpocitat kolikata to je sitovka. -
ens224 => ens160 (protoze vymenou radice, coz je odebrani stavajiciho a pridani novyho posoupnou vsechny pci(e)). “ens224” bejva druha sitovka. Tedy pouze za predpokladu ze byla pridana hned po prvni sitovce ktera dostala pnin “ens192”. A dost mozna i podle distra, protoze mam dojem ze u RHEL/Centosu to dostalo tuplovane jiny oznaceni.
-
Petr Neni (neregistrovaný)
Ano, ono je to naprosto predikovatelne ze z ens160 vznikne ens224. /ironie
Tohle oznacovani ma spoustu IF podminek, takze ve finale aby clovek mel prehled musi mit u 1000 serveru evidenci ktera sitovka je v kterem slotu namisto snadneho eth0,1,... tohle proste dava stejny smysl jako cely systemd ktery Lennart nakodil ozraly pod vlyvem houbicek a koksu, jinak se to proste neda vysvetlit. Reseni oznacovani sitovek ala EU, kde vsichni tusi ze je to naprosta pitchovina, ale budeme si hrat jak super to je protoze je to advanced a muzu dle nazvu vedet ze je to pci stiovka a ne onboard. -
dizzy (neregistrovaný)
cakal som, ze sa to tu zvrhne na hromadne onanovanie nad tym ako je systemd na p**u a aky je Lennart... Takze len dve poznamky:
- da sa to vypnut (zatial ;-)) a mozes si nadalej uzivat stare "dobre" schema pridelovania
- systemd je opensource, takze ti nikto nebrani vymysliet a naimplementovat genialne riesenie a poslat pull request.Mimochodom, ked uz sme pri tom, ake riesenie navrhujes ty? Lebo mne osobne sa v minoulosti bezne ethX nazvy prehadzovali takmer po kazdom vacsom upgrade jadra, co je najma pri serveri, ktory pocuva na verejnej IP adrese dost neprijemne. Nadavat totiz dokaze kazdy...
-
Tak já odpovím z pozice seniorského vývojáře v Red Hatu. Zkušenému člověku manažeři dávají volnější ruce, Lennart není žádná výjimka. Sám to mám taky tak. Netvrdím že si děláš celý den co si zamaneš, ale ten prostor může být hodně velký. Denodenní povinnosti má každý, zejména opravovat bugzilly to se někdy musí když se finishuje release, ale jinak to může být pro někoho celkem těžko pochopitelné. Dám příklad.
Do posledních tří major verzí produktu na kterém dělám jdou featury které byly moje invence. Měl jsem prostě pocit, že tohle by projekt potřeboval, navrhl jsem řešení, poslal patche do všech komponent a nyní to používají lidé z komunity i zákazníci. Žádný manažer mi neřekl "budeš dělat to a to", je to spíš tak že odprezentuju nápad a prototyp a manažer řekne "je to ok, hodí se nám to do krámu, dělej na tom dál".
Ne každý senior to tak má, člověk musí mít čuch na to, co se hodí v upstreamu, downstreamu, co manažer dokáže snadno obhájit u svého nadřízeného a tak dále. Nicméně nic světoborného to není.
-
Petr M (neregistrovaný)
Takže rozdíl je jenom v tom, že chce řešit problémy tohoto světa a když na nějaký problém narazí, vymyslí řešení?
Tak ať to kritici dělají stejně - najdou problém, najdou řešení a implementují ho. U nás se vždycky, když něco děláme, pokusíme najít víc řešení a vybírá se to lepší podle pro a proti. Pokud Lennart vytasí nějakou "pitomost" za RedHat, proč třeba Suse nebo Canonical nepřijdou s alternativou?
-
Problém je, že ta Lennartovská "řešení" vždy vyřeší jeden okrajový problém a spoustu dalších přidělají. Při tom to v tomto případě šlo řešit jednoduše - nový "prediktivní" systém dát jako volbu jen těm, kterým to něco přinese. Ostatní by jeli po staru a měli klid.
Canonical alternativy má (pro problémy svých uživatelů), ale syslí si je u sebe a nedává je do upstreamu, za což paradoxně bývá dost často kritizován.
Vysvětluju si to tím, že je to od Redhatu záměr - administraci Linuxu zkomplikovat natolik, aby si na řešení umělých problémů musely zaplatit podporu - a to zase u Redhatu.
-
t (neregistrovaný)
Já jsem ve světě bez systemd žádný problém nespatřoval a vše fungovalo dle očekávání tak jak přesně mělo. Že Lennart vidí v něčem problém a hned na něho musí najít řešení neznamená, že stejný problém ve věci vidí jiní, či že vůbec daný problém existuje jinde než v hlavě pana Lennarta.
Připadá mi to jak EU. Ta taky vidí problémy tam kde nejsou a hned nalézá všespásná řešení takto vyskytnuvších se problémů.
-
Takže rozdíl je jenom v tom, že chce řešit problémy tohoto světa a když na nějaký problém narazí, vymyslí řešení?
Aniž bych se chtěl přidávat k dobře rozjetému flamu, tak nahradit jedno problematické řešení jiným problematických řešením je jako to známé rčení "z bláta do louže". Ano, předchozí řešení jmen síťovek není dokonalé, ale už si na něj tak nějak všichni zvykli. Nové řešení není dokonalé a budou si na něj muset všichni zvyknout.
Tak ať to kritici dělají stejně - najdou problém, najdou řešení a implementují ho.
To je zcela mylný postup. U spousty věcí (nejen ze světa systemd) má člověk pocit, že by stačil rollback na předchozí non systemd řešení. Problém je, že takto se nepostupuje. Kdykoliv systemd s něčím přijde, tak se chce oprava jen toho systemd řešení a o tom, že to třeba před zásahem systemd vlastně fungovalo se nesmí mluvit.
Ale ano, rozumím, taky jsem měl tu čest s managery, pro které bylo nutné všechno každý rok 3x všechno předělat, aby se něco dělalo. To, že se předělávalo něco, s čím vlastně nikdy nebyl problém nechtěli vidět. Pořád chtěli lepší a lepší řešení (neexistujícího problému). To je jako řvát na horolezce na vrcholu Mount Everestu, že to nestačí, že musí šplhat ještě vejš. Od takových debilů je dobrý se co nejdřív vzdálit.
-
dizzy (neregistrovaný)
Az na taku malu drobnost, ze ani jedna z tych uzasnych nahrad "v podobe systemu bez systemd" to nedotiahla do enterprise level riesenia. Takze nikto nie je ochotny brat prachy za support tychto bezplatnych bezproblemovych systemov a vsetci velki dodavatelia Linux distribucii su uplni idioti a zbytocne si komplikuju zivot a zvysuju naklady zavadzani systemd...
Odporcovia systemd by sa mali rozhodne spojit a tuto dieru na trhu vykryt, skor, nez im niekto tento napad vyfukne :-)...teraz koniec srandy - lebo vidim, ze len mavam cervenou handrou s napisom systemd, na ktoru len niektori prehnane a iracionalne reaguju a zbytocne zbieram negativne body :-)
-
t (neregistrovaný)
Tak uprime v enterprise levelu at si delaji co chteji, at si plati koho chteji. Ma zkusenost s 800+ servery ve skolach po CR a SR i Polsku a Nemecku, jede se striktne bez systemd a uplne v poho. Jestli se chce nekdo zasekat se systemd, a platit admina za nekonecne googleni s kazdou novou verzi, nizkou produktivitu prace, nasrany klienty, kteri cekaji 14 dni na reseni jindy trivialniho vzdaleneho servisu, ci si chce platit treba primo Lennarta, pac ten jediny se v tom svem systemd snad vyzna, to je jeho boj a jeho prachy. U nas to delame ponekud rutinneji a systemy bezi naprosto stabilne. Ja jsem tedy nadmiru spokojen i bez systemd :) PS: ja za servis systemu bez systemd prachy beru, majitel je spokojen s funkcnosti a plati celkem slusne. Takze asi jsem vyjimka a nepatrim do vami zminene skupiny "nikdo".
-
dizzy (neregistrovaný)
Vy ste to to mozno z kontextu nevycitali, ale ja som nemal na mysli nejaky maly e-shop alebo homepage firmicky s 10 zamestnancami, kde si 2-dnovy vypadok nikto nevsimne. Situacia je dnes taka, ze vsade, kde vypadok sluzieb znamena tazke financne straty, sa nasadzuju v pripade GNU/Linux LEN distribucie, ktore splnaju urcite podmienky (stabilita, podpora, ...).
Momentalne neviem o ziadnej takej distribucii, ktora by nenamigrovala na systemd. Ja na rozdiel od Vas si nemyslim, ze by Lennart Poettering bol az taky diabol, ze by politickymi machinaciami alebo zakulisnymi tahmi dokazal zmanipulovat firmy ako RedHat (ok, tam este mozno hej, dajme tomu..), Canonical, alebo SuSE. Skor to vyzera tak, ze systemd ma zrejme nejake kvality, kvoli ktorym sa tymto firmam oplatilo investovat nemale prachy na premigrovanie existujuceho init systemu na systemd.
Mne osobne tiez na systemd niektore veci vadia, ale fascinuje ma, ze drviva vacsina zarytych odporcov systemd pouziva len argumenty v style "mam to nejako nabastlene, tak mi to chodi uz roky a systemd mi to cele rozmrdal" (prip. "roky som zvyknuty to robit takto a systemd je na <> lebo to musim robit inac"). Za cele tie siahodlhe diskusie (teda skor flamy), ktore som mal tu moznost precitat som narazil az na JEDEN RELEVANTNY TECHNICKY ARGUMENT preco systemd nie, inak vsetko same dristy (zhrnute v dvoch vetach vyssie).
Skuste si, mili bojovnici svatej vojny proti systemd, aspon poriadne nastudovat, proti comu to vlastne bojujete a ci by Vam niektora jeho vlastnost napriklad neusetrila dlhe hodiny stravene ladenim skriptov, pretoze ak budete apriori odmietat vsetko nove, tak to zrejme v IT biznise moc daleko nedotiahnete... -
null null (neregistrovaný)
@dizzy
Tak systemd byl v podstatě nasazený IMO ve stavu Alfa verze do produkčních verzí dister. Co, jak a proč je otázka, údajně tam měl hrát roli "strach" z další nekompatibility s hlavními hráči - nevím. IMO potřebovali prostě širokou základnu pro laděním jinak by to doteď dělali na koleni a nepotkali ani 1/2 možných konfigurací reálných nasazení. Třeba v Debianu to údajně prošlo o jeden hlas, což mi zas tak super abys tady s tím mohl ostatní fackovat nepřijde. Problémů okolo systemd - faktyckých - byla hromada, uznávám to je všude, ostatně někdo tady vkládal zajímavou reakci od Linuse - nemyslím si že by to byl jenom nějaký trotl který si nenaštudoval nějaké scripty a teď jenom tak pindá. Systemd prostě zasáhl široké pole - už z definice určení - a na to jak budovat a řídit široký systém je více možných názorů a netroufl bych si šmahem jako ty jen tak ostatní spláchnout jako nějaké obyčejné trotly nebo hatery. Třeba mě osobně vadí že se z toho stává komponenta, které místo aby řídila a předávala, tak požírá další a další součásti systému a prostě toto se mi v životě a praxi neosvědčilo. Názor tedy nějaký mám - jak mám prokázat že už je to moc? Jsem bojovník svaté války?
A podobně, přestože je to u těch zlých svatobojovníků přehlíženo, málokdo z nich neuzná že nebylo potřeba zlepšení či vyřešení. Jenomže názory i na celkem takové neurčité věci jako je rozsah, chceš-li zásah, do architektury se různí a nemusí být správný jenom jeden, těžko se prosazují protože mají svá pro i proti a krom vyložených pindačů, byl bych velice opatrný na to paušálně všechny označovat jako nějaké "bojovníky ve svaté válce". Nehledě na to že spousta se jich tak nechová. Ovšem uznávám, nic jednoduššího než označit skupinu s protinázorem za hlupáky není. A to taky zrovna oblibě systemd nepřidá, když se ti třeba ten přístup tak úplně nelíbí a ještě tě někdo fackuje takovýmy nálepkami ... -
dizzy (neregistrovaný)
Vidis Kentan - ty si prave trafil ten jediny relevantny argument, ktory som mal na mysli (a ktory som tam naschval nepisal), preto mas za mna palec hore ;-) Toto je totiz jediny protiargument, ktory beriem - naozaj systemd sa snazi riesit veci, ktore by nemusel (napr. nahrada cron-u). Osobne by som tiez uvital, ak by sa rozbil na viac (podla moznosti volitelnych a idealne vzajomne nezavislych) modulov ale beriem to ako nutnu dan za nesporne vyhody, ktore na druhej strane prinasa...
Ja som narazal skor na ludi (a je ich tu zial strasne vela), ktorych argumentacia stoji na tom, ze im cosi kdesi funguje, su na to zvyknuti a sprosty systemd im to rozbil. -
null null (neregistrovaný)
@dizzy
Tak argument ... Nezbývá ti nic jiného než ho zobrat, protože to jestli systemd řeší moc věcí nebo ne je věc názoru a nejsem si vědom toho, že by se někde dala nalézt nějaká přesná odopvěď ve stylu naplnění nějaké věštby nebo definice. Maximálně nalezneš nějako autoritu před jejíž výrokem se skloníš, uznáš nebo ho přijmeš. To je celé.
Kdesi cosi - takže nevíš kde, nevíš co, je ti to jedno, ale označíš to za chabý argument v tom lepším případě, za svatoválečníky ~ zaslepence v tom horším, přestože jsi schopný přijmout argument že toho řeší až moc, tedy zasahuje do moc věcí tedy by mohl někde zbytečně zasáhnout do věcí které těm lidem fungují ... ach jo ...
-
dizzy (neregistrovaný)
Zle si ma pochopil Kentan - mne vadi skor to, ze je to jeden velky monolyt, nez to, ze zasahuje do viacero oblasti. Cize kludne nech tieto oblasti pokryva, ale modularne (t.j. oddelene a prip. nahraditelne). Je to taka moja idealizovana predstava ako by to malo vyzerat (a nie som si isty ci je to vobec technicky mozne).
Na margo zasahovania do fungujucich veci - zial nemozes ocakavat, ze skript, ktory si zbastlil pred 10-timi rokmi ti bude fungovat dalsich 100 rokov. Pretoze ked ti ho nerozdrbe systemd, rozdrbe ti ho nova verzia bashu, OpenRC (alebo co presne pouzivas), prip. ineho systemoveho komponentu, ktoreho prinos bude pre teba mozno otazny. Spatna kompatibilita sice vyzera dobre na papieri ale v praxi si so sebou prinasa vela technickych komplikacii. Plakat nad tym, ze sa po 20 rokoch (toto cislo som si typol, takze mozno nebude uplne presne) na Linuxe premenovali zariadenia mi pripada byt v dnesnom svete trocha scestne vzhladom na tempo akym sa technologie vyvijaju.
Ber to ako evoluciu - ja si myslim, ze doteraz pouzivane init systemy boli neudrzatelne a vnimam systemd ako riesenie, ktore zial nie je idealne, ale prinasa IMHO viac vyhod ako nevyhod. V tomto sa mozno nezhodneme, ale to je uplne jedno, pretoze jak ty tak aj ja s tym trt makovy urobime a zrejme nam nezostane nic ineho, nez sa prisposobit... -
null null (neregistrovaný)
@dizzy
No je celé takové nedomyšlené. Např. bavili jsme se o tom, proč hned neházet všechny nemilovníky systemd do jednoho "svatoválečného pytle" a ty do toho zatáhneš přejmenovávání zaízení .... Je to sice téma článku ale ne našeho rozhovoru. Jenom do toho zatahuješ další nesouvisející věc - jak můžeš mít situaci kolem našeho tématu promyšlenou když do toho mícháš další věci?
Dále jako jediný protiargument bereš to že zasahuje mnoho, resp. až moc, oblastí okolo, v druhé píspěvku ale zase že ti spíš vadí že je to monolit, což jsou neosouvislé věci a u systemd to ani neplatí, není to monolit, jenom zasáhl jako monolit ... jak říkám, chce to domyslet ... -
dizzy (neregistrovaný)
Kentan, hovoril som o drvivej väčšine, nie o všetkých, ale to nie je to podstatne. Podstatné v tom pôvodnom príspevku bolo to, že dookola sa tu stále opakujú tie isté argumenty o tom ako niekomu niečo roky rokúce fungovalo a ako mu to zlý zlý Lennart so svojim systemd rozbil.
Ja chápem, že je to k vzteku, prerábať niečo, čo funguje, kvôli zmene, o ktorej prínose nie ste zrovna úplne presvedčení, avšak systemd presvedčil väčšinu ľudí, ktorí o tom rozhodujú (a narozdiel od Vás, si nemyslím, že ich všetkých oblafol, ožral, zdrogoval, pretiahol,...).
Z môjho pohľadu robí systemd presne to, čo má (ok, možno trocha viac) a robí to IMHO výrazne lepšie než doteraz používané init systémy, takže ako protiargumenty by som skôr čakal konkrétne príklady toho, čo sa cez systemd nedá urobiť vôbec, alebo sa to robí výrazne horšie ako doteraz.
Ale uznávam, že som to mohol povedať aj menej, expresívne...
Snáď sa mi to podarilo zhrnúť bez zbytočných odbočiek. -
@dizzy zatimco lidi co "nadavaji" na systemd uvadi priklady z praxe, ty jako "obhajovac" pises(v principu) "kdyz to vsichni prevzali tak to preci musi byt bezva" to mi rekni kdo je vetsi slepej bojovnik ;-)
ze im cosi kdesi funguje, su na to zvyknuti a sprosty systemd im to rozbil.
tak bylo by seriozni kdyby nemenil urcite chovani co vede ke ztrate, napr co sem uvedl jinde:
https://www.root.cz/clanky/predvidatelne-pojmenovani-sitovych-karet-v-linuxu-kam-se-podelo-eth0/nazory/994017/radeji nepremyslet co vse systemd sezral, tady (rok 2013) je toho uz tak dost...
https://www.youtube.com/watch?v=bdmv2FQRHWg -
dizzy (neregistrovaný)
@k3dAR
"kdyz to vsichni prevzali tak to preci musi byt bezva" to mi rekni kdo je vetsi slepej bojovnik ;-)
- alebo, žerte hovná, miliardy múch sa predsa nemôžu mýliť ;-) Ale teraz vážne - áno, myslím si, že je to silný argument - to, že to prevzali všetky major distribúcie o niečom svedčí (aj keď uznávam, že tie posledné už asi moc na výber nemali). Ale samozrejme môžem tu začať menovať konkrétne dôvody, prečo si myslím, že je systemd lepší ako "tradičné" riešenia...- čo sa týka tvojho problému - je to nová vlastnosť, ktorá mala byť riadne zdokumentovaná a mala by byť defaultne zapnutá skôr pri nejakom security profile (myslím ten kill). Systemd to mal zdokumentovať, na úrovni distribúcie sa to malo pri normálnom desktope vypnúť (mať bezpečnejšiu voľbu ako default je momentalne totiž trendy, viď selinux ;-))
- čo sa týka mountovania, pokiaľ sú všetky disky, potrebné na beh systému dostupné, systém by mal určite nabehnúť, o tom žiadna, tu skôr ale mám väčší problém s tým, že nenabehol, než s tým je niekde nejaký default (až sa mi nechce veriť, ale som lenivý to skúšať)
Áno, žiaľ aj v systemd sú bugy, uznávam (dostali ste ma ;-)). Treba žiaľ hľadať také nastavenia, pri ktorých sa buď workaround - ne, prip. začne chovať presne podľa Vašich predstáv a to sa zatiaľ v oboch spomínaných prípadoch dá. Aj keď je to možno vopruz, nie je to showstopper. Holt zakaždým, keď sa migruje na nový systém, je s tým spojená určitá pracnosť a nie je reálne očakávať, že Vaše nastavenia /skripty budú fungovať večne :-(
Tiež nie som nadšený z toho, že už takmer všetko má závislosti na systemd, ale vnímam to ako cenu za vylepšenia, ktoré sú podľa mňa dosť podstatné, či Vy ste si skutočne nič, okrem problémov nevšimli? -
@dizzy
čo sa týka mountovania, pokiaľ sú všetky disky, potrebné na beh systému dostupné, systém by mal určite nabehnúť, o tom žiadna, tu skôr ale mám väčší problém s tým, že nenabehol, než s tým je niekde nejaký default (až sa mi nechce veriť, ale som lenivý to skúšať)mas to treba tady: https://www.freedesktop.org/software/systemd/man/systemd.mount.html
nofail
With nofail, this mount will be only wanted, not required, by local-fs.target or remote-fs.target. This means that the boot will continue even if this mount point is not mounted successfully.
jiste ze kdyz by nekdo cetl dokumentaci, manual nebo mailing list, tak na to narazi, prida nepotrebnym zaznamum v fstab nofail a ma hotovo, nicmene princip problemu je v tom, ze drive bylo nofail vychozi, ted ne, takze spousta lidi na tuto "vlastnost" prisla kdyz restartovala vzdaleny pocitac ktery jiz nenabehl i kdyz systemove oddily se pripojili ok, takze museli sednout do auta, dojet k serveru, dat pokracovat ve startu, pridat nofail...pro uplnost, k nofail je potreba pridat jeste x-systemd.device-timeout=3, protoze samotne nofail nezajisti aby systemd zbytecne necekal 90vterin pro kazde zarizeni co mu nejde pripojit a zaroven samotne x-systemd.device-timeout=3 nezajisti aby se nezastavilo bootovani skocenim do "zachraneho" (bez SSH) rezimu...
-
anon (neregistrovaný)
Protoze system kde "0day" user dostane prava roota a zavreme to jako not-a-bug a nebudeme resit je to nejlepsi pro produkci.
Ve velkych firmach se zasadne vybira to za co dostane zjebano NEKDO JINY pokud se to posere, tam systemd nikdo neresi a proto si tam muze lennart lestit svoje ego a pridelavat praci vsem okolo.
-
Lol Phirae (neregistrovaný)
Kdyby někdo náhodou netušil, o čem se mluví, tak odkaz na frikulínského blba v akci zde: https://github.com/systemd/systemd/issues/6237
-
DannyStříbrný podporovatel
A jak dlouho se tim (davno opravenym) CVE-2017-1000082 budou lidi jeste ohanet? :-) Takovych problemu bylo, je a jeste bude... staci se podivat na takove CVE-2018-10938 v kernelu, ktere sice bylo opravene pres rok, ale nejakym "nedopatrenim" se to jaksi pozapomelo backportovat do stabilnich verzi kernelu. Proste ten patch nekdo chybne klasifikoval :-) Chybuje nejen Poettering... a mnou odkazovane letosni CVE byl ve vysledku ponekud vetsi pruser...
-
Lol Phirae (neregistrovaný)
A jak dlouho se tim (davno opravenym) CVE-2017-1000082 budou lidi jeste ohanet? :-)
Asi do té doby, dokud bude LP k chybám ve svém produktu přistupovat jako úplný kokot. Protože přístup "když je něco nevalidní, tak to pustím jako root a nějak to dopadne" hraničí se zbavením svéprávnosti. Nota bene, když si vzpomenu, že na druhou stranu byl ten samý jedinec schopný prostě totálně rozbít boot jen proto, páč se mu např. nelíbilo, že /etc/mtab je soubor a ne symlink. Ten člověk je obecně nebezpečný psychopat.
-
DannyStříbrný podporovatel
On je ale jenom programator. Jsou cinnosti, ktere by mel vykonavat nekdo jiny - vyvoj obecne neni jen o jednom cloveku, tech roli je vic a je potreba je oddelovat (bohuzel u opensource se to ne vzdy dari - ale to je chyba systemova, nikoliv chyba toho dotycneho). Nicmene ten argumenty ad reakce kolem CVE-2017-1000082 jde pouzit i obracene - pokud je admin takovy jelito, ze udela ve svym konfigu unity preklep, pusti to a necha bez kontroly (treba i toho, ze mu to bezi pod spravnym UID) bezet, tak jde na dotycneho admina pouzit podobne expresivnich vyrazu... a rootovsky prava mu do rukou nepatri zrovnatak.
-
DannyStříbrný podporovatel
Nikdo vas ho pouzivat nenuti. Cest je vzdycky vice... napriklad http://www.linuxfromscratch.org/lfs/ :-)
-
DannyStříbrný podporovatel
Tak ono je ve vysledku vcelku fuk, zda se vyvojar vykrucuje... nebo opravu zatluce takovym zpusobem, ze nikdo z toho nepozna, ze jde o opravu bezpecnostni diry (jako v pripade tech CIPSO zneuzitelnych i vzdalene). Rozhodne nejde nadavat jen jednomu clovekovi - chybuje kdekdo.
U toho systemd to "pusteni pod rootem" bylo ve vysledku jen nespravne osetreni chyby v konfiguracnim souboru (ktery ale upravuje zas jen root a reportujici osoba na to prisla asi diky vlastnimu preklepu v unit configu; rozhodne bych to nenazyval nejakym 0day exploitem snadno zneuzitelnym nekym z ulice). Bug byl nahlasen 29.cervna 2017, po velkem humbuku je tomu 6.cervence formalne prirazeno CVE a 12.cervence 2017 vychazi nova verze systemd, kde uz ten problem neni - je opraven. Ale najdou se jedinci, co to budou vytahovat jeste po vic jak roce od incidentu - i kdyz to bylo vyresene behem ani ne 14 dni...
-
Lol Phirae (neregistrovaný)
Ale přece ty lidi to nevytahujou proto, že tam byla nějaká chyba (mraky chyb jsou všude), ale jako ilustraci přístupu LP k návrhu softwaru a řešení problémů. Dotyčný si ještě asi za těch mnoho let neuvědomil, že už si nehraje se zvukovým systémem, který, když se rozbije, tak se stane v zásadě velké lejno. :-(
-
DannyStříbrný podporovatel
Jenomze takhle reaguje kdejaky softwarovy vyvojar. Jenom kolem LP se dela takovy humbuk. Jak uz jsem psal vyse - navrh softwaru je pomerne komplexni zalezitost, nemuze se to hazet na hlavu jedne jedine osoby - a pokud se tak deje, tak jde v prvni rade o systemove selhani v obecne rovine, protoze se nikdo neobtezoval jednotlive role spojene s vyvojem jakkoliv oddelit. Programator je uz jen ta lopata, ktera ma neco delat na zaklade externich vstupu (aka nejaka analyza, specifikace atd). Jiste, setri se na ruznych mistech a na ruznych mistech, kde se neco vyviji je i analytyk povazovany za zbytecnost, zeano...
-
Lol Phirae (neregistrovaný)
Jenom kolem LP se dela takovy humbuk.
Nesmysl. Humbuk se dělá kolem každého na podobné pozici, když se jako začne chovat jako úplný tydýt, namátkou mě napadá např. DJB, Jörg Schilling... a ostatně u RedHatu už by mohli mít s těmito duševně vyšinutými jedinci taky zkušenost a podle toho se zachovat, viz https://bugzilla.redhat.com/show_bug.cgi?id=119185 (s tím rozdílem, že dotyčného onehdá aspoň vyrazili, ale tady tedy žádné řešení v dohledu nevidím.)
-
Lol Phirae (neregistrovaný)
Ona je ta debata stejně zbytečná, v RedHatu mají zjevně mnohem důležitější starosti než to, že tady nějaký blázen zcela nekontrolovaně rozbíjí linuxový init... viz zde.
-
DannyStříbrný podporovatel
Tak jeste jednou. Jakmile cokoliv stoji na jednom jedinem cloveku, tak je to spatne - systemove. Kdyz se nekdo chova jako tydyt, ma byt v jeho teamu nekdo, kdo to nejak koriguje. A je vtipne, ze vic energie lidi venuji tomu, aby nadavali na cloveka - misto toho, aby se snazili nejak zmenit ten system ;-) U opensource si lidi hodne zvykli na to, ze jeden clovek dela vsechno... ale ono delat pod tlakem spousty lidi kolem, co akorat na vsecko nadavaji taky nebude zadny med - a svoje stopy to zanecha. Hodnoceni dusevniho zdravi prosim prenechme povolanejsim odbornikum - to sem skutecne nepatri ani okrajove, zvlast kdyz tato hodnoceni padaji z ust zjevnych laiku v oboru psychologie. Nejsme v hospode u piva.
-
anon (neregistrovaný)
Snazit se zmenit system? Kdyz se podivame na priklade v tomhle vlakne, tak za vetsinu pruseru v linuxu ecosystemu vetsinou muze nejaky arogantni kokot v Red Hatu, ktery si muze delat co chce.
Realne to teda znamena informovat kolik Red Hat napachal skody a tlacit na nase zamestnavatele aby Red Hat prestali pouzivat.
-
anon (neregistrovaný)
A kdyz uz jsme u toho tak si tim i firmy dost pomuze, ze prestanou RHEL pouzivat, napr. ted ve stale podporovanem RHEL6 jsou *zname* code execution vulnerabilities s trivialnim exploity a pristup Red Hatu je *will not fix*.
https://access.redhat.com/security/cve/cve-2018-16509
Skvely, jak si je Red Hat vedom, ze jsou zakaznici totalne v prdeli a kasle na to - viz sekce Mitigation
"Additionally, this issue can be triggered when processing files in order to generate thumbnails, for example when browsing a folder containing a malicious PostScript file in Nautilus. To prevent this, remove or rename the "/usr/bin/evince-thumbnailer" executable."
A ano RHEL6 na desktopu v mnoha korporacich stale bezi.
-
DannyStříbrný podporovatel
Nekdo nadava na RedHat, nekdo na Microsoft... no to jsme se posunuli :-) Kazdej ma svoje, nekdo zas nadava na Canonical, zejo. Nadavat jde na kohokoliv, ale to se fakt posouvame na uroven IV. cenovy na nadrazi...
Mluvit o skodach u software, kde formalne nikdo za nic neruci je vcelku vtipny ;-) -
anon (neregistrovaný)
A co se tyka nadavani na Canonical, tak o to se nam stara jeden znamy troll ucet "alex285" (za kterym imo stoji nekdo z Red Hatu) a nadavky jsou ve stylu "Ubuntu si dovoluje pouzivat vlastni gtk tema a nepouzivaji adwaita, c*raci jedni!".
Nedelam si srandu:
https://medium.com/@alex285/how-ubuntu-damages-gnome-just-with-a-theme-d6fb257e266
-
t (neregistrovaný)
Demokraticke hlasovani uvnitr nekterych distribuci nemusi vzdy znamenat dobrovolnost a uz vubec ne to, ze vysledek bude povedeny. V jinem svem prispevku zde v diskuzi pisu o 2 ruznych vecech, ktere (mate pravdu) zaroven prcam. A to obe dve. Jednou z veci je vec jmenem Lennart a druhou veci jsou zblbli tvurci distribuci, kteri bud diky demokracii, nebo vlastnimu rozhodnuti skocili veci jmenem Lennart na spek. Navic s vysledkem obvykle znacne polarizace drive docela v pohode komunity. Nastesti napriklad u debianu existuje reseni, kterym se da systemd celkem schopne odstranit a vse funguje jako drive. Jeste ze tak.
-
anon (neregistrovaný)
Tak zrovna v pripade debianu to fakt dobrovolne nebylo, nakonec odesel kvuli tomu z vedeni debianu autor noveho dpkg atd.
Maintainer systemd v debianu, ktery ho tezce tlacil, ted dela v Red Hatu.
https://wiki.debian.org/Debate/initsystem/systemd je plny lzi - moje nejoblibenejsi "Using systemd helps mitigating or eliminating other security issues, by bringing new security features to all daemons running on the system. Switching to systemd is a security improvement for the whole system" a pritom stacilo vytvorit uzivatele "0day" a mas roota a to zavreme jako not-a-bug
-
Petr M (neregistrovaný)
Btw, koukal jsem se na GitHub, kolik toho Lennart v tom zdrojáku "zprasil" a jak se do toho zapojil. Takže v produkčním kódu udev-builtin-net_id.c je to asi takhle:
852 LOC celkem, 21 LOC (2,46%) od Lennarta, z toho
- 1x prázdný řádek,
- 4x komentář
- 2x include jinýho souboru
- 1x direktiva #pragmaPoslední Lennartův commit se týká znaku pro copyright v hlavičce:
"Let's unify an beautify our remaining copyright statements, with a unicode . This means our copyright statements are now always formatted the same way. Yay."A jenom tak mimochodem, ten soubor založil Kay Sievers, ne Lennart "Univerzální Viník" Poettering...
-
dustin (neregistrovaný)
O to hůř, např. klasika http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01331.html
-
Puneš (neregistrovaný)
<cite>
Navíc tohle schéma docela dobře připomíná třeba pojmenování diskových oddílů v /dev. První oddíl na prvním disku je sda1, první port na první kartě je enp0s0.
</cite>No jenže konektory pro disky mají na desce jasné označení. Když tam zapojím disk tak predikovatelně vím jaké bude mít jméno. Vím jaké jméno bude mít síťovka zasunutá ve druhém PCIE slotu? Ani prd. Záleží jak výrobce motherboardu natáhnul linky. To je predikce jak prase. To už radši, použít udev a MAC adresy a přejmenovávat z kernelového eth na en, aby nešlo ke kolizi. MAC adresa síťovky je jediný jasný identifikátor navíc vždy známý. Buď je napsany na kartě nebo v definici virtuálu.
-
Petr M (neregistrovaný)
Tak koukám, že MAC adresu si můžu přepsat za běhu... Co se stane pak? Přejmenuje to zařízení v /dev a shodí komunikaci? Nebo zůstane jméno, ale nekonzistentní s HW?
A co když prostě zkopíruju image na jiný stroj s jinýma MAC adresama? Pojede to out-of-the-box?
I když jsem dělal fw na 100MHz embedded krámu s 1MB FLASH a 128kB RAM, musel jsem kvůli reuse knihoven, aletrenativním osazením desky a update systému volit identifikátory rozhraní nebo některých dat nezávislý na HW i verzi SW... Na větším stroji s víc rozhraníma, možností patche jádra za běhu, rekonfigurace za běhu a virtualizací je to o to horší! Pls nesvazovat nic s HW, pokud to není absolutně nutný.
-
j (neregistrovaný)
MAC adresu si rozhodne zmenit nemuzes ... muzes si zmenit MAC kterou pouziva system ale tu fyzickou nikolivek.
A kdyz skopirujes stroj s jinema sitovkama tak to nepojede tak jako tak, takze je to uplne jedno. V horsim pripade ti navic sit nejak nabehne, ale bez firewallu a dalsich veci, coz je daleko vetsi pruser, nez kdyz nenastartuje vubec.
-
Mti. (neregistrovaný)
"muzes si zmenit MAC kterou pouziva system ale tu fyzickou nikolivek" ...
Checht. Sem videl krabicu 10mbit karet s prilozenou disketkou... Karty mely mac pred-nastavenou, ale sla prepsat... a obcas zapominaly... :-D Nikdo je po case nechtel ani videt. Neni nad to mit pul ucebny s mac adresou 00:00:00:00:00:00 :-D
-
j (neregistrovaný)
Ja mel v ruce dve sitovky se stejnou MAC adresou ... a jo, u hromady HW muzes pochopitelne prepsat nejakou epromku nebo tak neco, ale neprepises to tak, ze zmenis MAC v nastaveni site v linuxu. V kazdym pripade je to zcela virtualni a neexistujici problem kterej nikdo neresi. Zato ty sracky od lennarta resej opakovane vsichni.
-
Petr Neni (neregistrovaný)
Ano, v praveku se mac adresy prepisovali protoze to melo sve duvody. Duvody pominuli, 10mbit coax se snad uz nikde ve vetsim meritku nepouziva, tudiz bych se vykaslal na moznost ze se muze zmenit mac adresa. Muze ji zmenit admin a ten snad vi co dela. A pokud ne, tak je debil a at si to pak opravi.
-
Adam KaliszStříbrný podporovatel
Autorizace podle MAC je poměrně hloupá záležitost, ale funguje na většinu běžných případů a co já vím, tak pomocí odpovídajících skriptů funguje jen na konkrétním portu switche, kde administrátor ví, že za tímto portem je jeden konkrétní pokoj, který má přesně jednoho nájemníka, jehož osobní údaje admin má od data registrace. Jinde tato MAC nefunguje a případný rozdíl je evidován a automaticky eliminován.
Docela by mě zajímalo, jak to přesně chcete v takové situaci zneužít. Jako v nejlepším případě se připravíte o spojení (skript port vypne), resp. Vás hodí do VLAN s captive portal (třeba pro vyplnění přihlášky) nebo někde, kde to zařízení umožňují, do unikátní VLAN, která je na backbonu realizovaná např. pomocí VXLAN nebo SPBM nebo jinak podobně izolované sítě.Kdo zlobí (porušuje stanovy sítě), tomu se jinak ve studentských sítích může pozastavit či úplně zrušit členství v síti a tím pádem efektivně eliminovat další incidenty. Spolupráce se zřizovatelem kolejí může v důsledku vést i k zrušení pronájmu pokoje, což např. uprostřed semestru nebo ve zkouškovém může mít následky. Samozřejmě vše má určitou míru, ale myslím, že např. za snahu nějak systematicky rušit provoz sítě (i když většinu typických problémů jako spoofing, DHCP snooping atp. má administrátor už dlouho podchycenou) i po napomenutí by pozastavení členství mohlo nastat. Podobně např. za nějaké očividné chválení rasově motivovaných zločinů nebo sdílení lechtivých filmů s nezletilými. (Kde by se po ujištění, že nejde o mýlku, pravděpodobně zapojila i vysoká škola a policie.)
-
Když tam zapojím disk tak predikovatelně vím jaké bude mít jméno.
Bohužel ne. Několikrát se mi stalo, že jsem do pcie vrazil další řadič, a tyto disky byly první a disky na desce (původně sda, sdb), se posunuly a to o tolik písmenek, kolik bylo v pcie řadiči disků.
Netuším, co by se stalo, kdyby tam těch řadičů bylo víc a měnil bych jejich pozice.
Ani tohle není predikovatelné, proto se vymysleli různé by-uuid, glabel apod.
-
A říkám, že ne? ;-)
U disků je výhoda, že na ně lze zapsat. Potom je super, že disk toho na sebe hodně vykecá, takže třeba ve FreeBSD používám pojmenování disků podle seriového čísla (diskid/DISK-ZDH32XAC). Disk má stejné jméno bez ohledu na pozici a současně na něj ani není potřeba zapisovat label nebo cokoliv dalšího. Má to taky tu výhodu, že když si na něj třeba ZFS stěžuje, tak podle SN okamžitě vím, po jakém disku sáhnout.
-
Trident (neregistrovaný)
Kdysi davno se resily levne IDE disky pres seriova cisla a to jen pokud je prozradily.
Ale WWN jsou tu velmi dlouho i u nejlevnejsiho spotrebniho keplu a je dobrou praxi i pres ne disky identifikovat(WWN byva i odvozene od serioveho cisla). Navic se nemusi menit zabehnuta praxe u FC,iSCSI a u levnych SATA disku. Admin pouziva stejny system jak u malych systemu tak u velkych storagi. Dneska i muj disk v 10 let starem notasu WWN ma. Neni duvod je nepouzivat. -
Tomas Z (neregistrovaný)
Jak presne ma ta symlinkova metoda blokace fungovat? Ptam se, protoze na me relativne zanovni Fedore 28 nefunguje, a na rychly google jsem u ni nenasel nikde vysvetleni. Pokud "přepsat výchozí politiku" znamena, ze nekde je stejne nebo podobne nazvany soubor, tak aspon podle locate neni a nebyl. Strilim na pohyblivy cil?
A update-grub taky nemam, ale s tim si poradim...
-
Osobně tohle nepoužívám a svazuju pevně mac adresu s názvem zařízení přes systemd link. Ale po každé změně je potřeba updatnout ještě initramfs, aby se změna projevila. Protože je udev součástí systemd, tak bych očekával že to zafunguje i ve Vašem případě. Ale netestoval jsem, nepoužívám ani ten udev symlink ani Fedoru ... takže to berte jako hint co ještě zkusit.
-
andreeeeeeeeeeee (neregistrovaný)
Je fajn ze sa rozdelili sitove karty na 4x3 tried (eno, ens, enp, slo......).
Nejak v tom clanku ale nevidim podstatnu informaciu - ako sa zaruci, ze to teda bude fungovat spravne, ak sa niektore z tych kariet pridavaju "hotplugom" a pod., zvlast ak je boot bezestavovy a rootfs readonly? Predpokladam ze toto bola ta primarna motivacia....?
-
andreeeeeeeeeeee (neregistrovaný)
"je fajn" == "whatever". Pride mi to zbytocne az kontraproduktivne; mizive percento ludi ma na HW viac ako 1-8 sitovek. V 90% to bude 1xETH + 1xWLAN, alebo napr. 8xETH + SFP; ak ma niekto 30x vsetky druhy sitovek v servri/routri, dost pravdepodobne si to stejne bude pomenovavat rucne aby to odrazalo realny stav? Ale tak snad Lennart & spol. nevymyslei takuto vec len aby utesili 1-2 zakaznikov, takze tam musi byt nejaka hlbsia myslienka...?
-
dustin (neregistrovaný)
Ono když kvůli přehozenému názvu síťovky heartbeat zdetekuje nedostupnost druhé strany, zahájí automatický failover a namontuje DRBD disk RW, čímž způsobí split-brain a musíš to pak celé resynchronizovat, taky nic moc. Je fakt, že přesně z tohoto důvodu automatický failover raději nepoužíváme...
-
motyq (neregistrovaný)
HA, ha, zha zha muhahaha.
A teď si k téhle kaši ještě přidejte netplan. Badum tssss.
Systemd mi prostě přijde logikou fungování jako windows. Prostě asi kvuli neschopným adminům začal vznikat systemd, který začal řešit věci nejlépe jak mohl a sám ví jak to má být správně..
Je mi z toho na blití, boj se systemd jsem vzdal - už ho prostě používám, ale pozapínaných mám jen minimum věcí, aby se mi kvůli němu co nejmíň věcí rozbíjelo.
Takové kombo jako: nové distro + systemd + systemd-resolved + hostnamectl + netplan = to je prostě kouzelná skříňka, která se ani náhodou nechová predikovatelně. Minimálně když se něco začne srát, tak v první řadě ztrácím čas zjišťováním, jestli nemá problém samotné systemd.
Příklad - stroj nemůže resolvit z nějakého důvodu:
- stará situace bez systemd (ok bez systemd-resolved) - zkontroluju /etc/resolv.conf jestli tam mám správně nameserver, zkontroluju jestli se dostanu ze stroje na dané nameservery, pokud ano pravděpodobně je problém mimo stroj a mám to jakože za jistotu.
- se systemd - twl přes co vlastně resolvim, neni systemd nějak jeblý - jo aha už vim přes co resolvim a dokonce se na ty stroje dostanu a můžu ručně resolvit, tak proč to kua neresolví. Vystoupit/nastoupit a stále prostě nemám jistotu kde je zakopaný pes.Se systemd prostě koexistuju, ale už z těch systemů nemám takový dobrý pocit, že je mám plně pod kontrolou a vím co dělají. Každým updatem systemd se děsím toho, co zas Poetering pohltil do systemd. Počítám, že budou následovat věci ohledně disků :-)
-
DannyStříbrný podporovatel
U systemd rozhodne neni nutne pouzivat vsechny jeho komponenty - a ne vsechny jeho komponenty jsou spatne. Vykopavat ale systemd jako takovy je nesmysl, ono to ma i sve pozitivni dopady (vedle par tech negativnich) a popravde jsem rad, ze je nejaka snaha to sjednotit i napric distribucemi... nektere veci jsou jinak, delaji se jinak - ale da se zvyknout a ve finale to az tak strasne neni, bavime-li se ciste o initu...
-
DannyStříbrný podporovatel
Tak treba pricetne vyresene zavislosti sluzeb (v configu, tedy lip, nez psanim jakychsi hlavicek do vykonnych shell scriptu) vcetne pokrocilych moznosti jejich izolace, monitorovani jejich behu a treba i automaticke restartovani v pripade jejich padu bez nutnosti to bastlit nejak jinak (ano, znam treba monit), paralelizace a tedy zrychleni startu (ktery zpomalovalo i parsovani/interpretace dlouhych startovacich shell scriptu)... Ono se toho najde dost. Chapu, ze na nejakou domaci Raspberry, kde si clovek hlida dva GPIO piny je to kanon na vrabce, ale na serveru to smysl rozhodne dava...
-
j (neregistrovaný)
Jakze? Zavislosti sluzeb ma gentoo v openrc kolik ... 10+ let? A narozdil od ty sracky to funguje. Monitorovat to NIC neumi, jen to blaboli neco o tom ze neco je v ramce, ale nema to ani paru jestli to bezi, naopak, srackomet systemd si dovoli slubu ve skutecnosti nenastartovat, a jen se tvari ze bezi. A automatickej reset? To muze myslet vazne leda totalni imbecil ... kdyz neco padne, tak to ma duvod. O paralleni start nikdo nestoji, v zadnym pripade. Nezrychluje to vubec nic, jen to zpusobuje prusery (a openrc to umi taky, ale je to zcela pricetne bydefault vypnuty).
Takze se nenajde absolutne vubec nic, jen blabolis.
-
Ondřej CaletkaZlatý podporovatel
Tohle se ale vůbec netýká systemd, ale udevu, což je sice jeho podprojekt, ale stále celkem oddělený. Ani by mě nepřekvapilo, kdyby ten slavný devuan používal udev také, stejně jako to dělá třeba Gentoo.
-
Ondřej CaletkaZlatý podporovatel
Moje Gentoo má udev a openrc, nemá systemd. Všechno funguje, včetně algoritmického pojmenovávání síťových karet (pokud bych ho nevypnul).
-
t (neregistrovaný)
Ja jedu na NTB Debian 9 s Mate a without-systemd. Uplne v pohode. S chuti tedy do toho a nejen na serverech.
-
Ondřej CaletkaZlatý podporovatel
Díky za potvrzení, že používáte přesně ten samý udev, co všichni ostatní, takže i pojmenování síťových karet v něm bude fungovat úplně stejně.
-
t (neregistrovaný)
Ano .. to sice ano, ale ostatni veci funguji stejne jako pred tim. Bohuzel praseni sitovych rozhrani se metodou without-systemd resit neda. Coz jsem ostatne nikde netvrdil ze mam zpet i eth0 eth1 atd. A rad bych mel a pochopitelne na to casem prijde take rada nalezt jednoduche reseni jak se dostat zpet do puvodniho stavu.
-
t (neregistrovaný)
Tak diky pane Caletka za nakop, cas prisel drive nez jsem cekal.. :) Uz mam zase vse tak jak drive. Pouzil jsem metodu s parametrem pro boot jadra zadavany do grubu, update-grub a reboot. Dokonce jako vedlejsi efekt jsem odhalil, ze na mistni siti nejaky lajdak pustil druhy DHCP server distribuujici konfiguraci s neexistujici GW, coz zpusobovalo zridka kdy nahodne necekane liznuti si spatne konfigurace z druheho DHCP, ale to je spise jen proto, ze jsem se vrtal podrobneji v sitovem nastaveni a tuhle zhovadilost objevil. Takze dve mouchy jednou ranou. Díky a jeste jednou diky :)
root@ntb:/# ifconfig -s
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 428 0 0 0 487 0 0 0 BMU
lo 65536 7423 0 0 0 7423 0 0 0 LRU
wlan0 1500 37800 0 0 0 27162 0 0 0 BMRUroot@ntb:/# cat /etc/*elease
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"root@ntb:/# ps ax q 1
PID TTY STAT TIME COMMAND
1 ? Ss 0:03 init [2] -
Palo M. (neregistrovaný)
V maji som upgradol z wheezy na stretch (jessie so preskocil, respektive to bol len nutny medzikrok v upgrade).
Na serveroch mam sysvinit-core + sysv-rc (teda boot po starom, uplne bez problemov).
Na desktop som dal sysvinit-core + openrc (na niektore demony som spravil vlastny openrc-konfigurak namiesto initskriptu), plus niektore baliky som nahradil tymi z https://angband.pl/deb/archive.html (veci ako policykit, udisks2, kvoli tomu aby KDE nebolo ozobracene o niektore funkcie). V sddm nefungovalo vypinanie a reboot (odmietli podporovat consolekit a pouzivaju len libpam-systemd), takze namiesto neho pouzivam lightdm.
Systemd je zablokovany cez apt-pinning (okrem balika libsystemd0), aby sa mi tam zakerne nenatlacil pri instalacii nejakeho uplne ineho balika. V pohode to pouzivam bez systemd (ten sddm je jedina vec na ktoru som narazil, ze bez systemd nefunguje, a to mi nechyba).
Na desktop som zvazoval Devuan, ale odradilo ma, ze su s vydanim pozadu aj za stable Debian-om, plus maju o dost slabsiu dokumentaciu balikov na webe.
-
libcha (neregistrovaný)
Tak jen pro ilustraci. Mám noťas a na něm poslední Ubuntu bez nějakých speciálních voleb.
Zabudovaná síťovka: enp0s31f6
Síťovka v dokovací stanici: enx....
Síťovka v USB: enx...
(takže v Ubuntu je MAC pojmenování zapnuté)
Wifina: wlp1s0Nehodnotím, jen uvedu, že si pořád nemůžu u těch enx... zapamatovat, která je která, protože člověk se spíš vyzná v eth0/1/2 než ve 12 hexa znacích. Druhá nevýhoda je, že názvy jsou dlouhé a nezapamatovatelné, takže kdykoli píšu nějaký příkaz v terminálu, musím si to vykopírovávat z `ip addr show`.
-
j (neregistrovaný)
To ze si to nepamatujes je jedna vec, ale horsi je, ze typicky mas rekneme stroj kterej ma dve sitovky. Rekneme ze tech stroju mas tisic, a rekneme ze dodrzujes nejaky schema na tema eth0 = ven, eth1 = dovnitr. Napises si na to script, kterym generujes nastaveni/firewall/...
Kdyz se ti v systemu objevujou tyhle sracky, tak si zadnej script nenapises, protoze to na kazdym jednom stroji bude jinak. A kdyz se na ten stroj pripojis, tak budes nejdriv 1/2 hodiny zkoumat, ktera kam vede, natoz kdyz jich mas vic.
Plus samozrjeme sposuta dalsich uchvancacujicich situaci typu ze chces shodit sit ven = ifdown eth0 .... neexistujici zarizeni ... takze opet budes nejdriv 1/2 hodiny zkoumat, kterou z tech zhuverilosti vlastne chces shodit, a ve finale odstrelis sam sebe.
-
dustin (neregistrovaný)
Přesně takhle to mám na strojích v heartbeat clusteru - jsou to různé modely serverů, ale pojmenování síťovek (přes mac) se stejným významem (out, drbd link 1, drbd link 2) mají shodné, aby fungovaly skripty na všech jednotně. Nedovedu si představit, že by mi to na různých strojích natvrdo přejmenoval a musel bych skripty upravovat pro každý odděleně....
-
y, (neregistrovaný)
Ja mam clanky pana Krcmare rad, ale tento mi prijde jako jeden z tech ne uplne povedenych. Muze to byt, ze nechtel clanek moc dlouhy, nebo ze holt nemam patricne znalosti... Cili to neni kritika clanku, spis seznam veci, kterym nerozumim.
Napr.
Proc predvidatelne nazvy? Ja jako clovek toho pri zasunuti karty do slotu moc nepredpovim, jake bude mit znaceni. Nebylo by terminologicky vhodnejsi "deterministicke"?
"Vyžaduje to zapisovatelný root, což je obecně v průběhu bootu problém." -- nerozumim duvodu, vzdyt konfiguraci by nemel byt problem ukladat pozdeji. Tim by se vyresil i problem s tim, ze zarizeni muze "vzniknout" pozdeji -- udev jako takove preci nema problem s hotplugem.
"utility v uživatelském prostoru závodí s jádrem v tom, kdo kdy přidělí rozhraní jméno" -- predpokladam, ze se zde hovori o udev a pripadne podobnych vecech. Neni mi jasne, proc se souperi, zda to jde vypnout, proc nemuze mit vice jmen pres symlinky v /sys?
"do hry vstoupí více instancí udev, přičemž device tree už je naplněný a každý paralelní udev pak uvidí jiný PCI tree" -- neni to tedy spise chyba udev? Proc by melo bezet/bezi vice instanci, navic kazda z nich s jinym device tree?
proc je pojmenovani podle lokace sbernice preferovano pred pojmenovanim dle MAC? Prijde mi, ze device tree je rozbity casteji nez se musi prekonfigurovat MAC -- navic ve spojeni s udev a hotplugem by snad nemel byt ani problem zareagovat udevem na zmenu MAC (i kdyz nevim, jestli se ta zmena verejne signalizuje). -
Ondřej CaletkaZlatý podporovatel
"Vyžaduje to zapisovatelný root, což je obecně v průběhu bootu problém." -- nerozumim duvodu, vzdyt konfiguraci by nemel byt problem ukladat pozdeji.
To si nějak nedokážu představit. Systém startuje, kořenový svazek je read-only. Spustí se udev, objeví novou síťovku a chce pro ni vytvořit záznam do
/etc/udev/rules.ds persistentním pojmenováním. Co by měl udělat? Uložit si nějakou poznámku do/deva pak se k ní později vrátit? Jak, když už v té době nepoběží? Co když se mezitím objeví další karta a bude jí chtít přidělit stejné persistentní pojmenování? Ten problém rozhodně žádné jednoduché řešení nemá a bezestavové algoritmické pojmenování je rozhodně lepší nápad. -
Ondřej CaletkaZlatý podporovatel
Udev daemon běží jen proto aby reagoval na události jádra. Když nastane nějaká událost, je obsloužena a démon se vrací k poslouchání událostí jádra.
Jistě, každý problém se pravděpodobně dá vyřešit přidáním další komplexity, otázka zní, jestli to za to stojí. Jestli má nějaký význam lpět na pojmenování eth0-n , když je možné celou komplexitu ušetřit přejmenováním na algoritmicky generovaná jména rozhraní.
-
Y, (neregistrovaný)
Myslel jsem to tak, že si system bootuje, zkonzultuje existující pravidla a případně vytvoří pravidla nová. V /etc/RC.d je pak služba, která se zavolá buďto po nabootovani (když je root v RW) nebo při vypínání (dokud je root v RW), která zapíše pravidla. Chápu, že bezstavova konfigurace je v mnoha případech vhodnější, aleargument s RW rootem mi přijde zvláštní.
A naprosto chápu, že ten problém je složitý a nedělám si iluze, že bych ho zde v diskusi jako první vyřešil, jen říkám, že argumentace v článku mi nepomáhá. -
DannyStříbrný podporovatel
Hned nemusi delat nic - proc by mel? Bohate staci, kdyz ten zapis/update probehne az v momente, kdy uz root r/w mas - a to snadno poznas (a to i na old-school sysvinit-based systemech, kde dependency-based boot v nejake forme fungoval uz dlouho pred tim, nez se objevil systemd). Mimoto udev beztak bezi porad, pripojovat novy HW muzes i za chodu systemu a je potreba nejaka reakce, takze argument "kdyz uz nebezi" moc validni sam o sobe neni...
-
j (neregistrovaný)
To je zajimavy jak to safra ty distribuce (zarucene gentoo ale i dalsi) sakra delaly, ze jim to bez problemu fugovalo.
Gentoo si totiz pri startu (dokud to teda jeste fungovalo) prave to pravidlo pojmenovani na sitovky do udev rules vyrobilo. A kdyz pribyla nova sitovka, pribyl novy radek s ethX+1. Pokud bylo treba nazvy prehazet, stacilo pravidla upravit. Sakra, asi si to meli nechat patentovat, to je vynalez na nobelovku nejmin.
-
Ondřej CaletkaZlatý podporovatel
Právě že to fungovalo jen většině, rozhodně ne všem. To je ostatně důvod, proč byl vyvinut nový systém.
-
Ondřej CaletkaZlatý podporovatel
Výše uvedený výpis je ze serveru, který svých 8 síťových portů řadí při každém bootu jinak.
-
Takového hardwaru jsem zažil... Periférie cestující po sběrnici podle toho, jestli byl proveden horký nebo studený start nebo restart. Nebo HW, který měnil pořadí zařízení na sběrnici podle toho, jestli byla zapnutá virtualizace nebo nebyla. Nebo po aktualizaci BIOSu a další. Ale nebylo to nic, čím by se nedalo lehce pracovat přes udev nebo ifrename a hlavně pojmenování co je teď v systemd takové případy stejně nijak neřeší, akorát přidělává problémy další.
-
DannyStříbrný podporovatel
Zadny system nebude fungovat vsem. Ten predchozi vetsine fungoval, par lidem ne... vysledkem je opet system, ktery opet funguje jen (jine) vetsine a nekterym naopak zpusobil problemy do te doby neresene. Prikladu, kdy prediktivni jmena nefunguji dvakrat spolehlive jsem zminil vyse uz dost.
-
jouda (neregistrovaný)
Pokud systém funguje většině a je dost flexibilní, aby si menšina mohla relativně snadno upravit jeho chování podle use case (*), je to přímo učebnicový příklad ne-problému, které má správné řešení nehrabat do toho vůbec, případně vylepšit ony možnosti customizace.
*) Už proto, že univerzální řešení neexistuje (důkaz sporem: U firewall appliance chci pojmenování tvaru fyzický slot+port bez ohledu na to, jestli v jiném slotu něco je strčené nebo ne, u virtuálu kde síťovka po sběrnici může cestovat, ale jejich pořadí zůstane stejné chci evidentně podle pořadí na sběrnici).
-
y, (neregistrovaný)
Ke svemu nazoru jste samozrejme opravnen. Ja bych jen podotknul, ze jsme na technickem serveru a v technicke terminologii ma slovo "deterministicky" peclive vymezeny vyznam tak, aby prave nebylo potreba ho prekladat jako "ocekavatelne" nebo "predvidatelne" a potom se hadat kdo ma co ocekavat nebo zda jde znaceni skutecne predvidat. Kdybych mel poskytnout vysvetleni nejakemu decku, tak bych mu rekl, ze z meho pohledu je nejblizsi slovo "nenahodne", coz vystihuje duvod, proc to zavedli -- aby odstranili problemy, kdy ruzne drivery najdou ruzna zarizeni v ruznem poradi a vyhnuli se pri pojmenovani vlivu nahody. Kazdopadne dalsi diskusi s Vami nehodlam vest, rikejte tomu jak chcete, ale az budete chtit, aby Vam v branzi lidi rozumeli, tak holt budete muset sahnout po terminologii. Prozatim tomu rikejte klidne "lehkost kreckova dechu".
-
Taky souhlasím s tím, že tento článek nemá obvyklou kvalitu Petra. Není mi např. jasné, proč v jedné podkapitole je "Podle fyzického umístění to nejde", když se nejedná o řešení v systemd špatně a v další podkapitole "Předvídatelné názvy", která je o řešení podle fyzického umístění, ale v systemd naopak vychvalována.
-
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....
-
anon (neregistrovaný)
po nabootovani napr po pridani/odebrani jine karty (treba grafika pro tensorflow) do jineho pcie slotu ta lennartovina prejmenuje sitovku jinak a stroj nenabootuje s funkcni siti
kdyby za lennartem nestal red hat tak se mu akorat vsichni smeji, takto muzou vsichni jen brecet
vypada to ze je v red hatu silna frakce ktera se z linuxu snazi udelat windows (za me neakceptovatelna regrese, podle lennarta je potreba windows dohnat).
-
Malé doplnění, v RHELu (CentOSu) 7.x je chyba v ovladači virtio, takže pojmenovává rozhraní ještě podle starého scénáře (eth0, eth1...). Je to bug který sice byl opraven ještě před vydáním 7.1, nicméně už to nemůžeme změnit updatem - to by totálně rozbilo stávající systémy. Fedora už je opravena dlouho.
Takže bacha, RHEL 7 při použití virtio síťového ovladače nové pojmenovávání ignoruje. Celkem úsměvný bug.
Díky za článek, diskusi raději číst ani nebudu... ;-)
-
Petr Neni (neregistrovaný)
Lukasi, cetl jsem Vas prispevek ohledne volnosti u senioru. Chci se zeptat jak probiha rozhodovani o tom jestli se nejake reseni hodi do kramu nebo ne? Mate nejakou interni prezentaci reseni a nejaky feedback od kolegu, nebo to navrhnete sefovi a ten dle sveho uvazeni schvali/zamitne dane reseni?
-
Pojem "hodit do krámu" jsem použil asi neuváženě, hnedka se tam trollové do toho navážejí. Spíš jde o to, jestli je to něco co by se hodilo zákazníkům Red Hatu. Tím nechci říct, že by manažer neschválil nic co by bylo dobré třeba jen pro komunitu (například máme 1,5 člověka kteří dělají jen pro komunitu našeho projektu). Ale když je tam synergie, tak proč ne. Budu konkrétní, dělám na projektu www.theforeman.org - systém pro správu serverů.
Příklad A: Auto-provisioning rules - nový server který se objeví na síti se nareportuje a díky novým pravidlům (to je ta featura) se může rovnou nastartovat provisioning. Je to výhodné pro ty, kteří mají hodně serverů a často "zareckovávají" servery. Tzn. často naši zákazníci, ale samožejmě všichni uživatelé. Manažerovi se ten nápad líbil moc, byl to týden práce na prototypu, pak asi měsíc na takovýto "dodělání" - odbugování, lepší UI, API, CLI, dokumentace, testování.
Příklad B: Telemetrie z aplikace. Největší deploymenty našeho softwaru mají 100 tisíc strojů (eBay/Paypal) a naši zákaznící mají také velké instance. Performance regressions se špatně měří když nemáš data, přidal jsem proto malý stack který umí interní data (časy controllerů, počítadla instancí atd) exportovat do Prometheuse a taky do Statsd/PCP. Navrhl jsem řešení tak, aby bylo výhodné pro upstream (tam hraje Prometheus prim) i pro downstream (Red Hat používá PCP). Takže benefit pro obě strany, manažeři měli snadné rozhodování.
Prezentace se v našem týmu dělá na komunitním demu, tam ukazují všichni členové komunity na čem dělají.Je jednou za tři týdny, pro příklad B (telemetrie) je záznam zde: https://www.youtube.com/watch?v=ujTwePoc4jw nic se neskrývá. Manažer spíše rozhoduje o tom, jestli danou věc dotáhnout (dokumentace, API/CLI, lepší UI atd).
Je potřeba si uvědomit, že více často nerozhodují manažeři ale komunita. Ta rozhodne co je dobré a co ne, já sám jsem napsal tucty RFC (email s návrhem řešení) které komunita odmítla, nebo se na tom prostě nezačlo dělat protože je to moc práce nebo není čas. To je život. Podobně funguje komunita Fedory, ta rozhodla jestli tam systemd bude nebo ne.
Na to o těch manažerech bych se neupínal, prostě jsem jen odpovídal trollovi, má to širší kontext.
-
anon (neregistrovaný)
A reakce komunity se pak take bere ze kdo nesouhlasi je troll?
Nedokazu si jinak vysvetlit, ze to proslo, kdyz systemd skoro vse jen zpusobuje problemy a proto nadavaji.
Vzdyt se podivej, jak se tady mezi sebou shodneme, ale tady v komentarich panuje vzacna shoda. Vsichni jsou trollove!
-
Já bych vás rád oslovil jménem, to byste ale museli vystoupit ze stínu anonymity. Ale beru, pokud jsem se někoho dotkl tak se omlouvám, tak nějak jsem už na to neustálé nadávání na cokoli kolem systemd alergický tak proto ta reakce. Nic není dokonalé a některé věci se mi také nelíbí, ale u mě převažují zkrátka výhody. Například konzistentní pojmenovávání mělo být udělané už dávno, bohužel se jakákoli změna týká všech a někomu se to musí nelíbit. Tak to prostě je.
-
t (neregistrovaný)
Nechci byt neslusny, ale asi by bylo vhodne se tu vasi alergii naucit ponekud zvladat. Kdo vi kolika potencialnim zakaznikum jste tu ukazal, jak reaguji zamestnanci RH alergicky na problemy, ktere rika clovek (a bohuzel nejsem sam, jak vidite nejen zde v diskuzi), ktery s vami vyvijienymi systemy musi pracovat. Nebavim se o managerech, kteri podepisi smlouvy a tvari se spokojene a vy jako zamestnanci RH mate pocit ze jste udelali kseft a dobro. Skutecni admini z toho mohou leckdy vykvest, ale jsou zase drzeni svym managerem, protoze smlouva je podepsana a finance zaslany.
Manager se systemd delat nebude. Na to ma admina. Kdyz admin rekne ze je to na dve veci, manager rekne, sorry, uz jsme to koupili a proinvestovali majlant. Pouzivaji to prece v Amazonu a kdo vi kde jeste tak prece to musi byt dobry ne? Kolikrat bych takove managery za to posadil a rekl, tak ukaz, jak dobry to je. A budes tu sedet treba do rana, dokud to neprimejes k cinnosti a stabilite.
Ono to nadavani ma podstatu v praktickych zkusenostech ostatnich se systemd. Nikoliv vasich zkusenostech, kdy vidite prevazujici vyhody, protoze to pouzivate zrejme v obastech ci konkretnich "use case", kde problemy nepocitujete. To ale zdaleka neobsahne problematicke pouziti v jinych pripadech u ostatnich. A ono to nadavani mnoha lidi neni jen tak z niceho nic. V pripade systemd je ta nastvanost docela viditelna a v rade veci podlozena i konkretnimi priklady.
Ohledne jmena ci prijmeni, povazuji to za osobni udaj, ktery zde nema co delat a ani s diskuzi kolem systemd ani s RedHatem ani s vami nijak nesouvisi. Pro ucely diskuze ci faktu kolem systemd naprosto postaci, kdyz me budete brat a oslovovat jako "t". Ze jsem clovek co ma fakticke zkusenosti se spravou a technickym servisem 800+ serveru fungujicich pro urcity konkretni ucel ve skolnich institucich bez problemu bez systemd (jak jsem zde psal) uz samo o sobe mnohem zajimavejsi, nez me obcanske jmeno.
-
Nálada v diskusi pod článkem o systemd na root.cz reprezentuje náladu v celé linuxové uživatelské bázi. Nevím proč bych se tím měl zabývat. Já navíc se systemd nemám nic společného, no snad kromě https://github.com/lzap/systemd-shortcuts ale to je jen wrapper který nikdo nepoužívá, ani já ne.
Open-source komunity často dělají příliš průzkumy "trhu", našemu projektu není jedno, co si uživatelé myslí. Děláme je každý rok, výsledky analyzujeme a zařizujeme se podle nich. Například jsme zaměnili mailing-listy za Discourse, já jsem byl největším odpůrcem této změny, nakonec jsme se shodli že je to pro dobro uživatelů a komunity. Takže jsem se přizpůsobil, nicméně doteď si myslím že list + HyperKitty by byl pohodlnější pro core vývojáře i občasné "kolemjdoucí".
Tak mně tady nevykládejte něco o ignorování uživatelů, díky.
-
Zdarec, jasně to jsem asi mohl uvést rovnou, z paměti jsem to nedal musel bych to googlit. Ale tak pro pořádek:
https://bugzilla.redhat.com/show_bug.cgi?id=1259015
Backportováno do RHELu 7.2 - https://access.redhat.com/errata/RHBA-2015:2092
-
snehuliak (neregistrovaný)
Mne trochu prekaza (ne)logika poradia slotu a portu. Podla mna by bolo lepsie keby bol najprv slot a za nim volitelny port. ens0p1 a nie enp1s0... Je to lepsie citatelnejsie, grepovatelnejsie aj skriptovatelnejsie... Zeby sme sa toho dockali v nepremenovanej buducnosti? ;)
-
Ondřej CaletkaZlatý podporovatel
Tím portem se nemyslí port na kartě, ale port na PCI sběrnici (nebo aspoň to tak chápu já). V každém případě, pokud má síťová karta dva porty, vystupují v linuxu jako
enp5s0f0aenp5s0f1, tedy přidá se ještě identifikátor funkce. -
Lol Phirae (neregistrovaný)
V každém případě, pokud má síťová karta dva porty, vystupují v linuxu jako enp5s0f0 a enp5s0f1, tedy přidá se ještě identifikátor funkce.
Takhle to zjevně taky nefunguje, viz v diskusi už zmiňované
enp0s10f0u virtuální síťovky (která žádných víc portů nemá), nebo jinou Lennartovou obětí zmíněnéenp0s31f6u integrované karty v notebooku. -
Ivan (neregistrovaný)
Jen pro ukazku jak to resi konkurence. Neprijde mi uplne stastny aby exitovalo jedno obecne reseny pro "normalni" HW a brak.
https://www.ibm.com/developerworks/aix/library/au-aix-decoding-location-codes/index.html
https://www.ibm.com/support/knowledgecenter/8247-21L/p8ecs/p8ecs_locations.htm#locations__physlocsmapping
https://www.ibm.com/support/knowledgecenter/en/POWER5/iphau_p5/locsqsf2.htmNeni nic jednodussiho nez kdyz vygenerovane jmeno (label) v OS odpovida primo nalepce, ktera je nalepena sezadu na bedne.
-
Andrej Babis (neregistrovaný)
Takze protoze nektery bez MAC zarizeni nesly jednoznacne identifikovat, tak to pokazili vsem a vsude.
Jeste jsem nevidel system, kde by to bylo predvidatelny a odvoditelny. Nektery to meni pri odpojeni a pripojeni kabelu. Nektery i pri rebootu.
Argumentace bezMAC zarizenimi je snad jedina uznatelna, ale hodne slaba. Ve skriptech staci prozkoumat log systemu a hned vite co je to zac. Pokud pouzivate sitove API, zeptate se toho API co je to zac.
Navrh neni spatny, ale jako vse v dnesnim Linuxu neni to proste dotazene resp. v tomto pripade uplne nahovno a ta situace se rok od roku horsi.
-
mc (neregistrovaný)
Mne rozhodilo to zavedení těch novot. Nyní mne to nevadí. Zařízení si pojmenuji dle MAC jak potřebuji v:
/etc/udev/rules.d/76-netnames.rules
Což dává smysl, jelikož když píši firewall pravidla, musím hned vidět co to síťové zařízení představuje (lan0, wan0, ...). Z názvů co generuje toto "předvídatelné" pojmenování to nevidím (nepíši firewall pravidla či definici sítě a routování pro síťovku v rozhraní X ve slotu Y..., ale třeba pro rozhraní wan0). Navíc předvídat to jméno snad neumí ani autor toho předvídajícího algoritmu.No a pokud tam vložím novou síťovku tak ji hned poznám díky tomu "geniálnímu" názvu a mohu ji pak vzápětí slušně pojmenovat. Takže to není zas tak špatné:-).
Pokud síťovku měním, mohu novou otestovat jinde a tím zjistím její MAC... nebo jak tu bylo zmíněno užiji live distribuci... Pravda neužívám systemd init, ale s ním to asi taky nebude problém řešit stejně.
-
mc (neregistrovaný)
OK. Vidím dva problémy, které přišly:
Dříve jsem jména nastavoval zde:
/etc/udev/rules.d/70-persistent-net.rules
a to s částečnou spoluprací s mechanizmem, který tam prvotně pravidla vytvořil a já je jen doladil. Nevím zda to dnes funguje - tuším ne. Nyní to dávám sem:
/etc/udev/rules.d/76-netnames.rules
a nic se mnou nespolupracuje - pravidlo musím celé vytvořit sám (většinou vycházím z toho co bylo dřív nagenerováno v 70-persistent-net.rules).Názvy enBFLMPSVZ a podobné trochu člověka rozhodí pokud je mnoho let zvyklý na ethX. Navíc pokud to přijde v okamžiku, kdy má plno jiných konfiguračních ladění a práce... Musí být trochu připraven - já naštěstí byl, když jsem se s tím prvně setkal. (Víc ho rozhodí to, co jsem zmiňoval předtím, že přestal fungovat mechanizmus, který vytvářel 70-persistent-net.rules.) Je také pravda, že jsem často dosud zůstával v některých případech u názvů ethX jen jsem třeba chtěl, aby wan byl eth0 a podobně a aby to tak bylo tak stačilo doladit 70-persistent-net.rules. Vlastní pojmenování jsem vždy stavěl na MAC adresách a neměl s tím nikdy problém. S problémem eth_rename (pokud jsem zůstal u ethX) jsem se nesetkal (respektive jednou, ale to jsem špatně sepsal pravidla).
-
Petr Neni (neregistrovaný)
Soudruzi z RH by ti rekli ze tve pouziti je marginalni use case a nikdo normalni nebude pouzivat nejake usb sitovky... ja bych rekl ze Lennart videl za zivot 10sitovek, mozna se docetl ze je rozdil mezi sitovkou na desce a v pci a dle toho to “vymyslel”. Napada me jenom jedno vulgarni oznaceni...
-
neregistrovany (neregistrovaný)
Ono prekvapivo tie cisla maju svoj vyznam:
$ ip a s ... 4: enp0s26u1u3: <BROADCAST,MULTICAST,UP,LOWER_UP> ... $ lspci ... 00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) ... $ lsusb ... Bus 001 Device 003: ID 04b3:4010 IBM Corp. ... $ lsusb -v -s 1:3 Bus 001 Device 003: ID 04b3:4010 IBM Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x04b3 IBM Corp. idProduct 0x4010 bcdDevice 2.15 iManufacturer 1 IBM iProduct 2 RNDIS/CDC ETHER iSerial 0 bNumConfigurations 2 ...
-
neregistrovany (neregistrovaný)
Lepsi format:
$ ip a s
...
4: enp0s26u1u3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
...
$ lspci
...
00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
...
$ lsusb
...
Bus 001 Device 003: ID 04b3:4010 IBM Corp.
...
$ lsusb -v -s 1:3
Bus 001 Device 003: ID 04b3:4010 IBM Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x04b3 IBM Corp.
idProduct 0x4010
bcdDevice 2.15
iManufacturer 1 IBM
iProduct 2 RNDIS/CDC ETHER
iSerial 0
bNumConfigurations 2
... -
ano, z tohoto pohledu jsou predvidatelne, nicmene z pohledu praxe jsou nepouzitelne ;)
tohle je predvidatelnejsi (protoze si to nastavim sam) a v praxi pouzitelnejsi (protoze vim co sem si nastavil sam)
cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x8086:0x15b8 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS="?*", ATTR{address}=="60:45:cb:a1:b1:c2", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="60:45:cb:a1:b1:c1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
ip a s | grep eth.: -A1
2: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 60:45:cb:a1:b1:c1 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 60:45:cb:a1:b1:c2 brd ff:ff:ff:ff:ff:ff -
neregistrovany (neregistrovaný)
Nieco taketo?
$ ls -l /dev/disk/by-path/
total 0
lrwxrwxrwx. 1 root root 9 sep 17 19:53 pci-0000:01:00.1-ata-1 -> ../../sda
lrwxrwxrwx. 1 root root 10 sep 17 19:53 pci-0000:01:00.1-ata-1-part1 -> ../../sda1
lrwxrwxrwx. 1 root root 9 sep 17 19:53 pci-0000:01:00.1-ata-2 -> ../../sdb
lrwxrwxrwx. 1 root root 10 sep 17 19:53 pci-0000:01:00.1-ata-2-part1 -> ../../sdb1
lrwxrwxrwx. 1 root root 13 sep 17 19:53 pci-0000:08:00.0-nvme-1 -> ../../nvme0n1
lrwxrwxrwx. 1 root root 15 sep 17 19:53 pci-0000:08:00.0-nvme-1-part1 -> ../../nvme0n1p1
lrwxrwxrwx. 1 root root 15 sep 17 19:53 pci-0000:08:00.0-nvme-1-part2 -> ../../nvme0n1p2
lrwxrwxrwx. 1 root root 15 sep 17 19:53 pci-0000:08:00.0-nvme-1-part3 -> ../../nvme0n1p3
lrwxrwxrwx. 1 root root 15 sep 17 19:53 pci-0000:08:00.0-nvme-1-part4 -> ../../nvme0n1p4
lrwxrwxrwx. 1 root root 15 sep 17 19:53 pci-0000:08:00.0-nvme-1-part5 -> ../../nvme0n1p5
lrwxrwxrwx. 1 root root 15 sep 17 19:53 pci-0000:08:00.0-nvme-1-part6 -> ../../nvme0n1p6 -
poiu (neregistrovaný)
<sarkasm>
Pokúsim sa zhrnúť vzorec, ktorý som vypozoroval v diskusii pre túto aj pre niektoré predošlé kauzy:-vymyslím riešenie na marginálny problém
-kritiku ignorujem
-riešenie presadím prostredníctvom silného subjektu
-riešenie sa ukáže katastrofou, vytvára väčšie problémy než bol pôvodný
-odmietam to vidieť alebo pripustiť
-kritiku naďalej ignorujem
-zodpovednosť za dôsledky prehadzujem ju na inýchNa prvý pohľad by sa mohlo zdať, že sa to podobá niektorým charakteristikám pojmu "dobroser" resp. "slniečkár".
Ale treba povedať, že sú tu aj niektoré významné rozdiely: napríklad zatiaľ neprebieha cenzúra, mediálny lynč, profesijná likvidácia a trestné stíhanie kritikov tej jedinej správnej myšlienky. To ma napĺňa optimizmom.
-
Seki (neregistrovaný)
Uz ma nebavilo nadavanie uzivatelov a tiež má nebavilo neustále vysvetľovať NIC naming. Začal som teda písať tool ktorý je tak trochu blast-from-the-past ale snáď niekomu pomôže k jeho vytúženým necoX NIC menám.
Bez záruky, ale mohlo by sa to objaviť do budúcna v RHELu. Ak by bol zaujem tak aj vo Fedore.
https://github.com/msekletar/prefixdevname/blob/master/README.md
-
Problém je v tom, že eth pojmenování není stabilní. Kernel prostě pojmenovává síťovky postupně jak se při bootu objevují. Takže dost často se po aktualizaci jádra eth jména popřeházejí. Takže pokud má člověk víc než jednu síťovku tak bych to nedělal.
A než se někdo ozve, že na centosu6 a starších se mu to nepřehazovalo, tak tam to bylo zajištěné jinak, udev pároval mac adresu a eth jméno a při změně kernelu je popřehazoval. Ale u více síťovek to nefungovalo spolehlivě.
