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=ffffffff9efefbffffffffff1f; 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." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> Chemistry professors never die, they just fail to react.
