Torsten Landschoff cced. The short story is: slapd can fail to start if one of the nis services grabs one of slapd's ports. My suggestion was to move nis behind slapd in the startup process.
On Wed, Apr 27, 2005 at 12:37:16PM +0100, Mark Brown wrote: > On Tue, Apr 26, 2005 at 11:29:06PM +0200, Jens Taprogge wrote: > > > The same is---or at least can be, if ldap is used for authentification > > and/or autofs map serving---true for slapd. But since nis is flexible > > in its use of ports it would make more sense IMHO to move it after slapd > > which binds to specific ports. At least if there are no other issues. > > There's not much room for manouver here: NIS runs at S19 (as does > slapd), wedged between portmap at S18 and the majority of things at S20. > It looks like it would be easier to get the change you're asking for by > getting slapd started earlier (with portmap at S18, say) - it's easier > to move things earlier in the boot process and slapd doesn't have a > portmap to consider. I agree. Should I file a bug against slpad? > > I feel that it is way too late in the game to contemplate changing the > NIS startup in such a manner for sarge. There has been some talk of > restructuring things for etch (for example, in order to allow starting > autofs earlier) so it should probably be considered then. > > If the OpenLDAP daemon were only called ldapd... :) > > > The problem can become quite pressing if for some reason it is triggered > > on a remote system using ldap/slapd for authentification or autofs: it > > can become impossible to log into the system and take care of the issue. > > Fortunately the crossover between NIS and LDAP usage should be > relatively low. -- Jens Taprogge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
