Hi,

Is there any gross imcompatability that would prevent a 2.6.1p1 client
from being backed up by a 2.4.3b3 server?

I've got it to the point where they are at least talking with each
other, using auth bsd.

amcheck -c is happy.
estimates worked ok.

But amstatus is showing this:

client-a:/a        0 driver: [parse of reply message failed] (10:34:30)
client-a:/var      0 driver: [parse of reply message failed] (10:41:15)
client-a:/var/log  0   31020k wait for dumping driver: (aborted:[request 
timeout])


hmm...  here's something interesting in the sendbackup.debug file:

   1242744076.458012: sendbackup: pid 14788 ruid 501 euid 501 version 2.6.1p1: 
start a
   t Tue May 19 10:41:16 2009
   1242744076.458089: sendbackup: Version 2.6.1p1
   1242744076.458650: sendbackup:   sendbackup req: <GNUTAR /var 0 
1970:1:1:0:0:0 OPTI
   ONS |;bsd-auth;index;>
   1242744076.458736: sendbackup:   Parsed request as: program `GNUTAR'
   1242744076.458749: sendbackup:                      disk `/var'
   1242744076.458760: sendbackup:                      device `/var'
   1242744076.458770: sendbackup:                      level 0
   1242744076.458781: sendbackup:                      since 1970:1:1:0:0:0
   1242744076.458791: sendbackup:                      options 
`|;bsd-auth;index;'
   1242744076.458998: sendbackup: start: client-a:/var lev 0
   1242744076.459129: sendbackup: doing level 0 dump as listed-incremental to 
'/var/li
   b/amanda/gnutar-lists/client-a_var_0.new'
   1242744076.461334: sendbackup: Started index creator: "/bin/tar -tf - 
2>/dev/null |
    sed -e 's/^\.//'"
   1242744076.461537: sendbackup: pipespawnv: stdoutfd is 50
   1242744076.461947: sendbackup: Spawning "/usr/libexec/amanda/runtar runtar 
NOCONFIG
    /bin/tar --create --file - --directory /var --one-file-system 
--listed-incremental
    /var/lib/amanda/gnutar-lists/client-a_var_0.new --sparse 
--ignore-failed-read --to
   tals ." in pipeline
   1242744076.463151: sendbackup: gnutar: /usr/libexec/amanda/runtar: pid 14792
   1242744076.463205: sendbackup: Started backup
   1242744166.493587: sendbackup: critical (fatal): index tee cannot write 
[Broken pip
   e]
   /usr/lib64/amanda/libamanda-2.6.1p1.so[0x35834215b2]
   /lib64/libglib-2.0.so.0(g_logv+0x26f)[0x3af5c34d5f]
   /lib64/libglib-2.0.so.0(g_log+0x83)[0x3af5c34f33]
   /usr/libexec/amanda/sendbackup(start_index+0x290)[0x4037f0]
   /usr/libexec/amanda/sendbackup[0x4075f0]
   /usr/libexec/amanda/sendbackup(main+0x10a4)[0x405834]
   /lib64/libc.so.6(__libc_start_main+0xf4)[0x3fe1c1d8b4]
   /usr/libexec/amanda/sendbackup[0x403139]


So it looks like a problem sending the index data.  I've set index_server
to the correct hostname in /etc/amanda-client.conf.  Will this properly
override the settings configured at compile time?  This client is installed
from the redhat rpm, so it has no local compile-time configuration.

The /etc/amanda-client.conf looks like this:

   #
   # amanda.conf - sample Amanda client configuration file.
   #
   # This file normally goes in /etc/amanda/amanda-client.conf.
   #

   conf "test"             # your config name

   index_server "amanda-server"    # your amindexd server
   tape_server  "amanda-server"    # your amidxtaped server
   tapedev      "tape:/dev/nst1"   # your tape device
                        # if not set, Use configure or ask server.
                        # if set to empty string "", ask server
                        # amrecover will use the changer if set to the value
                        # of 'amrecover_changer' in the server amanda.conf.

   #   auth        - authentication scheme to use between server and client.
   #                 Valid values are "bsd", "bsdudp", "bsdtcp", "krb5", 
"local",
   #                 "rsh" and "ssh".
   #                 Default: [auth "bsdtcp"]
   auth "bsd"

   ssh_keys ""                     # your ssh keys file if you use ssh auth


Anyone see anything obvious we're overlooking?  (Yeah, besides needing to
upgrade the server!)  :-)

-Mitch