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?
>
A)
To answer the question about why putting the path change in
~/.bash_profile works and overrides the system alloted $PATH is
simple.
Order of execution.
/etc/profile is processed before ~/.bash_profile is executed, thus the
changes made in ~/.bash_profile are lasting since nothing wipes them
out.
B)
/usr/local and /opt are paths not necessarily used by a lot of people,
but when it is used the same rule differences apply to /usr/local/bin
and /usr/local/sbin as are applied to /usr/bin and /usr/sbin.
In general the sbin directories contain "system" commands and are viewed
as not necessary for the ordinary user. This does not prevent anybody
from modifying their own $PATH and adding the sbin directories if they
choose (as you already found out); it is simply a starting point.
HTH
Jeff
> Explain it to me please.
