Bugzilla – Bug 134206
named forwarders.conf syntax error
Last modified: 2005-12-02 13:28:56 UTC
After a system-update from 10.0 to alpha3, I see this in /var/log/boot.msg: Reloading name server BIND - Warning: named not running! /etc/named.d/forwarders.conf:7: '{' expected near ';' done Line 7 looks like this: forwarders ;
/etc/named.d/forwarders.conf is not part of the bind package. If it has syntax errors after an update, it's not binds fault but of course bind can't start then. I don't know who creates the forwarders.conf. Maybe some dialin script?
rpm -qf /etc/named.d/forwarders.conf file /etc/named.d/forwarders.conf is not owned by any package Sigh. Werner any idea?
the bug has to analyzed and fixed
next time please do not close a bug if the bug has not a valid fix
File /etc/named.d/forwarders.conf is created by YaST2 DNS Server because of the script (dial-up) which can modify forwarders itself. YaST creates and includes the file this way: /etc/named.conf: --- cut --- options { ... include "/etc/named.d/forwarders.conf"; ... } --- cut --- /etc/named.d/forwarders.conf: --- cut --- forwarders { 10.20.0.2; }; --- cut --- See bug #suse40610 x bug #55610 https://bugzilla.novell.com/show_bug.cgi?id=suse40610 Actually, bind should not break the configuration when updating, but ... I don't have the configuration file neither the new one, nor the old one. -> ug?
I don't have any config files at all but bind doesn't touch the file /etc/named.d/forwarders.conf If it's broken after an update, I hardly doubt it's bind fault. Since it was a system update and not just a bind update, we have to find out which part of the update broke the forwarders.conf Juergen, can you reproduce that and attach the forwarders.conf before and after the update?
Args ... we DON NOT play ping pong here, fix the BROKEN syntax of /etc/named.d/forwarders.conf.
Hmm, reading the bugreport again... "After a system-update from 10.0 to alpha3..." This means that YaST doesn't have anything with it. It was obviously done by updating the package somehow. Installation doesn't run DNS-Server configuration. If we had YaST logs from the installation we could have seen whether there had been some yast2 dns-server running or not. (If it had, it would be a mistake!) "Line 7 looks like this: forwarders ;" Try to edit the /etc/named.d/forwarders.conf to contain this configuration, then run `yast2 dns-server` click through the configuration (you don't need to change anything, just click through to swith the "changed" flag to "true"). Click [Accept], [Save], whatever... How forwarders look like now? -> "forwarders {};" Whence it follows that dns-server itself saves the configuration of forwarders correctly event it has been broken before and there is nothing I could fix. Well, Werner, what do you think I could fix? From my point of view, dns-server hasn't been (shouldn't be) executed at all. I suspected the update-mechanism of the BIND package but if Uwe said that it was impossible...?
there is a modify_forwarders mechanism in some dialin script. Maybe that is doing something nasty during the update? the bind package itself has not changed since SUSE Linux 9.3. So if it's a bug in the bind package it's either hard to trigger or it's invoked by something new in the update mechanism from 10.0 to 10.1 that I don't know.
Currently the /etc/named.d/forwarders.conf looks like forwarders ; which may accepted by named in past but is broken syntax. Maybe the new NetworkManager or an other tool started by the NetworkManager does not like broken syntax. Therefore an empty /etc/named.d/forwarders.conf should look forwarders {}; ... and it should be tested to avoid messages like: restored /etc/resolv.conf from /etc/resolv.conf.saved.by.dhcpcd.eth0 ..skipped Reloading name server BIND - Warning: named not running! /etc/named.d/forwarders.conf:7: '{' expected near ';' at boot time.
Juergen, please, attach YaST logs. http://www.opensuse.org/Bug_Reporting_FAQ#YaST Werner: - BIND update hasn't been changed since 9.3. If the accepted configuration was changed, also the update mechanism would must have been changed too. - YaST DNS Server doesn't write empty forwarders with "forwarders ;" but with "forwarders {};" which works. - Forwarders file is (due to the bug #55610) changed with the if-up (ip-up?) script. - Comment #8 says almost the same. Ludwig: Could you, please, take a look at it? It might be a problem of some of your scripts (might not but...) Thanks for your patience.
Sorry, it seems to be Christian's script, not a Ludwig's one. Christian: could you, please, check whether your script `/sbin/modify_resolvconf` could change /etc/named.d/forwarders.conf during update to have "forwarders ;" in it? The right syntax is "forwarders {};" if there are none listed.
Created attachment 57901 [details] y2logs from the machine with the syntax error.
modify_resolvconf does only modify named.conf itself and never named.d/*. If modify_resolvconf has a bug then that it does not work on /etc/named.d/forwarders.conf
YaST logs say that the DNS Server hasn't been running at all during or after the installation. Juergen, thanks for them. `rpm -ql yast2-dns-server | grep "etc"` doesn't return anything - updating the yast2-dns-server cannot replace /etc/named.d/forwarders.conf file. So, what am I supporsed to fix?
The file /etc/named.d/forwarders.conf but is not part of any pacakge therefore it MUST be written out by a tool. Btw: It was also there on SL 10.0. Which program/tool/script has written this file? It has to be fixed.
Christian, so it is a bug :) See the bug #55610 comment #6, comment #15 and comment #26. Many of these comments were written by Lars... adding lmuelle.
The file is written by YaST DNS Server when configuring the DNS Server because of the ppp daemon which can touch it. It was already on 9.3.
Yes, but this modify_resolvconf bug is off topic here. See bug 134692
Right. It has nothing to do with updating to alpha3. The file was broken already on my plain 10.0 installatin. - the update to alpha3 only showed it.
This was the bugreport: --- cut --- After a system-update from 10.0 to alpha3, I see this in /var/log/boot.msg: Reloading name server BIND - Warning: named not running! /etc/named.d/forwarders.conf:7: '{' expected near ';' done --- cut --- Juergen, you can't report a bug of wrong config file for "update to 10.1" and than say that the file has been already broken BEFORE the update. The other thing is also that you can't tell when and how it was broken. Bind would not run with a wrong configuration either on the 10.0 (tested). The configuration would either not already work on 10.0 and should have been reported for 10.0 or would not work after the update and should have been reported for update to 10.1. If you reproduce the error on your 10.0, please, reopen the bug and attach appropriate YaST logs. All in all, I can't reproduce the error also because it doesn't seem that I could get needed logs (which are lost after the update). I'm sorry, but in this case I have to use this -> WORKS FOR ME.
Even if this was an update, the file has to be checked and fixed.
Jiri: this seems to be an enhancement request for the installation: "Search for every possible configuration file on the system and fix it if the syntax is wrong". And BTW: this doesn't seem to be a joke.
Hmm ... I'm talking about configuration files generated by 9.3/10.0 by our own scripts. The problem is that the most of those scripts arn't %ghost entries in a RPM spec file and therefore will not be removed if not needed anymore. Beside this the /etc/named.d/forwarders.conf will be included in /etc/named.conf and /etc/named.conf is part of package bind.
Beside this: if /etc/named.conf, part of package bind, includes by default an other file this file must be part of a package.
Lukas: Sorry for the wrong initial description. It was the update to alpha 3 that had the error message in the logs. I had reported it earlier if it had surfaced earlier of course.
#25 bind does not include forwarders.conf by default.
Juergen, never mind :) just for the next time... Uwe: well, that might be the problem, see: https://bugzilla.novell.com/show_bug.cgi?id=55610#c26 and https://bugzilla.novell.com/show_bug.cgi?id=55610#c28
YaST cannot check configuration of all tools during update, it is nonsense. It is task of the particular package. Maybe this problem is caused by the network configuration during update, but anyway, it is not task of YaST to take care of it... thus reassigning to bind maintainer.
sorry but if a yast module writes a configuration file and that file got somehow broken during update, then it's not task of the package to fix that situation. What should I do in that situation? It's impossible that the bind package can catch and fix this.
If the configuration was correct before the update, then the package itself shouldn't break it while updating... Anyway, it is not task for the general update mechanism, but either for DNS YaST module, or bind...
Please stop this game. The writer of /etc/named.d/forwarders.conf has to correct the syntax used in the file to something valid.
I don't touch it at all. I suggest someone should start installation under strace (with recursion to all subprocesses) to learn who modifies the file and why...
OK, let me summarize some basic ideas and resolutions, please: - The main issue is, that the configuration file /etc/named.d/forwarders.conf has been broken somehow but BEFORE the update -> INVALID bugreport - Bugreported can attach only logs AFTER the update. So nobody can inspect the bug behavior -> CAN'T FIX - BIND doesn't work with broken /etc/named.d/forwarders.conf file neither in 10.0 nor in 10.1AplhaX. - Running `yast2 dns-server` would repair the syntax error in this file in both 10.0 and 10.1AplhaX -> WORKS FOR ME (comment #32). - Installation / Update can't run checking of all configuration files. That would be the same if you wanted from Perl language to add a missing right bracket somewhere into your Perl-program. Impossible -> CAN'T FIX - BIND will not check the configuration during update (comment #30) -> WONTFIX Nobody other have ever had the same error there and running 'yast2 dns-server' can simply fix it even there is no evidence that is is because of yast2-dns-server -> NORMAL. All in all, this bug isn't reproducible and repairable -> WONTFIX.