Kopírované servery, bondy, bridge a upgrade Debianu

6.9.2021 12:02 | Přečteno: 5011× | Linux |

Při upgrade serverů jsem šlápnul na další systemd minu.

Jako správně líný sysadmin jsem si dřív šetřil čas a místo instalace nových serverů jsem je kopíroval.

Prostě jsem přes USB redukci připojil disk z dalšího serveru, který byl na řadě, k čerstvě nainstalovanému, nahodil shell z initrd, spáchal partition tabulku, filesystémy, swap a tarem na něj poslal OS. Pak jsem vzal tu kopii, upravil /etc/fstab, /etc/hosts a /etc/network/interfaces, vrazil disk do správného chasis, nabootoval a frčel.

Bylo nebylo a vyšel nový stable Debian.
Takže přišlo klasické kombo - úprava sources listu, apt update, apt upgrade, apt full-upgrade, apt autoremove, reboot, aptitude remove '~o', apt clean.
Upgrade prvního serveru byl naprosto v pohodě, ale po rebootu druhého začala brutálně zlobit síť.

V čem byl problém?
V generování MAC adres pro bondy a bridge. Kdesi NEWS a Changelogu jsou schované lahůdky jako

bridge-utils (1.7-1) unstable; urgency=medium

  Linux kernel has changed bridge MAC address selection.

  In older Linux kernels the MAC of the bridge was the lower mac of the
  devices attached to it, this is no longer the case now at Bullseye. The
  kernel now makes up a completely new MAC address.

kde makes up znamená vygenerování podle názvu interfacu a obsahu /etc/machine-id.

Takže jestli jste někdy zkopírovali server s Debianem Buster a starším, používáte bondy nebo bridge a máte originál i kopii na stejné síti, vřele doporučuji před upgradem pustit ještě:
rm -f /etc/machine-id /var/lib/dbus/machine-id
dbus-uuidgen --ensure=/etc/machine-id
sudo dbus-uuidgen --ensure

       

Komentáře

[Michal Kubeček]

Linux kernel has changed bridge MAC address selection.

Nevím o tom, že by jádro v tomto ohledu něco změnilo. Spíš půjde o systemd / udev, tam se na nějakou zpětnou kompatibilitu nehraje.

[alkoholik]

Ja vim. Proto pisu, ze to je systemd mina.

[Michal Kubeček]

Ten komentář, na který jsem dával link, obsahuje i návod, jak obnovit původní chování.

[alkoholik]

Tim smerem vetsinou nejdu. Jenom by pribyvalo veci, ktere se musi udelat na nove instalovanych serverech.

[Michal Kubeček]

…a bridge-utils jsou už taky nějaký pátek obsolete. :-)

[alkoholik]

Changelog od bridge-utils jsem tam hodil, protoze to je jedno ze dvou mist, kde se o tom vubec nekdo zminuje.

[trekker.dk]

Po zkušenostech s ifconfig byste měl vědět, že to nikoho nezajímá

Btw.:

dpkg -s lxc
...
Depends: ... bridge-utils

I když to někoho zajímalo a chtěl to odinstalovat, jsou programy, co bez toho nedokážou žít. Ostatně Debian ještě pár let zpátky bez toho ifconfig nedokázal nakonfigurovat síť.

[Mayhem]

Ifconfig je nahodou super a pro zacatecniky daleko intuitivnejsi. Chapu, ze je to vykopavka, ale pro vetsinu jednoduchych konfiguraci je dostatecny.

[Michal Kubeček]

Intuitivnější je pro ty, kdo jsou na něj zvyklí a odmítají se naučit cokoli jiného.

[R]

Ked chcem nieco rychlo urobit, tak napisem "ifconfig eth0 up" a nebudem onanovat nad "ip link eth0 up", ci "ip link dev eth0 up" alebo "ip link set dev eth0 up" alebo ako to vlastne ma byt...

[Michal Kubeček]

Onanie je nepovinná, příkaz funguje i bez ní.

[Jendа]

ip l s eth0 up

[Mayhem]

ip l s... velmi intuitivni... ifconfig eth0 up je jednoduche a zapamatovatelne. A ruku na srdce, na vetsinou domacich konfiguraci ten ifconfig staci.

[ehmmm]

Laicky dotaz: Pouzivam "ifup eth0", delam neco spatne?

[Josef Kufner]

Ne. To je úplně něco jiného než ifconfig.

