ds-mod Verzeichnisse /etc vs. /mod/etc - Grundlagen

[MaxMuster]

Moin zusammen,

ich stehe vor einem "kleinen" Problem, bei dem mir die erfahrenen Modder sicherlich hilfreich in die Seite springen können.
Nach ein paar Änderungen bin ich gerade dabei, die GUI für das OpenVPN Paket zu ergänzen/erweitern.
Dabei hatte knox angeregt, eine "Multi-Konfig" zu implementieren. Nach längerem Überlegen wollte ich dies so implementieren, dass ich die Skripte recht "generisch" schreibe (so dass sich z.B. die Variablen-Namen vom Aufruf ableiten, so dass ich Sym-Links nutzen kann. Also das openvpn-lzo.cgi soll sich, wenn es als openvpn-config25.cgi aufgerufen wird, halt so verhalten bezüglich der Variablen usw.). So weit so gut.
Nun wäre meine Idee, wenn ich eine weitere Instanz "fertig" habe, das Verzeichnis bis auf die Konfig durch Symlinks zu ersetzen. Grundsätzlich müsste ich also "im laufenden Betrieb" ein Modul hinzufügen und löschen können. Das klappt auch soweit, solange ich die Dinge in "/mod/etc" ablege. Ich kann das CGI registrieren, und die Config aufrufen.

Erstes Problem ist das "save.cgi" was alles nur in "/etc" nicht aus "/mod/etc" nutzt. Mir ist nun nicht ganz klar, was "richtig" ist, auch die "Erläuterungen" von Danisahne sind (für mich) eher "verwirrend" als helfend:

Das Verzeichnis /mod/ (bzw. /var/mod/) ist im RAM und stellt ein quasi root Verzeichnis für den Mod dar. Die rc Skripte der Pakete sind alle in /mod/etc/init.d/rc.* bzw. dort verlinkt.

Demnach ist "/mod/etc/init.d/rc.*" schon mal o.k.? Oder wäre das dann ein "dynamisches Paket"? Irgendwie habe ich dazu nichts gefunden (oder war zu blöd zum suchen)

Statische Pakete werden auf der Box nach / entpackt, dynamische nach /mod/.

Könntet ihr mir da bite etwas auf die Sprünge helfen, wie es gedacht/richtig ist? Für mich (bzw. diesen Anwendungsfall) wäre es natürlich besser, wenn sich alle "unter /mod" abspielte, denn sonst müsste ich schon im Voraus unter /etc Verzeichnisse/Dateien anlegen, und die später mit "mount -o bind" überladen...

Vielen Dank für eure Unterstützung!

Jörg

 

[olistudent]

Hi, Jörg.
Wir wollten mit dem nächsten dsmod-Release die unterschiedlichen Pakete für alle Binarys zusammenzufassen. Es wird dann also nur noch ein openvpn-Paket geben. Vielleicht könntest du das irgendwie berücksichtigen.
Wenn du was ins Firmwareimage packst, dann muss es nach /. /mod existiert ja erst während der Laufzeit. Wenn du also zur Laufzeit Skripte dynamisch erzeugst, dann müssen die nach /mod, weil ja / sowieso nicht beschreibbar ist.

MfG Oliver

 

[MaxMuster]

die unterschiedlichen Pakete für alle Binarys zusammenzufassen. Es wird dann also nur noch ein openvpn-Paket geben.

... ääähm, wie was zusammenfassen?? könntest du ds nochmal ausführlicher erläutern? Ich habs nicht kapiert.

Das mit dem /mod ist einleuchtend. Wird dann etwas "merkwürdig", weil dann z.B. "meine Einstellungen" in /tmp/flash/<mynewovpn>.diff schon da sind, und ich die "defaults" dazu erst später erzeuge. Ist aber klar, andersrum geht es nicht...
Da muss ich noch einiges bedenken.

Jörg

 

[olistudent]

Es gibt nur noch das Package openvpn. Nicht mehr openvpn und openvpn-lzo...

--- trunk/make/openvpn/openvpn.mk 2007/07/11 11:22:14 821
+++ trunk/make/openvpn/openvpn.mk 2007/08/16 12:49:15 989
@@ -7,14 +7,15 @@
 OPENVPN_BINARY:=$(OPENVPN_DIR)/openvpn
 OPENVPN_PKG_VERSION:=0.6d
 OPENVPN_PKG_SITE:=http://netfreaks.org/ds-mod
+
 ifeq ($(strip $(DS_PACKAGE_OPENVPN_WITH_LZO)),y)
-OPENVPN_PKG_NAME:=openvpn-lzo-$(OPENVPN_VERSION)
-OPENVPN_PKG_SOURCE:=openvpn-$(OPENVPN_VERSION)-dsmod-$(OPENVPN_PKG_VERSION)-lzo.tar.bz2
 OPENVPN_LZO:=lzo-precompiled 
 else
+OPENVPN_LZO:=
+endif
+
 OPENVPN_PKG_NAME:=openvpn-$(OPENVPN_VERSION)
 OPENVPN_PKG_SOURCE:=openvpn-$(OPENVPN_VERSION)-dsmod-$(OPENVPN_PKG_VERSION).tar.bz2
-endif
 OPENVPN_TARGET_DIR:=$(PACKAGES_DIR)/$(OPENVPN_PKG_NAME)
 OPENVPN_TARGET_BINARY:=$(OPENVPN_TARGET_DIR)/root/usr/sbin/openvpn
 
@@ -117,16 +118,8 @@
  rm -f $(OPENVPN_TARGET_BINARY)
 
 openvpn-list:
-ifeq ($(strip $(DS_PACKAGE_OPENVPN_WITH_LZO)),y)
-ifeq ($(strip $(DS_PACKAGE_OPENVPN)),y)
- @echo "S40openvpn-lzo-$(OPENVPN_VERSION)" >> .static
-else
- @echo "S40openvpn-lzo-$(OPENVPN_VERSION)" >> .dynamic
-endif
-else
 ifeq ($(strip $(DS_PACKAGE_OPENVPN)),y)
  @echo "S40openvpn-$(OPENVPN_VERSION)" >> .static
 else
  @echo "S40openvpn-$(OPENVPN_VERSION)" >> .dynamic
 endif
-endif

Wie ist das mit der Änderung an save.cgi? Die sollte eigentlich keinen Unterschied machen, außer in deinem Fall. Dann würde ich die einchecken.

MfG Oliver

 

[MaxMuster]

Ah, jetzt ja ! Keine "lzo-Unterscheidung", dass sollte kein Problem sein.
Wenn meine Ansicht stimmt, dass alle Pakete von /etc nach /mod/etc gelinkt werden (so ist das bei mir auf jeden Fall), dann sollte es unbedenklich sein, die defaults aus /mod/etc/default.<pkg> zu nehmen...
Aber wie gesagt, da arbeite ich mich gerade erst rein, und kann sicher keine "allgemein verbindlichen" Aussagen treffen ;-)

Jörg

 

[hermann72pb]

Ist es normal nicht so gedacht, dass die defaults im Image liegen? D.h. die erzeugt man normalerweise per hand zusammen mit dem Paket. Ich verstehe nicht, warum du defaults im laufenden Betrieb erzeugen willst. defaults sind per see da, wenn dein Paket startet.

MfG

 

[MaxMuster]

Ja, ist sicher "ungewöhnlich", das Problem sind auch eigentlich nicht die defaults selber:
Mein "Problem" ist, dass ich das flexibel halten wollte und man z.B "dynamisch" ein Paket openvpn-zumbuero und ein openvpn-zuKarlheinz erstellen können sollte, dann müssen halt die Verzeichnisse, Dateien und eben auch die Defaults diesen "Namen" in sich tragen.
Das könnte man nur umgehen (und mittlerweile denke ich da ernsthaft drüber nach) indem man das halt vorgibt (openvpn, openvpn-config2 und openvpn-config3) und die Pakete nur beim Laden mit einem anderen Titel im WebIF ausstattet. Der Nachteil ist halt (neben dem fixen "Namen"), dass ich immer eine Anzahl vorgeben muss, die entweder zu groß ist und unnötig Platz braucht oder halt "immer genau um einen zu klein";-).
Wie gesagt, über Hinweise und gute Ideen wie man sowas sinnvoll/besser/optimal lösen könnte wäre ich sehr froh!

Danke fürs "Mitdenken"!

Jörg

 

[hermann72pb]

Du willst also mehrere Instanzen da gleichzeitig auf der Box haben, die parallel laufen können und einzeln ab/zuschaltbar sind und konfigurierbar sind. Das ist nicht so einfach. Deine progmatische Lösung wäre mehrere pseudo-Pakete da quasi zu implementieren, damit man die einzelne Tunnels bei den Diensten ab und einschalten könnte. Habe ich es richtig verstanden?
Ich würde es anders machen. Wie das zu realisieren ist, weiß ich nicht. Nur Ideen.
1. Es gibt nur ein default, dann muss du defaults nicht überschreiben. Alle anderen configs sind diffs gegenüber diesem einen default.
2. In der Hauptmaske von OpenVPN gibt es ein Schalter (durch Auswahl), welche der Instanzen "aktiv" ist. "Aktiv" bedeutet in diesem Fall, die anderen Masken zeigen die Inhalte dieser Konfiguration.
3. In der Hauptmaske gibt es ein (oder vielleicht mehrere) Schalter, um einzelne Instanzen separat zu starten und zu beenden.
4. Außerdem gibt es Irgendwo ein Hacken für jede Instanz: "diese Instanz beim Dienststart laden".
5. Im Hintergrund muss allerdings viel ablaufen: Wenn die Instanz aktiv wird, sollen die configs und diffs von dieser Instanz in die "aktiven" configs und diffs kopiert oder umgelenkt (ln oder bind) werden. Auch init-Skript muss mehrere Instanzen beherrschen.

Also, einfach ist es nicht.

MfG

 

[MaxMuster]

Hi Hermann,

das in einer Oberfläche zu machen, wäre mir sogar sehr recht, den Ansatz habe ich auch schonmal gehabt. Was mich dann störte wäre, dass ich dann wohl die "Verwaltung" der Instanzen auch "selbst" machen müsste.
Das wäre sicher machbar, starten, stoppen usw ist ja kein Hexenwerk ;-)

Das einzige Ziel, was ich jedoch hätte, wäre, dass ich die einzelnen Instanzen auf der "Dienste" Seite haben will. Ich würde halt ungern nur den einen Button haben, der dann entweder "auf alle" Dienste wirken müsste (ein stopp stoppt alle) oder das Verhalten wäre anders, indem es ein "unterskript" ausführte, was dann nicht auf dieser Seite direkt einsehbar wäre...

Wenn ich also von einem Paket mehrere "Dienste" Einträge generieren und verwalten könnte, wäre ich "glücklich".

Jörg

PS:

Also, einfach ist es nicht.

Naja, wenns einfach wäre, könnte es ja jeder ;-) ;-)

 

[MaxMuster]

Bitte um Kommentar zu "dynamischen Paketen"

Ich hoe den "alten" Thread mal wieder hervor, um eine Frage an die "aktiven Modder" zu stellen.

Im Zuge der erweiterten GUI für OpenVPN habe ich unter anderem eingeführt, dass ich über die GUI mehrere Konfigs erstellen kann. Dabei hatte ich dann das Problem, wie ich deren Autostart und die Einbindung in die "Dienste-GUI" lösen könnte. Ich habe dafür die bislang ungenutzten "dynamischen Pakete" genutzt. Ich möchte euch bitten, kurz zu kommentieren, ob diese Änderungen "gegen das Konzept" sind oder sonstwie mit dem Gedanken des Mods und der "dynamischen Pakete" kollidieren.
Meine Änderungen an den originalen MOD-Dateien sind recht gering, letztlich sind das nur Kopien der "statischen Pakete":

--- etc/init.d/rc.mod_ori   2007-01-16 23:26:37.000000000 +0100
+++ etc/init.d/rc.mod        2007-08-30 15:19:41.000000000 +0200
@@ -20,11 +20,17 @@

        if [ -e "/etc/static.pkg" ]; then
                for pkg in $(cat /etc/static.pkg); do
                        [ -x "/etc/init.d/rc.$pkg" ] && /etc/init.d/rc.$pkg
                done
        fi

