Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 16:16:15 John Hein did opine
And Gene did reply:
> Gene Heskett gheskett-at-wdtv.com |amusersj-ml0| wrote at 15:07 -0400 on 
Jul 18, 2014:
>  > On Friday 18 July 2014 14:22:48 John Hein did opine
>  > 
>  > And Gene did reply:
>  > > Gene Heskett wrote at 12:25 -0400 on Jul 18, 2014:
>  > >  > 14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed
>  > >  > (Address already in use (errno = 98)). service = amanda
>  > > 
>  > > More than one xinetd or inetd running?
>  > > 
>  > > Maybe some basic background is in order.  The basic operation of
>  > > *inetd is pretty simple, and if you understand the basics, you can
>  > > really solve many of the common issues yourself.
>  > > 
>  > > *inetd runs forever "listening" on the sockets you tell it to
>  > > listen on (as configured by the xinetd or inetd config files).
>  > > When requests (any activity) on that socket come in, it tries
>  > > to run the service that is specified in its configuration.
>  > > 
>  > > If something else "owns" that socket, *inetd can't do its job
>  > > (i.e., can't start the service corresponds to that socket).
>  > > 
>  > > If not, then *inetd will spawn off the configured service (amandad
>  > > in amanda's case).
>  > > 
>  > > Technically, you don't need *inetd.  You can kick off amandad to
>  > > run on the client some other way (e.g., daemontools, ssh).  But
>  > > the server expects something to be listening on the client when
>  > > it comes time to do the dump.
>  > > 
>  > > As others have mentioned, you have to configure things for the
>  > > right type of socket - the configuration of the amanda server
>  > > (primarily in amanda.conf / disklist) and client (typically inetd
>  > > config and amanda-client.conf) should match (see amanda-auth(7)
>  > > and
>  > > amanda-client.conf(5)).
>  > > 
>  > > Here's some other good info so you can maybe help yourself and
>  > > understand better how things work:
>  > > 
>  > > http://wiki.zmanda.com/index.php/Quick_start_%28old%29
>  > 
>  > I just discovered that the failing box did NOT have an /etc/amanda-
>  > client.conf, so I copied the one from examples and edited it.  But
>  > the working machine doesn't have one either, so I nuked it. amcheck
>  > didn't care.
> 
> You got that out of my email?
> 
> What about the most important bits:
> 
> two inetd's running?
> and the bind failure?
> 
> And the hint to use the background info to try digging on your own a
> little.  You're doing lots of things and it seems you don't know why -
> just guessing.  That's never a good recipe.
> 
> Your xinetd got a bind failure.  That has nothing to do with amanda.
> Fix that first.

I found it! Call off the Bloodhounds & St. Bernards. :)

I had to reinstall xinetd, then remove the application of the -inet_ipv6 
option the startup script in /etc/init.d was applying to xinetd.

$DIETY damn them all to someplace really hot for trying to make a linux 
version released in 2010 as ipv6 only!  I knew I had fought with this crap 
4 years ago, but my shorter term memory doesn't get refreshed on a short 
enough cycle.  One of the hazards of outliving ALL your enemies.

But I am glad I have, altho that was touch and go about 6 weeks back when 
I found myself just barely aware on the bedroom floor and couldn't draw a 
breath.  Pulmonary embolism, blocked the artery from the right side of my 
heart going into the lungs, came very very close to punching my ticket.  
Blew the right side of my heart up to about 2x normal, but that seems to 
have fixed itself now.  The high priced clot-buster shot worked, so I am 
still here.  Lost some weight too & I feel better right now than I have in 
10 years.  On rat poison for blood thinner of course. ;-)

Thank you ALL for putting up with me when it wasn't even an amanda 
problem, please accept my apologies.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[Debra S Baddorf]

On Jul 18, 2014, at 3:13 PM, Gene Heskett  wrote:

> On Friday 18 July 2014 15:49:47 Debra S Baddorf did opine
> And Gene did reply:
>> ps auxww | grep net
> 
> Except for PID's both machines are identical:
> shop:
> gene@shop:/etc$  ps auxww | grep net
> root13  0.0  0.0  0 0 ?SJul11   0:00 [netns]
> root  1128  0.0  0.0   1984   684 ?Ss   Jul11   0:00 
> /usr/sbin/inetd
> gene 15807  0.0  0.0   3352   888 pts/5S+   16:03   0:00 grep 
> --color=auto net
> 
> lathe:
> gene@lathe:/etc$  ps auxww | grep net
> root13  0.0  0.0  0 0 ?SJul17   0:00 [netns]
> root  4386  0.0  0.0   2132   748 ?S15:45   0:00 
> /usr/sbin/inetutils-inetd
> gene  4427  0.0  0.0   3352   884 pts/1S+   16:03   0:00 grep 
> --color=auto net
> 
> Humm,no they are not! but a bare inetd is not now available from the repos.
> The shop box apparently has (its a 2 year old install) openbsd-inetd
> whereas the lathe has inetdutils-inetd.  Shouldn't they work alike?
> 
> Cheers, Gene Heskett

Ahh!  OK — inetd   not  xinetd.


Heres an AMANDA specific instruction:

Steps
1. Edit /etc/inetd.conf and add this line to the end of the file, if there is 
any old amanda related lines comment them out:
amanda stream tcp nowait  amandabackup /usr/lib/amanda/amandad amandad 
-auth=bsdtcp amdump amindexd amidxtaped
   my comment:   change  “amandabackup”  to your username
 check that the location is right for you
  change to  “auth=bsd”   if that’s what the 
working node has

2. Edit /etc/services and add this line to the end of the file, if there is any 
old amanda related lines comment them out:
amanda 10080/tcp # amanda backup services

3. Restart the inetd demon and check for errors in the system log files


Deb Baddorf
I defer to anybody else who still uses this,  but if no other suggestions, try 
the above!
I used to use it;  and it does look familiar.

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 16:16:15 John Hein wrote:
> Gene Heskett gheskett-at-wdtv.com |amusersj-ml0| wrote at 15:07 -0400 on Jul 
> 18, 2014:
>  > On Friday 18 July 2014 14:22:48 John Hein did opine
>  > 
>  > And Gene did reply:
>  > > Gene Heskett wrote at 12:25 -0400 on Jul 18, 2014:
>  > >  > 14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed
>  > >  > (Address already in use (errno = 98)). service = amanda
>  > > 
>  > > More than one xinetd or inetd running?
>  > > 
>  > > Maybe some basic background is in order.  The basic operation of
>  > > *inetd is pretty simple, and if you understand the basics, you can
>  > > really solve many of the common issues yourself.
>  > > 
>  > > *inetd runs forever "listening" on the sockets you tell it to
>  > > listen on (as configured by the xinetd or inetd config files).
>  > > When requests (any activity) on that socket come in, it tries
>  > > to run the service that is specified in its configuration.
>  > > 
>  > > If something else "owns" that socket, *inetd can't do its job
>  > > (i.e., can't start the service corresponds to that socket).
>  > > 
>  > > If not, then *inetd will spawn off the configured service (amandad
>  > > in amanda's case).
>  > > 
>  > > Technically, you don't need *inetd.  You can kick off amandad to
>  > > run on the client some other way (e.g., daemontools, ssh).  But
>  > > the server expects something to be listening on the client when
>  > > it comes time to do the dump.
>  > > 
>  > > As others have mentioned, you have to configure things for the
>  > > right type of socket - the configuration of the amanda server
>  > > (primarily in amanda.conf / disklist) and client (typically inetd
>  > > config and amanda-client.conf) should match (see amanda-auth(7)
>  > > and
>  > > amanda-client.conf(5)).
>  > > 
>  > > Here's some other good info so you can maybe help yourself and
>  > > understand better how things work:
>  > > 
>  > > http://wiki.zmanda.com/index.php/Quick_start_%28old%29
>  > 
>  > I just discovered that the failing box did NOT have an /etc/amanda-
>  > client.conf, so I copied the one from examples and edited it.  But
>  > the working machine doesn't have one either, so I nuked it. amcheck
>  > didn't care.
> 
> You got that out of my email?
> 
> What about the most important bits:
> 
> two inetd's running?
> and the bind failure?
> 
> And the hint to use the background info to try digging on your own a
> little.  You're doing lots of things and it seems you don't know why -
> just guessing.  That's never a good recipe.
> 
> Your xinetd got a bind failure.  That has nothing to do with amanda.
> Fix that first.

Lets go back to that netstat -na|grep 10080
shop:
tcp0  0 0.0.0.0:10080   0.0.0.0:*   LISTEN
lathe:
tcp6   0  0 :::10080:::*LISTEN

So my guess is that -inet_ipv6 option is killing ipv4 on the lathes machine.

Bingo!!! 
manda Backup Client Hosts Check

ERROR: lathe: [Can't open exclude file /GenesAmandaHelper-0.61/excludes (No 
such file or directory)]
ERROR: lathe: [Can't open exclude file /GenesAmandaHelper-0.61/excludes (No 
such file or directory)]
ERROR: lathe: [Can't open exclude file /GenesAmandaHelper-0.61/excludes (No 
such file or directory)]
ERROR: lathe: [Can't open exclude file /GenesAmandaHelper-0.61/excludes (No 
such file or directory)]
ERROR: lathe: [Can't open exclude file /GenesAmandaHelper-0.61/excludes (No 
such file or directory)]
Client check: 3 hosts checked in 2.107 seconds.  5 problems found.

