Dotaz: Přechod na Debian 10 a označení síťovek

[Dan]

Ahoj, mám malý server Debian 9 a chci přejít na 10. Mám obavy z označení síťovek (mám dvě, které jsou označeny stále postaru eth0 a eth1). Bude stačit, když ještě na devítce, před upgradem, přidám do zavaděče net.ifnames=0 biosdevname=0? Díky.

Odpovědi

[Andrej]

Uf. Tohle je neštěstí. Debian je technologie poplatná roku 1995. Tenkrát se muselo „přecházet“, jako když je postarší dáma na přechodu. Důvod byl jednoduše ten, že většina systémů byla většinu času offline, distribuovaná na disketách, bez možnosti stahovat průběžně aktualizace. V dnešní době, tedy ve 2. dekádě 21. století (a ono to tak bylo už i v 1. dekádě, jen si toho méně důvtipní uživatelé nevšimli), se nikam nepřechází. Nainstaluje se prostě distribuce, která žádné „verze“ nemá.

Nejdůležitější úvaha k zamyšlení: Proč by měla mít distribuce verzi, když každý jednotlivý balíček má taky verzi, nezávislou na ostatních balíčcích? Aha! To je ono! Distribuce nemá mít verzi. To je celé.

[Dan]

A odpověď na mou otázku by nebyla? :)

[k3dAR]

to je naprosto spatna uvaha, duvod proc ma distribuce verzi a prechazi se mezi nima po (napr.) 5letech, je ten ze po celou dobu sve zivotnosti ZARUCUJE ze se nemeni verze/jmena/sluzby/dm/de/cokoliv pod rukama, nemusi se pri/pred kazde aktualizaci studovat fora/changelog/readme aktualizovanejch balicku zda se nemenil format configu a/nebo jake problemy nastanou a zda jsou zname workaroundu nez se to v dalsi verzi doresi nebo nez se povysej jine zavisle balicky... to jsou vsechno problemy ktere prinasi neverzovane/rolovaci distribuce jako Arch Linux... samozrejme to ma i nejake vyhody ale ty jsou irelevantni pro nekoho kdo potrebuje dlouholetou stabilitu kterou nabizi prave a z principu jedine "verzovane" vydani distra jako Debian, Ubuntu, Fedora, (open)SUSE, CentOS, RHEL atd, atd...

[ewew]

Používaš túto distribúciu ?

[Jendа]

Tak by tady ten stejný dotaz byl ve znění „chci upgradovat z ArchLinuxu stavu z 9.7.2019 10 UTC na stav 9.7.2019 6 UTC a bojím se že se mi přejmenují síťovky“. Akorát u toho ArchLinuxu by si to nemohl naplánovat kdy se mu to hodí. Ale to už jsem ti včera vysvětloval.

[Jendа]

Pardon, to druhé samozřejmě mělo být 10.7.2019 6 UTC.

[Sten]

Pokud máš tenhle názor, tak můžeš používat Debian Sid, ten žádné verze nemá. Naštěstí většina výrobců operačních systémů (a to nejen linuxových) moc dobře ví, proč se aktualizace, které mění chování, dělají jen jednou za dlouhou dobu.

[trekker.dk]

Neštěstí jste vy. Jak velkou serverovnu s tímhle přístupem spravujete? Vůbec nějakou?

[j]

Zkus, ale je to takova loterie, on ti totiz nikdo neni schopen zarucit, jak se to bude v ramci toho konzistente (ne)predvidatelnyho chovani bude chovat. Je to tak cca 50:50, ze prijdes o sit, takze je dobry mit nejakou dalsi moznost, jak se k tomu stroji pripojit.

Ono ti to totiz muze i pri zachovani stavajicich nazvu ty sitovky prehodit, s cimz nic neudelas, protoze soudruh uberkokot poettering rozhod, ze navazat to na MAC je zlo (ta funcionalita, ktera naprosto vsem krome 0,00001% uzivatelu desitky let fungovala, uz v udev neni).

