Baustelle: "multid Controller"

[knox]

Hallo,

ich bin durch Zufall auf folgendes Problem gestoßen: mindestens zwei ds-mod Pakete (re-)starten u.U. den multid neu, um ihn mit bestimmten Parametern zu füttern.
Leider nehmen die beiden Pakete aber bisher noch keine Rücksicht aufeinander und dummer Weise gehen die Parameter des anderen Paketes dabei verloren.

Beispiel:

• dnsmasq überprüft, ob igdd entfernt wurde und startet multid ggf. mit -u.
• openntp bietete einen Option, den ntp Client von AVM zu deaktivieren und startet multid ggf. mit -t

Hier gibt es also noch eine Baustelle und kreative Ideen sind gefragt

Hypsch wäre z.B., wenn es so eine Art "mutlid Controller" geben würde, dem die anderen Pakete ihre Wunsch-Parameter mitteilen können und der dann zentral das Starten und Stoppen des multid übernimmt. Die Pakete, die bisher den multid selbst neu starten, sollten dann statt dessen den Controller dazu bemühen.

Ferner habe ich schon seit einer halben Ewigkeit auf meiner persönlichen Todo- bzw. Wishlist, eine Option für erweitertes Logging (siehe u.a. hier) ins Mod zu integrieren und das würde sich hier ideal einfügen.

Wenn man das Ganze dann im Kontext des erweiterten Logging weiter denkt, könnte dieser Controller in einer Ausbaustufe auch gleich noch die anderen AVM Dienste steuern.

(Ach, hätte ich Zeit, würde ich nicht nur darüber schreiben...)

 

[kriegaex]

Den Multid-Controller gibt es in meinem Kopf auch schon, seitdem ich den UPnP/igdd-Patch in ds26 integriert habe. Das ist nämlich eine weitere Ecke, wo multid gesteuert wird, und ich bin mir der Unzulänglichkeit der momentanen Lösungen bewußt. Darüber habe ich mit olistudent und RoyceMcKnight auch schon gesprochen.

Ich hatte zumindest an ein rc.multid, also ein Init-Skript zum Starten/Stoppen gedacht, welches erkennt, welche Optionen ggf. in Abwesenheit eines igdd gesetzt werden müssen. Eine andere (oder zusätzliche) Möglichkeit wäre ein globaler Shell-Wrapper, verbunden mit dem Umbenennen des multid in multid.bin, an den dann nur noch delegiert werden würde. So ähnlich habe ich es ja bei ar7login gemacht, damit auch Binaries, welche hard-coded ein bestimmtes Binary aufrufen, also nicht gepatcht werden können, in einem sinnvollen Aufruf enden.

Irgendwann mal... Gerade bei Dnsmasq gibt es in den Skripten diverse potentielle Problemfälle, wo etwas schief gehen könnte, und da habe ich gerade keine Lust zum Wurschteln, da ich das Paket auch nicht nutze.

 

[knox]

Ob als Wrapper oder init-Script: die Aufrufparameter für den multid sollten am Besten unter /mod/etc/conf gespeichert werden. Falls Web-If Scripte andere Pakete es benötigen, können sie dort ihre Einstellungen speichern.
Am besten wäre, wenn die Config gleich so designed wird, dass wir auch die anderen AVM Daemons später noch über den selben Mechanismus steuern können.
Ferner sollte das Starten/Stoppen von AVM daemons durch andere Scripte/Packages als deprecated gelten, um das System nicht zu unterlaufen.