Píšeme pravidla pro udev (diskuse)

[Michal Kubeček]

Udev před přibližně šesti lety definitivně nahradil starého, jaderného správce adresáře /dev zvaného devfs.

Tahle věta je IMHO trochu zavádějící, protože vzbuzuje představu, že se devfs opravdu používal. Ve skutečnosti ho ale z běžných distribucí používal pouze Mandrake, takže to byla spíš taková slepá ulička.

[Luboš Doležel (Doli)]

Aha, právě Mandrake jsem v té době používal. Co se používalo jinde?

[Michal Kubeček]

Totéž co od počátku unixových systémů: /dev jako normální součást filesystému a v něm statické soubory vytvářené skriptem při instalaci. Když bylo potřeba něco upravit (což bylo jen velmi zřídka), provádělo se to přímo příkazem mknod - buď to udělal přímo správce systému nebo post-instalační skript balíčku. Takové řešení mělo samozřejmě spoustu nedostatků, takže se hledaly způsoby, jak spravovat obsah /dev dynamicky, aby opravdu odpovídal tomu, co v počítači je, a umožňoval mít jména zařízení persistentní. Virtuální filesystém devfs byl (v Linuxu) první takový pokus, ale měl řadu chyb, proto se nikdy moc neprosadil a nakonec vznikl udev založený na úplně jiné koncepci.

[Sten]

IIRC se devfs používal i v Gentoo a v Debianu se snad objevoval v initrd (ale už ne dále)

[Michal Kubeček]

O tom, jestli je Gentoo běžnou distribucí dnes, by se dalo dlouze diskutovat. Ale za dob jádra 2.4 jí nebylo zcela určitě.

[ondro]

Podobné chování je u názvů síťových rozhraní. Že má v těchto názvech prsty udev se člověk bohužel často dozví, až když hledá důvod, proč je jeho síťová karta při startu přejmenována např. z eth0 na eth3 Udev totiž pro každé síťové rozhraní, co je kdy připojeno do systému, trvale vyhradí název.

To ma nemilo prekvalipo v Debiane, kde som za nic na svete nevedel prist preco pri vymene sietovky mi ta nie a nie fungovat, ked pri starsej distribucii Debianu to fungovalo.

Po hodinach patrania som na to prisiel, ze to sposobil udev a jeho pravidlo. Osobne si myslym, ze to mohli lepsie postavit aby sa chovanie udev podobalo tomu, co bolo pred tym. Ak mam jednu sietovku, tak preco po jej vymene to nemoze byt stale eth0. Tak mam za bezpecene, ze siet mi bude fungovat stale(samozrejme ak mam ovladac). Teraz to tak nieje a ludom, ktory sa s tym stretnu prvy raz to zbytocne komplikuje zivot. To nehovorim o BFU, ktory to nema sancu zvladnut. Neviem ako su na tom ine distribucie.

[Honza Jaroš]

Pokud se nepletu, jde tady v první řadě o to, aby u strojů s více síťovými kartami nemohlo dojít k prohození jejich názvů. To, že se po výměně síťovky pro ni vytvoří úplně nový název (neboť se změní MAC adresa) je jen vedlejší efekt.

[Michal Kubeček]

On je to vlastně nutný důsledek, protože zařízení mohou být dynamická (např. USB to ethernet adaptér), takže systém nemůže vědět, jestli se to, které "zmizelo", časem zase neobjeví. Proto nemůže (automaticky) znovu použít opuštěné jméno a musí novému zařízení přidělit nové.

[ondro]

Nemusi pridelit nove. To je len pohlad z urciteho uhlu na vec. Objavi sa to povodne zariadenie a pri deli sa mu najblizsie volne. Otazka znie aky vplyv to bude mat na nastavenie a chod systemu.

Neriesi to uz mno spominay problem, ze po vymene sietovky mi ta fungovat nebude lebo nebude nastavena. Sadne k tomu BFU a je nahrany. Nejako sa mu ju podari nakonfigurovat ako eth1 ale ak tu sietovku vymeni 5x(trochu prehanam), tak aj napriek tomu, ze ma v systeme stale len jednu sietovku, tak sa bude volat eth4. To nepovazujem za najstastnejsie riesenie.

