...
- Pre-requisites: having a backup of the VM in question done following this article: Backup your instance
- Restoring a backup to a different new VM will break the LDAP configuration of both the original and the new VM .(generally only an issue on EUMETSAT tenancies where LDAP is provided by default)
- This happens because the VM is a clone of the original with all of its configuration, including LDAP, but the original is still there
- We will see in this article how to repair the LDAP configurations
...
Repairing the LDAP configurations after restoring the backup
| Info |
|---|
This section mainly applies to EUMETSAT tenancies where LDAP is provided by default. Some ECMWF tenancies may also use LDAP by opt-in. |
Right after we restore the backup we are going to have this situation:
- the new VM in failed state
- the original VM apparently fine, but the DNS records in LDAP will be misconfigured (two records will exist in a round-robin configuration), preventing us from repairing the LDAP config in the new VM
Example: in the screenshot below the original VM is backup-test-01 and backup-test-02 is a new VM restored from a backup of the first one:
In order top to fix this, we need to repair the original VM first, we can do that by clicking on the original VM, then ACTIONS → Run Workflow, that will show the dialog below where we should choose Enroll VM to LDAP. This will re-do the LDAP configuration, which deletes the now-corrupted LDAP information on the server and recreates it fresh.
After that, to verify that everything worked fine, we should be able to see an item in the VM history like this:
...
To work around that, you can simply click on ACTIONS → Restart Server. This will clear the failure flag.
Once the VM is up and Running again, you will be able to execute the Enroll VM to LDAP workflow in the same way you did for the original VM. As a new VM, it must have a new and unique hostname and this will be registered in LDAP.