(brought to you by Amanda 4.0.0alpha.svn.4761)

That subdir, which is part of my own scripting wrapped around amanda,
does not exist on the lathes box. nfs is working so I can fix that
from here with mc.  BRB.  Except I can't, only the /home dirs are nfs
shares, damn.

I'll figure out something.

Thanks, that ipv6 only option in the /etc/init.d/xinetd script was it.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[John Hein]

Gene Heskett gheskett-at-wdtv.com |amusersj-ml0| wrote at 15:07 -0400 on Jul 
18, 2014:
 > On Friday 18 July 2014 14:22:48 John Hein did opine
 > And Gene did reply:
 > > Gene Heskett wrote at 12:25 -0400 on Jul 18, 2014:
 > >  > 14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed (Address
 > >  > already in use (errno = 98)). service = amanda
 > >
 > > More than one xinetd or inetd running?
 > >
 > > Maybe some basic background is in order.  The basic operation of
 > > *inetd is pretty simple, and if you understand the basics, you can
 > > really solve many of the common issues yourself.
 > >
 > > *inetd runs forever "listening" on the sockets you tell it to
 > > listen on (as configured by the xinetd or inetd config files).
 > > When requests (any activity) on that socket come in, it tries
 > > to run the service that is specified in its configuration.
 > >
 > > If something else "owns" that socket, *inetd can't do its job
 > > (i.e., can't start the service corresponds to that socket).
 > >
 > > If not, then *inetd will spawn off the configured service (amandad
 > > in amanda's case).
 > >
 > > Technically, you don't need *inetd.  You can kick off amandad to run
 > > on the client some other way (e.g., daemontools, ssh).  But the server
 > > expects something to be listening on the client when it comes time to
 > > do the dump.
 > >
 > > As others have mentioned, you have to configure things for the right
 > > type of socket - the configuration of the amanda server (primarily
 > > in amanda.conf / disklist) and client (typically inetd config and
 > > amanda-client.conf) should match (see amanda-auth(7) and
 > > amanda-client.conf(5)).
 > >
 > > Here's some other good info so you can maybe help yourself and
 > > understand better how things work:
 > >
 > > http://wiki.zmanda.com/index.php/Quick_start_%28old%29
 >
 > I just discovered that the failing box did NOT have an /etc/amanda-
 > client.conf, so I copied the one from examples and edited it.  But the
 > working machine doesn't have one either, so I nuked it. amcheck didn't
 > care.

You got that out of my email?

What about the most important bits:

two inetd's running?
and the bind failure?

And the hint to use the background info to try digging on your own a
little.  You're doing lots of things and it seems you don't know why -
just guessing.  That's never a good recipe.

Your xinetd got a bind failure.  That has nothing to do with amanda.
Fix that first.

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 15:49:47 Debra S Baddorf did opine
And Gene did reply:
>  ps auxww | grep net

Except for PID's both machines are identical:
shop:
gene@shop:/etc$  ps auxww | grep net
root13  0.0  0.0  0 0 ?SJul11   0:00 [netns]
root  1128  0.0  0.0   1984   684 ?Ss   Jul11   0:00 /usr/sbin/inetd
gene 15807  0.0  0.0   3352   888 pts/5S+   16:03   0:00 grep 
--color=auto net

lathe:
gene@lathe:/etc$  ps auxww | grep net
root13  0.0  0.0  0 0 ?SJul17   0:00 [netns]
root  4386  0.0  0.0   2132   748 ?S15:45   0:00 
/usr/sbin/inetutils-inetd
gene  4427  0.0  0.0   3352   884 pts/1S+   16:03   0:00 grep 
--color=auto net

Humm,no they are not! but a bare inetd is not now available from the repos.
The shop box apparently has (its a 2 year old install) openbsd-inetd
whereas the lathe has inetdutils-inetd.  Shouldn't they work alike?

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 15:38:36 Debra S Baddorf did opine
And Gene did reply:
> On Jul 18, 2014, at 1:53 PM, Joi L. Ellis  
wrote:
> > 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.
> 
> do a  locate(or a find /  -iname “*am*”  )   to find your amanda
> logs.
> 
> Joi  puts his in  /var/log/Amanda   apparently.
> I have mine  in   /tmp/amanda   — which I *think*  is the default,  but
> who knows!
> 
> Some of the logs start with   “amandad.”  some are “amrecover”  (since
> you’ve got THAT working,  you can look where THOSE logs get put). 
> Some start with   “selfcheck”  but those are the ones you aren’t
> reaching yet.
> 
> Deb Baddorf
> Fermilab
None of the return is logfiles, just the executables and docs.  On  both 
machines.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 15:24:00 Debra S Baddorf did opine
And Gene did reply:
> On Jul 18, 2014, at 1:53 PM, Joi L. Ellis  
wrote:
> > 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.  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.  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...
> > 
> > 
> > --
> > Joi Owen
> > System Administrator
> > Pavlov Media, Inc
> 
> I’ve got clients in several flavors.  My server has all of the types of
> xinetd  running,  and can listen to whatever the client is sending. Of
> course,  I have to configure the amanda.conf  and disklist  to request
> of backup of the right type for each client.   Each client can only do
> one kind  (in my experience).
> 
No change in the disklist on the server for quite a few days, I had added 
an entry to grab /lib/firmware 2 or 3 weeks ago, before e2fsck gave the / 
partition on the drive a good mauling until it up and died.  New drive, 
new install.  No backup of /etc for either machine. Once I get it working, 
I'll add that to the disklist for both machines.  Hindsight, 20-10 you 
know.  :)
> 
Humm, good box has inetutils-inetd installed, bad box does not.  
Installing it will remove xinetd. And now I am back to connection refused.

Anybody got a magic 
 
> for example  (only if you are interested any further)
> AMANDA.CONF:
> define dumptype dailyNormal {
> BDglobal
>  # includes auth "bsd"
> }
> 
> define dumptype dailyNormalBSDTCP  {
> BDglobal
> auth “bsdtcp”#overrides the “bsd"
> }
> 
> define dumptype dailyNormalKRB5  {
> BDglobal
> auth “krb5"   #overrides the “bsd”
> }
> 
> DISKLIST:
> 
> /dailyNormal
>  /   dailyNormalBSDTCP
> /dailyNormalKRB5
> 
> 
> /ETC/XINETD.D   :I’m sure the filenames don’t matter, but these
> help me:
> 
> amanda-dgramfile:
> ##note the   auth=bsdon the server_args line
> 
> service amanda
> {
> socket_type = dgram
> protocol= udp
> wait= yes
> user= operator
> group   = root
> server  = /usr/local/libexec/amanda/amandad
> server_args = -auth=bsd amdump amindexd amidxtaped
> disable = no
> groups  = yes
> }
> 
> 
> amanda-krb5   file:
> ##note the   auth=krb5on the server_args line
> 
> service k5amanda
> {
> socket_type = stream
> protocol= tcp
> wait= no
> user= root
> group   = root
> server  = /usr/local/libexec/amanda/amandad
> server_args = -auth=krb5 amdump amindexd amidxtaped
> disable = no
> groups  = yes
> }
> 
> 
> amanda-stream   file:
> ##note the   auth=bsdtcpon the server_args line
> 
> service amanda
> {
> socket_type = stream
> protocol= tcp
> wait= no
> user= operator
> group   = root
> server  = /usr/local/libexec/amanda/amandad
> server_args = -auth=bsdtcp amdump amindexd
> amidxtaped disable = no
> groups  = yes
> }


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please 

Re: amrecover works, normal amanda backup, logging connection refused

[Debra S Baddorf]

On Jul 18, 2014, at 2:13 PM, Gene Heskett  wrote:

> On Friday 18 July 2014 14:51:39 Debra S Baddorf did opine
> And Gene did reply:
>> On Jul 18, 2014, at 11:25 AM, Gene Heskett  wrote:
>>> 14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed (Address
>>> already in use (errno = 98)). service = amanda
>>> 14/7/18@12:09:37: ERROR: 3859 {cnf_start_services} Service amanda
>>> failed to start and is deactivated.
>>> 14/7/18@12:09:37: DEBUG: 3859 {cnf_start_services} mask_max = 0,
>>> services_started = 0
>>> 14/7/18@12:09:37: CRITICAL: 3859 {init_services} no services.
>>> Exiting...
>> 
>> I don’t like this part of your earlier email.
>> Does tail  /var/log/messages  say anything about an error?
>> After I use root and restart xinetd
>> 
>> /sbin/service xinetd restart
>> Stopping xinetd:   [  OK  ]
>> Starting xinetd:   [  OK  ]
>> 
>> 
>> 
>>  my  /var/log/messages file says
>> 
>> Jul 18 13:50:47 adback2 xinetd[32427]: Exiting...
>> Jul 18 13:50:47 adback2 xinetd[32468]: xinetd Version 2.3.14 started
>> with libwrap loadavg labeled-networking options compiled in. Jul 18
>> 13:50:47 adback2 xinetd[32468]: Started working: 8 available services
>> 
>> 
>> Does yours say there are ANY services successfully running?
>> Deb
> 
> Nothing about xinetd in dmesg, or in messages.
> 
> Cheers, Gene Heskett



Hmmm.   Do we have a running  xinet ?

 ps auxww | grep net
root  2758  0.0  0.0   2852   884 ?Ss   Jul11   0:00 xinetd 
-stayalive -pidfile /var/run/xinetd.pid

 /sbin/chkconfig --list  xinetd
xinetd  0:off   1:off   2:off   3:on4:on5:on6:off
 this tells what phases of reboot to start it with.   The  “ps”  will say 
if it is running NOW.

If you find   “inetd”  instead  (or whatever the older name was?)   THEN  we 
can proceed down that path.
Deb Baddorf

Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused

[Debra S Baddorf]

On Jul 18, 2014, at 1:53 PM, Joi L. Ellis  wrote:

> 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.


do a  locate(or a find /  -iname “*am*”  )   to find your amanda logs.

Joi  puts his in  /var/log/Amanda   apparently.
I have mine  in   /tmp/amanda   — which I *think*  is the default,  but who 
knows!

Some of the logs start with   “amandad.”  some are “amrecover”  (since you’ve 
got THAT working,  you can look where THOSE
logs get put).  Some start with   “selfcheck”  but those are the ones you 
aren’t reaching yet.

Deb Baddorf
Fermilab

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 15:06:49 Debra S Baddorf did opine
And Gene did reply:
> On Jul 18, 2014, at 1:35 PM, Gene Heskett  wrote:
> > 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.
> 
> Well, whatever you have as the username   (I use operator and
> group=root) you need to have a user by that name.  It can be  no-login
>but it has to be there.
> 
> Does the client have any  /tmp/amanda log files? Certain such log
> files contain the  configured params at the top.   That would tell you
> what the backup user is supposed to be. grep   for   CLIENT_LOGIN
> 
> Or did I miss you saying that you HAD created an account on the client
> node? Deb

The working machine has a  /tmp/amanda directory, the non-working one does 
not.

Both /tmp's are owned by root, and looks to be 0777 perms, the whole 
string shows drwxrwxrwt on both machines,  This is not a network 
showstopper, I am ssh -Y into both machines, checking diffs. ATM I haven't 
found and fixed any diffs between those two machines that did make a diff.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused

[Debra S Baddorf]

On Jul 18, 2014, at 1:53 PM, Joi L. Ellis  wrote:

> 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.  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.  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...
> 
> 
> --
> Joi Owen
> System Administrator
> Pavlov Media, Inc


I’ve got clients in several flavors.  My server has all of the types of xinetd  
running,  and can listen to whatever the client is sending.
Of course,  I have to configure the amanda.conf  and disklist  to request of 
backup of the right type for each client.   Each client
can only do one kind  (in my experience).



for example  (only if you are interested any further)
AMANDA.CONF:
define dumptype dailyNormal {
BDglobal
 # includes auth "bsd" 
}

define dumptype dailyNormalBSDTCP  {
BDglobal
auth “bsdtcp”#overrides the “bsd"
}

define dumptype dailyNormalKRB5  {
BDglobal
auth “krb5"   #overrides the “bsd”
}

DISKLIST:

/dailyNormal
 /   dailyNormalBSDTCP
/dailyNormalKRB5


/ETC/XINETD.D   :I’m sure the filenames don’t matter, but these help me:

amanda-dgramfile:
##note the   auth=bsdon the server_args line

service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= operator
group   = root
server  = /usr/local/libexec/amanda/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
disable = no
groups  = yes
}


