Re: [lfs-support] ACL check errors: are they important?
On Mon, 21 Apr 2014 22:14:31 +0100 Ken Moffat zarniwh...@ntlworld.com wrote: From memory (so, I might be wrong) the book doesn't ever create a 'users' group in LFS... So, I _guess_ that the 'users' group exists on your host system and you will need to create it in LFS to get these tests to work. ĸen You're right. I do have a users group on my host system. But how does that affect the lfs partition? At this stage, we are in a chroot jail, using freshly-built software. Doesn't that mean complete independence from the host except for the running kernel and its virtual file systems? There would have been no previous need for a users group or a daemon user on LFS because acl was not included in the basic system and therefore there were no acl tests to be run. That must still be the case for LFS with sysVinit. But acl is apparently required for systemd, so I think it would make sense for section 6.6 to be different in the systemd edition of the book. Hazel -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Le 22/04/2014 13:31, Hazel Russman a écrit : On Mon, 21 Apr 2014 22:14:31 +0100 Ken Moffat zarniwh...@ntlworld.com wrote: From memory (so, I might be wrong) the book doesn't ever create a 'users' group in LFS... So, I _guess_ that the 'users' group exists on your host system and you will need to create it in LFS to get these tests to work. ĸen You're right. I do have a users group on my host system. But how does that affect the lfs partition? At this stage, we are in a chroot jail, using freshly-built software. Doesn't that mean complete independence from the host except for the running kernel and its virtual file systems? There would have been no previous need for a users group or a daemon user on LFS because acl was not included in the basic system and therefore there were no acl tests to be run. That must still be the case for LFS with sysVinit. But acl is apparently required for systemd, so I think it would make sense for section 6.6 to be different in the systemd edition of the book. I filed a ticket about that. It seems that the bin group membership of the daemon user is not needed. Could you confirm? Regards Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On Tue, 22 Apr 2014 13:42:58 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: It seems that the bin group membership of the daemon user is not needed. Could you confirm? Confirmed. It is also not necessary to set real home directories or shells for the bin and daemon users as specified in BLFS. /dev/null and /bin/false work perfectly well for these. Hazel -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Le 22/04/2014 17:51, Hazel Russman a écrit : On Tue, 22 Apr 2014 13:42:58 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: It seems that the bin group membership of the daemon user is not needed. Could you confirm? Confirmed. It is also not necessary to set real home directories or shells for the bin and daemon users as specified in BLFS. /dev/null and /bin/false work perfectly well for these. Hazel Thanks for checking. Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Pierre Labastie wrote: Le 22/04/2014 17:51, Hazel Russman a écrit : On Tue, 22 Apr 2014 13:42:58 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: It seems that the bin group membership of the daemon user is not needed. Could you confirm? Confirmed. It is also not necessary to set real home directories or shells for the bin and daemon users as specified in BLFS. /dev/null and /bin/false work perfectly well for these. Hazel Thanks for checking. Well I did some more checking. daemon does need to be a member of bin to pass all the 'make root-tests', but reall home directories/shells are not required. I'll update the book. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] ACL check errors: are they important?
I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 of LFS-systemd does not include this user in /etc/passwd). Adding it reduced the number of errors from 47 to 10. However I have not been able to reduce them any further. BLFS also recommends giving bin and daemon proper home directories (I used /bin and /sbin respectively) and a shell, but this had no effect in my case. As far as I know, the acl and user_xattr options required for acl to work on the mounted lfs partition are built into the ext4 driver that my host kernel (3.10.17) uses and do not need to be set explicitly. When I do set them, they are accepted silently but don't show up in /proc/mounts, whereas noacl and nouser_xattr do. I attach an edited log file containing the actual test errors. I need to know if they are important and, if so, how to get rid of them. -- *** malformed-restore.test *** 13 commands (13 passed, 0 failed) *** sbits-restore.test *** 17 commands (17 passed, 0 failed) *** utf8-filenames.test *** 7 commands (7 passed, 0 failed) *** setfacl-X.test *** 24 commands (24 passed, 0 failed) *** getfacl-noacl.test *** 22 commands (22 passed, 0 failed) *** getfacl-recursive.test *** 12 commands (12 passed, 0 failed) *** cp.test *** 22 commands (22 passed, 0 failed) *** misc.test *** [91] $ setfacl -m g:users:rw,g:daemon:r f -- failed setfacl: Option -m: Invalid argument near character 3 != ~ [95] $ getfacl --omit-header f -- failed user::rw- == user::rw- user:bin:rw- == user:bin:rw- user:daemon:r-- == user:daemon:r-- group::r--== group::r-- mask::rw- != group:daemon:r-- other::r--!= group:users:rw- != mask::rw- ~ != other::r-- ~ != [108] $ setfacl -x g:users f -- failed setfacl: Option -x: Invalid argument near character 3 != ~ [112] $ getfacl --omit-header f -- failed user::rw- == user::rw- user:bin:rw- == user:bin:rw- user:daemon:r-- == user:daemon:r-- group::r--== group::r-- mask::rw- != group:daemon:r-- other::r--!= mask::rw- != other::r-- ~ != [128] $ getfacl --omit-header f -- failed user::rw- == user::rw- user:bin:rw- == user:bin:rw- group::r--== group::r-- mask::rw- != group:daemon:r-- other::r--!= mask::rw- != other::r-- ~ != [233] $ setfacl -nm u:daemon:rx,d:u:daemon:rx,g:users:rx,g:daemon:rwx d/d -- failed setfacl: Option -m: Invalid argument near character 29 != ~ [237] $ getfacl --omit-header d/d -- failed user::rwx == user::rwx user:bin:rwx #effective:r-x == user:bin:rwx #effective:r-x group::r-x!= user:daemon:r-x mask::r-x != group::r-x other::---!= group:daemon:rwx #effective:r-x default:user::rwx != group:users:r-x default:user:bin:rwx #effective:r-x != mask::r-x default:group::r-x!= other::--- default:mask::r-x != default:user::rwx default:other::---!= default:user:bin:rwx #effective:r-x != default:user:daemon:r-x ~ != default:group::r-x ~ != default:mask::r-x ~ != default:other::--- ~ != [263] $ getfacl --omit-header d/l -- failed user::rwx == user::rwx user:bin:rwx #effective:r-x == user:bin:rwx #effective:r-x group::r-x!= user:daemon:r-x mask::r-x != group::r-x other::---!= group:daemon:rwx #effective:r-x default:user::rwx != group:users:r-x default:user:bin:rwx #effective:r-x != mask::r-x default:group::r-x!= other::--- default:mask::r-x != default:user::rwx default:other::---!= default:user:bin:rwx #effective:r-x != default:user:daemon:r-x ~ != default:group::r-x ~ !=
Re: [lfs-support] ACL check errors: are they important?
On 04/21/2014 06:13 PM, Hazel Russman wrote: I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 of LFS-systemd does not include this user in /etc/passwd). Adding it reduced the number of errors from 47 to 10. However I have not been able to reduce them any further. BLFS also recommends giving bin and daemon proper home directories (I used /bin and /sbin respectively) and a shell, but this had no effect in my case. As far as I know, the acl and user_xattr options required for acl to work on the mounted lfs partition are built into the ext4 driver that my host kernel (3.10.17) uses and do not need to be set explicitly. When I do set them, they are accepted silently but don't show up in /proc/mounts, whereas noacl and nouser_xattr do. I attach an edited log file containing the actual test errors. I need to know if they are important and, if so, how to get rid of them. Drop the root-tests, they are broken anyways. I couldn't even get them to run with daemon user present. -- Note: My last name is not Krejzi. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On Mon, 21 Apr 2014 18:32:49 +0200 Armin K. kre...@email.com wrote: Drop the root-tests, they are broken anyways. I couldn't even get them to run with daemon user present. I didn't do the root tests. These were the standard ones invoked with make tests though of course I was logged in as root when I did them. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Le 21/04/2014 18:13, Hazel Russman a écrit : I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 of LFS-systemd does not include this user in /etc/passwd). Adding it reduced the number of errors from 47 to 10. However I have not been able to reduce them any further. BLFS also recommends giving bin and daemon proper home directories (I used /bin and /sbin respectively) and a shell, but this had no effect in my case. As far as I know, the acl and user_xattr options required for acl to work on the mounted lfs partition are built into the ext4 driver that my host kernel (3.10.17) uses and do not need to be set explicitly. When I do set them, they are accepted silently but don't show up in /proc/mounts, whereas noacl and nouser_xattr do. I attach an edited log file containing the actual test errors. I need to know if they are important and, if so, how to get rid of them. You do not say that you have mounted your filesystem with acl and user_xattr. Those options must be specified when mounting the lfs partition, possibly in the fstab... Distributions usually do not do that by default. Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Le 21/04/2014 18:13, Hazel Russman a écrit : I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 of LFS-systemd does not include this user in /etc/passwd). Adding it reduced the number of errors from 47 to 10. However I have not been able to reduce them any further. BLFS also recommends giving bin and daemon proper home directories (I used /bin and /sbin respectively) and a shell, but this had no effect in my case. As far as I know, the acl and user_xattr options required for acl to work on the mounted lfs partition are built into the ext4 driver that my host kernel (3.10.17) uses and do not need to be set explicitly. When I do set them, they are accepted silently but don't show up in /proc/mounts, whereas noacl and nouser_xattr do. I attach an edited log file containing the actual test errors. I need to know if they are important and, if so, how to get rid of them. Looking more closely at your log, it seems that acl's are enabled, because the line beginning with [95]: 'getfacl --omit-header f' correctly returns acl entries: user::rw- user:bin:rw- user:daemon:r-- Actually, the line beginning with [91], which returns the first error, seems to choke on g:users:rw. Do you have a users group in /etc:group? Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
Le 21/04/2014 19:25, Pierre Labastie a écrit : Le 21/04/2014 18:13, Hazel Russman a écrit : I am building a 7.5 LFS with systemd and currently working through chapter 6. Having successfully installed coreutils, I rebuilt acl and ran the test suite. Initially I got 47 errors! According to BLFS, the acl test suite requires a daemon user who is also in the bin group (currently section 6.6 of LFS-systemd does not include this user in /etc/passwd). Adding it reduced the number of errors from 47 to 10. However I have not been able to reduce them any further. BLFS also recommends giving bin and daemon proper home directories (I used /bin and /sbin respectively) and a shell, but this had no effect in my case. As far as I know, the acl and user_xattr options required for acl to work on the mounted lfs partition are built into the ext4 driver that my host kernel (3.10.17) uses and do not need to be set explicitly. When I do set them, they are accepted silently but don't show up in /proc/mounts, whereas noacl and nouser_xattr do. I attach an edited log file containing the actual test errors. I need to know if they are important and, if so, how to get rid of them. Looking more closely at your log, it seems that acl's are enabled, because the line beginning with [95]: 'getfacl --omit-header f' correctly returns acl entries: user::rw- user:bin:rw- user:daemon:r-- Actually, the line beginning with [91], which returns the first error, seems to choke on g:users:rw. Do you have a users group in /etc:group? Pierre s@/etc:group@/etc/group@ sorry. Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On Mon, 21 Apr 2014 19:25:10 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: Looking more closely at your log, it seems that acl's are enabled, because the line beginning with [95]: 'getfacl --omit-header f' correctly returns acl entries: user::rw- user:bin:rw- user:daemon:r-- Actually, the line beginning with [91], which returns the first error, seems to choke on g:users:rw. Do you have a users group in /etc:group? Pierre Thank you very much. That was the source of the problem. Adding the users group cleared all the remaining errors. But I notice that this group, like the daemon user, are not specified in section 6.6 where /etc/passwd and /etc/group are created. Should they be? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ACL check errors: are they important?
On Mon, Apr 21, 2014 at 06:36:19PM +0100, Hazel Russman wrote: On Mon, 21 Apr 2014 19:25:10 +0200 Pierre Labastie pierre.labas...@neuf.fr wrote: Looking more closely at your log, it seems that acl's are enabled, because the line beginning with [95]: 'getfacl --omit-header f' correctly returns acl entries: user::rw- user:bin:rw- user:daemon:r-- Actually, the line beginning with [91], which returns the first error, seems to choke on g:users:rw. Do you have a users group in /etc:group? Pierre Thank you very much. That was the source of the problem. Adding the users group cleared all the remaining errors. But I notice that this group, like the daemon user, are not specified in section 6.6 where /etc/passwd and /etc/group are created. Should they be? From memory (so, I might be wrong) the book doesn't ever create a 'users' group in LFS. What we as individuals have to do may differ. I came here via RedHat-6 and Mandrake-7 and shared /home between the systems I was running at the time. So /home/ken is owned by user 500 and group 1000 : I create ken as user 500 and add a users group of 1000 whenever I build a new system. When I was using ppc I had a user/group combination from debian-based systems - the numbers were quite different. So, I _guess_ that the 'users' group exists on your host system and you will need to create it in LFS to get these tests to work. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
