Prediktivní názvy síťovek, jo?

3.8.2019 01:03 | Přečteno: 2731× | Linux | poslední úprava: 5.8.2019 13:46

Tak jsem se v práci dostal k upgrade Debianu ze Stretche na Buster na HP ProLiant DL120 G6.
Pěkně jsem si podle 5.1.5. Migrating from legacy network interface names připravil nový název sítovky a čekalo mě nemilé překvapení.

$ udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
Load module index
Parsed configuration file /usr/lib/systemd/network/99-default.link
Created link configuration context.
Using default interface naming scheme 'v240'.
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enxb499XXXXXXXX
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_PATH=enp32s0
ID_NET_NAME_SLOT=ens2
Unload module index
Unloaded link configuration context.

Přepsal jsem v konfiguraci eth0 na ens2, jenže boot trval docela dlouho a síť nakonec nefungovala. Klika, že je u serveru vzdálená konzole.
V čem byl problém? Ve druhé síťovce:

Load module index
Parsed configuration file /usr/lib/systemd/network/99-default.link
Created link configuration context.
Using default interface naming scheme 'v240'.
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enxb499XXXXXXXX
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_PATH=enp34s0
ID_NET_NAME_SLOT=ens2
Unload module index
Unloaded link configuration context.

Systemd kupodivu neskousnul, že obě měly mít ID_NET_NAME_SLOT=ens2. Skončil jsem s jednou ens2 a jednou rename2.
Řešením je smazat slot z parametru NamePolicy v /usr/lib/systemd/network/99-default.link. Tak bacha na to!

PS: na bugreport jsem se vykašlal.        

Komentáře

[trekker.dk]

Persistentní názvy síťovek: ne. I Buster jde dokopat k tomu, aby se pojmenovávaly normálně.

Jinak tohle je opravdu povedená verze, někdo asi vymejšlel, jak zrychlit boot, takže initramfs se bez explicitního zadání neobtěžuje natáhnout ovladač na filesystém a stěžuje si, že na command-line jádra je nutné zadat root=. Na jiném to potřebovalo ovladač filesystému, MD raidu, řadiče a grafické karty - hádám, že ten zdržel boot natolik, aby jádro v mezičase stihlo nadetekovat zbytek hardware a initramfs byl schopen nabootovat. A není nic lepšího, než tohle řešit ve tři ráno, protože jiný stroj se stejným hardware při testování nic z toho nepotřeboval...

[R]

Tuto migraciu som robil uz pri upgrade na Debian 9. Najlepsie to funguje na serveroch DELL, tam aj stare servery (PE1950) maju v BIOSe nazvy onboard sietoviek, takze interfacy sa volaju eno1 a eno2 ("onboard 1" a "onboard 2"). Mame ale aj par HP, tak dufam, ze sa to pri upgrade na 10 neposerie...

[k3dAR]

cistejsim resenim je pridat kernel parametr: net.ifnames=0
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/#idontlikethishowdoidisablethis

[Sten]

V čem je to čistější než vypnout použití SLOT, takže systemd použije PATH? net.ifnames=0 hrozí tím, že pokud se ty síťovky nainicializují v opačném pořadí, tak prohodí jména.

[k3dAR]

nema to zprasene nazvy sitovek navic na kazdem stroji jine
s net.ifnames=0 s vice sitovkama se pouzije jednoduse /etc/udev/rules.d/70-persistent-net.rules jako se to delalo "do ted":

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:00", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:01", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

[Sten]

Hmm, tohle vypadá, že firmware hlásí, že obě síťovky jsou v hot-plug slotu #2. To by byla chyba firmware, hot-plug sloty mají mít unikátní čísla. Každopádně zajímavá chyba :)

[Odin]

Ani igelitkám ani síťovkám nemám potřebu dávat jména. Snad jedině trekovým batohům.

[Xerces]

Ha ha ha. Tak jsme se zasmáli a teď zpátky k vážné práci.