amanda-krb5   file:
##note the   auth=krb5on the server_args line

service k5amanda
{
socket_type = stream
protocol= tcp
wait= no
user= root
group   = root
server  = /usr/local/libexec/amanda/amandad
server_args = -auth=krb5 amdump amindexd amidxtaped
disable = no
groups  = yes
}


amanda-stream   file:
##note the   auth=bsdtcpon the server_args line

service amanda
{
socket_type = stream 
protocol= tcp
wait= no
user= operator
group   = root
server  = /usr/local/libexec/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
disable = no
groups  = yes
}

Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

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  home
> > directory with these contents:
> > 
> > backup-server.full.name 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//.*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= 
> > 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
> > 

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 14:51:39 Debra S Baddorf did opine
And Gene did reply:
> On Jul 18, 2014, at 11:25 AM, Gene Heskett  wrote:
> > 14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed (Address
> > already in use (errno = 98)). service = amanda
> > 14/7/18@12:09:37: ERROR: 3859 {cnf_start_services} Service amanda
> > failed to start and is deactivated.
> > 14/7/18@12:09:37: DEBUG: 3859 {cnf_start_services} mask_max = 0,
> > services_started = 0
> > 14/7/18@12:09:37: CRITICAL: 3859 {init_services} no services.
> > Exiting...
> 
> I don’t like this part of your earlier email.
> Does tail  /var/log/messages  say anything about an error?
> After I use root and restart xinetd
> 
>  /sbin/service xinetd restart
> Stopping xinetd:   [  OK  ]
> Starting xinetd:   [  OK  ]
> 
> 
> 
>   my  /var/log/messages file says
> 
> Jul 18 13:50:47 adback2 xinetd[32427]: Exiting...
> Jul 18 13:50:47 adback2 xinetd[32468]: xinetd Version 2.3.14 started
> with libwrap loadavg labeled-networking options compiled in. Jul 18
> 13:50:47 adback2 xinetd[32468]: Started working: 8 available services
> 
> 
> Does yours say there are ANY services successfully running?
> Deb

Nothing about xinetd in dmesg, or in messages.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 14:27:20 Jon LaBadie did opine
And Gene did reply:
> On Fri, Jul 18, 2014 at 10:26:38AM -0400, Gene Heskett wrote:
> > Greeting Jean-Louis;
> > 
> > Trying to figure out why amanda can't backup this machine, one of the
> > things I noticed in /etc, is that on the shop box, which works, there
> > is not an /etc/xinetd.d but it has an old-xinetd.d with a single
> > stanza amanda file in it.
> > 
> > An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently
> > accessed a few minutes ago by my amcheck from the server.
> > 
> > However, on the new install on the machine that is failing to allow
> > the connection, there is an /etc/xinet.d, with an amanda file in it
> > with an old last access date/time, was not 'touched' when I ran the
> > amcheck.  Its last access date/time is I believe, the date/time of
> > the installation itself.
> 
> The last used time 'may' not be valid.  Some admins mount their
> filesystems with the ?noatime? option.
> 
> Jon

That option is not set in either machines /etc/fstab Jon.

Thanks.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[Debra S Baddorf]

On Jul 18, 2014, at 1:35 PM, Gene Heskett  wrote:

> 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.


Well, whatever you have as the username   (I use operator and group=root)
you need to have a user by that name.  It can be  no-loginbut it has
to be there.

Does the client have any  /tmp/amanda log files? Certain such log files
contain the  configured params at the top.   That would tell you what the
backup user is supposed to be. grep   for   CLIENT_LOGIN

Or did I miss you saying that you HAD created an account on the client node?
Deb

RE: [BULK] Re: amrecover works, normal amanda backup, logging connection refused

[Joi L. Ellis]

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.  
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.  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...


--
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  home 
> directory with these contents:
> 
> backup-server.full.name 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//.*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= 
> 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  --no-taper/# 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

Re: amrecover works, normal amanda backup, logging connection refused

[Debra S Baddorf]

On Jul 18, 2014, at 11:25 AM, Gene Heskett  wrote:

> 14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed (Address 
> already in use (errno = 98)). service = amanda
> 14/7/18@12:09:37: ERROR: 3859 {cnf_start_services} Service amanda failed 
> to start and is deactivated.
> 14/7/18@12:09:37: DEBUG: 3859 {cnf_start_services} mask_max = 0, 
> services_started = 0
> 14/7/18@12:09:37: CRITICAL: 3859 {init_services} no services. Exiting...


