Gene Heskett a écrit :

On Thursday 27 April 2006 07:56, Thomas Ginestet wrote:
[...]

501 Could not read config file /etc/amanda/DailySet/amanda.conf!


I've checked amindexd logs:

backup:/var/log/amanda# vi amindexd.20060426132954.debug

amindexd: debug 1 pid 12531 ruid 34 euid 34: start at Wed Apr 26
13:23:57 2006

amindexd: version 2.5.0

amindexd: < 220 backup AMANDA index server (2.5.0) ready.

amindexd: > SECURITY USER root

bsd security: remote host backup.gpsa.fr user root local user backup

amindexd: < 200 Access OK

amindexd: > FEATURES fffffeff9ffeffff07

amindexd: < 200 FEATURES fffffeff9ffeffff07

amindexd: > DATE 2006-04-26

amindexd: < 200 Working date set to 2006-04-26.

amindexd: > SCNF DailySet

could not open conf file "/etc/amanda/DailySet/amanda.conf":
Permission denied

amindexd: < 501 Could not read config file
/etc/amanda/DailySet/amanda.conf!



My permissions for /etc/amanda/DailySet/amanda.conf:

backup:/var/log/amanda# ls -al /etc/amanda/DailySet/amanda.conf
-rwxrwx---  1 root amanda 4451 2006-04-25 16:19
/etc/amanda/DailySet/amanda.conf

I don't understand why it complain about that...

You've apparently edited the amanda.conf as root (never do that,
always become amanda to do that) and the perms are now fubar.  It
should look something like this:

-rw-r--r--  1 amanda disk 22049 Apr 16
08:59 /usr/local/etc/amanda/Daily/amanda.conf

The user amanda should be a member of the group disk or backup.
AFAIK, there is no group 'amanda', at least not here.

Is this a new install?

Any help would be appreciate


Thomas

Yes, I've tried to properly reconfigure Amanda but with Debian tools.
I didn't find how to set --with-user=amanda --with-group=backup .....
options, that's why I've changed all permissions by hand.
I'm so lost with permissions....following your advices, this is what
I've set:

backup:~# ls -l /usr/sbin/am* => owner amanda group backup for all
except for amcheck:

-rwSr--r-- 1 root backup 35164 2006-04-03 14:07 /usr/sbin/amcheck

-rwsr-x---  1 root disk 88191 Apr 25 00:09 /usr/local/sbin/amcheck
The s's are all lowercase here, no idea what diff that might indicate.

backup:~# ls -al /usr/local/sbin/am* => owner amanda group backup for
all except for amcheck:

-rwSr--r-- 1 root backup 93903 2006-04-03 10:09
/usr/local/sbin/amcheck

backup:~# ls -l /usr/local/libexec => owner amanda group backup for
all except for:

-rwSr--r-- 1 root backup 86228 2006-04-03 10:09 dumper

-rwSr--r-- 1 root backup 40553 2006-04-03 10:08 killpgrp

-rwSr--r-- 1 root backup 100783 2006-04-03 10:09 planner

-rwSr--r-- 1 root backup 38055 2006-04-03 10:08 rundump

-rwSr--r-- 1 root backup 38062 2006-04-03 10:08 runtar

backup:~# ls -l /usr/lib/amanda => owner amanda group backup for all

backup:~# ls -l /var/log/amanda => owner amanda group backup for all


backup:~# ls -l /etc/amanda => owner amanda group backup for all


backup:~# ls -l /etc/amandahosts => owner amanda group backup for all


backup:~# ls -l /tmp/amanda => owner amanda group backup for all



My dumpuser on amanda.conf is amanda but I can't launch amcheck
anymore: backup:~# su amanda -c "/usr/sbin/amcheck DailySet" bash:
/usr/sbin/amcheck: Permission non accordée (access not allowed for
english guys ;-))
I must have forgotten something else but I don't know what...

see my ls -l on amcheck above, or:

-rwsr-x---  1 root disk 88191 Apr 25 00:09 /usr/local/sbin/amcheck

You are missing the 'x' bit in the perms in your copy.

This is why we generally recommend building from the tarballs, doing the unpack, configure, and make stages in the user amanda's home directory. THEN you become root and do the make install, and all perms are then correctly set automaticly.

So far, very few packagers making packages to match their fav systems have demonstrated a working understanding of the amanda theory of using just enough permissions to do the job.

I've been building the new snapshots as they become available for several years now, and I've boiled it down to a short script that I use after becoming the user amanda, and unpacking the tarball in /home/amanda, and then cp'ing this script I keep a copy of sitting in /home/amanda:

----------------------
#!/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
-------------------------

which is named gh.cf into the freshly unpacked directory, then cd'ing to that directory, and (set the exec bit on that script with a chmod +x gh.cf after you clip it out and save it) and doing a ./gh.cf.

I'm using vtapes, so you'll need to edit this script and set your tapedev type, tape-server name (or addresses will work), and your tar is probably in /usr/bin. ISTR when I as using tapes I had about 3 more option lines in this script, but that was some time back and lost in the sands of my ancient & grey wet ram. Also be sure and trim off anything the save might have left after the \ characters, only a newline is legal there.

Once this script has run to its conclusion, use the package system to remove amanda, or just go thru and nuke all except the 'config' dir as root, then come back to here and do a make install as root. Or I assume that if you have checkinstall properly configured for your packageing system, one could do a checkinstall install. I haven't tried that myself though.

Then your 'su - amanda -c "amcheck Daily"' should work just fine. The su - portion makes sure you have the amanda $PATH, which will be more restricted that roots $PATH and this will uncover whether or not the user amanda's $PATH is correctly set. Thats because the crontab entry that runs it will be in amanda's crontab, it won't run as root.

I can do all this for a new snapshot here in less than 10 minutes, so to me its not that big a deal. Using the script makes sure that each succeeding snapshot is built exactly like the last with none of the gotchas that go with trying to remember all the option lines at configure time. :-)

Thomas

Thanks a lot Gene (and you too Matt ;-) ), your script is such a good idea.

Thomas