(2012/11/23 8:37), Dave Chinner wrote:
> On Thu, Nov 22, 2012 at 02:05:03PM +0900, Satoru Takeuchi wrote:
>> Current xfs_quota (I pulled xfsprogs today) seems not be able to the users
>> managed by LDAP. There is no patch since I'm not good at LDAP and don't know
>> the root cause yet ;-(
>> Step to reproduce(in this case, "sat" is the user managed by LDAP):
>> # uname -r
>> # mount -o loop,usrquota xfs.img mnt
>> # xfsprogs/quota/xfs_quota -xc "limit bsoft=10M bhard=10M sat" /dev/loop0
>> xfs_quota: invalid user name: sat #
>> # su sat
>> $ #
>> But this user acutally exists.
>> The kernel is a bit old, but I suspect this is a userland problem.
> Yes, userland.
> However, xfs_quota is not supposed to know about LDAP, or NIS, or
> any other user database. It uses the getpwnam() to convert the user
> name to a UID, and that call is failing to find "sat". This is
> supposed to work with LDAP (as mentioned in the man page), and if it
> isn't it generally means something is broken with your LDAP setup
> (/etc/nsswitch.conf not correct?) rather than there being something
> wrong with xfs_quota....
Probably this behaivor comes from the difference between the test machine
and the build machine which I built the upstream xfsprogs.
I made the following simple program which just calls getpwnam().
struct passwd *p;
if ((p = getpwnam("sat")) == NULL)
err(EXIT_FAILURE, "getpwnam() failed.");
printf("name = %s, id = %d\n", p->pw_name, p->pw_uid);
Here is the result of this problem at the test machine.
- SUCCEEDED: build at the test machine
- FAILED: built at the build machine
I will build xfsprogs at the test machine and confirm whether this behavior
(getpwnam() fails) happens or not again.