I don’t like this part of your earlier email.
Does tail  /var/log/messages  say anything about an error?  
After I use root and restart xinetd  

 /sbin/service xinetd restart 
Stopping xinetd:   [  OK  ]
Starting xinetd:   [  OK  ]



  my  /var/log/messages file says

Jul 18 13:50:47 adback2 xinetd[32427]: Exiting...
Jul 18 13:50:47 adback2 xinetd[32468]: xinetd Version 2.3.14 started with 
libwrap loadavg labeled-networking options compiled in.
Jul 18 13:50:47 adback2 xinetd[32468]: Started working: 8 available services


Does yours say there are ANY services successfully running?
Deb

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

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  home
> directory with these contents:
> 
> backup-server.full.name 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//.*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= 
> 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  --no-taper/# 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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[Jon LaBadie]

On Fri, Jul 18, 2014 at 10:26:38AM -0400, Gene Heskett wrote:
> Greeting Jean-Louis;
> 
> Trying to figure out why amanda can't backup this machine, one of the 
> things I noticed in /etc, is that on the shop box, which works, there is 
> not an /etc/xinetd.d but it has an old-xinetd.d with a single stanza 
> amanda file in it.
> 
> An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently 
> accessed a few minutes ago by my amcheck from the server.
> 
> However, on the new install on the machine that is failing to allow the 
> connection, there is an /etc/xinet.d, with an amanda file in it with an 
> old last access date/time, was not 'touched' when I ran the amcheck.  Its  
> last access date/time is I believe, the date/time of the installation 
> itself.
> 

The last used time 'may' not be valid.  Some admins mount their
filesystems with the ?noatime? option.

Jon
-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (609) 477-8330 (C)

Re: amrecover works, normal amanda backup, logging connection refused

[John Hein]

Gene Heskett wrote at 12:25 -0400 on Jul 18, 2014:
 > 14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed (Address 
 > already in use (errno = 98)). service = amanda

More than one xinetd or inetd running?

Maybe some basic background is in order.  The basic operation of
*inetd is pretty simple, and if you understand the basics, you can
really solve many of the common issues yourself.

*inetd runs forever "listening" on the sockets you tell it to
listen on (as configured by the xinetd or inetd config files).
When requests (any activity) on that socket come in, it tries
to run the service that is specified in its configuration.

If something else "owns" that socket, *inetd can't do its job
(i.e., can't start the service corresponds to that socket).

If not, then *inetd will spawn off the configured service (amandad
in amanda's case).

Technically, you don't need *inetd.  You can kick off amandad to run
on the client some other way (e.g., daemontools, ssh).  But the server
expects something to be listening on the client when it comes time to
do the dump.

As others have mentioned, you have to configure things for the right
type of socket - the configuration of the amanda server (primarily
in amanda.conf / disklist) and client (typically inetd config and
amanda-client.conf) should match (see amanda-auth(7) and
amanda-client.conf(5)).

Here's some other good info so you can maybe help yourself and
understand better how things work:

http://wiki.zmanda.com/index.php/Quick_start_%28old%29

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 12:44:49 Olivier Nicole did opine
And Gene did reply:
> On Fri, Jul 18, 2014 at 11:25 PM, Gene Heskett  
wrote:
> > On Friday 18 July 2014 11:53:57 Jean-Louis Martineau did opine
> > 
> > And Gene did reply:
> >> On 07/18/2014 11:39 AM, Gene Heskett wrote:
> >> > On Friday 18 July 2014 10:50:47 John Hein did opine
> >> > 
> >> > And Gene did reply:
> >> >> Gene Heskett wrote at 10:26 -0400 on Jul 18, 2014:
> >> >>   > Trying to figure out why amanda can't backup this machine,
> >> >>   > one of the things I noticed in /etc, is that on the shop
> >> >>   > box, which works, there is not an /etc/xinetd.d but it has
> >> >>   > an old-xinetd.d with a single stanza amanda file in it.
> >> >>   > 
> >> >>   > An ls -lau shows that file, /etc/old-xinetd.d/amanda was
> >> >>   > apparently accessed a few minutes ago by my amcheck from the
> >> >>   > server.
> >> >>   > 
> >> >>   > However, on the new install on the machine that is failing to
> >> >>   > allow the connection, there is an /etc/xinet.d, with an
> >> >>   > amanda file in it with an old last access date/time, was not
> >> >>   > 'touched' when I ran the amcheck.  Its last access date/time
> >> >>   > is I believe, the date/time of the installation itself.
> >> >>   > 
> >> >>   > That amanda-common is 2.6.1p1 IIRC.
> >> >>   > 
> >> >>   > amcheck says:
> >> >>   > WARNING: lathe: selfcheck request failed: Connection refused
> >> >> 
> >> >> Try running xinetd -d (then amcheck) to see if (or why not)
> >> >> xinetd is running amandad.
> >> > 
> >> > Puzzle, first I had to install it!  Then got a report ending here:
> >> > Service defaults
> >> > 
> >> > Bind = All addresses.
> >> > Only from: All sites
> >> > No access: No blocked sites
> >> > No logging
> >> > 
> >> > Service configuration: amanda
> >> > 
> >> > id = amanda
> >> > flags = IPv4
> >> > socket_type = dgram
> >> > Protocol (name,number) = (udp,17)
> >> > port = 10080
> >> > wait = yes
> >> > user = 34
> >> > group = 34
> >> > Groups = yes
> >> > PER_SOURCE = -1
> >> > Bind = All addresses.
> >> > Server = /usr/lib/amanda/amandad
> >> > Server argv = amandad -auth=bsd amdump amindexd amidxtaped
> >> > Only from: All sites
> >> > No access: No blocked sites
> >> > No logging
> >> > 
> >> > 14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} Started
> >> > service: amanda 14/7/18@11:27:40: DEBUG: 3748
> >> > {cnf_start_services} mask_max = 6, services_started = 1
> >> > 14/7/18@11:27:40: NOTICE: 3748 {main} xinetd Version 2.3.14
> >> > started with libwrap loadavg options compiled in.
> >> > 14/7/18@11:27:40: NOTICE: 3748 {main} Started working: 1 available
> >> > service 14/7/18@11:27:40: DEBUG: 3748 {main_loop} active_services
> >> > = 1
> >> > 
> >> > But running an amcheck on the server didn't get any further output
> >> > than what you see above.  And got the same results, connection
> >> > refused. But I see an auth=bsd, where it should be bsdtcp. Fixed
> >> > that, restarted xinetd, no change in amcheck report, lathe still
> >> > refused connection. the amanda file in xinetd.d wasn't touched. 
> >> > So we are a bit closer, but no biscuit.  Next?
> >> 
> >> If you are using bsdtcp, then you must fix the xinetd file for it.
> >> 
> >> socket_type = stream
> >> protocol= tcp
> >> wait= no
> > 
> > Did that, and change  at the top line to the FQDN of
> > this machine, which now looks like this:
> > 
> > # default: on
> > # description: The amanda service
> > service amanda
> > {
> > #   only_from   = coyote.coyote.den
> > 
> > socket_type = stream
> > protocol= tcp
> > wait= no
> > user= backup
> > group   = backup
> > groups  = yes
> > server  = /usr/lib/amanda/amandad
> > server_args = -auth=bsdtcp amdump amindexd amidxtaped
> > disable = no
> > 
> > }
> > 
> > and restarted xinetd
> > then an xinetd -d returns this:
> > 
> > 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
> > configuration file: /etc/xinetd.d/amanda [file=/etc/xinetd.conf]
> > [line=14] 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading
> > included configuration file: /etc/xinetd.d/chargen
> > [file=/etc/xinetd.d/chargen] [line=16]
> > 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
> > configuration file: /etc/xinetd.d/daytime
> > [file=/etc/xinetd.d/daytime] [line=28]
> > 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
> > configuration file: /etc/xinetd.d/discard
> > [file=/etc/xinetd.d/discard] [line=26]
> > 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
> > configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo]
> > [line=25] 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading
> > included c

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 12:11:24 Debra S Baddorf did opine
And Gene did reply:
> > There is a /var/backups/.amandahosts file, its a link to
> > /etc/amandahosts BUT, in /etc/.amandahosts.  I'll mv it to
> > /etc/amandahosts. Ran amcheck, no change and that file was not
> > accessed.
> 
> The actual file SHOULD have a dot at the beginning of the name.
> .amandahosts
> I guess if the one amanda USES   (perhaps  /var/backups/.amandahosts  
> but I’d bet on the other one)starts with a dot,  then it doesn’t
> much matter what that link points to.
>  But on the whole,  the file IS supposed to start with a dot.
> 
> Deb Baddorf
> Fermilab

