This feed contains pages with tag "gpg".
It seems kind of unfair, given the name, but duplicity really doesn't like to be run in parallel. This means that some naive admin (not me of course, but uh, this guy I know ;) ) who writes a crontab
@daily duplicity incr $ARGS $SRC $DEST @weekly duplicity full $ARGS $SRC $DEST
is in for a nasty surprise when both fire at the same time. In particular one of them will terminate with the not very helpful.
AttributeError: BackupChain instance has no attribute 'archive_dir'
After some preliminary reading of mailing list archives, I decided to
~/.cache/duplicity on the client and try again. This was
not a good move.
- It didn't fix the problem
- Resyncing from the server required decrypting some information, which required access to the gpg private key.
Now for me, one of the main motivations for using duplicity was that I could encrypt to a key without having the private key accessible. Luckily the following crazy hack works.
A host where the gpg private key is accessible, delete the
~/.cache/duplicity, and perform some arbitrary duplicity operation. I did
duplicity clean $DEST
UPDATE: for this hack to work, at least with s3 backend, you need to specifify the same arguments. In particular omitting --s3-use-new-style will cause mysterious failures. Also, --use-agent may help.
- Now rsync the ./duplicity/cache directory to the backup client.
Now at first you will be depressed, because the problem isn't fixed yet. What you need to do is go onto the backup server (in my case Amazon s3) and delete one of the backups (in my case, the incremental one). Of course, if you are the kind of reader who skips to the end, probably just doing this will fix the problem and you can avoid the hijinks.
And, uh, some kind of locking would probably be a good plan... For now I just stagger the cron jobs.
What is it?
I was a bit daunted by the number of mails from people signing my gpg keys at debconf, so I wrote a script to mass process them. The workflow, for those of you using notmuch is as follows:
$ notmuch show --format=mbox tag:keysign > sigs.mbox $ ffac sigs.mbox
where previously I have tagged keysigning emails as "keysign" if I want to import them. You also need to run gpg-agent, since I was too lazy/scared to deal with passphrases.
This will import them into a keyring in
~/.ffac; uploading is still
manual using something like
$ gpg --homedir=$HOME/.ffac --send-keys $keyid
UPDATE Before you upload all of those shiny signatures, you might
want to use the included script
fetch-sig-keys to add the
corresponding keys to the temporary keyring in
$ fetch-sig-keys $keyid
$ gpg --homedir ~/.ffac --list-sigs $keyid
should have a UID associated with each signature.
How do I use it
At the moment this is has been tested once or twice by one
person. More testing would be great, but be warned this is pre-release
software until you can install it with
Get the script from
$ git clone git://pivot.cs.unb.ca/git/ffac.git
Get a patched version of Mail::GnuPG that supports
gpg-agent; hopefully this will make it upstream, but for now,
$ git clone git://pivot.cs.unb.ca/git/mail-gnupg.git
I have a patched version of the debian package that I could make available if there was interest.
Install the other dependencies.
# apt-get install libmime-parser-perl libemail-folder-perl
2011/07/29 libmail-gnupg-perl in Debian supports gpg-agent for some time now.
So I had this brainstorm that I could get sticky labels approximately the right size and paste current gpg key info to the back of business cards. I played with glabels for a bit, but we didn't get along. I decided to hack something up based on the gpg-key2ps script in the signing-party package. I'm not proud of the current state; it is hard-coded for one particular kind of labels I have on my desk, but it should be easy to polish if anyone thinks this is and idea worth pursuing. The output looks like this. Note that the boxes are just for debugging.