Freetz+OpenVPN: Starttyp Automatisch geht nicht mehr

[DSLFritze]

Hallo,

ich habe mir ein Image Freetz devel-2159 für Firmware 39.04.47 gebacken. Es scheint alles reibungslos zu klappen, mit folgender Ausnahme:

Der Starttyp Automatisch für OpenVPN wird vom Freetz-GUI hartnäckig ignoriert. OpenVPN kann nur manuell gestartet werden.

Ich habe mir nun erstmal mit einem Aufruf von OpenVPN in der debug.cfg beholfen.

Kann jemand dieses Problem bestätigen? Soll ich dafür ein Ticket aufmachen?

Grüße,
DSLFritze

 

[olistudent]

Ja, mach bitte ein Ticket dafür auf.

MfG Oliver

 

[MaxMuster]

Was wird denn genau ignoriert?
Kannst du das in der GUI nicht (dauerhaft) verändern, oder wird es da geändert und steht in der GUI auf "automatisch", aber wird nicht gestartet?

Poste doch bitte mal ein

 grep AUTO /var/tmp/flash/openvpn.diff

einmal wenn "Manuell" und einmal wenn "Automatisch" abgespeichert wurde.

Danke.

Jörg

EDIT Habe gerade mal die neuste SVN-Version installiert (die openvpn-files sollten zu 2159 identisch sein) , bei mir geht es damit :
Log bei openvpn "manuell"

rc.mod version freetz-devel-2162
crond is disabled
Starting telnetd...done.
Starting webinterface...done.
Starting ssh server...done.
openvpn is disabled
openvpn_Config2 is disabled
openvpn_Config3 is disabled
openvpn_Config4 is disabled
swap is disabled

Log bei openvpn "automatisch"

rc.mod version freetz-devel-2162
crond is disabled
Starting telnetd...done.
Starting webinterface...done.
Starting ssh server...done.
Starting openvpn ... done.
openvpn_Config2 is disabled
openvpn_Config3 is disabled
openvpn_Config4 is disabled
swap is disabled

 

[DSLFritze]

Hallo MaxMuster,

Ich kann den Starttyp im GUI nicht dauerhaft verändern.

Wenn ich 'Automatisch' auswähle und dann auf 'Übernehmen' klicke, springt der Starttyp sofort wieder auf 'Manuell'

Grüße,
DSLFritze

 

[MaxMuster]

Kannst du denn trotzdem mal bitte die Ausagabe posten?
Kommt denn eine Fehlermeldung beim Speichern?

Jörg

 

[DSLFritze]

Hallo MaxMuster,

1. Eine /var/tmp/flash/openvpn.diff existiert nicht.

2. Bei meinem Versuch, diese Datei leer anzulegen, stellte ich fest, dass diese jedesmal gelöscht wird, wenn ich im Freetz GUI unter OpenVPN auf 'Übernehmen' klicke.

3. Nachdem ich auf 'Übernehmen' klicke, erscheint die folgende Ausgabe:

Saving settings...done.
Saving openvpn.cfg...done.


Writing /var/flash/freetz...done.
31232 bytes written.

4. Die Einstellungen werde wohl in /var/mod/etc/conf/openvpn.cfg gespeichert. Dies Datei enthält stets den Eintrag:

export OPENVPN_AUTOSTART='#'

und zwar unabhängig davon, ob ich mit Starttyp 'Automatisch' oder 'Manuell' auf 'Übernehmen' geklickt habe. Die übrigen Einstellungen entsprechend aber durchaus den letzten Eingaben in der Eingabemaske. Die Datei wird also tatsächlich geschrieben.

Grüße,
DSLFritze

 

[DSLFritze]

Hallo MaxMuster,

noch ein Nachtrag zu einem weiteren Verhalten des Freetz GUIs für OpenVPN, das vermutlich so nicht sein sollte und mit dem o.g. Problem im Zusammenhang stehen könnte: Wenn ich zusätzliche Konfigurationen definiere, also den Namen eingebe und dann auf '+' klicke, erscheinen diese Namen in der Drop-Down-Box unter 'default'. Sobald ich jedoch auf 'Übernehmen' klicke, sind die zusätzlichen Konfigurationen wieder verschwunden.

Grüße,
DSLFritze

 

[MaxMuster]

Sorry, bin momentan etwas in Eile:

Das sieht meiner Meinung nach aber nicht so aus, wie es sollte: Die Datei /var/mod/etc/conf/openvpn.cfg wird "gebaut" aus der "default-Config" in /etc/default.openvpn/openvpn.cfg und den "Änderungen", die in "/var/tmp/flash/openvpn.diff" stehen sollten.

Gibt es denn andere .diff Dateien in /var/tmp/flash/ ? Ansonsten lege doch dort mal eine Datei an (vorher die config wegsichern, falls nötig):

echo 'export OPENVPN_AUTOSTART="#yes"' > /var/tmp/flash/openvpn.diff

und schau ob sich was ändert.

Melde mich heute abend wieder.

Jörg

 

[McNetic]

Ich fürchte, das Problem hängt mit den Änderungen in r2135 zusammen. Das OpenVPN-Init-Script tut einige wirklich schräge Dinge, um in den save-Mechanismus des Webinterface einzuhaken. Diese basieren wesentlich auf unspezifizierten Abläufen in save.cgi, die einfach unbeabsichtigt waren und darum aufgeräumt wurden. Stattdessen gibt es in save.cgi einige neue Mechanismen, die das Gleiche auf definierte Art und Weise ermöglichen sollten; ein recht starke Anpassung des Pakets ist aber dabei wohl unausweichlich.

@MaxMuster
Schau Dir mal das aktuelle save.cgi aus dem Trunk an. Dort gibt es einige Funktionen, die mit pkg_ beginnen, und die Du mit einer Datei /etc/default.$pkg/$pkg.save implementieren kannst. Ich werde versuchen, nachher noch eine Erläuterung zum save.cgi-Mechanismus im Wiki zu schreiben.

Leider gibt es nach wie vor keine gute Möglichkeit, auf die Konfigurationsvariablen vor und nach der Änderung zuzugreifen. Das wäre vielleicht ein Feature für die Version 1.1...

Gruss, Nico

 

[MaxMuster]

Das OpenVPN-Init-Script tut einige wirklich schräge Dinge, um in den save-Mechanismus des Webinterface einzuhaken.

.... ja, schuldig, Euer Ehren.

Aber die Folge der Änderung ist nur, dass das init Skript nicht mehr feststellen kann, ob eine der Konfiogs geändert wurde, und den zugehörigen Dienst deshalb nicht neu startet. Dafür muss ich mir noch was ausdenken, mit den neuen Möglichkeiten was nachzubilden oder das ganz anders zu machen.
Ich hatte damit schon angefangen (die Mini-Lösung ist trivial, die alte Config vom "pkg_pre_save" speichern lassen), dabei jedoch gemerkt, dass ich auch vorher schon einige Dinge nicht abfangen konnte (speziell das Löschen einer Konfig) und wollte das dann in einem erledigen. Daher wird das wohl etwas aufwändiger und dauert noch etwas...

Dass hier aber wohl kein .diff geschrieben wird ist so nicht o.k.

Jörg

 

[McNetic]

Ich hab jetzt mal eine kleine Beschreibung des Save-Mechanismus ins Wiki geschrieben. Ich hoffe, das ist verständlich.

 

[MaxMuster]

Danke, für mich war es verständlich!

Anbei mal ein kleiner Patch, um zumindest die alte Situation wieder herzustellen (und einen Fehler zu beheben).
Ich würde versuchen, in den nächsten Tagen mal das ganze nochmal neu zu überdenken und die genannten Probleme beim Löschen einer Konfig anzugehen, von daher bin ich unschlüssig, ob man die Version einchecken sollte...

Jörg

 

[McNetic]

Mach aber am besten mal ein Ticket auf deswegen. Ist auf jeden Fall etwas, was vor der Release noch gemacht werden sollte.

 

[MaxMuster]

...habe etwas schneller gedacht, als gedacht ;-)