I replaced the link with the real file as .amandahosts, but no change in 
the amcheck report.

Connection reset by peer.

And I mv'd /etc/amandahosts as .amandahosts. again no change in the 
amcheck report.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 12:11:24 Debra S Baddorf did opine
And Gene did reply:
> > There is a /var/backups/.amandahosts file, its a link to
> > /etc/amandahosts BUT, in /etc/.amandahosts.  I'll mv it to
> > /etc/amandahosts. Ran amcheck, no change and that file was not
> > accessed.
> 
> The actual file SHOULD have a dot at the beginning of the name.
> .amandahosts
> I guess if the one amanda USES   (perhaps  /var/backups/.amandahosts  
> but I’d bet on the other one)starts with a dot,  then it doesn’t
> much matter what that link points to.
>  But on the whole,  the file IS supposed to start with a dot.
> 
> Deb Baddorf
> Fermilab

I'll replace that link with the real .amandahosts

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 12:10:10 Charles Curley did opine
And Gene did reply:
> On Fri, 18 Jul 2014 22:34:16 +0700
> 
> Olivier Nicole  wrote:
> > > What do I check next?
> 
> Firewall?
> 
> That's bitten me more than once.

No firewalls running on any machine, I have a dd-wrt router between me and 
my local network and the modem.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 11:58:22 Joi L. Ellis did opine
And Gene did reply:
> I've been installing Amanda on our network for the past few months and
> on a number of the machines, I noticed that the machine had an
> /etc/xinetd.d/Amanda file, but the xinetd service wasn't installed,
> openbsd-inetd was, and that one reads /etc/inetd.conf.  Amanda-client
> package installs the config lines for both inetd packages, but
> naturally only one of them will be read by your machine.  Depending
> upon the version of the package you installed, I've seen Amanda-client
> install both, only xinetd, or only openbsd-inetd configs, so your
> machine may be looking at a different inetd config than you expected.
> 
> Also check to see if your machine is running iptables or ufw, and if
> so, do 'lsmod | grep amanda' and verify that the ip_conntrack_amanda
> or nf_conntrack_amanda module is loaded.  If either firewall is active
> it is probably blocking your ports.
> 
> If you have the rules enabled, but the *_conntrack_amanda module isn't
> loaded in the kernel, the amcheck will work but amdump will fail. 
> (I've just worked with another admin here to get Amanda running on a
> new machine of his and this was the problem.)
> 
Here, amcheck AND of course amdump are failing.  I did look at indetd.conf 
and reset it for bsdtcp, made no change.   However I just noted that htop 
is reporting two copies of xinetd running, one as root, one as me, and the 
end of the report line says "inetd_compat -inetd_ipv6".  No clue where 
that inetd_ipv6 comes from.  If its a limitation, thats it.

>From the manpage:
   -inetd_compat
  This  option  causes xinetd to read /etc/inetd.conf in 
addition to the standard xinetd config files.  /etc/inetd.conf is read 
after the standard xinetd
  config files.

   -inetd_ipv6
  This option causes xinetd to bind to IPv6  (AF_INET6)  
addresses  for  inetd  compatibility  lines  (see  previous  option).   
This  only  affects  how
  /etc/inetd.conf is interpreted and thus only has any effect 
if the -inetd_compat option is also used.

Is that something I should remove?  In it in the option line in 
/etc/init.d/xinetd as
init.d/xinetd:XINETD_OPTS="$XINETD_OPTS -inetd_ipv6"

Do do know that by default, this 4 year old install tries to make us use 
ipv6 only. So you have to carve up your own network/interfaces files to 
get a working network.


> --
> 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 10:39 AM
> To: amanda-users@amanda.org
> Subject: [BULK] Re: amrecover works, normal amanda backup, logging
> connection refused
> 
> On Friday 18 July 2014 10:50:47 John Hein did opine And Gene did reply:
> > Gene Heskett wrote at 10:26 -0400 on Jul 18, 2014:
> >  > Trying to figure out why amanda can't backup this machine, one of
> > > 
> > > the things I noticed in /etc, is that on the shop box, which works,
> > > there is not an /etc/xinetd.d but it has an old-xinetd.d with a  >
> > 
> > single stanza amanda file in it.
> > 
> >  > An ls -lau shows that file, /etc/old-xinetd.d/amanda was
> >  > apparently
> > > 
> > > accessed a few minutes ago by my amcheck from the server.
> > > 
> >  > However, on the new install on the machine that is failing to
> >  > allow
> > > 
> > > the connection, there is an /etc/xinet.d, with an amanda file in it
> > > with an old last access date/time, was not 'touched' when I ran the
> > > amcheck.  Its last access date/time is I believe, the date/time of
> > > the installation itself.
> > > 
> >  > That amanda-common is 2.6.1p1 IIRC.
> >  > 
> >  > amcheck says:
> >  > WARNING: lathe: selfcheck request failed: Connection refused
> > 
> > Try running xinetd -d (then amcheck) to see if (or why not) xinetd is
> > running amandad.
> 
> Puzzle, first I had to install it!  Then got a report ending here:
> Service defaults
>   Bind = All addresses.
>   Only from: All sites
>   No access: No blocked sites
>   No logging
> 
> Service configuration: amanda
>   id = amanda
>   flags = IPv4
>   socket_type = dgram
>   Protocol (name,number) = (udp,17)
>   port = 10080
>   wait = yes
>   user = 34
>   group = 34
>   Groups = yes
>   PER_SOURCE = -1
>   Bind = All addresses.
>   Server = /usr/lib/amanda/amandad
>   Server a

Re: amrecover works, normal amanda backup, logging connection refused

[Debra S Baddorf]

> 
> 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
yum install xinetd
yum install  dump(xfsdump is problematic)
yum install mtx
yum install mt-st

yum remove xfsdump

Add a file with the name .amandahosts to the  home directory with
these contents:

backup-server.full.name amdump  amindexd

chmod 600 /home//.*amandahosts  #it insists on this


My   xinetd start file matches yours, as quoted in a recent email.
service amanda
{
socket_type = stream
protocol= tcp
wait= no
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



Test a simple backup (without using up a tape).  On SERVER:
amdump  --no-taper/# or any DLE that’s small

===
Any of this help?
Deb Baddorf
Fermilab

Re: amrecover works, normal amanda backup, logging connection refused

[Olivier Nicole]

On Fri, Jul 18, 2014 at 11:25 PM, Gene Heskett  wrote:
> On Friday 18 July 2014 11:53:57 Jean-Louis Martineau did opine
> And Gene did reply:
>> On 07/18/2014 11:39 AM, Gene Heskett wrote:
>> > On Friday 18 July 2014 10:50:47 John Hein did opine
>> >
>> > And Gene did reply:
>> >> Gene Heskett wrote at 10:26 -0400 on Jul 18, 2014:
>> >>   > Trying to figure out why amanda can't backup this machine, one
>> >>   > of the things I noticed in /etc, is that on the shop box, which
>> >>   > works, there is not an /etc/xinetd.d but it has an old-xinetd.d
>> >>   > with a single stanza amanda file in it.
>> >>   >
>> >>   > An ls -lau shows that file, /etc/old-xinetd.d/amanda was
>> >>   > apparently accessed a few minutes ago by my amcheck from the
>> >>   > server.
>> >>   >
>> >>   > However, on the new install on the machine that is failing to
>> >>   > allow the connection, there is an /etc/xinet.d, with an amanda
>> >>   > file in it with an old last access date/time, was not 'touched'
>> >>   > when I ran the amcheck.  Its last access date/time is I
>> >>   > believe, the date/time of the installation itself.
>> >>   >
>> >>   > That amanda-common is 2.6.1p1 IIRC.
>> >>   >
>> >>   > amcheck says:
>> >>   > WARNING: lathe: selfcheck request failed: Connection refused
>> >>
>> >> Try running xinetd -d (then amcheck) to see if (or why not) xinetd
>> >> is running amandad.
>> >
>> > Puzzle, first I had to install it!  Then got a report ending here:
>> > Service defaults
>> >
>> > Bind = All addresses.
>> > Only from: All sites
>> > No access: No blocked sites
>> > No logging
>> >
>> > Service configuration: amanda
>> >
>> > id = amanda
>> > flags = IPv4
>> > socket_type = dgram
>> > Protocol (name,number) = (udp,17)
>> > port = 10080
>> > wait = yes
>> > user = 34
>> > group = 34
>> > Groups = yes
>> > PER_SOURCE = -1
>> > Bind = All addresses.
>> > Server = /usr/lib/amanda/amandad
>> > Server argv = amandad -auth=bsd amdump amindexd amidxtaped
>> > Only from: All sites
>> > No access: No blocked sites
>> > No logging
>> >
>> > 14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} Started service:
>> > amanda 14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} mask_max =
>> > 6, services_started = 1
>> > 14/7/18@11:27:40: NOTICE: 3748 {main} xinetd Version 2.3.14 started
>> > with libwrap loadavg options compiled in.
>> > 14/7/18@11:27:40: NOTICE: 3748 {main} Started working: 1 available
>> > service 14/7/18@11:27:40: DEBUG: 3748 {main_loop} active_services =
>> > 1
>> >
>> > But running an amcheck on the server didn't get any further output
>> > than what you see above.  And got the same results, connection
>> > refused. But I see an auth=bsd, where it should be bsdtcp. Fixed
>> > that, restarted xinetd, no change in amcheck report, lathe still
>> > refused connection. the amanda file in xinetd.d wasn't touched.  So
>> > we are a bit closer, but no biscuit.  Next?
>>
>> If you are using bsdtcp, then you must fix the xinetd file for it.
>> socket_type = stream
>> protocol= tcp
>> wait= no
>
> Did that, and change  at the top line to the FQDN of this
> machine, which now looks like this:
>
> # default: on
> # description: The amanda service
> service amanda
> {
> #   only_from   = coyote.coyote.den
> socket_type = stream
> protocol= tcp
> wait= no
> user= backup
> group   = backup
> groups  = yes
> server  = /usr/lib/amanda/amandad
> server_args = -auth=bsdtcp amdump amindexd amidxtaped
> disable = no
> }
>
> and restarted xinetd
> then an xinetd -d returns this:
>
> 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
> configuration file: /etc/xinetd.d/amanda [file=/etc/xinetd.conf] [line=14]
> 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
> configuration file: /etc/xinetd.d/chargen [file=/etc/xinetd.d/chargen]
> [line=16]
> 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
> configuration file: /etc/xinetd.d/daytime [file=/etc/xinetd.d/daytime]
> [line=28]
> 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
> configuration file: /etc/xinetd.d/discard [file=/etc/xinetd.d/discard]
> [line=26]
> 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
> configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo] [line=25]
> 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
> configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=26]
> 14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing chargen
> 14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing chargen
> 14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing daytime
> 14/7/18@12:09:37: DEBUG: 3859 {remove_disabl

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 11:54:51 Jean-Louis Martineau did opine
And Gene did reply:
> On 07/18/2014 11:43 AM, Gene Heskett wrote:
> > On Friday 18 July 2014 11:34:16 Olivier Nicole did opine
> > 
> > And Gene did reply:
> >> Gene,
> >> 
> >> On Fri, Jul 18, 2014 at 9:26 PM, Gene Heskett  
wrote:
> >>> Greeting Jean-Louis;
> >>> 
> >>> Trying to figure out why amanda can't backup this machine, one of
> >>> the things I noticed in /etc, is that on the shop box, which
> >>> works, there is not an /etc/xinetd.d but it has an old-xinetd.d
> >>> with a single stanza amanda file in it.
> >>> 
> >>> An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently
> >>> accessed a few minutes ago by my amcheck from the server.
> >>> 
> >>> However, on the new install on the machine that is failing to allow
> >>> the connection, there is an /etc/xinet.d, with an amanda file in it
> >>> with an old last access date/time, was not 'touched' when I ran the
> >>> amcheck.  Its last access date/time is I believe, the date/time of
> >>> the installation itself.
> >>> 
> >>> That amanda-common is 2.6.1p1 IIRC.
> >>> 
> >>> amcheck says:
> >>> WARNING: lathe: selfcheck request failed: Connection refused
> >>> 
> >>> There has been enough configuration done that amrecover on this
> >>> machine works.
> >>> 
> >>> There is a /var/backups/.amandahosts file, its a link to
> >>> /etc/amandahosts BUT, in /etc/.amandahosts.  I'll mv it to
> >>> /etc/amandahosts. Ran amcheck, no change and that file was not
> >>> accessed.
> >>> 
> >>> What do I check next?
> >> 
> >> netstat -na |grep 10080
> >> 
> >> You should see an UDP open on that port, else it means xinetd is not
> >> running/not listening for amanda.
> >> 
> >> Olivier
> > 
> > gene@lathe:/etc/xinetd.d$ netstat -na |grep 10080
> > udp0  0 0.0.0.0:10080   0.0.0.0:*
> > udp0  0 0.0.0.0:10080   0.0.0.0:*
> > 
> > IIRC thats good.
> 
> It's not good, this is for bsd auth, you want to use bsdtcp.

I changed it according to Olivier, and now amcheck says connection reset 
by peer, and errors back out quickly rather than waiting 10 seconds. Oh, 
didn't notice the udp was a duplicate.  What effects that?

After the amanda file change, now the netstat -na |grep 10080:
gene@lathe:/etc/xinetd.d$ netstat -na |grep 10080
tcp0  0 0.0.0.0:10080   0.0.0.0:*   LISTEN 
udp0  0 0.0.0.0:10080   0.0.0.0:*

Which should look better. But it doesn't make amcheck happy:

Amanda Backup Client Hosts Check

WARNING: lathe: selfcheck request failed: recv error: Connection reset by 
peer
Client check: 3 hosts checked in 2.498 seconds.  1 problem found.

Thanks Jean-Louis.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 11:53:57 Jean-Louis Martineau did opine
And Gene did reply:
> On 07/18/2014 11:39 AM, Gene Heskett wrote:
> > On Friday 18 July 2014 10:50:47 John Hein did opine
> > 
> > And Gene did reply:
> >> Gene Heskett wrote at 10:26 -0400 on Jul 18, 2014:
> >>   > Trying to figure out why amanda can't backup this machine, one
> >>   > of the things I noticed in /etc, is that on the shop box, which
> >>   > works, there is not an /etc/xinetd.d but it has an old-xinetd.d
> >>   > with a single stanza amanda file in it.
> >>   > 
> >>   > An ls -lau shows that file, /etc/old-xinetd.d/amanda was
> >>   > apparently accessed a few minutes ago by my amcheck from the
> >>   > server.
> >>   > 
> >>   > However, on the new install on the machine that is failing to
> >>   > allow the connection, there is an /etc/xinet.d, with an amanda
> >>   > file in it with an old last access date/time, was not 'touched'
> >>   > when I ran the amcheck.  Its last access date/time is I
> >>   > believe, the date/time of the installation itself.
> >>   > 
> >>   > That amanda-common is 2.6.1p1 IIRC.
> >>   > 
> >>   > amcheck says:
> >>   > WARNING: lathe: selfcheck request failed: Connection refused
> >> 
> >> Try running xinetd -d (then amcheck) to see if (or why not) xinetd
> >> is running amandad.
> > 
> > Puzzle, first I had to install it!  Then got a report ending here:
> > Service defaults
> > 
> > Bind = All addresses.
> > Only from: All sites
> > No access: No blocked sites
> > No logging
> > 
> > Service configuration: amanda
> > 
> > id = amanda
> > flags = IPv4
> > socket_type = dgram
> > Protocol (name,number) = (udp,17)
> > port = 10080
> > wait = yes
> > user = 34
> > group = 34
> > Groups = yes
> > PER_SOURCE = -1
> > Bind = All addresses.
> > Server = /usr/lib/amanda/amandad
> > Server argv = amandad -auth=bsd amdump amindexd amidxtaped
> > Only from: All sites
> > No access: No blocked sites
> > No logging
> > 
> > 14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} Started service:
> > amanda 14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} mask_max =
> > 6, services_started = 1
> > 14/7/18@11:27:40: NOTICE: 3748 {main} xinetd Version 2.3.14 started
> > with libwrap loadavg options compiled in.
> > 14/7/18@11:27:40: NOTICE: 3748 {main} Started working: 1 available
> > service 14/7/18@11:27:40: DEBUG: 3748 {main_loop} active_services =
> > 1
> > 
> > But running an amcheck on the server didn't get any further output
> > than what you see above.  And got the same results, connection
> > refused. But I see an auth=bsd, where it should be bsdtcp. Fixed
> > that, restarted xinetd, no change in amcheck report, lathe still
> > refused connection. the amanda file in xinetd.d wasn't touched.  So
> > we are a bit closer, but no biscuit.  Next?
> 
> If you are using bsdtcp, then you must fix the xinetd file for it.
> socket_type = stream
> protocol= tcp
> wait= no

Did that, and change  at the top line to the FQDN of this 
machine, which now looks like this:

# default: on
# description: The amanda service
service amanda
{
#   only_from   = coyote.coyote.den
socket_type = stream
protocol= tcp
wait= no
user= backup
group   = backup
groups  = yes
server  = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
disable = no
}

and restarted xinetd
then an xinetd -d returns this:

