On Mon, Oct 07, 2013 at 05:09:52PM -0500, Dan McGhee wrote:
> I use the more_control hint in my builds. I need <su> before I start
> working in Ch. 6. It's used to go back and forth between 'root' and a
> 'package_user.' When coreutils still supplied <su>, the procedure was
> just to copy it to /tools/bin after installing coreutils to the build
> chain. Su itself was not installed because user 'lfs' is the installer
> and coreutils wanted to install it suid root. In the 'package users'
> system, there is no need for it to be suid root, but it's needed before
> the installation of shadow in Ch. 6.
>
> One option is to install 'shadow' at the beginning of Ch. 6, but that
> leads to some hiccups down the road. They're not insurmountable, but
> they can be frustrating. I'm want to install only <su> from shadow
> before I get to Ch. 6. My problem is that I know only enough about
> <make> and <make install> to make me dangerous, and I get bogged down
> reading the documentation.
>
> Knowing that there are some packages in LFS that will either make one
> target or install one target or copy the desired binary from the source
> directory, I looked in the configure and makefile and just couldn't see
> a way to do what I wanted. After I compiled it, I found all the
> programs shadow installs in a directory called src. In it are sets of
> files in the form <filename.{,c,o}>. Of course, in my situation I am
> interested in only su, su.c and su.o. At this point can I just copy su
> to /tools/bin? Do I need the other two files? If so, where do they go?
>
I'm extremely reluctant to encourage people to use that hint (over
the years, the lists have seen many problems and often the users
have neglected to mention they are using it until after a lot of
investigation). But I see people are still using versions of it, so
here goes -
You don't need to install the .c file, it's the source code.
Similarly, the .o is object code from the compile - it then has to
be linked before you can execute ('run') it.
Probably, src/su will not need any further libs. But when you get
to desktop packages they often rely on their own libraries. To be
sure, run 'ldd' on src/su and confirm that it only uses system
libraries (if it uses others, they will probably be marked as 'not
found' if shadow isn't installed - I'm assuming you are already in
chroot, so system libs will be in /tools apart from the vdso).
> Alternatively, I have a question about how to use <make install>. The
> following is part of the output from <./install-sh --help>:
>
> > Usage: ./install-sh [OPTION]... [-T] SRCFILE DSTFILE
> > or: ./install-sh [OPTION]... SRCFILES... DIRECTORY
> > or: ./install-sh [OPTION]... -t DIRECTORY SRCFILES...
> > or: ./install-sh [OPTION]... -d DIRECTORIES...
> >
> > In the 1st form, copy SRCFILE to DSTFILE.
> > In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
> > In the 4th, create DIRECTORIES.
>
> The way I see this is that I'll get what I want if I run <make install
> su /tools/bin>
> Is this correct? Of course, I'm back to the copy mode if I can't
> install this as user lfs. I do not want it suid.
>
Without looking at the Makefile(s), I'm reluctant to assume that
'make install' will do the same thing as ./install-sh. Perhaps it
does.
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.
If/when it is installed there, use ldd to confirm that it doesn't
need any not-present libraries.
But two more comments:
First, why not use --prefix=/tools when you configure it ?
Second, ISTR that su is a problem. My notes show that I tested the
code from
http://wiki.linuxfromscratch.org/hints/browser/trunk/PREVIOUS_FORMAT/more_control_and_pkg_man.txt?rev=904
last September (Bryan pointed to it last year, and I was
experimenting with building as a user to do DESTDIR LFS installs (so
I could log the files without accidentally doing a real install if
the package didn't respect DESTDIR - e.g. glibc uses INSTALLROOT or
similar). That didn't work for me (segfaulted when run as a user).
I perhaps tried su from the last version of coreutils - I'm not
sure. In the end, for BLFS I went through sudo (PITA, no added
security IMHO) and then found a (slow, voluminous) way of logging
all the files at the start of a package and after it completed, and
from that noting what got installed and what was updated -
My method still gives me erroneous 'updated' files if the first
attempt to install fails (usually from fubars in my scripts, e.g.
hard-coded filenames/versions - static libs, usually - getting
renamed or deleted) - but then anyone who writes scripts needs to
expect failures, and to learn *how* their own scripts fail : I'm
still regretting moving to 'set -e' - my scripts are much shorter
but I miss my specific error messages ;-)
No doubt the other users of the hint can explain how to get su
working at the start of chapter 6. I would think that using the
last version of coreutils which included it is probably a more
productive way to go (or using a hardcoded su.c or su-tools.c if
anyone has one that works in this context).
ĸ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
