Re: New problem, no access to ubuntu clients

2012-04-06 Thread Chris Nighswonger
Hi Gene,

2012/4/6 gene heskett ghesk...@wdtv.com

 On Friday, April 06, 2012 01:13:17 AM Nathan Stratton Treadway did opine:

  On Thu, Apr 05, 2012 at 23:37:51 -0400, Nathan Stratton Treadway wrote:
 $ netstat -a | grep amanda
  
   on those machines...
  
   Does the output from that command on 192.168.71.3 look any different
   from that on your other clients?
 
  p.s. on my Lucid boxes, the Amanda client is invoked from inetd, so if
  netstat doesn't show the ports open then the issue is probably that
  inetd isn't running, or the amanda entry in /etc/inetd.conf has been
  changed.  But I don't know off hand why both your machines would have
  problems with inet at the same time.
 
  (Obviously if you are using xinetd or whatever, check that instead.)
 
 Something must have pulled in xinetd, which removed inetd on the shop box,
 so I'm fixing that back to inetd since the .conf still exists.  Apparently
 no conflict.  Since I know inetd was working until the 3rd, I have
 reinstalled it on both machines.  However amanda is running on this box
 ATM, so I can't check with amcheck until that has finished.  If this
 doesn't do it, I'm back to square one.


Have you tried

$ amservice clienthostname yourauth noop /dev/null

to see if you get an option string back?  (per
http://wiki.zmanda.com/index.php/Selfcheck_request_failed)

I've had similar experiences with clients suddenly disappearing and this
has helped me to troubleshoot.

HTH.

Kind Regards,
Chris


Re: New problem, no access to ubuntu clients

2012-04-06 Thread Jean-Louis Martineau

On 04/06/2012 01:08 AM, gene heskett wrote:

Beside having inet and xinetd file, which one are the machine using?

root@shop:/etc# cat xinetd.d/amanda
# default: on
# description: The amanda service
service amanda
{
#only_from   =coyote.coyote.den
 socket_type = dgram
 protocol= udp
 wait= yes
 user= backup
 group   = backup
 groups  = yes
 server  = /usr/lib/amanda/amandad
 server_args = -auth=bsdtcp amdump amindexd amidxtaped
 disable = no
}
This file is wrong, it listen on udp and expect a tcp connection 
(-auth=bsdtcp)


For bsdtcp, you need:

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
}




Re: New problem, no access to ubuntu clients

2012-04-06 Thread Nathan Stratton Treadway
On Fri, Apr 06, 2012 at 00:53:04 -0400, gene heskett wrote:
 On coyote, the server:
 root@coyote Documents]# netstat -a | grep amanda
 tcp0  0 *:amanda*:* LISTEN
 
 On shop, one of the clients as sudo:
 netstat -a | grep amanda
 udp0  0 *:amanda*:*
 
 And on lathe, also sudo:
 gene@lathe:~$ sudo netstat -a | grep amanda
 udp0  0 *:amanda*:*
 
 No LISTEN on the clients.  xinetd has been restarted several times.

More to the point, shop and lathe have open UDP instead of TCP.  Based on
the inetd.conf line you quoted in your other message, you are using bsdtcp
authentication, so listening on UDP is definitely part of the problem :)

Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko  Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


Re: New problem, no access to ubuntu clients

2012-04-06 Thread Nathan Stratton Treadway
On Fri, Apr 06, 2012 at 01:08:44 -0400, gene heskett wrote:
 On lathe, no inetd.conf exists
  (Obviously if you are using xinetd or whatever, check that instead.)
 But xinetd.d does and contains this amanda file:
 root@lathe:/etc# cat xinetd.d/amanda
 # default: on
 # description: The amanda service
 service amanda
 {
 #   only_from   = Amanda server
 socket_type = dgram
 protocol= udp
 wait= yes
 user= backup
 group   = backup
 groups  = yes
 server  = /usr/lib/amanda/amandad
 server_args = -auth=bsdtcp amdump amindexd amidxtaped
 disable = no
 }
 
 That is a fresh amanda-common and amanda-client install

That's strange.  What does apt-cache policy amanda-common show? 

On my Lucid boxes I have amanda-common 1:2.6.1p1-2 installed, and the
xinetd.d/amanda file that is installed is entirely set up for bsd
authentication (so both protocol=udp and server_args containing
-auth-bsd ).

Anyway, hopefully making the change Jean-Louis mentioned will get you
going on this machine.

Nathan

Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko  Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


Re: New problem, no access to ubuntu clients

2012-04-06 Thread gene heskett
On Friday, April 06, 2012 09:00:32 AM Chris Nighswonger did opine:

 Hi Gene,
 
 2012/4/6 gene heskett ghesk...@wdtv.com
 
  On Friday, April 06, 2012 01:13:17 AM Nathan Stratton Treadway did opine:
   On Thu, Apr 05, 2012 at 23:37:51 -0400, Nathan Stratton Treadway wrote:
  $ netstat -a | grep amanda

on those machines...

Does the output from that command on 192.168.71.3 look any
different from that on your other clients?
   
   p.s. on my Lucid boxes, the Amanda client is invoked from inetd, so
   if netstat doesn't show the ports open then the issue is probably
   that inetd isn't running, or the amanda entry in /etc/inetd.conf
   has been changed.  But I don't know off hand why both your machines
   would have problems with inet at the same time.
   
   (Obviously if you are using xinetd or whatever, check that instead.)
  
  Something must have pulled in xinetd, which removed inetd on the shop
  box, so I'm fixing that back to inetd since the .conf still exists. 
  Apparently no conflict.  Since I know inetd was working until the
  3rd, I have reinstalled it on both machines.  However amanda is
  running on this box ATM, so I can't check with amcheck until that has
  finished.  If this doesn't do it, I'm back to square one.
 
 Have you tried
 
 $ amservice clienthostname yourauth noop /dev/null
 
 to see if you get an option string back?  (per
 http://wiki.zmanda.com/index.php/Selfcheck_request_failed)
 
 I've had similar experiences with clients suddenly disappearing and this
 has helped me to troubleshoot.
 
 HTH.
 
 Kind Regards,
 Chris

This is new to me Chris, but one would assume all 3 machines would be using
the same security format.

To verify:
[root@coyote etc]# amservice coyote bsdtcp noop /dev/null
OPTIONS features=9efefbff1f;

As listed in my xinetd.d/amanda it bsdtcp
But:
[root@coyote etc]# amservice shop bsdtcp noop /dev/null
Request failed: Connection refused
[root@coyote etc]# amservice lathe bsdtcp noop /dev/null
Request failed: Connection refused

From inetd.conf on shop or lathe:
amanda stream tcp nowait backup /usr/lib/amanda/amandad amandad -auth=bsdtcp 
amdump

From the 2 clients, one of which I had to blacklist ipv6 on in order to get
any network connectivity at all, the netstat query returns this on both
failing machines, shop:
tcp6   0  0 [::]:amanda [::]:*  LISTEN

and lathe:
tcp6   0  0 [::]:amanda [::]:*  LISTEN

And 'lathe' does not have an ipv6 address in its ifconfig eth0 listing,
while 'shop' does.  What is this 'tcp6' and how should I either make
this machine compliant, something I'll have to do eventually anyway,
or somehow manage to get it blacklisted on the clients?

This machine does have an ipv6 line, as scope:link in its ifconfig
report.  So does 'shop', but 'lathe' does not.  The elderly netgear switch
these are all connected to, may not pass ipv6 even.

Using shops ipv6 address to ping6 it from here:
[root@coyote etc]# ping6 fe80::3a60:77ff:fe4e:381b
connect: Invalid argument
[root@coyote etc]# ping6 fe80::3a60:77ff:fe4e:381b/64
unknown host

But, can I ping6 me?  No, unknown host again.

I don't seem to be learning very much.

Last nights run, with the latest 4.00alpha, apparently screwed up the pdf
generator, cups refused to print it so I have no printed report, only the
email.  I'll back up a version for tonight's run.

While doing that, I am reminded that I get a few hundred stanza's of this:
libtool: relink: warning: `/usr/lib//libidn.la' seems to be moved
libtool: relink: warning: `/usr/lib//libssh2.la' seems to be moved
libtool: relink: warning: `/usr/lib//libldap.la' seems to be moved
libtool: relink: warning: `/usr/lib//libidn.la' seems to be moved
libtool: relink: warning: `/usr/lib//libssh2.la' seems to be moved
libtool: relink: warning: `/usr/lib//libldap.la' seems to be moved
libtool: relink: warning: `/usr/lib//libidn.la' seems to be moved
libtool: relink: warning: `/usr/lib//libssh2.la' seems to be moved
libtool: relink: warning: `/usr/lib//libldap.la' seems to be moved
libtool: relink: warning: `/usr/lib//libidn.la' seems to be moved
libtool: relink: warning: `/usr/lib//libssh2.la' seems to be moved
libtool: relink: warning: `/usr/lib//libldap.la' seems to be moved
libtool: relink: warning: `/usr/lib//libidn.la' seems to be moved
libtool: relink: warning: `/usr/lib//libssh2.la' seems to be moved
libtool: relink: warning: `/usr/lib//libldap.la' seems to be moved
libtool: relink: warning: `/usr/lib//libidn.la' seems to be moved
libtool: relink: warning: `/usr/lib//libssh2.la' seems to be moved
libtool: relink: warning: `/usr/lib//libldap.la' seems to be moved

during the make install, but it doesn't error out so I assume that
the make install was successful. There's that word assume again...

Thanks Chris.

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

Re: New problem, no access to ubuntu clients

2012-04-06 Thread gene heskett
On Friday, April 06, 2012 09:59:11 AM Jean-Louis Martineau did opine:

 On 04/06/2012 01:08 AM, gene heskett wrote:
 
 Beside having inet and xinetd file, which one are the machine using?
 
  root@shop:/etc# cat xinetd.d/amanda
  # default: on
  # description: The amanda service
  service amanda
  {
  #only_from   =coyote.coyote.den
  
   socket_type = dgram
   protocol= udp
   wait= yes
   user= backup
   group   = backup
   groups  = yes
   server  = /usr/lib/amanda/amandad
   server_args = -auth=bsdtcp amdump amindexd amidxtaped
   disable = no
  
  }
 
 This file is wrong, it listen on udp and expect a tcp connection
 (-auth=bsdtcp)
 
 For bsdtcp, you need:
 
 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
 }
