LDAP Service Failure After VM Snapshot – Configuration Mismatch Resolution

Environment

Background

Recently I was asked to help troubleshoot an LDAP service that wasn't starting on a newly created VM. The VM in question, SNAP-198, was a snapshot of our Pre-Release server, spun up to test something in isolation — hence the name. Sounds straightforward — but as soon as the snapshot was booted, LDAP was in a failed state.

The Problem

The issue was a classic snapshot trap. When you snapshot a running server, the new VM inherits everything — including the source server's identity. LDAP is particularly sensitive to this because it uses its own hostname to identify itself in the configuration.

The errors in the logs made it clear:

1daemon: bind() failed errno=99 (Cannot assign requested address)
2read_config: no serverID / URL match found

LDAP was trying to bind to an address that didn't exist on this new server, and couldn't match its own identity in the config.

Root Causes

After digging in, there were four things that needed fixing:

• SLAPD_URLS still referencing the Pre-Release server hostname
• olcServerID in the LDAP config still pointing to the Pre-Release server
• SNAP-198's hostname resolving to 127.0.0.1 (loopback) instead of its actual public IP
• Replication config still pointing back to Pre-Release — not needed since SNAP-198 is a standalone server

The Fix

1. Update SLAPD URLs — /etc/sysconfig/slapd

1sudo vim /etc/sysconfig/slapd

1SLAPD_URLS="ldapi:/// ldap://SNAP-198 ldap://localhost"

2. Fix /etc/hosts

Remove the loopback entry for the hostname and map it to the actual public IP:

1sudo vim /etc/hosts

1<public-ip> SNAP-198 SNAP-198

3. Fix olcServerID

This is where it got interesting. The right way to modify LDAP config is through ldapmodify — the config files explicitly say do not edit directly. So I prepared the ldif file and tried to apply it:

1sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/fix_serverid.ldif

But this failed immediately — ldapmodify requires slapd to be running, and slapd wouldn't start because of the bad config. A classic chicken and egg situation.

The only way out was to edit the config file directly and manually recalculate the CRC32 checksum that OpenLDAP uses to validate the file:

1sudo vim /etc/openldap/slapd.d/cn=config.ldif

Change:

1olcServerID: 0 ldap://Pre-Release
2olcServerID: 1 ldap://Other-Server

To:

1olcServerID: 0 ldap://SNAP-198

Then recalculate the CRC32:

1sudo python3 -c "
2import binascii
3with open('/etc/openldap/slapd.d/cn=config.ldif', 'r') as f:
4    lines = f.readlines()
5content = ''.join(lines[2:])
6crc = binascii.crc32(content.encode()) & 0xffffffff
7print(f'{crc:08x}')
8"

Update the # CRC32 <value> line at the top of the file with the new value.

4. Remove Replication Config

Now that slapd was up, I could use ldapmodify properly to remove the unwanted replication entries.

Create the ldif files:

1sudo vim /tmp/fix_config_syncrepl.ldif

1dn: olcDatabase={0}config,cn=config
2changetype: modify
3delete: olcSyncrepl

1sudo vim /tmp/fix_mdb_syncrepl.ldif

1dn: olcDatabase={1}mdb,cn=config
2changetype: modify
3delete: olcSyncrepl

Apply both:

1sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/fix_config_syncrepl.ldif
2sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/fix_mdb_syncrepl.ldif

Verification

1sudo systemctl restart slapd
2sudo systemctl status slapd
3sudo grep -r "olcSyncrepl" /etc/openldap/slapd.d/

No output on the last command — SNAP-198 is now running as a fully standalone LDAP server with no dependency on Pre-Release.

Key Takeaway

When creating a VM snapshot from a running LDAP server, always update the server identity configuration before starting LDAP. The config doesn't just hold data — it holds the server's identity, and LDAP will refuse to start if that identity doesn't match the environment it's running in.