OpenVPN-Paket

[MaxMuster]

So,

nun mal eine "Komplettversion" (Danke an knox für die Vorarbeit).

Neu ist:
- Alles (sollte) auch in Englisch möglich sein
- "Minimale Änderungen" beim Inhalt (bei einer "ausführlichen" Erklärung keinen Tooltip mehr)
- Es wird die "aktuelle" Konfig (ungleich default) entfernt


Jörg

Vorgehen:
- Patches anwenden (im Verzeichnis "oberhalb" des dsmod)
- Datei nach "dl" kopieren und in "ds26-15.2/make/openvpn/openvpn.mk" "OPENVPN_PKG_VERSION" ändern auf OPENVPN_PKG_VERSION:=0.6f Änderung ist im patch mit drin

 

[kriegaex]

Edit: Achtung, zeitliche Überschneidung mit dem vorherigen Beitrag! Das Paket dort enthält dieselben Probleme, die ich hier für das aus #474 korrigiere.

Ich verwende das Paket nicht, Dein Overlay ebensowenig. Aber gezogen habe ich es mir schnell. Dabei ist mir zweierlei aufgefallen:

• Die Dateien etc/default.openvpn/openvpn_* sind nicht im ANSI-Format gespeichert, sondern in UTF-8, also Unicode. Das gefällt der Box nicht, wenn ich die Datei direkt rüber kopiere. Konsolen-Ausgabe:
  

  [B]$ cat openvpn_dynamic_conf[/B]
  #!/bin/sh
  
  cc="openvpn"        # hier merken wir uns, welche Configs es gibt (um andere zu l[COLOR="Red"]?[/COLOR]chen)
  bakupifs=$IFS;
  ...
  . /mod/etc/conf/openvpn.cfg
  while [ $count -le $OPENVPN_CONFIG_COUNT ]
  do
          IFS="[COLOR="red"]§*§[/COLOR]";
          wert $OPENVPN_CONFIG_NAMES $delimiter $count;
          LOKAL_CONFIG_NAMES=$uebergabe;
          IFS="[COLOR="red"]§*§[/COLOR]";
          wert $OPENVPN_AUTOSTART $delimiter $count;
          LOKAL_CONFIG_AUTOSTART=$uebergabe;
          IFS="[COLOR="red"]§*§[/COLOR]";
  ...

  Es gibt noch weitere problematische Stellen, das sind nur Beispiele. Ob das Beim Firmware-Bau umgewandelt wird, weiß ich nicht, aber ich bezweifle es. Ich würde an Deiner Stelle lieber die Datei gleich richtig abspeichern, so daß die Box sie versteht:
  

  [B]$ cat openvpn_dynamic_conf.converted_to_ansi[/B]
  #!/bin/sh
  
  cc="openvpn"        # hier merken wir uns, welche Configs es gibt (um andere zu l[COLOR="Red"]ö[/COLOR]schen)
  bakupifs=$IFS;
  ...
  . /mod/etc/conf/openvpn.cfg
  while [ $count -le $OPENVPN_CONFIG_COUNT ]
  do
          IFS="[COLOR="red"]§§[/COLOR]";
          wert $OPENVPN_CONFIG_NAMES $delimiter $count;
          LOKAL_CONFIG_NAMES=$uebergabe;
          IFS="[COLOR="red"]§§[/COLOR]";
          wert $OPENVPN_AUTOSTART $delimiter $count;
          LOKAL_CONFIG_AUTOSTART=$uebergabe;
          IFS="[COLOR="red"]§§[/COLOR]";
  ...

• Das eigentliche Problem bzgl. des Fehlers im Skript liegt übrigens nicht in der hervorgehobenen Textzeile, sondern in der von dort aufgerufenen Funktion wert:
  

  # Falsch
   if [COLOR="Red"][ $c -eq $number ][/COLOR] ; then uebergabe=$inhalt; fi
  
  # Richtig wäre es so
   if [COLOR="Red"][ "$c" -eq "$number" ][/COLOR] ; then uebergabe=$inhalt; fi

  Ein typischer Fehler in Shell-Skripten: Die fehlenden Anführungszeichen führen dazu, daß es zu einem Syntaxfehler kommt, sofern eine der Variablen leer ist und somit zu nichts expandiert wird. Das ist hier der Fall, weil ja $3 leer ist. Der Fehler ist übrigens sowohl in openvpn_conf als auch in openvpn_dynamic_conf enthalten.

Anbei eine korrigierte Variante des Pakets aus #474, welche beide Dateien zeichensatzmäßig und logisch korrigiert. Ob noch andere Fehlerquellen da sind, weiß ich nicht, ich habe es nicht getestet.

 

[MaxMuster]

Ein typischer Fehler in Shell-Skripten: Die fehlenden Anführungszeichen führen dazu, daß es zu einem Syntaxfehler kommt, sofern eine der Variablen leer ist und somit zu nichts expandiert wird.

Danke, ich dachte, ich hätte nun alle Stellen erwischt, aber ganz offensichtlich nicht richtig geschaut...

Danke auch für den Format-Hinweis, werde mich bemühen, das demnächst zu berücksichtigen.

Wenn ich dich noch direkt bitte dürfte noch auf dies hier zu schauen, weil ich für mein Paket halt zwei Eingriffe in "originale" ds-mod Dateien benötige.

Danke!

Jörg

 

[wonderdoc]

@MaxMuster

Ich hatte gestern dein Overlay vom 4.10.07 nun auch auf meine Server Box gespielt.
Dabei ist mir noch aufgefallen, dass wenn man den Standard der Konfig (default) wiederherstellt, dabei der Autostart aktiv gesetzt wird.
Bei den hinzugefügten Configs ist der manuelle Start aktiv.

Sollte man daher nicht auch für den default den manuellen Start per Defaul setzen?

mfg
Wonderdoc

 

[MaxMuster]

Sollte man daher nicht auch für den default den manuellen Start per Defaul setzen?