I have removed xinetd from the shop machine, putting inetd back in.

From inetd.conf on both clients:
amanda stream tcp nowait backup /usr/lib/amanda/amandad amandad -auth=bsdtcp 
amdump

Both clients have this in /var/backups/.amandahosts

localhost backup
coyote.coyote.den amanda amdump

And both are still 'connection refused'

Thanks Jean-Louis

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
My web page: http://coyoteden.dyndns-free.com:85/gene
A committee takes root and grows, it flowers, wilts and dies, scattering the
seed from which other committees will bloom.
-- Parkinson



Re: New problem, no access to ubuntu clients

2012-04-06 Thread gene heskett
On Friday, April 06, 2012 10:12:18 AM Nathan Stratton Treadway did opine:

 On Fri, Apr 06, 2012 at 00:53:04 -0400, gene heskett wrote:
  On coyote, the server:
  root@coyote Documents]# netstat -a | grep amanda
  tcp0  0 *:amanda*:* LISTEN
  
  On shop, one of the clients as sudo:
  netstat -a | grep amanda
  udp0  0 *:amanda*:*
  
  And on lathe, also sudo:
  gene@lathe:~$ sudo netstat -a | grep amanda
  udp0  0 *:amanda*:*
  
  No LISTEN on the clients.  xinetd has been restarted several times.
 
 More to the point, shop and lathe have open UDP instead of TCP.  Based
 on the inetd.conf line you quoted in your other message, you are using
 bsdtcp authentication, so listening on UDP is definitely part of the
 problem :)
 
   Nathan
But after this mornings changes, nuking xinetd  reinstalling inetutils-
inetd, both clients return this from the netstat -a query:

tcp6   0  0 [::]:amanda [::]:*  LISTEN

And I have no clue where the tcp6 is coming from!

Thanks Nathan

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
My web page: http://coyoteden.dyndns-free.com:85/gene
Everyone is entitled to my opinion.


Re: New problem, no access to ubuntu clients

2012-04-06 Thread gene heskett
On Friday, April 06, 2012 10:16:39 AM Nathan Stratton Treadway did opine:

 On Fri, Apr 06, 2012 at 01:08:44 -0400, gene heskett wrote:
  On lathe, no inetd.conf exists
  
   (Obviously if you are using xinetd or whatever, check that instead.)
  
  But xinetd.d does and contains this amanda file:
  root@lathe:/etc# cat xinetd.d/amanda
  # default: on
  # description: The amanda service
  service amanda
  {
  #   only_from   = Amanda server
  
  socket_type = dgram
  protocol= udp
  wait= yes
  user= backup
  group   = backup
  groups  = yes
  server  = /usr/lib/amanda/amandad
  server_args = -auth=bsdtcp amdump amindexd amidxtaped
  disable = no
  
  }
  
  That is a fresh amanda-common and amanda-client install
 
 That's strange.  What does apt-cache policy amanda-common show?

root@lathe:~# apt-cache policy amanda-common
amanda-common:
  Installed: 1:2.6.1p1-2
  Candidate: 1:2.6.1p1-2
  Version table:
 *** 1:2.6.1p1-2 0
500 http://us.archive.ubuntu.com/ubuntu/ lucid/universe Packages
100 /var/lib/dpkg/status

On shop:
root@shop:/etc# apt-cache policy amanda-common
amanda-common:
  Installed: 1:2.6.1p1-2
  Candidate: 1:2.6.1p1-2
  Version table:
 *** 1:2.6.1p1-2 0
500 http://us.archive.ubuntu.com/ubuntu/ lucid/universe Packages
100 /var/lib/dpkg/status

Identical...

 On my Lucid boxes I have amanda-common 1:2.6.1p1-2 installed, and the
 xinetd.d/amanda file that is installed is entirely set up for bsd
 authentication (so both protocol=udp and server_args containing
 -auth-bsd ).
 
 Anyway, hopefully making the change Jean-Louis mentioned will get you
 going on this machine.

