The problem ----------- I want to copy a file from machine A (master) to machine B (backup) but I would like to stop root user on machine B to easily look at the file contents. So I encrypt the file to send at machine A and send just the encrypted version to machine B (which has no means to decrypt the file). Then I make a small change in the file in the machine A and want to send the new version to machine B. If I simply repeat the procedure (encrypt at A and rsync with B) I lose the rsync advantages, since a local change in the raw file leads to a global change in the encrypted file. The solution? ------------- Maybe I can split the raw file at A in several parts, encrypt them separately and send them as separated files to B, along with info on how to rebuild the file from the *decrypted* parts (remember, B doesn't know how to decrypt). The problem then would be to keep at A a record of the parts sent do B, in order to decide how to split the file the next time A wants to send it to B (the spliting is not trivial, since the parts must be equal to those already at B if possible). So eventually I finish using the rsync algorythm, not to do the final copy of files from A to B, but to do the splitting of the raw file at A into parts. I just need to build an auxiliary file with info on how to join the parts, instead of the parts already joined. The questions ------------- Can rsync do the spliting and build info on how to join instead of joining? Does anyone have this kind of problem? Has the problem an easier solution? Am I missing something? Thanks, Sebrosa
Why not rsync to a system where you are the root user? On Wed, Oct 10, 2001 at 08:27:35PM +0100, Jose' Sebrosa wrote:> > The problem > ----------- > > I want to copy a file from machine A (master) to machine B (backup) but I would > like to stop root user on machine B to easily look at the file contents. So I > encrypt the file to send at machine A and send just the encrypted version to > machine B (which has no means to decrypt the file). > > Then I make a small change in the file in the machine A and want to send the > new version to machine B. If I simply repeat the procedure (encrypt at A and > rsync with B) I lose the rsync advantages, since a local change in the raw file > leads to a global change in the encrypted file. > > > The solution? > ------------- > > Maybe I can split the raw file at A in several parts, encrypt them separately > and send them as separated files to B, along with info on how to rebuild the > file from the *decrypted* parts (remember, B doesn't know how to decrypt). The > problem then would be to keep at A a record of the parts sent do B, in order to > decide how to split the file the next time A wants to send it to B (the > spliting is not trivial, since the parts must be equal to those already at B if > possible). > > So eventually I finish using the rsync algorythm, not to do the final copy of > files from A to B, but to do the splitting of the raw file at A into parts. I > just need to build an auxiliary file with info on how to join the parts, > instead of the parts already joined. > > > The questions > ------------- > > Can rsync do the spliting and build info on how to join instead of joining? > Does anyone have this kind of problem? > Has the problem an easier solution? > Am I missing something? > > Thanks, > Sebrosa >
How about using something like the Cryptographic File System (CFS), where the files are stored encrypted locally, and the encryption is confined to blocks. This is done to make the encrypted files random-addressable in the CFS implementation, but a consequence it seems to me is that at least some changes might still rsync efficiently. Or maybe you'd be better off using CFS to a mirrored drive, where one half of the mirror is a network block device provided from the far end. -Bennett -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20011010/f7a8d4ae/attachment.bin