Re: [lfs-support] More control and package management using package users
On 10/07/2013 11:27 PM, Rob Taylor wrote:
Dan,
The build script itself already exists in the
more_control_helpers.tar.bz2 which is as it was before I got to it.
I altered it a little but for the most part it is as I found it. Now
that is not to say that I can not explain most of what it does... I
can, however I don't want to take credit for its design or function.
Now some things become quite clear for me in the historical sense. After
reading this e-mail, I went to the Change Log in the hint and saw some
things dating back to 2005. I wasn't aware of these. I'm trying to
find the exact date, but my last download of the scripts and helpers
must have been before Matthias' update in Dec, 2005. Whenever I got
ready to build LFS I just skimmed the hint to see if there were any
major changes, but used the one I had originally printed and maintained
my notes. I can't find it now. Drat! I thought you had developed the
build.conf concept, but apparently you didn't. Still. The wrappers you
modified and the helpers you designed, IMO, should be mentioned in the
Change Log. Build.conf is NOT in that log. That's why I thought you
did it and why you should make entries there. Some people do read those
things. :)
Re:root_{pre,post}_install
I noticed that when a function is missing from the build.conf file,
the step is just skipped. It appears that Matthias was experimenting
with this and didn't include it in the build.conf. I haven't tested
it, but the -c switch given to the su command is generally how you can
execute a script or command as a different user. So calling the script
itself with a specific option mentioned, and executing it as an option
to the su command should theoretically execute that phase of the
script as the specified user (in this case root). I expect the build
script would pause at this point expecting the user to enter the root
password since I don't see how it is getting passed.
My conclusion is, then, that they don't exist yet. I'll stop looking.
First reaction: I can't remember if it's a vim or emacs convention, but
my experience is, when working with an executable script in a graphic
text editor, that no color coding indicates a syntax problem and the
script will stop running at that point. Usually it's an extra or
missing 'fi,' a typo or a bracket problem. When I get there, I'll test
this build script to see if it runs. How long has it been since you
used it? (I think there is an extra 'fi' when calling the
root_pre_install commands. But, as you said, if it's not in build.conf
it would skip to _install.)
Second reaction: I'm just gonna have to look in the Advanced Bash
Scripting Guide I have--after I make sure it's current--and check on su
in a script. Regardless of the parameters passed, I think it's a bash
no-no.
https://www.javacrypt.com/lfs/dev_user_package_management.txt
If you look at the source code for the wrapper scripts that I have
been working on, you will see they seem rather involved. I noticed
that there was a great variety of ways that packages used the
commands: install, rm, ln, sln, unlink, mkdir, chmod, chown, chgrp
etc.. I also noticed that they did things that don't even seem to be
documented, such as placing folder and file references first and
options last, or putting the -m option between source and target file
and directory options. Also did you know that it is perfectly
acceptable to have a line feed in the middle of a file name? One of
the packages test this and so my wrapper scripts had to become more
and more robust to deal with these oddities.
But on that note it is worth mentioning that the wrapper scripts are
not really required until the install step. If you suspect that a
make check or make test is failing due to the wrapper scripts you
can simply disable them by changing the path, for the build check step.
For example, the rebuild of coreutils to enable acl in the BLFS was
checking things that were not permitted by the wrapper scripts... so I
simply did this in the build.conf file for the check function:
check_commands()
{ :
# for whatever reason, the wrapper scripts caused make test to fail
so...
WRAPPER_PATH=$PATH;# back up the PATH
export PATH=/bin:/usr/bin:/sbin:/usr/sbin;
make test
export PATH=$WRAPPER_PATH;# restore the PATH
}
It's for these things I think you should take credit in the Change Log.
That's a lot of work.
I am creating a my_blfs_7_4_notes.txt file, to carry on from the
similarly named LFS file, but I am a long ways off from publishing it.
I read your lfs notes and your developer notes. Outstanding job.
I almost have the su thing ready to go. I've got to correct somethings
in my current build and then I'll at least get su in /tools. It will be
a couple of days before I get to Ch. 6 to test it.
Enjoy your vacation and take care,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ:
Re: [lfs-support] Getting su in Chapter 5 [SOLVED]
On 10/07/2013 08:33 PM, Bruce Dubbs wrote: Ken Moffat wrote: On Mon, Oct 07, 2013 at 11:59:00PM +0100, Ken Moffat wrote: The usual way to look at what gets installed is to run 'make DESTDIR=/path/to/somewhere install [ optional args ]' - once you get into DESTDIR installs for looking at what is installed you will find some packages use other variables (often INSTALLROOT or something like that) - if shadow is such a package,then running *as a user* will fail. So try it as a user, to a directory which that user can write to. OK, so you can't try a DESTDIR install as a normal user because you are root and 'su' doesn't exist. Build outside the new system as user lfs and do a DESTDIR, e.g. to /home/lfs/somewhere or /tmp/somewhere. The same for su from old coreutils (my notes show that I had to build all of coreutils to get su linked - there might be a shorter series of commands - but NOT which old version of coreutils last contained 'su'. If the only thing needed is su, then I'd build shadow with: ./configure make cp src/su /tools/bin It doesn't need to be suid since it's run by root. -- Bruce Thanks to you both. Ken, I had forgotten about DESTDIR and was able to refresh my memory. I have su now in the tool chain. I won't need it until I get to CH. 6, but with my OCD kicking in I wanted to build it just after coreutils in CH. 5. I suppose it doesn't really make any difference, but... Bruce, I've forgotten the ins and outs of login vs. nonlogin shells, but in the package user system su is used to go from 'root' to 'pkgusr.' Of course, then, it's run by root, but I have also used it to go from 'pkgusr' to 'root' so I don't have to keep logging in. The test for this build will occur when I get to Ch. 6. Thanks again to you both. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting su in Chapter 5 [SOLVED]
Dan McGhee wrote: On 10/07/2013 08:33 PM, Bruce Dubbs wrote: Ken Moffat wrote: On Mon, Oct 07, 2013 at 11:59:00PM +0100, Ken Moffat wrote: The usual way to look at what gets installed is to run 'make DESTDIR=/path/to/somewhere install [ optional args ]' - once you get into DESTDIR installs for looking at what is installed you will find some packages use other variables (often INSTALLROOT or something like that) - if shadow is such a package,then running *as a user* will fail. So try it as a user, to a directory which that user can write to. OK, so you can't try a DESTDIR install as a normal user because you are root and 'su' doesn't exist. Build outside the new system as user lfs and do a DESTDIR, e.g. to /home/lfs/somewhere or /tmp/somewhere. The same for su from old coreutils (my notes show that I had to build all of coreutils to get su linked - there might be a shorter series of commands - but NOT which old version of coreutils last contained 'su'. If the only thing needed is su, then I'd build shadow with: ./configure make cp src/su /tools/bin It doesn't need to be suid since it's run by root. Thanks to you both. Ken, I had forgotten about DESTDIR and was able to refresh my memory. I have su now in the tool chain. I won't need it until I get to CH. 6, but with my OCD kicking in I wanted to build it just after coreutils in CH. 5. I suppose it doesn't really make any difference, but... Bruce, I've forgotten the ins and outs of login vs. nonlogin shells, but in the package user system su is used to go from 'root' to 'pkgusr.' Of course, then, it's run by root, but I have also used it to go from 'pkgusr' to 'root' so I don't have to keep logging in. The test for this build will occur when I get to Ch. 6. I don't use the pkgusr technique. I just use jhalfs. That said, I think I'd install sudo from blfs just before chapter 6 for doing what you want. The syntax is easier and it can be set to not request a password. To use it, you would need to wait until after section 6.6. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting su in Chapter 5 [SOLVED]
On 10/08/2013 11:33 AM, Bruce Dubbs wrote: I don't use the pkgusr technique. I just use jhalfs. That said, I think I'd install sudo from blfs just before chapter 6 for doing what you want. The syntax is easier and it can be set to not request a password. To use it, you would need to wait until after section 6.6. -- Bruce Thanks, Bruce. It's been three years since I've done any of this, and the whole thing involves a lot of memory refreshment. In fact, in the last build I did, coreutils supplied su. So As far as using 'root' in pgkusers, there are two things: 1. ldcong 2. the commands in Ch. 6 that must be run as root. This all goes away after the shadow install and currently package user's scripts have one that works around needing to be root to use ldconfig. I've not tried it yet. AND, I never considered sudo until Ken mentioned it earlier. It's going to be a day or two until I get to CH. 6, but I'll see what the easiest approach will be. This AM, I used the copying method you suggested, but su needed a password and crypt killed the process. Probably because I'm still using the host system. Maybe things will be different after CHROOT. We'll see. Thanks again. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Errata for LFS 7.4
Minor issue with LFS 7.4 Host Requirements Changelog lists host system requirements changes for kernel to 2.6.34, however host requirement section only says 2.6.32 -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errata for LFS 7.4
On Oct 8, 2013, at 7:02 PM, Steve Crosby wrote: Minor issue with LFS 7.4 Host Requirements Changelog lists host system requirements changes for kernel to 2.6.34, however host requirement section only says 2.6.32 -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page http://www.linuxfromscratch.org/lfs/view/stable/prologue/hostreqs.html Linux 2.6.32 http://www.linuxfromscratch.org/lfs/view/stable/prologue/errata.html Errata is blank. What are you getting at? Which ChangeLog states 2.6.34? You need to post links, not just state things. Prove it. Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errata for LFS 7.4
On Oct 8, 2013, at 7:02 PM, Steve Crosby wrote: Changelog lists host system requirements changes for kernel to 2.6.34, http://www.linuxfromscratch.org/lfs/view/stable/chapter01/changelog.html Indeed, Not sure why Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Errata for LFS 7.4
On Tue, Oct 08, 2013 at 07:42:49PM -0500, William Harrington wrote: On Oct 8, 2013, at 7:02 PM, Steve Crosby wrote: Changelog lists host system requirements changes for kernel to 2.6.34, http://www.linuxfromscratch.org/lfs/view/stable/chapter01/changelog.html Indeed, Not sure why Sincerely, William Harrington The initial discussion was on lfs-dev on 6th July, starting at http://www.mailarchive.com/lfs-...@linuxfromscratch.org/msg18826.html if I've manually copied the link correctly (I'm on my netbook, need to use a tty to be able to _read_ my mail, don't have gpm). The value of --enable-kernel= was set to 2.6.34 in r10302. It got downgraded to 2.6.32 in r10327 in August, and obviously the log was overlooked. I don't recall why it got downgraded, and I couldn't find the reason in my mailboxes (which is not to say that it wasn't discussed). Personally I don't have anything running such an old kernel at the moment - everything is now on 3.10-rc or newer :) ĸ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
Re: [lfs-support] Errata for LFS 7.4
On Oct 8, 2013, at 8:28 PM, Ken Moffat wrote: The initial discussion was on lfs-dev on 6th July, starting at http://www.mailarchive.com/lfs-...@linuxfromscratch.org/msg18826.html if I've manually copied the link correctly (I'm on my netbook, need to use a tty to be able to _read_ my mail, don't have gpm). The value of --enable-kernel= was set to 2.6.34 in r10302. It got downgraded to 2.6.32 in r10327 in August, and obviously the log was overlooked. http://comments.gmane.org/gmane.linux.lfs.devel/14171 and here: http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg18939.html Two different threads. Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
