Wow, great observation: doing a "ls" of /etc/group and /etc/passwd fixes
it. How incredibly strange:
[EMAIL PROTECTED] svn]# chroot staging/db
id: cannot find name for group ID 0
id: cannot find name for group ID 1
id: cannot find name for group ID 2
id: cannot find name for group ID 3
id: cannot find name for group ID 4
id: cannot find name for group ID 6
id: cannot find name for group ID 10
I have no [EMAIL PROTECTED]:/# ls /etc/group /etc/passwd
/etc/group /etc/passwd
I have no [EMAIL PROTECTED]:/# exit
[EMAIL PROTECTED] svn]# chroot staging/db
[EMAIL PROTECTED]:/#
Anyway, it's fantastic to have a workaround. Thanks a million!
Also, here's the output of "id" from a broken chroot; I don't actually
know if this fixes it -- I tried the "ls" trick and that did it, so I
don't know if "id" will fix it, too.
I have no [EMAIL PROTECTED]:/# id
uid=0 gid=0 groups=0,1,2,3,4,6,10
Finally, fixing one chroot neither fixes nor breaks the other -- they
seem entirely independent. (Great question, though.)
So, the next time I see it I'm going to see if "id" fixes it by itself.
I'm also going to read up more on the nscd and see if tweaking that
helps. It's a little slow going as it seems to take a long time for
this problem to re-appear; perhaps I can tweak nscd to force it to
happen more frequently, and thus better figure out how to make it not
happen it all.
Thanks for all your help!
-david
Daniel Burrows wrote:
On Mon, Jun 30, 2008 at 01:12:34PM -0700, David Barrett <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
