FREETZ WebIF: Starttyp mit Status vereinigen

[hermann72pb]

Die letzten Modifizierungen in modlibrc und in dem WebIF hatten uns nun ermöglicht, dass wir die start/stop-Knöpfe auch unter den Paketeinstellungen vorfinden. Zwar lässt sich bekanntlich über das Performance und über das Nutzen von solchen Änderungen streiten, aber lassen wir es erstmal beiseite.
Die besagte Lösung ist zwar schön und geht auch in die Richtung, die ich schon ursprünglich anstreben wollte, aber so ganz bin ich mit Realisierung noch nicht zufrieden und will eine wilde Idee in den Raum stellen:
Wäre es nicht schön, wenn wir die blöden Häckchen "Automatisch" / "Manuell" / "Inetd" endlich von den cgi der Paketen lösen und neben den drei Knöpfen (start/stop/restart) in der jeweiligen Zeile darstellen? "Manuell" kann man sich wohl ersparen, denn wenn es nicht automatisch ist und kein inetd angeklickt ist, dann ist es wohl manuell. Ob man es mit Häckchen macht, oder dafür vielleicht eher Knöpfe nimmt (lässt sich einfacher programmieren), darüber kann man noch reden.
Die Idee hatte ich schon lange gehabt, hatte aber letztendlich vor ein paar Tagen mich in der Richtigkeit dadurch bestätigt, dass ich sowas bei dem mod zu meinem Xtreamer gesehen hatte (die Jungs machen da etwas ähnliches, wie wir hier).

Gäbe es da etwas, was dagegen sprechen würde?

MfG

 

[olistudent]

Die letzten Modifizierungen in modlibrc und in dem WebIF hatten uns nun ermöglicht, dass wir die start/stop-Knöpfe auch unter den Paketeinstellungen vorfinden. Zwar lässt sich bekanntlich über das Performance und über das Nutzen von solchen Änderungen streiten, aber lassen wir es erstmal beiseite.

Ich finde es sehr praktisch, dass man jedes Paket auf seiner Seite auch starten und stoppen kann. Zumal man jetzt einen Klick mehr benötigt um auf die Dienste Seite zu kommen. Warum das jetzt auf Kosten der Performance gehen soll leuchtet mir nicht ein.

Wäre es nicht schön, wenn wir die blöden Häckchen "Automatisch" / "Manuell" / "Inetd" endlich von den cgi der Paketen lösen und neben den drei Knöpfen (start/stop/restart) in der jeweiligen Zeile darstellen?

Nicht jedes Paket unterstützt inetd. Aber man könnte den Code sicher in eine Funktion in libmodcgi packen. Entspricht das deinem Verständniss von "lösen"?

"Manuell" kann man sich wohl ersparen, denn wenn es nicht automatisch ist und kein inetd angeklickt ist, dann ist es wohl manuell.

Ich bin dafür die Auswahl zu lassen wie sie ist (automatisch, manuell, inetd). Was spricht gegen den Radio-Button? Hast du noch die Idee mit einem dynamischen inetd im Hinterkopf?

MfG Oliver

 

[hermann72pb]

1. Performance wird dadurch auf der Seite mit Paketeinstellungen etwas schlechter, weil du die drei Knöpfe da darstellen muss und wahsrcheinlich auf ähnliche Skriptkonstrukte, wie auf Seite mit Diensten zugreifst. Das war früher etwas einfacher und nach meiner Schätzung schneller. Aber lass uns nicht um die Millisikunden streiten.
2. Dass nicht jedes Paket inetd unterstützt ist klar. Diese Problematik kann man aber sicherlich irgendwie lösen.
3. Ich habe die Idee mit dem dynamischen inetd schon fast aufgegeben, ich will aber die Pakete dennoch dazu bringen, dass sie auch im inetd-Modus auf "start" und "stop" reagieren, wie ich es erwarten würde, nämlich sich beim inetd registrieren oder abmelden. Soweit ich es überblicken konnte, hatte cuma in die Richtung schon Bausteine angelegt, es muss nur weiter durchdacht und realisiert werden.
Wenn es denn so funktioniert, wie ich es mir denke, sehe ich da keine Radio-Buttons mehr mit einer oder-Auswahl, sondern zwei verundete Bedingungen:
a) Automatisch. Bedeutet nur, dass beim Hochfahren der Box "rc.paket start" ausgeführt wird. Ob denn inetd aktiviert ist, oder nicht, spielt dabei keine Rolle. Die Auswahl zwischen daemon/inetd findet innerhalb der start-Sektion zum jeweiligen Paket.
b) Inetd. (optionale Auswahlbedingung) bedeutet, dass beim "rc.paket start" kein Daemon gestartet wird, sondern das jeweilige Paket wird beim inetd registriert. Und beim "rc.paket stop" wird es dort abgemeldet.

