DDNS Updater Entwicklung & Fehlerbereinigung - Development & bugfixing

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

Status
Für weitere Antworten geschlossen.
Top!!!

Wenn es länger dauert, einen Bug-Report zu schreiben, als das Update bereitzustellen, dann ist das ein Traum-Service-Level!

Vielen Dank! CPU-Load = 0%

Viele Grüße


Matthias
 
IPv6 steht am Strassenrand....

Hi, wollt mal leise fragen, ob der aufgehende IPv6-Stern schon auf der ToDo-Liste steht, und wann da mit den ersten Versionen zu rechnen ist. Zumindest freedns.afraid.org , zB, ist da ja schon aktiv...


Ho Ho Ho,...
 
Hi, wollt mal leise fragen, ob der aufgehende IPv6-Stern schon auf der ToDo-Liste steht, und wann da mit den ersten Versionen zu rechnen ist. Zumindest freedns.afraid.org , zB, ist da ja schon aktiv...


Ho Ho Ho,...
leider noch nicht, habe zuviel andere Projekte. Ein komplett neuer DDNS updater + Daemon wird noch ein Weilchen dauern, freedns.afraid.org könnte aber früher kommen.
 
war nur rein informativ...
und danke! =b
 
Hallo QTip

Ich bin glücklicher Nutzer des DDNS updaters und sehr zufrieden damit. Nun musste ich leider feststellen, dass dieser nach dem gestrigen Update auf die neue DSM 5.0 Beta aufgehört hat zu funktionieren. Darum habe ich mich ein bisschen genauer damit befasst und auch herausgefunden an was es liegt. Ich werde darum meine Erkenntnisse hier teilen, damit du evtl. Arbeit an einem Update einsparen kannst. Möglicherweise können sogar auch die DSM 4.3 Nutzer von der umgeschriebenen Benutzerprüfung profitieren, jedoch konnte ich sie nicht testen. Doch alles der Reihe nach.

  1. Init_3rdparty lässt sich nicht mehr starten (da ich gesehen hab, dass du auch von diesem Paket Mitentwickler bist, kommt das auch gleich hier rein :) )
    Hier ist der Grund, dass der Pfad der Konfigurationsdatei von Apache httpd geändert hat. Es ist nicht mehr /usr/syno/apache/conf/httpd.conf-sys sondern neu /etc/httpd/conf/httpd.conf-sys. Den Pfad angepasst im start-stop-status Script läuft Init_3rdparty wieder.
  2. Trotz Installation von Init_3rdparty scheint PHP auf dem apache-sys nicht zu funktionieren.
    Synology liefert mit DSM 5.0 Beta keine libphp5.so mehr mit. Es läuft neu alles über php-fpm. Da ich keine Lust hatte, an irgendwelchen php-Konfigurationen rumzuschrauben oder libphp5.so selber zu kompilieren, hab ich die einfache Variante gewählt und per ipkg das Paket php-apache installiert, welches die libphp5.so unter /opt/libexec/libphp5.so ablegt. Den Pfad angepasst in der 3rdparty.conf vom Init_3rdparty Paket liess PHP wieder perfekt funktionieren.
  3. Beim Zugriff auf DDNS Updater (und anderen Paketen von dir) kommt es immer nur zur Anzeige von "403 Forbidden".
    Offenbar hat Synology für DSM 5.0 Beta an ihrer Authentifizierungsmethode geschraubt, jedenfalls gibt es das file /tmp/current.token, auf dem die Authentifizierung basierte, nicht mehr. Ich habe mir das Ganze einmal angeschaut, mir auch deinen Thread über Anwendungsberechtigung (http://www.synology-forum.de/showth...gung-und-SynoToken-f%FCr-3rdparty-Anwendungen) durchgelesen, Manuals von Synology studiert und dann noch etwas experimentiert. Ich denke ich bin zu einer guten und evtl. auch von Synology so gewollten Lösung gekommen. Hier ist der Code:
    PHP:
    if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])){
         $clientIP = $_SERVER['HTTP_X_FORWARDED_FOR'];
    } elseif (isset($_SERVER['HTTP_X_REAL_IP'])){
         $clientIP = $_SERVER['HTTP_X_REAL_IP'];
    } else {
         $clientIP = $_SERVER['REMOTE_ADDR'];
    }
    putenv('HTTP_COOKIE='.$_SERVER['HTTP_COOKIE']);
    putenv('REMOTE_ADDR='.$clientIP);
    $login = array();
    exec("/usr/syno/synoman/webman/login.cgi", $login);
    $token = explode('"', $login[4]);
    putenv('QUERY_STRING=SynoToken='.$token[3]);
    $user = exec("/usr/syno/synoman/webman/modules/authenticate.cgi");
    if ($user === '') {
       exit("403 Forbidden");
    }
    Grösstenteils ist es übernommener Code. Neu ist das Aufrufen von /usr/syno/synoman/webman/login.cgi. Dieses Script kann man auch vom Webbrowser aus aufrufen und wenn man angemeldet ist, wird das SynoToken angezeigt. Im Code wird das SynoToken nach $token[3] extrahiert und dann in die Umgebungsvariable QUERY_STRING abgelegt. Der Aufruf von /usr/syno/synoman/webman/modules/authenticate.cgi liefert nun den korrekten Benutzernamen auch mit aktivierter Option "Schutz gegen Cross-Site-Request-Forgery-Attacken verbessern". Offenbar ignoriert die authenticate.cgi den QUERY_STRING, wenn die CSRF-Option ausgeschaltet ist, denn mein Code funktioniert sowohl mit, als auch ohne aktivierte CSRF-Option.
Nach diesen 3 Anpassungen funktionierte der DDNS updater wieder wie gewohnt.

Ich hoffe meine Ausführungen sind irgendwie nützlich, auf jeden Fall aber ein ganz grosses DANKESCHÖN für deine Arbeit. Deine Tools sind wirklich nützlich, funktionieren einwandfrei und sind dazu auch noch schön gestaltet!

Gruss
mrsandman
 
Hallo!
Welches Paket von Apache hast du genau verwendet und von wo hast du es bezogen!
Kannst du die hier erwähnten Schritte etwas genauer beschreiben. Ich würde meinen Updater auch gern wieder in Betrieb nehemen und verstehe deine Schritte nicht ganz.
Vielen Dank
 
Hallo QTip

Ich bin glücklicher Nutzer des DDNS updaters und sehr zufrieden damit. Nun musste ich leider feststellen, dass dieser nach dem gestrigen Update auf die neue DSM 5.0 Beta aufgehört hat zu funktionieren. Darum habe ich mich ein bisschen genauer damit befasst und auch herausgefunden an was es liegt. Ich werde darum meine Erkenntnisse hier teilen, damit du evtl. Arbeit an einem Update einsparen kannst. Möglicherweise können sogar auch die DSM 4.3 Nutzer von der umgeschriebenen Benutzerprüfung profitieren, jedoch konnte ich sie nicht testen. Doch alles der Reihe nach.
  1. Init_3rdparty lässt sich nicht mehr starten (da ich gesehen hab, dass du auch von diesem Paket Mitentwickler bist, kommt das auch gleich hier rein :) )
    Hier ist der Grund, dass der Pfad der Konfigurationsdatei von Apache httpd geändert hat. Es ist nicht mehr /usr/syno/apache/conf/httpd.conf-sys sondern neu /etc/httpd/conf/httpd.conf-sys. Den Pfad angepasst im start-stop-status Script läuft Init_3rdparty wieder.
  2. Trotz Installation von Init_3rdparty scheint PHP auf dem apache-sys nicht zu funktionieren.
    Synology liefert mit DSM 5.0 Beta keine libphp5.so mehr mit. Es läuft neu alles über php-fpm. Da ich keine Lust hatte, an irgendwelchen php-Konfigurationen rumzuschrauben oder libphp5.so selber zu kompilieren, hab ich die einfache Variante gewählt und per ipkg das Paket php-apache installiert, welches die libphp5.so unter /opt/libexec/libphp5.so ablegt. Den Pfad angepasst in der 3rdparty.conf vom Init_3rdparty Paket liess PHP wieder perfekt funktionieren.
  3. Beim Zugriff auf DDNS Updater (und anderen Paketen von dir) kommt es immer nur zur Anzeige von "403 Forbidden".
    Offenbar hat Synology für DSM 5.0 Beta an ihrer Authentifizierungsmethode geschraubt, jedenfalls gibt es das file /tmp/current.token, auf dem die Authentifizierung basierte, nicht mehr. Ich habe mir das Ganze einmal angeschaut, mir auch deinen Thread über Anwendungsberechtigung (http://www.synology-forum.de/showth...gung-und-SynoToken-f%FCr-3rdparty-Anwendungen) durchgelesen, Manuals von Synology studiert und dann noch etwas experimentiert. Ich denke ich bin zu einer guten und evtl. auch von Synology so gewollten Lösung gekommen. Hier ist der Code:
    PHP:
    if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])){
         $clientIP = $_SERVER['HTTP_X_FORWARDED_FOR'];
    } elseif (isset($_SERVER['HTTP_X_REAL_IP'])){
         $clientIP = $_SERVER['HTTP_X_REAL_IP'];
    } else {
         $clientIP = $_SERVER['REMOTE_ADDR'];
    }
    putenv('HTTP_COOKIE='.$_SERVER['HTTP_COOKIE']);
    putenv('REMOTE_ADDR='.$clientIP);
    $login = array();
    exec("/usr/syno/synoman/webman/login.cgi", $login);
    $token = explode('"', $login[4]);
    putenv('QUERY_STRING=SynoToken='.$token[3]);
    $user = exec("/usr/syno/synoman/webman/modules/authenticate.cgi");
    if ($user === '') {
       exit("403 Forbidden");
    }
    Grösstenteils ist es übernommener Code. Neu ist das Aufrufen von /usr/syno/synoman/webman/login.cgi. Dieses Script kann man auch vom Webbrowser aus aufrufen und wenn man angemeldet ist, wird das SynoToken angezeigt. Im Code wird das SynoToken nach $token[3] extrahiert und dann in die Umgebungsvariable QUERY_STRING abgelegt. Der Aufruf von /usr/syno/synoman/webman/modules/authenticate.cgi liefert nun den korrekten Benutzernamen auch mit aktivierter Option "Schutz gegen Cross-Site-Request-Forgery-Attacken verbessern". Offenbar ignoriert die authenticate.cgi den QUERY_STRING, wenn die CSRF-Option ausgeschaltet ist, denn mein Code funktioniert sowohl mit, als auch ohne aktivierte CSRF-Option.
Nach diesen 3 Anpassungen funktionierte der DDNS updater wieder wie gewohnt.

Ich hoffe meine Ausführungen sind irgendwie nützlich, auf jeden Fall aber ein ganz grosses DANKESCHÖN für deine Arbeit. Deine Tools sind wirklich nützlich, funktionieren einwandfrei und sind dazu auch noch schön gestaltet!

Gruss
mrsandman
Vielen Dank für deine Ausführungen
zu 1. und 2. Die Anpassungen für Init_3rdparty mit php-fpm sind soweit abgeschlossen und die Version 1.7 wird, wenn Nichts mehr dazwischen kommt, heute Abend released.

zu 3. dazu bin ich gestern noch nicht gekommen, ich schau es mir mal an. Danke für den Code, so ungefähr steht es auch im Developer-PDF.
 
Zuletzt bearbeitet:
Hallo!
Welches Paket von Apache hast du genau verwendet und von wo hast du es bezogen!
Kannst du die hier erwähnten Schritte etwas genauer beschreiben. Ich würde meinen Updater auch gern wieder in Betrieb nehemen und verstehe deine Schritte nicht ganz.
Vielen Dank

QTip hat soeben das neue Init_3rdparty-Paket (v1.7) Update veröffentlicht. Nachdem dieses Update installiert ist, sollte der DDNS updater wieder funktionieren. Zu beachten ist, dass man vorläufig (das heisst, bis ein mit DSM 5.0 Beta kompatibles DDNS updater Update kommt) die Option Systemsteuerung -> Sicherheit -> Schutz gegen Cross-Site-Request-Forgery-Attacken verbessern deaktivieren muss. Ansonsten erhält man den Fehler "403 Forbidden".
 
Entschuldigt die Frage, aber wo hat er dieses bereit gestellt?
 
Entschuldigt die Frage, aber wo hat er dieses bereit gestellt?

Du kannst unter Paket-Zentrum -> Einstellungen -> Paketquellen -> Hinzufügen die Paketquelle CPHub mit Ort http://www.cphub.net eintragen. Danach findest du das Paket unter Paket-Zentrum -> Community -> Init 3rdparty. Da ich davon ausgehe, dass du das Paket schon installiert hast, sollte es aber eigentlich genügen, nachdem du die Paketquelle hinzugefügt hast, einmal im Paket-Zentrum auf Aktualisieren zu klicken. Danach sollte das verfügbare Update im Paket-Zentrum unter Aktualisieren angezeigt werden.
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat