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