[Jendа]

To je distribuční záležitost, která dělá kompletní konfiguraci typicky podle /etc/network/interfaces (možná to má i jiné backendy).

[🇨🇽]

hlavněže to jako dobře dopadlo :O :D :D ;D

[trekker.dk]

Bývávalo, že bridge měl MAC adresu podle interface, které mělo nejnižší MAC adresu. Takže se měnila a dělalo to bordel. Od té doby ze zvyku MAC adresu nastavuju ručně a je klid. Teda... MAC adresu nastavuju ručně, do grub.cfg dávám net.ifnames=0 a napsal jsem si vlastní variantu init skriptu pro ifrename a je klid. Furt míň práce než pokoušet se při každou práci se síťovkou vypisovat enp97s0f1 místo eth0

(O tom, že zrovna tady v tomhle případě má síťovka dvě takzvaně persistentní pojmenování, ani nemá cenu mluvit.)

[Peter Golis]

enp97s0f1

Takú dlhú zbernicu by som rád videl. Čo to je za hardware?

[kono]

Mozno by stacilo vytvotit hodnotu enp97s0f1 v premennej prostredia eth0, a dalej narabat s nou.

[Michal Kubeček]

S dostatečně novým jádrem (upstream od verze 5.5) lze rozhraní přiřadit "alternative names" (altnames), která lze použít místo standardního jména. Novější verze udev pak umějí nechat původní jméno od jádra a přidat "predictable" jako altname:

lion:~ # ip -d link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether a0:36:9f:0a:81:b0 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 9216 addrgenmode eui64 numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535 parentbus pci parentdev 0000:04:00.0 
    altname enp4s0f0
lion:~ # ip -d link show dev enp4s0f0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether a0:36:9f:0a:81:b0 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 9216 addrgenmode eui64 numtxqueues 8 numrxqueues 8 gso_max_size 65536 gso_max_segs 65535 parentbus pci parentdev 0000:04:00.0 
    altname enp4s0f0

(Příklad z openSUSE Leap 15.3.) Pořád to ale bohužel vypadá, že udev použije jen jedno jmenné schéma, ne rozdíl od blokových zařízení, kde ke stejnému zařízení existuje víc /dev/disk/by-*/ symlinků a lze tak použít kterýkoli (a zároveň původní jméno od jádra).

[trekker.dk]

S dostatečně novým jádrem (upstream od verze 5.5) lze rozhraní přiřadit "alternative names" (altnames)

Takového s.aní jen kvůli tomu, že jednoho blbečka včas nevyhodili ze dveří...

[Michal Kubeček]

