gc and encrypted metafiles
ryan at ryanandmorgan.net
Mon Jan 19 14:24:16 UTC 2009
That would be fantastic! There was a thread on this list a few months
back about this exact problem. We discussed 2 different solutions to
1. Moving the decryption code to a shared location and calling it from
both places (your proposed solution).
2. Modifying brackup-target to take a command line switch that tells it
to use local copies of the metadata files (which are not encrypted).
The biggest advantages of #2 are that you don't need to keep private
keys running around and you don't have to prompt for a password which
would enable cron usage. If we do #2, I also propose to modify the
prune operation to remove the local metadata files as well.
If you look back through the archives I think there are some starting
patches posted. I don't know if any more work has been done in this
direction of if anything made it upstream. Can anyone confirm?
Stéphane Alnet wrote:
> I've been using brackup for a while for backup / restore but never
> tried the brackup-target script until tonight. When I tried to do a
> "gc", the script started complaining about invalid lines in the
> metafiles. After inspection it seems that Brackup/Metafile.pm (where
> the problem occurs on line 45) is used by Brackup::Target::gc() but
> without the ad-hoc decryption code found for example in Restore.pm
> ("decrypt_file_if_needed" etc.).
> Am I missing something obvious? Should I attempt to move the
> decryption code in Restore.pm to a separate module so that both
> Restore::new() and Target::gc() can use it? (I don't mind doing the
> work, I just want to make sure I'm looking at the right issue.)
More information about the brackup