Steve,
Steve Langasek wrote:
On Wed, Oct 04, 2006 at 02:14:13AM +0200, Steinar H. Gunderson wrote:
The first one is that it attempts to touch a file in a directory that
does not exist. /etc/init.d/libnss-ldap needs /lib/init/rw to exist but
does not make sure.
Simple fix is to create the dir manually.
You're mixing and matching testing and unstable packages, with somewhat mixed
results; I guess libnss-ldap should depend on initscripts that are new enough
to have /lib/init/rw (the version in sid definitely is).
And initscripts is frozen, and no decision has been made yet to let that
version of sysvinit into etch.
Can we just fix libnss-ldap already to use a sensible default bind policy,
please?
It's not so much a sensible default bind policy, but rather the
possibility that during startup things will be extremely delayed because
the ldap server might not yet be available (no connection, not started,
etc).
For example, in my case the rcS/S70x11-common was the first one to call
upon the services of libnss-ldap. So it took some time (I think about 30
minutes, but I went for coffee) to decide that the ldap server perhaps
wouldn't show up in time.
The next one was bind9 and I gave up and decided to figure out what was
causing this.
I need a normal bind policy that's one of the hard ones (user database
in ldap). But during startup a soft policy is fine, since all
administrative accounts are local.
I think the file base approach that is now implemented is quite
reasonable. It allows admins to use a soft policy during startup and
migrate to the regular policy later on. Using an initscript allows the
admin to decide when to change to the regular policy.
And for the server that actually hosts the ldap daemon this means that a
soft policy can be used until that daemon is available.
So all in all I think this is a reasonable and practical approach. With
a detail or two to polish.
-- Jan Evert
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
