Belajar LDAP - Troubleshooting

#Pendahuluan

Di episode 26 kalian membangun high availability agar kegagalan node tidak terasa. Episode 27 ini membahas apa yang harus kalian lakukan saat tetap terjadi masalah: troubleshooting LDAP. Metodologinya sama seperti debugging sistem lain — mulai dari gejala, baca log, persempit cakupan, lalu perbaiki akar penyebabnya. Kalian akan belajar katalog masalah umum, teknik debugging dengan level debug dan packet capture, alat bantu seperti slaptest dan cn=Monitor, serta cara menyembuhkan replikasi yang macet.

#Masalah Umum dan Penyebabnya

Sebagian besar insiden LDAP jatuh ke enam kategori ini. Kenali polanya:

Gejala	Penyebab umum	Langkah perbaikan
Connection refused	slapd tidak jalan, port salah, firewall	Cek status service, `ss -tlnp`, dan firewall
Invalid credentials	DN atau password salah, bind anonim dibatasi	Verifikasi dengan `ldapwhoami`, cek `olcRootDN`
Search lambat	Filter memakai atribut tanpa indeks	Tambah `olcDbIndex`, lalu `slapindex`
Replication lag	Jaringan lambat, konfigurasi syncrepl salah	Bandingkan `contextCSN`, cek log sync
Schema violation	Atribut atau objectClass belum ada di schema	Periksa `cn=schema,cn=config`
Constraint violation	Dilanggar oleh ppolicy atau overlay lain	Tinjau overlay `ppolicy` dan `unique`

Baris pertama adalah yang paling sering muncul. Sebelum menyalahkan konfigurasi LDAP, pastikan prosesnya hidup, port 389 atau 636 terbuka, dan tidak ada aturan firewall yang memblokir. Gunakan ss -tlnp | grep :389 untuk memastikan slapd benar-benar mendengarkan.

#Teknik Debugging

Mulai dari yang paling tidak invasif: log. Naikkan level log slapd agar peristiwa yang relevan tercatat:

stats mencatat operasi dasar, acl mencatat evaluasi ACL (penting saat akses ditolak), dan sync mencatat aktivitas replikasi. Di production, jangan biarkan level di atas stats menetap — log yang terlalu detail menjadi beban I/O tersendiri.

Untuk melihat apa yang sebenarnya dikirim klien, pakai level debug pada ldapsearch:

Debug pencarian dari sisi klien

ldapsearch -d 5 -x -b "ou=people,dc=example,dc=com" "(uid=budi)"

ldapsearch -d 5 menampilkan detail koneksi, pembacaan konfigurasi, dan hasil parse filter — berguna saat klien berperilaku tidak sesuai harapan. Di sisi server, jalankan slapd di foreground dengan level debug untuk melihat alur lengkap:

Menjalankan slapd di foreground dengan level debug

slapd -d stats -u openldap -g openldap

Untuk masalah jaringan, gunakan tcpdump:

Menangkap traffic LDAP

tcpdump -i any -s 0 -A port 389

Ingat: bila kalian memakai TLS di port 636, isi paket sudah terenkripsi — tcpdump hanya akan menunjukkan koneksi terjadi, bukan payload-nya. Untuk inspeksi payload secara visual, Wireshark dengan de-koder LDAP adalah pilihan yang lebih nyaman.

#Alat Bantu Troubleshooting

slapd -Tt — uji konfigurasi tanpa menjalankan server. Menangkap kesalahan sintaks sebelum crash di production:

Validasi konfigurasi slapd

slapd -Tt

slapcat -o ldif-wrap=no -n 0 — dump konfigurasi cn=config untuk diperiksa baris per baris. Format tanpa wrap memudahkan mencari direktif tertentu.
cn=Monitor — penghitung operasi dan status internal. ldapsearch langsung ke branch monitor:

Cek penghitung operasi di cn=Monitor

ldapsearch -x -b "cn=Operations,cn=Monitor" -s base

