Restartovat síť v Debianu není taková sranda, jak by se mohlo zdát. Když to uděláte špatně, odříznete se třeba od serveru.
Před čtrnácti dny jsem na Strahově v rámci Střediska unixových technologií (SUT) přednášel o Debianu. Na konci hodinu a půl trvajícího povídání a ukazování přišly na řadu dotazy. I přišel jeden nevinně vypadající: „Jak se v Debianu restartuje síť?“ Vypadá to triviálně – stačí restartovat init skript. Ale ona to taková legrace není, protože to je zastaralý a poměrně nebezpečný způsob. On ten init skript taky varuje:
# /etc/init.d/networking restart Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces ... (warning).
Vznikla kolem toho diskuse, ve které mimo jiné zaznělo: „Tohle jsem nedávno zkusil a skončil jsem bez připojení na server. Naštěstí mašina leží ve vedlejší místnosti.“ Rozhodl jsem se o tom později zjistit víc a ukázalo se, že to trápí opravdu hodně uživatelů a skutečně může nastat nepříjemný problém.
Výše uvedený způsob restartování nám byl dobrý v době, kdy byla konfigurace sítě přísně statická. Síťová rozhraní se nahodila při zapnutí stroje a při vypnutí se zase shodila. Jenže! Mezi tím přišla doba hotplugová, kdy jsme zvyklí připojovat a odpojovat za jízdy haldu různých udělátek, včetně síťových karet, ethernetových kablíků, USB Wi-Fi donglů a jiných krabiček. Systém tedy generuje myriády událostí a reaguje na ně. To se týká i sítí. Před několika lety o tom psal Adam Přibyl v článku Jak události mění Linux.
Pokud restartneme „celou síť“ (čti: všechna rozhraní naráz) pomocí init skriptu, systém nejprve rozhraní shodí a poté je začne nahazovat podle konfigurace v /etc/network/interfaces
. Ta může vypadat třeba následovně:
auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet dhcp
V takové situaci se nahodí loopback, protože má příznak auto. Ovšem pak nastane problém – eth0 se vám nezapne, protože ten reaguje až na hotplug událost – v tomto případě zasunutí kabelu. A jste bez konektivity a běžíte do serverovny, či v lepším případě hledáte heslo k managementu. Proto je tento způsob považován za neaktuální, nebezpečný a tudíž nedoporučovaný.
Otázka dne ale zní: jak to tedy uděláme správně?
Potíž je, že ani sami vývojáři na to nemají odpověď. Správná cesta totiž vlastně neexistuje. Někdo radí volat to přes příkaz service
nebo invoke-rc.d
, ale to jen opět spustí původní init skript, takže si nepomůžeme. Pokud si přečtete mailing listy Debianu (jeden za všechny), zjistíte, že „oficiální přístup“ k věci by se dal shrnout jako: „Restartovat síť jako celek nepotřebujete, restartujte jednotlivá zařízení.“
Doporučuje se proto shodit a nahodit jen konkrétní rozhraní. Přibližně takovým způsobem:
# ifdown eth0 ; ifup eth0
Nedoporučuje se používat parametr -a
(jako all, všechna), protože ten vyústí ve stejný problém jako u init skriptu. Pozor taky na radu nejdřív zavolat na init skriptu stop a pak start. Init skript v takovém případě opět jen zavolá ifup -a
.
Příjemné to není, protože (kromě zmíněných problémů) to zmate spoustu uživatelů, kteří jsou na tenhle postup prostě zvyklí (jako já). Zdá se mi ale, že rada restartovat jen konkrétní rozhraní, je poměrně logická. Píše o ní nakonec i dokumentace k Debianu. Hlavní problém tak nakonec vidím v tom, že vám tyhle obecné informace nepodá samotný init skript. Stačilo by připsat informaci: „Správný postup je ifdown eth0; ifup eth0“.
[2] presne tak, pokud je konfigurace manualni, coz u serveru je dost castu, tak
uprava na auto je v podstate nutna
http://wiki.debian.org/NetworkConfiguration#Configuring_the_interface_manually
[1]. K čemu otvírat duplicitní, když už na jeden je v článku odkazováno?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565187
Rek bych, ze to je "debian-like" problem, trebas gentoo ma script (net.ethX) pro kazdy zarizeni extra (on je to teda symlink), takze vsechny najednou ani restartnout nelze (respektive lze, ale musi si to user naladovat do radky nebo do scriptu).
BTW: Co ma co sitovka cekat na zasunuti kabelu, to je prece naprosta blbost - specielne by default. Nehlede na to, ze takovouhle udalost to v pripade stabilniho pripojeni nevygeneruje nikdy. To ma smysl u notesu, kterej nosim sem a tam.
[6] Neni to blbost. Je to dokonce vlastnost prevzata z "velkych" sitovych technologii. Sitovky na link cekaji uz strasne dlouho. Posledni ktera to nedelala byla naka 3c509 jeste do isa.
Vyhody cekani na link resp. jeho signalizace jsou zrejme. Vim kdy je protistrana nahore,uspora energie kdyz link neni, rychla kontrola spojeni podle linku atp. Jinak predchozi stav byl takovy ze clovek premyslel jestli ma spravne driver,nastaveni sitovky,hub nebo kabel a vubec link nevidel. Nebylo zrejme kdy sitari treba uz opravili l2 cast site.
Signalizace linku je supr dobra vec. To ze to evidentne splacal nejaky jouda je vec jina. Dynamicky konfigurace site na serverech jsou mor kterej je treba vymytit pri instalaci.A zrovna debza ktery bezi na spouste serverech by to uz mohl mit davno vyreseny. Uzitecna by taky byla opsna jestli chci shodit a nahodit link pri restartu site nebo ne. V rade situaci se to hodi, ale v rade zase ne kdyz clovek prenastavuje jen na ip a potrebuje mit ethernet zivej jako backdoor;)
Remote management na malem serveru je zaklad. Bez neho ani ranu.
podle me "allow-hotplug" nema nic spolecneho se zapojovanim kabelu (alespon ne typicky) - tohle proste nahodi sit ve chvili kdy se inicializuje modul a najde podporovanou a funkcni sitovou kartu. Ten event (nevim jaky, source ted zkoumat nebudu :)) se urcite generuje pri vice akcich, napriklad pri zapnuti wifi pres tlacitko, ale nestalo se mi, ze by server chtel "vycvaknout/nacvaknout" kabel.
Horsi je spis ukladani state tech interfacu - pokud mate v konfiguraci chybu, napriklad spatnou masku, pak se interface nenahodi, ale ifupdown si ulozi stav started - a dalsi start uz nezabere bez stop. Pokud nektery interface rusite, tak ho zase musite shodit nez ho z konfigurace odstranite (jinak na nej snad networking restart ani nesahne).
Udelat prosty "reload" zkratka neni jednoduche, u serveru mi prijde skoro lepsi udelat si to rucne - napriklad pres rc.local. Namitnete, ze je to prasarna, ale v tomhle pripade bohuzel celkem opravnena. Mnohem radeji budu IP adresu menit pres
# ip addr add ...
# ip addr del ...
a pak poedituju jeden soubor, nez riskovat hotplug/networkmanager a dalsi vymysly co se dneska by default objevuji v distrech.
Asi nejlepe vyresene to melo gentoo (aktualni stav nevim, uz jsem ho par let nepouzil) - konfigurace prehledna, dobre dokumentovana, bez nutnosti editovat toho moc - ale zaroven slo nastavit vsechno. Dalo se pouzit nekolik metod (backendu) pro manipulaci se siti, melo to hezkou integraci wpa_supplicant/hostapd apod., a dalo se definovat napriklad v jakem poradi se sitovky nahazuji (nezavisle na sobe), takze loopback se nahodil na zacatku a verejna adresa treba az na konci kdy funguji sluzby nutne pro provoz webserveru, ktere ale potrebuji alespon nejakou sit...
Samozrejme v dnesni dobe je na vsechno klikator (treba NetworkManager), ale nezazil jsem ze by nekdy opravdu spolehlive fungoval. Kazda distribuce ho ma ohnuty jinak a je normalni ze nektere funkce jsou v Gnome UI a nejsou v KDE UI nebo naopak, nebo nektere pluginy proste nefunguji nebo funguji jen kdyz se dokonfiguruji z radky...
Navic nemam vubec chut ucit se dbus/policykit/devicekit a dalsi nesmyslykity jen proto, abych nastavil sit bez GUI.. trochu prehanim, ale moje nocni mura je ze se struktura v /etc zmeni ve windows registry a uz si nepoeditujeme jednoduse nic.
a jeste jeden dodatek - ifdown eth0 a ifup eth0 udela uplne to same (s eth0) jako /etc/init.d/networking restart - takze nevim cim si pomuzu. Leda by ten stroj mel sitovek vic a ja si s nim povidal po eth1. Casteji ale ma server sitovku jednu, nebo je to ta po ktere si s nim povidame...
[11] A v souboru /boot/grub/grub.cfg
je co? To není textová konfigurace Grubu 2? Samozřejmě je. Ve většině distribucí se tento soubor vytváří automaticky podle konfigurace vedle, ale není problém si to změnit a psát si ten konfig ručně. Doporučuji si o tom něco přečíst a nešířit tolikrát šířené nesmysly.
Podle mě už doba hotplugu v debian/interfaces odeznívá. Buď chci statickou konfiguraci,
pak žádný hotplug nepotřebuju, nebo chci dynamickou konfiguraci a plnohodnotný network
management, pak je lepší volbou NetworkManager.
@Jan Schermer: Já to za prasárnu nepovažuju. Když vím přesně, co chci, aby se pro konfiguraci
sítě spustilo, tak proč to nenasázet do skriptu. Skript může klidně zahrnovat příkazy typu 'ip address flush scope global' pro odstranění adres, které už jsme na rozhraní přidali.
[16] Pokud mam naky svuj maly exoticky system tak je to v pohode. Ale kdyz mam tisice masin a team rekneme 50-100 lidi+sberatele certifikatu, tak je nutne pouzivat standartni veci. Jinak se neda spravovat hromada masin.
A zjistovat ze se system chova jinak po bootu a jinak po restartu network - mit z toho boleni hlavy nechci. Kdo ma zakaznikovi potom vysvetlovat ze banalni rekonfigurace site se protahla na trikrat tak dlouho kvuli tomu ze nejaky kokos si udelal vlastni skript mimo system. Tim spis pokud system jako celek podleha nejake certifikaci. Podobny bordel muzu udelat na kazdem i neunixovem systemu ze nebudu respektovat jeho strukturu. A velice brzy se mi to vymsti napriklad pri upgrade.
Jo kde jsou ty doby kdy jsem jako malej fakan ve slackwaru cpal vsechno do rc.local...;)
[17] To máš naprostou pravdu. Ale já jako vývojář takovéhoto standardního řešení (NetworkManager) musím být ve slovech o něco opatrnější :). Navíc mě baví hodně experimentovat. U řešení pro tisíce mašin už se ale očekává úplně jiný komfort,
jako třeba checkpointing funkční síťové konfigurace a návrat k němu při ztrátě
konektivity.
„Kdo ma zakaznikovi potom vysvetlovat ze banalni rekonfigurace site se protahla na trikrat tak dlouho kvuli tomu ze nejaky kokos si udelal vlastni skript mimo system.“
Nadávat na zákazníky je sice hezké, ale nikdo neříká, že se zákazníci nemůžou obrátit na někoho ochotnějšího :).
„Tim spis pokud system jako celek podleha nejake certifikaci.“
Teď jde o to, jestli ta certifikace je k něčemu nebo jen pro srandu králíkům. Když pak člověk zjistí, že něco bylo před pěti lety certifikováno a teď se to teprve implementuje
či opravuje, aby to začalo fungovat, tak pak neví, k čemu ta certifikace vlastně je.
„Jo kde jsou ty doby kdy jsem jako malej fakan ve slackwaru cpal vsechno do rc.local...;)“
V jednoduchosti je krása :).
[18] Checkpointing nepouzivame. Alespon v nasem oddeleni. Tuto technologii jsem videl nasazenou ale u malych isp a u naseho providera na velkych cisco kramech.
V pripade pruseru se pouzije druha management pristupova sit. V nekterych pripadech se i vylozene vola vzdaleny stroj pres klasickou telefonni linku kdyz neni zbyti.
Zakaznici se na nikoho ochotnejsiho nemohou obratit protoze:
- Vendor lock;)
- Nedodrzeni standardu a procedury se tresta financne pripadne vyhazovem
- Ve velke korporatni sfere je nekdy lepsi nedelat nic nez byt prilis ochotny. Clovek ma urcite terminy na urcite projekty,zasahy a nemuze se zabyvat telatkem s nestadartni konfiguraci. Hraju si doma nebo na novych resenich pro freenet. V byznysu nema bastl co delat.
Muj osobni nazor je ze certifikace je pro srandu kralikum. Ale musime mit tyhle blbosti abychom se vubec ziskali podporu od dodavatele a taky ruzni bezpecaci a auditori si prijdou na sve. V pripade pruseru se vsechny tyhle papiry hned vyndaji. Nikoho uz potom nezajima ze v nakym cesku lehlo pul mobilni site.
Nicmene jsem toho nazoru ze certifikace by se mela opirat uz o realne referencni reseni a ne nejake natahane ikonky ve visiu a hromadu papiru.
Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. GNU/Linuxem a Unixem obecně se zabývá již více než deset let a věnuje se především jeho nasazení v počítačových sítích a bezpečnostní politice. Zde bloguje o Root.cz, Linuxu, internetu a světě kolem sebe.
Přečteno 112 292×
Přečteno 89 765×
Přečteno 73 162×
Přečteno 58 109×
Přečteno 54 435×