[Michal Kubeček]

Jeden z největších problémů s koncepcí "predictable names" je v tom, že na rozdíl od např. blokových zařízení nejde u síťových rozhraní udělat něco jako symlink. U blokových zařízení může udev nechat původní jméno od jádra jako skutečné jméno a k němu pak přidat několik aliasů - by-id, by-path, by-uuid, …, zatímco síťové rozhraní může mít jen jedno, takže je potřeba vybrat jeden způsob pojmenování.

Naštěstí to vypadá, že by tohle omezení v dohledné době mohlo padnout, takže by časem udev mohl nechávat jména rozhraní na pokoji a vytvářet aliasy podle různých schémat, jako to funguje u blokových zařízení.

[trekker.dk]

Jedna věc je, že to (možná) půjde. Druhá věc je, jestli systemd/udev bude ochoten používat něco jiného než jméno, které nám bylo sesláno svatým lennártem.

[Michal Kubeček]

IMHO je poměrně slušná šance že to půjde, koneckonců to byli právě lidé okolo systemd/udev, kdo přišel s tím, že se zařízení nebudou přejmenovávat, ale pouze vytvářet symlinky. Takže pokud bude možné používat stejný model i pro síťová rozhraní, mělo by jim to vyhovovat. Navíc vývojáři systemd nemívají zábrany nechat systemd natvrdo záviset na nějaké poměrně nové featuře jádra. Třeba závislost na kdbus plánovali ještě dřív, než se kdbus dostal do jádra (což je o to pikantnější, že se tam nakonec nedostal).

Mimochodem, ne všechno zlo světa má na svědomí Lennart Poettering, pachatelem "predictable names" je Kay Sievers.

[Heron]

A jsou ty názvy opravdu prediktivní? V manu se píše jen stable. Navíc ani s tím to nebude moc slavné:

Newer versions of udev take more of these attributes into account, improving (and thus possibly changing) the names and addresses used for the same devices.

Fakt si na základě toho manu někdo troufne uhodnout, jaké jméno bude mít další přidaná síťovka? Dřív to šlo, pokud si člověk udržoval udev rules na základě MAC, mohl si jméno pro novou síťovku (pokud věděl její mac) zapsat jako další pravidlo a po přidání tohle jméno skutečně dostala. Dneska lze akorát tak strčit kartu do PC a potom najít jejich jméno a doufat, že už se nikdy nezmění.

Jinak, fyzické stroje s jednou integrovanou síťovkou. Odhadl by někdo jejich jména?:

enp3s0

enp2s0

Kdyby nějakou náhodou ta síťovka byla na PCI bus 0 (proč je zrovna v Intel NUC na trojce ví asi jen intel), tak se tam to p nepíše a bylo by to ens0. Kdyby náhodou firmware oznámil index, tak by se jmenovaly eno0. Nic prediktivního na tom není. Otázkou je, zda je to vůbec stabilní napříč verzemi udev (tj, pokud se nová verze udev naučí číst firmware těchto strojů, jestli se to nepřejmenuje na eno0).

Dřív, pokud bylo potřeba přehodit kartu ze slotu do slotu (nebo popřeházet jejich pořadí), přiřazené jméno zůstalo stejné (na základě mac). Dnes, kdyby tohle někdo udělal, tak si může přepsat všechny konfiguráky.

[trekker.dk]

Vy tomu zjevně moc nerozumíte. Pravidla na základě MAC adres jsou špatná, protože ten systém můžete přestěhovat do jiného hardware a ono vám to nebude fungovat. Proto bylo potřeba to zrušit a zavést tenhle systém předvídatelných jmen, které jsou v každém hardware stejné™ (some restrictions apply)

Už nějakou dobu říkám, že by každý měl být donucen aspoň dva roky používat svůj výtvor a pro vývojáře to platí dvojnásob. Přejmenovávat síťovky na názvy typu enp2s3b1flpzv9 by je hodně rychle přešlo, kdyby to párkrát museli vypisovat do konzole na serveru, který nechce bootovat a plánovaná odstávka se tak pomalu ale jistě mění v neplánovaný výpadek.

