Re: No index files being generated - possible freebsd-ism or shell specific issues
Dustin J. Mitchell wrote: On Thu, Apr 3, 2008 at 9:40 PM, Oscar Ricardo Silva <[EMAIL PROTECTED]> wrote: 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. I don't know if it's because people who are into encryption play their cards close to their chest, or what, but it seems like every time it comes up, the documentation doesn't end up getting updated. Personally, I've not played much with encryption, and my plate's way to full to do so at the moment. All of this is a roundabout way of saying: yes, the documentation is horribly linux-centric, aespipe-centric, and out of date, and is also on a wiki. Please update! :) 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. This is a good point. I'll take a look. They really should be common to both client and server. 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) This looks suspiciously like amrecover isn't even trying to decrypt the data. The funny thing about Amanda is that all of the "unfiltering" of data on restore is done on the server, regardless of the client/server settings in the DLE, and happens through 'amfetchdump'. So a good place to start may be extracting your dumps using 'amfetchdump', and examining any problems there. Hopefully someone else can jump in with a solution. What version of Amanda is this? Dustin It's 2.5.2p1 on both the server and the client. I'll take a look at the server side of things and see if I'm able to "recover" anything there as well as using amfetchdump.
Re: No index files being generated - possible freebsd-ism or shell specific issues
On Thu, Apr 3, 2008 at 9:40 PM, Oscar Ricardo Silva <[EMAIL PROTECTED]> wrote: > 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. I don't know if it's because people who are into encryption play their cards close to their chest, or what, but it seems like every time it comes up, the documentation doesn't end up getting updated. Personally, I've not played much with encryption, and my plate's way to full to do so at the moment. All of this is a roundabout way of saying: yes, the documentation is horribly linux-centric, aespipe-centric, and out of date, and is also on a wiki. Please update! :) > 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. This is a good point. I'll take a look. They really should be common to both client and server. > 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) This looks suspiciously like amrecover isn't even trying to decrypt the data. The funny thing about Amanda is that all of the "unfiltering" of data on restore is done on the server, regardless of the client/server settings in the DLE, and happens through 'amfetchdump'. So a good place to start may be extracting your dumps using 'amfetchdump', and examining any problems there. Hopefully someone else can jump in with a solution. What version of Amanda is this? Dustin -- Storage Software Engineer http://www.zmanda.com
Re: No index files being generated - possible freebsd-ism or shell specific issues
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
Re: Encrypted backups on FreeBSD ?
I've been through this but still don't have it working. On the
particular disk entry (backing up with gtar) encryption doesn't run
during amdump. amcheck reports the error:
WARNING: testhost:/disk1/user/srl does not support server data encryption
-Matt
On 4/3/2008 3:56 AM, Dave Ewart wrote:
On Wednesday, 02.04.2008 at 16:54 -0500, Nomad wrote:
I'm having some strange issues as well, trying to do encrypted backups on
FreeBSD. Let me ask this:
1. Is encrypted storage of backups a production feature?
I got this working without too much of a problem.
1. Create a key file and a passphrase as described in 'man amcrypt',
store them in the locations indicated.
2. Use a config such as the following to perform the actual encryption:
define dumptype whatever {
# [... other settings ...]
encrypt server
server_encrypt "/usr/sbin/amcrypt"
}
Dave.
Re: Encrypted backups on FreeBSD ?
On Wednesday, 02.04.2008 at 16:54 -0500, Nomad wrote:
> I'm having some strange issues as well, trying to do encrypted backups on
> FreeBSD. Let me ask this:
>
> 1. Is encrypted storage of backups a production feature?
I got this working without too much of a problem.
1. Create a key file and a passphrase as described in 'man amcrypt',
store them in the locations indicated.
2. Use a config such as the following to perform the actual encryption:
define dumptype whatever {
# [... other settings ...]
encrypt server
server_encrypt "/usr/sbin/amcrypt"
}
Dave.
--
Dave Ewart
[EMAIL PROTECTED]
Computing Manager, Cancer Epidemiology Unit
University of Oxford / Cancer Research UK
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc
N 51.7518, W 1.2016
signature.asc
Description: Digital signature
