Worked like a charm. thanks again and I will try not to evolve my config into oblivion. geez
Thanks again, Doug -----Original Message----- From: John R. Jackson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 3:35 PM To: Doug Johnson Cc: Amanda-Users (E-mail) Subject: Re: another amrecover problem. >Ok here is what I have and here are my thoughts on this. (The thoughts may >be important here :/) ... :-) :-) >Instead of inetd.conf I am using xinetd. Same difference, although as I recall there were some bad suggestions (and RPM's) of the Amanda related config files. And make sure you kick it the right way if you make any changes. As I recall, sending it a HUP is not what it wants (something about "refresh", but I don't recall the details). >The user for the services is operator <=== I am thinking mistake here... > I had problems with amanda user >having access to full paths >I am currently running the commands (amdump, amrecover, etc) with root. ... Things should be consistent. It's extremely rare to need to run Amanda as root (the few pieces it needs to run as root are handled in special ways). If you can tolerate it, here's what I would do: * Pick an Amanda user and group. For purposes of the following, I'll use operator/disk. * make distclean ./configure --with-user=operator --with-group=disk ... make make install (as root) * Fix your xinetd config files to run the services as operator/disk and enable the full group list (groups = yes, as I recall). * chown -R operator:disk /tmp/amanda/. * chown -R operator:disk /usr/adm/amanda/DailySet1/. * Ditto for your index area (amgetconf DailySet1 indexdir). * Ditto for any other Amanda areas not covered above. * Copy/create the .amandahosts file in ~operator. Make it owned by operator and mode 0600 or 0400. Make sure ~operator is actually readable by operator. I seem to recall some Linux systems setting it as /root which was then locked down so operator could not get through. * **Always** run **everything** as operator, never root (with the one exception of amrecover). Most of the Amanda commands will complain if you try to run them as other than the user you built them for. * su - operator "amcheck -cl DailySet1" * Fix the problems :-). * Do an amdump. * Take a look at the various files (logdir, indexdir) and make sure they are operator/disk. * Try amrecover (or maybe amadmin, first). >[root@schroeder tmp]# amadmin DailySet1 find schroeder sda6 >Scanning /dumps/amanda... > >date host disk lv tape or file file status >2002-04-09 schroeder sda6 0 DailySet100 1 OK Two things of note here. First is that you ran this as root, so access to the log.YYYYMMDD.NN files would not be a problem. But if you look at those files, I suspect you'll see they are not readable by operator (amindexd), which is part of the problem. Second point is that there is no backup for the 8th, which is what you were trying before. Is that because of the reconfig stuff you're doing, or do you think it should have found something for that day? >[root@schroeder tmp]# amgetconf DailySet1 logdir >/usr/adm/amanda/DailySet1 > >[root@schroeder tmp]# grep -e schroeder |grep sda6 * >... Sorry. What I meant was, cd to the log area (/usr/adm/amanda/DailySet1) and grep the log.YYYYMMDD.NN files for the client/disk. But you would want to do that as operator (like amindexd), not root. >doug John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
