On Friday 18 July 2014 14:53:23 Joi L. Ellis did opine
And Gene did reply:
> I think you have a more basic network connectivity issue.  If it were a
> simple .amandahosts issue, you'd get an error message to that affect,
> not 'connection reset by peer', which is a network thing.
> 
> Don't forget to check the logs on the server and the client, see
> /var/log/Amanda/*, find the newest files in there and see what they
> say.
> 
> The first thing to do is verify that the server can backup itself as a
> client.

It did last night, along with the shop machine, but not the lathe machine.  
I've been using amanda for about 15 years here

> If your server-side is not working, this will get that
> straightened out.  Then check that the server and the client can
> resolve each other's hostnames, and that they can ping each other
> (firewalls allowing.)  If you can, put the client on the same network
> as the server and disable all iptables/ufw firewalls, and verify it
> works that way.

They are all on the same 192.168.xx.xx subnet. I use hosts files and  can 
ssh -Y lathe into the machine, in fact thats how I am doing all this.

> Then move the client back to its own network and test
> again.  If it breaks on the other network, it has to be a firewall or
> network issue blocking you.
> 
> In my own project here to install Amanda services everywhere, I've
> discovered hosts running undocumented iptables, undocumented
> firewalls, and all sorts of DNS breakages that I've had to clean up as
> I went.
> 
> For what it's worth, I had to drop back to using plain old auth=bsd for
> Amanda, not bsdtcp, as some of the clients are so ancient the
> Amanda-client packages they have don't grok bsdtcp yet, so I'm using
> the lcd to get everyone running on a consistent setup.  Once the
> ancients are retired I can upgrade all of them to something modern,
> but until then...

The other machine just like it, same box etc, has been using bsdtcp for 
several years.

About burned out, but I need this backup to work too.
> 
> 
> --
> Joi Owen
> System Administrator
> Pavlov Media, Inc
> 
> 
> -----Original Message-----
> From: owner-amanda-us...@amanda.org
> [mailto:owner-amanda-us...@amanda.org] On Behalf Of Gene Heskett Sent:
> Friday, July 18, 2014 1:36 PM
> To: amanda-users@amanda.org
> Subject: [BULK] Re: amrecover works, normal amanda backup, logging
> connection refused
> 
> On Friday 18 July 2014 13:24:12 Debra S Baddorf did opine And Gene did 
reply:
> > > What do I check next?
> > > 
> > > Thank you.
> > > 
> > > Cheers, Gene Heskett
> > 
> > Since Olivier wrote that he only used xinetd once,  I figured I'd
> > best chime in. I use it all the time (not that I know very much
> > about it).
> > 
> >  Here are parts of my CHECKLIST for a new node:
> > yum install openssh-server
> 
> Got that already
> 
> > yum install xinetd
> 
> installed about an hour ago
> 
> > yum install  dump    (xfsdump is problematic)
> 
> Not using dump, tar-1.22 instead
> 
> > yum install mtx
> 
> Not using tape
> 
> > yum install mt-st
> 
> Not using tape
> 
> > yum remove xfsdump
> > 
> > Add a file with the name .amandahosts to the <backup-user> home
> > directory with these contents:
> > 
> > backup-server.full.name  <backup-user>   amdump  amindexd
> 
> backup user on the server is amanda, but neither client machine even
> has an amanda (or backup) user.  Presumably its backup:backup on the
> clients. The /var/backups/.amandahosts files were different, so I made
> the failing machine match the working machines version, no change,
> made the one in /etc match, again no change.  Neither file had
> amindexd listed, added that to each, one at a time, no change.
> 
> > chmod 600 /home/<backup-user>/.*amandahosts      #it insists on this
> 
> Yup
> 
> > My   xinetd start file matches yours, as quoted in a recent email.
> > service amanda
> > {
> > 
> >         socket_type             = stream
> >         protocol                = tcp
> >         wait                    = no
> >         user                    = <backup-user>
> >         group                   = root    #whatever you are using
> >         server                  = /usr/local/libexec/amanda/amandad
> >      
> >      #wherever your file actually IS server_args             =
> > 
> > -auth=bsdtcp amdump amindexd amidxtaped disable                 = no
> > 
> >         groups                  = yes
> > 
> > }
> > 
> > /sbin/service xinetd restart         # restart xinetd
> > 
> > 
> > If they don't already exist, add these  in /etc/services amanda
> > 10080/udp # Dump server control amidxtape 10083/tcp # Amanda tape
> > indexing amandaidx 10082/tcp # Amanda recovery program
> > 
> > ON SERVER:   new node:
> >   add to   disklist file
> >   add to /etc/sysconfig/iptables  and restart with
> >   
> >              /sbin/service iptables restart         # if you have
> > 
> > iptables running add to  .amandahosts
> 
> No iptables running.
> 
> > Test a simple backup (without using up a tape).  On SERVER:
> > amdump   <config>   --no-taper  <newclientnode>  /    # or any DLE
> > that's small
> 
> as root: su amanda -c "amdump Daily --no-taper lathe /home"
> 
> returns no error in about 1 full second.
> 
> > =======================
> > Any of this help?
> > Deb Baddorf
> > Fermilab
> 
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Reply via email to