Thanks for the tips Josh. This was actually resolved last week when some lucky members of the list got the post and helped me out. It seems that there are some really big latency problems in the mailing list software -- the original post was more two weeks ago and it only now made the list (or is this the second time on the list)???
-- Jeremy Wadsack Wadsack-Allen Digital Group Josh Burroughs ([EMAIL PROTECTED]): > On Thu, 20 Sep 2001, Jeremy Wadsack wrote: >> I keep getting this error: >> >> ERROR: net-cf9a5410: [access as tape not allowed from >> root@net-cf9a5425] >> >> On 'net-cf9a5410' the ~tape/.amandahosts looks like this: >> >> net-cf9a5425 root > Ahh I think I see your problem right here. If I understand things properly > (and I'm not claiming that I do ;-> ) the user listed in .amandahosts > needs to be the user you are trying to access the client as, ie tape, so > your entry should read as: > net-cf9a5425 tape > See if that works. I think also that the user runing amanda on the backup > server needs to be the same as the user running amandad on the client, so > you may need to setup your server to be run under the tape user as well. >> /etc/inetd.conf contains this: >> >> amanda dgram udp wait tape /usr/local/libexec/amandad amandad > Or if everything is being run as root on the other clients and on the > backup sever you should continue using your original .amandahosts (which > will need to live in root's home dir) and change the inetd.conf line to > read: > amanda dgram udp wait root /usr/local/libexec/amandad amandad > I *think* one of these two suggestions will work, all else being equal. >> The only thing I can think is that perhaps the client (not installed >> by me) was built with a different user than 'tape'. But I can't tell >> anyway of finding out what that was. Do I need to rebuild the client >> on this (and all other client systems) or is there some way I can find >> out what user it's expecting. > I too know the pain of dealing with an amanda setup built by someone else > who never got around to documenting the setup before leaving... I feel your pain ;->> I have had to on two occaisons rebuild the amandad client > for similar reasons, the original client that my predecessor > installed/configured wasn't using .amandahosts properly and rebuilding > from source proved to be a quicker fix. >> (For that matter, if it's expecting some user, why go through all this >> rigamarole. Why not just run as whatever user inetd starts it as?) > While I agree that it can be a pain in the ass sometimes, think about the > need for security in a setup like this. By only permitting one user, from > one host to have access to amandad you reduce the risk of an attacker > being able to "fake out" the amandad client into giving up the whole > filesystem > -Josh
