Hi I have ISPConfig version 2.0.9 installed on FC4, with a pretty standard installation. I have previously managed to successfully set up websites using the 'Crete DNS' option. Until today, the sites and the DNS settings have been set up flawlessly. Since the last sucessful DNS update, I have made 2 changes to the server, which might be of note:- 1. I have disabled IPv6 since it was slowing down DNS resolution. 2. I have updated server packages using yum. The following packages related to BIND were included in the update:- bind-utils.i386 24:9.3.1-14_FC4 bind.i386 24:9.3.1-14_FC4 bind-chroot.i386 24:9.3.1-14_FC4 I have done some further digging in the database and in ispconfig.log. I can confirm that the DNS records added are in that database, with the status flag set as 'n'. The ispconfig log shows a corresponding 'Signalfile Set: insert' when I add the domain. The site is set up as a vhost in httpd, but there is no reference in the log to ispconfig_bind.lib.php being called. I am at a loss as to why DNS is not being set up, but the site is. Can anybody shed some light on it? Thanks in advance -- Ronnie Davies
Is the status of the DNS record still 'n' after the website was setup? Are the DNS records being written when you change anything in the DNS-Record in DNS-Manager , e.g. the ttl + 1 second, and save it?
The DNS record status field remains as 'n' after the website is setup. If I add an A record to an existing zone, it does not update. If I modify any of the zone header, it does not update the file either (but it does update the DB). Thanks for your speedy reply! -- Ronnie
Not sure if it helps, but I've gone to line 226 of writeconf.php, which contains the query:- select dns_isp_dns.doc_id from dns_nodes,dns_isp_dns WHERE dns_nodes.doc_id = dns_isp_dns.doc_id AND dns_nodes.doctype_id = '".$isp_web->dns_doctype_id."' AND dns_isp_dns.status != '' I have replaced $isp_web->dns_doctype_id with the value listed in the file (1016) and run that query through MySQL. It does return results when I do it manually, meaning that there is either a problem when the query runs in the program or one of the following lines is not working:- if(!empty($dns_write)){ $bind_restart = 0; foreach($dns_write as $write){ $doc_id = $write["doc_id"]; $bind_restart += $mod->dns->make_zonefile($doc_id); $mod->db->query("UPDATE dns_isp_dns SET status = '' where doc_id = '$doc_id'"); } } It is not running the query 'UPDATE dns_isp_dns SET status = '' where doc_id = '$doc_id'' as the status is not changing. Therefore, it is likely that if(!empty($dns_write)) is returning false or the foreach loop is not being entered, perhaps because $dns_write is not an array. If the foreach loop was being entered, the status would be reset. My question, therefore, is whether I could invoke the code manually from the shell and output the query. Thanks in advance -- Ronnie
You can execute the script manually on the shell as root user: /root/42go/php/php -q /root/ispconfig/scripts/writeconf.php
Thanks I've been having a play and have found that the script is exiting when it comes to setting up the zones with a segfault. Having looked further, the line it's failing on is in ispconfig_bind.lib.php. The line reads:- $mod->file->mkdirs($mod->system->server_conf["server_bind_zonefile_dir"]); When I try to echo the contents of $mod->system->server_conf["server_bind_zonefile_dir"], I get a null result. The server_bind_zonefile_dir value in the isp_server table is empty. Should that be the case? Kind regards -- Ronnie
No. In DEBIAN it is /etc/bind Check where your zonefiles are and put this directory in the isp_server table (without trailing slash).
Thanks I've now reinstated the BIND zonefile directory in the DB. It is strange that the value got deleted. There is no log of any user apart from the ispconfig user accessing the DB and all access correlates with modification of site values. The only person using the system was a reseller who does not have access to system settings. On a separate note, one of my resellers has (inadvertently) found another way to break BIND through ispconfig. When entering a new site, if you trail the domain by a period '.', it will not create the primary record and will prevent named from loading. Kind regards -- Ronnie
I can confirm that both of these bugs still exist in 2.2.18 1. When one tries to change and save Server Settings all is fine, but the Zonefiles Dir field empties. I use FC6 and my path is /var/named/chroot/var/named I could see /etc/bind in the form field (which is not correct in my case), but the corresponding field in the database is empty and not updating from ISPConfig. I had to manually enter the correct path into the database field. 2. One of my clients accidentally entered host name with a .(dot), like 'host.', instead of 'host'. It broke named configuration.
1) This happens when the zonefile directoty is not readable for the admispconfig user. Please chmod the directory so that it is world readable. 2) We will check that.
That os the output: [root@ns1 named]# ls -la /var/named/chroot/var/ total 56 drwxr-x--- 5 root named 4096 Mar 14 2003 . drwxr-x--- 6 named named 4096 Nov 12 19:09 .. drwxr-xr-- 4 root named 20480 Dec 2 11:52 named drwxr-x--- 4 root named 4096 Mar 14 2003 run drwxrwx--- 2 named named 4096 Mar 14 2003 tmp Whenever I change anything in Server Settings it does change Zonefiles Dir to something else, but not what is was.
The permissions are wrong. Please do this: Code: chmod 755 /var/named/ chmod 775 /var/named/chroot/ chmod 775 /var/named/chroot/var/ chmod 775 /var/named/chroot/var/named/ chmod 775 /var/named/chroot/var/run/ chmod 777 /var/named/chroot/var/run/named/ cd /var/named/chroot/var/named/ ln -s ../../ chroot
Another bug related to dns. If a client mistypes in co-domains and instead of 'domain.com' writes 'domain .com', notice the space between domain and dot, ISPConfig creates the DNS record. Named of course doesn't start. There must be some sort of check there. Not all people know the exact syntax, etc. I don't know if this is fixed and don't want to try, but some time ago a client of mine created subdomain with '_' (underscore). ISPConfig created this DNS record as well.
Thanks again for implementing this. Two questions: 1. Does this work when creating a domain (not just co-domain) or DNS record? 2. Is the regex stored in serialized objects? If it is and someone has customized forms, it could get lost when restoring the custom form after an upgrade.
1) The domain function was not affected by this. 2) The regex is not stored in the serialized object.
1) OK. What about when creating a domain or a web? One could also make a mistake in the name. Or put a .(dot) in the host part, like "www.". I've seen people doing that. 2) That is perfect.