I am going to try and resurrect this thread having been able to home in on
the apparent bug I found with bsdtcp auth.
I have now converted most of our systems to using bsdtcp and amcheck is
showing no errors at this time.
The problem I had before was, to reiterate:
Disklist with two entries.
One entry uses bsdtcp
The other entry uses BSD.
If the client of the disklist entry that is configured on the server to use
bsdtcp is not configured to use bsdtcp on the CLIENT in /etc/inetd.conf
then the client which is configured to use default authentication returns
errors.
I now have a full disklist for all of our servers. Some are using bsdtcp
others are using the default (which as I understand it is BSD).
If I go to one of the clients whose disklist entry on the server is for
bsdtcp and I change its /etc/inetd.conf from this:
amanda stream tcp nowait backup /usr/lib/amanda/amandad amandad
-auth=bsdtcp amdump
to this:
amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad
then ALL other disklist entries which are NOT using bsdtcp return errors on
amcheck -c
Disklist entries which are configured to use bsdtcp are not affected and do
not generate errors, only those using BSD auth.
This is just a change in inetd.conf on ONE client.
The errors for the other disklist entries are:
ERROR: <an amanda client>: [access as backup not allowed from root@<the
amanda server>] amandahostsauth failed
I have no idea if this is an amanda problem or a Debian packaging problem
or what it is. But its repeatable.
Version info for the amanda-server package on the amanda server is:
r...@fileserver:~# dpkg -s amanda-server
Package: amanda-server
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 1216
Maintainer: Bdale Garbee <bd...@gag.com>
Architecture: i386
Source: amanda
Version: 1:2.5.2p1-5
Steve Wray wrote:
Steve Wray wrote:
Jean-Louis Martineau wrote:
Run 'amadmin <CONFIG> disklist' and check the auth is set as expected
for all dles.
I've done this, with the amanda.conf having bsdudp and with it having
bsdtcp for that entry.
In both cases all auth entries for all other DLE's are 'BSD'.
In both cases only that one DLE is reported as having either bsdtcp or
bsdudp, in both cases matching what is in the amanda.conf
So I'd say that was all as expected.
Having changed this one DLE to bsdudp I'm still seeing intermittent
problems with the nightly backup run.
I'd like to change to bsdtcp as it seems more robust but as I've
mentioned there were some serious problems with that.
Any further advice or help would be appreciated.
Thanks.
Jean-Louis
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
On the client, in the sendbackup.20100106012630.debug log I see:
sendbackup-gnutar: time 0.056: /usr/lib/amanda/runtar: pid 3348
sendbackup: time 0.057: started backup
sendbackup: time 90.352: index tee cannot write [Broken pipe]
sendbackup: time 90.352: pid 3346 finish time Wed Jan 6
01:28:01 2010
90 seconds, it's not a dtimeout issue.
Post all debug files for the run.
You can also try the bsdtcp auth, it is more firewall friendly.
Ah hang on, am I right in understanding that you can't have just
one dle using bsdtcp auth? That they would all have to have it?
(ie the inetd configuration)
All dles for a client must have the same auth.
different client can have different auth.
We are going around in circles a little here.
Allow me to try to make things very clear.
In my amanda.conf I have a dumptype defined as such:
(I've included the parent dumptypes. The 'global' dumptype is empty)
define dumptype root-tar {
global
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
index
exclude list "/etc/amanda/exclude.gtar"
priority low
}
define dumptype nocomp-root-tar {
root-tar
comment "Root partitions without compression"
compress none
}
define dumptype problem-nocomp-root-tar {
nocomp-root-tar
comment "Root partitions without compression, problem client"
compress none
auth "bsdudp"
# auth "bsdtcp"
}
There are several DLEs for clients using the 'nocomp-root-tar'
dumptype and only *one* DLE for *one* client using the
'problem-nocomp-root-tar' dumptype.
With the bsdudp line uncommented everything is happy with an amcheck.
With the bsdtcp line uncommented (and the bsdudp line commented out)
*no* client is happy with the amcheck *other* than the client which
uses 'problem-nocomp-root-tar'. However, as noted in another email
this is intermittent, sometimes some clients using nocomp-root-tar
are happy. So far its not exhibiting much pattern that I can see.
The above *does* include the fact that I *do* change the inetd.conf
on the client which uses problem-nocomp-root-tar *and* restart inetd.
So, with a change of one line in a dumptype in a DLE used by one
client, all other clients have problems.
Perhaps I am misunderstanding something basic about dumptype
configuration?
--
Please remember that an email is just like a postcard; it is not
confidential nor private nor secure and can be read by many other people
than the intended recipient. A postcard can be read by anyone at the mail
sorting office and expecting what is written on it to be private and secret
is not realistic. Please hold no higher expectation of email.
If you need to send confidential information in an email you need to use
encryption. PGP is Pretty good for this.
