[Pkg-openldap-devel] Bug#478674: slapd: please run init script at earlier sequence

[Arthur de Jong]

On Wed, 2008-04-30 at 22:39 -0700, Steve Langasek wrote:
> I'm averse to fiddling with init script priorities in this manner.
> There's no good way to handle changes to these priorities on upgrade,
> and I think that the use case of needing to connect to a local slapd
> server for your NSS backend, that early in the boot sequence, is a
> marginal one.  I really don't think anything starting at sequence 20
> should need non-system users; I think if anything, it would be more
> correct for exim to start later.

The problem is that this is not just exim but most mail servers provided
by Debian use sequence 20. Some other daemons also use non-system
accounts (sshd, cups, samba and maybe others) but are less problematic
because nonexistent users for a mailserver will result in rejected mail
(a user of nss-ldapd reported #475626 because of rejected mail).

Anyway, I see your pont in not changing the sequence number and I more
or less agree. I don't think that I want to file bugreports for every
service at sequence 20 thay may want to do NSS lookups though.
> 
> I also think this is entirely an exercise in futility and that we
> should be migrating to dependency-based runlevels - and that users who
> really need slapd running for local user lookups should in the
> meantime adjust by hand if necessary, because this really isn't a
> well-supported configuration. (e.g., winbind is another name service
> daemon that runs locally which is started at S20.)
>
> So let's please work instead on getting proper dependency-based rules
> in place, so that nss-ldap declares a Should-Start: slapd, and
> nss-ldap, winbind, and nscd can all Provide some sort of
> "user_lookups" virtual service that the init scripts for exim & co.
> can declare a dependency on.

I think dependency-based booting is a good idea but from what I've seen
from init scripts is that standardisation is still some way away (e.g.
some mail servers provide mail-transport agent and some don't, specified
dependencies haven't been tested thoroughly yet, etc). Having a service
like naming-services should be a helpful.

Anyway, thanks for considering this.

-- 
-- arthur - adejong at debian.org - http://people.debian.org/~adejong --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20080503/a5d322f5/attachment.pgp