No such luck.
 
   Nathan
 
  Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic
 region Ray Ontko  Co.  -  Software consulting services  -  
 http://www.ontko.com/ GPG Key:
 http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
 fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Thanks Nathan.

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
My web page: http://coyoteden.dyndns-free.com:85/gene
Just give Alice some pencils and she will stay busy for hours.


Re: New problem, no access to ubuntu clients

2012-04-06 Thread Nathan Stratton Treadway
On Fri, Apr 06, 2012 at 10:15:22 -0400, gene heskett wrote:
 But after this mornings changes, nuking xinetd  reinstalling inetutils-
 inetd, both clients return this from the netstat -a query:

I don't know why inetutils-inetd wouldn't work just as well, but my
Lucid machines have openbsd-inetd as their inetd server, presumably
because that's what is listed first in the amanda package dependencies. 
So unless you are sure that your machines had inetutils-inetd installed
back when they were working, you might try switching to openbsd-inetd
instead, just in case that makes a difference.



On Fri, Apr 06, 2012 at 09:44:08 -0400, gene heskett wrote:
 This machine does have an ipv6 line, as scope:link in its ifconfig
 report.  So does 'shop', but 'lathe' does not.  The elderly netgear switch
 these are all connected to, may not pass ipv6 even. 

 Using shops ipv6 address to ping6 it from here:   

 [root@coyote etc]# ping6 fe80::3a60:77ff:fe4e:381b

[etc...]

(Personally, I wouldn't try to get tcp6 working now, but rather
concentrate on getting back to the prior working tcp4 configuration...)


Nathan

Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko  Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


Re: New problem, no access to ubuntu clients

2012-04-06 Thread gene heskett
On Friday, April 06, 2012 05:44:07 PM Nathan Stratton Treadway did opine:

 On Fri, Apr 06, 2012 at 10:15:22 -0400, gene heskett wrote:
  But after this mornings changes, nuking xinetd  reinstalling
  inetutils-
 
  inetd, both clients return this from the netstat -a query:
 I don't know why inetutils-inetd wouldn't work just as well, but my
 Lucid machines have openbsd-inetd as their inetd server, presumably
 because that's what is listed first in the amanda package dependencies.
 So unless you are sure that your machines had inetutils-inetd installed
 back when they were working, you might try switching to openbsd-inetd
 instead, just in case that makes a difference.
 
I just KNEW there had to be a genius here that had the answer, absolutely 
spot on Nathan!  I wasn't even aware there were 2 versions!

[root@coyote xinetd.d]# su - amanda -c amcheck Daily
Amanda Tape Server Host Check
-
Holding disk /usr/dumps: 415156 MB disk space available, using 414656 MB
Searching for label 'Dailys-4':found in slot 4: volume 'Dailys-4'
Will write to volume 'Dailys-4' in slot 4.
NOTE: skipping tape-writable test
NOTE: host info dir /usr/local/var/amanda/Daily/curinfo/lathe does not 
exist
NOTE: it will be created on the next run.
NOTE: index dir /usr/local/var/amanda/Daily/index/lathe does not exist
NOTE: it will be created on the next run.
Server check took 0.218 seconds

Amanda Backup Client Hosts Check

Client check: 3 hosts checked in 2.550 seconds.  0 problems found.

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


And, guess what? The tcp6 is gone too!!
gene@lathe:~$ netstat -a |grep amanda
tcp0  0 *:amanda*:* LISTEN

And we'll see if this 4.0.0alpha.svn.4624) version prints ok, the next one 
in the series did not last night.
 
 (Personally, I wouldn't try to get tcp6 working now, but rather
 concentrate on getting back to the prior working tcp4 configuration...)
 
Well, I have to do it eventually I imagine, but I'd sure like to start with 
a WORKING system.  ;-)

Every list needs a genius, looks like you get to wear that hat for a while. 
:) Thanks Nathan.
 
   Nathan
 
  Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic
 region Ray Ontko  Co.  -  Software consulting services  -  
 http://www.ontko.com/ GPG Key:
 http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
 fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
My web page: http://coyoteden.dyndns-free.com:85/gene
If you would know the value of money, go try to borrow some.
-- Ben Franklin


Re: New problem, no access to ubuntu clients

2012-04-05 Thread gene heskett
On Thursday, April 05, 2012 10:50:42 PM gene heskett did opine:

[...]
 
Addendum:  No logs are being created on the clients, zip, they end cleanly 
on the 3rd, the last dump that worked.

What would be the nmap invocation that would show if ports amanda needs are 
closed?

This, from amcheck, are almost the only clues I am being given:

WARNING: shop: selfcheck request failed: Connection refused
WARNING: lathe: selfcheck request failed: Connection refused

There is a little more in the amcheck.*.debug file attached from a run of 
amcheck a few minutes ago.

