On Mon, Jun 30, 2008 at 01:12:34PM -0700, David Barrett <dbarrett@quinthar.com> was heard to say:
> Basically, I go into staging/www, and it works fine. Then I go into
> staging/db, and it has the problem. I immediately check the group
> permissions, and note that now group IDs are being resolved to group
> names, but user IDs aren't getting resolved. I then check the passwd
> permissions, and note that both user and group names are now working. I
> go right back to the group file, and now group and usernames are working
> fine. I exit the broken DB chroot, and re-enter just fine.

Just out of curiosity, does the chroot that *was* working continue to
work after this?

If you run, e.g., "id" a few times when it's broken, does it continue
to be broken? And although I can't imagine why this would be the case,
does the problem consistently go away for, e.g., passwords after you
"ls" the password file? I notice that this happened in both of your
last two examples: your problems with each file went away as soon as you
listed it. Is there anything unusual about how your filesystems are
configured?

> As for nsswitch.conf, here it is: I haven't changed it, but I'm not
> familiar with the file so I don't know if it's right or not:

That looks right. The main concern would be if you had done something
like fetching user information from LDAP, which would be another place
for bugs to hide.

> As for nscd... Aha! This is a good candidate: it turns out I *do* have
> this installed on the host system. I don't know anything about this;
> I'll need to read up on it.

nscd caches lookups of things like uid <-> name mappings. I've had
various problems in the past, which I won't detail because I can't
remember them in detail, and I wouldn't recommend installing it unless
you need to (mostly if you're using something like NIS or LDAP). This
looks like the sort of gremlin that nscd could cause.

However, I don't think I needed to ask whether you had it installed on
the host system: it looks like it communicates via a Unix-domain socket
in /var, so it wouldn't be able to interfere with what's happening in
the chroots.


I think an strace of a failing command (e.g., "id") would be very
interesting.

Daniel


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org