Init with user db in local LDAP (slapd): On service dependencies
When exactly are accounts supposed to exist?
Assume that some accounts in a system are handled by a daemon, and
that this daemon therefore must be running before you can refer to
these accounts by name. Clearly, having other init scripts that assume
that certain accounts are available, or start other programs/daemons
that do, will have problems if the aforementioned daemon isn't running
yet when they are called.
A concrete example:
The symlink /etc/rc2.d/S20slapd will cause slapd to be started. Some
system accounts and virtually all user accounts are handled by slapd.
However, many other services are also started by /etc/rc2.d/S20*, and
most of these will be started before slapd because they come before
slapd in alphabetical order. One simple solution to this would be to
keep all system accounts in /etc/passwd, so if I do, I lose, right?
But otherwise it should be acceptable to keep accounts in a database
handled by a local slapd, right?
Unfortunately not. /etc/rcS.d/S85nethack is run before slapd is
started, and this init script has to be able to look up user accounts.
This is one example; there might be more that include more critical
services/applications than nethack, so this matter shouldn't be taken
lightly just because nethack made me stumble onto this problem.
How early are user accounts supposed to exist? What about system
accounts? Is this problem a bug in the nethack package, or in slapd,
or in another package? If not, is an administrator actually expected
to reorder installation scripts whenever this kind of dependency
occurs?
There is a problem here. However, I don't know whether I should file a
bug against some package, and in that case, against which package. I'm
beginning to doubt that the sysvinit way of keeping track of
dependencies between services (by just assigning an integer that
doesn't even have to be unique to each service) was ever a good
idea. Somebody please enlighten me!
/Thorild
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: