Created the branch to develop new XSL stylesheets
Hi, A branch to develop the new XSL stylesheets has been justs created. To work with that branch: $ svn co svn+ssh://[EMAIL PROTECTED]/LFS/trunk/BOOK new-xsl $ cd new-xsl/stylesheets $ svn switch svn+ssh://[EMAIL PROTECTED]/LFS/branches/new-xsl . From now on, an svn up on the new-xsl/ dir will update book files to trunk, but stylesheets files to the new-xsl branch. This stylesheets branch contains the required files from the most current docbook-xsl-snapshot tarball, thus there is no need to install the newer DocBook-XSL package on the system to render the book, until 1.72.1 version will be released and the new stylesheets developed. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LTP mincore01 failure explained
After quite a bit of analysis and other research, I have found that the Linux Test Project mincore01 (memory-in-core) tests are invalid in that they always expect a failure when a success is sometimes valid. I learned a lot from this exercise as I had to instrument the kernel with printk statements and follow the code. The tests use mmap and mincore to check if memory is in core or not (swapped). Internally the kernel memory for a process is managed via vma structures (virtual memory area) in a linked list. The mmap function associates a memory area with a file or an anonymous area and creates an associated vma structure. The kernel's mincore function cycles through the vma list, starting at the address in the function call, checking to see if specific memory pages are in memory and associated with (any) file. If adjacent areas are properly mapped, the LTP mincore01 tests incorrectly reports an unexpected success. After a brief exchange on lkml, I also found that 2.6.21-rc changes mincore to succeed on anonymous areas too, so the other mincore01 tests may fail in the future. I have filed a bug with the LTP about this problem. The bottom line is that all the base tests of the LTP either pass or can be explained as proper for LFS builds. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
user nobody and test suites
I dunno if any of you have tried it, but we can use nobody for the Coreutils tests. Add nogroup and nobody to /etc/group, and nobody in /etc/passwd in the nobody group. For the src/su command, add '-s /bin/sh' so that /bin/false won't be used. I'd also like to suggest we use /sbin/nologin (from Shadow), instead of /bin/false. 'nologin' is the same as 'false', except it gives a polite message explaining the account is suspended. It's intended for login accounts, while /bin/false is intended for everything else. Robert pgpvnQnHQXMYB.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: user nobody and test suites
On 3/25/07, Robert Connolly [EMAIL PROTECTED] wrote: I dunno if any of you have tried it, but we can use nobody for the Coreutils tests. Add nogroup and nobody to /etc/group, and nobody in /etc/passwd in the nobody group. For the src/su command, add '-s /bin/sh' so that /bin/false won't be used. That seems fine to me. I'd also like to suggest we use /sbin/nologin (from Shadow), instead of /bin/false. 'nologin' is the same as 'false', except it gives a polite message explaining the account is suspended. It's intended for login accounts, while /bin/false is intended for everything else. Also seems fine to me, but I have no idea what the history/implications of that change would be. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: user nobody and test suites
Dan Nicholson wrote: On 3/25/07, Robert Connolly [EMAIL PROTECTED] wrote: I dunno if any of you have tried it, but we can use nobody for the Coreutils tests. Add nogroup and nobody to /etc/group, and nobody in /etc/passwd in the nobody group. For the src/su command, add '-s /bin/sh' so that /bin/false won't be used. That seems fine to me. I don't agree. The nobody user should never have a valid login shell or home directory. If a temporary user is needed for the Coreutils tests, add a temp user and then as the INSTALL file says, `sudo env NON_ROOT_USERNAME=$USER make -k check`. Delete the temp user when done. I know we don't build sudo in LFS, but perhaps an equivalent su command could be used. I'd also like to suggest we use /sbin/nologin (from Shadow), instead of /bin/false. 'nologin' is the same as 'false', except it gives a polite message explaining the account is suspended. It's intended for login accounts, while /bin/false is intended for everything else. Also seems fine to me, but I have no idea what the history/implications of that change would be. Using /sbin/nologin to give a polite message for accounts that should *never* be tried is overkill. To me, its not an accident and users trying that don't need or deserve courtesy. I prefer /bin/false. That said, it doesn't make a practical difference. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Remarks on LFS-6.2
On 3/21/07, Matthew Burgess [EMAIL PROTECTED] wrote:
I'd be interested if you can reproduce your tens of failures using jhalfs, if
only to rule out a) mistakes in any build scripts you might be using and/or
b) mistakes made when copying/pasting/typing the commands from the book.
scripts or running the commands by hand).
False alarm, sorry.
I'd thought that that was because of patches I'd used, but when I
built my *LFS again from the beginning, these tests mysteriously
succeed. Only three failures: annexc, tst-cancel1, tst-cancel24.
Again, please note that LFS
doesn't currently support 64-bit architectures. If you're wanting to build
LFS on such a box, the recommended method is to use the CLFS instructions.
Nevertheless, now I've finished building a __pure__ 64-bit *LFS
without use of the cross compilation, with slight deviations from the
book. All the libraries now are 64-bit and they're placed in
{,/usr}/lib instead of {,/usr}/lib64. In order to achieve this, six
different patches (four patches for gcc, two for glibc) were written
and applied at a different stages of a build process.
My toolchain:
binutils-2.17.50.0.12
gcc-4.1.2
glibc-2.5
Regards,
Fix
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: user nobody and test suites
On 3/25/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Dan Nicholson wrote: On 3/25/07, Robert Connolly [EMAIL PROTECTED] wrote: I dunno if any of you have tried it, but we can use nobody for the Coreutils tests. Add nogroup and nobody to /etc/group, and nobody in /etc/passwd in the nobody group. For the src/su command, add '-s /bin/sh' so that /bin/false won't be used. That seems fine to me. I don't agree. The nobody user should never have a valid login shell or home directory. If a temporary user is needed for the Coreutils tests, add a temp user and then as the INSTALL file says, `sudo env NON_ROOT_USERNAME=$USER make -k check`. Delete the temp user when done. If I understand Robert correctly, the nobody user doesn't have to have a valid home directory or login shell. He's just saying to execute su -s /bin/bash ... so that /bin/false isn't used. You can does this anyway right now. # grep ^nobody /etc/passwd nobody:x:99:99:unprivileged nobody:/dev/null:/bin/false # su -s /bin/bash nobody -c echo no home directory needed no home directory needed Oh, we already create nobody:nobody in LFS, so we could do this right now. I know we don't build sudo in LFS, but perhaps an equivalent su command could be used. It works fine right now with the src/su that's built during coreutils. But one thing I want to try to do before 6.3 is build the non-suid su during Ch. 5 coreutils so that we can also switch users during the bash testsuite. I'd also like to suggest we use /sbin/nologin (from Shadow), instead of /bin/false. 'nologin' is the same as 'false', except it gives a polite message explaining the account is suspended. It's intended for login accounts, while /bin/false is intended for everything else. Also seems fine to me, but I have no idea what the history/implications of that change would be. Using /sbin/nologin to give a polite message for accounts that should *never* be tried is overkill. To me, its not an accident and users trying that don't need or deserve courtesy. I prefer /bin/false. That said, it doesn't make a practical difference. Sure. Maybe it's worth a mention that system users get /bin/false but that /sbin/nologin can also be used. In fact, I don't think that the /dev/null home directory, /bin/false login shell is currently explained anywhere in LFS or BLFS. The discussion would be good even if we don't change the current situation. I know it seemed strange to me the first time I saw one of those entries in passwd. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: user nobody and test suites
Dan Nicholson wrote: On 3/25/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Dan Nicholson wrote: On 3/25/07, Robert Connolly [EMAIL PROTECTED] wrote: I dunno if any of you have tried it, but we can use nobody for the Coreutils tests. Add nogroup and nobody to /etc/group, and nobody in /etc/passwd in the nobody group. For the src/su command, add '-s /bin/sh' so that /bin/false won't be used. That seems fine to me. I don't agree. The nobody user should never have a valid login shell or home directory. If a temporary user is needed for the Coreutils tests, add a temp user and then as the INSTALL file says, `sudo env NON_ROOT_USERNAME=$USER make -k check`. Delete the temp user when done. If I understand Robert correctly, the nobody user doesn't have to have a valid home directory or login shell. He's just saying to execute su -s /bin/bash ... so that /bin/false isn't used. You can does this anyway right now. # grep ^nobody /etc/passwd nobody:x:99:99:unprivileged nobody:/dev/null:/bin/false # su -s /bin/bash nobody -c echo no home directory needed no home directory needed Oh, we already create nobody:nobody in LFS, so we could do this right now. I see. I withdraw my objection. I'd also like to suggest we use /sbin/nologin (from Shadow), instead of /bin/false. 'nologin' is the same as 'false', except it gives a polite message explaining the account is suspended. It's intended for login accounts, while /bin/false is intended for everything else. Also seems fine to me, but I have no idea what the history/implications of that change would be. Using /sbin/nologin to give a polite message for accounts that should *never* be tried is overkill. To me, its not an accident and users trying that don't need or deserve courtesy. I prefer /bin/false. That said, it doesn't make a practical difference. Sure. Maybe it's worth a mention that system users get /bin/false but that /sbin/nologin can also be used. In fact, I don't think that the /dev/null home directory, /bin/false login shell is currently explained anywhere in LFS or BLFS. The discussion would be good even if we don't change the current situation. I know it seemed strange to me the first time I saw one of those entries in passwd. Additional explanation in chapter06/createfiles.html would never be a bad thing. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Remarks on LFS-6.2
Fix wrote:
Nevertheless, now I've finished building a __pure__ 64-bit *LFS
without use of the cross compilation, with slight deviations from the
book. All the libraries now are 64-bit and they're placed in
{,/usr}/lib instead of {,/usr}/lib64. In order to achieve this, six
different patches (four patches for gcc, two for glibc) were written
and applied at a different stages of a build process.
My toolchain:
binutils-2.17.50.0.12
gcc-4.1.2
glibc-2.5
Some benchmarks against a 32-bit build would be interesting. My
understanding is that 64-bit systems have larger binaries, use more ram,
and are slower the equivalent 32-bit systems unless you are doing some
fairly serious number crunching.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: user nobody and test suites
On 3/25/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Dan Nicholson wrote: On 3/25/07, Bruce Dubbs [EMAIL PROTECTED] wrote: I don't agree. The nobody user should never have a valid login shell or home directory. If a temporary user is needed for the Coreutils tests, add a temp user and then as the INSTALL file says, `sudo env NON_ROOT_USERNAME=$USER make -k check`. Delete the temp user when done. If I understand Robert correctly, the nobody user doesn't have to have a valid home directory or login shell. He's just saying to execute su -s /bin/bash ... so that /bin/false isn't used. You can does this anyway right now. # grep ^nobody /etc/passwd nobody:x:99:99:unprivileged nobody:/dev/null:/bin/false # su -s /bin/bash nobody -c echo no home directory needed no home directory needed Oh, we already create nobody:nobody in LFS, so we could do this right now. I see. I withdraw my objection. Well, we still have to decide whether we want to use nobody or continue using temporary users. I could go either way, but I do like the idea of not having to mangle passwd just to run a testsuite. We'd still have to create at least one extra group for coreutils, though. Also, I'm wondering if there would be problems running scripts, etc., when HOME=/dev/null. The dummy user we create for coreutils is given /root as it's home directory. Robert, do you see any issues running the testsuites as nobody? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: user nobody and test suites
On Sunday March 25 2007 22:30, Dan Nicholson wrote: Also, I'm wondering if there would be problems running scripts, etc., when HOME=/dev/null. The dummy user we create for coreutils is given /root as it's home directory. Robert, do you see any issues running the testsuites as nobody? I used this for passwd: nobody:x:65534:65534:Unprivileged User:/nonexistent:/sbin/nologin And this for group: nogroup:x:65533: nobody:x:65534: The home directory doesn't seem to matter unless you try to login (use su --login). 'HOME=/nonexistent' is in nobody's environment, but it doesn't seem to bother anything. One Coreutils test didn't pass, but I don't think it was related to these nobody users/groups. Bash's test suite can run as nobody: su-tools nobody -s /bin/bash -c make tests but the Bash sources need to be writtable by nobody first. It passed without errors. robert pgpbJ5EzpUTVD.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: user nobody and test suites
Robert Connolly wrote: On Sunday March 25 2007 22:30, Dan Nicholson wrote: Also, I'm wondering if there would be problems running scripts, etc., when HOME=/dev/null. The dummy user we create for coreutils is given /root as it's home directory. Robert, do you see any issues running the testsuites as nobody? I used this for passwd: nobody:x:65534:65534:Unprivileged User:/nonexistent:/sbin/nologin And this for group: nogroup:x:65533: nobody:x:65534: The use of 65534 for a uid or gid is not a good idea. It comes from old time usage in nfs and nowhere else. *If* nfs does not find a nobody user, it defaults to -2. Since the uid/gid are 16 bit numbers, this equates to 65534. There are two things wrong with this. First it makes the /var/log/wtmp look very large when viewing with ls -l. du /var/log/wtmp does show the correct disk usage though as it is a sparse file but the ls -l can confuse users that don't know its a sparse file (or even what a sparse file is). If the file system does not support sparse files, the file really is huge. I think most modern distros use 99 for nobody as we do. I know RedHat does at least as far back as RH9. They do have a nfsnobody user, but that is merely for an ls -l display if accessing a disk with very old practices. Secondly, if a user is able to log in somehow and the home directory does not exist, it defaults to /. You see this if a home directory is on a separate partition that is not mounted. This is why root's home directory is always /root and not /home/root. I highly recommend using /dev/null instead of /nonexistent. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Remarks on LFS-6.2
On 3/26/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Some benchmarks against a 32-bit build would be interesting. My understanding is that 64-bit systems have larger binaries, use more ram, and are slower the equivalent 32-bit systems unless you are doing some fairly serious number crunching. Yes, such a benchmark would be interesting. Can you suggest a suitable benchmark tool? Fix -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Remarks on LFS-6.2
Fix wrote: On 3/26/07, Bruce Dubbs [EMAIL PROTECTED] wrote: Some benchmarks against a 32-bit build would be interesting. My understanding is that 64-bit systems have larger binaries, use more ram, and are slower the equivalent 32-bit systems unless you are doing some fairly serious number crunching. Yes, such a benchmark would be interesting. Can you suggest a suitable benchmark tool? I really don't know for sure, but a quick Google for 'linux benchmark suite' leads me to http://lbs.sourceforge.net/. I'd start there. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: user nobody and test suites
On Monday March 26 2007 01:11, Bruce Dubbs wrote: The use of 65534 for a uid or gid is not a good idea. It comes from old time usage in nfs and nowhere else. *If* nfs does not find a nobody user, it defaults to -2. Since the uid/gid are 16 bit numbers, this equates to 65534. There are two things wrong with this. First it makes the /var/log/wtmp look very large when viewing with ls -l. du /var/log/wtmp does show the correct disk usage though as it is a sparse file but the ls -l can confuse users that don't know its a sparse file (or even what a sparse file is). If the file system does not support sparse files, the file really is huge. I thought it had more to do with 65534 being the last available 16-bit ID (even though Linux handles 32-bit ID's). The last available ID is generally thought of as the least privileged user, although technically it is not. I think most modern distros use 99 for nobody as we do. I know RedHat does at least as far back as RH9. They do have a nfsnobody user, but that is merely for an ls -l display if accessing a disk with very old practices. Using 99 works, but I think 65534 is more widely understood as the 'nobody' ID... in that if you see a uid 65534 in a tar archive you automatically know it once belonged to 'nobody'. A group ID of 65533 would be easy to assume as a close relative of 'nobody', such as 'nogroup'. There are probably uses for this assumption, but the only one I can think of is when unpacking binary tarballs with programs like 'kdesud' which are 'sgid nogroup'. Using these large and old fashioned ID numbers is logical to me, even though there's no technical merit to it. I could see ID 99 becoming understood as 'nobody', but currently I don't think it is (in the scope of the *nix community). Secondly, if a user is able to log in somehow and the home directory does not exist, it defaults to /. You see this if a home directory is on a separate partition that is not mounted. This is why root's home directory is always /root and not /home/root. I highly recommend using /dev/null instead of /nonexistent. Using /nonexistant is usefull if you set 'DEFAULT_HOME no' in /etc/login.defs. Using /dev/null would also work with the DEFAULT_HOME setting because it's not a directory. I don't see either one having an advantage over the other, except that one exists and the other does not... and considering what /dev/null is, it leaves a gray area of difference. robert pgpMgDrWgqieT.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: user nobody and test suites
On 3/25/07, Robert Connolly [EMAIL PROTECTED] wrote: Using 99 works, but I think 65534 is more widely understood as the 'nobody' ID... in that if you see a uid 65534 in a tar archive you automatically know it once belonged to 'nobody'. A group ID of 65533 would be easy to assume as a close relative of 'nobody', such as 'nogroup'. There are probably uses for this assumption, but the only one I can think of is when unpacking binary tarballs with programs like 'kdesud' which are 'sgid nogroup'. Using these large and old fashioned ID numbers is logical to me, even though there's no technical merit to it. I could see ID 99 becoming understood as 'nobody', but currently I don't think it is (in the scope of the *nix community). On Fedora, they have both: $ grep nobody /etc/passwd nobody:x:99:99:Nobody:/:/sbin/nologin nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin $ grep nobody /etc/group nobody:x:99: nfsnobody:x:65534: -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
