Re: Segmentation fault

[Shachar S. <rsy...@sh...>]

al...@ki... wrote:

>Shachar,
>
>Thanks for this..
>
>I love rsync, however the size of my backups now require me to sync my work to 
>a NAS that is accessed by some really dodgy collegues. I needed an app that 
>applies encryption and keeps the directory\file structure. rsyncrypto is it..
>  
>
Shouldn't the NAS be running rsync too for this exercise to mean
anything? If all you are doing is copy between two local folders,
whether one of them mounted remotely or not, then rsync doesn't apply
any of it's special capabilities. There's nothing wrong with that, but
it does mean that rsyncrypto is probably doing an overkill here.

>Both Redhat and Suse did not come with argtable.
>  
>
Yeah, I know.

>post my email I discovered a site that had a simple line:
>"openssl req -x509 -newkey rsa:2048 -keyout key.pem -out req.pem"
>This meant absolutely nothing to me, but I applied it anyway.
>  
>
Yeah, I should really put in the planned "Examples" section in the man
page. Would that have helped you?

>then I applied
>"rsyncrypto -r -c -vv tmp it-nas ./keydir ./req.pem"
>and the backup worked..BUT not without the error\notice "gzip: unrecognized 
>option `--rsyncable'"
>  
>
That's a critical one, and it's an actual error, not a notice. Rsync has
two ways of telling whether a file has changed, and you're only really
using one of them. The one you are using is the comparison of file
timestamps, so that only changed files are synced. This one works
whether both files are mounted locally, or whether it is synching with a
remote machine running rsync as well. The other thing rsync does is to
determine, in a very intelligent way, what changed INSIDE a file.

Rsyncrypto was specifically built so that this second capability is not
lost, even after encryption. Obviously, having a program that compresses
and then encrypts while the encryption keeps changes local is totally
meaningless if the compression does not. That's why rsyncrypto requires
a special version of gzip which was patched to include an option called
"rsyncable". The patch for gzip is available in rsyncrypto's "contrib"
folder. It is planned to get rid of this external dependency, and do the
compression using a library, but that will take a version or two more.

It seems that Suse doesn't have the patched gzip. It was only a couple
of days ago that I learned that Fedora had it, so this is not very
surprising in itself. As you don't require that specific feature of
rsync, there are a couple of things I can suggest to you.
- Either use something other than rsyncrypto for the encryption (as you
do not need rsyncrypto's special encryption mode anyways). or
- Wrap gzip in order to make it work.

Assuming you do want to go with rsyncrypto, here's what I would do. If
you had any use for the rsync friendliness of rsyncrypto, I would have
suggested to you to compile your own gzip. It's not very difficult, but
is really not required for your case. In your case, I would write a
small script that looks like this:
#!/usr/perl/bin

shift;

exec "gzip", @ARGV;

Call it "gzip.pl", and mark it executeable. When you run rsyncrypto
next, just do:

rsyncrypto -r -c -vv --gzip=./gzip.pl tmp it-nas ./keydir ./req.pem

Since you do not require rsync-friendliness, I would also add:
--roll-win=1 --roll-sensitivity=4096

This effectively disables the special rsyncrypto encryption, and leaves
you with standard AES encryption in CBC mode. If you are not using the
special rsync features, there is no reason to carry the risk, small
though it may be.

>Without this I would have given up on the program.
>Someone needs to put a simple example on sourceforge or hundred others are 
>going to experience what I have, and will give in.
>  
>
Could be. Simply out of interest, did you try "man rsyncrypto"?

>The userguide on sourceforge is useless:
>rsyncrypto <plaintext file> <cyphertext file> <key file> <certificate>
>at the time I thought "what the hell is that ??"
>  
>
Quoting from the user guide on sf:

Some of the information in this document is no longer accurate. Please
be sure to read the release notes for version 0.05 before applying the
information presented here to your files.

>Without examples of restoring on the web, I played around with a few commands, 
>trying to understand the logic of the syntax
>
>To simulate a recovery I deleted the tmp folder then performed
>i) rsyncrypto -d -r -c -vv tmp it-nas ./keydir ./req.pem
>this did nothing
>ii) rsyncrypto -d -r -c -vv it-nas tmp ./keydir ./req.pem
>"gzip: stdin: not in gzip format
>Decrypting tmp/test.jpg error: gunzip failed to run:"
>  
>
The problem here, likely, is that after having failed to encrypt due to
passing an unsupported option to gzip, the file does not hold the right
information, and rsyncrypto can't decrypt it. Try using the workaround
discussed above, and see whether things are better.

>I assume rsyncrypto fully works in debian.  I would definately like to see 
>this app work in Suse.
>  
>
I'm hoping the next version will depend less on strange distro-specific
patches.

>cheers
>Shannon
>  
>
       Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html