PDA

Bekijk Volledige Versie : dns_raw_save_post.sh werkt niet



huizinga
02/10/12, 10:39
hallo,

Ik ben bezig met de implementatie van DNSSEC in voor mijn Directadmin server. Nu loop ik tegen een, ik denk fout in DA aan, waarvan ik hoop dat iemand een idee heeft hierover.

Ik heb in een opstelling 2 DA servers verbonden via multi-server-setup. Dit werkt prima. als ik een zone aanmaak op server1 zie ik hem direct op server2 en andersom. updaten en deletel hetzelfde, werkt perfect dus.

Nu las ik (http://www.directadmin.com/features.php?id=1094) dan ik dat het script /usr/local/directadmin/scripts/custom/dns_raw_save_post.sh aangeroepen werd op elke (remote) DA box na een update van de DNS via multi-server-setup.

Dit lijkt niet te werken. na wat nazoeken zag ik dat het volgende url aangeroepen worden door DA zelf na elke DNS update:
https://server.mycompany.nl:2222/CMD_API_DNS_ADMIN?action=rawsave&domain=my-company-domain.nl

Ik krijg hierop de volgende foutmelding:
error=1&text=Cannot save raw zone&details=Unable to write file /etc/namedb/my&#45company&#45domain.nl.db &#58 data is empty&#60br&#62
&#60br&#62

Ik verwacht dat deze problemen met elkaar te maken hebben. Het vreemde aan de fout is dat je zou denken dat het updaten van de DNS niet werkt, maar dat werkt dus nog steeds prima..

Heeft iemand een idee?

ps. ik heb het zelfde probleem ook op het DA forum gezet in de hoop een snelle reactie te krijgen:
http://www.directadmin.com/forum/showthread.php?t=44670

Netbulae
03/10/12, 10:13
Hmm, bestaat de directory "/etc/namedb" uberhaubt? Bij mij staat de data van DNS in "/var/named"

huizinga
03/10/12, 10:44
Ik ben inmiddels een heel stuk verder.

De foutmelding komt doordat je naast de GET ook een POST met de zonefile mee moet geven.
Dit staat echter los van het daadwerkelijke probleem, het niet werken van /usr/local/directadmin/scripts/custom/dns_raw_save_post.sh

Inmiddels heb ik volop mailcontact met John (eigenaar Directadmin) gehad en het blijkt een bug te zijn in DA


I found it to be a bug where DA was running as "nobody", so it couldn't find the script because one of the paths was set to 700.
I changed DA to read as root.
Our test box has more open privileges, hence the script worked for me (world readable due how we have our network file system)


Hij heeft mij een gefixte versie gegeven en die werkt perfect.

Zal vermoedelijk in de eerst volgende DA update verwerkt worden.

Toch bedankt voor het meedenken!

The-BosS
03/10/12, 13:58
Hmm, bestaat de directory "/etc/namedb" uberhaubt? Bij mij staat de data van DNS in "/var/named"

Dit zal wel iets Debian/Ubuntu vs RHEL/Centos zijn ;)

Netbulae
03/10/12, 16:00
Ah dat zal zeker, gebruik haast nooit Debian/Ubuntu behalve als het niet anders kan.

Soms wel lastig al die dialecten, fedora is in ieder geval in de directories aan het opschonen en samenvoegen om daar een en ander wat overzichtelijker te maken.