amrecover works, normal amanda backup, logging connection refused
Greeting Jean-Louis; 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 There has been enough configuration done that amrecover on this machine works. There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts BUT, in /etc/.amandahosts. I'll mv it to /etc/amandahosts. Ran amcheck, no change and that file was not accessed. What do I check next? Thank you. 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
Re: amrecover works, normal amanda backup, logging connection refused
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.
Re: amrecover works, normal amanda backup, logging connection refused
Gene, On Fri, Jul 18, 2014 at 9:26 PM, Gene Heskett ghesk...@wdtv.com wrote: Greeting Jean-Louis; 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 There has been enough configuration done that amrecover on this machine works. There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts BUT, in /etc/.amandahosts. I'll mv it to /etc/amandahosts. Ran amcheck, no change and that file was not accessed. What do I check next? netstat -na |grep 10080 You should see an UDP open on that port, else it means xinetd is not running/not listening for amanda. Olivier Thank you. 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
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
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 11:34:16 Olivier Nicole did opine And Gene did reply: Gene, On Fri, Jul 18, 2014 at 9:26 PM, Gene Heskett ghesk...@wdtv.com wrote: Greeting Jean-Louis; 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 There has been enough configuration done that amrecover on this machine works. There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts BUT, in /etc/.amandahosts. I'll mv it to /etc/amandahosts. Ran amcheck, no change and that file was not accessed. What do I check next? netstat -na |grep 10080 You should see an UDP open on that port, else it means xinetd is not running/not listening for amanda. Olivier gene@lathe:/etc/xinetd.d$ netstat -na |grep 10080 udp0 0 0.0.0.0:10080 0.0.0.0:* udp0 0 0.0.0.0:10080 0.0.0.0:* IIRC thats good. Next? Thanks Olivier. 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
Re: amrecover works, normal amanda backup, logging connection refused
On 07/18/2014 11:39 AM, Gene Heskett wrote:
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?
If you are using bsdtcp, then you must fix the xinetd file for it.
socket_type = stream
protocol= tcp
wait= no
Re: amrecover works, normal amanda backup, logging connection refused
On 07/18/2014 11:43 AM, Gene Heskett wrote: On Friday 18 July 2014 11:34:16 Olivier Nicole did opine And Gene did reply: Gene, On Fri, Jul 18, 2014 at 9:26 PM, Gene Heskett ghesk...@wdtv.com wrote: Greeting Jean-Louis; 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 There has been enough configuration done that amrecover on this machine works. There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts BUT, in /etc/.amandahosts. I'll mv it to /etc/amandahosts. Ran amcheck, no change and that file was not accessed. What do I check next? netstat -na |grep 10080 You should see an UDP open on that port, else it means xinetd is not running/not listening for amanda. Olivier gene@lathe:/etc/xinetd.d$ netstat -na |grep 10080 udp0 0 0.0.0.0:10080 0.0.0.0:* udp0 0 0.0.0.0:10080 0.0.0.0:* IIRC thats good. It's not good, this is for bsd auth, you want to use bsdtcp. Next? Thanks Olivier. Cheers, Gene Heskett
RE: [BULK] Re: amrecover works, normal amanda backup, logging connection refused
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
Re: amrecover works, normal amanda backup, logging connection refused
On Fri, 18 Jul 2014 22:34:16 +0700 Olivier Nicole olivier.nic...@cs.ait.ac.th wrote: What do I check next? Firewall? That's bitten me more than once. -- The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized. -- U.S. Const. Amendment IV Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
Re: amrecover works, normal amanda backup, logging connection refused
There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts BUT, in /etc/.amandahosts. I'll mv it to /etc/amandahosts. Ran amcheck, no change and that file was not accessed. The actual file SHOULD have a dot at the beginning of the name. .amandahosts I guess if the one amanda USES (perhaps /var/backups/.amandahosts but I’d bet on the other one)starts with a dot, then it doesn’t much matter what that link points to. But on the whole, the file IS supposed to start with a dot. Deb Baddorf Fermilab
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 11:53:57 Jean-Louis Martineau did opine
And Gene did reply:
On 07/18/2014 11:39 AM, Gene Heskett wrote:
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?
If you are using bsdtcp, then you must fix the xinetd file for it.
socket_type = stream
protocol= tcp
wait= no
Did that, and change amanda-server at the top line to the FQDN of this
machine, which now looks like this:
# default: on
# description: The amanda service
service amanda
{
# only_from = coyote.coyote.den
socket_type = stream
protocol= tcp
wait= no
user= backup
group = backup
groups = yes
server = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
disable = no
}
and restarted xinetd
then an xinetd -d returns this:
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/amanda [file=/etc/xinetd.conf] [line=14]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/chargen [file=/etc/xinetd.d/chargen]
[line=16]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/daytime [file=/etc/xinetd.d/daytime]
[line=28]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/discard [file=/etc/xinetd.d/discard]
[line=26]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo] [line=25]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=26]
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing chargen
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing chargen
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing daytime
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing daytime
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing discard
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing discard
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing echo
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing echo
14/7/18@12:09:37: DEBUG: 3859
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 11:54:51 Jean-Louis Martineau did opine And Gene did reply: On 07/18/2014 11:43 AM, Gene Heskett wrote: On Friday 18 July 2014 11:34:16 Olivier Nicole did opine And Gene did reply: Gene, On Fri, Jul 18, 2014 at 9:26 PM, Gene Heskett ghesk...@wdtv.com wrote: Greeting Jean-Louis; 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 There has been enough configuration done that amrecover on this machine works. There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts BUT, in /etc/.amandahosts. I'll mv it to /etc/amandahosts. Ran amcheck, no change and that file was not accessed. What do I check next? netstat -na |grep 10080 You should see an UDP open on that port, else it means xinetd is not running/not listening for amanda. Olivier gene@lathe:/etc/xinetd.d$ netstat -na |grep 10080 udp0 0 0.0.0.0:10080 0.0.0.0:* udp0 0 0.0.0.0:10080 0.0.0.0:* IIRC thats good. It's not good, this is for bsd auth, you want to use bsdtcp. I changed it according to Olivier, and now amcheck says connection reset by peer, and errors back out quickly rather than waiting 10 seconds. Oh, didn't notice the udp was a duplicate. What effects that? After the amanda file change, now the netstat -na |grep 10080: gene@lathe:/etc/xinetd.d$ netstat -na |grep 10080 tcp0 0 0.0.0.0:10080 0.0.0.0:* LISTEN udp0 0 0.0.0.0:10080 0.0.0.0:* Which should look better. But it doesn't make amcheck happy: Amanda Backup Client Hosts Check WARNING: lathe: selfcheck request failed: recv error: Connection reset by peer Client check: 3 hosts checked in 2.498 seconds. 1 problem found. Thanks Jean-Louis. 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
Re: amrecover works, normal amanda backup, logging connection refused
On Fri, Jul 18, 2014 at 11:25 PM, Gene Heskett ghesk...@wdtv.com wrote:
On Friday 18 July 2014 11:53:57 Jean-Louis Martineau did opine
And Gene did reply:
On 07/18/2014 11:39 AM, Gene Heskett wrote:
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?
If you are using bsdtcp, then you must fix the xinetd file for it.
socket_type = stream
protocol= tcp
wait= no
Did that, and change amanda-server at the top line to the FQDN of this
machine, which now looks like this:
# default: on
# description: The amanda service
service amanda
{
# only_from = coyote.coyote.den
socket_type = stream
protocol= tcp
wait= no
user= backup
group = backup
groups = yes
server = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
disable = no
}
and restarted xinetd
then an xinetd -d returns this:
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/amanda [file=/etc/xinetd.conf] [line=14]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/chargen [file=/etc/xinetd.d/chargen]
[line=16]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/daytime [file=/etc/xinetd.d/daytime]
[line=28]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/discard [file=/etc/xinetd.d/discard]
[line=26]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo] [line=25]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=26]
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing chargen
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing chargen
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing daytime
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing daytime
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing discard
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing discard
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing echo
14/7/18@12:09:37:
Re: amrecover works, normal amanda backup, logging connection refused
What do I check next?
Thank you.
Cheers, Gene Heskett
Since Olivier wrote that he only used xinetd once, I figured I’d best chime in.
I use it all the time (not that I know very much about it). Here are parts of
my CHECKLIST
for a new node:
yum install openssh-server
yum install xinetd
yum install dump(xfsdump is problematic)
yum install mtx
yum install mt-st
yum remove xfsdump
Add a file with the name .amandahosts to the backup-user home directory with
these contents:
backup-server.full.name backup-user amdump amindexd
chmod 600 /home/backup-user/.*amandahosts #it insists on this
My xinetd start file matches yours, as quoted in a recent email.
service amanda
{
socket_type = stream
protocol= tcp
wait= no
user= backup-user
group = root#whatever you are using
server = /usr/local/libexec/amanda/amandad
#wherever your file actually IS
server_args = -auth=bsdtcp amdump amindexd amidxtaped
disable = no
groups = yes
}
/sbin/service xinetd restart # restart xinetd
If they don't already exist, add these in /etc/services
amanda 10080/udp # Dump server control
amidxtape 10083/tcp # Amanda tape indexing
amandaidx 10082/tcp # Amanda recovery program
ON SERVER: new node:
add to disklist file
add to /etc/sysconfig/iptables and restart with
/sbin/service iptables restart # if you have iptables
running
add to .amandahosts
Test a simple backup (without using up a tape). On SERVER:
amdump config --no-taper newclientnode /# or any DLE that’s small
===
Any of this help?
Deb Baddorf
Fermilab
Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused
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
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 12:10:10 Charles Curley did opine And Gene did reply: On Fri, 18 Jul 2014 22:34:16 +0700 Olivier Nicole olivier.nic...@cs.ait.ac.th wrote: What do I check next? Firewall? That's bitten me more than once. No firewalls running on any machine, I have a dd-wrt router between me and my local network and the modem. 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
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 12:11:24 Debra S Baddorf did opine And Gene did reply: There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts BUT, in /etc/.amandahosts. I'll mv it to /etc/amandahosts. Ran amcheck, no change and that file was not accessed. The actual file SHOULD have a dot at the beginning of the name. .amandahosts I guess if the one amanda USES (perhaps /var/backups/.amandahosts but I’d bet on the other one)starts with a dot, then it doesn’t much matter what that link points to. But on the whole, the file IS supposed to start with a dot. Deb Baddorf Fermilab I'll replace that link with the real .amandahosts 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
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 12:11:24 Debra S Baddorf did opine And Gene did reply: There is a /var/backups/.amandahosts file, its a link to /etc/amandahosts BUT, in /etc/.amandahosts. I'll mv it to /etc/amandahosts. Ran amcheck, no change and that file was not accessed. The actual file SHOULD have a dot at the beginning of the name. .amandahosts I guess if the one amanda USES (perhaps /var/backups/.amandahosts but I’d bet on the other one)starts with a dot, then it doesn’t much matter what that link points to. But on the whole, the file IS supposed to start with a dot. Deb Baddorf Fermilab I replaced the link with the real file as .amandahosts, but no change in the amcheck report. Connection reset by peer. And I mv'd /etc/amandahosts as .amandahosts. again no change in the amcheck report. 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
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 12:44:49 Olivier Nicole did opine
And Gene did reply:
On Fri, Jul 18, 2014 at 11:25 PM, Gene Heskett ghesk...@wdtv.com
wrote:
On Friday 18 July 2014 11:53:57 Jean-Louis Martineau did opine
And Gene did reply:
On 07/18/2014 11:39 AM, Gene Heskett wrote:
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?
If you are using bsdtcp, then you must fix the xinetd file for it.
socket_type = stream
protocol= tcp
wait= no
Did that, and change amanda-server at the top line to the FQDN of
this machine, which now looks like this:
# default: on
# description: The amanda service
service amanda
{
# only_from = coyote.coyote.den
socket_type = stream
protocol= tcp
wait= no
user= backup
group = backup
groups = yes
server = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
disable = no
}
and restarted xinetd
then an xinetd -d returns this:
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/amanda [file=/etc/xinetd.conf]
[line=14] 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading
included configuration file: /etc/xinetd.d/chargen
[file=/etc/xinetd.d/chargen] [line=16]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/daytime
[file=/etc/xinetd.d/daytime] [line=28]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/discard
[file=/etc/xinetd.d/discard] [line=26]
14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading included
configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo]
[line=25] 14/7/18@12:09:37: DEBUG: 3859 {handle_includedir} Reading
included configuration file: /etc/xinetd.d/time
[file=/etc/xinetd.d/time] [line=26] 14/7/18@12:09:37: DEBUG: 3859
{remove_disabled_services} removing chargen 14/7/18@12:09:37: DEBUG:
3859 {remove_disabled_services} removing chargen 14/7/18@12:09:37:
DEBUG: 3859 {remove_disabled_services} removing daytime
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing
daytime
Re: amrecover works, normal amanda backup, logging connection refused
Gene Heskett wrote at 12:25 -0400 on Jul 18, 2014:
14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed (Address
already in use (errno = 98)). service = amanda
More than one xinetd or inetd running?
Maybe some basic background is in order. The basic operation of
*inetd is pretty simple, and if you understand the basics, you can
really solve many of the common issues yourself.
*inetd runs forever listening on the sockets you tell it to
listen on (as configured by the xinetd or inetd config files).
When requests (any activity) on that socket come in, it tries
to run the service that is specified in its configuration.
If something else owns that socket, *inetd can't do its job
(i.e., can't start the service corresponds to that socket).
If not, then *inetd will spawn off the configured service (amandad
in amanda's case).
Technically, you don't need *inetd. You can kick off amandad to run
on the client some other way (e.g., daemontools, ssh). But the server
expects something to be listening on the client when it comes time to
do the dump.
As others have mentioned, you have to configure things for the right
type of socket - the configuration of the amanda server (primarily
in amanda.conf / disklist) and client (typically inetd config and
amanda-client.conf) should match (see amanda-auth(7) and
amanda-client.conf(5)).
Here's some other good info so you can maybe help yourself and
understand better how things work:
http://wiki.zmanda.com/index.php/Quick_start_%28old%29
Re: amrecover works, normal amanda backup, logging connection refused
On Fri, Jul 18, 2014 at 10:26:38AM -0400, Gene Heskett wrote: Greeting Jean-Louis; 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. The last used time 'may' not be valid. Some admins mount their filesystems with the ?noatime? option. Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (609) 477-8330 (C)
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 13:24:12 Debra S Baddorf did opine
And Gene did reply:
What do I check next?
Thank you.
Cheers, Gene Heskett
Since Olivier wrote that he only used xinetd once, I figured I’d best
chime in. I use it all the time (not that I know very much about it).
Here are parts of my CHECKLIST for a new node:
yum install openssh-server
Got that already
yum install xinetd
installed about an hour ago
yum install dump(xfsdump is problematic)
Not using dump, tar-1.22 instead
yum install mtx
Not using tape
yum install mt-st
Not using tape
yum remove xfsdump
Add a file with the name .amandahosts to the backup-user home
directory with these contents:
backup-server.full.name backup-user amdump amindexd
backup user on the server is amanda, but neither client machine even has
an amanda (or backup) user. Presumably its backup:backup on the clients.
The /var/backups/.amandahosts files were different, so I made the failing
machine match the working machines version, no change, made the one in
/etc match, again no change. Neither file had amindexd listed, added that
to each, one at a time, no change.
chmod 600 /home/backup-user/.*amandahosts #it insists on this
Yup
My xinetd start file matches yours, as quoted in a recent email.
service amanda
{
socket_type = stream
protocol= tcp
wait= no
user= backup-user
group = root#whatever you are using
server = /usr/local/libexec/amanda/amandad
#wherever your file actually IS server_args =
-auth=bsdtcp amdump amindexd amidxtaped disable = no
groups = yes
}
/sbin/service xinetd restart # restart xinetd
If they don't already exist, add these in /etc/services
amanda 10080/udp # Dump server control
amidxtape 10083/tcp # Amanda tape indexing
amandaidx 10082/tcp # Amanda recovery program
ON SERVER: new node:
add to disklist file
add to /etc/sysconfig/iptables and restart with
/sbin/service iptables restart # if you have
iptables running add to .amandahosts
No iptables running.
Test a simple backup (without using up a tape). On SERVER:
amdump config --no-taper newclientnode /# or any DLE
that’s small
as root: su amanda -c amdump Daily --no-taper lathe /home
returns no error in about 1 full second.
===
Any of this help?
Deb Baddorf
Fermilab
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
Re: amrecover works, normal amanda backup, logging connection refused
On Jul 18, 2014, at 11:25 AM, Gene Heskett ghesk...@wdtv.com wrote:
14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed (Address
already in use (errno = 98)). service = amanda
14/7/18@12:09:37: ERROR: 3859 {cnf_start_services} Service amanda failed
to start and is deactivated.
14/7/18@12:09:37: DEBUG: 3859 {cnf_start_services} mask_max = 0,
services_started = 0
14/7/18@12:09:37: CRITICAL: 3859 {init_services} no services. Exiting...
I don’t like this part of your earlier email.
Does tail /var/log/messages say anything about an error?
After I use root and restart xinetd
/sbin/service xinetd restart
Stopping xinetd: [ OK ]
Starting xinetd: [ OK ]
my /var/log/messages file says
Jul 18 13:50:47 adback2 xinetd[32427]: Exiting...
Jul 18 13:50:47 adback2 xinetd[32468]: xinetd Version 2.3.14 started with
libwrap loadavg labeled-networking options compiled in.
Jul 18 13:50:47 adback2 xinetd[32468]: Started working: 8 available services
Does yours say there are ANY services successfully running?
Deb
RE: [BULK] Re: amrecover works, normal amanda backup, logging connection refused
I think you have a more basic network connectivity issue. If it were a simple
.amandahosts issue, you'd get an error message to that affect, not 'connection
reset by peer', which is a network thing.
Don't forget to check the logs on the server and the client, see
/var/log/Amanda/*, find the newest files in there and see what they say.
The first thing to do is verify that the server can backup itself as a client.
If your server-side is not working, this will get that straightened out. Then
check that the server and the client can resolve each other's hostnames, and
that they can ping each other (firewalls allowing.) If you can, put the client
on the same network as the server and disable all iptables/ufw firewalls, and
verify it works that way. Then move the client back to its own network and
test again. If it breaks on the other network, it has to be a firewall or
network issue blocking you.
In my own project here to install Amanda services everywhere, I've discovered
hosts running undocumented iptables, undocumented firewalls, and all sorts of
DNS breakages that I've had to clean up as I went.
For what it's worth, I had to drop back to using plain old auth=bsd for Amanda,
not bsdtcp, as some of the clients are so ancient the Amanda-client packages
they have don't grok bsdtcp yet, so I'm using the lcd to get everyone running
on a consistent setup. Once the ancients are retired I can upgrade all of them
to something modern, but until then...
--
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 1:36 PM
To: amanda-users@amanda.org
Subject: [BULK] Re: amrecover works, normal amanda backup, logging connection
refused
On Friday 18 July 2014 13:24:12 Debra S Baddorf did opine And Gene did reply:
What do I check next?
Thank you.
Cheers, Gene Heskett
Since Olivier wrote that he only used xinetd once, I figured I'd best
chime in. I use it all the time (not that I know very much about it).
Here are parts of my CHECKLIST for a new node:
yum install openssh-server
Got that already
yum install xinetd
installed about an hour ago
yum install dump(xfsdump is problematic)
Not using dump, tar-1.22 instead
yum install mtx
Not using tape
yum install mt-st
Not using tape
yum remove xfsdump
Add a file with the name .amandahosts to the backup-user home
directory with these contents:
backup-server.full.name backup-user amdump amindexd
backup user on the server is amanda, but neither client machine even has an
amanda (or backup) user. Presumably its backup:backup on the clients.
The /var/backups/.amandahosts files were different, so I made the failing
machine match the working machines version, no change, made the one in /etc
match, again no change. Neither file had amindexd listed, added that to each,
one at a time, no change.
chmod 600 /home/backup-user/.*amandahosts #it insists on this
Yup
My xinetd start file matches yours, as quoted in a recent email.
service amanda
{
socket_type = stream
protocol= tcp
wait= no
user= backup-user
group = root#whatever you are using
server = /usr/local/libexec/amanda/amandad
#wherever your file actually IS server_args =
-auth=bsdtcp amdump amindexd amidxtaped disable = no
groups = yes
}
/sbin/service xinetd restart # restart xinetd
If they don't already exist, add these in /etc/services amanda
10080/udp # Dump server control amidxtape 10083/tcp # Amanda tape
indexing amandaidx 10082/tcp # Amanda recovery program
ON SERVER: new node:
add to disklist file
add to /etc/sysconfig/iptables and restart with
/sbin/service iptables restart # if you have
iptables running add to .amandahosts
No iptables running.
Test a simple backup (without using up a tape). On SERVER:
amdump config --no-taper newclientnode /# or any DLE
that's small
as root: su amanda -c amdump Daily --no-taper lathe /home
returns no error in about 1 full second.
===
Any of this help?
Deb Baddorf
Fermilab
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
Re: amrecover works, normal amanda backup, logging connection refused
On Jul 18, 2014, at 1:35 PM, Gene Heskett ghesk...@wdtv.com wrote: backup user on the server is amanda, but neither client machine even has an amanda (or backup) user. Presumably its backup:backup on the clients. The /var/backups/.amandahosts files were different, so I made the failing machine match the working machines version, no change, made the one in /etc match, again no change. Neither file had amindexd listed, added that to each, one at a time, no change. Well, whatever you have as the username (I use operator and group=root) you need to have a user by that name. It can be no-loginbut it has to be there. Does the client have any /tmp/amanda log files? Certain such log files contain the configured params at the top. That would tell you what the backup user is supposed to be. grep for CLIENT_LOGIN Or did I miss you saying that you HAD created an account on the client node? Deb
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 14:27:20 Jon LaBadie did opine And Gene did reply: On Fri, Jul 18, 2014 at 10:26:38AM -0400, Gene Heskett wrote: Greeting Jean-Louis; 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. The last used time 'may' not be valid. Some admins mount their filesystems with the ?noatime? option. Jon That option is not set in either machines /etc/fstab Jon. Thanks. 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
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 14:51:39 Debra S Baddorf did opine
And Gene did reply:
On Jul 18, 2014, at 11:25 AM, Gene Heskett ghesk...@wdtv.com wrote:
14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed (Address
already in use (errno = 98)). service = amanda
14/7/18@12:09:37: ERROR: 3859 {cnf_start_services} Service amanda
failed to start and is deactivated.
14/7/18@12:09:37: DEBUG: 3859 {cnf_start_services} mask_max = 0,
services_started = 0
14/7/18@12:09:37: CRITICAL: 3859 {init_services} no services.
Exiting...
I don’t like this part of your earlier email.
Does tail /var/log/messages say anything about an error?
After I use root and restart xinetd
/sbin/service xinetd restart
Stopping xinetd: [ OK ]
Starting xinetd: [ OK ]
my /var/log/messages file says
Jul 18 13:50:47 adback2 xinetd[32427]: Exiting...
Jul 18 13:50:47 adback2 xinetd[32468]: xinetd Version 2.3.14 started
with libwrap loadavg labeled-networking options compiled in. Jul 18
13:50:47 adback2 xinetd[32468]: Started working: 8 available services
Does yours say there are ANY services successfully running?
Deb
Nothing about xinetd in dmesg, or in messages.
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
Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 14:53:23 Joi L. Ellis did opine
And Gene did reply:
I think you have a more basic network connectivity issue. If it were a
simple .amandahosts issue, you'd get an error message to that affect,
not 'connection reset by peer', which is a network thing.
Don't forget to check the logs on the server and the client, see
/var/log/Amanda/*, find the newest files in there and see what they
say.
The first thing to do is verify that the server can backup itself as a
client.
It did last night, along with the shop machine, but not the lathe machine.
I've been using amanda for about 15 years here
If your server-side is not working, this will get that
straightened out. Then check that the server and the client can
resolve each other's hostnames, and that they can ping each other
(firewalls allowing.) If you can, put the client on the same network
as the server and disable all iptables/ufw firewalls, and verify it
works that way.
They are all on the same 192.168.xx.xx subnet. I use hosts files and can
ssh -Y lathe into the machine, in fact thats how I am doing all this.
Then move the client back to its own network and test
again. If it breaks on the other network, it has to be a firewall or
network issue blocking you.
In my own project here to install Amanda services everywhere, I've
discovered hosts running undocumented iptables, undocumented
firewalls, and all sorts of DNS breakages that I've had to clean up as
I went.
For what it's worth, I had to drop back to using plain old auth=bsd for
Amanda, not bsdtcp, as some of the clients are so ancient the
Amanda-client packages they have don't grok bsdtcp yet, so I'm using
the lcd to get everyone running on a consistent setup. Once the
ancients are retired I can upgrade all of them to something modern,
but until then...
The other machine just like it, same box etc, has been using bsdtcp for
several years.
About burned out, but I need this backup to work too.
--
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 1:36 PM
To: amanda-users@amanda.org
Subject: [BULK] Re: amrecover works, normal amanda backup, logging
connection refused
On Friday 18 July 2014 13:24:12 Debra S Baddorf did opine And Gene did
reply:
What do I check next?
Thank you.
Cheers, Gene Heskett
Since Olivier wrote that he only used xinetd once, I figured I'd
best chime in. I use it all the time (not that I know very much
about it).
Here are parts of my CHECKLIST for a new node:
yum install openssh-server
Got that already
yum install xinetd
installed about an hour ago
yum install dump(xfsdump is problematic)
Not using dump, tar-1.22 instead
yum install mtx
Not using tape
yum install mt-st
Not using tape
yum remove xfsdump
Add a file with the name .amandahosts to the backup-user home
directory with these contents:
backup-server.full.name backup-user amdump amindexd
backup user on the server is amanda, but neither client machine even
has an amanda (or backup) user. Presumably its backup:backup on the
clients. The /var/backups/.amandahosts files were different, so I made
the failing machine match the working machines version, no change,
made the one in /etc match, again no change. Neither file had
amindexd listed, added that to each, one at a time, no change.
chmod 600 /home/backup-user/.*amandahosts #it insists on this
Yup
My xinetd start file matches yours, as quoted in a recent email.
service amanda
{
socket_type = stream
protocol= tcp
wait= no
user= backup-user
group = root#whatever you are using
server = /usr/local/libexec/amanda/amandad
#wherever your file actually IS server_args =
-auth=bsdtcp amdump amindexd amidxtaped disable = no
groups = yes
}
/sbin/service xinetd restart # restart xinetd
If they don't already exist, add these in /etc/services amanda
10080/udp # Dump server control amidxtape 10083/tcp # Amanda tape
indexing amandaidx 10082/tcp # Amanda recovery program
ON SERVER: new node:
add to disklist file
add to /etc/sysconfig/iptables and restart with
/sbin/service iptables restart # if you have
iptables running add to .amandahosts
No iptables running.
Test a simple backup (without using up a tape). On SERVER:
amdump config --no-taper newclientnode /# or any DLE
that's small
as root: su amanda -c amdump Daily --no-taper lathe /home
returns no error in about 1 full second
Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused
On Jul 18, 2014, at 1:53 PM, Joi L. Ellis jlel...@pavlovmedia.com wrote:
I think you have a more basic network connectivity issue. If it were a
simple .amandahosts issue, you'd get an error message to that affect, not
'connection reset by peer', which is a network thing.
Don't forget to check the logs on the server and the client, see
/var/log/Amanda/*, find the newest files in there and see what they say.
The first thing to do is verify that the server can backup itself as a
client. If your server-side is not working, this will get that straightened
out. Then check that the server and the client can resolve each other's
hostnames, and that they can ping each other (firewalls allowing.) If you
can, put the client on the same network as the server and disable all
iptables/ufw firewalls, and verify it works that way. Then move the client
back to its own network and test again. If it breaks on the other network,
it has to be a firewall or network issue blocking you.
In my own project here to install Amanda services everywhere, I've discovered
hosts running undocumented iptables, undocumented firewalls, and all sorts of
DNS breakages that I've had to clean up as I went.
For what it's worth, I had to drop back to using plain old auth=bsd for
Amanda, not bsdtcp, as some of the clients are so ancient the Amanda-client
packages they have don't grok bsdtcp yet, so I'm using the lcd to get
everyone running on a consistent setup. Once the ancients are retired I can
upgrade all of them to something modern, but until then...
--
Joi Owen
System Administrator
Pavlov Media, Inc
I’ve got clients in several flavors. My server has all of the types of xinetd
running, and can listen to whatever the client is sending.
Of course, I have to configure the amanda.conf and disklist to request of
backup of the right type for each client. Each client
can only do one kind (in my experience).
for example (only if you are interested any further)
AMANDA.CONF:
define dumptype dailyNormal {
BDglobal
# includes auth bsd
}
define dumptype dailyNormalBSDTCP {
BDglobal
auth “bsdtcp”#overrides the “bsd
}
define dumptype dailyNormalKRB5 {
BDglobal
auth “krb5 #overrides the “bsd”
}
DISKLIST:
client1/dailyNormal
client2 / dailyNormalBSDTCP
client3/dailyNormalKRB5
/ETC/XINETD.D :I’m sure the filenames don’t matter, but these help me:
amanda-dgramfile:
##note the auth=bsdon the server_args line
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= operator
group = root
server = /usr/local/libexec/amanda/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
disable = no
groups = yes
}
amanda-krb5 file:
##note the auth=krb5on the server_args line
service k5amanda
{
socket_type = stream
protocol= tcp
wait= no
user= root
group = root
server = /usr/local/libexec/amanda/amandad
server_args = -auth=krb5 amdump amindexd amidxtaped
disable = no
groups = yes
}
amanda-stream file:
##note the auth=bsdtcpon the server_args line
service amanda
{
socket_type = stream
protocol= tcp
wait= no
user= operator
group = root
server = /usr/local/libexec/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
disable = no
groups = yes
}
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 15:06:49 Debra S Baddorf did opine And Gene did reply: On Jul 18, 2014, at 1:35 PM, Gene Heskett ghesk...@wdtv.com wrote: backup user on the server is amanda, but neither client machine even has an amanda (or backup) user. Presumably its backup:backup on the clients. The /var/backups/.amandahosts files were different, so I made the failing machine match the working machines version, no change, made the one in /etc match, again no change. Neither file had amindexd listed, added that to each, one at a time, no change. Well, whatever you have as the username (I use operator and group=root) you need to have a user by that name. It can be no-login but it has to be there. Does the client have any /tmp/amanda log files? Certain such log files contain the configured params at the top. That would tell you what the backup user is supposed to be. grep for CLIENT_LOGIN Or did I miss you saying that you HAD created an account on the client node? Deb The working machine has a /tmp/amanda directory, the non-working one does not. Both /tmp's are owned by root, and looks to be 0777 perms, the whole string shows drwxrwxrwt on both machines, This is not a network showstopper, I am ssh -Y into both machines, checking diffs. ATM I haven't found and fixed any diffs between those two machines that did make a diff. 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
Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused
On Jul 18, 2014, at 1:53 PM, Joi L. Ellis jlel...@pavlovmedia.com wrote: Don't forget to check the logs on the server and the client, see /var/log/Amanda/*, find the newest files in there and see what they say. do a locate(or a find / -iname “*am*” ) to find your amanda logs. Joi puts his in /var/log/Amanda apparently. I have mine in /tmp/amanda — which I *think* is the default, but who knows! Some of the logs start with “amandad.” some are “amrecover” (since you’ve got THAT working, you can look where THOSE logs get put). Some start with “selfcheck” but those are the ones you aren’t reaching yet. Deb Baddorf Fermilab
Re: amrecover works, normal amanda backup, logging connection refused
On Jul 18, 2014, at 2:13 PM, Gene Heskett ghesk...@wdtv.com wrote:
On Friday 18 July 2014 14:51:39 Debra S Baddorf did opine
And Gene did reply:
On Jul 18, 2014, at 11:25 AM, Gene Heskett ghesk...@wdtv.com wrote:
14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed (Address
already in use (errno = 98)). service = amanda
14/7/18@12:09:37: ERROR: 3859 {cnf_start_services} Service amanda
failed to start and is deactivated.
14/7/18@12:09:37: DEBUG: 3859 {cnf_start_services} mask_max = 0,
services_started = 0
14/7/18@12:09:37: CRITICAL: 3859 {init_services} no services.
Exiting...
I don’t like this part of your earlier email.
Does tail /var/log/messages say anything about an error?
After I use root and restart xinetd
/sbin/service xinetd restart
Stopping xinetd: [ OK ]
Starting xinetd: [ OK ]
my /var/log/messages file says
Jul 18 13:50:47 adback2 xinetd[32427]: Exiting...
Jul 18 13:50:47 adback2 xinetd[32468]: xinetd Version 2.3.14 started
with libwrap loadavg labeled-networking options compiled in. Jul 18
13:50:47 adback2 xinetd[32468]: Started working: 8 available services
Does yours say there are ANY services successfully running?
Deb
Nothing about xinetd in dmesg, or in messages.
Cheers, Gene Heskett
Hmmm. Do we have a running xinet ?
ps auxww | grep net
root 2758 0.0 0.0 2852 884 ?Ss Jul11 0:00 xinetd
-stayalive -pidfile /var/run/xinetd.pid
/sbin/chkconfig --list xinetd
xinetd 0:off 1:off 2:off 3:on4:on5:on6:off
this tells what phases of reboot to start it with. The “ps” will say
if it is running NOW.
If you find “inetd” instead (or whatever the older name was?) THEN we
can proceed down that path.
Deb Baddorf
Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 15:24:00 Debra S Baddorf did opine
And Gene did reply:
On Jul 18, 2014, at 1:53 PM, Joi L. Ellis jlel...@pavlovmedia.com
wrote:
I think you have a more basic network connectivity issue. If it were
a simple .amandahosts issue, you'd get an error message to that
affect, not 'connection reset by peer', which is a network thing.
Don't forget to check the logs on the server and the client, see
/var/log/Amanda/*, find the newest files in there and see what they
say.
The first thing to do is verify that the server can backup itself as
a client. If your server-side is not working, this will get that
straightened out. Then check that the server and the client can
resolve each other's hostnames, and that they can ping each other
(firewalls allowing.) If you can, put the client on the same
network as the server and disable all iptables/ufw firewalls, and
verify it works that way. Then move the client back to its own
network and test again. If it breaks on the other network, it has
to be a firewall or network issue blocking you.
In my own project here to install Amanda services everywhere, I've
discovered hosts running undocumented iptables, undocumented
firewalls, and all sorts of DNS breakages that I've had to clean up
as I went.
For what it's worth, I had to drop back to using plain old auth=bsd
for Amanda, not bsdtcp, as some of the clients are so ancient the
Amanda-client packages they have don't grok bsdtcp yet, so I'm using
the lcd to get everyone running on a consistent setup. Once the
ancients are retired I can upgrade all of them to something modern,
but until then...
--
Joi Owen
System Administrator
Pavlov Media, Inc
I’ve got clients in several flavors. My server has all of the types of
xinetd running, and can listen to whatever the client is sending. Of
course, I have to configure the amanda.conf and disklist to request
of backup of the right type for each client. Each client can only do
one kind (in my experience).
No change in the disklist on the server for quite a few days, I had added
an entry to grab /lib/firmware 2 or 3 weeks ago, before e2fsck gave the /
partition on the drive a good mauling until it up and died. New drive,
new install. No backup of /etc for either machine. Once I get it working,
I'll add that to the disklist for both machines. Hindsight, 20-10 you
know. :)
Humm, good box has inetutils-inetd installed, bad box does not.
Installing it will remove xinetd. And now I am back to connection refused.
Anybody got a magic
for example (only if you are interested any further)
AMANDA.CONF:
define dumptype dailyNormal {
BDglobal
# includes auth bsd
}
define dumptype dailyNormalBSDTCP {
BDglobal
auth “bsdtcp”#overrides the “bsd
}
define dumptype dailyNormalKRB5 {
BDglobal
auth “krb5 #overrides the “bsd”
}
DISKLIST:
client1/dailyNormal
client2 / dailyNormalBSDTCP
client3/dailyNormalKRB5
/ETC/XINETD.D :I’m sure the filenames don’t matter, but these
help me:
amanda-dgramfile:
##note the auth=bsdon the server_args line
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= operator
group = root
server = /usr/local/libexec/amanda/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
disable = no
groups = yes
}
amanda-krb5 file:
##note the auth=krb5on the server_args line
service k5amanda
{
socket_type = stream
protocol= tcp
wait= no
user= root
group = root
server = /usr/local/libexec/amanda/amandad
server_args = -auth=krb5 amdump amindexd amidxtaped
disable = no
groups = yes
}
amanda-stream file:
##note the auth=bsdtcpon the server_args line
service amanda
{
socket_type = stream
protocol= tcp
wait= no
user= operator
group = root
server = /usr/local/libexec/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd
amidxtaped disable = no
groups = yes
}
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,
Re: [BULK] Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 15:38:36 Debra S Baddorf did opine And Gene did reply: On Jul 18, 2014, at 1:53 PM, Joi L. Ellis jlel...@pavlovmedia.com wrote: Don't forget to check the logs on the server and the client, see /var/log/Amanda/*, find the newest files in there and see what they say. do a locate(or a find / -iname “*am*” ) to find your amanda logs. Joi puts his in /var/log/Amanda apparently. I have mine in /tmp/amanda — which I *think* is the default, but who knows! Some of the logs start with “amandad.” some are “amrecover” (since you’ve got THAT working, you can look where THOSE logs get put). Some start with “selfcheck” but those are the ones you aren’t reaching yet. Deb Baddorf Fermilab None of the return is logfiles, just the executables and docs. On both machines. 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
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 15:49:47 Debra S Baddorf did opine And Gene did reply: ps auxww | grep net Except for PID's both machines are identical: shop: gene@shop:/etc$ ps auxww | grep net root13 0.0 0.0 0 0 ?SJul11 0:00 [netns] root 1128 0.0 0.0 1984 684 ?Ss Jul11 0:00 /usr/sbin/inetd gene 15807 0.0 0.0 3352 888 pts/5S+ 16:03 0:00 grep --color=auto net lathe: gene@lathe:/etc$ ps auxww | grep net root13 0.0 0.0 0 0 ?SJul17 0:00 [netns] root 4386 0.0 0.0 2132 748 ?S15:45 0:00 /usr/sbin/inetutils-inetd gene 4427 0.0 0.0 3352 884 pts/1S+ 16:03 0:00 grep --color=auto net Humm,no they are not! but a bare inetd is not now available from the repos. The shop box apparently has (its a 2 year old install) openbsd-inetd whereas the lathe has inetdutils-inetd. Shouldn't they work alike? 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
Re: amrecover works, normal amanda backup, logging connection refused
Gene Heskett gheskett-at-wdtv.com |amusersj-ml0| wrote at 15:07 -0400 on Jul
18, 2014:
On Friday 18 July 2014 14:22:48 John Hein did opine
And Gene did reply:
Gene Heskett wrote at 12:25 -0400 on Jul 18, 2014:
14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed (Address
already in use (errno = 98)). service = amanda
More than one xinetd or inetd running?
Maybe some basic background is in order. The basic operation of
*inetd is pretty simple, and if you understand the basics, you can
really solve many of the common issues yourself.
*inetd runs forever listening on the sockets you tell it to
listen on (as configured by the xinetd or inetd config files).
When requests (any activity) on that socket come in, it tries
to run the service that is specified in its configuration.
If something else owns that socket, *inetd can't do its job
(i.e., can't start the service corresponds to that socket).
If not, then *inetd will spawn off the configured service (amandad
in amanda's case).
Technically, you don't need *inetd. You can kick off amandad to run
on the client some other way (e.g., daemontools, ssh). But the server
expects something to be listening on the client when it comes time to
do the dump.
As others have mentioned, you have to configure things for the right
type of socket - the configuration of the amanda server (primarily
in amanda.conf / disklist) and client (typically inetd config and
amanda-client.conf) should match (see amanda-auth(7) and
amanda-client.conf(5)).
Here's some other good info so you can maybe help yourself and
understand better how things work:
http://wiki.zmanda.com/index.php/Quick_start_%28old%29
I just discovered that the failing box did NOT have an /etc/amanda-
client.conf, so I copied the one from examples and edited it. But the
working machine doesn't have one either, so I nuked it. amcheck didn't
care.
You got that out of my email?
What about the most important bits:
two inetd's running?
and the bind failure?
And the hint to use the background info to try digging on your own a
little. You're doing lots of things and it seems you don't know why -
just guessing. That's never a good recipe.
Your xinetd got a bind failure. That has nothing to do with amanda.
Fix that first.
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 16:16:15 John Hein wrote:
Gene Heskett gheskett-at-wdtv.com |amusersj-ml0| wrote at 15:07 -0400 on Jul
18, 2014:
On Friday 18 July 2014 14:22:48 John Hein did opine
And Gene did reply:
Gene Heskett wrote at 12:25 -0400 on Jul 18, 2014:
14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed
(Address already in use (errno = 98)). service = amanda
More than one xinetd or inetd running?
Maybe some basic background is in order. The basic operation of
*inetd is pretty simple, and if you understand the basics, you can
really solve many of the common issues yourself.
*inetd runs forever listening on the sockets you tell it to
listen on (as configured by the xinetd or inetd config files).
When requests (any activity) on that socket come in, it tries
to run the service that is specified in its configuration.
If something else owns that socket, *inetd can't do its job
(i.e., can't start the service corresponds to that socket).
If not, then *inetd will spawn off the configured service (amandad
in amanda's case).
Technically, you don't need *inetd. You can kick off amandad to
run on the client some other way (e.g., daemontools, ssh). But
the server expects something to be listening on the client when
it comes time to do the dump.
As others have mentioned, you have to configure things for the
right type of socket - the configuration of the amanda server
(primarily in amanda.conf / disklist) and client (typically inetd
config and amanda-client.conf) should match (see amanda-auth(7)
and
amanda-client.conf(5)).
Here's some other good info so you can maybe help yourself and
understand better how things work:
http://wiki.zmanda.com/index.php/Quick_start_%28old%29
I just discovered that the failing box did NOT have an /etc/amanda-
client.conf, so I copied the one from examples and edited it. But
the working machine doesn't have one either, so I nuked it. amcheck
didn't care.
You got that out of my email?
What about the most important bits:
two inetd's running?
and the bind failure?
And the hint to use the background info to try digging on your own a
little. You're doing lots of things and it seems you don't know why -
just guessing. That's never a good recipe.
Your xinetd got a bind failure. That has nothing to do with amanda.
Fix that first.
Lets go back to that netstat -na|grep 10080
shop:
tcp0 0 0.0.0.0:10080 0.0.0.0:* LISTEN
lathe:
tcp6 0 0 :::10080:::*LISTEN
So my guess is that -inet_ipv6 option is killing ipv4 on the lathes machine.
Bingo!!!
manda Backup Client Hosts Check
ERROR: lathe: [Can't open exclude file /GenesAmandaHelper-0.61/excludes (No
such file or directory)]
ERROR: lathe: [Can't open exclude file /GenesAmandaHelper-0.61/excludes (No
such file or directory)]
ERROR: lathe: [Can't open exclude file /GenesAmandaHelper-0.61/excludes (No
such file or directory)]
ERROR: lathe: [Can't open exclude file /GenesAmandaHelper-0.61/excludes (No
such file or directory)]
ERROR: lathe: [Can't open exclude file /GenesAmandaHelper-0.61/excludes (No
such file or directory)]
Client check: 3 hosts checked in 2.107 seconds. 5 problems found.
(brought to you by Amanda 4.0.0alpha.svn.4761)
That subdir, which is part of my own scripting wrapped around amanda,
does not exist on the lathes box. nfs is working so I can fix that
from here with mc. BRB. Except I can't, only the /home dirs are nfs
shares, damn.
I'll figure out something.
Thanks, that ipv6 only option in the /etc/init.d/xinetd script was it.
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
Re: amrecover works, normal amanda backup, logging connection refused
On Jul 18, 2014, at 3:13 PM, Gene Heskett ghesk...@wdtv.com wrote: On Friday 18 July 2014 15:49:47 Debra S Baddorf did opine And Gene did reply: ps auxww | grep net Except for PID's both machines are identical: shop: gene@shop:/etc$ ps auxww | grep net root13 0.0 0.0 0 0 ?SJul11 0:00 [netns] root 1128 0.0 0.0 1984 684 ?Ss Jul11 0:00 /usr/sbin/inetd gene 15807 0.0 0.0 3352 888 pts/5S+ 16:03 0:00 grep --color=auto net lathe: gene@lathe:/etc$ ps auxww | grep net root13 0.0 0.0 0 0 ?SJul17 0:00 [netns] root 4386 0.0 0.0 2132 748 ?S15:45 0:00 /usr/sbin/inetutils-inetd gene 4427 0.0 0.0 3352 884 pts/1S+ 16:03 0:00 grep --color=auto net Humm,no they are not! but a bare inetd is not now available from the repos. The shop box apparently has (its a 2 year old install) openbsd-inetd whereas the lathe has inetdutils-inetd. Shouldn't they work alike? Cheers, Gene Heskett Ahh! OK — inetd not xinetd. Heres an AMANDA specific instruction: Steps 1. Edit /etc/inetd.conf and add this line to the end of the file, if there is any old amanda related lines comment them out: amanda stream tcp nowait amandabackup /usr/lib/amanda/amandad amandad -auth=bsdtcp amdump amindexd amidxtaped my comment: change “amandabackup” to your username check that the location is right for you change to “auth=bsd” if that’s what the working node has 2. Edit /etc/services and add this line to the end of the file, if there is any old amanda related lines comment them out: amanda 10080/tcp # amanda backup services 3. Restart the inetd demon and check for errors in the system log files Deb Baddorf I defer to anybody else who still uses this, but if no other suggestions, try the above! I used to use it; and it does look familiar.
Re: amrecover works, normal amanda backup, logging connection refused
On Friday 18 July 2014 16:16:15 John Hein did opine
And Gene did reply:
Gene Heskett gheskett-at-wdtv.com |amusersj-ml0| wrote at 15:07 -0400 on
Jul 18, 2014:
On Friday 18 July 2014 14:22:48 John Hein did opine
And Gene did reply:
Gene Heskett wrote at 12:25 -0400 on Jul 18, 2014:
14/7/18@12:09:37: ERROR: 3859 {activate_normal} bind failed
(Address already in use (errno = 98)). service = amanda
More than one xinetd or inetd running?
Maybe some basic background is in order. The basic operation of
*inetd is pretty simple, and if you understand the basics, you can
really solve many of the common issues yourself.
*inetd runs forever listening on the sockets you tell it to
listen on (as configured by the xinetd or inetd config files).
When requests (any activity) on that socket come in, it tries
to run the service that is specified in its configuration.
If something else owns that socket, *inetd can't do its job
(i.e., can't start the service corresponds to that socket).
If not, then *inetd will spawn off the configured service (amandad
in amanda's case).
Technically, you don't need *inetd. You can kick off amandad to
run on the client some other way (e.g., daemontools, ssh). But
the server expects something to be listening on the client when
it comes time to do the dump.
As others have mentioned, you have to configure things for the
right type of socket - the configuration of the amanda server
(primarily in amanda.conf / disklist) and client (typically inetd
config and amanda-client.conf) should match (see amanda-auth(7)
and
amanda-client.conf(5)).
Here's some other good info so you can maybe help yourself and
understand better how things work:
http://wiki.zmanda.com/index.php/Quick_start_%28old%29
I just discovered that the failing box did NOT have an /etc/amanda-
client.conf, so I copied the one from examples and edited it. But
the working machine doesn't have one either, so I nuked it. amcheck
didn't care.
You got that out of my email?
What about the most important bits:
two inetd's running?
and the bind failure?
And the hint to use the background info to try digging on your own a
little. You're doing lots of things and it seems you don't know why -
just guessing. That's never a good recipe.
Your xinetd got a bind failure. That has nothing to do with amanda.
Fix that first.
I found it! Call off the Bloodhounds St. Bernards. :)
I had to reinstall xinetd, then remove the application of the -inet_ipv6
option the startup script in /etc/init.d was applying to xinetd.
$DIETY damn them all to someplace really hot for trying to make a linux
version released in 2010 as ipv6 only! I knew I had fought with this crap
4 years ago, but my shorter term memory doesn't get refreshed on a short
enough cycle. One of the hazards of outliving ALL your enemies.
But I am glad I have, altho that was touch and go about 6 weeks back when
I found myself just barely aware on the bedroom floor and couldn't draw a
breath. Pulmonary embolism, blocked the artery from the right side of my
heart going into the lungs, came very very close to punching my ticket.
Blew the right side of my heart up to about 2x normal, but that seems to
have fixed itself now. The high priced clot-buster shot worked, so I am
still here. Lost some weight too I feel better right now than I have in
10 years. On rat poison for blood thinner of course. ;-)
Thank you ALL for putting up with me when it wasn't even an amanda
problem, please accept my apologies.
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
