Restore the Dogtag server files and database

Restore the Dogtag server files and databaseΒΆ

After you complete the Back up the Dogtag server files and database procedure, you can perform the Dogtag restore.

Note

  • The Dogtag restore procedure is available starting from the 2019.2.11 maintenance update.
  • If Dogtag restore has been already performed on your cluster, first delete the .dogtag_restored file in /etc/salt.

To restore the Dogtag server files and database:

  1. Verify that you have completed the steps described in Prepare for the Dogtag backup and restore.

  2. Select from the following options:

    • Restore Dogtag files and database automatically as described in Restore the services using Backupninja pipeline.

    • Restore Dogtag files and database manually:

      1. Log in to the Salt Master node.

      2. In cluster/openstack/barbican.yml, configure the following pillar:

        parameters:
          dogtag:
            server:
              initial_data:
                engine: rsync
                source: ${_param:backupninja_backup_host}
                host: ${_param:openstack_barbican_node01_hostname}.${_param:cluster_domain}
                home_dir: '/path/to/backups/' # defaults to '/srv/volumes/backup/backupninja' if not defined
        
      3. Stop the database service on secondary nodes to temporarily disable replication:

        salt -C 'I@dogtag:server:role:slave' service.stop 'dirsrv@pki-tomcat.service'
        
      4. Apply the restore state.

        Mirantis recommends running the following command using Linux GNU Screen or alternatives.

        salt -C 'I@dogtag:server:role:master' state.sls dogtag.server.restore
        
      5. Start the database service on secondary nodes to enable replication:

        salt -C 'I@dogtag:server:role:slave' service.start 'dirsrv@pki-tomcat.service'
        
      6. Verify that all services are running:

        salt -C 'I@dogtag:server' service.status "dirsrv@pki-tomcat.service"
        

        Expected system response:

        kmn02.example.domain.local:
          True
        kmn03.example.domain.local:
          True
        kmn01.example.domain.local:
          True
        
      7. Apply the states below in the following strict order:

        salt -C 'I@salt:master' state.sls salt,reclass
        salt -C 'I@dogtag:server and *01*' state.sls dogtag.server
        salt -C 'I@dogtag:server' state.sls dogtag.server
        salt -C 'I@haproxy:proxy' state.sls haproxy
        salt -C 'I@barbican:server and *01*' state.sls barbican.server
        salt -C 'I@barbican:server' state.sls barbican.server
        salt -C 'I@barbican:server' cmd.run "rm /etc/barbican/alias/*"
        salt -C 'I@barbican:server' service.restart apache2
        

        If the barbican.server state fails with the "Rendering SLS 'base:barbican.server' failed: Jinja variable 'dict object' has no attribute 'key'" error that may occur, for example, due to the mine data deletion after calling the mine.flush function:

        1. Obtain the Dogtag certificate location:

          salt -C 'I@dogtag:server:role:master' pillar.get dogtag:server:export_pem_file_path
          

          Example of system response:

          /etc/dogtag/kra_admin_cert.pem
          
        2. Apply the following state:

          Note

          In the state below, substitute the certificate path with the one you obtained in the previous step.

          salt -C 'I@dogtag:server:role:master' mine.send dogtag_admin_cert \
          mine_function=cmd.run 'cat /etc/dogtag/kra_admin_cert.pem'
          
        3. Rerun the failed Barbican state.