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
--
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.
|