Tohle nebyla jediná motivace pro altnames (ale byl to argument, díky němuž se podařilo prosadit, aby jeden interface mohl mít víc altnames. Mimochodem, altname má limit na délku 127 místo 15, což se taky občas může hodit (s "predictable" jmény to občas dělalo problémy).

[Jendа]

Pak jsem vzal tu kopii, upravil /etc/fstab, /etc/hosts a /etc/network/interfaces, vrazil disk do správného chasis, nabootoval a frčel.

Doufám, že sshd host klíče jsi vypustil pouze zde kvůli stručnosti.

A jinak díky za informaci. Já ještě přidám, že poslední dobou nějak moc často začalo být potřeba apt-get --allow-releaseinfo-change update. Nepochopil jsem co to dělá, resp. proč to jako je potřeba když všude používám kódová jména a ne "stable".

[Heron]

Ono je těch věcí tolik, že je skoro lepší udělat čistou instalaci. A tu postupně zjednodušovat, až to bude ručně o půlnoci za pět minut hotové. A nebo si k tomu napsat něco jako ansible playbook.

Jinak bych přihodil třeba ještě změnu názvu vg, pokud se používá. Někteří klonují celé disky, takže potom je ještě navíc identické i UUID FS. Různé db mají uuid svého node.

[xkucf03]

Ono je těch věcí tolik, že je skoro lepší udělat čistou instalaci.

Kdysi jsem tu psal: Kontrolní seznam pro nový server

Vzhledem k tomu, že málokteré stroje mám stejné a často experimentuji s různými distribucemi nebo verzemi nebo zkouším jinou konfiguraci (tabulka disků, RAID, šifrování, LVM, souborové systémy atd.), tak většinou dělám klasickou instalaci. Zase tolik času to nezabere.

[R]

Este chyba konfiguracia GRUBu. V debconf (/var/cache/debconf/config.dat) je ulozena cesta k disku, kam sa instaloval GRUB. Pri upgrade sa znovu nainstaluje prave tam. Ak zariadenie neexistuje, tak moze nasledujuci restart dopadnut dost zle.

[Jendа]

Mně se to občas ptá kam GRUB nainstalovat, tak bych čekal, že když zařízení nenajde, tak se zeptá.

[Aleš Kapica]

Grub je tupý. Ptá se postinstalační skript při instalaci. Ale když máš systém třeba na NFS, tak skončí generování grub.cfg chybou.

[R]

Neviem, mozno to uz nejako opravili. Ale robil som skript na upgrade stoviek PC klonovanych z jedneho image, bol tam este GRUB 1. Tvarilo sa to, ze vsetko funguje. Pokym neprisiel grub2. Po upgrade-from-grub-legacy to uz nenabootovalo. Tak som pridaval echo "grub-pc grub-pc/install_devices string /dev/sda" | debconf-set-selections.

P.S. Skript sa doteraz nepouzil, stale to bezi na GRUBe 1.

[LP]

Debian survival guide:

Rule 1: Never upgrade, always clean install.

Rule 2: If you have problem, you have probably ignored Rule 1.

[Jendа]

Já tedy naopak vždy upgraduju, neinstaloval jsem ani nepamatuju, a žádný problém jsem nepotkal. (ne, problém popsaný v zápisku nesouvisí s upgradem, kdyby autor klonoval servery již nainstalované s Debianem 11, tak si kolizi přivodí úplně stejně)

[R]

Presne tak. Servery raz nainstalujem a potom upgradujem. Nas firemny server zacinal snad na 4.0 (alebo 3.1)? Teraz je tam 9 a budem robit upgrade na 10 a hned aj 11. Obcas sa nejaky problem vyskytne, ale vzdy sa da nejako vyriesit.

[Aleš Kapica]

Ty tomu rozumíš jak koza petrželi.

[MP]

Jo to urcite. Jestli si mam vybrat vypadek 5-10min na upgrade nebo 1h+ na migraci db na jinym stroji, tak si vyberu upgrade debianu.

[LP]

Jaky vypadek? Vzdyt to delas na klonu virtualu a kdyz je hotovo tak prepnes na novy za par vterin. DB ma rozumny clovek v clustru a syncne se to samo.

[Max]

Lol :D
Zdar Max

[Heron]

Asi tak. Ne, že bych nikdy nedělal upgrade Debu, ale v praxi je lepší to nainstalovat načisto dle nového standardu (síť v networkd místo interfaces, vyházet nepotřebné balíčky apod.), sync potřebných dat a je to. Ale to dost záleží, k čemu se ten server používá. Někdo rád tlačí kouli před sebou, kde jsou ještě pozůstatky starých pojmenování disků apod., já to rád čisté. Nebo rolling update v podobě testingu a čistit to v průběhu.

[Josef Kufner]

Ono záleží jak se ten server používá. S příchodem kontejnerů se přišlo na to, že mít předpis (skript), který reprodukovatelně sestaví celý server pro konkrétní službu a image se pak vypustí do cloudu (např. Kubernetes), je docela fajn věc. Na druhou stranu tu mám server nainstalovaný před 16 lety, běží tam aktuální stabilní Debian a problémy s tím nejsou.

[Heron]

Tak já si taky hýčkám instalaci v podstatě prvního debu po přechodu z centos.

S příchodem kontejnerů se přišlo na to, že mít předpis (skript)

Tohle je na delší povídání. Mám několik ansible playbooku ve svém repu, používám je, ulehčí to čas (a hlavně nudnou opakovanou práci), ale já se obecně snažím mít servery co nejjednodušší, že jejich čistá ruční instalace zase tolik nezabere. Aktuálně spolupracuju s lidmi, kteří to vidí lehce jinak a ti zase nastavují naprosto všechno. (A proto chtějí ke všemu skripty.)

[Max]

Já to celkem chápu. Ono mít celou infrastrukturu popsanou formou konfiguráků není úplně tak špatné. Ale zase podobně jako u toho kubernetu, záleží na rozsahu. Aneb u 10 serverů se nevyplatí udržovat a vše popisovat playbookama apod. Pokud jich mám třeba 100, tak je to zase o něčem jiném.
Zdar Max

[Heron]

Já nevím, já jsem v tomto divnej, ansible sice používám, ale vše co dělám ručně udělám rychleji. A současně mi nevadí dělat opakovanou činnost, takže třeba i něco udělat na 30 serverech, tak udělám ručně a za hoďku hotovo. Když píšu ansible, tak to stejně rychleji otestované nemám. Nehledě na to, že když se to má potom pustit na stovkách serverů, tak to testování musí být fakt důkladné a stejně se to pouští po skupinách. (Nehledě na to, že jsme sice měli stovky serverů ale stejných jich bylo vždy tak maximálně těch 40, takže je to tak na hraně.)

Takže, je to super jako dokumentace stavu, to naprostej souhlas a kdyby to byla jediná funkce, tak je to dobrý, ale není to o nic efektivnější (co se ušetří na běhu, se propálí na testování).

[MP]

Jo, pro bezestavove VM/kontejnery to je idealni. Tam si clovek doslova muze dovolit to znicit.

U stavovych je to tezsi (napr. nesmazat datovy disk).

Ja mam treba stale problem rozumne vyresit inicializacni konfiguraci site a disku...

[trekker.dk]

Nebo rolling update v podobě testingu a čistit to v průběhu.

Nebo upgrade mezi stable a čistit to při přechodu. Nebo teda "čistit", protože třeba se "síť v networkd místo interfaces" nechť se každý laskavě odebere tam, kam mu slunce nesvítí - mít spuštěnou službu na statickou záležitost jako nastavení sítě na serveru je ptákovina.

[Max]

Je to věc preferencí a politik dané distribuce .
Zdar Max

[MP]

Ta vase staticka zalezitost ale pak neumi fungovat treba v rezimu (ne)dostupnosti site.

Podobne jako je v dnesni dobe omezeny resolv.conf (pouze 3 NS? atd...)

[Jendа]

Ta vase staticka zalezitost ale pak neumi fungovat treba v rezimu (ne)dostupnosti site.

To jsem nějak nepochopil. Při statické konfiguraci přiřadím rozhraní adresy a nastavím routy a je jedno jestli je link a tak.

Jediné co mě napadá že by se mělo dělat je, pokud síťovka může failnout a zase se objevit (u PCIečkových se to asi nestane, ale u USB si to představit dokážu), tak se musí znovu nakonfigurovat.

[MP]

Nektere sluzby vyzaduji funkcni sit, jinak nenastartuji. Jak vam tohle vyresi staticky konfig?

[Jendа]

Nastaví to před spuštěním těch služeb?

Jinak ta služba asi nebude vyžadovat funkční síť jenom ve smyslu nakonfigurovaného interface (vyjma něčeho co se binduje na specifickou adresu), ale bude vyžadovat dostupnost nějakého vzdáleného počítače, a to nakonfigurování sítě nezaručuje (například při výpadku proudu může nastartovat náš počítač dřív než ten vzdálený), takže by si tohle spíš měl hlídat skript pro startování té služby. A ani interface se nemusí nakonfigurovat hned: například se spustí OpenVPN client, připojí se do vzdálené VPN, a pak se spustí služba, které používá openvpn rozhraní.

[MP]

Jo, pokud takovy DB cluster existuje, tzn. je na to jak SW, tak HW, vsechno je pokryty monitoringem, backupem, aplikace se nemusi prenastavovat a ja nevim co vse jeste...

[j]

Pricemz naprosto drtiva vetsina aplikaci s zadnym clusterem fungovat vubec neumi, a u kdyby ti to nakrasne fungovalo, tak od toho da ruce pryc libovolnej support ... ;D.

---

Dete s tim guuglem dopice!

[alkoholik]

Oracle klienti umi pracovat s RAC clusterem nativne. PostgreSQL muzes schovat za Pgpool-II a mas to transparentni.
Takze s 'drtiva vetsina' bych byl opatrny.

[j]

Ja bych opatrnej nebyl, protoze to je zkratka prostej fakt.

Jak sem rek, muze se ti treba i povist to zprovoznit, muzes ten cluster za neco schovat (cimz ovsem zrusis drtivou vetsinu jeho prinosu), ale v takovym pripade se muzes rozloucit s libovolnym supportem, protoze kdyz ti na tom neco fungovat prestane, je to ciste na tobe.

Dokonce je to jeste horsi, protoze existujou aplikace, u kterych ti tvurci jsou schopni tvrdit, ze to cluster podporuje, presne do okamziku, kdy se to pokusis nasadit. Pak zjistis, ze vubec nepocitaj s tim, ze by nekdo neco takovyho provozoval a ze vlastne vubec netusej, co to cluster je a k cemu to je.

BTW: I tady se v hlubinach zdejsich postu urcite najde slusna hromadka na tema rozpadla synchronizace databaze a tak podobne. Mozna jeste veselejsi jsou zazitky s clusterovanejma fs. To kdyz se ti ten cluster pekne rozpadne na dve pulky, a kazda polovina firmy vidi jinou, coz se tady tusim taky resilo.

---

Dete s tim guuglem dopice!

[Max]

Tak teď hodně vaříš z vody .
Zdar Max

[LP]

Provozuji tucet intranetovych webu, vetsina se konektuje na oracle cluster. Jak se to nainstalovalo pred 5ti roky tak na to nebylo treba sahnout. Instanci je kolem 15 vesmes 4 na kontinent a dokonce to devopsuji indove a nedokazou to domrdkazit :) To se samozrejme o debianu rict neda, to je pro takove garazove serverovani, my presli na RHEL (hlavne protoze oracle) a to je jina liga.

