Author: Rafi Harlianto

  • Panduan Upgrade Carbonio Menggunakan Ansible

    Panduan Upgrade Carbonio Menggunakan Ansible

    Pendahuluan

    Menjaga Carbonio tetap menggunakan versi terbaru merupakan salah satu langkah penting untuk mendapatkan fitur terbaru, peningkatan performa, perbaikan bug, serta pembaruan keamanan. Mulai Carbonio 26.6.x, Zextras menyediakan mekanisme upgrade yang lebih terstruktur menggunakan Ansible, sehingga proses pembaruan dapat dilakukan secara konsisten baik pada deployment single-node maupun multi-node.

    Berbeda dengan aplikasi yang memiliki installer terpisah, Carbonio melakukan upgrade melalui pembaruan package sistem. Oleh karena itu, proses upgrade dilakukan menggunakan Ansible Playbook yang akan memperbarui seluruh paket Carbonio dari repository resmi Zextras ke versi terbaru yang tersedia. Dokumentasi resmi juga menjelaskan bahwa prosedur ini dapat digunakan untuk melakukan upgrade dari versi Carbonio yang masih didukung menuju versi terbaru tanpa harus melewati setiap versi satu per satu. Sebelum memulai upgrade, Zextras sangat menyarankan untuk membuat backup dan snapshot seluruh node sebagai langkah mitigasi apabila terjadi kendala selama proses upgrade.


    Persyaratan

    Sebelum menjalankan proses upgrade, pastikan beberapa persyaratan berikut telah dipenuhi:

    • Sudah melakukan backup seluruh data Carbonio.
    • Membuat snapshot seluruh virtual machine (jika menggunakan virtualisasi).
    • Seluruh repository Carbonio telah dikonfigurasi dengan benar.
    • Ansible dapat melakukan koneksi SSH ke seluruh node.
    • File inventory Ansible masih sesuai dengan kondisi infrastruktur Carbonio.
    • Hanya repository yang ingin digunakan untuk upgrade yang dalam kondisi aktif. Repository lain sebaiknya dinonaktifkan agar tidak ikut memperbarui package yang tidak diinginkan.

    Install atau Update Collection Carbonio Upgrade

    Sebelum menjalankan playbook upgrade, pastikan collection zxbot.carbonio_upgrade telah terpasang atau diperbarui ke versi terbaru.

    Jalankan perintah berikut:

    ansible-galaxy collection install zxbot.carbonio_upgrade -U

    Parameter -U berfungsi untuk:

    • menginstal collection apabila belum tersedia,
    • atau memperbarui collection ke versi terbaru apabila sudah pernah diinstal sebelumnya.

    Collection inilah yang berisi seluruh playbook yang digunakan untuk melakukan upgrade Carbonio.


    Pastikan File Inventory

    Ansible akan menggunakan file inventory yang sebelumnya digunakan saat instalasi.

    Contoh:

    carbonio-inventory

    Pastikan seluruh hostname, FQDN, dan pembagian service masih sesuai dengan kondisi server saat ini.

    Jika sebelumnya Carbonio diinstal secara manual, inventory tetap dapat digunakan selama seluruh node dan komponennya telah diisikan dengan benar.


    Jalankan Upgrade

    Masuk ke direktori tempat inventory berada, kemudian jalankan:

    ansible-playbook zxbot.carbonio_upgrade.carbonio_upgrade \
    -u root \
    -i carbonio-inventory

    Playbook akan melakukan proses upgrade seluruh package Carbonio yang berasal dari repository resmi Zextras.

    Dokumentasi resmi menjelaskan bahwa versi Carbonio yang saat ini terpasang tidak memengaruhi prosedur upgrade. Selama berasal dari versi yang masih didukung, sistem akan diperbarui ke release terbaru yang tersedia pada repository.


    Mencegah Auto Remove Package

    Secara default, playbook akan menjalankan proses autoremove terhadap dependency yang dianggap sudah tidak digunakan.

    Apabila Anda ingin menonaktifkan perilaku tersebut, gunakan parameter berikut:

    ansible-playbook zxbot.carbonio_upgrade.carbonio_upgrade \
    -u root \
    -i carbonio-inventory \
    --extra-vars skip_autoremove=1

    Opsi ini cukup berguna apabila Anda ingin melakukan verifikasi terlebih dahulu sebelum menghapus package yang tidak lagi digunakan.

    Perlu diperhatikan bahwa package yang dipasang secara manual dan tidak digunakan oleh Carbonio tidak akan dihapus secara otomatis, sehingga administrator tetap perlu melakukan pembersihan apabila diperlukan.


    Jika Upgrade Gagal

    Apabila proses upgrade berhenti karena suatu error, Anda tidak perlu mengulang seluruh proses dari awal.

    Cukup jalankan kembali playbook yang sama:

    ansible-playbook zxbot.carbonio_upgrade.carbonio_upgrade \
    -u root \
    -i carbonio-inventory

    Ansible akan mengenali task yang telah berhasil dijalankan sebelumnya dan hanya mengeksekusi task yang gagal atau belum selesai. Mekanisme ini membantu mempercepat proses recovery tanpa harus mengulang keseluruhan upgrade.


    Catatan Khusus Upgrade dari Versi Lama

    Bagi administrator yang melakukan upgrade dari Carbonio versi lama, terdapat beberapa penyesuaian pada file inventory.

    Upgrade dari Carbonio 24.12

    Jika menggunakan Carbonio 24.12, pastikan inventory telah memiliki section:

    [workStreamServers]

    Jika sebelumnya menggunakan komponen Chats, tambahkan hostname node Chats pada section tersebut sebelum menjalankan upgrade.

    Upgrade dari Carbonio 24.9 atau Lebih Lama

    Untuk deployment yang berasal dari Carbonio 24.9 atau versi yang lebih lama, section berikut tetap harus ada pada inventory selama proses upgrade:

    [dbsConnectorServers]

    Walaupun komponen DB Connector telah dihapus pada versi terbaru, keberadaan section tersebut masih diperlukan agar Ansible dapat melakukan migrasi package dengan benar. Setelah proses upgrade selesai, section tersebut dapat dikosongkan sesuai rekomendasi dokumentasi.


    Hal Pasca Upgrade

    Mulai Carbonio 26.6.x, Zextras memperkenalkan Unified Quota.

    Perubahan ini menggabungkan quota Mail, Files, dan Chat menjadi satu quota penyimpanan per pengguna.

    Penting untuk diketahui bahwa konfigurasi quota lama tidak dimigrasikan secara otomatis. Setelah upgrade, seluruh akun akan memiliki quota Unlimited hingga administrator menetapkan quota baru.

    Oleh karena itu, administrator disarankan untuk:

    • meninjau kembali penggunaan storage,
    • menentukan kebijakan quota baru,
    • menjalankan migration script Unified Quota yang tersedia melalui Partner Portal apabila diperlukan.

    Kesimpulan

    Upgrade Carbonio menggunakan Ansible merupakan metode resmi yang direkomendasikan oleh Zextras karena mampu melakukan pembaruan secara konsisten pada seluruh node dalam infrastruktur. Proses upgrade cukup sederhana, yaitu memperbarui collection Ansible, memastikan inventory telah sesuai, kemudian menjalankan playbook upgrade.

    Sebelum memulai proses, jangan lupa melakukan backup dan snapshot seluruh server. Selain itu, apabila Anda melakukan upgrade ke Carbonio 26.6.x, pastikan untuk meninjau perubahan Unified Quota karena konfigurasi quota lama tidak akan dimigrasikan secara otomatis dan memerlukan tindakan administrator setelah proses upgrade selesai.


    Referensi

  • Mengganti Logo & White Label Zimbra Modern UI

    Mengganti Logo & White Label Zimbra Modern UI

    Salah satu kebutuhan yang sering muncul ketika implementasi mail server Zimbra Collaboration adalah menyesuaikan tampilan webmail dengan identitas perusahaan. Mengganti logo perusahaan pada halaman webmail dapat meningkatkan branding sekaligus memberikan pengalaman yang lebih profesional bagi pengguna.

    Sejak hadirnya Modern UI, mekanisme penggantian logo di Zimbra berubah dibandingkan dengan Classic Web Client. Oleh karena itu, para admin perlu menggunakan metode yang sesuai dengan antarmuka yang digunakan.

    Pada artikel ini kita akan membahas cara mengganti logo pada Zimbra Modern UI berdasarkan panduan resmi Zimbra.


    Rebranding vs White Label

    Sebelum memulai, penting untuk memahami dua istilah yang sering digunakan.

    Rebranding adalah proses menambahkan identitas perusahaan, seperti logo, tanpa menghilangkan identitas Zimbra yang diwajibkan oleh lisensi tertentu.

    Sedangkan White Label berarti mengganti identitas Zimbra sepenuhnya dengan identitas perusahaan, termasuk logo maupun elemen antarmuka lainnya.

    Bagi pengguna Zimbra Open Source Edition, proses rebranding tetap harus mengikuti ketentuan lisensi CPAL. Sementara itu, kemampuan white label melalui konfigurasi bawaan tersedia pada Zimbra Network Edition. Informasi ini dijelaskan pada panduan resmi Zimbra mengenai rebranding Classic Web Client.

    Catatan

    Apabila masih menggunakan Classic Web Client (Zimbra 8.x), Zimbra telah menyediakan panduan resmi tersendiri mengenai penggantian Login Banner dan Application Banner menggunakan atribut zmprov. Karena artikel ini difokuskan pada Modern UI, panduan tersebut tidak dibahas kembali di sini.


    Persiapan

    Sebelum mengganti logo, siapkan terlebih dahulu file logo dengan format:

    • SVG (logo.svg)

    Modern UI menggunakan file logo.svg sebagai logo aplikasi.


    Menentukan Jenis Virtual Host

    Langkah pertama adalah mengetahui apakah deployment menggunakan default virtual hostname atau custom virtual hostname.

    Caranya:

    1. Login ke Modern UI menggunakan browser Firefox.
    2. Klik kanan pada logo Zimbra.
    3. Pilih Open Image in New Tab.
    4. Perhatikan URL gambar yang muncul.

    Hasilnya akan menunjukkan salah satu dari dua kondisi berikut:

    • Menggunakan default virtual hostname.
    • Menggunakan custom virtual hostname.

    Metode penggantian logo akan mengikuti kondisi tersebut.


    Prosedur A — Default Virtual Host

    Apabila logo berasal dari default virtual hostname, lakukan langkah berikut.

    1. Masuk ke direktori aset Modern UI

    cd /opt/zimbra/jetty/webapps/zimbra/modern/clients/default/assets

    2. Backup logo bawaan

    Sebelum mengganti logo, simpan salinan file asli.

    cp logo.svg logo.svg.old

    3. Upload logo

    Upload file logo perusahaan dengan nama:

    logo.svg

    ke direktori:

    /opt/zimbra/jetty/webapps/zimbra/modern/clients/default/assets

    Apabila file diunggah menggunakan user root, ubah ownership menjadi user zimbra.

    chown zimbra:zimbra \
    /opt/zimbra/jetty/webapps/zimbra/modern/clients/default/assets/logo.svg


    4. Perbarui config.json

    Edit file berikut.

    /opt/zimbra/jetty/webapps/zimbra/modern/clients/default/config.json

    Kemudian ubah nilai version menjadi nilai baru yang belum pernah digunakan sebelumnya.

    Tujuan perubahan versi ini adalah agar browser mengambil aset terbaru setelah logo diganti.


    5. Restart layanan Mailbox

    Masuk sebagai user zimbra.

    su - zimbra

    Kemudian restart layanan.

    zmmailboxdctl restart

    Prosedur B — Custom Virtual Host

    Apabila hasil pengecekan menunjukkan penggunaan custom virtual hostname, ikuti langkah berikut.

    1. Login sebagai user zimbra

    su - zimbra

    Masuk ke direktori Modern UI.

    cd /opt/zimbra/jetty/webapps/zimbra/modern/clients/

    2. Salin direktori default

    Salin direktori default menjadi nama virtual hostname yang digunakan.

    cp -r default <virtual-hostname>

    Sebagai contoh, apabila virtual hostname adalah mail.example.com, maka direktori baru akan dibuat menggunakan nama tersebut.


    3. Masuk ke direktori assets

    cd /opt/zimbra/jetty/webapps/zimbra/modern/clients/<virtual-hostname>/assets

    4. Backup logo bawaan

    cp logo.svg logo.svg.old

    5. Upload logo baru

    Upload logo perusahaan menggunakan nama:

    logo.svg

    ke direktori assets tersebut.


    6. Edit config.json

    Edit file:

    /opt/zimbra/jetty/webapps/zimbra/modern/clients/<virtual-hostname>/config.json

    Kemudian ubah nilai version menggunakan nilai baru yang belum pernah digunakan sebelumnya.


    7. Restart layanan

    Setelah konfigurasi, restart layanan Mailbox sebagai zimbra.

    zmmailboxdctl restart

    Verifikasi

    Setelah layanan berhasil dijalankan kembali:

    1. Buka kembali halaman Modern UI.
    2. Refresh browser.
    3. Apabila logo lama masih muncul, bersihkan cache browser lalu muat ulang halaman.

    Perubahan versi pada config.json membantu browser memuat aset terbaru, namun cache browser tetap dapat memengaruhi hasil yang ditampilkan.


    Hal yang Perlu Diperhatikan

    Beberapa hal penting sebelum melakukan kustomisasi logo:

    • Selalu lakukan backup terhadap file logo.svg bawaan.
    • Gunakan nilai version baru setiap kali mengganti logo.
    • Pastikan ownership file tetap dimiliki oleh user zimbra apabila proses upload dilakukan menggunakan user root.
    • Restart zmmailboxdctl setelah seluruh perubahan selesai dilakukan.

    Penutup

    Pada Modern UI, proses penggantian logo tidak lagi menggunakan atribut zmprov seperti pada Classic Web Client. Sebagai gantinya, administrator perlu mengganti file logo.svg, memperbarui nilai version pada config.json, kemudian me-restart layanan zmmailboxdctl.

    Bagi administrator yang masih menggunakan Classic Web Client, Zimbra tetap menyediakan panduan resmi mengenai rebranding Login Banner dan Application Banner. Namun, untuk implementasi Zimbra Modern UI, metode yang dijelaskan dalam artikel ini merupakan pendekatan yang direkomendasikan oleh Zimbra.

    Referensi

    1. Zimbra. (2023). Did you know? How to change the Zimbra logo in Modern UI. https://blog.zimbra.com/2023/08/did-you-know-how-to-change-the-zimbra-logo-in-modern-ui/
    2. Zimbra. (2021). How to change modern user interface logo. https://wiki.zimbra.com/wiki/How_to_change_modern_user_interface_logo
    3. Zimbra. (2015). How to add your Logo in the Login and App window in Open Source or Network Edition. https://blog.zimbra.com/2015/09/change-login-app-logo-open-source-network-edition/
  • Jumlah RAM untuk Homelab Proxmox

    Jumlah RAM untuk Homelab Proxmox

    Saat membangun homelab menggunakan Proxmox VE, salah satu pertanyaan yang paling sering muncul adalah, seberapa besar RAM yang sebenarnya dibutuhkan? Tidak sedikit yang langsung membeli RAM sebanyak mungkin karena menganggap virtualisasi selalu membutuhkan memori besar. Padahal, kebutuhan RAM sangat bergantung pada jumlah virtual machine (VM), container (LXC), dan layanan yang akan dijalankan.

    Di sisi lain, memilih kapasitas RAM yang terlalu kecil juga bisa menjadi masalah. Host Proxmox akan kehabisan memori lebih cepat, performa VM menurun, bahkan proses backup atau migrasi bisa terasa lambat. Oleh karena itu, sebelum membeli atau meng-upgrade server homelab, ada baiknya memahami kebutuhan RAM sesuai dengan skenario penggunaan.

    Pada artikel ini kita akan membahas rekomendasi kapasitas RAM untuk homelab Proxmox, mulai dari kebutuhan dasar hingga homelab yang digunakan untuk belajar clustering, Kubernetes, maupun Ceph.


    RAM Penting untuk Proxmox

    Berbeda dengan CPU yang dapat dibagi (oversubscribe) kepada banyak VM, RAM merupakan resource yang jauh lebih terbatas. Ketika sebuah VM diberikan RAM sebesar 4 GB, maka Proxmox harus menyediakan alokasi tersebut agar VM dapat berjalan dengan baik.

    Semakin banyak VM yang aktif, semakin besar pula kebutuhan RAM pada host.

    Sebagai gambaran sederhana:

    • Host Proxmox sendiri membutuhkan sekitar 2–4 GB RAM agar berjalan dengan lancar dan aman.
    • Setiap VM memiliki kebutuhan RAM masing-masing.
    • LXC Container biasanya lebih hemat RAM dibandingkan VM.
    • ZFS juga menggunakan RAM sebagai cache (ARC) untuk meningkatkan performa storage.

    Artinya, jangan hanya menghitung RAM berdasarkan jumlah VM saja. Sisakan juga ruang untuk sistem operasi host dan kebutuhan storage.


    Faktor yang Mempengaruhi Kebutuhan RAM

    Sebelum menentukan kapasitas RAM, perhatikan beberapa hal berikut.

    1. Jumlah Virtual Machine

    Semakin banyak VM yang dijalankan secara bersamaan, semakin besar RAM yang dibutuhkan.

    Contohnya:

    • Ubuntu Server : 1–2 GB
    • Debian Server : 512 MB–1 GB
    • Windows Server : 4–8 GB
    • Windows 11 : 4–8 GB
    • Kubernetes Node : 2–4 GB
    • Docker Host : 2–4 GB

    Jika Anda memiliki lima VM yang masing-masing membutuhkan 2 GB, maka setidaknya diperlukan sekitar 10 GB RAM hanya untuk VM tersebut.


    2. Menggunakan VM atau LXC?

    LXC jauh lebih ringan dibandingkan VM karena berbagi kernel dengan host.

    Sebagai contoh:

    • Pi-hole
    • Nginx
    • AdGuard Home
    • Grafana
    • Prometheus
    • Jellyfin

    Semua layanan tersebut sangat cocok dijalankan menggunakan LXC sehingga konsumsi RAM menjadi lebih kecil.


    3. File System yang Digunakan

    Apabila menggunakan ZFS, sebaiknya sediakan RAM lebih banyak karena ZFS memanfaatkan memori sebagai cache.

    Walaupun aturan lama menyebutkan “1 GB RAM untuk setiap 1 TB storage”, pada penggunaan homelab modern aturan tersebut sudah tidak lagi menjadi keharusan. Namun, tetap disarankan memiliki RAM yang cukup agar performa ZFS tetap optimal.


    Rekomendasi RAM Berdasarkan Skenario

    8 GB RAM

    Kapasitas ini cocok apabila Anda baru mulai belajar Proxmox.

    Contoh penggunaan:

    • 1–2 VM Linux
    • Beberapa LXC
    • DNS Server
    • Nginx
    • Pi-hole
    • Monitoring sederhana

    Kelebihan:

    • Biaya murah
    • Cocok untuk belajar virtualisasi dasar

    Kekurangan:

    • Sulit menjalankan Windows dan banyak VM secara bersamaan.
    • Ruang untuk pengembangan cukup terbatas.

    16 GB RAM

    Menurut saya, ini merupakan kapasitas yang paling ideal untuk sebagian besar homelab.

    Dengan RAM 16 GB, Anda sudah bisa menjalankan:

    • Active Directory
    • Windows Server
    • Ubuntu Server
    • Docker
    • GitLab
    • Monitoring
    • Reverse Proxy
    • Beberapa LXC

    Masih tersedia ruang untuk melakukan eksperimen tanpa terlalu cepat kehabisan memori.


    32 GB RAM

    Jika homelab mulai digunakan untuk simulasi lingkungan produksi, 32 GB menjadi pilihan yang jauh lebih nyaman.

    Contoh workload:

    • Kubernetes
    • Docker Swarm
    • Beberapa Windows Server
    • Database
    • Monitoring lengkap
    • CI/CD
    • Cluster Proxmox kecil

    Pada kapasitas ini Anda tidak perlu terlalu sering mematikan VM hanya untuk mencoba layanan baru.


    64 GB atau Lebih

    Kapasitas ini lebih cocok untuk pengguna yang ingin membangun homelab tingkat lanjut.

    Misalnya:

    • Cluster Proxmox 3 Node
    • Ceph Storage
    • Kubernetes Multi Node
    • OpenStack
    • OpenShift
    • Banyak VM aktif secara bersamaan

    Jika homelab digunakan sebagai lab sertifikasi atau simulasi data center, kapasitas ini akan memberikan ruang yang jauh lebih lega.


    Ingat RAM untuk Host

    Kesalahan yang sering dilakukan adalah mengalokasikan seluruh RAM kepada VM.

    Sebaiknya sisakan RAM untuk:

    • Proxmox VE
    • ZFS ARC
    • Backup
    • Live Migration
    • Proses update
    • Operasi sistem lainnya

    Sebagai contoh, apabila server memiliki RAM 32 GB, hindari memberikan seluruh kapasitas tersebut kepada VM. Sisakan beberapa gigabyte agar host tetap responsif.


    Mengaktifkan Memory Ballooning

    Proxmox menyediakan fitur Memory Ballooning yang memungkinkan penggunaan RAM menjadi lebih efisien.

    Fitur ini cocok apabila:

    • Tidak semua VM aktif menggunakan RAM secara maksimal.
    • Ingin meningkatkan kepadatan VM pada satu host.
    • Menjalankan banyak server Linux dengan beban yang berubah-ubah.

    Namun, untuk VM dengan beban kerja berat seperti database atau aplikasi yang membutuhkan performa stabil, sebaiknya tetap gunakan alokasi RAM tetap (fixed memory).


    RAM untuk Homelab

    Sebelum membeli RAM, pertimbangkan beberapa hal berikut:

    • Pilih motherboard yang masih memiliki slot RAM kosong agar mudah melakukan upgrade.
    • Gunakan dua keping RAM (dual-channel) jika memungkinkan untuk performa yang lebih baik.
    • Prioritaskan kapasitas dibandingkan kecepatan RAM jika anggaran terbatas.
    • Jika berencana menggunakan ZFS, Kubernetes, atau Ceph, pertimbangkan langsung memulai dari 32 GB.

    Kesimpulan

    Tidak ada jawaban pasti mengenai berapa RAM yang dibutuhkan untuk homelab Proxmox karena semuanya bergantung pada workload yang akan dijalankan. Namun, sebagai acuan sederhana:

    Kapasitas RAMCocok Untuk
    8 GBBelajar Proxmox dan menjalankan beberapa VM Linux atau LXC.
    16 GBHomelab rumahan dengan beberapa VM dan layanan sehari-hari.
    32 GBKubernetes, Docker, monitoring, database, dan simulasi lingkungan produksi.
    64 GB+Cluster Proxmox, Ceph, virtualisasi skala besar, serta lab sertifikasi.

    Apabila Anda baru membangun homelab, saya menyarankan minimal menggunakan RAM 16 GB. Kapasitas tersebut sudah cukup fleksibel untuk menjalankan beberapa VM sekaligus tanpa cepat kehabisan memori. Jika suatu saat kebutuhan meningkat, Anda tinggal menambah RAM tanpa harus mengganti seluruh platform.

    Dengan perencanaan RAM yang tepat sejak awal, homelab Proxmox akan lebih nyaman digunakan untuk belajar, melakukan pengujian, maupun membangun berbagai layanan virtual di rumah.


    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.

  • 9 Panduan Cleanup Resource Proxmox VE Secara Berkala

    9 Panduan Cleanup Resource Proxmox VE Secara Berkala

    Seiring bertambahnya jumlah VM, container, backup, dan file ISO, resource pada Proxmox VE juga akan semakin banyak. Kalau tidak pernah dirapikan, lama-kelamaan storage menjadi penuh, tampilan Web GUI semakin berantakan, dan proses administrasi kurang efisien.

    Pada artikel ini saya akan merangkum beberapa panduan cleanup yang dapat dilakukan secara berkala berdasarkan pembahasan dari VirtualizationHowTo. Sebagian besar langkah dapat dilakukan langsung melalui GUI Proxmox VE, sehingga tidak perlu selalu menggunakan terminal.


    1. Hapus File ISO yang Sudah Tidak Digunakan

    Setelah selesai menginstal sistem operasi, file ISO biasanya tetap tersimpan di storage. Jika dibiarkan terus, ukurannya bisa mencapai puluhan gigabyte tanpa disadari.

    Cara melalui Web GUI

    1. Login ke Proxmox Web UI.
    2. Pilih salah satu node Proxmox.
    3. Pilih storage yang menyimpan ISO (pada contoh nfs-iso).
    4. Buka tab ISO Images.

    Di halaman ini akan terlihat seluruh file ISO yang tersimpan.

    Jika ada ISO yang sudah tidak diperlukan:

    • Pilih file ISO.
    • Klik Remove.
    • Konfirmasi penghapusan.

    Sebaiknya simpan hanya ISO yang masih sering digunakan agar storage tetap lega.


    2. Hapus Template VM yang Sudah Tidak Digunakan

    Template VM sangat membantu untuk deployment cepat. Namun setelah beberapa tahun, biasanya template lama tetap tersimpan walaupun sudah tidak pernah dipakai.

    Cara melalui Web GUI

    1. Pilih node Proxmox.
    2. Cari VM yang memiliki ikon Template.
    3. Pastikan template tersebut memang sudah tidak digunakan.
    4. Klik More.
    5. Pilih Remove.

    Misalnya kalian memiliki:

    • Ubuntu 20.04 Template
    • Ubuntu 22.04 Template
    • Ubuntu 24.04 Template

    Jika seluruh deployment sudah menggunakan Ubuntu 24.04, template lama dapat dipertimbangkan untuk dihapus.


    3. Bersihkan Template LXC Lama

    Selain template VM, Proxmox juga menyediakan template untuk LXC Container. Jika sudah tidak digunakan lagi, template tersebut juga sebaiknya dibersihkan.

    Cara melalui Web GUI

    1. Klik Datacenter.
    2. Pilih Storage.
    3. Klik storage yang digunakan (biasanya local).
    4. Buka tab CT Templates.

    Pilih template yang sudah tidak digunakan kemudian klik Remove.


    4. Hapus Snapshot VM dan LXC yang Sudah Tidak Digunakan

    Snapshot biasanya dibuat sebelum upgrade, patching, atau perubahan konfigurasi. Namun setelah proses maintenance selesai dan server dipastikan berjalan normal, snapshot sering kali lupa dihapus.

    Padahal snapshot yang dibiarkan terlalu lama dapat:

    • menggunakan storage lebih banyak,
    • memperbesar ukuran virtual disk,
    • memperlama proses backup.

    Cara melalui Web GUI

    1. Pilih VM atau Container.
    2. Masuk ke tab Snapshots.
    3. Pilih snapshot yang sudah tidak diperlukan.
    4. Klik Delete.

    Saya sendiri biasanya hanya menyimpan snapshot selama proses maintenance berlangsung. Setelah semuanya dipastikan normal, snapshot langsung saya hapus.


    5. Hapus File Backup Lama

    Backup memang penting, tetapi backup yang tidak pernah dibersihkan hanya akan memenuhi storage. Jika belum menggunakan retention policy, sebaiknya lakukan pengecekan secara berkala.

    Cara melalui Web GUI

    1. Klik Datacenter.
    2. Pilih Backups.

    Jika ada backup yang sudah tidak diperlukan:

    • Pilih file backup.
    • Klik Remove.

    Lebih baik lagi jika kalian mengatur retention policy sehingga backup lama dapat dihapus secara otomatis.


    6. Hapus Kernel Proxmox Lama

    Setelah beberapa kali melakukan update Proxmox VE, biasanya kernel lama masih tetap tersimpan.

    Kernel lama memang berguna sebagai cadangan apabila terjadi masalah setelah update. Namun jika jumlahnya terlalu banyak, ruang pada partisi sistem juga akan semakin berkurang.

    Melihat daftar kernel yang terpasang

    Jalankan perintah berikut:

    proxmox-boot-tool kernel list

    Contoh output:

    6.17.13-19-pve
    7.0.0-3-pve
    7.0.14-6-pve

    Untuk mengetahui kernel yang sedang digunakan saat ini, jalankan:

    uname -r

    Output:

    7.0.0-3-pve

    Artinya server saat ini sedang menggunakan kernel tersebut.

    Menghapus kernel lama

    Jika sudah yakin server berjalan stabil menggunakan kernel terbaru, kernel lama dapat dihapus menggunakan package manager Debian.

    Misalnya:

    apt purge proxmox-kernel-6.17.13-19-pve

    Setelah selesai, jalankan:

    apt autoremove

    untuk menghapus dependency yang sudah tidak digunakan.

    Tips: Jangan langsung menghapus semua kernel lama. Sebaiknya sisakan kernel yang sedang aktif dan minimal satu kernel versi sebelumnya sebagai cadangan jika suatu saat perlu melakukan rollback setelah update.


    7. Bersihkan Orphaned Disk Setelah Menghapus VM

    Kadang sebuah VM sudah dihapus, tetapi virtual disk masih tertinggal pada storage. Hal ini biasanya terjadi setelah proses restore, migrasi, atau perubahan konfigurasi disk.

    Cara melalui Web GUI

    1. Pilih VM.
    2. Masuk ke tab Hardware.

    Jika terdapat item seperti:

    • Unused Disk 0
    • Unused Disk 1

    berarti disk tersebut sudah tidak terhubung ke VM.

    Untuk menghapusnya:

    1. Pilih Unused Disk.
    2. Klik Remove.

    Langkah sederhana ini dapat menghemat cukup banyak kapasitas storage.


    8. Audit VM dan Container yang Sudah Tidak Digunakan

    Banyak administrator memiliki VM seperti:

    • testing
    • lab
    • migration
    • temporary
    • old-server

    yang sebenarnya sudah tidak pernah digunakan lagi.

    Selain memenuhi storage, daftar VM juga menjadi kurang rapi.

    Via Web GUI

    1. Periksa seluruh daftar VM dan Container.
    2. Cari VM yang sudah lama berstatus Stopped.
    3. Pastikan tidak ada pengguna yang masih memerlukannya.
    4. Klik More.
    5. Pilih Remove.

    Sebelum menghapus VM, pastikan kalian sudah memiliki backup apabila sewaktu-waktu masih diperlukan.


    9. Hapus Storage Mount Point yang Sudah Tidak Digunakan

    Kadang sebuah storage NFS, SMB, iSCSI, atau direktori lokal sudah tidak digunakan lagi tetapi masih terdaftar pada Proxmox.

    Selain membuat tampilan kurang rapi, storage yang tidak aktif juga dapat memunculkan notifikasi error apabila mount point sudah tidak tersedia.

    Cara melalui Web GUI

    1. Klik Datacenter.
    2. Pilih Storage.
    3. Pilih storage yang sudah tidak digunakan.
    4. Klik Remove.

    Sebelum menghapus storage, pastikan:

    • tidak ada VM yang masih menggunakan storage tersebut,
    • tidak ada backup yang tersimpan,
    • tidak ada ISO atau template penting yang masih berada di dalamnya.

    Tips Tambahan

    Selain sembilan cleanup di atas, saya biasanya juga melakukan beberapa pengecekan sederhana setelah maintenance:

    • Memastikan seluruh job backup berhasil.
    • Mengecek kapasitas storage pada setiap datastore.
    • Memastikan seluruh node cluster berstatus Online.
    • Memeriksa notifikasi warning atau error pada Datacenter.
    • Jika menggunakan Ceph, pastikan status cluster dalam kondisi HEALTH_OK.

    Walaupun tidak termasuk bagian dari artikel sumber, langkah-langkah tersebut cukup membantu untuk memastikan kondisi Proxmox tetap sehat setelah proses cleanup selesai.


    Penutup

    Cleanup pada Proxmox VE sering kali dianggap pekerjaan kecil karena tidak berdampak langsung terhadap performa VM. Padahal, jika dilakukan secara rutin, cleanup dapat menjaga storage tetap lega, membuat tampilan Web GUI lebih rapi, dan memudahkan administrator ketika mengelola infrastruktur virtualisasi.

    Dari sembilan panduan di atas, hampir seluruhnya dapat dilakukan langsung melalui Web GUI tanpa harus membuka terminal. Hanya penghapusan kernel lama yang saat ini masih memerlukan akses CLI.


    Referensi

  • 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

  • Mengenal Proxmox Offline Mirror

    Tidak semua server Proxmox boleh menyentuh internet. Di banyak lingkungan enterprise, host virtualisasi ditaruh di segmen tertutup atau benar-benar air-gapped, sementara update tetap harus jalan. Untuk kasus seperti ini Proxmox punya tool resmi bernama Proxmox Offline Mirror (POM). Di tulisan ini saya bahas konsepnya saja, belum ke langkah teknisnya.

    Apa itu Proxmox Offline Mirror

    POM adalah tool untuk membuat dan mengelola mirror repository APT Proxmox dan Debian secara lokal. Dari mirror lokal itu, isinya bisa diekspor ke media eksternal seperti flashdisk, hardisk portabel, atau network share, lalu dipakai untuk update sistem yang tidak punya akses internet. Selain repository, POM juga bisa mengelola subscription key untuk host offline, jadi aktivasi lisensi tetap bisa dilakukan tanpa host tersebut terhubung ke internet.

    Yang sering salah dipahami: POM tidak dipasang di host Proxmox yang offline. POM dipasang di mesin terpisah yang punya koneksi internet, bisa Debian polos atau host Proxmox lain. Host offline hanya jadi konsumen dari media yang sudah disiapkan.

    Dua binary di dalamnya

    BinaryDijalankan diFungsi
    proxmox-offline-mirrorHost mirror (online)Membuat dan mengelola mirror serta media
    proxmox-offline-mirror-helperHost target (offline)Memakai media dan mengaktifkan subscription di PVE, PBS, atau PMG

    Empat istilah yang perlu dipahami

    IstilahPenjelasan
    keysSubscription key, baik untuk sistem mirror itu sendiri maupun untuk host offline
    mirrorsMetadata repository upstream plus path lokal tempat snapshot disimpan
    snapshotsPotret repository pada satu titik waktu
    mediaLokasi filesystem (flashdisk atau network share) tempat mirror disinkronkan

    Cara kerjanya

    Alurnya kurang lebih begini:

    1. Host mirror menarik isi repository upstream, lalu menyimpannya sebagai snapshot.
    2. Snapshot yang dipilih disinkronkan ke sebuah medium.
    3. Medium dibawa ke host offline, dicolok atau diekspos lewat jaringan internal (NFS, CIFS/SMB, atau HTTP).
    4. Host offline mengarahkan APT ke medium tersebut, lalu update seperti biasa.

    Bagian yang menarik ada di penyimpanannya. POM menyimpan file berdasarkan checksum di sebuah pool, lalu membuat hardlink ke file tersebut. Efeknya, snapshot kedua dan seterusnya tidak menduplikasi paket yang tidak berubah, jadi punya banyak snapshot tidak berarti disk membengkak berkali lipat. Satu base directory juga bisa dipakai bersama beberapa mirror, dan untuk repository Proxmox memang disarankan pakai satu base directory saja supaya dedup-nya maksimal.

    Konsekuensinya, filesystem yang dipakai wajib mendukung hardlink, di host mirror maupun di medium. Filesystem turunan Windows seperti FAT tidak mendukung ini, jadi flashdisk bawaan pabrik biasanya perlu diformat ulang ke ext4 atau XFS.

    Kenapa pakai POM, bukan rsync biasa

    Mirror repository sebetulnya bisa dibuat manual dengan rsync atau apt-mirror. Bedanya, POM memberi beberapa hal yang relevan untuk lingkungan produksi:

    • Snapshot berbasis waktu. Update jadi terkontrol karena kalian tahu persis versi paket mana yang dikirim ke host offline, dan bisa rollback ke snapshot sebelumnya.
    • Hemat disk. Deduplikasi lewat hardlink pool, bukan salin ulang.
    • Verifikasi bawaan. Signature repository ikut diverifikasi saat sync.
    • Filter scope. Arsitektur, komponen, nama paket, dan section bisa dipersempit supaya mirror tidak menarik hal yang tidak dibutuhkan, misalnya paket debug symbol.
    • Manajemen subscription offline. Ini yang tidak bisa dilakukan tool mirror generik.

    Catatan sebelum mencoba

    Beberapa hal yang perlu disiapkan:

    • Storage cukup besar. Untuk mirror Debian dan Proxmox VE dasar, Proxmox menyarankan minimal 150 GiB.
    • Host mirror berbasis Debian, CPU 64bit, idealnya 2 core atau lebih.
    • Untuk mirror repository enterprise, dibutuhkan subscription produk yang aktif sekaligus subscription POM sendiri. Kalau lab kalian pakai repo no-subscription, alurnya lebih sederhana dan tanpa key sama sekali.

    Penutup

    Intinya POM memindahkan beban koneksi internet dari host produksi ke satu mesin mirror. Host Proxmox tetap bisa dipatch rutin walaupun berada di jaringan tertutup. Untuk langkah instalasi dan konfigurasinya saya bahas terpisah di tulisan berikutnya. Semoga bermanfaat.

    Referensi

  • Memperbaiki Chrony Setelah Rollback Snapshot VM di Proxmox (Rocky 9)

    Memperbaiki Chrony Setelah Rollback Snapshot VM di Proxmox (Rocky 9)

    Setelah rollback snapshot, jam VM ikut mundur ke waktu snapshot dibuat. Kalau chrony tidak langsung menyinkronkan ulang, jam tetap salah dan service yang sensitif waktu ikut bermasalah. Panduan ini fokus memperbaiki jam lewat chrony di Rocky Linux 9.

    Informasi lab

    KomponenDetail
    HypervisorProxmox VE
    OS VMRocky Linux 9
    Time syncchrony (chronyd)
    Aksesroot atau sudo

    Kenapa chrony tidak otomatis membetulkan

    • Default makestep 1.0 3: chronyd cuma melompatkan (step) jam di 3 update pertama setelah start, sesudah itu hanya slew (koreksi pelan). Selisih besar praktis tidak kekejar.
    • Kalau sumber NTP tak terjangkau (firewall UDP 123, DNS, atau network putus), status chrony Not synchronised dan jam tidak dikoreksi sama sekali.
    • Snapshot include RAM mengembalikan VM dalam keadaan running dengan jatah step chrony sudah habis, jadi jam paling sering nyangkut di kondisi ini.

    1. Cek jam dan status chrony

    timedatectl
    chronyc tracking
    chronyc sources -v

    Tanda bermasalah: System clock synchronized: no, Leap status : Not synchronised, offset besar, atau kolom Reach masih 0. Kalau Reach sudah 377, sumber NTP sehat.

    2. Paksa chrony step jam

    Kalau sumber NTP sudah terjangkau, lompatkan jam ke waktu benar:

    chronyc makestep

    Verifikasi:

    timedatectl

    Diharapkan waktu sudah benar dan System clock synchronized: yes.

    Kalau makestep belum mempan, pakai mode one-shot (ganti pool sesuai kebutuhan):

    systemctl stop chronyd
    chronyd -q 'pool 2.rocky.pool.ntp.org iburst'
    systemctl start chronyd

    3. Kalau sumber NTP tak terjangkau

    Cek konfigurasi:

    cat /etc/chrony.conf

    Pastikan ada baris pool atau server. Default Rocky 9:

    # /etc/chrony.conf
    pool 2.rocky.pool.ntp.org iburst

    Untuk NTP internal, ganti (sesuaikan ntp.domain.lokal):

    # /etc/chrony.conf
    server ntp.domain.lokal iburst

    Terapkan

    systemctl restart chronyd

    Setelah Reach naik, ulangi chronyc makestep.

    Pencegahan

    • Pastikan chronyd aktif: systemctl enable --now chronyd.
    • Pasang QEMU Guest Agent supaya Proxmox bisa menyinkronkan waktu guest setelah snapshot atau resume, lalu aktifkan juga di menu Options VM:
    dnf install qemu-guest-agent -y
    systemctl enable --now qemu-guest-agent
    • Kalau sering rollback, biasakan langsung chronyc makestep sesudahnya.

    Troubleshooting

    GejalaPenyebabSolusi
    System clock synchronized: no, jam mundurSelisih besar, chrony cuma slewchronyc makestep
    Reach 0 atau sumber ?Sumber NTP tak terjangkauPerbaiki chrony.conf, buka UDP 123, lalu makestep
    Jam mundur lagi tiap rollbackSnapshot include RAM atau guest agent matiAktifkan qemu-guest-agent, biasakan makestep

    Penutup

    Kalau ada service bermasalah sesudah rollback, cek jam dan chrony dulu sebelum menyalahkan aplikasinya. Semoga bermanfaat.

    Referensi

    • Chrony Frequently Asked Questions: https://chrony.tuxfamily.org/faq.html
    • Manual: man chrony.conf dan man chronyc
  • Mengaktifkan Repository Debug Symbol (dbgsym) di Proxmox VE 9

    Mengaktifkan Repository Debug Symbol (dbgsym) di Proxmox VE 9

    Proxmox baru saja merilis repository khusus untuk paket debug symbol di https://dbgsym.proxmox.com/. Paket -dbgsym berisi informasi debug untuk paket binary pasangannya, berguna saat kalian perlu menganalisis crash atau hang dengan tools seperti gdb, systemd-coredump, atau crash. Repository ini berlaku untuk Proxmox VE, PBS, PMG, dan PDM berbasis Debian 12 (Bookworm) dan Debian 13 (Trixie). Di panduan ini saya contohkan implementasi dan pengujiannya di Proxmox VE 9 (Trixie).

    Informasi Lab

    ItemKeterangan
    ProdukProxmox VE 9 (Debian 13 Trixie)
    Nodepverafi1
    Aksesroot via SSH atau shell web UI
    KebutuhanKoneksi internet ke dbgsym.proxmox.com

    Catatan: paket dbgsym bersifat inert (tidak mempengaruhi operasi normal), jadi aman dipasang di sistem production maupun test. Repository ini juga publik, tidak ada pembedaan enterprise atau no-subscription.

    1. Menambahkan Repository dbgsym

    Buat file repository dalam format deb822 di /etc/apt/sources.list.d/pve-dbgsym.sources:

    cat > /etc/apt/sources.list.d/pve-dbgsym.sources << 'EOF'
    Types: deb
    URIs: https://dbgsym.proxmox.com/debian/pve
    Suites: trixie
    Components: pve-dbgsym
    Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
    EOF

    Jika memakai versi lain, sesuaikan bagian produk pada URI dan component (pbs, pmg, pdm) serta suite (bookworm untuk Debian 12).

    Update index paket:

    apt update

    Pastikan repository baru ikut ter-fetch. Di output apt update harus muncul baris dari dbgsym.proxmox.com, kurang lebih seperti ini:

    Get: https://dbgsym.proxmox.com/debian/pve trixie InRelease

    Bisa juga dicek lewat:

    apt policy | grep dbgsym

    2. Melihat Paket dbgsym yang Tersedia

    Cek daftar paket debug symbol yang bisa dipasang:

    apt list 2>/dev/null | grep dbgsym | head -20

    Kalian akan melihat paket seperti pve-qemu-kvm-dbgsym, pve-manager-dbgsym, dan sebagainya.

    3. Instalasi Paket dbgsym

    Install paket dbgsym yang cocok dengan binary yang ingin kalian debug. Contoh untuk QEMU:

    apt install pve-qemu-kvm-dbgsym gdb -y

    Install gdb untuk pengujian di langkah berikutnya.

    Verifikasi file debug sudah masuk ke /usr/lib/debug:

    dpkg -L pve-qemu-kvm-dbgsym | head

    Output harus menunjukkan file di bawah /usr/lib/debug/.build-id/.

    4. Verifikasi Pasangan Build ID

    Setiap binary Linux modern punya identitas unik (build ID) yang dipakai gdb untuk mencari file debug pasangannya secara otomatis. Ambil build ID dari binary QEMU:

    readelf -n /usr/bin/qemu-system-x86_64 | grep "Build ID"

    Contoh output:

    Build ID: 1d5ac8f0a05d7978645a38aaeac6cd9e6f32e539

    Cocokkan nilai ini dengan nama file di /usr/lib/debug/.build-id/ (dua karakter pertama jadi nama folder, sisanya jadi nama file .debug):

    ls /usr/lib/debug/.build-id/1d/

    Kalau muncul file 5ac8f0a05d7978645a38aaeac6cd9e6f32e539.debug, berarti file debug untuk binary tersebut sudah lengkap dan siap dipakai gdb. Kalau tidak ada, berarti versi paket binary dan dbgsym tidak sinkron (lihat troubleshooting).

    Catatan: pengecekan dengan gdb -batch -ex quit <binary> sering dipakai sebagai tes cepat, tapi pesan Reading symbols from ... tidak selalu tampil di mode batch meskipun symbol sudah terbaca dengan benar. Jadi verifikasi build-id di atas lebih bisa diandalkan daripada mengandalkan ada tidaknya pesan tersebut.

    5. Pengujian dengan Proses Live

    Cara paling meyakinkan untuk membuktikan debug symbol benar-benar berfungsi adalah attach gdb ke proses QEMU yang sedang berjalan, tanpa mematikannya. VM akan freeze sesaat selama gdb attach, jadi gunakan VM test, bukan VM production.

    Cari PID proses QEMU untuk VM tertentu. Proxmox menyimpan PID di /var/run/qemu-server/<VMID>.pid:

    cat /var/run/qemu-server/<VMID>.pid

    Attach gdb ke PID tersebut, ambil backtrace semua thread, lalu langsung lepas:

    gdb -batch -p <PID> -ex "thread apply all bt" -ex detach -ex quit

    Kalau debug symbol berfungsi, backtrace akan menunjukkan nama fungsi dan lokasi source, bukan alamat mentah. Contoh potongan hasil pengujian saya di thread utama QEMU:

    Thread 1 (Thread ... "kvm"):
    #5  qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../util/qemu-timer.c:343
    #6  0x... in os_host_main_loop_wait (timeout=989602) at ../util/main-loop.c:308
    #7  main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:592
    #8  0x... in qemu_main_loop () at ../system/runstate.c:946
    #9  0x... in qemu_default_main (opaque=opaque@entry=0x0) at ../system/main.c:50
    #10 0x... in main (argc=<optimized out>, argv=<optimized out>) at ../system/main.c:93
    [Inferior 1 (process ...) detached]

    Dua hal yang wajar muncul di output dan bukan tanda gagal:

    • Baris ?? () from /lib/x86_64-linux-gnu/libc.so.6: berasal dari glibc, di luar cakupan paket pve-qemu-kvm-dbgsym. Kalau mau symbol glibc ikut terbaca, perlu paket debug terpisah dari Debian (libc6-dbg).
    • Thread seperti kvm-nx-lpage-re atau iou-wrk-* yang menunjukkan Cannot access memory at address 0x0: ini kernel worker thread, gdb memang tidak bisa unwind stack userspace untuk thread jenis ini.

    Troubleshooting

    GejalaPenyebabSolusi
    apt update error 404 di repo dbgsymSuite atau produk di file .sources tidak sesuaiCocokkan suite (trixie/bookworm) dan produk (pve/pbs/pmg/pdm) dengan sistem kalian
    Error NO_PUBKEY atau signatureFile keyring tidak adaPastikan paket proxmox-archive-keyring terpasang: apt install proxmox-archive-keyring
    gdb tetap bilang no debugging symbolsVersi paket binary dan dbgsym tidak samaJalankan apt update && apt upgrade agar versi keduanya sinkron, lalu install ulang paket dbgsym
    Dulu install debug package dari repo standar, sekarang tidak dapat updatePaket dbgsym sudah dipindah ke repo terpisahTambahkan repository dbgsym seperti langkah 1

    Penutup

    Dengan repository ini, kalian tidak perlu lagi mencari paket debug di repo standar saat menganalisis crash di Proxmox. Semoga bermanfaat.

    Referensi

  • Turnkey di Proxmox: 100+ Appliance Siap Pakai

    Turnkey di Proxmox: 100+ Appliance Siap Pakai

    Hari ini saya baca-baca artikel di Virtualization Howto, salah satu blog yang cukup sering saya buka kalau cari tahu update terbaru tentang proxmox maupu virtualisasi. Ada satu tulisan yang baru yaitu tentang pembahasan soal fitur Proxmox yang menyediakan lebih dari 100 TurnKey Linux appliance.

    Yang bikin saya penasaran istilah turnkey di lxc proxmox. Jadi tulisan adalah untuk memahami lebih lanjut turnkey yang ada di proxmox, plus bagian kapan kalian sebaiknya pakai appliance turnkey dan kapan lebih baik pakai Docker saja.

    Turnkey itu istilah, bukan nama produk

    Ini yang sempat bikin saya bingung di awal. Turnkey adalah istilah umum, bukan merek. Asalnya dari frasa turn the key, seperti mobil yang tinggal putar kunci lalu jalan. Kalian tidak perlu merakit mesinnya dulu.

    Di dunia IT, turnkey solution berarti sistem yang sudah dirakit, dikonfigurasi, dan diuji oleh pihak lain, lalu diserahkan ke kalian dalam kondisi siap dipakai. Lawan katanya adalah build it yourself, di mana kalian install OS kosong, pasang web server, database, aplikasi, dan sambungkan semuanya sendiri.

    Di konteks virtualisasi, wujud turnkey biasanya adalah virtual appliance: satu image VM atau container yang di dalamnya sudah berisi OS plus aplikasi yang sudah dikonfigurasi. Kalian tinggal import, nyalakan, isi password, selesai.

    Nah, kebetulan ada proyek yang namanya persis seperti istilahnya, yaitu TurnKey Linux. Di sinilah kebingungan saya berasal.

    TurnKey Linux, proyeknya

    TurnKey Linux adalah proyek yang membuat kumpulan appliance siap pakai berbasis Debian. Satu appliance berisi satu aplikasi lengkap dengan semua dependensinya yang sudah dikonfigurasi.

    Beberapa hal yang perlu kalian tahu soal proyek ini:

    • Basisnya Debian standar, bukan distro eksotis. Jadi apt, systemd, dan struktur direktorinya tetap seperti Debian yang kalian kenal.
    • Tersedia dalam banyak format: ISO, image VM, dan yang paling relevan buat kita, template LXC yang langsung didukung Proxmox.
    • Ada wizard inisialisasi yang jalan saat pertama kali login, meminta root password, password admin aplikasi, dan alamat email untuk notifikasi.
    • Tiap appliance biasanya membawa confconsole (menu konfigurasi berbasis teks, termasuk untuk request sertifikat Let’s Encrypt) dan panel web administrasi. Port panelnya berbeda-beda tergantung appliance, jadi cek langsung di layar setelah boot.

    Di Proxmox, ini bukan fitur baru

    Poin yang diangkat artikel tadi memang tepat: template TurnKey ini bukan fitur baru, hanya jarang dilirik. Kebanyakan orang buka menu CT Templates, lihat debian-12-standard, ambil itu, lalu tutup jendelanya. Padahal di bawahnya ada ratusan baris lagi.

    Kalian bisa cek sendiri dari shell node Proxmox:

    pveam update
    pveam available | grep turnkey
    

    Atau kalau mau lebih rapi, filter langsung per section:

    pveam available --section turnkeylinux
    

    Daftarnya panjang sekali. Untuk gambaran, ini sebagian kategori yang tersedia:

    KategoriContoh appliance
    DatabasePostgreSQL, MySQL, MongoDB, Redis, CouchDB
    File dan syncFile Server (Samba), Nextcloud, Syncthing
    Jaringan dan VPNWireGuard, OpenVPN, OpenLDAP
    DevOpsGitea, GitLab, Jenkins, Ansible
    Framework aplikasiDjango, Laravel, Rails, Node.js, ASP.NET Core, Symfony, Tomcat
    BisnisOdoo, SuiteCRM, EspoCRM, Mattermost, Snipe-IT, Invoice Ninja, Leantime

    Yang menarik dari artikel sumbernya, penulisnya menyoroti appliance File Server. Begitu container dinyalakan, kalian langsung disambut setup Samba, bukan disuruh install dan konfigurasi smb.conf dari nol.

    Cara memakainya

    Lewat GUI, jalurnya seperti ini:

    1. Pilih node, lalu masuk ke storage local.
    2. Buka tab CT Templates, klik Templates.
    3. Ketik turnkey di kolom pencarian, pilih appliance yang kalian mau, klik Download.
    4. Klik Create CT, dan di tab Template pilih file yang barusan diunduh.

    Lewat CLI, unduhnya begini. Salin nama template persis dari output pveam available, karena nomor versinya berubah seiring rilis:

    pveam download local debian-12-turnkey-gitea_18.1-1_amd64.tar.gz
    

    Setelah container jalan, login ke konsolnya. Wizard inisialisasi akan meminta password dan beberapa isian dasar, lalu aplikasinya sudah siap diakses.

    Kelebihan appliance turnkey

    Saya lihat nilainya ada di beberapa hal berikut:

    • Cepat sekali. Dari nol sampai aplikasi jalan bisa di bawah lima menit, dibanding satu jam kalau kalian rakit sendiri.
    • Konfigurasinya sudah masuk akal. Web server, database, dan koneksi antar keduanya sudah disiapkan orang yang paham aplikasinya.
    • Basis Debian yang familiar. Kalau ada yang perlu diubah, kalian masuk saja dan edit seperti biasa. Tidak ada abstraksi aneh yang harus dipelajari dulu.
    • Ringan karena LXC. Bukan full VM, jadi overhead-nya kecil dan cocok buat homelab dengan RAM terbatas.
    • Bagus untuk belajar. Ini yang sering diremehkan. Kalian bisa masuk ke appliance yang sudah jadi dan lihat bagaimana orang lain menyusun konfigurasinya. Itu bahan belajar yang bagus.
    • Backup dan snapshot Proxmox tetap berlaku. Karena ini container biasa, vzdump dan snapshot jalan normal.

    Kekurangan yang perlu kalian sadari

    Artikel sumbernya tidak banyak membahas sisi ini, jadi bagian berikut lebih ke pertimbangan saya sendiri.

    • Kalian mewarisi keputusan orang lain. Konfigurasinya sudah jadi, tapi kalian tidak otomatis tahu apa saja yang diubah dari default. Untuk lab tidak masalah. Untuk produksi, kalian tetap harus audit isinya.
    • Versi aplikasi menempel ke rilis appliance. Update aplikasi tidak selalu mengikuti rilis upstream secepat yang kalian mau, karena tergantung maintainer appliance-nya.
    • Upgrade major itu merepotkan. Umumnya polanya bukan upgrade di tempat, melainkan bikin container baru lalu migrasi data. Ini beban yang perlu diperhitungkan sejak awal.
    • Satu appliance satu aplikasi. Sepuluh aplikasi berarti sepuluh container dengan sepuluh OS yang harus kalian patch dan pantau masing-masing.
    • Tidak declarative. Tidak ada file yang bisa kalian commit ke git. Kalau container ini hilang, kalian mengulang wizard dan konfigurasi manual lagi, tanpa jejak yang bisa direproduksi.
    • Kalau ujungnya kalian kustomisasi berat, keuntungannya habis. Begitu kalian ganti banyak hal di dalamnya, kalian sebenarnya sudah kembali ke mode rakit sendiri, tapi dengan titik awal yang tidak kalian dokumentasikan.

    Turnkey atau Docker?

    Sebelum masuk tabel, ada satu hal yang perlu diluruskan. Keduanya sebenarnya menjawab masalah di lapisan yang berbeda.

    Appliance turnkey menjawab “tolong siapkan mesin lengkap untuk saya”. Hasilnya satu sistem operasi utuh dengan systemd, cron, dan banyak service di dalamnya. Docker menjawab “tolong jalankan proses ini dengan dependensi yang tetap”. Hasilnya unit yang lebih kecil, sekali pakai, dan definisinya tertulis dalam file.

    Jadi pertanyaannya bukan mana yang lebih bagus, tapi kebutuhan kalian sedang di lapisan yang mana.

    Perbandingan karakteristik

    AspekTurnKey (LXC appliance)Docker
    Waktu setup awalSangat cepat, wizard interaktifCepat kalau compose file sudah ada
    Bentuk konfigurasiManual di dalam containerTertulis di docker-compose.yml
    ReproducibilityRendah, sulit diulang persisTinggi, tinggal jalankan ulang file yang sama
    Update aplikasiIkut rilis applianceGanti tag image, biasanya lebih dekat ke upstream
    Beban perawatanSatu OS penuh per aplikasiSatu host OS untuk banyak aplikasi
    Cocok untuk CI/CDLemahKuat, memang dirancang untuk itu
    Aplikasi multi-service legacyNyaman, karena ada systemdSering perlu akal-akalan

    Tabel pemilihan

    Ini bagian yang paling praktis. Cari baris yang paling mirip situasi kalian.

    Situasi kalianPilihAlasan
    Mau coba software baru, belum tahu bakal dipakai atau tidakTurnKeyLima menit siap, kalau tidak cocok tinggal hapus container
    Layanan produksi jangka panjangDockerUpdate dan rollback lebih terkendali
    Konfigurasi harus tercatat di git (IaC atau GitOps)DockerCompose file bisa di-commit, appliance tidak
    Demo ke klien atau bahan training, harus cepat siapTurnKeyTampil jadi tanpa waktu persiapan panjang
    Butuh stack lengkap tapi malas meracik sendiriTurnKeyWeb server dan database sudah disambungkan
    Ada pipeline CI/CD yang rebuild otomatisDockerAppliance tidak punya jalur otomatisasi ke arah ini
    Banyak aplikasi menumpuk di satu hostDockerTidak perlu merawat OS terpisah untuk tiap aplikasi
    Aplikasi legacy yang butuh systemd dan banyak serviceTurnKeyLXC memang perilakunya seperti VM kecil
    Lab sementara yang minggu depan dihapusTurnKeyUmurnya pendek, tidak perlu investasi konfigurasi
    Orang lain harus bisa reproduce environment kalianDockerCukup kirim satu file, hasilnya sama
    Mau update aplikasi mengikuti upstream secepatnyaDockerTidak menunggu rilis appliance
    Kalian sedang belajar dan ingin lihat konfigurasi yang benarTurnKeyBisa dibongkar isinya sebagai bahan belajar

    Pola yang muncul kira-kira begini. Kalau umur layanannya pendek dan yang kalian butuhkan adalah kecepatan, pilih TurnKey. Kalau umurnya panjang dan yang kalian butuhkan adalah kontrol serta pengulangan, pilih Docker.

    Penulis artikel sumbernya sampai di kesimpulan yang sama. Untuk layanan jangka panjang, Docker tetap menang di tempatnya karena jauh lebih enak diotomatisasi. TurnKey dia pakai untuk evaluasi software, belajar platform baru, proof of concept, dan environment sementara.

    Kesimpulan

    Saya senang akhirnya duduk dan memastikan arti istilah turnkey, karena ternyata konsepnya sederhana: sistem yang sudah dirakitkan orang lain sampai tinggal pakai. Dan template TurnKey Linux di Proxmox memang layak dilirik, terutama karena sudah ada di depan mata tanpa perlu install apa-apa lagi.

    Buat saya posisinya jelas. TurnKey itu alat untuk mempercepat fase mencoba, bukan pengganti Docker untuk layanan yang kalian rawat bertahun-tahun. Lain kali kalau kalian penasaran dengan software baru dan malas menyiapkan lab-nya, coba dulu pveam available | grep turnkey sebelum buka dokumentasi instalasi manual. Lumayan menghemat sore.

    Referensi