[Heron]

Proto bylo potřeba to zrušit a zavést tenhle systém předvídatelných jmen, které jsou v každém hardware stejné™ (some restrictions apply)

Chápu, že ten odstavec je ironie, ale tohle u těchto jmen neplatí už tuplem. Nenašel jsem doma dvě pecka, kde by byly stejné a očekávané názvy síťovek. Integrované síťovky se vesele liší deska od desky, síťovky v PCIE mají různá jména. Očekávám, že ty sloty nebudou očíslované ani podle fyzického pořadí na desce, takže při přehození to dostane opět nepredikovatelný název. Přenositelnost OS moc nehrozí. Kdežto u starého systému stačilo přepsat udev rules tak, aby jména síťovek odpovídala jejich použití a nic jiného (tj nastavení sítě, iptables, bridge apod.) se už dál měnit nemuselo. V okamžiku, kdy se mi z enp3s0 stane eno0, tak to musím přepsat.

Btw proč teda nikdo nepřišel s možností si nastavit kompletně vlastní název síťovky? Vnitřně ať to má path dle fyzického zapojení, ale proč tomu nemůžu dát alias eth-wan apod.?

Mimochodem ve FreeBSD (kde se by default síťovky pojmenovávají podle driveru - em0 intel, re0 realtek apod), lze udělat:

It is also possible to rename an interface by doing:

ifconfig_ed0_name="net0"

přímo v rc.confu

Už nějakou dobu říkám, že by každý měl být donucen aspoň dva roky používat svůj výtvor a pro vývojáře to platí dvojnásob. Přejmenovávat síťovky na názvy typu enp2s3b1flpzv9 by je hodně rychle přešlo, kdyby to párkrát museli vypisovat do konzole na serveru, který nechce bootovat a plánovaná odstávka se tak pomalu ale jistě mění v neplánovaný výpadek.

Asi tak nějak.

[alkoholik]

Ono je to dobre spis pro servery. Jeden chcipne, tak z nej prehazu disky do jineho serveru stejneho typu, zapojim kabely do stejnych konektoru a jedu dal.
Jenze se mi uz stalo, ze se po upgradu BIOSu zacaly sitovky jmenovat jinak.

[Heron]

A jak často přehazujete disky ze serveru do serveru? Za svou 14 letou praxi jsem se s tím ještě nesetkal, ve skutečnosti je to právě storage, co obvykle odejde jako první (a tím myslím raid karty a jejich baterky apod., disky se vyměňují). A ve chvíli, kdy začnou odcházet jiné komponenty (druhé na ráně jsou zdroje, ale ty lze taky hotswapovat), tak je nejvyšší čas na migraci na nové železo. Nevím o žádné situaci, kdy by server odešel tak, že jediné zdravé komponenty zůstanou disky s nepoškozenými daty a je to tak urgentní, že ani přepis udev pravidel na nové mac nelze akceptovat (potom je ovšem s podivem, proč ten server nemá repliku).

Já pro tohle nevidím use case.

Samozřejmě, stabilní pojmenování iface je dobrá věc a chápu, že nevyhovují pojmenování jen na bázi mac, ale v tom případě nechápu, proč není možné (jako například v tom FreeBSD) si síťovky pojmenovat podle své koncepce. Vyhovovalo by to oběma stranám. Ti, co chtějí přehazovat disky mezi HW by dostali stabilní pojmenování a ti, co si nechtějí přepisovat všechny skripty při změně jména by si jen přiřadili správným iface svoje pojmenování.

[sigma]

Záleží dost na prostředí. U klasických serverů může být ten use-case minoritní, ale pro některé typy služeb s unifikovaným HW ve větším počtu ks se může hodit.

