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]
