Updated buildscripts (2.2.7)

Matthew Burgess ca9mbu at hermes.sunderland.ac.uk
Sun Apr 13 15:09:33 PDT 2003

On Sun, 13 Apr 2003 21:53:39 +0000 (UTC)
lfsbill at wlmcs.com (Bill's LFS Login) wrote:

> 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.

But running the coreutils tests as roots causes many of them to be

> > 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.

No, I'm not doing a remote install, sorry for the lack of clarity there. 
I was thinking that you could do a `echo rootpassword | su -c root make
check` but then of course you get the error message that you can't su from
anything other than a term.

<snipped intriguing hints towards a nifty portable solution>

> 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.

Well I did a bit of digging and the result was the sudo suggestion.  I
thought I'd pass it on as it works for me, and thought it might be useful.
 I realised there were limitations to it and described those as well.  I
wasn't aware that Ryan (or anyone else for that matter) was installing
coreutils as part of the PLFS builds and therefore thought I'd contribute
something I had noticed in time for when the PLFS/LFS stuff incorporates
it.  I wasn't intending to increase Ryan's or Greg's workload by any
means, hence I mentioned the observations and trial workarounds that I had

Oh well, I'll leave Ryan/Greg to contact you if they feel these tests
should be run.


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