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 {remove_disabled_services} removing time
14/7/18@12:09:37: DEBUG: 3859 {remove_disabled_services} removing time
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 = stream
Protocol (name,number) = (tcp,6)
port = 10080
wait = no
user = 34
group = 34
Groups = yes
PER_SOURCE = -1
Bind = All addresses.
Server = /usr/lib/amanda/amandad
Server argv = amandad -auth=bsdtcp amdump amindexd amidxtaped
Only from: All sites
No access: No blocked sites
No logging
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...
Reverted the only_from name change, then noted its commented out?
But an amcheck now says connection reset by peer, and returns quickly.
And the xinetd.d/amanda file was not touched by the amcheck run.
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
