Dotaz: "ip route add 0/0 dev ppp0 table 200" pomocí NetworkManager nmcli?

[Franta Hanzlik]

Zdravím Linux guru,
Fedora zařízla spolehlivé network-scripts-y, takže se snažím nakonfigurovat multihome router pomocí NetworkManager nmcli - a připadám si jak debil/že vynalézám kolo. Dokumentace na stránkách NetworkManager (jestli jsou na https://networkmanager.dev/) slabá, jinde na netu jsem také nenašel nic extra přínosného.
Tak volám o pomoc - nevíte, jak v NetworkManageru (pomocí jeho nmcli apod.) realizovat jednoduché přiřazení routy do routovací tabulky, konkrétněji třeba to, co v ip zapíši příkazem:

ip route add 0/0 dev ppp0 table 200

Jediné, co jsem k tomu našel, je, že to NetworkManager vůbec neumí a musí se to řešit přes jeho dispečer skripty - nevím, jestli to není vtip ;)
Můžete mne někdo nasměrovat? Díky předem, Franta H.

Odpovědi

[X]

nmcli modify "Tvoje DSL" +ipv4.routes "0/0" ipv4.route-table 200

Pet minut hledani..

[Franta Hanzlik]

Když už, tak:

nmcli con modify DSL +ipv4.routes "0.0.0.0/0" ipv4.route-table 200

- ale tohle nefunguje, routa se nevytvoří. IMO problém je v tom, že nmcli neumí to "dev ppp0" - naprosto standardní volbu "ip route". Někde jsem také našel doporučení zadat libovolnou fake adresu GW, ale to mi také nefunguje. Zdá se mi, že routy na point-to-point linky NM nepodporuje. Nebo špatně čtu/hledám - nevylučuji, protože s NM/nmcli zatím dost tápu. Ale proto se tu ptám ;)

[Andrej]

systemd-networkd

[Franta Hanzlik]

Díky za váš čas. Jo, na tohle doporučení jsem také narazil, a řešení tam bylo popsáno úplně stejně obšírně. Takže se asi klidně může stát, že se zaseknu někde o kousek jinde - přiznávám, že systemd-networkd jsem ještě nepoužil a neznám jej, a obecně mi při čemkoliv, co začíná systemd, naskakují už patnáct let pupíny - beru to jako věc, která se se.e do všeho, ale nic neumí pořádně. Údajně ani Bulánky... Už to jde používat bez systemd-journald?

[Andrej]

“beru to jako věc, která se se.e do všeho, ale nic neumí pořádně” == ”nemám tušení, která bije, a musím se tím náležitě pochlubit”

…přiznávám, že systemd-networkd jsem ještě nepoužil a neznám jej…

Manuálové stránky na Fedoře fungují? Co jsem se posledně díval, fungovaly.

Už to jde používat bez systemd-journald?

Proč by chtěl někdo používat jakýkoliv systém bez rozumně fungujícího správce logů, který má (konečně!) korektně synchronizovaný čas mezi různými zdroji logů, indexování a vyhledávání, kompresi, podpisy a ochranu před manipulací s logy, atd. atp.?

Strach z „neznámého“? Ten by byl omluvitelný možná v roce 2010. Dnes nemáme rok 2010.

Je neuvěřitelné, jak se dodnes vynořuje to uvažování z divokých devadesátých let, podle kterého je normální spustit službu z rozbitého Bash skriptu spuštěného kdovíčím a kdovíodkud, samozřejmě, že pod rootem a bez “hardeningu”, jak jinak; skript pak možná selže, možná občas ne, ale žádný problém, nikoho to nesere, hlavně když od toho nikde nebude vidět žádný stav ani log, a když náhodou jo, tak logy nebudou správně prokládané v čase vůči logům od zbytku systému, nebude to umět reagovat na uspání / probuzení / změnu nastavení sítě / jinou zásadní událost v systému…

No ale furt se najdou lidi, kteří budou tvrdit, že tenhle↑↑↑ stav věcí byl přijatelný, zatímco systemd prý jako fakt ne.

systemd FTW.

[Franta Hanzlik]

Vývojář systemd? Dík za pohled/názor z jiné strany. Já nejsem a nepotřebuji být aktivista, chci, aby věci fungovaly jak potřebuji - a pokud to tak je, nemá smysl (každá změna něco stojí) je měnit. A pokud to tak není, je třeba nasadit něco jiného - jak prosté, milý Watsone... Není v tom žádný strach z neznámáho, prostě zásada držet se věcí které fungují a KISS platí a platilo vždy. Jestli jste měl třeba s rsyslogd nějaké problémy nebo potřeboval nějaké fíčury journald, tak beru jako logické, že jste sáhl po něčem co to řeší. Já preferuji rsyslog, chci textové logy a nepotřebuji mezi tím mít nějaký oslí můstek. Nápodobně bash scripty - na to, co jsem potřeboval, fungovaly skvěle, jsou čitelné, univerzální a maximálně flexibilní. A samozřejmě, nevýhody mají také, stejně jako cokoliv jiného vč. systemd.

