Backup/restore actions for EasyRSA.

[castrojo]

We should consider adding actions for backing up and restoring certificates from EasyRSA so people don't need to manually scp things back and forth.

[mbruzek]

I am all for adding this feature to the charm!

It is not clear to me if EasyRSA supports backup/restore, or how to properly do this. EasyRSA creates a "database" and I ran into some problems with when trying to manipulate CA certificates and keys manually.

More investigation is needed. https://github.com/OpenVPN/easy-rsa

[chuckbutler]

Adding addendum by duplicated issue 222

We'd need an ability to export the PKI root from easyrsa - and re-import it. I suggest the following workflow.

juju run-action easyrsa/0 backup gpg-key=<key_id>

This will create a backup and GPG encrypt that payload which will have the PKI bits inside. The action output will present the user with the SCP command to copy down.

For restoring, the user can decrypt the payload on disk and use

juju attach easyrsa pki=backup.tar.xz

This will trigger a hook run to unpack the PKI infrastructure then re-generate and redistribute certs to all relations.

This will also provide a path forward to "bring your own PKI"

[hansbogert]

the charm keeps its own state in the charm's state database for at least the CA certificate as far as I can see. This bit me when I tried to manually move the pki database to another node, but it had no effect
Why doesn't it look in pki/ directory?

/update
Is this really used by canonical in production environments? There's no disaster recovery option, unless you get really down & dirty with altering the charm's database.

/update2
Maybe this is already known, but I couldn't find this anywhere else, but you can manually backup and redeploy:

1. backup your pki folder
2. Remove easyrsa unit
3. Add easyrsa unit
4. Let the deploy achieve a steady state.
5. Remove the pki directory in /var/lib/juju/agents/*easyrsa*/charm/EasyRSA/pki
6. copy your backup pki folder to /var/lib/juju/agents/*easyrsa*/charm/pki (not the same location as above in point 5 !)
7. Remove /var/lib/juju/agents/*easyrsa*/charm/.unit-state.db
8. Restart through systemctl
9. The charm will deploy your pki/ folder.
   You can deploy you easyrsa, wait for steady state

[tvansteenburgh]

@hansbogert Thanks for documenting these steps. For 7, do you mean you reboot the unit?

[hansbogert]

@tvansteenburgh No, simply a systemctl restart jujud*easyrsa*

[hansbogert]

Okay, I tried it another time and I can now say that the following commands actually work:

# Login to  node with current easyrsa:
juju ssh 1
  sudo cp -a /var/lib/juju/agents/unit-easyrsa-5/charm/EasyRSA/pki ~/
  # chown to ubuntu so we can read this later on from the juju-client machine with `juju scp`
  sudo chown -R ubuntu:ubuntu pki/
  # Logout
# Get pki folder to juju client
juju scp -- -r   1:pki/ ~/juju/
# Remove old easyrsa unit
juju remove-unit easyrsa/5
# Add new easyrsa unit
juju add-unit easyrsa --to 0
juju scp -- -r   ~/juju/pki   0:pki
juju ssh easyrsa/6
  sudo systemctl stop jujud-unit-easyrsa-6.service 
  sudo rm -rf /var/lib/juju/agents/unit-easyrsa-6/charm/EasyRSA/pki/
  sudo cp -a pki /var/lib/juju/agents/unit-easyrsa-6/charm/
  sudo rm -rf /var/lib/juju/agents/unit-easyrsa-6/charm/.unit-state.db
  cd /var/lib/juju/agents/unit-easyrsa-6/charm/
  # Magic be here. This will skip the recreation of a new pki.
  sudo charms.reactive set_state easyrsa.certificate.authority.available
  sudo systemctl restart jujud-unit-easyrsa-6.service 

/update

Okay.. this also doesn´t work. The above assumes that the upgrade mechanisms would actually work in the charm, but as far as I can tell, that also wouldn´t work, and would actually not copy over your PKI folder. You would be left with pretty blank pki/ folder. It wouldn't be a problem functionally in the case of an upgrade, because the unit-state.db would still have the keys and certificates.

To test if I'm right, how can I test an upgrade process, without actually having a new charm?