Re: [Duplicity-talk] Removed .cache dir requires GnuPG passphrase

[Kenneth Loafman]

My first suggestion is an upgrade to 0.6.25.  There have been a lot of fixes since then.

As to getting in sync, you could place the private key on the machine for a short while, let things settle, then remove it, or you could manually decrypt the files from the remote and put them in the cache.

...Ken

On Wed, Dec 10, 2014 at 7:03 AM, Andrew Langhorn <address@hidden> wrote:

From what I can see, it has unencrypted *.manifest and *.sigtar.gz files in two of the directories under ~/.cache/duplicity, but nothing in the remaining two; here's a Gist of the tree: https://gist.github.com/ajlanghorn/1f3c38e362a5d72990af

We're running 0.6.18, which does appear to be a few behind given that the current is 0.6.25. Nothing else, that we're aware of, was deleted with the ~/.cache directory, but at this stage, I suppose it's difficult to tell either way.

Thanks Ken!

On 10 December 2014 at 12:55, Kenneth Loafman <address@hidden> wrote:

Duplicity needs the *.manifest and *.sigtar.gz files to be unencrypted in the local cache.  When syncing the remote to the local, the key is needed in order to decrypt those files back into the cache.  When you look in the cache you should see only those kinds of files.

It sounds like collection-status may be wrong about the sync of the data.  What version of duplicity are you running?  What else was deleted along with the .cache?  Maybe it was something that supplied the password to gpg (has nothing to do with private key).

...Ken

On Wed, Dec 10, 2014 at 6:10 AM, Andrew Langhorn <address@hidden> wrote:

Hi,

Recently, the contents of the ~/.cache directory of the user which some Duplicity jobs run under were removed. Since then, Duplicity backup jobs have failed to run because the GnuPG passphrase is now required. We don't store the private key on this machine, as we only need it to encrypt with the public key - decryption (if required) takes place elsewhere.

From running 'collection-status', there appear to be some orphaned/incomplete backups on the remote, which I think is a new thing - these don't appear to have been there from before we lost `~/.cache`. 'collection-status' reckons that the local cache has been fully synced from the remote metadata.

I don't want to pass the private key in to Duplicity to get this working, but I don't know how to get over this hurdle.

Help?!

Thanks! :)

--

Andrew Langhorn

Web Operations

Government Digital Service

e: address@hidden

t: +44 (0)7810 737375

a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

--

Andrew Langhorn

Web Operations

Government Digital Service

e: address@hidden

t: +44 (0)7810 737375

a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk