user $PATH problem
Gene Heskett
gene.heskett at verizon.net
Wed Apr 5 22:12:44 UTC 2006
On Wednesday 05 April 2006 11:56, Craig White wrote:
>On Wed, 2006-04-05 at 10:20 -0400, Gene Heskett wrote:
>> Greetings;
>>
>> I've been trying to help Anne Wilson setup a working amanda system
>> at her place for over a week now, and having all sorts of troubles
>> that were triggered by the amanda executables not being in the user
>> amanda's environmental path when she actually logs in as amanda, as
>> opposed to doing an 'su amanda' from root, which of course gets you
>> the full maryann of roots $PATH. Thats why when she sent me an
>> example of the command she was useing, it was always after cd'ing to
>> the amanda src tree and doing "./amcheck" or whatever, otherwise she
>> was getting not found messages.
>>
>> This was found by "su - amanda" means here, and its a huge gotcha
>> for the unwary. Seemingly un-necessary paranoia to me, but...
>>
>> When doing it as amanda, with amanda's full $PATH, /usr/local/sbin,
>> where all of amanda's executables live, is NOT in the $PATH.
>>
>> Adding it to ~/.bash_profile seems to allow it to survive the
>> pathmunge'ing being done in /etc/profile, so I'm A) confused as to
>> why it does, and B) in any event, is there a good reason to
>> dis-allow access to /usr/local/sbin for the normal user?
>>
>> Explain it to me please.
>
>----
>not entirely clear what you are asking.
>
>su -
>the implications are explained in the info page to su...you need the
> '-' to obtain the shell environment (bash_profile, etc.) of the user
> login.
>
>Not sure why you guys aren't using the rpm packages instead of
> compiling from source/tarball - or if you feel you need newer
> versions, why not download tarball and make an rpm from the spec file
> from amanda source. All of the heavy lifting should be already done
> for you and these would be non-issues and updating would be simple.
Back on that high horse again. Its actually pretty simply explained
Craig. While I've not looked at every amanda rpm extant, those that I
have were obviously configured and built by a non-user of the software,
resulting in configuration options that are hard coded into amanda so
that it stands only a small snowballs chance of working either because
of something being left out or set sub-optimaly, forcing the newbie
user into working within the configuration, or as seen on the
amanda-users list, simply gave up and tried something else. I long ago
comitted my configuration options to a script so I don't get attacked
by impending alzheimers or something. These have made it so I can grab
the next snapshot when Martin puts it on the server, download it,
unpack it, configure, build, install and run a function check on it,
all in about 15 minutes, ten of which I've been on this screen looking
at email.
And because there are in fact, numerous options to set for each system,
I wouldn't feel at all comfortable building an rpm for it for
publication because I would then be doing the same thing to everyone
else, forcing my version of reality on them. I'd much rather copy the
mail on the user list and help the newbies where I can, and I shut the
heck up if I can't.
>anyway...normal usage would not allow a user access to /sbin
>or /usr/sbin but in checking from rpm package install of amanda
>that /var/lib/amanda/.bash_profile looks like below (amanda's home
>directory in rpm package install being /var/lib/amanda)...
>
># .bash_profile
>
># Get the aliases and functions
>if [ -f ~/.bashrc ]; then
> . ~/.bashrc
>fi
What in tuncket is it doing in /var/lib/amanda? Its expected to be
in /home/amanda. Talk about a surprise, Sheesh. It (/var/lib/amanda)
doesn't exist on this FC2 system.
># User specific environment and startup programs
>
>PATH=$PATH:$HOME/bin
>PATH=$PATH:/usr/sbin
>BASH_ENV=$HOME/.bashrc
>USERNAME="amanda"
And again, locally built stuff goes in /usr/local unless you override
that on the ./configure line. This is another argument point as to
where it belongs and one can argue both ways I suppose.
>export USERNAME BASH_ENV PATH
>
>Which to me means that you should adjust for your different paths of
> the amanda routines/binaries in /usr/local/sbin and thus, allow by
> necessity, the user amanda access to these files as some of these
> will fail if run by root (as I'm sure you know).
Which we've now done. And yes I'm well aware of it, so much so that
even my config script tests to make sure it not running as root, by
specifically makeing sure that the user amanda is running it:
===============================
#!/bin/sh
# since I'm always forgetting to su amanda...
if [ `whoami` != 'amanda' ]; then
echo
echo "!!!!!!!!!!!! Warning !!!!!!!!!!!!"
echo "Amanda needs to be configured and built by the user amanda,"
echo "but must be installed by user root."
echo
exit 1
fi
make clean
rm -f config.status config.cache
./configure --with-user=amanda \
--with-group=disk \
--with-owner=amanda \
--with-gnu-ld \
--prefix=/usr/local \
--with-tapedev="FILE:/amandatapes" \
--with-debugging=/tmp/amanda-dbg/ \
--with-tape-server=coyote \
--with-amandahosts \
--with-configdir=/usr/local/etc/amanda \
--with-config=Daily \
--with-gnutar=/usr/local/bin/tar
make
=====================================
Except for the location of tar (I have the 1.15-1 from a tarball build
there, while the older 1.13-25 is in /usr/bin) every one of those
options might need adjusted at some other site/some other
os/whathaveyou. So its only an example, a syntax example at that.
>Craig
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
More information about the users
mailing list