LDAP 搬家記：476 條靈魂的大遷徙

Prologue: The Old Server's Ultimatum

Here's the thing: the LDAP server that had been running since roughly the Jurassic period finally issued its resignation. Not the graceful "I've served well, time to pass the torch" kind — more like the hard drive occasionally making clicking noises that roughly translate to "move your data or lose it forever."

And so began the great migration of 476 souls — 398 user accounts, 27 groups, 46 mail aliases, and 4 OUs. Sounds manageable? That's exactly the kind of dangerous optimism LDAP loves to punish.

And after the move, you're hit with an existential question: "What if the new server also dies?" So we didn't just move — we cloned it. Master-Slave replication. One does the work, the other stands by. Perfection.

Part I: The Great Move

Step 1: Packing the Boxes (Data Export)

First things first: pack up everything from the old place. In LDAP-land, your moving truck is ldapsearch and the boxes are called LDIF files.

Make sure the new server has the basics installed:

# Verify slapd is installed and running
dpkg -l slapd ldap-utils
systemctl status slapd

# Install samba (we'll need samba.schema later)
apt-get install -y samba

Then dump everything from the source:

mkdir -p /home/admin/ldap-backup

ldapsearch -x -H ldap://192.168.1.100 \
  -D "cn=admin,dc=example,dc=com" \
  -w your_password \
  -b "dc=example,dc=com" \
  -LLL > /home/admin/ldap-backup/export.ldif

# Verify the export
wc -l /home/admin/ldap-backup/export.ldif
grep -c "^dn:" /home/admin/ldap-backup/export.ldif

So far so good. You might even be thinking "this isn't so bad." Give it a minute.

Step 2: Schema Hell — The Triple Boss Fight

If LDAP migration were an RPG, loading schemas would be the first boss. And this boss has three phases.

Phase 1: Samba Schema

Because our users also need Samba/Windows integration, we need the samba schema loaded. Simple, right? Except OpenLDAP 2.6 uses cn=config for dynamic configuration, so you can't just drop a .schema file in place. Instead, you need to convert it to LDIF format with slaptest, scrub the metadata with a chain of sed commands, and finally ldapadd it in. Because nothing says "fun Friday" like five piped sed commands.

# Copy samba schema
cp /usr/share/doc/samba/examples/LDAP/samba.schema /etc/ldap/schema/

# Convert to cn=config LDIF format
mkdir -p /tmp/samba_schema_ldif
cat > /tmp/samba_schema.conf << 'EOF'
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema
EOF

slaptest -f /tmp/samba_schema.conf -F /tmp/samba_schema_ldif

# Clean up and load
SCHEMA_FILE=$(ls /tmp/samba_schema_ldif/cn=config/cn=schema/ | grep samba)
sed -n '/^dn:/,$ p' /tmp/samba_schema_ldif/cn=config/cn=schema/$SCHEMA_FILE | \
  sed 's/dn: cn={[0-9]*}samba/dn: cn=samba,cn=schema,cn=config/' | \
  sed 's/cn: {[0-9]*}samba/cn: samba/' | \
  grep -vE "^(structuralObjectClass|entryUUID|creatorsName|createTimestamp|entryCSN|modifiersName|modifyTimestamp):" \
  > /tmp/samba_add.ldif

ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/samba_add.ldif

Phase 2: Misc Schema

This one is surprisingly painless. OpenLDAP ships a pre-built LDIF version. One line. Enjoy this rare moment of mercy.

ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/misc.ldif

Phase 3: Custom Schema (Final Boss)

Our directory uses custom attributes — isVPN for VPN access control, maillist for distribution lists, maildrop for mail forwarding. These don't exist in any standard schema, so we get to write our own.

# Custom LDAP Schema

attributetype ( 1.3.6.1.4.1.99999.1.2
    NAME 'mailacceptinggeneralid'
    DESC 'Mail accepting general ID / mail alias name'
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.99999.1.3
    NAME 'maildrop'
    DESC 'Mail drop / forwarding address'
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.99999.1.1
    NAME 'isVPN'
    DESC 'VPN access flag (Y/N)'
    EQUALITY caseIgnoreMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
    SINGLE-VALUE )

objectclass ( 1.3.6.1.4.1.99999.2.2
    NAME 'myorgUser'
    DESC 'Custom user attributes'
    SUP top
    AUXILIARY
    MAY ( isVPN ) )

objectclass ( 1.3.6.1.4.1.99999.2.1
    NAME 'maillist'
    DESC 'Mail distribution list'
    SUP top
    STRUCTURAL
    MUST ( mailacceptinggeneralid )
    MAY ( maildrop $ description $ owner $ cn ) )

Once the schema file is written, it's the same slaptest → sed → ldapadd dance. Congratulations, you're now a sed expert.

mkdir -p /tmp/myorg_schema_ldif
cat > /tmp/myorg_schema.conf << 'EOF'
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/myorg.schema
EOF

slaptest -f /tmp/myorg_schema.conf -F /tmp/myorg_schema_ldif

