Portál AbcLinuxu, 26. dubna 2024 14:35
13.5.2014 11:01
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
eth0 byla někdy síťovka, někdy wifina. Po nainstalování toho druhýho ovladače, kterej wifině přiděluje wlan0 (a krom toho je lepší) problém odpadl, ale je možné, že kdyby tam například ty wifiny byly dvě, zase by se to přehazovalo...
13.5.2014 19:02
rADOn | skóre: 44
| blog: bloK
| Praha
jinak to ze se ti to nestalo znamena jen to ze jsi mel stesti, nebo ze sis toho nevsiml. Kernel nijak negarantuje ze se to nebude menit, pouze se jeho vývojari na cestne slovo snazi aby se ovladace pri bootu dostávaly v lizu pokud mozno ve stejnem poradi. Ale kdyby k tomu byl dobry duvod, zmenit to mohou (ovsem Linusova definice dobreho duvodu je evidentne narocnejsi nez Lennartova . Kdyz bys menil ovladac (treba brcmsmac -> brcmfmac) tak ti zase nikdo nic neslibi. Nemluve o tom ze staci aby behem detekce skytla sbernice a jsi zase sejdrem… V praxi je to sice na 99% spolehlivy ale treba u firewallu se vzdycky doporucovalo kontrolovat MAC adapteru.
biosdevname od Dellu. Jenom by mě zajímalo, jestli si to pisatel blogu nainstaloval, nebo jestli se to stalo součástí systemd (což se mi nezdá).
13.5.2014 13:27
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
biosdevname som medzitým nainštaloval, to je pravda. Nemal som potuchy, že to zmení chovanie udevu. Mal som za to, že biosdevname len číta, nie že sa spolčí s udevom a "upečú" to spolu. Ďakujem za nasmerovanie.
14.5.2014 13:34
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
* sys-apps/biosdevname
Available versions: 0.3.11-r1 0.4.0 0.4.1
Homepage: http://linux.dell.com/biosdevname/
Description: Sets BIOS-given device names instead of kernel eth* names
No nevím, když vidím "Sets" tak bych předpokládal, že to něco nastavuje 
přijde celkem vhod si v udev pravidlech nastavit pevná jména podle MAC adres síťovek
Tak se to také ve většině distribucí už dost dlouho dělalo. Pak ale přišel Kay Sievers a rozhodl, že je to špatně a že místo persistentních jmen potřebujeme jména "predikovatelná" - která ovšem obecně nejsou ani persistentní, natož predikovatelná.
sám jsem párkrát zažil, že po upgradu jádra se mi prohodilo eth0 a eth1
Na to mnohdy není potřeba ani upgrade, leckdy na to stačí i reboot.
ethx${mac}". Co ještě chce kdo víc?
která ovšem obecně nejsou ani persistentní, natož predikovatelná.[citation needed]
[citation needed]
Opravdu? Tak si přečtěte blogpost, ke kterému je tato diskuse. Stejný HW, stejný BIOS, stejné jádro, stejný udev, dva booty, pokaždé jiné schéma použité pro "predikovatelná" jména. Připadá vám to persistentní? Připadá vám to predikovatelné? A není to zdaleka jediný případ, podobnou věc jsem už zažil i sám (tam šlo o instalátor vs. nainstalovaný systém), stejně jako hrůzy typu eno16777217.
13.5.2014 15:36
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
To ale na věci vůbec nic nemění - podstata je v té sieversovině, bez které by ten problém (jakož i spousta jiných) vůbec nenastal, ani kdyby si biosdevname stavěl na hlavu.
Kay Sievers měl pravdu v jediné věci: že použít pro persistentní jména stejný jmenný prostor jako ten, ze kterého jména přiřazuje jádro, bylo nešťastné a náchylné na race conditions. Ale to šlo snadno vyřešit použitím jiného prefixu v persistent name generátoru a bylo by vymalováno. Nebylo kvůli tomu potřeba vymýšlet ptákoviny. Jen by to holt nebyla the systemd way.
1. V tom nevidím nejmenší problém.
2. To může být komplikace, ale za normálních okolností je při instalaci stejně potřeba mít /etc zapisovatelný a pak už se to měnit nebude.
3. To je kontrolovaná situace, kdy vím, že ke změně dojde, a zařídím se podle toho. A můžu se na to i předem připravit.
4. To nelze ze spousty jiných důvodů, tak jako tak je vždycky potřeba přizpůsobení konkrétnímu systému.
Ackoliv nova sieversovina ma taky spoustu problemu … tak je to aspon castecny navrat k pricetnosti (napr. tim, ze je bezestavova).
Právě tím, že se snaží být bezstavová, vznikají problémy, které způsobují (jak ukazují bugreporty), že nedokáže zajistit ani tu persistenci. Takže krok zpátky to je, ale bohužel ne k příčetnosti.
No, ta predchozi byla zas protlacovana v ramci udevu
Tohle ale nebylo nikým protlačováno. Naopak, třeba SuSE Linux jednu nebo dvě verze problém řešil tak, že jména persistentní nebyla a byla k dispozici utilitka převádějící persistentní identifikátor (např. MAC adresu) na jméno rozhraní. Celkem to fungovalo, ale bylo to nepraktické, takže nakonec stejně jako ostatní distribuce (jen později) došli ke generátoru, který se stal i součástí upstreamu.
To je právě ten zásadní rozdíl mezi tím, co vznikne přirozenou cestou jako výsledek potřeb vývojářů a uživatelů, a tím, co někdo tlačí silou. O jaký případ jde u "persistentních jmen", ilustruje i fakt, že pokud se "persistentní jména" vypnou (což se dělá jedním z nejméně praktických způsobů), nedostanete původní generátor ani upravený generátor nekolidující s jmenným prostorem jádra, ale nepersistentní jaderná jména; přičemž generátor byl pro jistotu z balíčku odstraněn úplně (the systemd way: our way or the highway).
O jaký případ jde u "persistentních jmen", ilustruje i fakt, že pokud se "persistentní jména" vypnou
Tady samozřejmě v obou případech mělo být "predikovatelná jména".
2. To může být komplikace, ale za normálních okolností je při instalaci stejně potřeba mít /etc zapisovatelný a pak už se to měnit nebude.Nejde o instalaci, ale např. o stateless výpočetní uzly, které bootují ze společného RO filesystému, a /etc, /run atd. mají pak na ramdisku. Můžeme uvažovat, že nějaký provisioning konfigurace se ve výsledku stejně dělá podle HW identifikace, ale abych ho mohl u nového HW udělat vzdáleně, je třeba aby se ten HW dostal na síť. A to když neví, který interface je který, jde docela blbě.
3. To je kontrolovaná situace, kdy vím, že ke změně dojde, a zařídím se podle toho. A můžu se na to i předem připravit.Jak se předem připravíte na to, že systém vám bootuje ze SAN "každou chvíli na jiném HW"? Nebo třeba ne až takový extrém, ale že prostě při poruše HW nabootujete někde jinde, ale předem nevíte kde? Budu si bastlit nějaké skripty, které to při bootu poznají, a podle fyzické cesty k zařízení si nějak vyčtu jejich MAC adresy a z nich vygeneruju nové persistentní udev rules?
Systémy, o kterých mluvíte, budou mít typicky jen jedno (aktivní) rozhraní nebo, bude-li jich víc, budou stejně v bondu.
Navíc takové speciální případy stejně vyžadují tolik úprav a přizpůsobení standardní distribuční konfigurace, že vytvoření udev pravidel na míru konkrétním potřebám nevidím jako zásadní problém.
Systémy, o kterých mluvíte, budou mít typicky jen jedno (aktivní) rozhraní nebo, bude-li jich víc, budou stejně v bondu.Tak to rozhodně ne. Často tam bude jedno rozhraní na veřejnou síť, jedno na interconnect / backend, jedno na storage. Některé/všechny pak mohou být zdvojené v bondu.
Navíc takové speciální případy stejně vyžadují tolik úprav a přizpůsobení standardní distribuční konfigurace, že vytvoření udev pravidel na míru konkrétním potřebám nevidím jako zásadní problém.Dobře, tak jeden server v datacentru na pronajatém HW -- žádná speciální situace, řekl bych. Když DC zjistí závadu HW, sami do pár desítek minut dokážou vzít disky a dát je do náhradního HW stejného typu. Ethernety tam jsou 2 - veřejná síť a private backend síť. Nebo to může být blade server, kde storage je sdílený přes SAS, a je tam spare blade. Ten zapnou, a všechno by mohlo hned běžet dál. Pokud jsou interfacy vázané na MAC adresy, nepojede síť. Neměl by na tohle linux mít standardní řešení?
Dobře, tak jeden server v datacentru na pronajatém HW -- žádná speciální situace, řekl bych. Když DC zjistí závadu HW, sami do pár desítek minut dokážou vzít disky a dát je do náhradního HW stejného typu. Ethernety tam jsou 2 - veřejná síť a private backend síť. Nebo to může být blade server, kde storage je sdílený přes SAS, a je tam spare blade. Ten zapnou, a všechno by mohlo hned běžet dál. Pokud jsou interfacy vázané na MAC adresy, nepojede síť. Neměl by na tohle linux mít standardní řešení?Jak tenhle problém řeší jiné systémy, než
udev? Pojmenujete ta síťová rozhraní náhodně eth0 a eth1 a berete to, že 50 % pravděpodobnost úspěchu je dost vysoké číslo? Nějak si nedovedu představit řešení nezávislé na vnějších informacích, které se vyrovná s jakoukoli změnou hardware. Vždyť to, na které síťové kartě je veřejná síť a na které backend síť může záviset jenom na tom, který kabel padne technikovi první do ruky.
Ge/0/2/47.
U ethernetů bych čekal označování - u onboard portů podle čísel, která jsou u nich v případě serverů vždy napsaná. U přídavných karet podle čísla slotu (který bývá taky viditelně popsán zvenku skříně) a čísla portu na kartě (může být opět popsáno, nebo je to číslováno od nějaké dané strany, a pak se tam doplní štítky).
Přijde mi, že právě tohle je možné s aktuálním odklonem od sekvenčního číslování eth0, 1 ... a zavedení označování podle fyzické cesty, případně jmen poskytnutých nějakým firmwarem. Samozřejmě je problém PC-class HW, kde tohle není nijak standardizované.
Nějak si nedovedu představit řešení nezávislé na vnějších informacích, které se vyrovná s jakoukoli změnou hardware.Vůbec nejde o jakoukoliv změnu HW. Jde mi výhradně o jiný kus HW stejného typu. Typické případy takové situace jsem vám napsal.
Vždyť to, na které síťové kartě je veřejná síť a na které backend síť může záviset jenom na tom, který kabel padne technikovi první do ruky.Tak to snad ne. Technik má nějaké podklady, jak to má zapojit. Když se mění HW, tak stávající kabely mají popisky na kterou kartu a který port patří. U nového HW se řekne na kterou síť (případně i který switchport) má být který interface zapojený. Přitom se vychází z toho značení, které je na lepším HW přímo napsané, případně se doplní náčrtek.
U ethernetů bych čekal označování - u onboard portů podle čísel, která jsou u nich v případě serverů vždy napsaná. U přídavných karet podle čísla slotu (který bývá taky viditelně popsán zvenku skříně) a čísla portu na kartě (může být opět popsáno, nebo je to číslováno od nějaké dané strany, a pak se tam doplní štítky).A když tu kartu posunu o slot vedle, protože tam potřebuju něco přidat a do druhého volného slotu se to nevejde, tak jsem zase v háji.
Vůbec nejde o jakoukoliv změnu HW. Jde mi výhradně o jiný kus HW stejného typu. Typické případy takové situace jsem vám napsal.Takže my, co občas něco vyměňujeme do jiného HW, se máme jít bodnout? (Stejný hardware na Linuxu? Proč? Vždyť to bootuje všude.)
A když tu kartu posunu o slot vedle, protože tam potřebuju něco přidat a do druhého volného slotu se to nevejde, tak jsem zase v háji.To sice jo. Pokud jde o posunutí stejné karty do jiného slotu, tak to je skutečně případ, kdy jsou jména podle MAC výhodnější. Nicméně tohle mnohem víc plánovaná operace než nečekaný výpadek HW, takže vidím jako menší problém změnit názvy v konfiguraci v tomhle případě, než když se mění HW za stejný typ, a dá se bez administrativního zásahu obejít.
Takže my, co občas něco vyměňujeme do jiného HW, se máme jít bodnout? (Stejný hardware na Linuxu? Proč? Vždyť to bootuje všude.)Ne, bude to fungovat jako do teď - na jiném HW budou jinak pojmenovaná rozhraní, pokud se na to předem nepřipraví konfigurace. Ať už vlastními pravidly pro přejmenování podle MAC nebo fyzické cesty, nebo využitím nového systému jmen. Chci jen říct, že nový systém co je teď v linuxu mi řeší některé dřív problematické případy, a jiné třeba neřeší (protože to třeba automaticky dost dobře nejde), ale není to zhoršení proti předchozímu stavu. Jak už jsem psal, tak jako jediné zhoršení vidím v situaci přesunu karty do jiného slotu, nebo USB adaptéry pokud jsou pojmenované podle fyzického portu. Může mít vůbec síťové zařízení v linuxu víc jmen? Pak bych si mohl vybrat, jestli chci používat označení podle MAC nebo fyzické cesty. Nebo na to může být nějaký nástroj, co mi připraví konfiguraci udevu. Ale beru to jako lepší stav, než dřív.
Ne, bude to fungovat jako do teď - na jiném HW budou jinak pojmenovaná rozhraní, pokud se na to předem nepřipraví konfigurace.Ono pokud je stejna logicka cesta, tak je vcelku jedno, jaky konkretni hardware tam je - pokud mam sitovku na pci0000-1c.1-0, tak je vcelku jednoznacne identifikovana, at uz je to rtl8169 nebo e1000e.
Může mít vůbec síťové zařízení v linuxu víc jmen?Nemuze. Jen jedno a delky max 15 nebo 16.
udev řešitelné. Není to řešitelné se sekvenčním číslováním ani s predikovatelným číslováním. Ani s označením podle fyzické cesty, protože můžete dostat jiný kus HW stejného typu, který ale bude fyzicky zapojen jinak. To, že se s udevem jména nastavují podle MAC adresy je akorát nejjednodušší a nejčastější řešení, ale jinak můžete kartu detekovat jak chcete.
Pokud jsou obě síťové karty stejné, může se klidně dělat i tak, že se karty nejprve zapojí a teprve pak se - podle toho, která je kam zapojená - určí, která je ta pro veřejnou síť a která pro backend.
Nějak si nedovedu představit řešení nezávislé na vnějších informacích, které se vyrovná s jakoukoli změnou hardware.Nepamatuju si kdo, ale dělá se něco jako serverovna-all-in-one, prostě ti přivezou rack (nebo víc), v tom je storage, servery a něco, co to všechno řídí. Když ti odejde blade, dá se tam jiný, ten od managementu téhle věci dostane info o tam, jaké MAC adresy měl ten původní, a jede se dál.
1. V tom nevidím nejmenší problém.To je teoreticky problem, ktery vede k explozi moznych stavu systemu, coz ma pak mnoho neprimych praktickych dusledku (napr. daleko horsi predvidatelnost v chovani).
3. To je kontrolovaná situace, kdy vím, že ke změně dojde, a zařídím se podle toho. A můžu se na to i předem připravit.Ne, pokud k vymene dochazi na zaklade necekane poruchy a pokud je sit zaroven primarni kanal pro management.
4. To nelze ze spousty jiných důvodů, tak jako tak je vždycky potřeba přizpůsobení konkrétnímu systému.Ne nutne. Ale i kdyz nejake upravy muze byt treba udelat, ale alespon ma clovek funkcni sit, takze se tam muze prihlasit a udelat je.
že nedokáže zajistit ani tu persistenciV okrajovych pripadech to nedokaze zajistit zadny zpusob - systemy zalozene ma MAC adresach selhavaji v pripadech nahodne generovanych MAC adres (dnes obzvlaste popularni vzhledem k virtualizaci) nebo v pripade, kdy MAC adresy prideluje onboard sitovkam BIOS, a nebo proste u sitovek, ktere ani MAC nemaji (ne-ethernet, ne-wifi). Systemy zalozene na topologii pak v pripadech, kdy virtualni topologie se meni podle voleb v BIOSu (to je treba pripad u diskovych radicu a volby AHCI / legacy IDE). A pak je otazka v presne definici persistence. Ja bych i to, ze konfigurace neprezije vymenu kus za kus, povazoval za selhani persistence, nebot o pocitaci uvazuju jako o sestave funkcich casti, ktera je definovana svou strukturou, a ne identitou jednotlivych casti (pokud nejde o cast, ktera ze sve funkce uchovava permanentni vnitrni stav, jako treba harddisk).
Tohle ale nebylo nikým protlačováno.No, minimalne distributory baliku pro udev. Klidne mohli nechat udev s minimalni konfiguraci a nechat plne na uzivatelich, co si chteji nastavit.
13.5.2014 16:36
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
13.5.2014 17:05
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
eth0 nebo tvojeBaba123...
✔ 19:01 vojta ~ $> cat /boot/syslinux/arch.cfg | grep APPEND | head -1
APPEND (snip) init=/usr/lib/systemd/systemd net.ifnames=0
✔ 19:01 vojta ~ $> cat /etc/udev/rules.d/80-net-setup-link.rules
# This file masks persistent renaming rules for network devices. If you
# delete this file, /usr/lib/udev/rules.d/80-net-name-slot.rules may
# rename network devices according to ID_NET_NAME_{ONBOARD,SLOT,PATH}
# properties of your network devices, with priority in that order. See
# the output of 'udevadm test-builtin net_id /sys/class/net/$interface'
# for details on what that new name might be.
#
# http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
✔ 19:01 vojta ~ $> cat /etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="(snip)", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="(snip)", NAME="eth1"
✔ 19:02 vojta ~ $> ls /sys/class/net
eth0 eth1 lo
✔ 19:02 vojta ~ $>
eth0 a wlan0)
$> ls /sys/class/net
eth0 lo tvojeBaba123
eth0 je ta bývalá eth1 (což je úplně původně wlan0)... Stále žádný problém.
Na jaké konfiguraci si s tím měl problém?
For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back.Není mi jasný, co přesně teda bylo odebráno. Já asi fakt budu muset nainstalovat ten druhej driver a vyzkoušet to
16.5.2014 11:18
pavlix | skóre: 54
| blog: pavlix
Já si hlavně myslím, že je potřeba znát fakta a řídit se jimi. Je dobré vědět, že je ta metoda nespolehlivá.jistě, vím, že nejsem dokonalý řidič, takže cestuji-li z A do B, mohu namísto v B skončit na krchově řídím se tím a pokukuju po životní pojistce někdo jiný, kdo se řídí stejným faktem, to může považovat za neakceptovatelné, a proto raděj auto neřídí, resp. ze strachu nevychází z domu
Dokonce si troufám tvrdit, že chápu proč ji odstranit.zakažme tedy auta, i kdyby to zachránilo jen jediný dětský život! tak nějak jsi to myslel?
18.5.2014 10:03
pavlix | skóre: 54
| blog: pavlix
18.5.2014 14:27
pavlix | skóre: 54
| blog: pavlix
19.5.2014 05:24
pavlix | skóre: 54
| blog: pavlix
takže bych si troufl doufat, že na mém přijímači chyba neníTvrdit to můžeš, ale na realitě to asi nic nezmění.
16.5.2014 12:01
pavlix | skóre: 54
| blog: pavlix
Podle mě spočívá ten problém už v tom, že byl vůbec tenhle mechanismus do udevu původně začleněn, tj. že na začátku povolili dávat síťovkám jména ze stejného prostoru jaký používá ve stejné chvíli i jádro.Není to moje originální myšlenka, ale věřím tomu, že problém spočívá prvně v tom, že udev síťovky nepojmenovává, ale přejmenovává, a že taková race condition vůbec existuje. Samozřejmě by to znamenalo, že se udev bude moci registrovat vůči jádru jako služba, která může mluvit do pojmenování síťovek, nikoliv jen opravovat stav ex post.
Osobně mi nepřijde užitečné udržovat zpětnou kompatibilitu s něčím, co obsahovalo bezpečnostně rizikový race conditiona) jestli ti přejmenování síťovek způsobuje bezpečnostní problém, máš něco blbě. b) neměl bych to být já, kdo se má rozhodnout o tom, jestli je ten (imaginární) bezpečnostní problém tak závažný? c) spravuju stovky strojů, na všech jsou aspoň 2 rozhraní a ještě nikdy jsem se nepotkal s tím, že by přejmenovávání rozhraní způsobilo nějaký problém. Troufám si hádát, že podobnou zkušenost má dost lidí a že s tím 1% jsi přestřelil o několik řádů. Tohle "bezpečnostní riziko" je jenom zátěrka k tomu, aby se nemusely hledat jiné - rozumné - argumenty, proč rozbít >> 1% konfigurací
Kdyby si lidi bejvali pojmenovali síťovky na něco jinýho než ethXTak si to shrňme: nejdřív byly síťovky pojmenované ethX a pokud vím, moc se s tím hnout nedalo. Pak přišel udev s tím, že lze zařídit persistenci jména ethX podle MAC adresy (což na slušném hardware není potřeba) A teď chceš použít argument "Kdyby si lidi bejvali pojmenovali síťovky na něco jinýho než ethX"? To je vtip, že jo.
a to si furt ještě nejsem tak jist, jestli skutečně mají problém i dnesTeď zrovna řešil kolega, že se mu díky téhle bezva věci přejmenovala síťovka a nenajela VPN. A zbytečně upravovat konfigurace serverů jenom kvůli tomu, že se nějaký pípus rozhodl napáchat co největší bordel, je problém sám o sobě.
a to si furt ještě nejsem tak jist, jestli skutečně mají problém i dnes, jestli si zas někdo jen nechtěl kopnout do udev/systemd...ano, skutečně máme problém i dnes cirka před dvěma měsícema jsem řešil aktualizaci testu, který byl tuším před pěti lety napsán s tím, že naše prostředí zaručuje, že každý systém má alespoň jedno ethernetové rozhraní a je čistě nainstalovaný, takže prostě natvrdo vzal eth0 zjistil jsem, že s "predictable" names nejsem schopen udělat jednoduchý match typu [ethX nebo emX nebo enXněco], protože to "predictable" jméno je totálně nepredikovatelné, vůbec nevím, co se v něm může objevit, takže jsem tam musel přidat funkci, která mi to jméno zjistí jistě, teď se dozvím, že to byl prasácky napsaný test a jánevímco - ale já bych se raději dozvěděl, proč by takový test nemohl fungovat beze změny "až do konce věků", tzn. dokud je mi prostředí schopno plnit tu podmínku uvedenou výše (bez ohledu, jestli k tomu rozhraní vede fyzicky UTP kabel nebo jestli je celé virtualizované)?
ls /sys/class/net | head -n 1).
Na druhou stranu chápu, že ses mohl zlobit, že ty predictable names tvoje distribuce povolila jako default...
Takový problémy bych fakt chtěl mít.chápu, že hladomor v Africe to nevyřeší, nicméně údržba testů je jedna z věcí, za které mě zaměstnavatel platí kdybychom je nemuseli neustále přepisovat kvůli věcem tohoto typu, měli bychom více času na jiné věci, které by mohly zaměstnavateli přinášet větší užitek, anebo by třeba zaměstnavatel nepotřeboval těch lidí tolik další implikace si laskavý čtenář doplní sám
Ani jsi nemusel psát tu funkci, stačilo zakázat predictable names.to je něco jako "na toho vrabce nepotřebuješ kanón, můžeš použít raketu s jadernou hlavicí"? - aneb znáš nějaký způsob, který by nevyžadoval reboot anebo zásah do nastavení instalátoru?
Ačkoli ta funkce bude asi úplně jednoduchá (něco jako ls /sys/class/net | head -n 1).
hm, kolik si vsadíš na to, že z toho potřebné rozhraní vždy vyjde jako první?
aneb znáš nějaký způsob, který by nevyžadoval reboot anebo zásah do nastavení instalátoru?No, tak rebootem jsi tam vůbec tu změnu dostal, ne?
hm, kolik si vsadíš na to, že z toho potřebné rozhraní vždy vyjde jako první?Asi tolik, kolik vsadim na to, že kernel driver přidělí
eth0 té správné síťovce. Takže obecně bych nevsadil nejspíš nic a na mém hardware určitě nic...
he? vo čem to meleš ty vořechu, já tam žádnou změnu nedostával, to je default po instalaci ...aneb znáš nějaký způsob, který by nevyžadoval reboot anebo zásah do nastavení instalátoru?No, tak rebootem jsi tam vůbec tu změnu dostal, ne?
Asi tolik, kolik vsadim na to, že kernel driver přidělí eth0 té správné síťovce.
kontrolní dotaz: a která je podle tebe "ta správná"?
he? vo čem to meleš ty vořechu, já tam žádnou změnu nedostával, to je default po instalaci ...Takže tobě vadí reboot na nové instalaci? Nicméně jestli je změna nastavení problém, ať už z jakéhokoli důvodu, tak jsi to vyřešil správně tou funkcí...
kontrolní dotaz: a která je podle tebe "ta správná"?Co já vim? Nevím, co tam testuješ, to musíš vědět ty...
Takže tobě vadí reboot na nové instalaci?ano, vadí, musel bych v tom testu řešit, jestli je to běh před rebootem nebo po něm, což kromě složitosti kódu testu ještě navíc znamená, že se nedá pustit ve stateless prostředí, nemluvě o zdržení, a nemluvě o tom, že to neměl být integrační test řešící zároveň vlastnosti udevu a jánevímco ještě ocaseované přes různé verze na kterých může běžet, nýbrž KISS na jednu jedinou věc, která se má chovat všude stejně
no, beru, že jsem se nijak moc nerozkecal, co to dělá (sám už pořádně nevím, bo teď jsem to ani neřešil, teď jsem řešil jen to jméno síťovky), nicméně z formulace "alespoň jedno ethernetové rozhraní", dále doplněné o "bez ohledu, jestli k tomu rozhraní vede fyzicky UTP kabel nebo jestli je celé virtualizované", by se snad dalo odvozovat, že "ta správná" je jakákoliv, nepotřebuju nijak zaručovat, která to bude, stačí, že nějaká to budekontrolní dotaz: a která je podle tebe "ta správná"?Co já vim? Nevím, co tam testuješ, to musíš vědět ty...
Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single "eth0" interface. With this new scheme in place, an administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that "eth0" was the right name.
A pak take byly sitovky na ISA a PCI slotech, a obcas nejaka odesla, a bylo prekvapeni ze po vymene je to najednou eth1.
Tehdy, kdyz jsem to poprve videl, jsem vubec nechtel uverit tomu, ze nekoho napadlo ukladat nejak automaticky MAC adresy sitovek, co nahodou na vyzkouseni strcim do pocitace, nekam do /etc .
Taky mi to přišlo trochu zvláštní, nicméně jsem to velmi ocenil v počítači se dvěma síťovkami téhož typu.No, ja se stabilitou defaultnich kernelich jmen nikdy problemy nemel, a to jsem mel jednu dobu pocitac s asi 15 sitovkama trech ruznych typu.
Navic se zajimave ze uplne stejne pravidlo plati pro uplne vsechen HW bez vyjimek.Nevim jak na AIX hardware, ale na PC jsou AFAIK sitovky a harddisky jedny z mala zarizeni, ktera obecne maji v hardwaru kusove unikatni identifikator, takze na jina zarizeni toto pravidlo moc dobre pouzit nejde.
13.5.2014 12:53
Josef Kufner | skóre: 70
13.5.2014 13:03
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
13.5.2014 13:58
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
28.3.2016 16:23
msk | skóre: 27
| blog: msk
Nerozumiem komu tato kokotina pomoze. Kto ma viac sietoviek, uz si ich prehadzovanie davno osetril podla MAC. Kto nema, takuto imbecilitu k zivotu vobec nepotrebuje.
Za posledne roky sa mi uz par krat stalo, ze upgrade systemu priniesol nejaku komplikaciu. Na toto som minimalne u Debianu nebol vobec zvyknuty a taketo chovanie ocakavam prevazne na windows ... ale bohuzial, doba sa meni a linux sa vdaka mrdkam ako systemd a udev posuva milovymi krokmi do rovnakej prdele ...
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.