[k3dAR]

to udev pravidlo lze rucne bezproblemu pridat

[Dan]

Ja tam udev pravidlo mám už teď, tak pokud bude fungovat i nadále a a jestli ta "úprava" zavaděče bude něco platná, bude to ok :)

[j]

To sem zvedav, jak to udelas, protoze udelat z eth0 eth1 ... NEJDE ... coz samozrejme lidi co nevedi o cem zvanej nemuzou tusit, ze?

[k3dAR]

zase kecas hosku... JDE... viz: https://i.postimg.cc/3RcGHqdj/jecko-keca-deb10-rename-eth0-to-eth1-by-udev-rules.png

[GeorgeWH]

Nie nekeca, minimalne v CentOS 7 sme mali presne s tymto problem*, ze to (systemd) nevedelo premenovat eth0 na eth1 a naopak, pretoze ta blbost (systemd) chcela premenovat eth0 rovno na eth1, ale kedze eth1 uz existovalo, tak to spadlo. Vyriesili sme to premenovanim sietoviek na wanX/lanX. Predtym (Debian) to robil tak, ze eth0 najprv premenoval na docasny nazov, potom premenoval eth1 na eth0 a naslede uz premenovany eth0 prehodil na eth1.

A vseobecne sme s tym premenovavanim sietoviek mali vzdy problem (grub parametre, udev pravidla), stale sa to spravalo inac.

* tusim sa to ale vyskytovalo len na HP microserver gen8

[k3dAR]

mozna v CentOS, ale v Debian o kterej je tenhle dotaz je to jak sem psal (a jak sam pises)

[trekker.dk]

Už jsem narazil na to, že přejmenování síťovek na správná jména nefungovalo ani s pravidlem v udevu. Pro takové případy doporučuju balík ifrename

[j]

On totiz k3dAR, jako vzdy, zvani o vecech, o kterych nic nevi ... se starym udevem kdyz si tam mel pravidlo, se to pokusilo sitovky pojmenovat tak, jak si to mel v tech pravidlech, a nekdy to nekomu ani stema pravidlama nefungovalo (za jaky situace se da dohledat). Ale bylo to nepatrny mnoztvi uzivatelu.

Potom co udev schlamstli kokoti od systemd tuhle moznost uplne odstranili, takze pravidlo si napsat muzes, ale pokud se sitovka bude jmenovat ethX a ty ji budes chtit prejmenovat na ethY, ktera navic taky existuje, tak to nepude.

Prakticky vsechny distra na to vyslovene uz par let upozornujou nebo upozrnovala. A spousta lidi si na tom prave pri vsemoznych aktualizacih nabila hubu. A nabiji vesele dal, protoze pouzivat ty "predvidatelny" nazvy se nedaj ... ale i kdybys je tam nechal, tak spousta vsemoznych aplikaci a pripadne scriptu proste predpoklada, ze sit = ethX. A to pak prave vede k tomu, ze ani prejmenovani na netX, coz ti pude, ti nemusi byt nic platny, protoze proste neco co pouzivas vylozene ocekava eth.

[MP]

Ty proste vecne lzes.

A mimochodem, aplikace, co ceka sit na ethX, se muze hodit rovnou do /dev/null. Jak si to pak poradi s wifi?

[Josef Kufner]

V souboru /etc/udev/rules.d/70-persistent-net.rules jsou uloženy MAC adresy síťovek a jejich přiřazené názvy, takže po rebootu dostane stejná síťovka stejný název jako dříve. Nový způsob značení se projeví u nově přidaných síťovek.

[alkoholik]

A mas to vyzkousene?
5.1.5. Migrating from legacy network interface names:

... you should be aware that the mechanism of defining their names via /etc/udev/rules.d/70-persistent-net.rules is officially not supported by udev in buster (while it may still work in some cases) ...

[k3dAR]

