Vlákno názorů k článku Debian 9 Stretch je tu: firewall nftables a konec MySQL od Santiago - > Používá mnohem více skutečných informací od hardware,...
-
Santiago (neregistrovaný)
> Používá mnohem více skutečných informací od hardware, jako je například tabulka hardware v BIOSu nebo pořadí karet ve slotech.
Funguje tohle nekomu? Zatim jsem jeste nevidel, ze by nekdo nacetl nejake rozumne informace z BIOSu (napr. mapovani PCIe devices na fyzicke sloty), a ten novy mechanismus mi vzdy skoncil na pojmenovani rozhrani podle PCI numberingu, coz funguvalo stabilne v dobach klasicke PCI, ale na PCIe je to rozbite kvuli sekvencnimu cislovani PCI busu.
Takze zatimco standardni kerneli mechanismus precisluje sitovky pri pridani nebo ubrani sitove karty, novy udev mechanismus precisluje sitovky pri pridani nebo ubrani libovolne PCIe karty. Ale hlavne ze se to jmenuje 'Predictable Network Interface Names'.
-
Bohuzel, je snad lepsi ponechat si stare udev scripty, ktere device prejmenuji podle MAC adresy na ethX. Osobne jsem s tim nikdy zadny problem nemel. Zato mam problem s tim, ze mam nastroje, ktere pracuji s eth0 (protoze v systemu proste byla vzdy jen jedna sitovka), ale ted se sitovka v systemu jmenuje na kazdem pocitaci uplne jinak a zpravidla zcela nezapamatovatelne. Je to neco jako UUID ale pro sitovky. Driv taky stacilo prekopirovat OS na jiny disk a spustit, dneska bez poskakovani kolem UUID a regenerovani initramfs nejde nic.
-
wsh (neregistrovaný)
Jo, taky to vracím zpět, v mém případě kvůli monitoring nástrojům.
Třeba Zabbix má nějaké regulární výrazy, kterými detekuje, že dané zařízení je síťová karta a názvy jako enp1s1 tam nejsou (mohl bych je doplnit, ale ani nevím, kde najít komplet seznam možných názvů). Stejně tak je jednodušší nastavit si monitoring na eth0 než na libovolné rozhraní a odfiltrovávat docker0, veth* apod.
-
Slávek (neregistrovaný)
Díky, jsem rád, že nejsem jediný, kterému nové pojmenování připadá jako nesmyslné řešení problému, který přestal existovat v době, kdy se začalo používat pojmenování vázané na MAC adresu.
Například "predikovatelnost" pojmenování síťových rozhraní integrovaných na základní desce je super - stačí přece spočítat neviditelné sloty. A když se taková karta pokazí, tak se "opravdu snadno" zajistí, aby nová karta měla stejné pojmenování jako předchozí integrovaná na desce a nemusela se kvůli její výměně předělávat konfigurace všeho souvisejícího.
Tuší někdo, jak se asi zachová základní deska, která má například integrované čtyři karty, když některou z nich vypnu? Příslušný neviditelný slot se bude tvářit jako prázdný a nebo se snad čísla neviditelných slotů posunou a "predikovatelnost" bude... no prostě úžasná?
-
Slávek (neregistrovaný)
No, hezká myšlenka. Jen mi schází nějaká rozumná rada na to, co už jsem zmiňoval výše: Jak zajistíte zachování pojmenování rozhraní, když se pokazí síťová karta integrovaná na základní desce, aby se nemusela kvůli její výměně předělávat konfigurace všeho souvisejícího.
Se špatným zastaralým způsobem stačí jednoduše aktualizovat MAC adresu v příslušném udev pravidlu a jede se dál. S báječným novým pojmenováním jako udělám co?
-
j (neregistrovaný)
To tezko, kdyz ma 10k stroju co pouzivaj ethX ... tak ma zcela na kazdym tom stroji eth0. Specielne kdyz ty stroje maj jeden port.
Kdyz ma 10k stroju co pouzivaj "predikovatelny" nazvy, tak ma na kazdym jednom jinej nazev sitovky, a to i kdyby byla presne a prave jedina.
Navic nemuze jednoduse vzit 10k stroju a spustit na nich jeden centralne udrzovane img systemu, protoze potrebuje jinej system pro kazdej jeden stroj, coz je vazne uzasny.
-
Slávek (neregistrovaný)
Ano, jasně, nabootovat s net.ifnames=0 není tak těžké.
Jen jsem doufal, že se třeba dozvím nějaké na první pohled skryté výhody, které mělo toto úžasné řešení dlouho dobu neexistujícího problému přinést, když je takto servírované ve výchozím stavu. Namísto toho jako výsledek vidím jen to, že je třeba buď přidat volby, které doteď nebylo třeba, a nebo psát ručně pravidla, která dříve byla generována automaticky a stačilo je jen jednoduše aktualizovat.
-
Sten (neregistrovaný)
@Slávek: nějaké výhody jsem nastínil výše. Kompletní zdůvodnění je zde.
@j: Předvídatelná jména síťových rozhraní nemají nic společného s Poetteringem. Přišel s nimi Matt Domsch a měl podporu např. kernelového vývojáře Grega Kroah-Hartmana. Linus tu změnu schvaloval pod podmínkou, že si to bude řešit userspace, což je hlavní důvod, proč je to v udevu.
-
j (neregistrovaný)
2Sten: Jisteze a proto z udevu zmizela moznost priradit ethX na zaklade MAC ... kratce potom, co to ten idiot zaintegroval do systemd.
Vis, kdyby tu ty uzasny nazvy byly 10 let, a 90% veci by to bez problemu pouzivalo, tak by situace byla ponekud jina, nez kdyz proste ze dne na den nejakej kokot rekne, ze eth uz nebude eth.
BTW: Si pravidelne dovoluju tu drzost pouzivat screen, a po odhlaseni mi ho nic nekillne ... hec ..
-
Ondra Satai NekolaZlatý podporovatel"Si pravidelne dovoluju tu drzost pouzivat screen, a po odhlaseni mi ho nic nekillne ... hec .."
No to teda. Uplne jako na systemd na vetsine dister, co si to tak nastavila... Nebo jako by sis to nastavil za polovinu casu, cos ted venoval psani tohohle OT hemzu.
-
Sten (neregistrovaný)
Jisteze a proto z udevu zmizela moznost priradit ethX na zaklade MAC ... kratce potom, co to ten idiot zaintegroval do systemd.
Ta možnost je pravidlo, které si tam klidně můžeš napsat a pořád bude fungovat.
Vis, kdyby tu ty uzasny nazvy byly 10 let, a 90% veci by to bez problemu pouzivalo, tak by situace byla ponekud jina, nez kdyz proste ze dne na den nejakej kokot rekne, ze eth uz nebude eth.
Ty názvy neměnil „nějaký kokot ze dne na den“, ta změna se připravuje a ladí od roku 2009 (takže skoro těch 10 let), testuje na serverech Dell od roku 2011, schéma pojmenování se vyvíjelo a současné se používá od roku 2014. Že až dosud j-čko netušil, co se děje, je jeho chyba.
Si pravidelne dovoluju tu drzost pouzivat screen, a po odhlaseni mi ho nic nekillne ... hec ..
Mě taky ne, protože screen spouští PAM session. Výchozí nastavení Debianu.
-
Slávek (neregistrovaný)
Jasně, namísto toho, abych měl udev pravidla, která vznikala automaticky a jen jsem je v případě potřeby snadno upravil, tak nově je třeba psát pravidla vlastní, abych se dostal do použitelného stavu... to je fakt "lepší" :)
Představa, že kvůli báječnému novému pojmenování by pro výměnu karty na základní desce muselo být pravidlo, které bude enp2s1 přejmenovávat na enp0s3, je fakt lákavá.
Děkuji za potvrzení, že báječná nová jména jsou nevhodná k používání, a že je nezbytné napsat si udev pravidla pro zajištění stabilního pojmenování, které bude možné používat v konfiguracích služeb.
-
j (neregistrovaný)
Jmenuje se to nahodou zcela spravne, muzes predem predikovat, ze se to pri zcela libovolny zmene naprosto rozesere ...
BTW: Staci kdyz ty karty prohazes ve slotech.
Jinak teda muzes (nez zas soudruh o nejvyssi a nejgenialnejsi prijde s tim ze to je spatne) navazat nazev (krome EthX) na MAC. Pak si to (zatim) pamatuje.
-
Tohleto je naprostá kravina především na velkých serverových farmách. Tam si člověk objedná papírově stejný server od jiného dodavatele, a pak aby přepisoval orchestraci. My to vypínáme, protože potřebujeme aby první síťovka v serveru (to je ta ze které se spustí jako první PXE boot) měla vždy stejné jméno. A kernel má pořadí síťovek na 99% konzistentní s biosem (tedy na 100% našich serverů).
No a na desktopu si většina lidí dává NetworkManager (podobně úchylný produkt jako systemd nebo pulseaudio, jen zaštítěný freedesktopem), a ten stejně myslím rozlišuje zařízení podle MAC adresy a název mu je celkem jedno (alespoň když klikám "connection", tak tam lze vybrat zařízení jen dle MACky).
Takže ano, za mne je to řešení dávno vyřešeného problému způsobem, že se to rozbije tam kde problém nebyl a tam kde problém byl, tak už je to vyřešeno dávno jinak.
-
Samozřejmě by mi bylo jedno jaká je defaultní politika, kdyby byla se změnou dodána možnost zpětně kompatibilní konfigurace - tedy pravidlo které docílí předchozí funkcionality (včetně přidání do /etc/...persitent..). To by totiž umožnilo administrátorovi si to případně přiohnout dle svého přání. Ani by to pravidlo nemuselo být v defaultu povolené, jen by to chtělo aby si ho nemusel každý admin dělat homo domo na svých strojích různě, protože tyhle "predictable" interface names takhle povedou akorát na nepredikovatelné hacky v různých orchestračních a autodeployment nástrojích.
-
motyq (neregistrovaný)
Pouzivam stare nazvy, tedy do syslinuxu/grubu pridam
net.ifnames=0 biosdevname=0
pak je vsechno eth0 - ethX a na stejnem hw porad stejne.
99% serveru dell, supermicro apod pak odpovida eth0=prvni sitovka tak jak je oznacena na chassi.
Vetsinou do rackovych serveru dalsi sitovky nepridavam, takze pak je to proste vsude ok a odpovida to znaceni na bedne/znaceni od vyrobce.
Kdyz to takto mam, tak muzu i automaticky sestavovat bond z eth0+eth1, kdy technik proste zapoji prvni dve sitovky a hotovo. Tech pripadu kdy je neco jinak je naproste minimum.Kazdopadne tento pripad - rackove servery = porad stejny hw, by pocitam fungoval i s temi novymi nazvy sitovek. Akorat by se to lisilo vyrobce od vyrobce, mozna verze serveru od verze serveru...
-
Případně přímo z kernelu přes /sys filesystém, například:
ls -la /sys/class/net/enp0s31f6/device/driver
lrwxrwxrwx 1 root root 0 Jun 20 20:46 /sys/class/net/enp0s31f6/device/driver -> ../../../bus/pci/drivers/e1000eNicméně to není přenositelné na staré kernely (které zase typicky nepoužíváte s tímhle výmyslem). Nedavno jsem dělal check na konfiguraci bondů a stav slave síťovek, který běží od 2.6.35 do 4.0.9, těch ifů dle kernelu je tam víc.