Thanks.

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
My web page: http://coyoteden.dyndns-free.com:85/gene
Immortality -- a fate worse than death.
-- Edgar A. Shoaff
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck: pid 23158 ruid 0 euid 501 
version 4.0.0alpha.svn.4639: start at Thu Apr  5 22:48:11 2012
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck: pid 23158 ruid 0 euid 501 
version 4.0.0alpha.svn.4639: rename at Thu Apr  5 22:48:11 2012
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_getdriver(name=bsdtcp) returns 0xb77183e0
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_handleinit(handle=0x8745d98, driver=0xb77183e0 (BSDTCP))
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_streaminit(stream=0x8746ec0, driver=0xb77183e0 (BSDTCP))
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-server: Spawning 
/usr/local/libexec/amanda/amcheck-device 
/usr/local/libexec/amanda/amcheck-device Daily in pipeline
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_port: Skip 
port 512: owned by exec.
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_port: Skip 
port 513: owned by login.
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_port: Skip 
port 514: owned by shell.
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_port: Skip 
port 515: owned by printer.
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: make_socket opening 
socket with family 2
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_port: Try  
port 516: available - Success
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connected to 
192.168.71.3:10080
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: our side is 
0.0.0.0:516
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: try_socksize: send 
buffer size is 65536
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: try_socksize: receive 
buffer size is 65536
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: tcpm_send_token: data 
is still flowing
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_getdriver(name=bsdtcp) returns 0xb77183e0
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_handleinit(handle=0x87510f0, driver=0xb77183e0 (BSDTCP))
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_streaminit(stream=0x87511c0, driver=0xb77183e0 (BSDTCP))
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: make_socket opening 
socket with family 2
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_port: Try  
port 516: available - Success
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
Connect from 0.0.0.0:516 failed: Connection refused
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
connect to 192.168.71.4:10080 failed: Connection refused
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: stream_client: Could 
not bind to port in range 512-1023.
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_seterror(handle=0x87510f0, driver=0xb77183e0 (BSDTCP) error=Connection 
refused)
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_close(handle=0x87510f0, driver=0xb77183e0 (BSDTCP))
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_stream_close(0x87511c0)
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_getdriver(name=bsdtcp) returns 0xb77183e0
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_handleinit(handle=0x87514e0, driver=0xb77183e0 (BSDTCP))
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: 
security_streaminit(stream=0x87598d8, driver=0xb77183e0 (BSDTCP))
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: make_socket opening 
socket with family 2
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_port: Try  
port 516: available - Success
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
Connect from 0.0.0.0:516 failed: Connection refused
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
connect to 192.168.71.5:10080 failed: Connection refused
Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: stream_client: Could 
not bind to 

Re: New problem, no access to ubuntu clients

2012-04-05 Thread Nathan Stratton Treadway
On Thu, Apr 05, 2012 at 23:01:57 -0400, gene heskett wrote:
 What would be the nmap invocation that would show if ports amanda needs are 
 closed?


 Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_port: Try  
 port 516: available - Success
 Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connected to 
 192.168.71.3:10080
 Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: our side is 
 0.0.0.0:516

 Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_port: Try  
 port 516: available - Success
 Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 Connect from 0.0.0.0:516 failed: Connection refused
 Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 connect to 192.168.71.4:10080 failed: Connection refused
 Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: stream_client: 
 Could not bind to port in range 512-1023.

 Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_port: Try  
 port 516: available - Success
 Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 Connect from 0.0.0.0:516 failed: Connection refused
 Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 connect to 192.168.71.5:10080 failed: Connection refused

 Thu Apr  5 22:48:16 2012: thd-0x86ede00: amcheck-clients: connect_port: Try  
 port 516: available - Success
 Thu Apr  5 22:48:16 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 Connect from 0.0.0.0:516 failed: Connection refused
 Thu Apr  5 22:48:16 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 connect to 192.168.71.4:10080 failed: Connection refused
 Thu Apr  5 22:48:16 2012: thd-0x86ede00: amcheck-clients: stream_client: 
 Could not bind to port in range 512-1023.

 Thu Apr  5 22:48:16 2012: thd-0x86ede00: amcheck-clients: connect_port: Try  
 port 516: available - Success
 Thu Apr  5 22:48:16 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 Connect from 0.0.0.0:516 failed: Connection refused
 Thu Apr  5 22:48:16 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 connect to 192.168.71.5:10080 failed: Connection refused
 Thu Apr  5 22:48:16 2012: thd-0x86ede00: amcheck-clients: stream_client: 
 Could not bind to port in range 512-1023.

 Thu Apr  5 22:48:21 2012: thd-0x86ede00: amcheck-clients: connect_port: Try  
 port 516: available - Success
 Thu Apr  5 22:48:21 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 Connect from 0.0.0.0:516 failed: Connection refused
 Thu Apr  5 22:48:21 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 connect to 192.168.71.4:10080 failed: Connection refused
 Thu Apr  5 22:48:21 2012: thd-0x86ede00: amcheck-clients: stream_client: 
 Could not bind to port in range 512-1023.

 Thu Apr  5 22:48:21 2012: thd-0x86ede00: amcheck-clients: connect_port: Try  
 port 516: available - Success
 Thu Apr  5 22:48:21 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 Connect from 0.0.0.0:516 failed: Connection refused
 Thu Apr  5 22:48:21 2012: thd-0x86ede00: amcheck-clients: connect_portrange: 
 connect to 192.168.71.5:10080 failed: Connection refused
 Thu Apr  5 22:48:21 2012: thd-0x86ede00: amcheck-clients: stream_client: 
 Could not bind to port in range 512-1023.

