Thanks for the reply Joi. Nothing you suggested seemed to be an issue, but I did just restart xinetd on the client and it's working now! Very strange, because I'd swear I tried that before. But who knows. It's working now which is great. Thanks again.
-M On Wed, Dec 17, 2014 at 6:40 PM, Joi L. Ellis <jlel...@pavlovmedia.com> wrote: > With the NIS change… did that involve changing the hostname or IPs the > server appears to be using as seen from the client? Is your xinetd using > tcpwrappers? Do you need to update /etc/hosts.allow, hosts.deny, and/or > ~amanda/.amandahosts? Is the new Amanda UID reflected properly in > xinetd.conf? Perhaps bouncing xinetd may suffice to solve the issue, if > you haven’t rebooted the whole host since the NIS changes. > > > > Is there an iptables firewall on the client that needs updating? > AppArmor or SELinux updates? > > > > > > *From:* owner-amanda-us...@amanda.org [mailto: > owner-amanda-us...@amanda.org] *On Behalf Of *Michael Stauffer > *Sent:* Wednesday, December 17, 2014 16:31 > *To:* amanda-users@amanda.org > *Subject:* can't connect to client > > > > Amanda 3.3.4 > > CentOS 6.5 (server and client) > > Hi, > > > > I'm having trouble connecting to a client. It used to work. The only thing > I can think of that's changed since the last time it worked is that the NIS > server changed. But that seems to be working fine and the amandabackup user > is available on the client (the server is not using NIS). > > > > Note that the server works with other clients just fine. > > > > amcheck on the client shows this: > > > > WARNING: tesla: selfcheck request failed: recv error: Connection reset by > peer > > > > The amandabackup uid changed with the NIS server change, so I went through > these dirs on the client to make sure files were owned by amandabckup:disk > (except where they should be owned by root): > > > > /usr/sbin > > /etc/amanda > > /usr/libexec/amanda > > /var/lib/amanda > > > > xinetd is running on the client. > > > > 'netstat -a | grep amanada' shows: > > tcp 0 0 *:amanda *:* > LISTEN > > > > Here's the tail of /var/log/amanda/server/jet1/amcheck.<date>.debug from > the server: > > > > ... > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: make_socket > opening socket with family 2 > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: connect_port: > Try port 571: available - Success > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: connected to > 170.212.169.49:10080 > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: our side is > 0.0.0.0:571 > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: try_socksize: > send buffer size is 65536 > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: try_socksize: > receive buffer size is 65536 > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: tcpm_send_token: > data is still flowing > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: > security_stream_seterr(0x1eeb050, recv error: Connection reset by peer) > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: > security_seterror(handle=0x1ee6e50, driver=0x3efe86fce0 (BSDTCP) error=recv > error: Connection reset by peer) > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: > security_close(handle=0x1ee6e50, driver=0x3efe86fce0 (BSDTCP)) > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck-clients: > security_stream_close(0x1eeb050) > > Wed Dec 17 17:27:50 2014: thd-0x1a0e4b0: amcheck: pid 1157 finish time Wed > Dec 17 17:27:50 2014 > > > > Can anyone help me figure this out? Thanks! > > > > -M >
