(2012/11/29 9:34), Satoru Takeuchi wrote:
> (2012/11/28 6:05), Dave Chinner wrote:
>> On Tue, Nov 27, 2012 at 04:27:34PM +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
>>>>>>>> 3.7.0-rc5
>>>>>>>> # 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 # denied
>>>>>>>> # su sat
>>>>>>>> $ # But this user acutally exists.
>>>>>>>> ===============================================================================
>> .....
>>
>>> So there is a problem in "report" subcommand. Refer to report_without_U.log,
>>> I found "quotactl(Q_XGETQUOTA|GRPQUOTA, ...) is only called for local users
>>> and it's because that getpwent() only returned only local users.
>>
>> Yes, it appears from the strace that glibc is only reading
>> /etc/passwd and not querying the ldap server.
>>
>>> open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
>>> fstat(3, {st_mode=S_IFREG|0644, st_size=1724, ...}) = 0
>>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f851afee000
>>> read(3, "#¥n# /etc/nsswitch.conf¥n#¥n# An ex"..., 4096) = 1724
>>> read(3, "", 4096) = 0
>>> close(3) = 0
>> ...
>>> open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
>> ...
>>> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
>>> fstat(3, {st_mode=S_IFREG|0644, st_size=2005, ...}) = 0
>>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f851afee000
>>> lseek(3, 0, SEEK_CUR) = 0
>>> read(3, "root:x:0:0:root:/root:/bin/bash¥n"..., 4096) = 2005
>>> quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/loop0", 0, {version=1, flags=XFS_USER_QUOTA, fieldmask=0, id=0, blk_hardlimit=0, blk_softlimit=0, ino_hardlimit=0, ino_softlimit=0, bcount=0, icount=3, ...}) = 0
>>
>> As you can see, it only dynamically loads the local files name
>> service library, not the ones that do ldap lookups.
>>
>> Can you run ldd on the test binary you had and on xfs_quota to see
>> if they are linked against the same libraries?
>
> I ran ldd on the test binary and found that I built it on i686
> machine and the test machine is x86_64. So the test binary
> couldn't find the suitable 32 bit nss library on the test machine.
> I found the test binary built on the test machine works the same
> as xfs_quota.
>
> | build machine | getpwnam | getpwent
> =============+===============+===========+==========
> test binary | 32 bit | NG | NG
> | 64 bit | OK | NG
> -------------+---------------+-----------+----------
> xfs_quota | 64 bit | OK | NG
> -------------+---------------+-----------+----------
>
> Since the test binary(64bit) and xfs_quota load the same
> nss library and have the same behavior, it's apparently
> not the xfs_quota problem but the LDAP/libnss related problem.
>
> I will dig this problem more as the LDAP/libnss perspective.
>
> Thank you very much for helping me, Dave.
Just FYI, I finally found that this problem happened because
I forgot to add the following line to /etc/sssd/sssd.conf.
===============================================================================
...
enumerate = True
...
===============================================================================
So getpwent() skipped LDAP users and xfs_quota didn't work correctly.
Thanks,
Satoru.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