[Heron]

V čem? Já jsem RHEL (CentOS ale i placený RHEL) adminoval hromadu let a nic extra na tom není. V offiko repu vůbec nic není (na rozdíl od Debu), na všechno je nutno přidávat vlastní repo, strašně dlouho se zasekli u network scripts, které měly potíže s více ip na iface a o ipv6 ani nemluvím, nm-tui v RHEL 6 nebylo o nic lepší. Jinak je to linux jako každej jinej. Žádná jiná liga a dá se to rozbít úplně stejně. A hlavně to na rozdíl od debu nemá možnost dist-upgrade. Takže smát se debu, že je nutno (reálně není) pořád instalovat čistý server je kravina, navíc když to v rhelu není (nebo jen velmi skrytá placená varianta) možné vůbec.

[xkucf03]

V offiko repu vůbec nic není (na rozdíl od Debu), na všechno je nutno přidávat vlastní repo

Žádná jiná liga a dá se to rozbít úplně stejně.

Řekl bych, že když si přidáváš repositáře spravované různými týmy, tak je to riziko rozbití naopak větší – závislosti mezi balíčky, kolize, překřížení verzí… Alespoň tedy u klasických distribucí typu .deb/.rpm.

Debian/Ubuntu by se tímhle způsobem dal rozbít taky, ale tam má člověk to štěstí, že najde prakticky vše v distribučních repositářích. A když už instaluješ něco bokem, tak to je jedna dvě důležité aplikace, které si ohlídáš (ne spousty menších programů a knihoven, které chybí v .rpm distribucích).