Somit ergibt sich folgende Matrix, die meiner Meinung nach viel logischer ist und nativ zu verstehen, als jetzige Lösung:

Automatisch  Inetd
       0        0      Paket wird beim Hochfahren nicht automatisch gestartet. Daemon-Modus ist aktiviert. Beim manuellen "start/stop" wird Daemon gestartet/gestoppt.
       0        1      Paket wird beim Hochfahren nicht automatisch gestartet. Inetd-Modus ist aktiviert. Beim manuellen "start/stop" wird das Paket bei inetd registriert/abgemeldet.
       1        0      Paket wird beim Hochfahren automatisch als Daemon gestartet. Daemon-Modus ist aktiviert. Beim manuellen "start/stop" wird Daemon gestartet/gestoppt.
       1        1      Paket wird beim Hochfahren automatisch im inetd-Modus gestartet. Inetd-Modus ist aktiviert. Beim manuellen "start/stop" wird das Paket bei inetd registriert/abgemeldet.

MfG

 

[olistudent]

Die Probleme kommen daher, dass wir 'inetd' als Status haben. Du hast schon Recht, dass Status eigentlich nur 'running' und 'stopped' sein sollte. Wir bräuchten dann für inetd Pakete eine weitere Konfig-Variable, die die Startart anzeigt. Oder sogar für alle Pakete? (normal und inetd)

Im Webinterface wäre ich für zwei Radio-Buttons (automatisch/manuell) und eine Check-Box (Inetd).

MfG Oliver

 

[cuma]

eine Check-Box (Inetd).

MfG Oliver

nicht so gut. Wenn inetd im Image war und ein Package noch auf inetd steht ist kein Radiobutton ausgewählt. Mit einer Chekcbox bräuchteman noch logik und man würde es ändern wenn man nur auf übernehmen drückt

 

[olistudent]

Wenn inetd im Image war und ein Package noch auf inetd steht ist kein Radiobutton ausgewählt.

Versteh ich nicht. Inetd hat doch dann mit automatisch/manuell nichts mehr zu tun. Der Radiobutton bleibt egal ob mit oder ohne inetd unverändert.

MfG Oliver

 

[hermann72pb]

Ob wir das mit Knöpfen, Check-Boxen oder Radio-Buttons realisieren, darüber können wir später reden. Mich würde interessieren, ob ihr erstmal generell mit meiner Definition und der Logiktabelle aus #3 einverstanden seid. Es entspricht nicht unserem jetzigen Stand, würde aber von der Logik an besser und nativ von allen verstanden. Nochmal zum Hauptton:
1. "Inetd / Daemon" würde in meinen Augen die Art des Startens definieren, wenn man "rc.paket start" ausführt. Würde aber im Gegensatz zum jetzigen Stand nicht bedeuten, dass wenn inetd aktiviert ist, dass das Paket mit dem Starten von inetd oder mit dem Hochfahren der Box sofort startet.
2. "Automatisch / Manuell" heißt für mich lediglich nur, dass irgendwo im rc.mod solche Pakete, die auf "auto" stehen beim Hochfahren der Box starten. Kombination "Manuell+Inetd" würde -wie ich schon oben sagte- nicht dazu führen, dass so ein Paket sich beim inetd registriert, wenn die Box hoch fährt.

@Oliver: Zu den Variablen.
a) Man könnte für inetd entweder eine extra-Variable vorschlagen. $PACKAGE_ENABLED könnten wir in diesem Falle weiterhin für auto/manuell nutzen (yes/no). Und $PACKAGE_INETD mit entsprechend auch (yes/no) würde für Modus inetd/daemon stehen. Wenn man es mit zwei Variablen macht, kann man bei den Paketen, die diese Variable nicht haben inetd-Option leichter ausblenden.
b) Man definiert für $PACKAGE_ENABLED entweder einer vierten Zustand (drei haben wir bereits: yes/no/inetd), oder man nennt sie gleich alle um, z.B. in rund/runi/stpd/stpi. Die Umbenennung ist aber so eine Sache. Man muss dann die Portierung von alten zu neuen Variablen bedenken und auch, wie man unterscheiden kann, ob ein Paket überhaupt inetd kann.

MfG