Sposobuje to aj problem pri klonovani systemu. V novom PC bude mat sietovka inu MAC adresu a uz to zase nebude eth0 ale eth1 a zase je ju potrebne nastavovat alebo upravit udev pravidlo aby to bola eth0.

[Michal Kubeček]

Objavi sa to povodne zariadenie a pri deli sa mu najblizsie volne.

Jenže ta persistentní jména mají zajistit právě to, aby se tohle nestalo.

[Ondrej 'SanTiago' Zajicek]

Persistentni jmena mohou byt, ale je otazka, co je ten spravny klic, podle ktereho by se ta persistence mela udrzovat. Osobne myslim, ze absolutni pozice po sbernicich (tedy vicemene cesta v /sys/devices) je pro persistenci daleko vhodnejsi klic nez MAC adresa.

Takove reseni ma podstatne vyhody stejne jako persistence na MAC (nezavislost jmena na poradi objeveni ci vubec existenci ostatnich zarizeni) bez nevyhod (nutnost softwarove rekonfigurace pri vymene porouchane karty ci pri naklonovani).

[Honza Jaroš]

No pokud uvažujeme například výše zmiňovaný USB to ethernet adaptér, opět by to byla slepá ulička. Bojím se, že se nikdy nezavděčíte všem.

Ale já ten problém stejně nechápu. BFU-like distribuce používají NetworkManager, který by měl být schopen si ty karty nastavit sám. A u pokročilejšího uživatele bych čekal, že si to bude schopen upravit...

[David Jaša]

Sposobuje to aj problem pri klonovani systemu.

Tak klonování systémů je obecně problém kvůli chybějícímu všeobjímajícímu seal/sysprep postupu. Když je potřeba dělat často nové systému, je podle mě lepší zkousnout kulku a nasadit něco, co je naprovižnuje od nuly.

[Ash]

Nemusi pridelit nove. To je len pohlad z urciteho uhlu na vec. Objavi sa to povodne zariadenie a pri deli sa mu najblizsie volne. Otazka znie aky vplyv to bude mat na nastavenie a chod systemu.

Vliv to může mít značný, protože pro původní síťovku jste měl třeba nějak nastavenou síť, a to nastavení s novým jménem nebude fungovat.

V každém případě pokud chcete, aby se systém choval tak, jak popisuje, není nic jednoduššího, než persistentní jména prostě nepoužívat Persistentní jména totiž slouží právě k tomu, aby se tak nechoval.

[Ash]

Sposobuje to aj problem pri klonovani systemu. V novom PC bude mat sietovka inu MAC adresu...

Zkušený administrátor systém naklonuje bez toho persistentního souboru Problem solved.

[Gilhad]

Tohle jsem celkem jednoduse "vyresil" tim, ze ve skriptu, co se spousti pri vypinani stroje ten soubor /etc/udev/rules.d/70-persistent-net.rules proste smazu. Pak prvni nalezena sitovka (cti jedina) dostane prvni volne jmeno (cti eth0) a veci funguji spravne. Ostatne stejne jsem to udelal i s CD mechanikama

[blami]

To je nadherne hnusny hack!

[Michal Kubeček]

Nebylo by jednodušší prostě vyhodit ten generátor?

[Marián Kyral]

A při další aktualizaci udev se mu tam ten generátor zase vrátí. To není moc velká výhra

[Michal Kubeček]

Když tam nechám prázdný soubor, tak by mi ho přepsat neměl, je-li ten balíček udělaný rozumně.

[Marián Kyral]

Tak to jo. To by šlo.

[Michal Kubeček]

Podobné chování je u názvů síťových rozhraní. Že má v těchto názvech prsty udev se člověk bohužel často dozví, až když hledá důvod, proč je jeho síťová karta při startu přejmenována např. z eth0 na eth3 Udev totiž pro každé síťové rozhraní, co je kdy připojeno do systému, trvale vyhradí název. Tyto názvy jsou pak zapisovány do /etc/udev/rules.d/70-persistent-net.rules. Tento soubor můžete dle své vůle upravovat, nebo smazat.