predpokladam ze duvod je stejny jako byl pred casem v Ubuntu, tedy prohlaseni za problematicke/nepodporovane a odebrani auto skriptu co to pravidlo (re)generoval automaticky a prenechani na "inteligenci" sYsTeMd s generovanim panazvu... nicmene v Ubuntu 18.04 mam overene ze to funguje (s 1port, 4port GLAN a 1port, 2port 10Gig)

[Dan]

právě ... S přechodem z 8 na 9 jsem to ještě ošetřil, ale v 10 už to zřejmě nebude tak easy

[k3dAR]

stacit by to melo (ale neoveril sem), pro jistottu doufam ze ted pouzivas /etc/udev/rules.d/70-persistent-net.rules tak po upgrade zkontroluj ze tam zustane (kdyz ne vrat svuj ze zalohy) a zkontroluj ze v /etc/default/grub a ve vygenerovanem grub.cfg ty parametry mas...

[k3dAR]

zkusil sem ve virtualu (coz samozrejme nic 100% pro tebe neznamena), dal 3 lan (e1000, rtl8139, virtio), vytvoril /etc/udev/rules.d/70-persistent-net.rules a nem pro kazdou lan v jinem poradi nez jsou nastavene dal eth0, eth10, eth11, po restartu vse tak jak sem nastavil je...

ten server mas na dalku nebo na stole? pokud nadalku nema IPMI/KVM-over-IP?

[Dan]

super.. mám ho na dálku, ale i se k němu v nejhorším dostanu.. jen na dálku je to časově výhodnější (pokud se samozřejmě neodstřihnu:)

[k3dAR]

jen pred rebootem zkontroluj jak sem psal

[ewew]

Neviem ako to máš riešené. Ale mohol by si skúsiť naištalovať novú verziu do nejakého volného miesta.

[k3dAR]

to postrada vyznam ne? kdyz Deb10 nainstaluje bokem, bude tam muset stejne provest zmeny ktere v stavajicim Deb9 ma a pri rebootu pokud by mu to prehazelo sitovky (a pokud nema fyzickej pristup k serveru) by na tom byl stejne nebo hure :) leda by do Deb10 bokem dal do rc.local detekci zda eth0, eth1 atd jsou ty a ty mac a pokud ne tak auto reboot Grub do Deb9 )

[xxl]

net.ifnames=0 by mělo stačit k tomu, aby se pro jména síťových rozhraní použilo eth0, eth1,... Ale není tak úplně zaručeno, jestli to bude po upgradu na stejných síťovkách, jako to bylo před ním.

Pokud máš server před sebou, tak je to celkem jedno, akorát musíš vědět, která síťovka má kterou MAC adresu.

Pokud děláš upgrade stylem apr-get dist-upgrade, tak předpokládám, že se stávající jména rozhraní nezmění. Ale nedělal jsem to.

Pokud děláš vzdálený upgrade čistou instalací pomocí např. debootstrap na jinou partition, a nemáš přístup přes nějaké to iLO a nechceš si podříznout větev, tak můžeš použít systemd predictable interface names a nechat nazvat rozhraní podle MAC adres (https://www.freedesktop.org/software/systemd/man/systemd.link.html).

/etc/systemd/network/99-default.link

NamePolicy=mac
MACAddressPolicy=persistent

[Jendа]

U mě teda na vícero strojích došlo k přeznačení už s přechodem z 8 na 9, a ano, přidání těchto dvou parametrů tomu zamezilo.

[Dan]

Mezi 8 a 9 jsem nastavil jen udev pravidlo a to stačilo. Ty parametry v Grubu jsem zatím nepotřeboval. Dostanu se k tomu zřejmě až o víkendu, tak uvidíme, jak dopadnu :)

[Jendа]

Jo, už jsem si to zjistil, na tom stroji kde mi k přejmenování při upgrade 8→9 došlo to pravidlo nebylo (překvapilo mě to, protože jsem si myslel, že se generují automaticky).

[Peter Golis]

A to je problém si ten systém zreplikovať, a skúsiť upgrade s parametrami?