14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included 
configuration file: /etc/xinetd.d/amanda [file=/etc/xinetd.conf] [line=14]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included 
configuration file: /etc/xinetd.d/chargen [file=/etc/xinetd.d/chargen] 
[line=16]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included 
configuration file: /etc/xinetd.d/daytime [file=/etc/xinetd.d/daytime] 
[line=28]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included 
configuration file: /etc/xinetd.d/discard [file=/etc/xinetd.d/discard] 
[line=26]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included 
configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo] [line=25]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included 
configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=26]
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing chargen
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing chargen
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing daytime
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing daytime
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing discard
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing discard
14/7/18@12:09

Re: amrecover works, normal amanda backup, logging connection refused

[Debra S Baddorf]

> 
> There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts
> BUT, in /etc/.amandahosts.  I'll mv it to /etc/amandahosts. Ran amcheck, 
> no change and that file was not accessed.
> 

The actual file SHOULD have a dot at the beginning of the name.
.amandahosts
I guess if the one amanda USES   (perhaps  /var/backups/.amandahosts   but
I’d bet on the other one)starts with a dot,  then it doesn’t much matter
what that link points to.
 But on the whole,  the file IS supposed to start with a dot.

Deb Baddorf
Fermilab

Re: amrecover works, normal amanda backup, logging connection refused

[Charles Curley]

On Fri, 18 Jul 2014 22:34:16 +0700
Olivier Nicole  wrote:

> > What do I check next?

Firewall?

That's bitten me more than once.

-- 

The right of the people to be secure in their persons, houses, papers,
and effects, against unreasonable searches and seizures, shall not be
violated, and no Warrants shall issue, but upon probable cause,
supported by Oath or affirmation, and particularly describing the
place to be searched, and the persons or things to be seized.
-- U.S. Const. Amendment IV

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB

RE: [BULK] Re: amrecover works, normal amanda backup, logging connection refused

[Joi L. Ellis]

I've been installing Amanda on our network for the past few months and on a 
number of the machines, I noticed that the machine had an /etc/xinetd.d/Amanda 
file, but the xinetd service wasn't installed, openbsd-inetd was, and that one 
reads /etc/inetd.conf.  Amanda-client package installs the config lines for 
both inetd packages, but naturally only one of them will be read by your 
machine.  Depending upon the version of the package you installed, I've seen 
Amanda-client install both, only xinetd, or only openbsd-inetd configs, so your 
machine may be looking at a different inetd config than you expected.

Also check to see if your machine is running iptables or ufw, and if so, do 
'lsmod | grep amanda' and verify that the ip_conntrack_amanda or 
nf_conntrack_amanda module is loaded.  If either firewall is active it is 
probably blocking your ports.

If you have the rules enabled, but the *_conntrack_amanda module isn't loaded 
in the kernel, the amcheck will work but amdump will fail.  (I've just worked 
with another admin here to get Amanda running on a new machine of his and this 
was the problem.)


--
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 10:39 AM
To: amanda-users@amanda.org
Subject: [BULK] Re: amrecover works, normal amanda backup, logging connection 
refused

On Friday 18 July 2014 10:50:47 John Hein did opine And Gene did reply:
> Gene Heskett wrote at 10:26 -0400 on Jul 18, 2014:
>  > Trying to figure out why amanda can't backup this machine, one of  
> > the things I noticed in /etc, is that on the shop box, which works,  
> > there is not an /etc/xinetd.d but it has an old-xinetd.d with a  > 
> single stanza amanda file in it.
>  >
>  > An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently  
> > accessed a few minutes ago by my amcheck from the server.
>  >
>  > However, on the new install on the machine that is failing to allow  
> > the connection, there is an /etc/xinet.d, with an amanda file in it  
> > with an old last access date/time, was not 'touched' when I ran the  
> > amcheck.  Its last access date/time is I believe, the date/time of  
> > the installation itself.
>  >
>  > That amanda-common is 2.6.1p1 IIRC.
>  >
>  > amcheck says:
>  > WARNING: lathe: selfcheck request failed: Connection refused
> 
> Try running xinetd -d (then amcheck) to see if (or why not) xinetd is 
> running amandad.

Puzzle, first I had to install it!  Then got a report ending here:
Service defaults
Bind = All addresses.
Only from: All sites
No access: No blocked sites
No logging

Service configuration: amanda
id = amanda
flags = IPv4
socket_type = dgram
Protocol (name,number) = (udp,17)
port = 10080
wait = yes
user = 34
group = 34
Groups = yes
PER_SOURCE = -1
Bind = All addresses.
Server = /usr/lib/amanda/amandad
Server argv = amandad -auth=bsd amdump amindexd amidxtaped
Only from: All sites
No access: No blocked sites
No logging

14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} Started service: amanda
14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} mask_max = 6, 
services_started = 1
14/7/18@11:27:40: NOTICE: 3748 {main} xinetd Version 2.3.14 started with 
libwrap loadavg options compiled in.
14/7/18@11:27:40: NOTICE: 3748 {main} Started working: 1 available service
14/7/18@11:27:40: DEBUG: 3748 {main_loop} active_services = 1

But running an amcheck on the server didn't get any further output than what 
you see above.  And got the same results, connection refused.
But I see an auth=bsd, where it should be bsdtcp. Fixed that, restarted xinetd, 
no change in amcheck report, lathe still refused connection. the amanda file in 
xinetd.d wasn't touched.  So we are a bit closer, but no biscuit.  Next?

Thank you John.

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

Re: amrecover works, normal amanda backup, logging connection refused

[Jean-Louis Martineau]

On 07/18/2014 11:43 AM, Gene Heskett wrote:

On Friday 18 July 2014 11:34:16 Olivier Nicole did opine
And Gene did reply:

Gene,

On Fri, Jul 18, 2014 at 9:26 PM, Gene Heskett  wrote:

Greeting Jean-Louis;

Trying to figure out why amanda can't backup this machine, one of the
things I noticed in /etc, is that on the shop box, which works, there
is not an /etc/xinetd.d but it has an old-xinetd.d with a single
stanza amanda file in it.

An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently
accessed a few minutes ago by my amcheck from the server.

However, on the new install on the machine that is failing to allow
the connection, there is an /etc/xinet.d, with an amanda file in it
with an old last access date/time, was not 'touched' when I ran the
amcheck.  Its last access date/time is I believe, the date/time of
the installation itself.

That amanda-common is 2.6.1p1 IIRC.

amcheck says:
WARNING: lathe: selfcheck request failed: Connection refused

There has been enough configuration done that amrecover on this
machine works.

There is a /var/backups/.amandahosts file, its a link to
/etc/amandahosts BUT, in /etc/.amandahosts.  I'll mv it to
/etc/amandahosts. Ran amcheck, no change and that file was not
accessed.

What do I check next?

netstat -na |grep 10080

You should see an UDP open on that port, else it means xinetd is not
running/not listening for amanda.

Olivier

gene@lathe:/etc/xinetd.d$ netstat -na |grep 10080
udp0  0 0.0.0.0:10080   0.0.0.0:*
udp0  0 0.0.0.0:10080   0.0.0.0:*

IIRC thats good.


It's not good, this is for bsd auth, you want to use bsdtcp.


Next?

Thanks Olivier.

Cheers, Gene Heskett

Re: amrecover works, normal amanda backup, logging connection refused

[Jean-Louis Martineau]

On 07/18/2014 11:39 AM, Gene Heskett wrote:

On Friday 18 July 2014 10:50:47 John Hein did opine
And Gene did reply:

Gene Heskett wrote at 10:26 -0400 on Jul 18, 2014:
  > Trying to figure out why amanda can't backup this machine, one of
  > the things I noticed in /etc, is that on the shop box, which works,
  > there is not an /etc/xinetd.d but it has an old-xinetd.d with a
  > single stanza amanda file in it.
  >
  > An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently
  > accessed a few minutes ago by my amcheck from the server.
  >
  > However, on the new install on the machine that is failing to allow
  > the connection, there is an /etc/xinet.d, with an amanda file in it
  > with an old last access date/time, was not 'touched' when I ran the
  > amcheck.  Its last access date/time is I believe, the date/time of
  > the installation itself.
  >
  > That amanda-common is 2.6.1p1 IIRC.
  >
  > amcheck says:
  > WARNING: lathe: selfcheck request failed: Connection refused

Try running xinetd -d (then amcheck) to see if (or why not) xinetd is
running amandad.

Puzzle, first I had to install it!  Then got a report ending here:
Service defaults
Bind = All addresses.
Only from: All sites
No access: No blocked sites
No logging