Tady by bylo vhodné upřesnit, že to udev nedělá sám od sebe, ale opět na základě nějakého jiného souboru s pravidly (a za pomoci helperů). Např. v OpenSuSE 12.2 je to /lib/udev/rules.d/75-persistent-net-generator.rules

[ludvik]

Jenže leckdy tam ten generator není ... např. Archlinux ho už nemá. A tam jsem narazil také na to, že nelze jen tak přejmenovávat jak se mi zlíbí. Např. nadefinovat si to jako eth0-ethX je cesta do pekel. Občas se to přejmenování totiž neprovede, zjevně neumí vyřešit konflikt. Takže musím používat jiné názvy, např net0. Je tam jádro 3.4.9. A vím, že dříve to šlo bezpečně, mám to tak na více kusech serverů, s různými jádry.

[Michal Kubeček]

Pokud tam ten generátor není, tak tam není ani ten soubor s pravidly, o kterém píše autor.

Přejmenovávání na jména, která by mohla kolidovat s těmi automaticky generovanými, se obecně moc nedoporučuje (ať už u blokových/znakových zařízení nebo u síťových rozhraní). On i ten generátor je trochu komplikovanější a snaží se potenciální kolize řešit, ale stejně je to náchylné na race conditions. Některé zdroje jdou dokonce tak daleko, že doporučují NAME="..." nepoužívat vůbec, nechat všemu původní jména a jen přidávat symbolické linky. Ale to zrovna u síťových rozhraní nejde.

[Limoto]

 

Jenže leckdy tam ten generator není ... např. Archlinux ho už nemá.

A ani nikdy neměl

 

[D.A.Tiger]

Pěkné, dík :)

[the.max]

Parada, uz dlouho chci prejmenovat usb-serial prevodniky tak, aby se mi ruzne po restartu neprehazovali, ale protoze jsem nikde nenasel zadnej ucelenej 'navod' v cestine, ale jen v anglictine, odkladal jsem to (jiz druhy rok) na dlouhe zimni vecery

[loki]

Super clanek, diky za nej.

[Cohen]

Tak. Být tu Flattr tlačítko, tak už tam má hlas.

[edison]

ten prikaz "CMD=" se mi nejak nezda. Nemelo by tam byt nahodou "RUN+=" ?

[Luboš Doležel (Doli)]

Mělo, nevím, jak jsem přišel na CMD.

[Ondrej 'SanTiago' Zajicek]

Novy devtmpfs je moc pekna vec, nicmene jednu vec jsem nepochopil. Kdyz uz leta mame v /sys textovy soubor s major a minor cislem zarizeni (e.g. /sys/class/block/sda/dev ), proc tam uplne stejne nemuze byt device node toho zarizeni. Pak by stacilo misto /dev proste pouzivat device nodes v /sys.

[wykys]

Ahoj, zkoušel jsem podle vašeho popisu napsat pravidlo pro udev, aby mi po připojení klávesnice spustilo skript, který nastaví pro každou klávesu specifické podsvětlení, ale pokud použiju tohle pravidlo:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c331", ACTION="add", RUN="/home/wykys/.config/g810.sh"

Ta se nic nestane, pokud odstraním s pravidla ACTION="add", tak to funguje, ale zároveň to zatěžuje procesor, protože skript se spouští stále znovu.

[wykys]

Tak už to funguje, problém byl v zapomenutým rovnáse v podmínce.

ACTION=="add", ATTR{idVendor}=="046d", ATTR{idProduct}=="c331", RUN="/home/wykys/.config/g810.sh"

[aldrtik]

Tady slo o pravidla zarizeni, ktera byla moznost si osahat.

Predpokladejme ze uzivatel, co nevi nic o udev a pravidlech, bude chtit treba pouzivat flesky nebo externi disky, ktere mu nekdo prinese (treba i pro zapis). Je mozne psat pravidla i pro genericka zarizeni, nebo uz takova v distribucich byvaji, a kde je hledat?