On Thu, Jul 01, 2004 at 11:13:44AM +0100, Tony van der Hoff wrote: > OK, it turnes out that the entry in .amandahosts now (since the upgrade) > requires the FQDN for tony-lx, i.e. tony-lx.magpieway.net. It now works.
I've just had a similar adventure here. I've already solved it; this post is for the benefit of the archives. Without going into all the details, the solution to my problem seems to be that if your Amanda server has multiple FQDNs, you need to list *all* of them in .amandahosts on the clients, since you have no control over which FQDN Amanda will think it needs to look up on any given run. Whether this is necessary seems to depend on the nameserver software that the Amanda *client* is resolving against (i.e. which nameserver is running on the host(s) listed in the client's /etc/resolv.conf). Our Amanda server has two FQDNs. Our clients have been happily getting backed up for a year, with only one of the server's FQDNs in their .amandahosts files. But when I switched one client over to our test BIND 9.2.3 nameserver (production is BIND 8.2.3), that client started getting "amandahostsauth failed" errors until I added a .amandahosts entry for the server's second FQDN. To confirm this, I ran "amcheck -c" ten times. Two runs succeeded, eight failed (same "amandahostsauth failed" error for the same client). After I made the .amandahosts change on that client, I ran 90 more "amcheck -c"'s; all of them succeeded. It looks as though, when amandad(?) does a reverse lookup on the Amanda server's IP address, the old BIND predictably returns one of the host's FQDN's, but the new BIND can return either of them. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau