Dotaz: Jak nastavit po restartu ip route

[otula]

Aktualizoval jsem po nějakém roce jistý server a nejsem schopen přijít na to, jak po startu systému spustit automaticky nějaký příkaz. Dříve to bylo prosté a jednoduché – stačilo ho zadat do /etc/rc.local. Nyní to nejde a po celém internetu je spousta dalších zoufalců, kterým se to nedaří. Obecně se radí vytvořit si pro systemd službu rc-local.service, jenže ono její spuštění (pokud rc.local obsahuje požadovaný příkaz) jaksi během bootování neprojde (pokud je rc.local prázdný, spuštní proběhne v pořádku). Přičemž pokud danou službu zkusím nastartovat ručně po přihlášení, tak se normálně nastartuje (i s požadovaným příkazem v rc.local). Ale automatické spuštění selže.

Nejvíce mne tedy momentálně trápí automatické spuštění příkazu

ip route add a.b.c.d/e via w.x.y.z dev ethX

případně jiný způsob, jak docílit stejného výsledku.

Používám aktuální archlinux, síť spouštím přes systemd-networkd.service.

---

---

Odpovědi

[MP]

Nevim v cem ma arch definovanou sit, ale v klasickym /etc/network/interfaces se to delalo pomoci "up ip route...". Pokud je sit nadefinovana jako systemd unita (.network, .netdev atd), tak se da pouzit parametr Gateway u konkretniho interface/site.

[otula]

Nebude problém v tom že se rc.local spustí a ještě neexistuje zařízení dev ethX ?

Já jsem na začátek skriptu musel dát příkaz pro čekání několik sekund pak mi to funguje.

Skus k příkazům přidat přesměrování do souboru aby jsi si mohl přečíst na čem to zhavarovalo.

[otula]

Petře, děkuji, bylo to ono. Přihodil jsem na začátek sleep 15s, zkusil pro jistotu dvakrát zrestartovat, a pokaždé to naběhlo OK.

[Michal Kubeček]

Řešení race conditions pomocí náhodně přidaných sleepů je cesta do pekel. Když potřebujete něco spustit, až se to rozhraní objeví a bude nakonfigurované, tak si buď počkejte na příslušný event, nebo na to aspoň počkejte smyčkou. Vyhnete se pak nepříjemným a velmi obtížně debugovatelným překvapením v budoucnosti.

Jinak je IMHO chyba tohle vůbec řešit vlastním skriptem. Když už jste se jednou rozhodl svou konfiguraci sítě svěřit systemd-networkd, není dobrý nápad se v ní vrtat za jeho zády, ale měl byste tu routu přidat jeho prostřednictvím.

[otula]

Díky za info. Už jsem předtím zkoušel spustit ještě jiný příkaz, a i když jsem si vyjel celý strom posloupnosti a nechal umístit spuštění rc-local až za ten poslední, kam mne to pustilo, stejně se mi nespustil. Tak jsem dál laboroval s parametry toho .service skriptu, ale bez úspěchu. Takže ač není sleep ideální, dokáže pomoci ven z problému.

Každopádně máte naprostou pravdu, že nejkrásnější a nejčistší řešení tohoto konkrétního případu je to, co mi poradil Heron. Ačkoliv jsem hledal dost dlouho, nepodařilo se mi právě tohle nikde najít. Asi jsem nezadal správné parametry pro hledání. Všude jsou návody pro distribuce, které to řeší jinak. A v ArchWiki je nefunkční řešení (stejně jako v jiných situacích, kdy se na ni nedá moc spolehnout)...

[Heron]

No já se celkem divím, že tohle na archwiki není. Ač jsem uživatel Debianu, tak při hledání věcí týkající se zejména systemd, tak archwiki často poradí. (Pokud se nepletu, byla to první distribuce, která na sd přešla.)

Přidání statické routy bych tedy právě v této wiki očekával.

Ono to může být matoucí, protože systemd.network připouští víc způsobů nastavení téhož.

Můžete mít sekci [Network], kde se nastaví vše (tj Address a Gateway a DNS). Nebo taky můžete mít sekce [Address] a [Route] a mít to (tedy IP a GW) nastaveno ve dvou sekcích. No jenže sekcí [Route] tam může být víc a to včetně uvedení Destination - to ovšem nenastavuje default gw, ale routu pro danou sít. Takže se může plést nastavení default gw s nastavením statických rout.

Osobně si život zjednodušuju tak, že mám jednu sekci [Network], kde mám adresy a default gw a potom více sekcí [Route], kam si strkám statické routy. A nic se mi neplete.

Ukázka:

[Match]
Name=br0

[Network]
Address=xxx/29
Gateway=xxx

Address=192.168.xx/24

[Route]
Destination=10.0.0.0/24
Gateway=yyy

[Route]
Destination=10.8.0.0/24
Gateway=zzz

