Updated buildscripts (2.2.7)

Bill's LFS Login lfsbill at wlmcs.com
Sun Apr 13 15:00:12 PDT 2003


On Sun, 13 Apr 2003, Matthew Burgess wrote:

> On Tue, 8 Apr 2003 00:31:31 +0000 (UTC)
> Ryan.Oliver at pha.com.au wrote:
>
> > Also for those that have not been following on lfs-dev, please note that
> > these scripts are a __test_framework__ .
>
> As such could I ask that the coreutils section has a `make check-root`
> command executed please?  `make check` will skip certain tests that
> require root permissions which of course we don't have because we're an
> unprivileged user when building aren't we boys and girls :)  When I first

Optional. I used to run the "Chapter 5" stuff as non-root, but for
helping testing, I now run as root to stay closer to what Ryan does.

> saw this I thought, oh well I'll just run `make check` as root then, but
> it has tests in there that require non-root privileges.  So I propose the
> following after the initial `make check` (line 1006):
>
>    which sudo > /dev/null
>    if [ $? -eq 0 ]; then
>      sudo -u root make check-root \
>        >>  ${LOGFILE} 2>&1 &&
>      echo " o Test OK" &&
>    fi
>
> Of course this relies on the host having sudo

Just one of the reasons I suggest that this not be done.

> (http://www.courtesan.com/sudo/) already installed (or it being installed
> prior to coreutils in chap 5.).  It also requires the LFS user to be
> listed in /etc/sudoers in order to be able to execute anything under
> `sudo` privileges.  I thought about using `su` instead as it should be
> guaranteed to be available on any distro but you can't script the input of
> a password (which would be ludicrous anyway having to specify root's
> password in a clear text shell script!).

Installing from a remote node? On IP? That sounds a little risky anyway.
I would suggest using a secure link (ssh or hardwarired terms) into the
target node to overcome that objection.

Since su will *not* accept a password from anywhere but a term
(controlling tty), a password can not be scripted in a shell anyway.

>
> Just some food for thought :)

I have been giving this some thought and it seems that a technique I
used back in '89 or so would be ideal. I will not say more here. If Ryan
has an interest (after all, this is *only* a test harness and the
constant feature-addition has to stop somewhere), I will discuss it with
him or Greg.

If they want to use it, it has these advantages.

It works on any standard type of *IX system.
It is version independent.
It can be fully scrippted.
It is flexible and can be used for other purposes.
It can be made as secure or as open as desired.
It requires no software other than what is on a standard *IX system.

I've used sudo and it's alright. It incorporates some of the same
features as this old technique, but implements the facility in a way
that that is different.

To forestall questions about why I don't describe it here, I'll say
that I wish to help in Greg and Ryan's effort, not add to the workload.
If they have an interest in doing this for a *test harness*, I'll pass
it on to them.

Personally, I feel that it would be better to do a little digging and
custom scripting to accomplish this (I have started reviewing dejagnu
towards that end), because it is only a test harness.

>
> Matt.
>

-- 
Bill Maltby
lfsbill at wlmcs.com

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list