Interesting - is there any documentation out there about configuring RH7.2
from the RPM's.

I deleted my amanda user - and did an rpm -e on the amanda packages.

I then re-installed using the rpm -i command.

The install did not create a directory /home/amanda instead it created it in
/var/lib/amanda and there was a default amandahosts file there. Which I
think was the cause of my original problem - amcheck couldn't open
.amandahosts - I was trying to read the wrong version. I had two one in
/home/amanda which  had created by hand and the other one which had been
created by the RPM. amcheck was actually configured to look in
/var/lib/amanda - which of course was a default file - doh!!

If I "su amanda" and then "ls" is see the contents of the root desktop
directory and at the command line is see $bash-2.05.

I have not made any changes to the /etc/passwd file.

Hopefully I can resume my backups now - all this is a good learning curve
though.

Thanks again everyone.

Kevin Passey

-----Original Message-----
From: Jon LaBadie [mailto:jon AT jgcomp DOT com]
Sent: 02 June 2003 15:22
To: amanda-users AT amanda DOT org
Subject: Re: DONE - Configuring RH7.2 Amanda out of the box - error
access ing Amanda hosts file.


On Mon, Jun 02, 2003 at 02:52:43PM +0100, Kevin Passey wrote:
> And I am assuming from the errors that I got it will not work because the
> config expects .amandahosts to be in /var/lib/amanda.

My understanding is it must be in ~amanda, i.e. the $HOME directory of
the user named amanda.  In /etc/passwd (does linux still use that?)
what is listed as the home directory of user amanda?  Or, if you
login as amanda, or 'su - amanda', what directory are you in?

> I've also sorted my authority problem on sda*'s - in the xinetd service
> config some documentation I had stated that the group = amanda. Changing
> this to "disk" made it work - are there any experts who would like to let
me
> know if this is correct - it works anyway - my amcheck is now clean.

You ask as if there is a single answer.  The point is that amanda must be
able to read the disk drives.  The drives are owned by root and we don't
want amanda to run as root except for certain jobs.  We don't want the
drives accessible by the world (I hope some of the numerous security
implications of that are obvious) so that leaves group permission access.

In my installation (not linux, just used as an example) the disks are
readable
by members of group "sys".  Amanda's primary group is "backup", but amanda
is
also listed in the /etc/group file as a secondary member of "sys".  That
gives her the read access she needs.

So the objective is to get the disks readable by amanda without introducing
big security holes.  Sounds like you've done that.  Perhaps there is also
a way on Linux to make the amanda user a secondary member of group "disk".

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)