Service configuration: amanda
id = amanda
flags = IPv4
socket_type = dgram
Protocol (name,number) = (udp,17)
port = 10080
wait = yes
user = 34
group = 34
Groups = yes
PER_SOURCE = -1
Bind = All addresses.
Server = /usr/lib/amanda/amandad
Server argv = amandad -auth=bsd amdump amindexd amidxtaped
Only from: All sites
No access: No blocked sites
No logging

14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} Started service: amanda
14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} mask_max = 6,
services_started = 1
14/7/18@11:27:40: NOTICE: 3748 {main} xinetd Version 2.3.14 started with
libwrap loadavg options compiled in.
14/7/18@11:27:40: NOTICE: 3748 {main} Started working: 1 available service
14/7/18@11:27:40: DEBUG: 3748 {main_loop} active_services = 1

But running an amcheck on the server didn't get any further output than
what you see above.  And got the same results, connection refused.
But I see an auth=bsd, where it should be bsdtcp. Fixed that, restarted
xinetd, no change in amcheck report, lathe still refused connection. the
amanda file in xinetd.d wasn't touched.  So we are a bit closer, but no
biscuit.  Next?


If you are using bsdtcp, then you must fix the xinetd file for it.
   socket_type = stream
   protocol= tcp
   wait= no

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 11:34:16 Olivier Nicole did opine
And Gene did reply:
> Gene,
> 
> On Fri, Jul 18, 2014 at 9:26 PM, Gene Heskett  wrote:
> > Greeting Jean-Louis;
> > 
> > Trying to figure out why amanda can't backup this machine, one of the
> > things I noticed in /etc, is that on the shop box, which works, there
> > is not an /etc/xinetd.d but it has an old-xinetd.d with a single
> > stanza amanda file in it.
> > 
> > An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently
> > accessed a few minutes ago by my amcheck from the server.
> > 
> > However, on the new install on the machine that is failing to allow
> > the connection, there is an /etc/xinet.d, with an amanda file in it
> > with an old last access date/time, was not 'touched' when I ran the
> > amcheck.  Its last access date/time is I believe, the date/time of
> > the installation itself.
> > 
> > That amanda-common is 2.6.1p1 IIRC.
> > 
> > amcheck says:
> > WARNING: lathe: selfcheck request failed: Connection refused
> > 
> > There has been enough configuration done that amrecover on this
> > machine works.
> > 
> > There is a /var/backups/.amandahosts file, its a link to
> > /etc/amandahosts BUT, in /etc/.amandahosts.  I'll mv it to
> > /etc/amandahosts. Ran amcheck, no change and that file was not
> > accessed.
> > 
> > What do I check next?
> 
> netstat -na |grep 10080
> 
> You should see an UDP open on that port, else it means xinetd is not
> running/not listening for amanda.
> 
> Olivier

gene@lathe:/etc/xinetd.d$ netstat -na |grep 10080
udp0  0 0.0.0.0:10080   0.0.0.0:*  
udp0  0 0.0.0.0:10080   0.0.0.0:*

IIRC thats good.

Next?

Thanks Olivier.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

On Friday 18 July 2014 10:50:47 John Hein did opine
And Gene did reply:
> Gene Heskett wrote at 10:26 -0400 on Jul 18, 2014:
>  > Trying to figure out why amanda can't backup this machine, one of
>  > the things I noticed in /etc, is that on the shop box, which works,
>  > there is not an /etc/xinetd.d but it has an old-xinetd.d with a
>  > single stanza amanda file in it.
>  > 
>  > An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently
>  > accessed a few minutes ago by my amcheck from the server.
>  > 
>  > However, on the new install on the machine that is failing to allow
>  > the connection, there is an /etc/xinet.d, with an amanda file in it
>  > with an old last access date/time, was not 'touched' when I ran the
>  > amcheck.  Its last access date/time is I believe, the date/time of
>  > the installation itself.
>  > 
>  > That amanda-common is 2.6.1p1 IIRC.
>  > 
>  > amcheck says:
>  > WARNING: lathe: selfcheck request failed: Connection refused
> 
> Try running xinetd -d (then amcheck) to see if (or why not) xinetd is
> running amandad.

Puzzle, first I had to install it!  Then got a report ending here:
Service defaults
Bind = All addresses.
Only from: All sites
No access: No blocked sites
No logging

Service configuration: amanda
id = amanda
flags = IPv4
socket_type = dgram
Protocol (name,number) = (udp,17)
port = 10080
wait = yes
user = 34
group = 34
Groups = yes
PER_SOURCE = -1
Bind = All addresses.
Server = /usr/lib/amanda/amandad
Server argv = amandad -auth=bsd amdump amindexd amidxtaped
Only from: All sites
No access: No blocked sites
No logging

14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} Started service: amanda
14/7/18@11:27:40: DEBUG: 3748 {cnf_start_services} mask_max = 6, 
services_started = 1
14/7/18@11:27:40: NOTICE: 3748 {main} xinetd Version 2.3.14 started with 
libwrap loadavg options compiled in.
14/7/18@11:27:40: NOTICE: 3748 {main} Started working: 1 available service
14/7/18@11:27:40: DEBUG: 3748 {main_loop} active_services = 1

But running an amcheck on the server didn't get any further output than 
what you see above.  And got the same results, connection refused.
But I see an auth=bsd, where it should be bsdtcp. Fixed that, restarted 
xinetd, no change in amcheck report, lathe still refused connection. the 
amanda file in xinetd.d wasn't touched.  So we are a bit closer, but no 
biscuit.  Next?

Thank you John.

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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[Olivier Nicole]

Gene,

On Fri, Jul 18, 2014 at 9:26 PM, Gene Heskett  wrote:
> Greeting Jean-Louis;
>
> Trying to figure out why amanda can't backup this machine, one of the
> things I noticed in /etc, is that on the shop box, which works, there is
> not an /etc/xinetd.d but it has an old-xinetd.d with a single stanza
> amanda file in it.
>
> An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently
> accessed a few minutes ago by my amcheck from the server.
>
> However, on the new install on the machine that is failing to allow the
> connection, there is an /etc/xinet.d, with an amanda file in it with an
> old last access date/time, was not 'touched' when I ran the amcheck.  Its
> last access date/time is I believe, the date/time of the installation
> itself.
>
> That amanda-common is 2.6.1p1 IIRC.
>
> amcheck says:
> WARNING: lathe: selfcheck request failed: Connection refused
>
> There has been enough configuration done that amrecover on this machine
> works.
>
> There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts
> BUT, in /etc/.amandahosts.  I'll mv it to /etc/amandahosts. Ran amcheck,
> no change and that file was not accessed.
>
> What do I check next?

netstat -na |grep 10080

You should see an UDP open on that port, else it means xinetd is not
running/not listening for amanda.

Olivier


>
> Thank you.
>
> 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 
> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: amrecover works, normal amanda backup, logging connection refused

[John Hein]

Gene Heskett wrote at 10:26 -0400 on Jul 18, 2014:
 > Trying to figure out why amanda can't backup this machine, one of the
 > things I noticed in /etc, is that on the shop box, which works, there is
 > not an /etc/xinetd.d but it has an old-xinetd.d with a single stanza
 > amanda file in it.
 >
 > An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently
 > accessed a few minutes ago by my amcheck from the server.
 >
 > However, on the new install on the machine that is failing to allow the
 > connection, there is an /etc/xinet.d, with an amanda file in it with an
 > old last access date/time, was not 'touched' when I ran the amcheck.  Its
 > last access date/time is I believe, the date/time of the installation
 > itself.
 >
 > That amanda-common is 2.6.1p1 IIRC.
 >
 > amcheck says:
 > WARNING: lathe: selfcheck request failed: Connection refused

Try running xinetd -d (then amcheck) to see if (or why not) xinetd is
running amandad.

amrecover works, normal amanda backup, logging connection refused

[Gene Heskett]

Greeting Jean-Louis;

Trying to figure out why amanda can't backup this machine, one of the 
things I noticed in /etc, is that on the shop box, which works, there is 
not an /etc/xinetd.d but it has an old-xinetd.d with a single stanza 
amanda file in it.

An ls -lau shows that file, /etc/old-xinetd.d/amanda was apparently 
accessed a few minutes ago by my amcheck from the server.

However, on the new install on the machine that is failing to allow the 
connection, there is an /etc/xinet.d, with an amanda file in it with an 
old last access date/time, was not 'touched' when I ran the amcheck.  Its  
last access date/time is I believe, the date/time of the installation 
itself.

That amanda-common is 2.6.1p1 IIRC.

amcheck says:
WARNING: lathe: selfcheck request failed: Connection refused

There has been enough configuration done that amrecover on this machine 
works.

There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts
BUT, in /etc/.amandahosts.  I'll mv it to /etc/amandahosts. Ran amcheck, 
no change and that file was not accessed.

What do I check next?  

Thank you.
 
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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS