DynDNS mit ISPConfig

Dieses Thema im Forum "Entwicklerforum" wurde erstellt von worfinator, 3. Mai 2014.

  1. worfinator

    worfinator New Member

    Hallo zusammen,

    ich habe bei mir mal folgenden Einfall umgesetzt:
    DynDNS Service – Marke Eigenbau | Tim Herbst

    Problem nun:
    Grundsätzlich funktioniert das schon.

    Praktisch habe ich aber ein Problem:
    Die “Serial” der Zone wird durch das PHP-Skript nicht hochgesetzt. Dadurch funktioniert die Replikation zu meinem zweiten DNS nicht.

    Hat jemand dazu einen Einfall?

    Grüße,
    Marc.
     
  2. Till

    Till Administrator

    Du müsstest noch ein update der serial in das script einbauen, nach dem update des a-records. so in der art:

    Code:
    $zone = $client->dns_zone_get($session_id, array('origin' => 'meinedomain.tld.'));
    $zone['serial'] = $zone['serial'] + 1;
    $client->dns_zone_update($session_id, 0, $zone['id'], $zone);
    Der Code ist jetzt nicht getestet :)
     
  3. worfinator

    worfinator New Member

    Hey Till!

    Danke für deine Hilfe!

    Hab es nun wie folgt gebaut:
    Code:
    $zone = $client->dns_zone_get($session_id, 666);
    $zone['serial'] = $zone['serial'] + 1;
    $affected_rows = $client->dns_zone_update($session_id, 0, $zone['id'], $zone);
    		
    echo 'Number of records that have been changed in the database: '.$affected_rows.'<br>';
         
    Die 666 muss gegen die ID der Zone aus der MySQL ersetzt werden.
    Rennt 1a.

    Vielen Dank nochmal!
     
  4. stonegate

    stonegate New Member

    [SOLVED but Questions left] Siehe ganz unten in meiner Reply

    Hallo zusammen,

    ich habe auch das Tutorial von Tim Herbst verwendet.

    Leider bekomme ich nach Übergabe der Parameter an das SOAP Script (Remote API) gar kein Feedback. Einfach nur eine leere weisse Seite im Internet Explorer. Lasse ich etwas weg oder gebe ein falsches Passwort an, moniert das Skript dies aber ordentlich. Daher gehe ich davon aus, dass das Remote Script eigentlich funktioniert. Im Opera Browser bekomme ich immerhin:

    Meine Files sind (anonymisiert):

    Den Benutzer "remoteuser1" habe ich unter "entfernte Benutzer" mit allen Rechten versehen die es gab. Allerdings habe ich gelesen man soll eine "DNS Zone Function" für Remote User aktivieren. Mit DNS habe ich leider gar nichts zur Auswahl für remote User. Woran könnte das liegen ?

    Nachtrag:

    Habe eben mal aus der SQL Tabelle "remote_users" die Rechte des entfernten Benutzers ausgelesen:

    Vielleicht hilft das schon mal an dieser Stelle.

    Nachtrag 2:

    Ich konnte feststellen, dass mein (aktuellste Version Stable) ISPConfig 3 mir überhaupt gar keine DNS Funktionen für Remote User zur Aktivierung anbietet. Nach einigem Code-digging habe ich herausgefunden das mir folgende Einträge in der SQL Tabelle "remote_users" beim jeweiligen Benutzer unter "remote_functions" fehlen:

    Ich habe diese jetzt von Hand eingefügt. Aber es scheint ein Bug zu sein, dass man bei ISPConfig für Remote User keine DNS Funktionen aktivieren kann. Die remote.conf.php existiert jedoch korrekt in /usr/local/ispconfig/Interface/web/dns/lib

    Warum er die nicht includet bzw. die Funktionen daraus nicht zur Aktivierung für Remote User anbietet weiss ich leider nicht. Ich bin jetzt einen Schritt weiter. Allerdings sagt er mir nun:

    Nachtrag 3:

    Das scheint jedoch korrekt zu sein - der Record wurde mit der neuen IP Adresse geupdated.

    Soap_config.php
    PHP:
    <?php
     
    $username 
    'remoteuser1';
    $password 'remotepass1';
     
    /*
    $soap_location = 'http://localhost:8080/ispconfig3/interface/web/remote/index.php';
    $soap_uri = 'http://localhost:8080/ispconfig3/interface/web/remote/';
    */
     
    $soap_location 'https://server123.de:8181/remote/index.php';
    $soap_uri 'https://server123.de:8181/remote/';
     
    ?>
    update.php
    PHP:
    <?php
        
    require('soap_config.php');
         
    $client = new SoapClient(null, array('location' => $soap_location'uri' => $soap_uri'trace' => 1'exceptions' => 1));
         try {
             if(
    $session_id $client->login($_REQUEST['username'],$_REQUEST['password'])) {
                echo 
    'Logged successfull. Session ID:'.$session_id.'<br />';
            }
     
            
    //* Parameters
            
    $id $_REQUEST['id'];
             
    //* Get the dns record
            
    $dns_record $client->dns_a_get($session_id$id);
             
    //* Change active to inactive
            
    $dns_record['data'] = $_REQUEST['ip'];
             
    $affected_rows $client->dns_a_update($session_idnull$id$dns_record);
             echo 
    'Number of records that have been changed in the database: '.$affected_rows.'<br>';
             if(
    $client->logout($session_id)) {
                echo 
    'Logged out.<br />';
            }
         } catch (
    SoapFault $e) {
            echo 
    $client->__getLastResponse(); die('SOAP Error: '.$e->getMessage());
        }
    ?>
    ~
    Ich rufe das ganze dann zunächst testweise im Browser unter folgender URL auf:

    (die URL habe ich hier der Lesbarkeit halber absichtlich am Anfang mit einem Leerschritt "kaputt" gemacht. Der Leerschritt bei "Password" wird irgendwie hier beim Quoten aus Versehen eingefügt. Die URL wird aber richtig ohne Leerschritte von mir aufgerufen )

    ID 27 ist laut der Tabelle dns_rr vom ISPConfig3 mein a-Record für die gewünschte Subdomain.


    Ich habe aktuell keine Idee mehr warum er nichts tut. Könnt ihr mir bitte einen Tip geben wo es haken könnte ?

    Weiterhin habe ich dann noch eine Verständnisfrage:

    Ich möchte das ganze gerne auch für meine Freunde anbieten (habe das quasi schon versprochen :-/). Wie sieht das ganze denn bei MultiUserbetrieb aus ? Am liebsten wäre es mir wenn ich 1 Updatescript verwenden kann und nicht für jeden User einen eigenen Remoteuser anlegen muss, dann für jeden User einen eigenen Webspace/Clientaccount im ISPconfig und dann jedem noch von Hand die Scripte anpassen.

    Kann man das ganze nicht irgendwie galant mit einer Update URL für alle User lösen ? So dass keiner dem anderen seinen Account updaten kann ? Kann man vielleicht ISPConfig3 dazu bringen, dass ein angelegter "normaler" User auch per Remote API auf seine - und NUR seine - eigenen DNS Records zugreifen kann ? Das wäre eigentlich die perfekte Lösung.

    Vielen Dank für eure Hilfe.

    Stoney
     
    Zuletzt bearbeitet: 8. Mai 2014
  5. stonegate

    stonegate New Member

    Noch 2 Fragen

    Hallo zusammen,
    Hi Till,

    Ich konnte mein Problem zunächst einmal lösen habe aber meine Gedanken und Fragen sowie den Lösungsweg (für andere dokumentiert) hier im obigen Beitrag weiter reingeschrieben. Vielleicht helfe ich jemand anderem damit.

    Es bleiben jedoch 2 Punkte offen. Wäre toll wenn mir da noch jemand helfen kann:

    1) Remote User können nicht über ISPConfig mit DNS Rechten versehen werden. Dazu fehlt schlichtweg die Checkbox für "DNS Funktionen". Wieso ? Ich weiss es nicht.

    Nachtrag: Auch dieses Problem konnte ich nun korrekt lösen: Man muss als Admin in ISPConfig unter "System -> "ISPConfig Benutzer" dem Admin das "DNS" Modul aktivieren. Dann speichern, ausloggen und neu einloggen. Erst DANN kann man die DNS Rechte für Remote User setzen. Da muss man erst mal drauf kommen ;)

    Es bleiben also folgende Fragen als einzige in diesem Thread übrig:

    2) Als generelle Verständnisfrage (siehe auch nochmal im obigen Beitrag am Ende): Wenn ich mehreren Usern DynDNS mit ISPConfig einrichten will, wie kann ich dazu eine globale Update.php URL und verschiedene Logins verwenden? Ich möchte eigentlich nicht für jeden einen eigenen Remote User anlegen müssen. Am schönsten wäre es doch wenn man normale ISPConfig3 User anlegt und diese für die "Remote API" berechtigen kann. Somit können diese User dann auch ihr Passwort benutzen und man muss als Admin nicht 2 verschiedene Accounts einrichten und dann pro User nochmal eine eigene update.php mit den jeweiligen Credentials pflegen.

    Welche Möglichkeit gäbe es also, für verschiedene User eine gleiche DNS Update URL zu verwenden, so dass jeder sich seinen eigenen Hostnamen (Subdomain) mit einem eigenen Passwort und Usernamen pflegen kann ?
    Wie kann ich verhindern, dass mir die unterschiedlichen User nicht unterschiedliche IDs verändern? Es darf ja nicht sein, dass alle den selben Usernamen etc. verwenden und dann JEDE beliebige DNS ID verändern können. Wie könnte man hier Missbrauch in einem Multiuserbetrieb verhindern ?

    Besten Dank schon im Voraus für eure Gedanken.

    Danke
    Stoney
     
    Zuletzt bearbeitet: 8. Mai 2014
  6. Till

    Till Administrator

    Zu 1) Es gibt doch mehr als genug checkboxen für die dns funktionen. Kopiert aus ispconfig 3.0.5.4p1:

    DNS Zone Funktionen

    DNS a Funktionen

    DNS aaaa Funktionen

    DNS Alias Funktionen

    DNS cname Funktionen

    DNS hinfo Funktionen

    DNS mx Funktionen

    DNS ns Funktionen

    DNS ptr Funktionen

    DNS rp Funktionen

    DNS srv Funktionen

    DNS txt Funktionen

    Zu 2) Das liegt doch ganz bei Dir, wie Du Dein script schreibst und wie Du die usereingaben validierst. Mit ispconfig bzw. dem api hat das nichts zu tun, denn das remote api stellt eine low level schnittstelle mit admin rechten bereit.
     
  7. stonegate

    stonegate New Member

    Hi Till,

    wie gesagt - die Checkboxen tauchen erst auf wenn man den Admin auch das DNS Modul freischaltet. Das Thema ist gelöst.

    Was die Validierung angeht, so sehe ich den Wald vielleicht momentan einfach vor lauter Bäumen nicht. :confused: :D :confused:

    Du meinst also, man sollte in die update.php noch eine Authentifizierung einbauen. Ok - gut. Allerdings kommt mir gerade keine Idee wie ich dann verhindern will, dass ein authentifizierter Benutzer auch nur seinen eigenen Datensatz - seine ID - updaten darf. Für Vorschläge wäre ich dankbar. Gibt es vielleicht sogar ein Example Script das genau das tut was ich möchte ?

    VG
    Stoney
     
  8. worfinator

    worfinator New Member

    Mein Script geht nicht mehr :(

    Grund ist das Update und wahrscheinlich die neue .htaccess

    Jemand nen Einfall, wie ich das gelöst kriege ausser .htaccess löschen?
     
  9. nowayback

    nowayback Well-Known Member

    Code:
    allow from
     
  10. worfinator

    worfinator New Member

    In der .htaccess? Da ich die API aufrufe nur von localhost aus mache, würde das wahrscheinlich funktionieren, danke für den Einfall.

    Nachteil wäre, dass ich das Script von ispconfig zur automatischen Generierung der .htaccess wohl nicht mehr nutzen könnte...
     
  11. worfinator

    worfinator New Member

    Kurzer Zwischenstand dazu:
    AuthType Basic
    AuthName "Login"
    AuthUserFile /usr/local/ispconfig/interface/.htpasswd
    require valid-user
    allow from 127.0.0.1

    Also so funktioniert es bei mir nicht. Obwohl meine Anfragen definitv von localhost kommen.

    Irgendwer nen Einfall dazu?
     
  12. worfinator

    worfinator New Member

    Neuer Versuch hiermit:
    AuthType Basic
    AuthName "Login"
    AuthUserFile /usr/local/ispconfig/interface/.htpasswd
    require valid-user
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
    Satisfy ANY

    Damit klappt es bestens!
     
    Zuletzt bearbeitet: 29. Aug. 2014
  13. worfinator

    worfinator New Member

    Anbei mein CronJob um die .htaccess jede Stunde neu zu generieren und die benötigten Zeilen für dynDNS mit aufzunehmen:
    Code:
    45              6-23    *       *       *       /usr/bin/php -qc/etc /usr/local/ispconfig/server/scripts/ispconfig_htaccess.php
    46              6-23    *       *       *       printf "\nOrder deny,allow" >> /usr/local/ispconfig/interface/web/.htaccess
    47              6-23    *       *       *       printf "\nDeny from all" >> /usr/local/ispconfig/interface/web/.htaccess
    48              6-23    *       *       *       printf "\nAllow from 127.0.0.1" >> /usr/local/ispconfig/interface/web/.htaccess
    49              6-23    *       *       *       printf "\nSatisfy ANY" >> /usr/local/ispconfig/interface/web/.htaccess
    
    Läuft jetzt wieder 1a - auch mit dem zusätzlichen (sehr sinnvollen) .htaccess-Schutz.
    Kann gerne als Vorlage genutzt werden :)

    Grüße
    Marc.
     
    Zuletzt bearbeitet: 29. Aug. 2014
  14. worfinator

    worfinator New Member

    Grad noch eine kleine Korrektur an dem Cron-Job-Skript vorgenommen...
     
  15. tomnick

    tomnick Member

    Das Script benötigt ja die "soap_config.php", nur kann ich die nirgends finden. Weiss jemand wo die versteckt ist? Hab mich schon wund gesucht. Muss diese dann in das Verzeichnis kopiert werden, wo das update script liegt? Vielen Dank für eine kurze Hilfe und viele Grüße

    Tom
     
  16. tomnick

    tomnick Member

    Für alle die das gleiche Problem haben:

    Die "soap_config.php" liegt nicht irgendwo in dem Installtaionsverzeichniss von ISPConfig auf dem Server wo ich gesucht habe sondern in der downloadbaren Datei ISPConfig-3.0.5.3.tar.gz dort im Verzeichnis "remoting_client\examples".
     

Diese Seite empfehlen