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
