I have set up an LDAP server which is working with the imap mail server and as an authentication server (nis replacement). When I was setting up the DNS server, using the YAST module, I checked the “LDAP support active” checkbox.
The zone data is stored in the LDAP server but the zone files under /var/lib/named/master are not created. The named daemon is not able to load the zones and I get logs saying:
named[18344]: zone 20.168.192.in-addr.arpa/IN: loading from master file master/20.168.192.in-addr.arpa failed: file not found
named[18344]: zone 20.168.192.in-addr.arpa/IN: not loaded due to errors.
With similar logs for the forward zone. The LDAP server has records for the zone under DNS/20.168.192.in-addr.arpa:
dNSClass IN
dNSTTL 172800
nSRecord host.dom.name.co.uk.
objectClass dNSZone
relativeDomainName @
sOARecord host.dom.name.co.uk. root.host.dom.name.co.uk. 2011100400 10800 3600 604800 86400
zoneName 20.168.192.in-addr.arpa
(the dot name of the host has been changed for posting “host.dom.name” being fictional.)
There is also a set of records for the forward zone.
It looks as if the YAST tool is not
On 10/05/2011 07:06 PM, pblewis wrote:
> It looks as if the YAST tool is not
(not that i can answer, but i guess you had a question, so) it looks
like your message got truncated somewhere along the way…
–
DD
openSUSE®, the “German Automobiles” of operating systems
I am sorry, it did get truncated a bit!
It looks as if the YAST tool is not running the script that reads the zone data from the LDAP server and builds it into the zone files under /var/lib/named/master.
I have tried making the /var/lib/named/master directory ownership named:named but that made no difference. I even set the ownership of /var/lib/named to named:named which only got rid of a log on the messages:
named[18344]: the working directory is not writable
I have restored the root:root ownership after testing.
I hope that I have just missed some obvious action.
Thanks in advance.
I have done more debugging and can report.
Verify that /var/lib/named/master directory is empty.
Using the YAST DNS Server tool:
In Start-Up un-check LDAP Support Active. (No LDAP for now).
In DNS Zones ensure that the zones are there with the expected records.
Click on the OK button to finish setting up the server.
Look in /var/lib/named/master directory and find the two master zone files filled as expected.
Verify that the zone data is still in the LDAP server.
Using the YAST DNS Server tool:
In Start-Up note that LDAP Support Active is still unchecked.
In Zone Editor - Records tab remove one of the address records.
Click OK to return to DNS Server: DNS Zones.
Click on the OK button to finish setting up the server.
Look in /var/lib/named/master directory and find the altered zone file, check the change in contents.
Verify that the zone data in the LDAP server is unchanged.
Using the YAST DNS Server tool:
In Start-Up check LDAP Support Active to restore LDAP support.
In DNS Zones ensure that the zones are there with the expected records. Deleted record is not there.
Click on the OK button to finish setting up the server. Enter the LDAP administrator password.
Look in /var/lib/named/master directory and find the two master zone files filled are unchanged.
Verify that the zone data is still in the LDAP server. Note that the deleted record is still there.
Using the YAST DNS Server tool:
In Start-Up un-check LDAP Support Active. (No LDAP again).
In DNS Zones note that the zones are there with the deleted record present.
Click on the OK button to finish setting up the server.
Look in /var/lib/named/master directory and find the altered zone file, check the change in contents, the deleted record restored.
Verify that the zone data in the LDAP server is unchanged.
Conclusion:
When the “LDAP Support Active” box is checked, the DNS Server tool writes to the LDAP server but does not create the Zone Files so the DNS server does not work.
Has anyone out there got the DNS server running with LDAP support?
On looking at the YaST log file I find:
2011-10-06 15:10:03 <3> santorini(26088) [bash] ShellCommand.cc(shellcommand):78 Use of uninitialized value $h in substitution (s///) at /usr/lib/perl5/vendor_perl/5.12.3/Net/LDAP.pm line 107.
2011-10-06 15:10:03 <3> santorini(26088) [bash] ShellCommand.cc(shellcommand):78 Use of uninitialized value $h in substitution (s///) at /usr/lib/perl5/vendor_perl/5.12.3/Net/LDAP.pm line 109.
2011-10-06 15:10:03 <3> santorini(26088) [bash] ShellCommand.cc(shellcommand):78 Use of uninitialized value $h in substitution (s///) at /usr/lib/perl5/vendor_perl/5.12.3/Net/LDAP.pm line 110.
2011-10-06 15:10:03 <3> santorini(26088) [bash] ShellCommand.cc(shellcommand):78 Use of uninitialized value $host in substitution (s///) at /usr/lib/perl5/vendor_perl/5.12.3/Net/LDAP.pm line 141.
2011-10-06 15:10:03 <3> santorini(26088) [bash] ShellCommand.cc(shellcommand):78 Use of uninitialized value $_[1] in join or string at /usr/lib/perl5/5.12.3/i586-linux-thread-multi/IO/Socket/INET.pm line 117.
2011-10-06 15:10:03 <3> santorini(26088) [bash] ShellCommand.cc(shellcommand):78 can’t contact LDAP Server
So it looks as if there is a problem with the perl scripts used to read the LDAP data and generate the zone files.
I think I will submit a bug report.