SCHEMA_FILE=$(ls /tmp/myorg_schema_ldif/cn=config/cn=schema/ | grep myorg)
sed -n '/^dn:/,$ p' /tmp/myorg_schema_ldif/cn=config/cn=schema/$SCHEMA_FILE | \
  sed 's/dn: cn={[0-9]*}myorg/dn: cn=myorg,cn=schema,cn=config/' | \
  sed 's/cn: {[0-9]*}myorg/cn: myorg/' | \
  grep -vE "^(structuralObjectClass|entryUUID|creatorsName|createTimestamp|entryCSN|modifiersName|modifyTimestamp):" \
  > /tmp/myorg_add.ldif

ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/myorg_add.ldif

Step 3: Changing the Address

Fresh slapd installs default to dc=nodomain — yes, OpenLDAP literally starts life as a "John Doe." We need to give it a proper identity and set the admin credentials.

# Generate password hash
PWHASH=$(slappasswd -s your_password)

ldapmodify -Y EXTERNAL -H ldapi:/// << LDIF
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=com
-
replace: olcRootDN
olcRootDN: cn=admin,dc=example,dc=com
-
replace: olcRootPW
olcRootPW: $PWHASH
LDIF

Quick sanity check:

ldapsearch -x -H ldapi:/// -D "cn=admin,dc=example,dc=com" -w your_password \
  -b "dc=example,dc=com" -s base

Step 4: The Great Migration

All systems go. Time to move 476 souls into their new home. The -c flag on ldapadd means "keep going when you hit errors" — and you will hit errors. It's not a question of if, it's when.

# Import all entries (-c = continue on errors)
ldapadd -c -x -H ldapi:/// \
  -D "cn=admin,dc=example,dc=com" \
  -w your_password \
  -f /home/admin/ldap-backup/export.ldif \
  > /tmp/ldap_success.txt 2> /tmp/ldap_errors.txt

# Check results
grep -c "adding" /tmp/ldap_success.txt
grep "^ldap_add:" /tmp/ldap_errors.txt | sort | uniq -c

After the import, you'll notice some users with the isVPN attribute failed. Why? Because the LDIF has isVPN: Y but doesn't declare the myorgUser objectClass. LDAP's logic is basically: "You want to use that attribute? First tell me what species you are."

The fix: a Python script to inject the missing objectClass, then re-import the failures.

python3 << 'PYEOF'
import re

with open('/home/admin/ldap-backup/export.ldif', 'r') as f:
    content = f.read()

entries = re.split(r'\n\n+', content.strip())
failed_entries = []

for entry in entries:
    if 'isVPN:' in entry:
        if 'objectClass: myorgUser' not in entry:
            entry = entry.replace('isVPN:', 'objectClass: myorgUser\nisVPN:')
        failed_entries.append(entry)

with open('/tmp/retry_isvpn.ldif', 'w') as f:
    f.write('\n\n'.join(failed_entries) + '\n')
print(f"Prepared {len(failed_entries)} entries")
PYEOF

ldapadd -c -x -H ldapi:/// -D "cn=admin,dc=example,dc=com" -w your_password \
  -f /tmp/retry_isvpn.ldif

Step 5: Roll Call

After the move, it's time to count heads.

# Total entry count on new server (should be 476)
ldapsearch -x -H ldapi:/// -D "cn=admin,dc=example,dc=com" -w your_password \
  -b "dc=example,dc=com" -z 0 -LLL 2>&1 | grep -c "^dn:"

# Compare with source
ldapsearch -x -H ldap://192.168.1.100 -D "cn=admin,dc=example,dc=com" -w your_password \
  -b "dc=example,dc=com" -z 0 -LLL 2>&1 | grep -c "^dn:"

# Test a user lookup
ldapsearch -x -H ldapi:/// -D "cn=admin,dc=example,dc=com" -w your_password \
  -b "ou=users,dc=example,dc=com" "(uid=alice)" cn mail isVPN

# Test user authentication
ldapsearch -x -H ldapi:/// \
  -D "uid=alice,ou=users,dc=example,dc=com" \
  -w user_password \
  -b "uid=alice,ou=users,dc=example,dc=com" -s base

Numbers match? Users can log in? Great — but don't pop the champagne yet. The move was only the first half. The real fun is just starting.

Part II: The Clone (Master-Slave Replication)

After moving, you'll face an existential crisis: "What if this new server also dies?" After all, you just lived through one server death and the PTSD hasn't faded yet.

The solution: clone it. In OpenLDAP terms, this is called syncrepl — the Master handles all writes, the Slave keeps a real-time copy. Master goes down? Slave takes over. Master stays up? Slave handles read traffic. It's a win-win.

Step 1: Boot Up the Slave

On the Slave machine (192.168.1.201), install slapd and preconfigure the Base DN via debconf:

# Install slapd
DEBIAN_FRONTEND=noninteractive apt-get install -y slapd ldap-utils

