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.
Using the x bit was better ;-). But I have others problems like the
generated tapelist with owner amanda and group amanda (and restricted
permissions to owner) which complains when running amrecover. The
easiest way for me is to remove all file installed with my debian
packager and reinstall by hand with corrects arguments in my ./configure
My Debian mind tell me to download source package, modify arguments and
then re-package Amanda but...I'm so lazy on Friday.
Thomas