Netplan hat keine hook scripte wie interface an batman-adv binden?


#1

Moin

Ubuntu 18.04 LTS setzt ja für die Netzwerkkonfiguration auf netplan.io. Das etablierte /etc/network/interfaces geraffel wurde abgeschafft. Ich schaue mir das gerade zum ersten mal an, und sehe es eigentlich auch als deutlich angenehmeren Konfigurationsansatz, was ich aber vermisse sind die hook-scripte, die ich vorher problemlos setzten konnte. (pre-up, post-down etc.)

Wie würdet ihr hier ein Interface in batman einbinden?


#2

SystemD Services erstellen die dann als require
die network devices angeben.

Bei einem Ubuntu upgrade bleibt aber die alte
Konfiguration bestehen.

PS: netplan erstellt systemd services


#3
sudo apt-get install ifupdown

und der Schmarn ist gegessen, dann kannst du wieder ganz normal die interfaces-Datei verwenden. Ich verstehe diese Leute bei Canonical nicht. Immer anders immer komische Dinge bauen. Eine Liste von gescheiterten Projekten: UbuntuOne, Unity, Mir, Ubuntu Phone.

Die nächsten Einträge werden wohl netplan und das Snap-Container-Format oder wie das heißt.


#4

Gar nicht. Derzeit erscheint mir der einzig valide Installationweg von 18.04 LTS ein Upgrade von 16.04 LTS zu sein. Ansonsten: was @MPW sagt.


#5

Ich habe mir jetzt 3 mal

https://netplan.io/faq#example-for-an-ifupdown-legacy-hook-for-post-uppost-down-states

angeschaut… und habe nicht den Eindruck, mit dem erworbenen Wissen etwas effektiv selbst bauen zu können.

Warum schaffen die es nicht, einfach ein Beispiel zuliefern “ifup/ifdown als /etc/network/interfaces” -> "folgende exakte Dateien samt directory-Namen.
(Es gibt dazu noch nichtmal was im Ubuntu-Wiki, da wird stumpf nur mit einem einzigen Link auf das andere Projekt verwiesen. So dreist habe ich das bei Canonical noch nicht erlebt bislang.)


#6

Weil bspw. das systemd-networkd Backend von Haus aus keine Hooks unterstützt. Dazu verwendete Ubuntu bislang networkd-dispatcher, der sich per dbus an diverse Events klammert.

Was nicht von allen Lösungen unterstützt wird kann man schlecht abstrahieren.

Warum also nicht einfach bei der Lösung die funktioniert bleiben?


#7

Daraus könnte man jetzt eine Canonical- oder eine Systemd-Debatte forken…


#8

Nun tust du gerade so als ob ich keine Erklärung geliefert hätte. :disappointed:


#9

Mir ist gerade unklar, welche Du hier meinst; ifupdown? In dem Falle stelle ich mir diese Frage auch. That said, komme ich mit einem aus 16.04 gezogenen 18.04 recht gut aus (wobei ich bislang nicht mehr gemacht habe damit als RT4 in hinreichend aktueller Version zu installieren).


#10

Ich habe halt gestern Bedarf für zwei neue VMs gehabt, die eigentlich “nur wenig aktuell relevantes” tun müssen. Daher die Entscheidung, da mal ein Iso von 18.04 einzulegen, um sich mit dem Ding nun endlich mal vertraut zu machen.
Details erspare ich uns hier mal, weil offtopic im Thread… aber nachdem ich dann die Config für die Failover-IPs in diesem neuen netplan-yaml hatte kam die Frage: Und wenn ich jetzt noch ein batman dranhängen wollte an eine der Bridges, wie täte ich das (ausser ganz, ganz dreckig über restartende systemd-dienste)


#11

Ich habe eigentlich einen hohen Automatisierungsgrad erreicht (mit serverless puppet, was ifupdown-Schnippsel in interfaces.d ablegt), insofern erschließt sich mir nicht, wozu ich mich mit der netplan-Totgeburt auseinandersetzen soll. Es macht Dinge erst einmal bestenfalls nur »anders«, deckt augenscheinlich nicht alle administrativen Belange ab — aber ist bestimmt 0,3 Millisekunden schneller beim Netzstart auf einem P3 mit 700 MHz verglichen zu ifupdown.

Ernsthaft, anstatt Wege zu suchen, den Irrweg von Ubuntu nutzbar zu machen, sollte man als Admin mit Rückgrat mit den Füßen abstimmen und den netplan-Murks wieder durch ifupdown ersetzen — und dabei nicht leise sein.

Letztlich haben sich auch die Rahmenbedingungen geändert; Debian ist nicht mehr in einem (gefühlten) 5-Jahres-Plan gefangen, bis die nächste Version erscheint, während Ubuntu den Server zur Spielwiese auserkoren hat.
Ich bin keine Zwanzig mehr und huldige dem »don’t fix it if it ain’t broken« — und den Beweis, daß ENI/ifupdown broken sei, hat Canonical schlicht nicht geliefert. Warum also nicht reumütig zum Orginal, Debian, zurück?