+       if [ -e "/mod/etc/dynamic.pkg" ]; then
+               for pkg in $(cat /mod/etc/dynamic.pkg); do
+                       [ -x "/mod/etc/init.d/rc.$pkg" ] && /mod/etc/init.d/rc.$pkg
+               done
+       fi
+
        [ -r "/tmp/flash/rc.custom" ] && . /tmp/flash/rc.custom
 }

 case "$1" in

--- usr/mww/cgi-bin/daemons.cgi_ori 2007-10-04 15:11:31.000000000 +0200
+++ usr/mww/cgi-bin/daemons.cgi      2007-08-31 17:24:59.000000000 +0200
@@ -79,30 +79,44 @@

 stat_static() {
        sec_begin 'Statische Pakete'
        stat_begin

        empty=1
        if [ -e "/etc/static.pkg" ]; then
                for pkg in $(cat /etc/static.pkg); do
                        if [ -x "/mod/etc/init.d/rc.$pkg" ]; then
                                empty=0
                                stat_line "$pkg"
                        fi
                done
        fi
        if [ "$empty" -eq 1 ]; then
                echo '<p><i>keine statischen Pakete</i></p>'
        fi

        stat_end
        sec_end
 }

 stat_dynamic() {
        sec_begin 'Dynamische Pakete'
+       stat_begin

-       echo '<p><i>(noch) nicht implementiert</i></p>'
+       empty=1
+       if [ -e "/etc/static.pkg" ]; then
+               for pkg in $(cat /mod/etc/dynamic.pkg); do
+                       if [ -x "/mod/etc/init.d/rc.$pkg" ]; then
+                               empty=0
+                               stat_line "$pkg"
+                       fi
+               done
+       fi
+       if [ "$empty" -eq 1 ]; then
+               echo '<p><i>"keine dynamischen Pakete"</i></p>'
+       fi
+
+       stat_end

        sec_end
 }

 cgi_begin 'Dienste' 'daemons'

Danke !

Jörg

Das Ergebnis sieht dann so aus, wie angehängt (der Screenshot beweist zudem, dass es auch mit dem "alten" ds-mod so funktioniert ;-)

 

[MaxMuster]

Ich hol es nochmal hoch und hänge auch gleich Patches mit an.
Schaut ihr bitte mal, ob das so Bestand haben kann?!?

Danke!

Jörg

 

[kriegaex]

Ich habe mir Dein Add-On nicht inhaltlich angeschaut, weiß daher auch nicht genau, wieso Du mit dynamischen Paketen arbeitest - wohl wegen des Overlays. Aber dynamische Pakete waren unrsprünglich dafür gedacht, zur Laufzeit geladen zu werden. Das wird von Danisahne in seinem neuen Mod wohl über die ipkg-Pakete abgebildet. Ich sage mal so: Solange Du es als Add-On anbietest, ist mir relativ egal, wie Du es macht, aber falls es Anklang findet, wäre es wohl sinnvoll, es ins Basispaket mit aufzunehmen.

 

[MaxMuster]

Hallo,

ah, jetzt ja. Irgendwie habe ich nie finden können, was denn mit den "dynamischen" Paketen gemeint oder gedacht war. Wenn das quasi für ipk "reserviert" ist, sollte ich mir was anderes überlegen.

Für Ideen bin ich da immer offen. Mein "Problem" nochmal kurz beschrieben ist, dass ich mit der einen GUI mehrere Konfigurationen für mehrere parallel laufende Instanzen erzeugen kann.
Für die (das ist halt meine eigene "Vorgabe") soll auf jeden Fall auch jeweils ein Eintrag in der Dienste-GUI sein (sonst wäre die nach meiner Auffassung nicht korrekt).

Mal sehen, spontan fällt mir da nur ein, die Dienste-Oberfläche um "Laufzeitpakete" zu erweitern oder (das ist machbar, aber ich finde es etwas "unschön", die static.pkg im laufenden Betrieb zu ändern [kopieren, Kopie "drübermounten" und dann Kopie dynamisch verändern])

