Hi, I just upgraded ispconfig3 to the latest version and BIND has errored all of my dns records meaning all my sites are now down! I get the errors as below: cant post it as it thinks its a link, nothing like a link. will attach file later SEE BELOW FOR MORE DETAILS First, why is this happening, there is nothing wrong Second, does anyone have a sample named conf local file I can rebuild from for a quick fix? Thanks
Never seen an update issue with bind as the update does not alter the zone config. Wich exact error do you get?
Well, first I installed an application the other day, which seemed to knock out the emails being sent. It looks like whatever i installed enabled sendmail and messed up postfix, so I reinstalled these and roundcube, and manually ran the Install process steps to configure those parts, as a clean install of postfix without re-running the ISPConfig installer simply wont work due to changes it needed. My emails now send via SMTP again all ok, however I remain unable to log in to any email accounts in roundcube, it just tells me the username cannot be found in the error log /var/log/secure. (i cleared the maillog and secure log files, now its not writing anything to them! ) At this point I updated ISPConfig to the latest version in the hope it might sort itself out, but it hasnt. My postfix/getmail/dovecot all look configured ok to use the database to auth, but it seems to not be looking (the database is fine). Then when saw my email forwarding wasnt working either for a site which i need it working on, i tried to delete and re-add the DNS Zone. It was at this point that BIND decided it was invalid (it was identical to before), and when I did a resync for the DNS it errored all of them (this morning it seems to have forgiven the others, but this one site still wont work!). It may be that this is a new DNS zone, and it's let me off on the old ones, as I added a test.com DNS Zone which also failed to work this morning. I have attached images showing a working zone file (moviedon) and the not working zone file (ultima), and also the named config files. The bind error is: WARNING - Writing BIND domain file failed: /var/named/pri.ultima.one
ISPConfig stores the files that bind did not accept as .err file. use the command "named-checkzone" to test the .err file to find out why bind rejected it.
Code: [root@ns370881 named]# named-checkzone ultima.one pri.ultima.one.err zone ultima.one/IN: loaded serial 2015072910 OK [root@ns370881 named]# named-checkzone www.ultima.one pri.ultima.one.err pri.ultima.one.err:11: ignoring out-of-zone data (ultima.one) pri.ultima.one.err:13: ignoring out-of-zone data (ultima.one) pri.ultima.one.err:14: ignoring out-of-zone data (ultima.one) pri.ultima.one.err:15: ignoring out-of-zone data (ultima.one) zone www.ultima.one/IN: has no NS records zone www.ultima.one/IN: not loaded due to errors. [root@ns370881 named]# named-checkzone ultima.one. pri.ultima.one.err zone ultima.one/IN: loaded serial 2015072910 OK not sure what was meant to go in the second parameter, so tried a few. There is NS settings, so i dont get whats wrong
If I manually add it to the local conf file it works fine, but I cant be doing that every time i add a website and risk them being removed randomly
named-checkzone didnt seem to have a problem with it, so i dont get why it was not adding it to start with, it has randomly started refusing new DNS Zones, and only since yesterday when i updated things
Ok the issue seems to be that the NS is specified with the main domain, so subdomains are not getting the name server. This is happening as all my sites have a www. version, and the www. has no nameserver. This fails: Code: ultima.one. 3600 NS ns1.pixelhero.co.uk. ultima.one. 3600 NS ns1.pixelhero.co.uk. This works: Code: @ 3600 NS ns1.pixelhero.co.uk. @ 3600 NS ns1.pixelhero.co.uk. BUT, ISPConfig keeps writing the files with the domain as the zone, and I cant add a NS for the subdomains in ISPConfig. Again, this is since i updated bind and ispconfig.
ok nevermind, it didnt help, i resynced after and it set it all back, and now all my sites have been removed from named.conf.local again - WHY, nothing changed!
Ok, so no matter what I try, any new DNS Zones are being refused, regardless of what i put in. named-checkzone says they are fine, but ISPConfig is putting them in .err and telling me it failed to write.
Code: [root@ns370881 server]# ./server.sh 30.07.2015-17:27 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 30.07.2015-17:27 - DEBUG - Found 1 changes, starting update process. 30.07.2015-17:27 - DEBUG - Calling function 'soa_update' from plugin 'bind_plugin' raised by event 'dns_soa_update'. 30.07.2015-17:27 - DEBUG - Writing BIND domain file: /var/named/pri.ultima.one 30.07.2015-17:27 - DEBUG - Writing BIND named.conf.local file: /etc/named.conf.local 30.07.2015-17:27 - DEBUG - Processed datalog_id 848 30.07.2015-17:27 - DEBUG - Calling function 'restartBind' from module 'dns_module'. 30.07.2015-17:27 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished. works fine when manually run. :/
Ok, it seems that ISPConfig needs some unsecure PHP functions enabled in order to do this.. why am I forced to open security flaws in my server to have this work? :/
ISPConfig server is s ahell script and not a website, so you have to enable shell functions off course for PHP cli scripts. Or how do you think that ispconfig should be able to restart services like bind or how should ispconfig run the named-checkzone script? On Debian and Ubuntu there are 4 php.ini files, one for apache, one for cgi, one for fpm and one for cli. You can disable exec functions in all php.ini files except of the cli ini as thats for shell scrips and disabling shell functions in a hell script is ridiculous.
So is cpanel but it sorts itself out fine. just wasn't expecting to have to manually sort out multiple php.ini myself, im using nginx not apache.
It's the same for nginx. If cpanel ignores the settings that the admin makes in the global php.ini files then they can do that. We don't want to trick the admin by silently enabling functions again that the admin has denied for the system. The default php.ini settings after a fresh ispconfig install are correct, if you change them and this results in failures then it's your fault and not the fault of ispconfig.