Die ganze "Änderungsüberprüfung" habe ich in das cgi "ausgelagert" und eine neue Variable dafür eingeführt, anhand derer das rc-Skript die geänderten Configs dann bei Bedarf neu starten kann.

Die einzige noch benötigte "Unschönheit" bastele ich mir nun selber: In pre wird eine Datei angelegt, anhand derer ich feststellen kann, ob das save.cgi läuft, im post wird die wieder gelöscht.

Bei mir klappt das so, auch beim Löschen von Configs. Diese Version könnte m.E. eingechecked werden, falls sich da jemand zu bereit findet....

Bedankt!

Jörg

 

[McNetic]

Hm, ich bin nicht ganz sicher, weil ich Deinen Mechanismus nicht komplett durchdacht habe, ich denke aber, daß sich der ganze Ablauf durch die verschiedenen pkg_-Funktionen sauberer und klarer gestalten liesse, und Du viel weniger 'magic' in der rc-Datei bräuchtest. Vielleicht sogar gar keine save.cgi-Erkennung. Man kann ja auch z.B. im pkg_apply_save() bestimmte Dienste neu starten.
Davon abgesehen solltest Du auf jeden Fall noch in save.cgi die Funktionen pkg_pre_def und pkg_post_def berücksichtigen, da nur die aufgerufen werden, wenn man im Webinterface die Default-Werte lädt. Du kannst dann ja einfach die jeweils andere Funktion aufrufen (bei Deinem Paket ist wohl die Behandlung von save und default gleich, bei anderen (wie z.b. mini_fo) passiert da unterschiedliches).

Gruss, Nico

 

[MaxMuster]

Moin Nico,

... ja, da hat man manchmal ein Brett vor dem Kopf, klasse Hinweis!

Mein Problem ist halt, dass es nur eine GUI gibt, die logischerweise nur das zugrunde liegende Paket mit Namen openvpn berücksichtigt. Damit würde der restart nur angestoßen, wenn die default-Config auch läuft.
Ich werde sehen, das (ggf nötige) Starten der anderen Config in das apply_save() zu verschieben, dann kann die ganze Überprüfung entfallen. Und natürlich fehlen die def... Versionen auch noch.

Nochmals Danke! Das hilft immer sehr, wenn man einen "unbeteiligten" Blick auf das eigene Chaos hat, der sofort einen Ausweg sieht ;-)

Jörg

 

[MaxMuster]

So, auf ein neues, ich hoffe ich darf dafür ein neues Posting machen:

Mit dem neuen Patch sind die Fallabfragen im rc-File raus. Es gibt nur noch eine Besonderheit:
Das normale save.cgi startet bei jedem "Übernehmen" den Dienst neu. Da möchte ich so nicht, denn damit würde (sofern er läuft) immer der openvpn "default"-Daemon neu gestartet, auch wenn dessen Konfig nicht verändert wurde. Daher habe ich das restarten in meine "apply_save()" Funktion mit eingebaut und (ich hoffe, das ist so o.k.) das reguläre apply_changes() mit einem leeren "überschrieben". So sieht das in meiner openvpn.save aus:

pkg_apply_save() {
. /mod/etc/conf/openvpn.cfg ;
if [ "$OPENVPN_CONFIG_COUNT" -gt 1 ]; then
        /mod/etc/default.openvpn/openvpn_dynamic_conf ;
        changed="${OPENVPN_CONFIG_CHANGED#*#}" ;
        for d in `echo "openvpn${OPENVPN_CONFIG_NAMES#*DEFAULT#}" | sed 's/#/ openvpn_/g' `; do
                if [ "${changed%%#*}" == "yes" -a ! -z "$(pidof "$d")"  ]; then
                echo "Change in config of running daemon $d. Restarting ..."
                "/mod/etc/init.d/rc.$d" restart ; fi ;
                changed=${changed#*#};
        done;
else
       start_stop openvpn "$oldstatus1" ;
fi ;
}

pkg_apply_def() {
        /mod/etc/default.openvpn/openvpn_dynamic_conf ;
        start_stop openvpn "$oldstatus1" ;
}

apply_changes() { :; }

Falls o.k., bitte übernehmen.

Danke!

Jörg