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.
