Boy, the story gets more interesting all the time ...
>>>> [EMAIL PROTECTED] 12/28/00 02:59PM >>>
>>I've only gotten one email report, but I did get that one, so I believe that t
>>he "mailto" is correct. ...
>
>OK, that's good.
>
>>As to the errors:
>> error result for host isgadmin disk /dev/hda2: isgadmin: [access as amanda not
>allowed from [EMAIL PROTECTED]]
>> These are puzzling, since I have both a /var/lib/amanda/.amandahosts and
>>a /home/amanda/.amandahosts file (the passwd entry for amanda is:
>>amanda:x:37:6:Am anda Admin:/var/lib/amanda:/bin/bash ), both files
>>are identical, both are own ed by amanda:amanda, and both contain
>>"isgback.jhuccp.org amanda.
>
>I assume all the directories down to the file are open enough for the
>Amanda user to read them? For instance, what happens if you run this
>as root:
>
> # su amanda -c "cat /var/lib/amanda/.amandahosts"
> # su amanda -c "cat /home/amanda/.amandahosts"
>
I ran these test on the isgadmin box, one of the targets. isgback is the amanda server.
Both seemed to work fine; both listed the contents of the file.
>>On what I believe is a related note, I also get this error in the log
>>file: FAIL dumper isgback /dev/ad0s1a 0 [[access as amanda not allowed
>>from amanda@i sgback.jhuccp.org] open of /home/amanda/.amandahosts failed
>>I believe that this is related to the fact that /home/amanda/.amandahosts
>>has owner:group of 37:102, neither one of which show up in /etc/passwd
>>or /etc/group ...
>
>Huh? Which machine are you looking at this from that does not have the
>Amanda user listed in /etc/passwd? Are you using NIS for passwd files?
>
On the isgback box (the amanda server):
su-2.03# grep amanda /etc/passwd
amanda:*:1111:0:amanda user:/home/amanda:/usr/local/bin/bash
su-2.03# grep amanda /etc/group
wheel:*:0:root,jmeacham,amanda,dsimmons,kevinz
amanda:*:1001:
On the isgadmin box (one of the backup clients or targets):
root@isgadmin:/home > grep amanda /etc/passwd
amanda:x:37:6:Amanda Admin:/var/lib/amanda:/bin/bash
root@isgadmin:/home > grep amanda /etc/group
amanda:x:102:
What I meant to say is that the userID 37 doesn't show up in the /etc/passwd file of
isgback.
Similarly, the groupID 102 doesn't show up in the /etc/group file of isgback.
su-2.03# grep 37 /etc/passwd
su-2.03# grep 102 /etc/group
su-2.03#
I think the differences in the content of /etc/passwd and /etc/group on the two boxes,
isgadmin and isgback,
shows that either I'm not using NIS for these files, or that it's not working
correctly.
>What happens if you do this as root:
>
> su amanda -c pwd
>
On isgadmin:
root@isgadmin:/home/amanda > su amanda -c pwd
/home/amanda
root@isgadmin:/home/amanda > cd /var/lib/amanda
root@isgadmin:/var/lib/amanda > su amanda -c pwd
/var/lib/amanda
On isgback:
su-2.03# su amanda -c pwd
/home/amanda
>> ... The /home directory is actually an NIS mount from the isgadmin
>> machine, but this doesn't seem to be working well either, since I get
>> an "Operation not permitted" error when I try to chown them. One more
>> thing I've discovered in the three weeks that I've been here that I
>> need to fix.
>
>Did you try to chown them as root or amanda? Does root map to root
>across the NFS mount?
>
I think my first sentence should have been:
... The /home directory is actually an NFS mount from the isgadmin
I thought I tried to chown them as root.
I'm not sure I know what "root mapping to root across the NFS mount" means.
The root directory of isgadmin is different from the root directory of isgback. In
fact,
isgadmin is running SuSE 6.4, while isgback is running FreeBSD 4.0
The information for the root user is also different from isgadmin to isgback. I have
to
telnet into each box separately to work on them.
>>I just learned from my coworker that the tape drive has been running intermitt
>>ently today. Any hope that anything useful is being written to the tape? ...
>
>If it's blinking, it's probably working. I have no idea yet why it's going
>so slow, but it sounds like you have so many other things going wrong we
>should defer that until we get a good baseline. However ...
>
>>It seems to me that your overall advice is to kill amanda and work on getting
>>amcheck to run without error. ...
>
>This would also be a reasonable step since while it may be sort of working
>it's clearly not doing everything right, so maybe it's better to get it
>all straightened out now and start over.
>
>Yes, killing Amanda is simply finding all the "ps -u amanda" processes
>and nailing them, then running amcleanup (which should send you E-mail).
>
>>Anything else I should do to kill it completely, so that I can work
>>with amcheck without any interference?
>
>That should do it.
>
>When you start working with amcheck, use the "-cl" options. That will
>check the client and server without accessing the tape drive and go a
>little faster.
>
>>-Kevin Zembower
Thanks, John, for all your help. I'm tired, I've got tomorrow off, it's New Years ...
I'm going to let the tape keep running, even if it's an exercise in futility, and
follow all your
good suggestions on Tuesday. Have a happy New Year.
-Kevin
>
>John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
E. Kevin Zembower
410-659-6139
