[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NSS library dependencies

* Sami Haahtinen <ressu@ressukka.net> [021217 15:13]:
> On Tue, Dec 17, 2002 at 10:43:27AM -0600, Steve Langasek wrote:
> > What information are you trying to store in LDAP that is so essential to
> > the system prior to mounting of /usr?
> > 
> > It is entirely valid for /usr to be located on a network share (NFS), so
> > you're not really guaranteed to be able to access your LDAP server (which
> > obviously isn't running locally either, with no /usr) until about the
> > same time as /usr is mounted.  If you have records that are needed by the
> > system prior to mounting of /usr, these ought to be stored in a local
> > database backend such as /etc/passwd.
> The major problem here is that you can't remount or unmount /usr if you
> are using the libnss-ldap module, which is kind of logical when you
> consider that part of the module reside on /usr.

Right, this is the issue that was described in the bug itself.  Anyone
who uses this will not be able to unmount /usr.  On my system this
results in the ext3 journal recovering each time I boot.  I know there
are possible ways around this but I don't know which one is best for the
libnss-ldap package to implement.

> one solution would be to move the whole module to /usr, but that would
> not (atleast to my knowledge, although i haven't tested it) solve the
> problem, the same problem would remain. 

Didn't someone in that bug mention that he had done it successfully by
moving a set of libraries from /usr/lib to /lib?  The reason I cc'd the
mail list is for suggestions on ways around this issue and specifically
on the "Won't fix" bug that has more details than I can accurately
provide myself.

> The only proper solution (which i was looking into this weekend
> actually) 

Really?  Synchronicity in action.

> would be to statically link all required libraries into
> libnss-ldap and keep that in /lib, i'm not that keen in the idea as it
> might bring some new unexpected problems.

But it could work out perfectly, right?

-- Grant Bowman                                <grantbow@grantbow.com>

Reply to: