* Marco d'Itri ([EMAIL PROTECTED]) wrote:
> On Jun 24, maximilian attems <[EMAIL PROTECTED]> wrote:
> 
> > > udev does not even know about LDAP, it just uses the libc interface.
> > > What do you think it should do?
> > > Possibly without horrible layering violations.
> > the errors happen when the sysvinit scripts call the udev scripts.
> > it seems udev with libnss expects an running ldap.

Huh, alright, I thought udevd was started in the initrd but apparently
it's just udev that's run during initrd and udevd (which is the source
of the issues) isn't run till after initrd.

> All udev expects is working getpwnam(3) and getgrnam(3) functions.
> If libnss_ldap cannot guarantee them to work at boot time then I think
> libnss_ldap is the problem.

It's simply not possible for libnss-ldap to provide a correct answer
before networking or the slapd daemon has been started.  I can see about
making libnss-ldap fail faster so that the boot process isn't stopped
but that's really not a terrific solution either.  The usual way this is
handled is that an nsswitch.conf is set up with 'files ldap' and 'files'
satisfies everything till things are far enough along for libnss-ldap to
be able to work.

> This issue is exposed by udev because it's the first complex program
> run at boot time, but it would affect other programs too.

Generally, things asking for NSS can be satisifed by 'files' until
networking and other things are available.  Actually, is there any
particular reason why udevd might want something beyond what would be
in local files (ie: system accounts)?  

Another possible approach would be to have a way of not installing
'ldap' as an option in the nsswitch.conf until it can be expected to be
working.  Actually, if that could be inverted during shutdown then we
could close the "can't unmount /usr" problem when shutting down with
'ldap' in nsswitch.conf (libnss-ldap uses the LDAP libraries which are
in /usr/lib, correctly).

What I've seen other distros do has been the 'fail faster' work-around.
I can probably do that but it'd be really nice to have a good
solution...

        Thanks,

                Stephen

Attachment: signature.asc
Description: Digital signature

Reply via email to