# Preconfigure Base DN via debconf
echo "slapd slapd/internal/generated_adminpw password your_password
slapd slapd/internal/adminpw password your_password
slapd slapd/password2 password your_password
slapd slapd/password1 password your_password
slapd slapd/domain string example.com
slapd shared/organization string example
slapd slapd/backend select MDB
slapd slapd/purge_database boolean true
slapd slapd/move_old_database boolean true
slapd slapd/allow_ldap_v2 boolean false
slapd slapd/no_configuration boolean false" | debconf-set-selections

DEBIAN_FRONTEND=noninteractive dpkg-reconfigure slapd

Step 2: Sync the Schemas (Critical!)

Here's the biggest gotcha: the Slave's schemas must exactly match the Master's. If the Master has samba, misc, and custom schemas, the Slave needs all of them loaded before you configure replication. Otherwise, when the Master pushes an entry with sambaSamAccount, the Slave goes: "What species is this? Never heard of it." And the whole replication explodes.

# Copy schema LDIFs to the Slave and load them
ldapadd -Y EXTERNAL -H ldapi:/// -f /home/admin/samba_schema.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /home/admin/misc_schema.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /home/admin/myorg_schema.ldif

(These are the LDIF files produced during the Schema Hell section above. Save them after the migration. Don't ask how I learned this lesson.)

Step 3: Configure syncrepl (Slave Side)

The main event. Tell the Slave: "Your master lives at 192.168.1.200 — stay in sync with it at all times."

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001
  provider=ldap://192.168.1.200
  bindmethod=simple
  binddn="cn=admin,dc=example,dc=com"
  credentials=your_password
  searchbase="dc=example,dc=com"
  scope=sub
  attrs="*,+"
  type=refreshAndPersist
  retry="5 5 300 +"
  interval=00:00:05:00
-
add: olcUpdateRef
olcUpdateRef: ldap://192.168.1.200

Save it as /tmp/syncrepl.ldif and apply:

ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/syncrepl.ldif
systemctl restart slapd
systemctl enable slapd

Key points:

• refreshAndPersist: Real-time push from Master, not periodic polling. Way better than refreshOnly.
• retry="5 5 300 +": On disconnect, retry every 5 seconds (5 times), then every 300 seconds, forever. Like you chasing a deadline.
• olcUpdateRef: If someone accidentally writes to the Slave, it politely redirects to the Master. "Not my department — talk to my boss."

Step 4: Enable Push on the Master

The Slave wanting to sync isn't enough — the Master also needs to enable the syncprov overlay. Think of it like subscribing to a YouTube channel: you hit subscribe, but if the creator hasn't enabled notifications, you won't get updates.

On the Master (192.168.1.200):

# Load syncprov module
ldapmodify -Y EXTERNAL -H ldapi:/// << 'EOF'
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
EOF

# Attach syncprov overlay to the database
ldapmodify -Y EXTERNAL -H ldapi:/// << 'EOF'
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionLog: 100
EOF

olcSpCheckpoint: 100 10 writes a checkpoint every 100 operations or 10 minutes. olcSpSessionLog: 100 keeps the last 100 operations so the Slave can do incremental sync instead of full reloads.

Step 5: Verify the Clone

# Slave entry count
ldapsearch -x -H ldap://192.168.1.201 -b "dc=example,dc=com" \
  "(objectClass=*)" dn | grep "^dn:" | wc -l

# Master entry count
ldapsearch -x -H ldap://192.168.1.200 -D "cn=admin,dc=example,dc=com" -w your_password \
  -b "dc=example,dc=com" "(objectClass=*)" dn | grep "^dn:" | wc -l

Same numbers? Congratulations — clone successful. You now have two LDAP servers. If one dies, the other lives. Sweet dreams tonight.

Troubleshooting Cheat Sheet

If things are truly beyond repair, there's always the nuclear option — wipe the Slave database and let it re-sync from scratch (use with caution):

# Nuclear option: force full re-sync
systemctl stop slapd
rm -f /var/lib/ldap/*.mdb
systemctl start slapd

Lessons Learned

1. Schemas first, data second — Whether migrating or building a Slave, schemas are always gate one. Miss one objectClass and LDAP will reject your entries like a bouncer checking IDs.
2. slaptest + sed is your best friend — The standard pipeline for converting .schema files to cn=config format. Memorize it. And save the resulting LDIFs — the Slave will need them too.
3. Custom attributes need objectClasses — Having an attribute without declaring its objectClass is like trying to board a plane without a passport.
4. ldapadd -c is non-negotiable — Let the import continue on errors, then fix failures afterward. Much better than one error killing the entire job.
5. Slave schemas must match the Master — Load schemas first, then configure syncrepl. Reverse the order and you'll see normalization failed everywhere and question your life choices.
6. refreshAndPersist beats refreshOnly — Real-time push, no polling delay. It's 2026 — don't use cron-style sync.

And one last thing: after the migration, properly decommission that old server. Those clicking hard drive noises? They weren't joking.