Ale chápu, že i samostatné sekce Address a Route mají svůj význam, protože tam toho jde nastavit mnohem víc.

[otula]

On to není jen problém ArchWiki. Včera jsem ze starého serveru kopíroval nastavení iptables (není nikam připojen, slouží jen na vnitřní síti, takže si už spoustu let v klidu běžel se zastaralým sw). A měl jsem jako jeden z parametrů -i ! eth1. To už ovšem nyní použít nelze. Na tom by nebylo nic až tak divného, kdyby v manuálových stránkách (aktuálního) iptables nebylo psáno: When the "!" argument is used before the interface name, the sense is inverted. Jenže on nemá být před interface name, ale ještě před parametrem -i.

Každopádně ještě jednou díky za radu.

[Michal Kubeček]

Tahle matoucí věta tam sice zůstala, ale jinak je tam (od roku 2008)

    [!] -i, --in-interface name

místo původního

    -i, --in-interface [!] name

[otula]

Jasně, mohlo mě to trknout, jenže zřejmě tím, že [!] stojí na začátku řádku, či tím, že manuálové stránky čtu jednou za x let a nejsem zběhlý v jejich syntaxi, mne to trklo až ve chvíli, když už jsem věděl, že to tak má být. Prostě jsem našel -i a přečetl si doprovodný text. To je jedno, každopádně jsem to nakonec vyřešil :)

[Petr Šobáň]

Jasně souhlasím s tím že pokud nastavuje síť pomocí systemd tak by i kompletní konfigurace měla být zapsána na jednom místě a né to přenastavovat v rc.local.

Jediné co jsem nepochopil proč rc.local není spuštěný až jako uplně poslední, pak by se nemuselo různě čekat vše by mělo už běžet....

[Michal Kubeček]

Nejsem znalec systemd (spíš se snažím zkoumání jeho detailů v mezích možností vyhýbat), ale nejsem si jistý, jestli jde takový okamžik v jeho koncepci dost dobře definovat. A pokud ano, může to být o dost později, než byste čekal.

Nedávno jsem třeba narazil na to, že jsem potřeboval udělat crash dump s ladícím jádrem, problém byl snadno reprodukovatelný, takže zdánlivě žádný problém. A byl jsem překvapený, že se dump se nevytvořil. Ukázalo se, že ve chvíli, kdy jsem chybu vyvolal, ještě pořád nestihla doběhnout služba, která při startu natáhne kdump kernel a v případě potřeby předtím k němu ještě vygeneruje initrd (pokud neexistuje). Takže by se vám klidně mohlo stát, že už se úspěšně nalogujete, napíšete pár příkazů a ta routa tam pořád ještě nebude. Případně na serveru už poběží služby, které na tu routu budou spoléhat.

IMHO není obecně moc šťastné spoléhat na nějaký "úplně nakonec" skript, ale je lepší si ujasnit, na čem konkrétně má váš skript záviset (a co má případně záviset na něm). Koneckonců i za starých dobrých časů před systemd šlo takové závislosti pro vlastní init script definovat. (Ale má to samozřejmě všechno smysl jen pro věci, které nelze zapsat do standardní systémové konfigurace.)

[pepe_]

Nezaručuju že to pojede naprosto všude ale :

A co si vytvořit pomocný script třeba

 

sudo touch /root/iproute.sh

sudo chmod +x /root/iproture.sh

echo 'ip route add a.b.c.d/e via w.x.y.z dev ethX' | sudo tee --append /root/iproute.sh > /dev/null

 

pak dát

 

sudo crontab -e

 

napsat tento řádek

 

@reboot root /root/iproute.sh

 

a uložit     (podle editoru , např ve vi   dát    :wq     ) .

 

 

Otestuj pak restartem.

[pepe_]

 

sudo chmod +x /root/iproture.sh            změnit na    iproute.sh

 

 

Po 2000 letech stále nefunguje editace přízpěvku ... (fuj)

[Michal Kubeček]

/root/iproute.sh

Po jednom takovém jako vy jsem kdysi zdědil systém. Všude neskutečný bordel, klíčové skripty rozházené v naprosto náhodně zvolených adresářích, člověk se musel bát cokoli smazat, jakákoli nevinná změna způsobila, že se někde úplně jinde něco sesypalo…

[pepe_]

Jj , máte pravdu. Systemd jde ale stejným směrem že se nikdo nevyzná v té evoluci takže je to vlastně trendy.

[randy]

Pokud používáš systemd-networkd.service, tak si routu nastav přímo v .network souboru (kde máš definici adresy, default gw apod.). Stačí přidat sekci:

[Route]
Destination=a.b.c.d/e
Gateway=w.x.y.z

a je to.

[otula]

Super, mockrát díky, tohle je pro tento případ krásně čisté řešení.