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.
