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: [email protected]
> [mailto:[email protected]] On Behalf Of Gene Heskett Sent:
> Friday, July 18, 2014 10:39 AM
> To: [email protected]
> 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