Assuming you don't have any firewalling going on between these machines,
you can most likely tell which ports Amanda has open on the clients by
just running

  $ netstat -a | grep amanda

on those machines...

Does the output from that command on 192.168.71.3 look any different
from that on your other clients?

(As described in /etc/services, port 10080 is the amanda port for both
UDP and TCP.)

Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko  Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


Re: New problem, no access to ubuntu clients

2012-04-05 Thread Nathan Stratton Treadway
On Thu, Apr 05, 2012 at 23:37:51 -0400, Nathan Stratton Treadway wrote:
   $ netstat -a | grep amanda
 
 on those machines...
 
 Does the output from that command on 192.168.71.3 look any different
 from that on your other clients?

p.s. on my Lucid boxes, the Amanda client is invoked from inetd, so if
netstat doesn't show the ports open then the issue is probably that
inetd isn't running, or the amanda entry in /etc/inetd.conf has been
changed.  But I don't know off hand why both your machines would have
problems with inet at the same time.

(Obviously if you are using xinetd or whatever, check that instead.) 



Nathan

Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko  Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


Re: New problem, no access to ubuntu clients

2012-04-05 Thread gene heskett
On Friday, April 06, 2012 12:37:47 AM Nathan Stratton Treadway did opine:

 On Thu, Apr 05, 2012 at 23:01:57 -0400, gene heskett wrote:
  What would be the nmap invocation that would show if ports amanda
  needs are closed?
  
  
  Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients:
  connect_port: Try  port 516: available - Success Thu Apr  5 22:48:11
  2012: thd-0x86ede00: amcheck-clients: connected to 192.168.71.3:10080
  Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients: our side is
  0.0.0.0:516
  
  Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients:
  connect_port: Try  port 516: available - Success Thu Apr  5 22:48:11
  2012: thd-0x86ede00: amcheck-clients: connect_portrange: Connect from
  0.0.0.0:516 failed: Connection refused Thu Apr  5 22:48:11 2012:
  thd-0x86ede00: amcheck-clients: connect_portrange: connect to
  192.168.71.4:10080 failed: Connection refused Thu Apr  5 22:48:11
  2012: thd-0x86ede00: amcheck-clients: stream_client: Could not bind
  to port in range 512-1023.
  
  Thu Apr  5 22:48:11 2012: thd-0x86ede00: amcheck-clients:
  connect_port: Try  port 516: available - Success Thu Apr  5 22:48:11
  2012: thd-0x86ede00: amcheck-clients: connect_portrange: Connect from
  0.0.0.0:516 failed: Connection refused Thu Apr  5 22:48:11 2012:
  thd-0x86ede00: amcheck-clients: connect_portrange: connect to
  192.168.71.5:10080 failed: Connection refused
  
  Thu Apr  5 22:48:16 2012: thd-0x86ede00: amcheck-clients:
  connect_port: Try  port 516: available - Success Thu Apr  5 22:48:16
  2012: thd-0x86ede00: amcheck-clients: connect_portrange: Connect from
  0.0.0.0:516 failed: Connection refused Thu Apr  5 22:48:16 2012:
  thd-0x86ede00: amcheck-clients: connect_portrange: connect to
  192.168.71.4:10080 failed: Connection refused Thu Apr  5 22:48:16
  2012: thd-0x86ede00: amcheck-clients: stream_client: Could not bind
  to port in range 512-1023.
  
  Thu Apr  5 22:48:16 2012: thd-0x86ede00: amcheck-clients:
  connect_port: Try  port 516: available - Success Thu Apr  5 22:48:16
  2012: thd-0x86ede00: amcheck-clients: connect_portrange: Connect from
  0.0.0.0:516 failed: Connection refused Thu Apr  5 22:48:16 2012:
  thd-0x86ede00: amcheck-clients: connect_portrange: connect to
  192.168.71.5:10080 failed: Connection refused Thu Apr  5 22:48:16
  2012: thd-0x86ede00: amcheck-clients: stream_client: Could not bind
  to port in range 512-1023.
  
  Thu Apr  5 22:48:21 2012: thd-0x86ede00: amcheck-clients:
  connect_port: Try  port 516: available - Success Thu Apr  5 22:48:21
  2012: thd-0x86ede00: amcheck-clients: connect_portrange: Connect from
  0.0.0.0:516 failed: Connection refused Thu Apr  5 22:48:21 2012:
  thd-0x86ede00: amcheck-clients: connect_portrange: connect to
  192.168.71.4:10080 failed: Connection refused Thu Apr  5 22:48:21
  2012: thd-0x86ede00: amcheck-clients: stream_client: Could not bind
  to port in range 512-1023.
  
  Thu Apr  5 22:48:21 2012: thd-0x86ede00: amcheck-clients:
  connect_port: Try  port 516: available - Success Thu Apr  5 22:48:21
  2012: thd-0x86ede00: amcheck-clients: connect_portrange: Connect from
  0.0.0.0:516 failed: Connection refused Thu Apr  5 22:48:21 2012:
  thd-0x86ede00: amcheck-clients: connect_portrange: connect to
  192.168.71.5:10080 failed: Connection refused Thu Apr  5 22:48:21
  2012: thd-0x86ede00: amcheck-clients: stream_client: Could not bind
  to port in range 512-1023.
 
 Assuming you don't have any firewalling going on between these machines,
 you can most likely tell which ports Amanda has open on the clients by
 just running
 
   $ netstat -a | grep amanda
 
 on those machines...
 
 Does the output from that command on 192.168.71.3 look any different
 from that on your other clients?
 
 (As described in /etc/services, port 10080 is the amanda port for both
 UDP and TCP.)
 
   Nathan
 
