I am about to start an indepth project for the company I work for. We want to use a PHP front end and be able to make updates to DNS dynamically.
I was wondering if I can get some opinions on where to start.
Also, what I should use... (ie, nsupdate.c, etc.)
Any help would be appreciated.
Thanks in advance.
>> get some opinions on where to start
Start learning Perl. PHP, often installed as mod_php, is not capable to perform sysem task to automate update, unless you change the file permission (insecure) to be writable by the user Apache runs as.
Start here -> http://forums.devshed.com/showthread.php?s=&threadid=23249&forumid=6
One more question...
What if I used PHP to interact with shell scripts?
Would that be a good solution?
>> What if I used PHP to interact with shell scripts?
Your shell/CGI scripts written in Perl must then be setuid root.
>> Would that be a good solution?
PHP is not a good solution in the first place. And whatever frontend doesn't make any difference, since those scripts are not doing the actual works anyway.
Anyhow, do not change whatever file permission from 644 to 646 or 666 to make it writable by the user Apache runs as.
The way we handled this problem was as follows:
Version 1:
We kept all our domain information in a SQL server database and when I first joined our company, my co-workers and I knew very little perl. So I wrote a Delphi program to query the database and write out all the data into the dns files. The Delphi program would then zip all the files and ftp the data over to the linux boxes and then send a request to a perl program that was listening on a specific port for a command from a specific IP. The perl program on the other end would unzip the files, convert CR/LF to LF in all the files, rebuild the .cf file and then restart named. Even though my co-worker and I knew very little perl at that time, we managed to hack some pretty decent working code using the Perl Cookbook and a few hours of elbow grease. Note that if someone tried to connect to the port from a different IP, the perl script would disconnect the connection immediately. In version 1 of the program, the Delphi program would ftp the zip file to one name server, send the perl program the appropriate command and then wait 15 mins or so before going to the next name server (assuming that the perl script + named took 15 mins to reload all the data). This is a bad idea if named takes more than 15 mins to restart, but we kept increasing the time delay in the Delphi code, as the number of domains increased.
Version 2:
We got better at perl and discovered how to make perl on *nix boxes connect to SQL Server on Windows. So we modified the perl script as follows: All the Delphi program did now was connect on the specific port and send the appropriate command to the perl script. The perl script would then connect to the SQL server and build all the dns data by itself. This saved us the time taken by the previous version to zip up and ftp the files over. After creating the necessary files, the perl script would then restart the name server. My buddy found a way (highly incompatible) to also determine when named was done reloading the data by monitoring the CPU activity! So the perl script would restart named and monitor the CPU load till named was done reloading. Then it would send back a response to the Delphi program saying that named was ready to recieve queries. The Delphi program would then send the command to the next name server. Thus we didn't have to depend upon guessing a delay time before sending the command to the next name server. This scheme's been working well for us for at least 1.5 years!
Hope this helps.
Why bother going thru all these troubles when there is a better named alternative - tinydns (in djbdns package)?
tinydns is highly secure, efficient and reliable. Writing a script to do dynamic updating is as easy as writing a "Hello World" script.