Ist in der aktuellen ersion bei mir schon drin, die mache ich aber erst die nächsten Tage fertig. Wenn du willst, kannst du auch die "openvpn.cfg" verändern und den zweiten Wert ("yes" bei "AUTOSTART" löschen
(die erste "Spalte" (durch # getrennt) sind die defaluts, die zweite ist die erste Konfig usw.)

Jörg

 

[knox]

@MaxMuster: Tolle Arbeit, vielen Dank!

@Alexander: Wenn Du es sowieso schon in der Mangel hast, kannst Du es doch bitte auch gleich ins SVN schieben, Danke.

 

[kriegaex]

Ich habe nichts in der Mangel, ich verwende das Paket ja nicht einmal. Da ich mich mit OpenVPN nullkommanull auskenne, würde ich das Überarbeiten des Pakets gern jemandem überlassen, der sich gut damit auskennt und es auch sinnvoll testen kann. Ob Oliver oder andere eincheck-berechtigte Entwickler (Du?) mehr darüber wissen, ist mir nicht bekannt. Ich wollte vorher nur mal kurz helfen, weil ich diese offensichtlichen Kleinigkeiten schnell erkennen konnte.

 

[MaxMuster]

Ich würde die "Grundsatzdiskussion" über die Darstellung und das Starten der Prozesse gern abgeschlossen haben, ehe der Schritt in die "offizielle" Welt geht.

Jörg

 

[MaxMuster]

[*]Die Dateien etc/default.openvpn/openvpn_* sind nicht im ANSI-Format gespeichert, sondern in UTF-8, also Unicode. Das gefällt der Box nicht, wenn ich die Datei direkt rüber kopiere.

Könntest du das nochmal verifizieren bitte?

Meine umgewandelten Dateien (jetzt auf ISO 8859-1) sehen auf der Box jetzt so "kaputt" aus, wie bei dir angegeben.

Test: Datei abgespeichert als "utf-8", "cp-1252" und als "iso-8859-1" ("ANSI" gibt es in "kate" oder kwrite" nicht, und lt. Wikipedie werden diese beiden manchmal als "ANSI" bezeichnet) und mit scp auf die Box kopiert:

/var/tmp $ grep IFS openvpn_dynamic_conf_utf
bakupifs=$IFS;
        IFS=$2;
        IFS=" ";
        IFS="§*§";
        IFS="§*§";
        IFS="§*§";
        IFS=$bakupifs;
IFS=$bakupifs;
/var/tmp $ grep IFS openvpn_dynamic_conf_iso
bakupifs=$IFS;
        IFS=$2;
        IFS=" ";
        IFS="�*�";
        IFS="�*�";
        IFS="�*�";
        IFS=$bakupifs;
IFS=$bakupifs;
/var/tmp $ grep IFS openvpn_dynamic_conf_cp_1252
bakupifs=$IFS;
        IFS=$2;
        IFS=" ";
        IFS="�*�";
        IFS="�*�";
        IFS="�*�";
        IFS=$bakupifs;
IFS=$bakupifs;
/var/tmp $

Ich bin leicht verwirrt...

Jörg

Dennoch mal ein "Stand" von heute. Die Dienste werden nun unter "Statischen Paketen" in einer "kleinen Untereinheit" angezeigt (siehe screenshot mit einer und mit mehreren Configs)

 

[kriegaex]

Ja, ANSI war ungenau. Ich meinte ISO-8859-1 bzw. 8859-15 (das gleiche, nur mit Euro-Zeichen). Kontrollier ruhig selbst: Wenn alles in ISO-8859-1 gut aussieht und auf der Konsole bzw. im Editor auf der Box auch, wird es wohl okay sein.

 

[MaxMuster]

... isses aber leider nicht. Bei mir sieht es so aus, als sei UTF-8 "richtig" und "ANSI" falsch. Wenn das bei dir gerade andersrum ist, finde ich das zumindest "merkwürdig"...

Jörg

 

[derheimi]

Jörg, Du verwendest ein aktuelles Linux auf Deinem Rechner (weil Du oben von kwrite/kate gesprochen hast)? Das Linux ist bestimmt komplett auf UTF-8 eingeschossen, so wie es sein sollte.
Nächste Frage: wie verbindest Du Dich zur Fritzbox um den Zeichensatz zu checken? Vermutlich mit einem SSH-Programm? Dann musst Du diesem Programm noch beibringen, dass es den entfernten Zeichensatz konvertieren muss, bevor es bei Dir angezeigt wird. Weil Deine Linux-Umgebung erwartet UTF-8 und geliefert wird ohne Konvertierung ISO, was zu diesen Anzeigeproblemen führen kann. Bei dem bekannten PuTTY (gibt wohl auch für Linux) kann man den Remote-Zeichensatz auswählen, wie das bei kssh oder dem Konsolenclient geht müsste ich selber erstmal nachlesen.

 

[kriegaex]

Lagern wir am besten die aktuelle Zeichensatz-Diskussion - bzw. das allgemeine Philosophioeren darüber, das nichts mit diesem Paket per se zu tun hat - aus. Ich habe zu diesem Zweck das sowieso längst überfällige Thema Unicode auf Build-System vs. ISO-8859-1 auf Fritz!Box angelegt.

 

[MaxMuster]

So, nachdem ich mir das einige Tage lang durch den Kopf hab gehen lassen, werde ich eine "Umstellung" auf eine "allgemeine Grundlage für Mod-Pakete mit mehreren Instanzen" erstmal nicht angehen. Das ist mir momentan einfach zu viel, da das Paket prinzipiell wohl so seine Funktion erfüllt. Prinzipiell eine Idee, die man angehen kann, dabei muss aber ein größerer Konsenz geschaffen werden, damit die Ideen dann auch kein "Spezialfall" sondern allgemein nutzbar sind.

Dennoch will ich mal die Gedanken dazu kurz einbringen, falls "man" später doch noch dazu übergehen möchte ist es ja vielleicht brauchbar:

Mein Vorschlag dafür wäre, dass es weiterhin nur ein Paket gibt, was aber eben "Unterinstanzen" verwalten kann. Ein paar Ideen dazu, nur so in den Raum geworfen:

• Ein "fester" Parameter (wie jetzt z.B. "ENABLED") z.B. "MULTI_DAEMON", der gesetzt wird
• Die "notwendigen Dateien" (default.<Package>, default.<Package>/rc.<Package> usw) dürfen entfallen und ersetzt durch "generische" Dateien, die z.B. mit einem Zusatzparameter aufgerufen werden können z.B. "rc.openvpn start <Configxy>"
• Anpassung der ds-mod Dateien, um eine "Sonderbehandlung" solcher Pakete zu machen: Speichern muss mehrere Configs ergeben, die Anpassung der Dienste und Erkennen von Änderungen: Wenn ich nur die letzte Config ändere, sollte auch nur die neu gestartet werden, momentan ist das etwas "umständlich" gelöst.

Der "größte" Eingriff ist im Bereich der "Abspeicherung" nötig. Hintergrund ist, dass der mod einfach und genial den Namen des "aktuelle Pakets" als Grundlage für alle Aktivitäten nutzt. Speziell der Fall "Abspeichern"/"Defaults wiederherstellen" ist das, was mich wegen der zu erwartenden Komplxität der Änderungen abgeschreckt hat.

Momentan wäre also meine Bitte, die notwendige Änderung an der "originalen" ds-mod Datei "daemons.cgi" in den Mod zu übernehmen und den jetzigen Stand erstmal zu nutzen. Änderungen/Ergänzungen können ja immernoch erfolgen, am ehesten wäre ich momentan aber dazu "bereit", das "Problem" mit den vielen Einstellungsdateien (Keys/Zertifikate) zu "ändern", das "stört" mich noch mehr, als dass die Behandlung der Instanzen "unterschiedlich" ist ;-).

Jörg


EDIT: Dateien entfernt. Aktuelle Version im nächsten Post

 

[MaxMuster]

Hier der letzte Stand, mit den folgenden Änderungen:

• Entfernen der Abhängigkeit vom aktuellen Terminal-Zeichensatz
• Korrektur beim Autostart der zusätzlichen Konfigurationen (es wurde nur die "Grundkonfig" korrekt geladen

Viel Spaß damit, ich hoffe, so langsam wird es "integrierbar" ;-)

Jörg

 

[wonderdoc]

@MaxMuster

Danke,
ich werde den letzten Stand nächste Woche testen und meine Erfahrungen damit dann posten.

mfg
Wonderdoc

 

[kriegaex]

Entfernen der Abhängigkeit vom aktuellen Terminal-Zeichensatz

Du meinst vermutlich, daß alle Dateien in ISO-8859-1 gespeichert sind (nicht hinein geschaut). Abhängig vom Zeichensatz sind sie nach wie vor, das war und ist ja gerade das Problem.

 

[MaxMuster]

Du meinst vermutlich, daß alle Dateien in ISO-8859-1 gespeichert sind (nicht hinein geschaut).

Auch. Zudem habe ich alle Zeichen rausgenommen, die unterschiedlich codiert sein könnten (sofern ich nichts übersehen habe). Also keine Umlaute und "Sonderzeichen", sondern alles aus den in scheinbar allen Zeichensätzen "identischen" ersten 128 Zeichen. Auch das gilt natürlich nur soweit, wie ich das mit den Zeichensätzen und den Problemen verstanden hatte...

Jörg

aus dem RFC 2279 ( UTF-8 ):

-  Character values from 0000 0000 to 0000 007F (US-ASCII repertoire)
   correspond to octets 00 to 7F (7 bit US-ASCII values). A direct
   consequence is that a plain ASCII string is also a valid UTF-8
   string.

 

[maceis]

@Max Muster

Es geht nochmal um das Problem mit dem nicht funktionierenden "explicit-exit-notify".
Deinen Beitrag #426 habe ich erst heute gesehen.
Damit konnte ich mein Problem lösen.

Falls jemand "explicit-exit-notify" verwenden möchte, unten ist ein patch und hier steht, wie man Patches einspielt.
HTH

 

[MaxMuster]

Danke für die Rückmeldung. Was hat das denn im Ergenis an "Größenunterschied" gebracht?

Jörg