[INFO] opendd, ein DynDNS-Client

[sf3978]

..., vielleicht ist es auch möglich die einzelnen Patches in eins zusammen zu fassen sowie die Rechte automatisch vergeben, weiss nicht ob sowas machbar ist, aber es wäre sicher für viele einfacher....

Der Spezial-Patch im Anhang (für dich) sollte deine Wünsche in Erfüllung gehen lassen. Teste den Patch mal, nach einem "make opendd-dirclean", "make matude-dirclean", dann die Ordner matude und opendd im make-Verzeichnis löschen, den Patch ausführen, die entsprechenden Dateien nicht ausführbar machen. ssl ist jetzt per default auch auf y.

:~/myfreetz/freetz5185/freetz-trunk> patch -p0 < ssl_y_chmod_755_opendd_matude_040710.patch.txt
patching file make/opendd/Config.in
patching file make/opendd/external.files
patching file make/opendd/external.in
patching file make/opendd/external.services
patching file make/opendd/files/root/etc/default.opendd/opendd.cfg
patching file make/opendd/files/root/etc/default.opendd/opendd_pem.def
patching file make/opendd/files/root/etc/init.d/rc.opendd
patching file make/opendd/files/root/etc/onlinechanged/start_opendd
patching file make/opendd/files/root/usr/lib/cgi-bin/opendd.cgi
patching file make/opendd/Makefile.in
patching file make/opendd/opendd.mk
patching file make/opendd/patches/100_Makefile.patch
patching file make/opendd/patches/110_util_c.patch
patching file make/opendd/patches/120_setproctitle_h.patch
patching file make/opendd/patches/130_setproctitle_c.patch
patching file make/opendd/patches/140_opendd_c.patch
patching file make/opendd/patches/150_opendd_h.patch
patching file make/opendd/files/.language
patching file make/matude/Config.in
patching file make/matude/files/root/etc/init.d/rc.matude
patching file make/matude/files/root/etc/onlinechanged/start_matude
patching file make/matude/Makefile.in
patching file make/matude/matude-0.1/Makefile
patching file make/matude/matude-0.1/matude.c
patching file make/matude/matude-0.1/tun_dev.c
patching file make/matude/matude.mk

Ich habe in die opendd.mk noch Folgendes eingefügt:

chmod 755 $(OPENDD_DEST_DIR)/usr/lib/cgi-bin/opendd.cgi \
		    $(OPENDD_DEST_DIR)/etc/init.d/rc.opendd \
		    $(OPENDD_DEST_DIR)/etc/onlinechanged/start_opendd

Und in die matude.mk habe ich Folgendes eingefügt:

chmod 755 $(MATUDE_DEST_DIR)/etc/init.d/rc.matude \
		    $(MATUDE_DEST_DIR)/etc/onlinechanged/start_matude

D. h. die Rechte werden nicht vom Patch, sondern von den Paketen geändert. Bei mir funktioniert das. Bevor Du flasht, schau in den package-Ordner, ob dort die Ausführungsrechte richtig gesetzt sind.

 

[Silent-Tears]

Ist dann aber im trunk reichlich unnöltig

 

[sf3978]

Richtig. So soll es ja auch nicht in den trunk. Ist halt nur ein Spezial-Patch für hoddelac.

 

[hoddelac]

Hallo,
so nach ca 2 Wochen habe ich keinerlei Probleme mehr mit dyndns dank opendd. eins ist mir aufgefallen meine 7270 hat in der zeit 2 Reboots hingelegt warum kann ich nicht sagen, habe jetzt mal syslogd aktiviert.

 

[sf3978]

Hast Du die Reboots mit Hilfe der eMail-Benachrichtigung von opendd festgestellt? Der Auslöser für die 2 Reboots sollte aber nicht opendd sein.

 

[hoddelac]

hallo, ja habe ich über die E-mail Benachritigung festgestellt, glaube auch nicht das es an opendd liegt, hatte ja ein ganz neues Image mit dem neusten Trunk erstellt.
Das alte Image war auch schon 7 Monate alt.
Wozu ist das neue Patch in deinem Anhang? kann ich das Patch so ausführen oder muss ich wieder alles löschen und von vorme anfangen? meine im Freetz.

 

[sf3978]

[...]
Wozu ist das neue Patch in deinem Anhang? kann ich das Patch so ausführen oder muss ich wieder alles löschen und von vorme anfangen? meine im Freetz.

Wenn der "alte" Patch bei dir ohne Probleme funktioniert, dann musst den deuen Patch nicht verwenden. Beim neuen Patch ist matude nicht mehr ersichtlich und muss auch nicht in die Datei "make/Config.in" eingetragen werden. Im neuen Patch wird matude aus der rc.opendd gestartet. Wenn Du den neuen Patch doch benutzen willst, dann müssen die Ordner "opendd" und "matude" aus dem Verzeichnis "make" gelöscht werden. Der Eintrag für matude in der "make/Config.in" muss auch gelöscht werden.