Velmi dobrá věc je to ale pro embedded a industrial nasazení. Tam je naopak zcela běžné, že ve skladu je od každého typu HW náhradní kus, a výměnu provádí technik, který o nějakém Linuxu uvnitř nic neví. Přehodit CFast kartu do nového PC zvládne, ale tím to tak končí. MAC adresy použít nelze, a na pořadí pojmenování se na novějším HW už skutečně nedalo spoléhat. Tady se ten nový přístup hodí, ale nefunguje to úplně dobře, protože výrobci se zatím moc nenaučili přes firmware exportovat názvy/sloty. Pak se stane, že s přidáním nové karty do slotu se přečíslují všechny ostatní - to už ale dělá někdo, kdo tomu rozumí. A takovýto typ použití je u Linuxu dneska velmi častý, a značná část funkcionalit v systemd je tímto motivovaná a řeší ty problémy velmi dobře.

[trekker.dk]

značná část funkcionalit v systemd je tímto motivovaná a řeší ty problémy velmi dobře

Problém je v tom, že to přidělává problémy tam, kde žádné nebyly

[sigma]

Přesto se systemd většina distribucí rozhodla adoptovat. A zrovna názvy síťových rozhraní lze do starého režimu snadno vrátit přes boot parametr, některé distribuce to tak mají, jinde si to správce snadno nastaví. Že je to ve výchozím stavu po novu se snad dá pochopit, a pomáhá to vytvářet tlak na výrobce HW, aby dali dohromady reportování správných údajů přes EFI. Pokud by fungovalo správně onboard / slot -based pojmenování, nevidím v novém přístupu problém. Samozřejmě pokud by byla možnost vícenásobného pojmenování (symlinky, aliasy) jako u disků, bylo by to ještě lepší.

[trekker.dk]

Přesto se systemd většina distribucí rozhodla adoptovat.

Ano, přesto se vývojáři distribucí rozhodli nové schéma pojmenování síťovek použít. Proto říkám, že by to teď měli za trest několik let používat. A tím nemyslím na svém pracovním laptopu, ale jako lidi odpovědní za to, že běží nějaká služba.

Pokud by fungovalo správně onboard / slot -based pojmenování, nevidím v novém přístupu problém.

Tak si znovu přečtěte #13 . Problém nového přístupu je, že rozbíjí starý přístup a nepřináší adekvátní náhradu, přičemž cenu za tuhle změnu pak nesou uživatelé. A brát si uživatele za rukojmí, aby se vytvářel tlak na výrobce HW, to je taky super přístup...

[sigma]

Problém nového přístupu je, že rozbíjí starý přístup

Starý přástup je možné jednoduše zapnout přes "net.ifnames=0" boot parametr. Ta "stará" udev pravidla by pak myslím také měla fungovat.

a nepřináší adekvátní náhradu

Toto: https://www.freedesktop.org/software/systemd/man/systemd.link.html mi přijde jako více než adekvátní náhrada.

[j]

A co ty a dalsi nechapes na tom, ze to NEFUNGUJE!? Protoze v udevu proste neni ta funcionalita (soudruh vrchni kokot lennart ji nechal odstranit), ktera umoznovala sitovky prejmenovat. Takze sice muzes mit ethX, ale nemuzes dat eth0 na eth1 a naopak.

[Michal Kubeček]

Funkcionalita na přejmenování síťového rozhraní tam pořád je, jinak by nemohly fungovat ani "predictable names". Odstraněn (z upstreamu) byl pouze pomocný script, který umožňoval přejmenování na jméno, které už mezitím "obsadilo" jiné zařízení (a tedy např. "prohodit" dvě jména). A možná i "persistent name generator" (nevím jistě, my máme v distribuci dál oboje).

[trekker.dk]

Ano, to je možné, ale nic to nemění na tom, že správný přístup je nerozbíjet fungující věci. Ta "adekvátní náhrada", kterou odkazujete, je další možnost, jak něco přejmenovat ručně. Já mluvil o tom, co je nyní výchozí - to není adekvátní, protože to neplní deklarovaný účel.

