Tag: troubleshoot

  • Mengatasi Gagal Menambahkan Host KVM di CloudStack

    Mengatasi Gagal Menambahkan Host KVM di CloudStack

    Saat testing CloudStack 4.23 di Rocky Linux 9.8, saya mengalami kendala ketika menambahkan host KVM melalui menu Add Host. Prosesnya gagal dengan pesan berikut:

    Unable to add the host: 
    Cannot find the server resources at http://192.168.14.9

    Salah satu konfigurasi yang perlu diperiksa adalah alamat Management Server pada file agent.properties. Untuk penyesuaian ini, alamat tersebut diarahkan menggunakan IP Management Server.

    1. Periksa konfigurasi agent

    Jalankan pada host KVM:

    grep '^host=' /etc/cloudstack/agent/agent.properties

    Parameter host berisi alamat Management Server yang dituju oleh CloudStack Agent. Jadi, nilainya harus mengarah ke Management Server yang dapat dijangkau dari host KVM.

    Jika sebelumnya menggunakan hostname, pastikan hostname tersebut mengarah ke IP yang benar. Penggunaan IP langsung dapat menghindari ketergantungan pada resolusi hostname untuk alamat ini.

    2. Ubah menjadi IP Management Server

    Backup konfigurasi terlebih dahulu:

    cp -a /etc/cloudstack/agent/agent.properties \
      /etc/cloudstack/agent/agent.properties.bak

    Kemudian buka file:

    vi /etc/cloudstack/agent/agent.properties

    Cari parameter host, lalu sesuaikan:

    host=192.168.14.9

    Contoh tersebut berlaku jika Management Server berada di 192.168.14.9. Jika Management Server dan KVM menggunakan server berbeda, isi dengan IP Management Server, bukan IP host KVM. Tulis IP tanpa awalan http://.

    3. Restart CloudStack Agent

    Setelah disimpan, restart layanan:

    systemctl restart cloudstack-agent
    systemctl status cloudstack-agent

    Periksa log agent:

    tail -n 100 /var/log/cloudstack/agent/agent.log

    Periksa kembali apakah masih ada error koneksi pada log.

    4. Periksa kembali melalui dashboard

    Kembali ke halaman Hosts dan refresh. Jika host sudah terdaftar, periksa apakah statusnya Up. Jika belum, coba kembali Add Host.

    Jika penyesuaian IP belum menyelesaikan kendala, lanjutkan pemeriksaan log agent dan Management Server untuk mencari penyebabnya.

    Dokumentasi: Konfigurasi agent.properties — Apache CloudStack

  • Error “No destination found” CloudStack: Cek CPU, Offering, dan Storage

    Error “No destination found” CloudStack: Cek CPU, Offering, dan Storage

    Saat menguji Apache CloudStack dengan KVM, saya menaikkan overprovisioning CPU dan RAM untuk menguji agar lab dapat menjalankan lebih banyak instance. Namun, beberapa kali pembuatan instance tetap gagal dengan error

    No destination found for a deployment for VM instance.

    Error ini belum menunjukkan penyebab pastinya. Dalam pengujian saya, ada tiga pengaturan yang saya periksa setelah konsultasi denga AI:

    Log management-server.logTindakan
    No clusters found having a host with enough capacityPeriksa faktor CPU dan RAM pada cluster.
    disk profile does not use local storage atau No storage pools available for [shared]Pilih offering untuk ROOT disk yang menggunakan Local Storage.
    allocated percentage ... crossed ... 0.85Periksa batas alokasi storage pada zone.

    1. Periksa faktor CPU dan RAM

    • Buka Infrastructure → Clusters → pilih cluster → Settings,
    • Cari pengaturan overprovisioning.
    • Ubah cpu.overprovisioning.factor dan mem.overprovisioning.factor
    • Dalam lab ini, saya memakai:
    CPU Overprovisioning Factor    = 10
    Memory Overprovisioning Factor = 10

    Faktor 10 hanya untuk pengujian, bukan rekomendasi production. Overprovisioning memperbesar kapasitas yang dihitung CloudStack, bukan CPU atau RAM fisik. Pada KVM, faktor memory juga dapat memengaruhi memori minimum saat guest mulai berjalan. Periksa kapasitas host dan memori yang tersedia di guest setelah perubahan.

    2. Sesuaikan Storage Type untuk ROOT disk

    Pada kasus lain, CPU dan RAM sudah lolos, tetapi log menampilkan

    No storage pools available for [shared] volume allocation.

    Ternyata offering yang dipakai meminta Shared Storage, sedangkan lab menggunakan Local Storage.

    • Buka Service Offerings → Compute Offerings.
    • Periksa pengaturan ROOT disk atau Disk Offering yang ditautkan, lalu pilih Storage Type: Local.

    Jika offering yang digunakan tidak dapat disesuaikan, buat offering baru dengan tipe Local dan pilih saat membuat instance.

    3. Periksa batas alokasi storage

    CPU, RAM, dan tipe storage sudah sesuai, tetapi ROOT disk 20 GB masih ditolak. Log menunjukkan alokasi sebelumnya 65.77 GB; jika ditambah 20 GB, totalnya 85.77 GB dari kapasitas hasil overprovisioning 95.85 GB:

    85.77 / 95.85 ≈ 89.48%
    Batas allocated storage = 85% (0.85)

    Untuk pengujian:

    • Buka Infrastructure → Zones → pilih zone → Settings,
    • Cari bagian pool.storage.allocated.capacity.disablethreshold.
    • Jika ruang fisik masih cukup, sesuaikan batasnya, misalnya dari 0.85 menjadi 0.95.

    Menaikkan batas ini tidak menambah kapasitas disk fisik. Tetap pantau ruang kosong filesystem host, terutama ketika storage juga di-overprovision. Jika diperlukan, faktor overprovisioning storage dapat ditinjau secara terpisah.

    Saat error muncul lagi

    Jangan langsung menaikkan faktor CPU dan RAM. Cari petunjuk sebelum baris No destination found pada log management server:

    tail -f /var/log/cloudstack/management/management-server.log

    Periksa menggunakan UUID Instance:

    grep -i "<UUID-INSTANCE>" /var/log/cloudstack/management/management-server.log

    Intinya: pastikan compute capacity cukup, ROOT disk meminta tipe storage yang tersedia, dan alokasinya belum melewati batas pool.

    Referensi

  • Mengatasi Error SSH Key CloudStack saat Menambahkan Host KVM

    Mengatasi Error SSH Key CloudStack saat Menambahkan Host KVM

    Saat menambahkan host KVM ke Apache CloudStack menggunakan opsi System SSH Key, proses penambahan host gagal karena Management Server tidak dapat melakukan autentikasi SSH.

    Error yang Muncul

    Pada log CloudStack, error yang muncul mengarah ke kegagalan autentikasi SSH key:

    Failed to authenticate with ssh key
    Failed to authenticate with ssh key, retrying with password

    Pada CloudStack UI, error dapat ditampilkan dalam bentuk:

    Could not add host at [http://192.168.14.135] ...
    due to: [Authentication error with ssh private key]

    Ketika koneksi diuji secara manual, autentikasi SSH juga gagal:

    root@192.168.14.135: Permission denied (publickey).

    Error tersebut menunjukkan bahwa private key milik CloudStack belum dikenali oleh user root pada host KVM.

    Kondisi Lab

    Server yang digunakan pada lab ini adalah:

    • Hostname: csmgmt-kvm.lab.local
    • IP address: 192.168.14.135
    • Fungsi: CloudStack Management Server sekaligus host KVM
    • Autentikasi host: System SSH Key

    Walaupun Management Server dan host KVM berada pada server yang sama, CloudStack tetap melakukan koneksi SSH ke:

    root@192.168.14.135

    Proses CloudStack berjalan menggunakan user sistem cloud. Oleh karena itu, private key yang digunakan harus dapat dibaca oleh user cloud, sedangkan public key-nya harus terdaftar pada /root/.ssh/authorized_keys.

    Memeriksa Home Directory User cloud

    Jangan langsung menggunakan /var/cloudstack/management karena lokasi home directory user cloud dapat berbeda berdasarkan sistem operasi dan paket CloudStack yang digunakan.

    Periksa lokasi sebenarnya dengan:

    getent passwd cloud

    Ambil home directory user cloud:

    CLOUD_USER_HOME=$(getent passwd cloud | cut -d: -f6)
    printf 'Home user cloud: %s\n' "$CLOUD_USER_HOME"

    Pada Ubuntu atau Debian, lokasinya umumnya:

    /var/lib/cloudstack/management

    Sementara pada distribusi berbasis RHEL dapat menggunakan:

    /var/cloudstack/management

    Karena itu, seluruh perintah berikut menggunakan variabel $CLOUD_USER_HOME.

    Memeriksa System SSH Key CloudStack

    Periksa apakah key CloudStack sudah tersedia:

    ls -la "$CLOUD_USER_HOME/.ssh"

    Seharusnya tersedia dua file berikut:

    id_rsa
    id_rsa.pub

    Private key id_rsa digunakan oleh Management Server, sedangkan id_rsa.pub perlu didaftarkan pada host KVM.

    Jika kedua file sudah tersedia, jangan membuat key baru. Cukup perbaiki ownership dan permission-nya:

    chown -R cloud:cloud "$CLOUD_USER_HOME/.ssh"
    chmod 700 "$CLOUD_USER_HOME/.ssh"
    chmod 600 "$CLOUD_USER_HOME/.ssh/id_rsa"
    chmod 644 "$CLOUD_USER_HOME/.ssh/id_rsa.pub"

    Pastikan private key dapat dibaca oleh user cloud:

    sudo -u cloud -H test -r "$CLOUD_USER_HOME/.ssh/id_rsa" \
      && echo "Private key dapat dibaca oleh user cloud"

    Membuat SSH Key Jika Belum Tersedia

    Langkah ini hanya dilakukan jika id_rsa dan id_rsa.pub benar-benar belum tersedia.

    Buat directory SSH:

    install -d -m 700 -o cloud -g cloud "$CLOUD_USER_HOME/.ssh"

    Kemudian buat SSH key sebagai user cloud:

    sudo -u cloud -H ssh-keygen \
      -t rsa \
      -b 4096 \
      -f "$CLOUD_USER_HOME/.ssh/id_rsa" \
      -N ""

    Periksa kembali hasilnya:

    ls -l "$CLOUD_USER_HOME/.ssh/id_rsa"*

    Menambahkan Public Key ke Host KVM

    Pada kasus ini, host KVM berada pada server yang sama, yaitu 192.168.14.135. Tambahkan public key CloudStack ke authorized_keys milik user root:

    install -d -m 700 -o root -g root /root/.ssh
    touch /root/.ssh/authorized_keys

    Tambahkan key hanya jika belum terdaftar:

    grep -qxF "$(cat "$CLOUD_USER_HOME/.ssh/id_rsa.pub")" \
      /root/.ssh/authorized_keys || \
      cat "$CLOUD_USER_HOME/.ssh/id_rsa.pub" \
      >> /root/.ssh/authorized_keys

    Sesuaikan ownership dan permission:

    chown root:root /root/.ssh/authorized_keys
    chmod 600 /root/.ssh/authorized_keys

    CloudStack memang menyediakan opsi penambahan host KVM menggunakan System SSH Key dengan menempatkan public key Management Server pada /root/.ssh/authorized_keys host KVM. Prosedur tersebut juga dijelaskan dalam dokumentasi konfigurasi Apache CloudStack.

    Memeriksa Konfigurasi SSH Server

    Periksa konfigurasi SSH yang sedang aktif:

    sshd -T | grep -E '^(permitrootlogin|pubkeyauthentication)'

    Konfigurasi yang dibutuhkan adalah:

    permitrootlogin prohibit-password
    pubkeyauthentication yes

    PermitRootLogin prohibit-password mengizinkan login root menggunakan public key, tetapi tetap menolak login root menggunakan password.

    Jika hasilnya belum sesuai, buat konfigurasi tambahan:

    nano /etc/ssh/sshd_config.d/99-cloudstack.conf

    Isi dengan:

    PermitRootLogin prohibit-password
    PubkeyAuthentication yes

    Validasi syntax:

    sshd -t

    Apabila tidak terdapat output, restart SSH:

    systemctl restart ssh

    Menguji SSH sebagai User cloud

    Pengujian harus dilakukan sebagai user cloud, bukan sebagai root, karena proses CloudStack Management Server berjalan menggunakan user tersebut.

    Jalankan:

    sudo -u cloud -H ssh \
      -o BatchMode=yes \
      -o IdentitiesOnly=yes \
      -o StrictHostKeyChecking=accept-new \
      -i "$CLOUD_USER_HOME/.ssh/id_rsa" \
      root@192.168.14.135 \
      'whoami && hostname -f'

    Jika berhasil, hasilnya kurang lebih:

    root
    csmgmt-kvm.lab.local

    Opsi BatchMode=yes memastikan SSH tidak meminta password. Dengan demikian, keberhasilan perintah tersebut membuktikan bahwa autentikasi benar-benar menggunakan SSH key.

    Jika masih gagal, jalankan pengujian verbose:

    sudo -u cloud -H ssh -vvv \
      -o BatchMode=yes \
      -o IdentitiesOnly=yes \
      -i "$CLOUD_USER_HOME/.ssh/id_rsa" \
      root@192.168.14.135

    Perhatikan bagian yang menunjukkan apakah private key ditawarkan, diterima, atau ditolak oleh SSH server.

    Mengulangi Penambahan Host

    Setelah pengujian SSH berhasil, ulangi penambahan host KVM pada CloudStack dengan parameter:

    Host Name     : 192.168.14.135
    Username      : root
    Authentication: System SSH Key

    Konfigurasi berikut tidak diperlukan pada kasus ini:

    Defaults:cloud !requiretty

    Pengaturan tersebut berkaitan dengan penggunaan sudo oleh user non-root pada host tujuan. Pada kasus ini CloudStack melakukan koneksi langsung sebagai root, sehingga masalahnya murni pada autentikasi SSH key.

    Kesimpulan

    Penyebab error bukan berasal dari status cloudstack-management, libvirtd, ataupun socket libvirt. Masalahnya adalah System SSH Key CloudStack belum dapat digunakan untuk login sebagai root ke host KVM.

    Alur autentikasi yang harus dipastikan adalah:

    Proses CloudStack sebagai user cloud
            ↓
    Membaca private key dari home user cloud
            ↓
    SSH ke root@192.168.14.135
            ↓
    Public key ditemukan di /root/.ssh/authorized_keys
            ↓
    Login berhasil tanpa password
    

    Setelah koneksi SSH sebagai user cloud berhasil dan menghasilkan output root, proses penambahan host KVM dapat diulangi menggunakan opsi System SSH Key.

    https://docs.cloudstack.apache.org/en/4.21.0.0/installguide/configuration.html#adding-a-kvm-host

  • Cara Mengatasi zmamavisdctl Gagal Start Setelah Upgrade Zimbra NE 10.1.20

    Cara Mengatasi zmamavisdctl Gagal Start Setelah Upgrade Zimbra NE 10.1.20

    Saya memiliki server Zimbra Collaboration Network Edition 10.1.16 yang sudah cukup lama tidak diperbarui. Setelah melakukan upgrade (patching) ke Zimbra 10.1.20, seluruh proses upgrade berjalan dengan baik, namun terdapat satu masalah, yaitu service Amavis (zmamavisdctl) gagal dijalankan.

    Akibatnya:

    • Service amavis berstatus Stopped.
    • Service antivirus dan mta juga ikut berhenti.
    • Email tidak dapat diproses karena Postfix gagal terhubung ke Amavis.

    Gejala

    Cek status service:

    zmcontrol status

    Hasil:

    zimbra@mail:~$ zmcontrol status
    Host mail.zimbra.lab
            amavis                  Stopped
                    amavisd is not running.
            antispam                Stopped
                    zmamavisdctl is not running
            antivirus               Stopped
                    zmamavisdctl is not running
            convertd                Running
            ldap                    Running
            license-daemon          Running
            logger                  Running
            mailbox                 Running
            memcached               Running
            mta                     Stopped
                    zmamavisdctl is not running
            onlyoffice              Running
            opendkim                Running
            proxy                   Running
            service webapp          Running
            snmp                    Running
            spell                   Running
            stats                   Running
            zimbra webapp           Running
            zimbraAdmin webapp      Running
            zimlet webapp           Running
            zmconfigd               Running

    Log Postfix menunjukkan:

    connect to 127.0.0.1:10026: Connection refused

    Artinya Amavis tidak berhasil membuka port filtering SMTP.


    Proses Troubleshooting

    1. Pastikan penyebab

    Jalankan:

    su - zimbra
    
    /opt/zimbra/common/sbin/amavisd \
    -X no_conf_file_writable_check \
    -c /opt/zimbra/conf/amavisd.conf \
    test-config

    Jika tidak ada output, berarti konfigurasi Amavis valid.


    2. Jalankan Amavis secara foreground

    /opt/zimbra/common/sbin/amavisd \
    -X no_conf_file_writable_check \
    -c /opt/zimbra/conf/amavisd.conf \
    foreground

    Didapatkan error:

    zimbra@mail:~$ /opt/zimbra/common/sbin/amavisd \
    -X no_conf_file_writable_check \
    -c /opt/zimbra/conf/amavisd.conf \
    foreground
    
    Suicide () TROUBLE in pre_loop_hook: config: no rules were found!  Do you need to run 'sa-update'?
    Compilation failed in require at /opt/zimbra/common/sbin/amavisd line 101.
    BEGIN failed--compilation aborted at /opt/zimbra/common/sbin/amavisd line 101.

    3. Periksa SpamAssassin

    Lakukan pengecekan:

    /opt/zimbra/common/bin/spamassassin --lint -D

    Hasil akhirnya menunjukkan:

    zimbra@mail:~$ /opt/zimbra/common/bin/spamassassin --lint -D
    .
    .
    .
    config: no rules were found!  Do you need to run 'sa-update'?

    Padahal direktori rules masih lengkap.


    4. Jalankan sa-update

    /opt/zimbra/common/bin/sa-update -D

    Didapatkan error:

    zimbra@mail:~$ /opt/zimbra/common/bin/sa-update -D
    .
    .
    Aug  3 12:05:57.745 [47987] dbg: gpg: [GNUPG:] NO_PUBKEY 6C55397824F434CE
    Aug  3 12:05:57.745 [47987] dbg: gpg: gpg: Can't check signature: No public key
    .
    .
    NO_PUBKEY
    error: GPG validation failed!

    Dari sini diketahui bahwa GPG key SpamAssassin hilang, sehingga proses update rules gagal diverifikasi.


    Solusi

    1. Buat direktori key

    mkdir -p /opt/zimbra/data/spamassassin/localrules/sa-update-keys
    chown -R zimbra:zimbra /opt/zimbra/data/spamassassin/localrules

    2. Download GPG Key resmi

    cd /tmp
    wget https://spamassassin.apache.org/updates/GPG.KEY

    3. Import GPG Key

    Jalankan sebagai user zimbra.

    su - zimbra
    /opt/zimbra/common/bin/sa-update --import /tmp/GPG.KEY

    4. Update SpamAssassin Rules

    /opt/zimbra/common/bin/sa-update

    Pastikan proses selesai tanpa error GPG.

    5. Restart Service

    zmamavisdctl restart

    atau

    zmcontrol restart

    Verifikasi

    Pastikan service kembali berjalan:

    zmcontrol status

    Hasil yang diharapkan:

    zimbra@mail:~$ zmcontrol status
    Host mail.zimbra.lab
            amavis                  Running
            antispam                Running
            antivirus               Running
            convertd                Running
            ldap                    Running
            license-daemon          Running
            logger                  Running
            mailbox                 Running
            memcached               Running
            mta                     Running
            onlyoffice              Running
            opendkim                Running
            proxy                   Running
            service webapp          Running
            snmp                    Running
            spell                   Running
            stats                   Running
            zimbra webapp           Running
            zimbraAdmin webapp      Running
            zimlet webapp           Running
            zmconfigd               Running

    Lalu pastikan dapat mengirim email secara normal kembali.


    Kesimpulan

    Kasus ini terjadi setelah melakukan upgrade dari Zimbra 10.1.16 ke 10.1.20 pada server yang sudah lama tidak diperbarui. Penyebab utamanya bukan pada konfigurasi Amavis, melainkan GPG key SpamAssassin yang hilang, sehingga proses sa-update gagal memverifikasi update rules. Akibatnya, SpamAssassin tidak dapat memuat rules dan Amavis gagal dijalankan.

    Dengan mengembalikan GPG key, menjalankan kembali sa-update, dan me-restart service Zimbra, service amavis, antivirus, dan mta dapat kembali berjalan normal.

    Referensi

  • Mengatasi Error 451 4.3.0 Temporary lookup failure  di Carbonio

    Mengatasi Error 451 4.3.0 Temporary lookup failure di Carbonio

    Beberapa waktu lalu, saya menemukan satu hal setelah melakukan upgrade in-place pada server Carbonio. Pengiriman email lokal (local delivery) gagal dan log Postfix menunjukkan error 451 4.3.0 Temporary lookup failure yang sekilas terlihat seperti masalah LDAP atau DNS.

    Awalnya saya juga mengira penyebabnya adalah layanan LDAP yang tidak berjalan atau DNS lokal bermasalah. Namun setelah melakukan pengecekan lebih dalam, ternyata penyebabnya sama sekali berbeda. Masalah terjadi karena Postfix tidak memiliki izin membaca file konfigurasi LDAP yang digunakan untuk melakukan lookup account dan domain.

    Panduan ini membahas langkah-langkah troubleshooting hingga menemukan akar penyebabnya.


    Kendala

    Saat mengirim email muncul log seperti berikut.

    postfix/proxymap: warning: ldap:/opt/zextras/conf/ldap-transport.cf is unavailable.
    open /opt/zextras/conf/ldap-transport.cf: Permission denied
    
    postfix/trivial-rewrite: warning:
    virtual_alias_domains lookup failure
    
    451 4.3.0 Temporary lookup failure

    Karena Postfix gagal melakukan lookup ke LDAP, proses penerimaan email langsung ditolak. Ternyata permission ditolak pada file /opt/zextras/conf/ldap-transport.cf untuk user group postfix.


    Analisis Awal

    Awalnya saya melakukan beberapa pengecekan berikut.

    Memastikan service LDAP berjalan

    su - zextras
    systemctl list-units -all carbonio-*

    Semua service berjalan normal.


    Memastikan DNS berjalan

    Saya juga mengecek dnsmasq.

    systemctl status dnsmasq

    Memeriksa permission file LDAP

    Saya mengecek seluruh file konfigurasi LDAP yang digunakan Postfix.

    ls -l /opt/zextras/conf/ldap-*.cf

    Hasilnya:

    -rw-r----- 1 zextras zextras ldap-transport.cf
    -rw-r----- 1 zextras zextras ldap-vad.cf
    -rw-r----- 1 zextras zextras ldap-vmd.cf

    Sekilas permission tersebut terlihat normal.

    Namun saya mencoba membaca file menggunakan user Postfix.

    su -s /bin/bash postfix

    Kemudian:

    cat /opt/zextras/conf/ldap-transport.cf

    Hasilnya:

    Permission denied

    Di sinilah penyebab utama mulai terlihat.


    Mengapa Bisa Terjadi?

    Service SMTP dijalankan oleh user postfix.

    ps -ef | grep smtpd

    Output:

    postfix .... smtpd

    Sementara file konfigurasi LDAP dimiliki oleh:

    Owner : zextras
    Group : zextras
    Permission : 640

    Artinya hanya:

    • owner (zextras)
    • group (zextras)

    yang dapat membaca file tersebut.

    Karena user postfix bukan anggota group zextras, maka Postfix tidak dapat membaca file konfigurasi LDAP.

    Akibatnya seluruh proses lookup gagal.

    Postfix
          │
          ▼
    ldap-transport.cf
          │
    Permission denied
          │
          ▼
    LDAP lookup gagal
          │
          ▼
    451 Temporary lookup failure
    

    Membandingkan Dengan Server Carbonio yang Normal

    Saya kemudian membandingkan dengan server Carbonio lain yang berjalan normal.

    Server yang sehat memiliki permission berikut.

    -rw-r----- 1 zextras postfix ldap-transport.cf

    Perbedaannya hanya pada group ownership.

    ServerOwnerGroup
    Server errorzextraszextras
    Server normalzextraspostfix

    Karena group sudah menggunakan postfix, service SMTP dapat membaca file tanpa perlu memberikan permission ke user lain.


    Solusi

    Saya mengubah group ownership seluruh file LDAP menjadi postfix.

    chown zextras:postfix /opt/zextras/conf/ldap-*.cf
    chmod 640 /opt/zextras/conf/ldap-*.cf

    Kemudian restart layanan MTA.

    systemctl restart carbonio-mta.target

    Setelah itu saya kembali mencoba membaca file menggunakan user postfix.

    su -s /bin/bash postfix
    
    cat /opt/zextras/conf/ldap-transport.cf

    File sudah dapat dibaca tanpa error.


    Penyebab Permission Berubah

    Sampai artikel ini ditulis saya belum tau penyebab pastinya. Namun ada beberapa kemungkinan:

    • Upgrade Carbonio mengubah ownership file.
    • Script maintenance atau proses regenerasi konfigurasi membuat ulang file LDAP.
    • Restore konfigurasi dari backup dengan ownership berbeda.
    • Perubahan manual menggunakan chown.

    Tips Sebelum Mengubah Permission

    Saya tidak menyarankan menggunakan:

    chmod 644 /opt/zextras/conf/ldap-*.cf

    karena file tersebut berisi informasi autentikasi LDAP seperti:

    bind_dn
    bind_pw

    Memberikan permission 644 berarti seluruh user lokal pada server dapat membaca credential LDAP.

    Solusi yang lebih aman adalah tetap menggunakan permission 640, namun memastikan group ownership sesuai dengan yang dibutuhkan oleh Postfix.


    Penutup

    Error 451 Temporary lookup failure tidak selalu berarti LDAP atau DNS sedang bermasalah. Pada kasus ini penyebab sebenarnya adalah Postfix tidak dapat membaca file konfigurasi LDAP akibat perubahan group ownership.

    Jika menemukan log seperti:

    open /opt/zextras/conf/ldap-transport.cf: Permission denied

    Periksa ownership dan permission file konfigurasi LDAP dan pastikan ownership dan permission sesuai. Perubahan kecil pada group ownership dapat menyebabkan seluruh proses lookup gagal dan membuat layanan email tidak dapat berfungsi sebagaimana mestinya.

  • Simulasi Error SMTP 451 Temporary Lookup Failure dengan Postfix

    Simulasi Error SMTP 451 Temporary Lookup Failure dengan Postfix

    Error 451 Temporary lookup failure sering muncul di lingkungan produksi dan bikin email nyangkut di antrian dengan status deferred. Supaya paham perilakunya tanpa mengganggu server klien, saya buat lab kecil berisi dua VM Postfix, satu sebagai pengirim dan satu sebagai penerima. Panduan ini mencakup instalasi, pengujian normal, simulasi error 451, lalu pemulihan ke kondisi normal.

    Informasi lab

    PeranHostnameIPOS
    Pengirimsender.lab192.168.14.22Ubuntu 24.04
    Penerimareceiver.lab192.168.14.23Ubuntu 24.04

    Prasyarat: akses root di kedua VM, koneksi internet untuk instalasi paket, dan kedua VM berada di segmen jaringan yang sama.

    1. Persiapan

    Tambahkan entri berikut di /etc/hosts pada kedua server:

    192.168.14.22 sender.lab
    192.168.14.23 receiver.lab

    Set hostname sesuai perannya:

    hostnamectl set-hostname sender.lab

    Pastikan saling terjangkau:

    ping -c 3 receiver.lab

    2. Instalasi Postfix

    Jalankan di kedua server:

    apt update
    apt install postfix mailutils -y

    Saat wizard muncul, pilih Internet Site, lalu isi System mail name dengan sender.lab atau receiver.lab sesuai server.

    Cek status service:

    systemctl status postfix

    Status harus active (running).

    3. Konfigurasi server penerima

    Edit /etc/postfix/main.cf di receiver, pastikan baris berikut ada:

    myhostname = receiver.lab
    mydestination = receiver.lab, localhost.lab, localhost
    inet_interfaces = all
    mynetworks = 127.0.0.0/8, 192.168.14.0/24

    Buat akun lokal sebagai tujuan email:

    adduser user
    systemctl restart postfix

    Verifikasi Postfix listen di port 25:

    ss -tlnp | grep :25

    Output:

    4. Konfigurasi server pengirim

    Secara default Postfix mencari tujuan lewat DNS (smtp_host_lookup = dns), jadi entri /etc/hosts saja tidak cukup. Karena di lab ini tidak ada DNS internal, arahkan langsung ke IP receiver. Edit /etc/postfix/main.cf di sender:

    myhostname = sender.lab
    relayhost = [192.168.50.20]

    Tanda kurung siku [ ] membuat Postfix melewati pencarian MX dan langsung konek ke IP tersebut. Lalu reload:

    systemctl reload postfix

    Uji koneksi SMTP dari sender:

    telnet receiver.lab 25

    Harus muncul banner seperti 220 receiver.lab ESMTP Postfix. Keluar dengan mengetik quit.

    5. Uji pengiriman normal

    Kirim email percobaan dari sender:

    echo "Test kondisi normal" | mail -s "SMTP Test" user@receiver.lab

    Pantau log di sender:

    tail -f /var/log/mail.log

    Output yang benar:

    2026-07-24T07:37:35.394338+00:00 sender postfix/smtp[27206]: 4DD982C6: to=<user@receiver.lab>, relay=192.168.14.23[192.168.14.23]:25, delay=0.09, delays=0.02/0.02/0.03/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5A88D6AF79)

    Ini jadi baseline sebelum kita rusak sengaja.

    6. Simulasi error 451

    Di server penerima, tambahkan restriction berikut di /etc/postfix/main.cf:

    smtpd_recipient_restrictions =
        check_recipient_access hash:/etc/postfix/recipient_access,
        permit_mynetworks,
        reject_unauth_destination

    Buat file /etc/postfix/recipient_access dengan isi:

    user@receiver.lab 451 4.3.0 Temporary lookup failure

    Format 4NN text di access table membuat Postfix membalas dengan kode dan pesan tersebut. Kode 4.3.0 ditulis eksplisit supaya DSN di sisi pengirim sama persis dengan kasus produksi. Generate database lalu reload:

    postmap /etc/postfix/recipient_access
    systemctl reload postfix

    Catatan: jika postmap gagal karena tipe hash tidak tersedia, cek dengan postconf -m dan ganti ke lmdb.

    7. Uji ulang dan baca log

    Kirim lagi dari sender:

    echo "Test 451" | mail -s "451 test" user@receiver.lab

    Log di sender akan berbunyi:

    2026-07-24T07:53:18.718740+00:00 sender postfix/smtp[27250]: 9CED3332: to=<user@receiver.lab>, relay=192.168.14.23[192.168.14.23]:25, delay=0.09, delays=0.03/0.01/0.03/0.01, dsn=4.3.0, status=deferred (host 192.168.14.23[192.168.14.23] said: 451 4.3.0 <user@receiver.lab>: Recipient address rejected: Temporary lookup failure (in reply to RCPT TO command))

    Cek antrian:

    postqueue -p

    Output

    Email tetap tertahan dan akan dicoba ulang sesuai maximal_queue_lifetime (default 5 hari). Ini yang membedakan error 4xx dari 5xx.

    8. Kembalikan ke kondisi normal

    Kosongkan file access lalu regenerate:

    : > /etc/postfix/recipient_access
    postmap /etc/postfix/recipient_access
    systemctl reload postfix

    Paksa antrian jalan lagi:

    postqueue -f

    Log akan berubah menjadi dsn=2.0.0, status=sent dengan balasan 250 2.0.0 Ok.

    2026-07-24T07:56:01.180149+00:00 sender postfix/qmgr[27194]: 9CED3332: from=<root@sender.lab>, size=317, nrcpt=1 (queue active)
    2026-07-24T07:56:01.258620+00:00 sender postfix/smtp[27271]: 9CED3332: to=<user@receiver.lab>, relay=192.168.14.23[192.168.14.23]:25, delay=163, delays=163/0.03/0.04/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 314AD6AF79)
    2026-07-24T07:56:01.258793+00:00 sender postfix/qmgr[27194]: 9CED3332: removed

    Ringkasan

    SkenarioBalasan SMTPStatus di antrian
    Server penerima normal250 2.0.0 Oksent
    Gangguan sementara di penerima451 4.3.0 Temporary lookup failuredeferred, retry otomatis
    Alamat ditolak permanen550 5.x.xbounced, tidak retry

    Troubleshoot

    GejalaPenyebabSolusi
    Host or domain name not foundSender masih pakai lookup DNSSet relayhost = [IP_RECEIVER] atau smtp_host_lookup = native, dns
    Connection refused port 25inet_interfaces = loopback-only atau firewallSet inet_interfaces = all, buka port 25
    Relay access deniedDomain tujuan tidak ada di mydestinationTambahkan receiver.lab ke mydestination
    554 Too many hopsMail loop antar serverPeriksa relayhost, mydestination, dan transport_maps
    /var/log/mail.log kosongrsyslog tidak terpasangGunakan journalctl -u postfix -f

    Lab ini cukup ringan tapi mencakup pola error yang paling sering ditemui saat troubleshooting Postfix, Zimbra, Carbonio, maupun SMTP relay. Semoga bermanfaat.

    Referensi