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.        erics AT telepres DOT com
|  |  /
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