Updated buildscripts (2.2.7)

Bill's LFS Login lfsbill at wlmcs.com
Sun Apr 13 18:11:05 PDT 2003


On Sun, 13 Apr 2003, Matthew Burgess wrote:

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

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

Yes, and running them as root cause many to be skipped too. :-(

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

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

I wasn't making any aspersions or suggesting that you had not. I was
just saying that my approach was to carry this part of the burden
ourselves.

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

For any individual's effort, I see nothing wrong with sudo. It will do
the job just fine. If the effort was a more generalized approach, in
which the platform was indeterminate, I feel that it would be less
useful due to the dependancy on having the package installed (some
distro's don't include it in default setup) and could not be assured to
run reliably and trouble-free regardless of user experience level and
*IX host distro.

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

I hope my intent was not misunderstood. To accomplish what you're after,
sudo works, is useful and I would offer no objections at all. I know
Ryan is working on something related to the issue ATM, but I do not know
what approach he's taking.

>
> Regards,
>
> Matt.

Forge ahead! :)

>

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