Co se týká systemd-networkd - manuálové stránky jsou, jistě. Ale nějaké srovnání s NetworkManager-em (který beru jako současný a komplexní systém správy sítě), které by odůvodňovalo, proč bych jej měl preferovat, jsem tam nenašel. Takže zatím mi jeho nasazení (kromě nějakých triviálních věcí, kam se nainstaluje sám a stará se o nějaký svůj jeden interface) nedává smysl. Ale třeba mne někdo přesvědčí o nějakých zásadních výhodách... Tohle vlákno to zatím není ;)

[Andrej]

Není v tom žádný strach z neznámáho, prostě zásada držet se věcí které fungují…

Nefungují. (Přesněji řečeno: nefungovaly. Proto vznikl systemd.)

Nápodobně bash scripty - na to, co jsem potřeboval, fungovaly skvěle, jsou čitelné, univerzální a maximálně flexibilní.

Tak určitě. Dobrý vtip.

Ale třeba mne někdo přesvědčí o nějakých zásadních výhodách...

A třeba ne. Není úkolem ostatních přesvědčovat někoho o výhodách té či oné technologie. Proč by to dělali?

[GeorgeWH]

Proč by chtěl někdo používat jakýkoliv systém bez rozumně fungujícího správce logů, který má (konečně!) korektně synchronizovaný čas mezi různými zdroji logů, indexování a vyhledávání, kompresi, podpisy a ochranu před manipulací s logy, atd. atp.?

Ako riesis roznu retenciu pre rozne typy logov? Napr. auth logy chcem drzat 1 rok, nejake aplikacne logy pol roka a ostatne 1 mesiac?

[Andrej]

Rizikový nápad. Proto nic takového neřeším.

Když jeden chytrolín tuhle nedávno obešel můj SSH tarpit, nebýt systemd-journald, byl by mi zaplnil dost rychle celou kvótu logy. Nemluvě o tom, kdybych se pokoušel takové logy udržovat rok. Naštěstí systemd-journald situaci zvládl. Historii (konec řidších logů před začátkem „útoku“) jsem pak už dohledal v Btrfs snapshotech.

Což zároveň odpovídá na původní dotaz: Dokud budou logy dost řídké, budou se ve snapshotech záloh překrývat a doba jejich skladování jaksi odpovídá algoritmu pro „ředění“ a mazání zálohovacích snapshotů. Jakmile začnou být logy hustohusté (a tím pádem zároveň nepříliš zajímavé a dost rychle taky škodlivé), kus se jich (naštěstí, díky systemd-journald) do snapshotů nedostane a zbude díky tomu místo pro smysluplnější data.

[fero]

jj nejlepss jsou totiz logy ktere neexistuji nebo nejdou precist, protoze je dojebany nejaky binani blob ...

Mimochodem, jak ze se cte ten blob kdyz jediny co funguje je vi?

[Peter Golis]

Tým binárnym blobom myslíš zrotovaný texťák ktorý sa ti po rotácii skomprimoval, alebo niečo na spôsob súborového systému? Alebo chceš tvrdiť že logy nahrávaš v textovej forme priamo na ďalekopis, tlačiareň alebo na pásku bez HW kompresie?

Povedz o tom niečo ...

[GeorgeWH]

Co si ty za kokota, ze stale musis zacat bliakat totalne nezmysly? Ale ze za kazdym.

[Peter Golis]

Skús mi vysvetliť v čom sa mýlim. Môžeš začať tým, či máš popis štruktúry daného blobu, aj so zdrojovým kódom.

Ale skús to bez expresionizmov ak to zvládneš.

[Heron]

Na binární logy existuje journalctl.

[Peter Golis]

A sú k tomu zdrojové kódy, alebo je to len blob bez popisu s ktorým sa nič nedá robiť?

[Andrej]

Mimochodem, jak ze se cte ten blob kdyz jediny co funguje je vi?

O jaké situaci je tady řeč? Po apokalypse? Proč by měl fungovat jenom paskvil vi?

Počítač se nedá nabootovat z média s live systémem? Proč?

Úložiště se nedá připojit k jinému počítači? Proč?

[Franta Hanzlik]

Vyřešeno - nakonec poradili ve Fedořím maillistu - příkaz 'nmcli con modify DSL +ipv4.routes "0.0.0.0/0 table=200" je správný, ale já jsem nepromítl změny následným 'nmcli device reapply ppp0' - částečně také proto, že do DSL.nmconnection přidané řádky

route1=0.0.0.0/0
route1_options=table=200

se mi jevily jako pitomost - ale chytrý NetworkManager si tam evidentně to "dev ppp0" (a i další odvoditelné routy) přiřadí sám.