On 11 Feb 2009, at 11:23 pm, Andreas Rottmann wrote:
Hi! I'm considering switching to ugarit (from a home-made C program driving afio/tar/gpg) for my backup needs (a few Linux boxes), and would really appreciate: - GPG support (e.g. generate a random AES key/IV, and store it, encrypted via GPG, in the archive). This would do away with the need to store the AES key in plaintext in a config file.
True, but there'd need to be something *equivalent* to the AES key still in the config file, even if that is just details of where to find a GPG key that can decrypt an AES key stored in the archive... ...would you prefer an option to prompt for a key on the console when opening an archive? (I already have a plan for plaintext passphrases, I just need to figure out a nice way to make 256-bit ones - Tiger hashes will produce 128 or 192 bit keys from passphrases, but not 256-bit ones).
- .ugarit-ignore file support (as already on the list of planned features); this is in fact the itch I scratched with my custom-made backup tool, as I couldn't find a backup solution that offered that feature.
Yeah! I'm mulling that a bit after a conversation that came up with Peter Bex on IRC. My original idea was just to make it an ignore file, to not archive certain things. But Peter raised the idea of filters such as magically archiving an SVN repository as just a file that's the result of an "svnadmin dump" on the repository and before/after commands, such as checkpointing a database before dumping it. However, such tricks would depend on being able to trust the rule files, while just supporting 'ignore' wouldn't; even if you run the commands as the UID of the user owning the rules file, they could fail to terminate and thus halt the snapshot. So my current thinking is to have "dangerous" and "safe" operations in the rules files, and dangerous operations would only be performed if the rules file was owned by a user in a trusted list, which defaults to the UID that ran ugarit. Dangerous operations would, in general, involve running an arbitrary wrapper closure to handle the object that matched, with procedures provided in the namespace that create closures to provide filtering and before/after shell command execution, with some support (to be determined) for running the commands as specified users (just punt that job to sudo?). For now, though, I can proceed with basic ignore functionality, but I'll need to leave my options open for the more advanced stuff :-)
Keep up the good work!
;-)
Regards, Rotty
ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
