DynDNS mit ISPConfig

[worfinator]

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.

 

[Till]

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

$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

 

[worfinator]

Hey Till!

Danke für deine Hilfe!

Hab es nun wie folgt gebaut:

$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!

 

[stonegate]

[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:

Logged successfull. Session ID:52e15ec0f025a672fc42a6ac3aa12a56
permission_deniedYou do not have the permissions to access this function. SOAP Error: You do not have the permissions to access this function.

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:

mail_domain_get,mail_domain_add,mail_domain_update,mail_domain_delete,mail_domain_set_status,mail_domain_get_by_domain;mail_aliasdomain_get,mail_aliasdomain_add,mail_aliasdomain_update,mail_aliasdomain_delete;mail_mailinglist_get,mail_mailinglist_add,mail_mailinglist_update,mail_mailinglist_delete;mail_user_get,mail_user_add,mail_user_update,mail_user_delete;mail_alias_get,mail_alias_add,mail_alias_update,mail_alias_delete;mail_forward_get,mail_forward_add,mail_forward_update,mail_forward_delete;mail_catchall_get,mail_catchall_add,mail_catchall_update,mail_catchall_delete;mail_transport_get,mail_transport_add,mail_transport_update,mail_transport_delete;mail_relay_get,mail_relay_add,mail_relay_update,mail_relay_delete;mail_whitelist_get,mail_whitelist_add,mail_whitelist_update,mail_whitelist_delete;mail_blacklist_get,mail_blacklist_add,mail_blacklist_update,mail_blacklist_delete;mail_spamfilter_user_get,mail_spamfilter_user_add,mail_spamfilter_user_update,mail_spamfilter_user_delete;mail_policy_get,mail_policy_add,mail_policy_update,mail_policy_delete;mail_fetchmail_get,mail_fetchmail_add,mail_fetchmail_update,mail_fetchmail_delete;mail_spamfilter_whitelist_get,mail_spamfilter_whitelist_add,mail_spamfilter_whitelist_update,mail_spamfilter_whitelist_delete;mail_spamfilter_blacklist_get,mail_spamfilter_blacklist_add,mail_spamfilter_blacklist_update,mail_spamfilter_blacklist_delete;mail_user_filter_get,mail_user_filter_add,mail_user_filter_update,mail_user_filter_delete;mail_filter_get,mail_filter_add,mail_filter_update,mail_filter_delete;server_get,get_function_list,client_templates_get_all,server_get_serverid_by_ip,server_ip_get,server_ip_add,server_ip_update,server_ip_delete;admin_record_permissions;client_get_all,client_get,client_add,client_update,client_delete,client_get_sites_by_user,client_get_by_username,client_change_password,client_get_id,client_delete_everything;domains_domain_get,domains_domain_add,domains_domain_delete,domains_get_all_by_user;sites_cron_get,sites_cron_add,sites_cron_update,sites_cron_delete;sites_database_get,sites_database_add,sites_database_update,sites_database_delete, sites_database_get_all_by_user,sites_database_user_get,sites_database_user_add,sites_database_user_update,sites_database_user_delete, sites_database_user_get_all_by_user;sites_web_folder_get,sites_web_folder_add,sites_web_folder_update,sites_web_folder_delete,sites_web_folder_user_get,sites_web_folder_user_add,sites_web_folder_user_update,sites_web_folder_user_delete;sites_ftp_user_get,sites_ftp_user_server_get,sites_ftp_user_add,sites_ftp_user_update,sites_ftp_user_delete;sites_shell_user_get,sites_shell_user_add,sites_shell_user_update,sites_shell_user_delete;sites_web_domain_get,sites_web_domain_add,sites_web_domain_update,sites_web_domain_delete,sites_web_domain_set_status;sites_web_aliasdomain_get,sites_web_aliasdomain_add,sites_web_aliasdomain_update,sites_web_aliasdomain_delete;sites_web_subdomain_get,sites_web_subdomain_add,sites_web_subdomain_update,sites_web_subdomain_delete

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:

dns_zone_get,dns_zone_get_id,dns_zone_add,dns_zone_update,dns_zone_delete,dns_zone_set_status,dns_templatezone_add,dns_a_get,dns_a_add,dns_a_update,dns_a_delete,dns_aaaa_get,dns_aaaa_add,dns_aaaa_update,dns_aaaa_delete,dns_alias_get,dns_alias_add,dns_alias_update,dns_alias_delete,dns_cname_get,dns_cname_add,dns_cname_update,dns_cname_delete,dns_hinfo_get,dns_hinfo_add,dns_hinfo_update,dns_hinfo_delete,dns_mx_get,dns_mx_add,dns_mx_update,dns_mx_delete,dns_ns_get,dns_ns_add,dns_ns_update,dns_ns_delete,dns_ptr_get,dns_ptr_add,dns_ptr_update,dns_ptr_delete,dns_rp_get,dns_rp_add,dns_rp_update,dns_rp_delete,dns_srv_get,dns_srv_add,dns_srv_update,dns_srv_delete,dns_txt_get,dns_txt_add,dns_txt_update,dns_txt_delete

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:

Logged successfull. Session ID:b07fe3cce601732f56f46800d8836c78
Number of records that have been changed in the database: 0
Logged out.

Nachtrag 3:

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

Soap_config.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
    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_id, null, $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:

http:// dnsupdate.server123.de/update.php?ip=194.12.22.125&username=remoteuser1&password=remotepass1&id=27

(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

 

[stonegate]

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

 

[Till]

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.

 

[stonegate]

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.

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

 

[worfinator]

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?

 

[nowayback]

allow from

 

[worfinator]

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...

 

[worfinator]

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?

 

[worfinator]

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!

 

[worfinator]

Anbei mein CronJob um die .htaccess jede Stunde neu zu generieren und die benötigten Zeilen für dynDNS mit aufzunehmen:

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.

 

[worfinator]

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

 

[tomnick]

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

 

[tomnick]

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".

 

[xxfog]

Hallo und sorry dass ich das alte Thema wieder auf frische, aber es ist nach wie vor aktuell. Ich würde gern wissen ob die Möglichkeit besteht, dieses Feature als Modul oder so umzusetzen. So dass der Kunde in seinem Backendbereich die Einstellung treffen kann.
Ohne dass Änderungen verloren gehen, wenn man ein ISPCONFIG Update einspielt.

Gruß xxfog

 

[xxfog]

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

Problem nun:
Grundsätzlich funktioniert das schon.

Hallo Marc,

leider scheint niemand soetwas als Modul für ISPConfig anbieten zu wollen, was ich überhaupt nicht verstehen kann. Wenn ich sehe was ein dyndns.com Accountmitlerweile kostet.

Gibt es irgendwo eine komplette (aktuelle) Beschreibung wie das ganze nun umgesetzt werden muss? Und vor allem die Antwort auf die Frage, ob es mit einer update.php im Multiuserbetrieb funktioniert?

https://timhaller.de/dyndns-service-marke-eigenbau/ wurde ja 2015 noch mal erweitert, sind diese Änderungen im https://github.com/DIXINFOR/ddns-update-for-ispconfig/blob/master/README.md mit eingeflossen?

Ich möchte meinen Kunden unbedingt dieses feature anbieten. Und möglichst so, dass es "idiotensicher" zu beidenen ist.
Ein Häkchen "dyndns" im ISPConfig und dann als einzige Eingabe die gewünschte Domain oder Subdomain wäre ideal. Noch besser wäre es natürlich wenn der Kunde sich genau wie bei FTP oder Email eigene Zugangsdaten für ddns setzen könnte.

Viele Grüße
xxfog

 

[pjservices.de]

Hallo zusammen,

wir sind aktuell in dabei einen Service zu erstellen, der DynDNS für ISPConfig ermöglicht:

es wird möglich sein:
- pro Account mehrere ISPConfig Server anlegen
- Kunden für DynDNS zu aktivieren/deaktivieren
- Domains für die Anlage von DynDNS Domains freizugeben
- A-Records per klick für DynDNS Updates freizuschalten (es werden direkt Zugangsdaten generiert die nur noch entsprechend in den DynDNS-Client eingetragen werden müssen)

Wir werden noch viele viele weitere Features integrieren.

Die DNS Updates finden dann direkt auf dem ISPConfig Server statt.

- Keine Programmier-Kenntnisse nötig
- sehr einfache Anbindung der Server

Bitte mal per PN melden wenn jemand Interesse hat. Es gibt aber noch kein offizielles Release.

Viele Grüße

 

[dr.h8ball]

Guten Tag miteinander.
Ist das Thema hier noch aktuelle?
Hat sich was getan?

Hallo zusammen,

wir sind aktuell in dabei einen Service zu erstellen, der DynDNS für ISPConfig ermöglicht:

es wird möglich sein:
- pro Account mehrere ISPConfig Server anlegen
- Kunden für DynDNS zu aktivieren/deaktivieren
- Domains für die Anlage von DynDNS Domains freizugeben
- A-Records per klick für DynDNS Updates freizuschalten (es werden direkt Zugangsdaten generiert die nur noch entsprechend in den DynDNS-Client eingetragen werden müssen)

Wir werden noch viele viele weitere Features integrieren.

Die DNS Updates finden dann direkt auf dem ISPConfig Server statt.

- Keine Programmier-Kenntnisse nötig
- sehr einfache Anbindung der Server

Bitte mal per PN melden wenn jemand Interesse hat. Es gibt aber noch kein offizielles Release.

Viele Grüße

Wie ist denn hier der Sachstand?

Danke schön.