Ich lasse mir das noch durch den Kopf gehen, für heute habe ich "Computerverbot" ;-)

Jörg

 

[kriegaex]

Frage zu Deinem Screenshot (zu faul zum Installieren und Anschauen): Da sind vier Zeilen für OpenVPN. Die drei unteren sind klar, aber was macht die obere? Kann es sein, daß da OpenVPN läuft, aber die drei unteren Dienste alle inaktiv sind? Braucht OpenVPN sowas wie einen "Master-Dienst", der als Voraussetzung für die drei "Slaves" laufen muß? Oder würden die drei Schalter unten ausreichen, so daß der "Letzte die Tür zu macht", d.h. wenn alle drei gestoppt sind, wird auch der "Master" (so er denn existiert) gestoppt. Dann würde ich dafür plädieren, das so umzusetzen, die drei Dienste nach oben zu holen und den "Master" dadurch zu ersetzen. Keine neue Kategorie von Diensten, einfach eine dynamische Erweiterung der Dienste-Liste unter "Statische Pakete". Keep it simple!

 

[MaxMuster]

o.k., noch mal kurz:
Es gibt keinen "übergeordneten" Dienst. Der "obere" ist der "normale" openvpn, ich habe noch die Möglichkerit ergänzt, zusätzliche Instanzen zu starten, die im Screenshot bei den dynamischen Paketen sind. Die kann man auch wiedr "löschen", dann verschwinden sie "unten", der eine (obere) Standard-Dienst bleibt immer da (genauso wie bisher halt auch, wenn ich Openvpn eingebaut hatte).

Ich denke auch, ich werde mich auf die "Ergänzung" einschießen, in der Hoffnung, dass es da nicht zu "Nebenwirkungen" kommt, wenn ich die Datei verändere. Ich baue mal eine Testversion.

Danke fürs "Mit-Denken" ;-)

Jörg

 

[knox]

Guten Abend,

ich habe mir in den letzten Tagen die Weiterentwicklung des OpenVPN Package von MaxMuster mal genauer angeschaut und bin dabei zunächst auch an der "missverständlichen" Umdeutung des Begriffes "dynamisches Paket" hängen geblieben.

Da die Erweiterungen auf jeden Fall eine sehr gute Sache sind, sollten sie auch Ihren Weg in den Upstream finden und daher sollte eine praktikable Lösung gefunden werden.

Also ich habe schon ein paar OpenVPN Initscripte gesehen, die einfach in einem bestimmten Verzeichniss schauen und dann für jede Config, die darin liegen, jeweils einen OpenVPN Prozess starten. Sicherlich ist das eine einfache Variante, die sich ohne viel Schnickschnack umsetzten lassen dürfte.

Viel Spaß

 

[kriegaex]

Ruby on Rails (nie benutzt, aber davon gehört) sagt ja: convention over configuration. Wieso also nicht, ich gebe knox Recht. Einfach ist gut, solange es Sinn macht.

 

[MaxMuster]

So, heute "darf" ich wieder an den Computer ;-)

Das "Starten" ist der geringste Teil. Für mich wäre es von zentraler Bedeutung, dass eien Grundsätzliche Sache gegeben ist:
Ein vom ds-mod "per GUI erzeugter" Prozess muss da auch angezeigt und z.B. zu stoppen sein.

Daher geht es mir vor allem darum, wie ich diese Dienste in der GUI anzeigen kann, ohne die dynamischen Pakete "umzuwidmen" oder eine Änderung reinzubringen, die keinen "langfristigen" Bestand haben kann.
Aber solange später erzeugte Einträge in der static.pkg keine negativen Auswirkungen haben, werde ich den Weg mal versuchen.

Jörg

 

[derheimi]

Habe die Diskussion interessiert verfolgt und bin jetzt so frei und gebe noch meine Gedanken zu "Protokoll".

Ich würde "ipkg" und "Dynamische Pakete" nicht unmittelbar vermischen. Beides sind zwei verschiedene Sachen: das eine ist ein Paketstandard, das andere bezeichnet nur das Konzept des Nachladens. Letzteres geht aber (prinzipiell) auch mit dem Paketformat des derzeitigen dsmods.

Die Verwendung der "Dynamischen Pakete" für "mehrere Instanzen" finde ich auch nicht so geeignet, weil von der Bezeichnung her schon verwirrend wäre und ich mir gut vorstellen könnte, dass man die "Dynamischen Pakete" irgendwann mal noch implementiert (vollkommen unabhängig davon, ob/wann/wie das dann von danisahnes ("dsmod-NG" auch realisiert wird). Andererseits bietet das aktuelle Framework für den Fall "mehrere Instanzen" keine wirkliche Unterstützung. Das liese sich ja aber ändern, wenn man ungefähr weiß, was man will.

Kurzer Einschub, der thematisch eher in den OpenVPN-Thread passen würde (sorry, eine gewisse Vermischung lässt sich nicht vermeiden): ich hab mir grade mal die neuen Paketquellen angesehen und wenn ich das richtig verstanden habe, werden zusätzliche (also ab der zweiten) Konfigurationen geringfügig anders gehandhabt. Das finde ich ehrlich gesagt etwas verwirrend und umständlich. Da würde ich eher eine klare Linie schaffen, die von vornherein auf "mehreren Instanzen" auslegt
ist. Und dafür sollte es dann im "Basispaket" auch die passende Unterstützung geben, weil ich mir vorstellen könnte, dass auch andere Pakete so etwas benötigen könnten.

Konkret:
Der Eintrag von "openvpn" in der Liste der "Statischen Pakete" macht dann in der jetzigen Form keinen Sinn mehr, denn auf welche Instanz beziehen sich die Button? Mein Vorschläg wäre, die Spalte "running/stopped" in die Form "x running/y stopped" zu überführen, die Button "start", "stop", "restart" durch "start all" und "stop all" und "Details" zu ersetzen. Der Zweck der beiden ersten dürfte klar sein, hinter "details" würde ich eine Seite erwarten, wo man alle konfigurierten (x+y) Instanzen des Pakets "OpenVPN" in einer analogen Liste findet, wo man wiederum "Instanzbezeichnung", "running/stopped" und "start", "stop" sowie "restart" hat.

Die Punkte, die das OpenVPN-Paket momentan unter "Einstellungen" registriert, würde ich komplett entfallen lassen, sonst hat man bei 5 Instanzen eine riesige Liste an dieser Stelle, was doch sehr unübersichtlich wäre.

Die Seite "Pakete|OpenVPN" könnte man z.B. so ausführen, dass sie die oben beschriebene "Status-Seite" enthält und gleichzeitig die Möglichkeit bietet, zusätzliche Instanzen anzulegen/löschen.
Die eigentliche Konfigurationseite (wie sie bisher bekannt ist), könnte man durch einen Link hinter der Instanz-Bezeichnung realisieren. Zusätzlich müssten die Punkte, die unter "Einstellungen" entfallen in diese Konfigseite integriert werden.

Wie gesagt, das sind meine Gedanken dazu, wie man dieses grundlegende Problem in den Griff bekommen könnte, so dass es eventuell von anderen Paketen adaptiert werden könnte. Es sieht nach sehr viel Arbeit aus, aber es wäre -denke ich- eine saubere und gangbare Lösung.

 

[MaxMuster]

Hi,

danke, noch jemand der sich beteiligt, das finde ich echt klasse!

Mein erster Ansatz ging in die skizzierte Richtung, die "zusätzlichen Konfigs" quasi genauso zu behandeln, wie ein "normales" Paket. Das hatte aus meiner Sicht ein paar Nachteile:
- Ich müsste alle Dateien kopieren und im Flash halten (gut einiges könnte man "mit Links" erledigen, aber vieles nicht)
- Für jede Instanz gäbe es einen Eintrag bei den "Paketen" (was ich dann eher verwirrend fand)
Daher fand ich es die gangbarste Lösung, zumindes die "Konfigurationen" unter einer GUI zusammenzufassen. Die von mir gewählte Lösung war, dass damit die "Hauptkonfig" im Ergebnis "leicht anders" behandelt werden muss, da gegenüber dem ds-mod nur dieses Paket bekannt ist.
Eine generelle Lösung wäre sicher interessant, jedoch viel mir "auf die Schnelle" kein anderes Paket ein, was "ähnliche Probleme" hätte, außer vielleicht "inadyn".
Letztlich müssten damit folgende Dinge abgedeckt werden:
- Wie "verwaltet" man "Unterkonfigs"?
- Wie werden die abgespeichert?
- Wie werden diese Konfigs beim Starten behandelt (Stichwort "Autostart")
- Wie und wo erscheinen die in der GUI?

Konkret:
Der Eintrag von "openvpn" in der Liste der "Statischen Pakete" macht dann in der jetzigen Form keinen Sinn mehr, denn auf welche Instanz beziehen sich die Button? Mein Vorschläg wäre, die Spalte "running/stopped" in die Form "x running/y stopped" zu überführen, die Button "start", "stop", "restart" durch "start all" und "stop all" und "Details" zu ersetzen. Der Zweck der beiden ersten dürfte klar sein, hinter "details" würde ich eine Seite erwarten, wo man alle konfigurierten (x+y) Instanzen des Pakets "OpenVPN" in einer analogen Liste findet, wo man wiederum "Instanzbezeichnung", "running/stopped" und "start", "stop" sowie "restart" hat.

Ist sicher Idee, ich weiß nicht, wie der Aufwand dafür wäre und ob es möglich wäre einen "neuen Buton" einzufügen.
Ich bin im Moment noch der Meinung, dass ich eine "Komplettliste" bevorzugte (zusätzliche zwei oder drei "Dienste" machen das wohl nicht zu Unübersichtlich und vielmehr kann die Box realistisch wohl nicht erbringen). Die Übersichtlichkeit und "Klarheit" wäre dabei das Problem. Wie du schon sagtest, die Zuordnung (speziell des "default-Dienstes") ist nicht eindeutig.
Mir fiel gerade folgendes als Idee ein:

Openvpn bei den "statischen" Paketen lassen, aber mit einer "Abwandlung":
Eine "Button-leere" Zeile (quasi als Überschrift) mit Bezeichnung "OPENVPN"
darunter (eingerückt) die Configs dazu. Also in etwa:

OpenVPN Instanzen:
   default  <Status>  [start] [stop] [restart]
   Config1  <Status>  [start] [stop] [restart]
...

Die Punkte, die das OpenVPN-Paket momentan unter "Einstellungen" registriert, würde ich komplett entfallen lassen, sonst hat man bei 5 Instanzen eine riesige Liste an dieser Stelle, was doch sehr unübersichtlich wäre.

Der Einsatz mit "mehreren" Konfigs stellt ja vermutlich schon den "Sonderfall" dar, der mit "mehreren Konfig mit eigenen Keys" umso mehr. Ich habe mich ja zumindest mit dem "Ausblenden" bemüht, die Übersichtlichkeit zu erhalten. Wenn es eine Möglichkeit gäbe, dafür eine "Unterseite" hinzubekommen wäre das Klasse, am besten fände ich eine "Integration" in die Config-Seite, also dass ich beim "Eingeben der Config" auch die Keys/Zertifikate eingeben kann. Mir ist da bislang nichts für eingefallen, wie ich das mit dem dsmod machen könnte (ich habe das auch nicht zu intensiv überlegt), daher habe ich dann die "schnellste" Variante gewählt. Wenn jemand dazu was einfällt, wie ich das realisieren kann, würde ich z.B. bei "Eigene Keys benötigt" einen Link/Buton freischalten, der auf eine Seite zur Eingabe führt. Problem ist halt, wie ich diese Eingaben dann "abspeichere". Vielleich die files "temporär" Registrieren, die "normale" file-Behandlung des mods nutzen und dann wieder Deregistrieren? Gute Idee zumindest.


Ich hoffe, du fühlst dich nicht "enttäuscht", ich möchte es gerne weiter diskutieren!

Jörg