On coyote, the server:
root@coyote Documents]# netstat -a | grep amanda
tcp0  0 *:amanda*:* LISTEN

On shop, one of the clients as sudo:
netstat -a | grep amanda
udp0  0 *:amanda*:*

And on lathe, also sudo:
gene@lathe:~$ sudo netstat -a | grep amanda
udp0  0 *:amanda*:*

No LISTEN on the clients.  xinetd has been restarted several times.

No firewall that I know of.  The iptables --list outputs
server:
[root@coyote Documents]# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source   destination
fail2ban-SSH  tcp  --  anywhere anywheretcp dpt:ssh

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain fail2ban-SSH (1 references)
target prot opt source   destination
RETURN all  --  anywhere anywhere


client shop:
root@shop:/var/lib/amanda# iptables --list
Chain INPUT (policy 

Re: New problem, no access to ubuntu clients

2012-04-05 Thread gene heskett
On Friday, April 06, 2012 12:56:45 AM Nathan Stratton Treadway did opine:

 On Thu, Apr 05, 2012 at 23:37:51 -0400, Nathan Stratton Treadway wrote:
$ netstat -a | grep amanda
  
  on those machines...
  
  Does the output from that command on 192.168.71.3 look any different
  from that on your other clients?
 
 p.s. on my Lucid boxes, the Amanda client is invoked from inetd, so if
 netstat doesn't show the ports open then the issue is probably that
 inetd isn't running, or the amanda entry in /etc/inetd.conf has been
 changed.  But I don't know off hand why both your machines would have
 problems with inet at the same time.

On shop, the date on /etc/inetd.conf is nearly a year old and the only 
active line in it is:
amanda stream tcp nowait backup /usr/lib/amanda/amandad amandad -auth=bsdtcp 
amdump 

This 'shop' machine also has an /etc/xinetd.d/amanda file that looks like this:
root@shop:/etc# cat xinetd.d/amanda
# default: on
# description: The amanda service
service amanda
{
#only_from   = coyote.coyote.den
socket_type = dgram
protocol= udp
wait= yes
user= backup
group   = backup
groups  = yes
server  = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
disable = no
}
On lathe, no inetd.conf exists
 (Obviously if you are using xinetd or whatever, check that instead.)
But xinetd.d does and contains this amanda file:
root@lathe:/etc# cat xinetd.d/amanda
# default: on
# description: The amanda service
service amanda
{
#   only_from   = Amanda server
socket_type = dgram
protocol= udp
wait= yes
user= backup
group   = backup
groups  = yes
server  = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
disable = no
}

That is a fresh amanda-common and amanda-client install
Stopping xinetd on the shop box changed nothing.

Thanks Nathan.

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
My web page: http://coyoteden.dyndns-free.com:85/gene
Revenge is a meal best served cold.


Re: New problem, no access to ubuntu clients

2012-04-05 Thread gene heskett
On Friday, April 06, 2012 01:13:17 AM Nathan Stratton Treadway did opine:

 On Thu, Apr 05, 2012 at 23:37:51 -0400, Nathan Stratton Treadway wrote:
$ netstat -a | grep amanda
  
  on those machines...
  
  Does the output from that command on 192.168.71.3 look any different
  from that on your other clients?
 
 p.s. on my Lucid boxes, the Amanda client is invoked from inetd, so if
 netstat doesn't show the ports open then the issue is probably that
 inetd isn't running, or the amanda entry in /etc/inetd.conf has been
 changed.  But I don't know off hand why both your machines would have
 problems with inet at the same time.
 
 (Obviously if you are using xinetd or whatever, check that instead.)
 
Something must have pulled in xinetd, which removed inetd on the shop box, 
so I'm fixing that back to inetd since the .conf still exists.  Apparently 
no conflict.  Since I know inetd was working until the 3rd, I have 
reinstalled it on both machines.  However amanda is running on this box 
ATM, so I can't check with amcheck until that has finished.  If this 
doesn't do it, I'm back to square one.

Thanks Nathan.
 
 
   Nathan
 
  Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic
 region Ray Ontko  Co.  -  Software consulting services  -  
 http://www.ontko.com/ GPG Key:
 http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
 fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
My web page: http://coyoteden.dyndns-free.com:85/gene
Q:  What do agnostic, insomniac dyslexics do at night?
A:  Stay awake and wonder if there's a dog.


Re: New problem, no access to ubuntu clients

2012-04-04 Thread gene heskett
On Wednesday, April 04, 2012 04:58:33 PM gene heskett did opine:

 [root@coyote amanda-4.0.0alpha.svn.4624]# su - amanda -c amcheck Daily
 Amanda Tape Server Host Check
 -
 Holding disk /usr/dumps: 415224 MB disk space available, using 414724 MB
 Searching for label 'Dailys-1':found in slot 1: volume 'Dailys-1'
 Will write to volume 'Dailys-1' in slot 1.
 NOTE: skipping tape-writable test
 NOTE: host info dir /usr/local/var/amanda/Daily/curinfo/lathe does not
 exist
 NOTE: it will be created on the next run.
 NOTE: index dir /usr/local/var/amanda/Daily/index/lathe does not exist
 NOTE: it will be created on the next run.
 Server check took 0.222 seconds
 
 Amanda Backup Client Hosts Check
 
 WARNING: shop: selfcheck request failed: Connection refused
 WARNING: lathe: selfcheck request failed: Connection refused
 Client check: 3 hosts checked in 10.010 seconds.  2 problems found.
 
 (brought to you by Amanda 4.0.0alpha.svn.4624)
 
 I used the scheduler patch, and when this failed, I went back to the
 4613 version that ran ok last night, just doing a reinstall of what
 worked last night.  Same error.  This was before I had edited the
 disklist to add the same dirs on the lathe box that I was backing up up
 on the shop box, but now neither is working.
 
 Nothing in the config of the install has been changed on either client,
 and a list of updates that were done to the formerly working 'shop' box
 are: root@shop:/var/cache/apt/archives# ls -l|grep 2012-04
 -rw-r--r-- 1 root root 20547946 2012-04-02 22:23 freecad_0.13-
 git201204030104~lucid1_i386.deb
 -rw-r--r-- 1 root root18280 2012-04-02 22:23 freecad-dev_0.13-
 git201204030104~lucid1_i386.deb
 -rw-r--r-- 1 root root 28938400 2012-04-02 22:23 freecad-doc_0.13-
 git201204030104~lucid1_all.deb
 -rw-r--r-- 1 root root  4572656 2012-04-02 16:29
 linuxcnc_1%3a2.6.0~pre0.2964.gce1994e_i386.deb
 -rw-r--r-- 1 root root  8910238 2012-04-02 16:29 linuxcnc-doc-
 en_1%3a2.6.0~pre0.2964.gce1994e_all.deb
 
 Nothing that should have effected amanda.
 
 Here on this box, the server, that list is:
 
 [gene@coyote archives]$ ls -l|grep 2012|grep Apr
 -rw-r--r-- 1 root root 40173 Apr  2 21:05
 libimobiledevice-1.0.7-1pclos2012.i586.rpm
 -rw-r--r-- 1 root root 37190 Apr  2 21:05
 libimobiledevice1-1.0.7-1pclos2012.i586.rpm
 -rw-r--r-- 1 root root180236 Apr  1 12:22
 plymouth-0.8.3-5pclos2012.i586.rpm
 
 I don't see anything there that ought to effect amanda either.
 
 Call me puzzled.  Its been working for at least 18 months on the shop
 box, and the lathe is the exact same computer including  the bios
 version, and was installed from the exact same ubuntu 10.04 LTS cd the
 shop box was installed from.  Both client amanda versions are what ever
 shipped with 10.04 LTS (lucid)
 
 Ideas?  I'm fresh out this time of the night.

Now its the middle of the afternoon  I still don't have a clue.
Comments anyone?
 
 Thanks.
 
 Cheers, Gene


Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
My web page: http://coyoteden.dyndns-free.com:85/gene
Tip of the Day:
Never fry bacon in the nude.

[Correction: always fry bacon in the nude; you'll learn not to burn 
it]