Majic Projects
Majic Ansible Roles
Go to the previous open issue
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
icon_project.png Majic Ansible Roles / Closed Bug report MAR-116 Changing encryption/signing keys in backup_client role results in Ansible run to fail
Go to the next issue (open or closed)
Go to the next open issue
This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue basics
  • Type of issue
    Bug report
  • Category
    General
  • Targetted for
    Not determined
  • Status
    Closed
  • Progress
  • Priority
    Not determined
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (1)
People involved
Times and dates
  • Posted at
  • Last updated
  • Estimated time
    2 hours
  • Time spent
    No time spent
    Click here to see time logged against this issue
Issue details
  • Resolution
    RESOLVED
  • Reproducability
    Always
  • Severity
    Not determined
Attachments (0)
There is nothing attached to this issue
Duplicate issues (0)
This issue does not have any duplicates
Show / hide more details »
Description

As per documentation for backup_client role, it is possible to provide two types of keys - backup_encryption_key, a private key to be used for both encryption and signing, and backup_additional_encryption_keys - a list of additional public keys to use for encryption.

When replacing the value for two parameters listed above, it is expected that the replacement will be taken care of by the role itself, avoiding manual work on purging and recreating the GnuPG keyring used by duply/duplicity.

However, instead of this, an error happens (see reproduction steps) upon updating the parameter values. The issue was technically discovered while updating Majic Ansible Roles to latest version due to change in newline/spacing due to task syntax updates.

The issue does not happen on Debian Jessie, but does happen on Debian Stretch (which is a supported platform). This is most likely due to differences in GnuPG home directory structure between versions 2.0.x and 2.1.x (where 2.1.x contains directories and not just files).

The following should be done:

  • Update the backup_client role to clean-up both files and sub-directories in /etc/duply/main/gnupg/ when recreating the keyring.
Steps to reproduce this issue

Reproduction steps:

  1. Set-up a Debian Stretch machine using the backup_client role.

  2. Update parameters backup_encryption_key and/or backup_additional_encryption_keys.

  3. Rerun the Ansible playbook.

Expected results:

  1. Rerun replaces the existing keys with new ones.

  2. No errors are reported.

Actual results:

  1. Rerun fails with error:
NOTIFIED: [backup_client | Clean-up GnuPG keyring for import of new keys] ***** 
failed: [machine] => {"changed": true, "cmd": "rm -f /etc/duply/main/gnupg/*", "delta": "0:00:00.034631", "end": "2017-08-13 20:55:23.387129", "rc": 1, "start": "2017-08-13 20:55:23.352498", "warnings": ["Consider using file module with state=absent rather than running rm"]}
stderr: rm: cannot remove '/etc/duply/main/gnupg/private-keys-v1.d': Is a directory
Todos (0 / 0)
Options
Issue created