Bug 161661
Summary: | named_sdb can depend on local ldap, but server isn't started until later | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dan Cox <dan> |
Component: | bind | Assignee: | Jason Vas Dias <jvdias> |
Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-07-12 23:00:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dan Cox
2005-06-25 03:50:40 UTC
On further consideration, I don't think this is a bug. It is up to server administrators to configure their service start order that suits their site configuration: both the "named" and "ldap" initscripts have 'chkconfig - XX XX' lines - ie., they are by default not started at all and it is up to administrators to issue 'chkconfig --level XXX on' commands to make them be started at boot, so it is up to them which order to run them in; if they choose to run named_sdb and to use the ldap sdb, then they should choose to start ldap before named. By default, named is started immediately after the 'network' service, so that it can be used as the only nameserver in resolv.conf, as the host's local resolver - that should not be changed. Administrators are free to change the start up order as they see fit. All configurable Linux subsystems can be misconfigured in many ways - we cannot make the code ever more complex to account for every misconfiguration of it. Your solution (1) above is unacceptable: it is "traditional" named behaviour that when it encounters a non-syntax zone file error it returns SERVFAIL for queries of all names in the zone - eg. for zones containing "CNAME and other data" - making named refuse to start on such errors is unlikely to be accepted upstream. When a zone fails to load at startup named returns SERVFAIL for every query within it , and it would require major redesign of named to change this. Your solution (2) above also is unacceptable, because users may restart the LDAP service for many reasons, and may not want it also to restart named - what if the ldap server is on a remote host, as it often is ? Really, the only solution is for administrators who want to use sdb ldap to ensure that the ldap server is running before named is started, either by configuring ldap to be started on the same host before named, or by inserting a check in the named initscript such as doing an ldapsearch of their ldap zone and not running named / taking some action if it fails - this is best left to per-site configuration. Actually I had another thought... Consider this: 1. Start the name server when the LDAP server IS available. 2. Shutdown the LDAP server or otherwise make it unreachable. named will then issue SERVFAIL as expected. 3. Bring the LDAP server back online. named will automatically start working again, no HUP required. So named is basically getting permanently stuck in SERVFAIL state even though the LDAP server has become available later. I will send this to the dns-ldap maintainers list and see what they think. |