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