I think I'm getting closer to getting this working on FreeBSD and my past errors
were a combination of hardheadedness and incorrect documentation. Some of the
"encryption" documentation points to the need to create your own amaespipe, etc.
I followed the suggestion of just using amcrypt and this appears to work.
- on the client, ran configure on the amanda source with no pointers to
special "amgtar" or exotic tar wrapper scripts, then built and installed it
./configure --prefix=/usr/local/amanda25 --infodir=/usr/share/info
--mandir=/usr/share/man --with-user=amanda --with-group=operator
--with-config=dailyencrypt --with-gnutar=/usr/local/bin/gtar
--with-gnutar-listdir=/usr/local/amanda25/gnutar-lists --with-debugging
--with-debug-days=21 --with-fqdn --with-ssh-security --with-buffered-dump
--with-dump-honor-nodump --with-tape-server=amanda.utexas.edu
--with-tmpdir=/tmp/amanda --with-index-server=amanda.utexas.edu --without-ipv6
- created a dumptype on the amanda server with the following:
define dumptype ssh-encrypt {
global
program "GNUTAR"
comment "No compression, using TAR and client symmetric encryption"
compress none
holdingdisk yes
auth "ssh"
ssh_keys "/home/amanda/.ssh/id_rsa_amdump"
encrypt client
client_encrypt "/usr/local/amanda25/sbin/amcrypt"
client_decrypt_option "-d"
}
One small note: amcrypt and amaespipe are not built on the client if you run
"configure" with "--without-server". I would suggest that this functionality
be changed although I don't have any real issue with building everything on the
client.
I ran a backup and it worked ... I could see the index file on the amanda
server, there were filesystem listings in it. The next step was to attempt a
restore. Here's where I ran into the next problem. amrecover started up and I
was able to list the files from the backup. Unfortunately, when I attempted a
recover I got the following error message:
Etar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Archive contains `\004KrtSv\2344D\314\377\371' where numeric off_t value
expected
tar: Skipping to next header
tar: Archive contains `\330\022\303c\230\265\a>\262\311\034\207' where numeric
off_t value expected
tar: Skipping to next header
tar: ./boot/boot0: Not found in archive
tar: ./boot/boot1: Not found in archive
tar: Error exit delayed from previous errors
Extractor child exited with status 2
(by the way, two backups were run, one with tar 1.13.25 and the second having
configured amanda to use 1.14)
Any suggestions/ideas?
Oscar Ricardo Silva wrote:
Sorry for the multiple recent posts but as I work my way through enabling
encrypted backups I keep running into different issues. In our last
episode, I
had enabled encrypted backups and corrected an issue with ipv6 and key
placement
on the amanda server.
My current issue is that while backups appear to run without a hitch, I
can't
restore. These problems are all on FreeBSD machines, 4.x on up through
6.3. I
can launch amrecover and it communicates with the amanda server. When I
try to
list files I get the error:
No index records for disk for specified date
If date correct, notify system administrator
I checked the amanda server and sure enough, there were no index files.
The
file for that particular filesystem was there but it was empty. I have
a feeling this isn't necessarily an amanda issue but more of a problem
in how encryption is implemented. If I try encrypting the backup file
manually I get the error:
bz2aespipe: wrong magic - aborted
I changed the output for amaespipe so that errors are written to a file
instead
of /dev/tty and when the backup runs I get the same error message.
Is anybody else doing encrypted backups for FreeBSD clients? Could be
we take this off-list since it's probably not an amanda specific problem.
Oscar
|