EDIT:
Ab trunk rev. 5275, ist opendd im trunk vorhanden.

 

[hoddelac]

EDIT:
Ab trunk rev. 5275, ist opendd im trunk vorhanden.[/QUOTE]

würde das diese Meldung erklären??

rene@debian:~/freetz-trunk$ svn up
U make/openntpd/files/root/etc/init.d/rc.openntpd
U make/openntpd/files/root/etc/onlinechanged/reload_ntpd
U make/rrdstats/files/.language
U make/rrdstats/files/root/usr/lib/cgi-bin/rrdstats.cgi
U make/rrdstats/files/root/etc/init.d/rc.rrdstats
U make/rrdstats/files/root/etc/default.rrdstats/rrdstats
svn: Verzeichnis »make/opendd« konnte nicht hinzugefügt werden: ein nicht versioniertes Verzeichnis mit demselben Namen existiert bereits
rene@debian:~/freetz-trunk$ make menuconfig
file make/opendd/Config.in already scanned?
make: *** [menuconfig] Fehler 1
rene@debian:~/freetz-trunk$

muss ich den trunk jetzt komplet neu laden?

 

[olistudent]

rm -rf make/opendd
rm -rf make/Config.in
svn up

MfG Oliver

 

[SaschaBr]

Aufgrund von Fehlermeldungen von inadyn (siehe hier) habe ich mich gestern dazu entschlossen, auf opendd umzusteigen.
Dies ist mir dank der Unterstützung von sf3978 auch heute geglückt. Jedoch habe ich noch immer ein Problem:
Und zwar wird nach einem Neutstart der Box zwar das onlinechanged-script gestartet (im Syslog ersichtlich), jedoch ist dies die einzige Zeile, die im Syslog auftaucht. Es erfolgen keine weiteren Einträge durch opendd im Syslog, und meine DynDNS-Account wird auch nicht aktualisiert.
Erst wenn ich dann die Online-Verbindung (über das AVM-WebIF) neu verbinden lasse, wird mein DynDNS-Account ohne Verzögerung aktualisiert.

Hier scheint das Script irgendwo hängen zu bleiben, oder aber auf irgendetwas zu warten.

 

[cuma]

Und zwar wird nach einem Neutstart der Box zwar das onlinechanged-script gestartet (im Syslog ersichtlich), jedoch ist dies die einzige Zeile, die im Syslog auftaucht.
...
Hier scheint das Script irgendwo hängen zu bleiben, oder aber auf irgendetwas zu warten.

checkip.dyndns.org will heute nicht, worauf opendd wartet

 

[sf3978]

... Es erfolgen keine weiteren Einträge durch opendd im Syslog, ...

Das ist nicht gut. Ich schau mal am Wochenende ob man opendd so patchen kann, dass eine Meldung im Syslog kommt, wenn checkip.dyndns.org einmal nicht will.

 

[SaschaBr]

checkip.dyndns.org will heute nicht, ...

Kommen da auch die Fehlermeldung von inady her?

 

[cuma]

opendd so patchen kann, dass eine Meldung im Syslog kommt, wenn checkip.dyndns.org einmal nicht will.

dies wird durch get_ip verursacht

 

[sf3978]

...
Hier scheint das Script irgendwo hängen zu bleiben, oder aber auf irgendetwas zu warten.

cuma hat im trunk schon die erforderlichen Änderungen gemacht:

