On Wed, 2006-04-05 at 18:12 -0400, Gene Heskett wrote: > 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. ---- I don't see how you could conclude I was on any high horse or was trying to be any thing but helpful. I was trying to show you... - the methodology used by the rpm packaging of amanda - the location of things including the the bash_profile for the amanda user from the rpm packaging. - suggesting that it would be simpler to take the tarball and building the rpm from the tarball instead of sending it to /usr/local since all of the things you seem to be struggling with (the user amanda and bash_profile) were already handled in the spec file for the source rpm which probably wouldn't need much adjustment for the newer version. The fact that Matthew Saltzman pretty much pointed to the same thing should have been an indication that there was some sound reasoning behind this. More to the point though, I understand your inclination to do all these source compiles by yourself and judging from your posting history, am rapidly coming to the conclusion that you don't bother with rpm packaging because you have never done it and simply opt for ./compile && make && make install because you got that much down. Evidently, a users environment is still a struggle for you. I was trying to suggest - if you can see things clearly - that you can obtain the spec file from the amanda SRPM, and build rpm's, using their spec file from a more recent tarball and probably have little extra effort. Please adjust your attitude - if you don't see the wisdom here, I'm sorry that I was unclear. ---- > > 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. ---- you can set the build options in the spec file if you want. I fail to see your point here. Personally, I think just about all users would be better off using Fedora packaged rpms of amanda. Though I should add, I've been fooling with bacula lately and it has a lot more features than amanda and seemingly works very well and would suggest that over amanda for someone with no experience with either. ---- > > >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. ---- I am not the packager of amanda rpms so I can't answer that. Does it really matter? If you do a 'useradd -m -d /var/lib/amanda' then it would exist on FC-2. If the pre or post rpm scripts tell it to check for the user amanda and failing to find the user, execute a command similar to above, then the user is created and the home directory as specified is created. What is so difficult to understand there? I will point out that it is not uncommon for daemon users to have their 'home' directory in /var/lib It is common for Red Hat / Fedora systems to put them there. Try executing # getent passwd|grep '/var/lib' to see a list of daemons whose home directories are in the place where you would never think to put it. I would suppose that is 'tuncket' why it amanda home is in /var/lib. ---- > > ># 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. ---- absolutely, if you are going to build from source and not use rpm and therefore, to minimize the risk of overwriting libraries with an unintelligent installer, /usr/local would be the right place to do that. Craig
