On Tuesday, May 24, 2011 08:58:11 AM Jean-Louis Martineau did opine:

> Gene,
> 
> Did you correctly set the xinetd for bsdtcp auth? (read 'man
> amanda-auth'), nobody can tell you what's wrong in it if you don't post
> the file.
> Did you restarted xinetd?
> 
> Jean-Louis
> 
> gene heskett wrote:
> > On Sunday, May 22, 2011 09:52:21 AM gene heskett did opine:
> >> On Saturday, May 21, 2011 09:36:50 AM gene heskett did opine:
> >>> On Saturday, May 21, 2011 09:11:22 AM gene heskett did opine:
> >>>> On Friday, May 20, 2011 09:18:28 PM Jean-Louis Martineau did opine:
> >>>>> gene heskett wrote:
> >>>>>> On Friday, May 20, 2011 11:51:52 AM Jean-Louis Martineau did
> > 
> > opine:
> >>>>>>> Check the ReleaseNotes:
> >>>>>>> * The default auth is changed to "bsdtcp", if you are using the
> >>>>>>> default bsd then you must add it to your configuration.
> >>>>>>> 
> >>>>>>>     o in amanda.conf
> >>>>>>>     o in amanda-client.conf
> >>>>>>>     o in dumptype/disklist
> >>>>>>>     o in xinetd (if no '-auth' argument to amandad)
> >>>>>>> 
> >>>>>>> As you are still using BSD, you must update your dumptype to
> >>>>>>> specify it. Or better, fix your xinetd for bsdtcp.
> >>>>>>> 
> >>>>>>> Jean-Louis
> >>>>>> 
> >>>>>> Is there a URL for instructions on how to do this?
> >>>>> 
> >>>>> man amanda-auth
> >>>>> 
> >>>>>> And, will it affect my ability to recover from backups made
> >>>>>> using the present .amandahosts way?
> >>>>>> 
> >>>>>> In other words, are these changes backwards compatible?
> >>>>> 
> >>>>> It change the authentication and transport mechanism, that's all,
> >>>>> your data are still on tape and recoverable.
> >>>>> 
> >>>>> Jean-Louis
> >>>> 
> >>>> I made that change, 4026 works but slower for the client check, and
> >>>> 4048 is still broken.  Connection refused for each machine.
> >>>> 
> >>>> Thanks Jean-Louis.
> >>> 
> >>> I had missed 4040 in the progression, with the changes in
> >>> xinetd.d/amanda for bsdtcp, 4040 passes the amcheck, so its
> >>> something between 4040 and 4048.
> >> 
> >> Further PS:  I made the changes noted in the ReleaseNotes, including
> >> on the client machine, now 4040 is refused by the client machine,
> >> and 4048 is refused by both.
> >> 
> >> The Client machines (shop.coyote.den) amanda is 2.61p1.
> >> 
> >> This is what is shipped yet with Ubuntu 10.4 LTS, and is frozen by
> >> the application it runs, emc, at least until someone ports RTAI to a
> >> later kernel.  That likely will not occur before Ubuntu releases
> >> another newer LTS version of linux.
> >> 
> >> So, I am between a rock and a hard place here.  I either start
> >> building the client machines amanda-client install from tarball, or
> >> stay frozen at no newer than 4040.  That machine is running
> >> extremely well and I hesitate to start installing tarballs
> >> willy-nilly on it.
> >> 
> >> If I comment out the auth line in the local amanda.conf global
> >> dumptype, then 4040 still works for both machines with both
> >> xinetd.d/amanda's server- args set for -auth=bsdtcp yadda yadda.
> > 
> > Additional PS:  The shop machine, a Ubuntu-10.4 LTS, has no functional
> > amanda-client file, only the ones in /usr/share/doc fall out of a
> > locate.
> > 
> > This morning I went through the 4048 ReleaseNotes checklist and
> > verified or changed everything noted about the auth "bsdtcp",
> > reinstalled 4048 and it all fails, even after restarting xinetd on
> > this machine.  ISTR I added the /etc/xinetd.d/amanda file to the LTS
> > install, but now I cannot find a launcher for xinetd to restart it,
> > so I suspect my addition there was a waste of time.  Yes, I just
> > found one active line in /etc/inetd.conf, for amanda, and changed its
> > auth setting from bsd to bsdtcp, but it made zero diff in the amcheck
> > output.
> > 
> > So, what am I missing yet?
> > 
> > The local /tmp/amanda-dbg/server/Daily/amcheck.20110522100026.debug
> > is attached, but all I see is the Connection refused, no clue why.
> > 
> > In the meantime, I am going back to 4040 if I can undo enough to
> > restore it.
> > 
> > Thanks.

Yes, and yes.  In fact, it may still be set, the reversion to make 4040 
work was I believe, the removal of that line from the amanda.conf by way of 
a # in front of it, in the global dumptype stanza.  And backing out the 
bsdtcp in this, from my coyote.coyote.den/etc/xinetd.d/amanda:
# default = off
#
# description: Part of the Amanda server package
# This is the list of daemons & such it needs
service amanda
{
        disable = no
#       only_from       = coyote.coyote.den
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = amanda
        group           = disk
        groups          = yes
        server          = /usr/local/libexec/amanda/amandad
        server_args     = -auth=bsd amdump amindexd amidxtaped
}
service amandaidx
{
        disable = no
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = amanda
        group           = disk
        groups          = yes
        server          = /usr/local/libexec/amanda/amindexd
}
service amidxtape
{
        disable = no
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = amanda
        group           = disk
        groups          = yes
        server          = /usr/local/libexec/amanda/amidxtaped
}

The above file likewise, except for playing with the -auth line, is 
unchanged since the .amandahosts was put into use, several years ago now.
 
ISTR the inetd.conf on the Ubuntu-10.4 LTS machine still says to use 
bsdtcp, but its working fine.
------------------------from shop.coyote.den/etc/inetd.conf--------------
#:OTHER: Other services (watch for kmails word wrap)
amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad -
auth=bsdtcp amdump amindexd amidxtaped

inetd of course is 100% on-demand, so there is no restart involved.

Obviously there is another interaction, and it may exist only on this pclos 
machine.

But since I've sent the selfcheck logs, which are no more informative than 
the connection refused that amcheck spits out to the terminal screen, there 
doesn't seem to be a clue there.

Do I also need to add that to my ./configure driver script somehow?
That stanza of the script has been unchanged for at least a year, maybe 
longer, however its date is Sept 2010 which is when I last reinstalled 
after a fatal firmware update of the boot drive:
----------------------
./configure --with-user=amanda \
        --with-group=disk \
        --with-owner=amanda \
        --with-gnu-ld \
        --prefix=/usr/local/ \
        --with-debugging=/tmp/amanda-dbg/ \
        --with-tape-server=coyote \
        --with-bsdtcp-security --with-amandahosts \
        --with-configdir=/usr/local/etc/amanda \
        --with-gnutar=/bin/tar
-------------------------

I could nuke the 4048 directory and re-create it again, but the build trace 
must be at least 20 megabytes.  The idea being to scroll back thru the 
./configure history to see if its missing something.  But what should I be 
looking for would appear to be the 64 dollar question.

Thanks Jean-Louis.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
<http://tinyurl.com/ddg5bz>
<http://www.cantrip.org/gatto.html>
For most men life is a search for the proper manila envelope in which to
get themselves filed.
                -- Clifton Fadiman

Reply via email to