#if supported by wget, [COLOR="Red"]don't wait forever[/COLOR]: 
wget --version >/dev/null 2>&1 && SHORTWAIT="-T 30 -t 1" 
ip=$(wget $SHORTWAIT -q -O - http://checkip.dyndns.org | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')

 

[SaschaBr]

Danke für die Info.
Hatte gestern noch auf trunk 5672 geuppt, wodurch dann auch eine Konfigurationsoberfläche (r5669) hinzukam. Danach musste ich opendd neu konfigurieren, aber seitdem läufts.

 

[SaschaBr]

Gestern Abend wollte ich von einem Kumpel aus auf meinen FTP-Server zugreifen, jedoch konnte Filezilla nicht zu der aufgelösten IP verbinden. Ich habe mich dann in meinem DynDNS-Account angemeldet, und nachgeschaut, wann zuletzt aktualisiert wurde. Und siehe da, die Aktualisierung hatte (ausgerechnet an diesem Tag) nicht geklappt.
Grade eben habe ich dann im Syslog meiner Box nachgesehen, und außer dieser Zeile

Sep 24 04:33:09 fritz user.notice info: Run OpenDD after IP-change.

stand nichts im Log.

Diese Nacht hat dann wieder alles ganz normal funktioniert:

Sep 25 04:32:03 fritz user.notice info: Run OpenDD after IP-change.
Sep 25 04:32:09 fritz daemon.info opendd[10998]: -- running OpenDD 0.7.9 in normal mode
Sep 25 04:32:09 fritz daemon.info opendd[10998]: main() : getting my ip address : 77.182.xxx.xxx
Sep 25 04:32:09 fritz daemon.info opendd[10998]: dyndns() : Setting SSL trust certificate store to /tmp/flash/opendd/opendd.pem
Sep 25 04:32:10 fritz daemon.err opendd[10998]: Warning : certificate cannot be verified with trust store : unable to get issuer certificate locally
Sep 25 04:32:10 fritz daemon.info opendd[10998]: dyndns() : connected to members.dyndns.org:443
Sep 25 04:32:10 fritz daemon.info opendd[10998]: dyndns() : GET /nic/update?system=dyndns&hostname=Mein.Server.de&wildcard=OFF&backmx=NO&offline=NO&myip=77.182.xxx.xxx HTTP/1.0
Sep 25 04:32:10 fritz daemon.info opendd[10998]: listen_response() : HTTP/1.1 200 OK
Sep 25 04:32:10 fritz daemon.info opendd[10998]: listen_response() : Date: Sat, 25 Sep 2010 02:32:10 GMT
Sep 25 04:32:10 fritz daemon.info opendd[10998]: listen_response() : Server: Apache
Sep 25 04:32:10 fritz daemon.info opendd[10998]: listen_response() : Content-Type: text/plain
Sep 25 04:32:10 fritz daemon.info opendd[10998]: listen_response() : Connection: close
Sep 25 04:32:10 fritz daemon.info opendd[10998]: listen_response() : good 77.182.xxx.xxx
Sep 25 04:32:10 fritz daemon.info opendd[10998]: listen_response() : The update was successful, and the hostname is now updated.
Sep 25 04:32:10 fritz daemon.err opendd[10998]: listen_response() : cannot send mail report
Sep 25 04:32:10 fritz daemon.info opendd[10998]: dyndns() : connection closed
Sep 25 04:32:10 fritz daemon.info opendd[10998]: main() : dyndns() exit normally

Nach dem Durchsehen der Logs der letzten Tage war dies wohl das erste mal, dass das nicht funktioniert hat.
Nur ein dummer Zufall?

 

[sf3978]

...
Nur ein dummer Zufall?

Es muss kein Zufall gewesen sein. Wenn ich cuma richtig verstanden habe, ist opendd aus dem trunk, von "checkip.dyndns.org" abhängig. Und "checkip.dyndns.org" funktioniert nicht immer zuverlässig. Wenn sich deine öffentliche IP-Adresse täglich ändert, dann könntest Du auch meine opendd-Version benutzen. Meine Version ermittelt die öffentliche IP-Adresse aus showdsldstat (d. h. aus der Box).

 

[Nimrod]

Danke erst mal an die Leute die sich hier reingehängt haben! Ich habe inadyn noch nie zum Laufen gebraucht obwohl ich schon öfters die Meldung hatte dass mein Account angeblich aktualisiert worden wäre.

Die einzigen Sachen wo ich nicht recht weiter weiß ist ob es mit libcrypto noch Probleme gibt (Rebootschleife) und ob ich auch per GUI meine Accounts auf verschiedene ifaces setzen kann. Ich nutze meine 2. PVC für einen anderen Account. Solange man bei einem Anbieter ist gehts ja, aber wenn man bei zwei verschiedenen ist dann müsste man das glaube ich eh von Hand eintragen.

 

[sf3978]

...
Die einzigen Sachen wo ich nicht recht weiter weiß ist ob es mit libcrypto noch Probleme gibt (Rebootschleife) und ob ich auch per GUI meine Accounts auf verschiedene ifaces setzen kann. Ich nutze meine 2. PVC für einen anderen Account. Solange man bei einem Anbieter ist gehts ja, aber wenn man bei zwei verschiedenen ist dann müsste man das glaube ich eh von Hand eintragen.

Meinst Du inadyn oder opendd? opendd hat mit libcrypto keine Probleme. Man kann (könnte) auch Port 80 benutzen, statt 443 (ssl). Für/Von opendd muss nicht unbedingt ein iface benutzt werden. opendd kann die öffentliche IP-Adresse auch aus showdsldstat beziehen oder aus einer Datei auf der Box. Bei welchen DynDNS-Providern sind deine Accounts?