[trekker.dk]

A jak často přehazujete disky ze serveru do serveru?

Docela často, buď se ten server chová divně, nebo zákazník chce víc výkonu, nebo tak něco. Problém je v tom, že takový přesun často není do stejného hardware a persistentní názvy jsou... no, to už je popsáno v #13

Takže tak jako tak se musí něco udělat, jenže od doby "stabilních" jmen to něco nefunguje spolehlivě.

[j]

Ono to je jeste radostnejsi, staci kdyz zmenis konfiguraci, nemusis na HW jako takovej vubec sahat. Napriklad zmenis rychlost sitovky a voiala, ona se ti i prejmenuje ...

[michich]

proč teda nikdo nepřišel s možností si nastavit kompletně vlastní název síťovky

Tu možnost přece máš. Můžeš mít vlastní udev pravidla, kterými zařízením přiřadíš libovolná jména (ovšem vyhni se jmennému prostoru ethX kvůli možnému souběhu s objevením nových rozhraní kernelem). Nebo můžeš jména přiřazovat pomocí systemd.link(5).

[Heron]

Aha. A jak dlouho to tam je (myslím možnost změnit jméno v .link)? V changelogu jsem příliš nenašel a na netu o tom evidentně mnoho lidí taky neví. Zdá se, že to funguje (sd-241).

[michich]