ldapwhoami — memverifikasi identitas bind yang sebenarnya. Ini cara tercepat memastikan DN dan credential yang dipakai klien benar:

Memverifikasi identitas bind

ldapwhoami -x -D "cn=admin,dc=example,dc=com" -W

#Masalah Performa

Saat directory terasa lambat, pisahkan dulu keempat bottleneck:

Slow searches — hampir selalu indeks yang hilang. Cek filter di log, lihat atribut yang dipakai, bandingkan dengan daftar olcDbIndex, lalu rebuild.
High CPU — full scan akibat filter tak terindeks, atau olcThreads yang terlalu besar sehingga banyak thread berebut lock. Kurangi beban pencarian liar dulu, baru kurangi thread.
Memory exhaustion — olcDbCacheSize terlalu besar, atau aplikasi membuka banyak koneksi tak terbatas. Batasi dengan olcConnMaxPending dan sesuaikan cache dengan RAM nyata.
Disk I/O bottleneck — cache terlalu kecil sehingga banyak baca dari disk, atau level log terlalu detail. Naikkan cache, turunkan loglevel ke stats.

#Troubleshooting Replikasi

Replikasi macet adalah masalah paling sulit karena gejala muncul di dua sisi. Mulai dari membandingkan contextCSN:

Cek contextCSN di provider dan consumer

ldapsearch -x -LLL -s base -b "" contextCSN

contextCSN yang tertinggal jauh di consumer berarti perubahan belum tersinkron. Penyebab umum: koneksi replikasi terputus dan retry tidak berjalan, credential replikasi berubah, atau schemachecking menolak entry baru. Periksa log dengan loglevel sync untuk melihat pesan seperti conn=... do_syncrep_update atau kegagalan ldap_result.

Bila perubahan konfigurasi di consumer tidak menyelesaikan masalah, lakukan sinkronisasi manual: dump dari provider dengan slapcat, restore ke consumer dengan slapadd (server berhenti), lalu mulai lagi — syncrepl akan menyambung dari contextCSN yang baru. Untuk konflik pada mirror mode, OpenLDAP menyelesaikan berdasarkan contextCSN: entry dengan timestamp terbaru menang. Hindari menulis ke dua node untuk entry yang sama dalam waktu bersamaan, karena itu menciptakan konflik yang tidak nyaman untuk diselesaikan.

Important

Sebelum mengubah konfigurasi saat menangani masalah, selalu buat dulu salinan konfigurasi: slapcat -o ldif-wrap=no -n 0 > /tmp/config-before.ldif. Satu kesalahan ACL atau typos pada olcDbIndex bisa membuat slapd menolak start — dan tanpa backup, jalan keluarnya menjadi berantakan.

Tip

Masalah "bisa di terminal tapi gagal dari aplikasi" hampir selalu berasal dari perbedaan konfigurasi klien: CA yang tidak dikenali, URI yang salah, atau credential yang berbeda. Bandingkan /etc/ldap/ldap.conf aplikasi dengan yang dipakai ldapsearch kalian.

#Penutup

Pada episode 27 ini, kalian memetakan masalah umum ke penyebab dan perbaikannya, menggunakan level debug di klien dan server, memakai tcpdump dan Wireshark, memanfaatkan slapd -Tt, slapcat -o, dan cn=Monitor, serta mendiagnosis masalah performa dan replikasi hingga sinkronisasi manual.

Inti yang harus dibawa pulang:

Baca log sebelum mengubah konfigurasi — log stats, acl, dan sync menjawab sebagian besar kasus.
ldapsearch -d 5 di klien dan slapd -d stats di server mempersempit titik masalah.
Pencarian lambat hampir selalu berarti indeks hilang.
Untuk replikasi, bandingkan contextCSN dulu, baru resync manual.

Di episode 28 berikutnya, kita meninjau fondasi yang membuat semua troubleshooting di atas lebih jarang terjadi: schema design best practices — merancang DIT yang sehat, memilih object class yang tepat, dan menghindari antipattern yang menyesatkan.