[LP]

No ja nevim a nechci vedet nac mi je na servru 20000 balicku. Ja frcim uplne minimalisticke instalace a vyhazuji vse. Clovek by neveril jake obskurni zavislosti mezi baliky existuji a treba vyhodit Perl ze serveru chce uz radnyho machra a neporadi vam v komunite vubec nikdo, vsichni jen resi ze proc a nac a facepalm misto toho aby vyhrnuli rukavy a zkusili ten Perl odstranit Mene baliku = mene der = mene starosti. Stejne ty baliky testujou minimalne a pokusni kralici jsme my. To si takovy RedHat moc nedovoli a pripadny pruser aktivne resi a nakonec vam jako omluvu jeste poslou kozatou barbie at vam vykouri. To je servis! Bodejt ne za ty prachy

[Heron]

Aha, a já myslel, že se chceš bavit vážně. Tak nic.

[LP]

Heh, vazne na abicku? Tady se do fora chodi vyventilovat a vytrolit linuxaky bez smyslu pro sarkazmus a hyperbolu :-P Heh, ze vazne..

[Aleš Kapica]

Zrovna tys toho teda vytrolil.

[Max]

Jo, to je možná nějaký survival guide nějakýho BFU, který rozumí Debianu, resp. Linuxu, jako koza petrželi.
Zdar Max

[~]

Spise presne vi co debianistu vytroli...

[totosite]

There were so many things I didn't know, but I got so many things from here that my brain became stronger토토사이트

[slotsite]

Hello ! I am the one who writes posts on these topics slotsite I would like to write an article based on your article. When can I ask for a review?