CHANGES WITH 209:
[...]
        * udev gained a new scheme to configure link-level attributes
          from files in /etc/systemd/network/*.link. These files can
          match against MAC address, device path, driver name and type,
          and will apply attributes like the naming policy, link speed,
          MTU, duplex settings, Wake-on-LAN settings, MAC address, MAC
          address assignment policy (randomized, ...).
[...]
        — Berlin, 2014-02-20

[Heron]

Ok. Někdy si říkám, že tyhle věci by chtěly lepší a rozumnější propagaci. V rámci této diskuse (kde jsem vlastně ani neřešil svůj problém, ale jen ze zájmu) jsem prošel několik diskusí na netu a nikdo se o tom nikde nezmiňuje. Všude jsou jen více či méně prasácké řešení, jak udržet starý udev apod. Bylo mi divné, že to má i FreeBSD v elegantní formě a linux nic. A ono je to už 5 let a nikdo to neví.

[j]

Jestli ono to nebude tim, ze to funguje stejne dobre jako zbytek systemd ...

[Heron]

No moje zkušenosti jsou přesně opačné. Cokoliv, co jsem nastavil "the systemd way" (po té, co jsem si to musel sám najít, vymyslet a otestovat) a vyházel jsem všechny kostlivce z distra, tak to funguje. Potom se do toho vkládají různé defaulty, několikrát se mi stalo, že v changelogu byla oznámena změna, ale v distru ponechali starý default (třeba ono KillUserProcesses=yes). A úplně nakonec si k tomu napíšu sám sobě článek. Ale stále mám nálepku systemd hatera.

Takže musíte dělat práci za systemd evangelisty, za distro a ještě za it novináře

[Jendа]

Jinak, fyzické stroje s jednou integrovanou síťovkou. Odhadl by někdo jejich jména?

Já teď zažil následující: stroj, integrované síťovky enp5s0 a enp6s0 (ok, whatever). Přidal jsem do PCIe kartu se dvěma SFP sloty. Ty se pojmenovaly ens4f0 a ens4f1. A ty onboard síťovky se tím přejmenovaly na enp7s0 a enp8s0. WTF!!

[j]

To urcite kecas, to totiz neni vubec mozny, protoze lennart prece vi vsechno nejlip, a jeho uzasne frikulinsky pojmenovani sitovek funguje naprosto perfektne.

Apropos, kazdy aspon trochu svepravny distro pred systemd zapsalo to systemovy pojmenovani sitovek prave do pravidel udevu, pekne podle MAC, takze kdyz pribyla nova, tak tem puvodnim zustaly nazvy stejny.

Jinak bych to videl tak (a neni to jedinej HW kterej se tak chova) ze kdyz v tom slotu nic neni, tak se chova jako by v systemu vubec nebyl, a kdyz v nem neco je, tak ten integrovanej odsune az za sebe.

[Michal Kubeček]

Trochu nepříjemné na tom persistent modelu bylo to, že když člověk vyměnil síťovou kartu v počítači s jednou, tak ta nová dostala nové jméno. Ale to je věc, která se nestane "sama od sebe" (aspoň u skutečného hardware), takže je na to admin připravený a pak ten soubor prostě odedituje. U "predictable" modelu se může stát (a děje), že se jméno změní bez toho, aby admin sahal na hardware.

Trochu horší bylo, že existují virtualizační prostředí, kde stejné rozhraní stejného virtuálu dostane při každém bootu jinou MAC adresu. Setkal jsem se s tím kdysi u Hyper-V, ale i tam to naštěstí šlo vypnout. Potom na to IIRC nadávali ti, kdo často migrovali VM mezi hosty.

[citanus]

Trochu nepříjemné na tom persistent modelu bylo to, že když člověk vyměnil síťovou kartu v počítači s jednou, tak ta nová dostala nové jméno. Ale to je věc, která se nestane "sama od sebe" (aspoň u skutečného hardware), takže je na to admin připravený a pak ten soubor prostě odedituje.

tohle se hrozne hodi, kdyz neco v serveru umre.

[Michal Kubeček]

Oproti tomu, že je potřeba, aby někdo přišel a vyměnil fyzicky tu kartu, je editace jednoho souboru prkotina.

[Michal Kubeček]

Mimochodem, systemd/udev už si usurpuje právo rozhodovat nejen o jménech síťových zařízení, ale i o MAC adresách. :-(

[trekker.dk]

Takováhle zjištění - zejména když je to po dvou+ hodinách práce a hledání, co se tam kde k**va dop***le děje - mě vždycky vedou k tomu přemýšlet o změně oboru a o tom nechat se radši zaměstnat v pro zdraví bezpečnější továrně na třaskaviny.

[V.]

Jo

[michich]

MACAddressPolicy jde přece vypnout, ať už globálně nebo třeba jen pro bridge. Jako default dává nové chování (persistent) pro bridge smysl. Ano, neočekávána změna chování byla samozřejmě problém. Ta změna byla dokumentovaná v NEWS, ale zřejmě ne dost jasně (hint o bridge tam Yu přidal až dodatečně po objevení té SUSE BZ). Když používám rolling distro, tak mě podobné problémy nesmí šokovat. Zbyszek byl v reakci na oznámení problému vstřícný. Uznal, že ta změna měla být představena pod novou verzí schématu a dodatečně ji zavedl. Tak nepřeháněj, že ti systemd usurpuje práva.

[Michal Kubeček]

Jako default dává nové chování (persistent) pro bridge smysl.

Za prvé: jak komu. Za druhé: za starých dobrých časů (TM) bývalo zvykem, že při zavedení podobné volby se jako default použila ta hodnota, která se chovala stejně jako dosud (nebo aspoň co nejblíže dosavadnímu chování). Ale to holt bylo před systemd…

[j]

Vazne by me zajimal aspon jedinej clovek, kterej se prihlasi k tomu, ze takovy chovani dava jakejkoli smysl. Protoze to naopak smysl nedava vubec zadnej pro 99% pouziti, specielne, kdyz se ta mac nahodne meni.

Jednoduse systemd je velesracka a sytemy s tim odmitam administrovat - prave v zajmu zachovani vlastniho zdravi.

[Käyttäjä 11133]

To ti ale pomalu ubyva (linuxovych) systemu k administraci s tim jak se systemd siri jako mor, ne? :D

[michich]

Nemění se náhodně.