Rafi Harlianto

Informatics Engineering

Tag: homelab

  • 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

  • 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

  • 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

  • Troubleshoot Zimbra Level 1: MTA yang Berhenti

    Troubleshoot Zimbra Level 1: MTA yang Berhenti

    Tulisan saya kali ini yaitu, catatan satu ronde latihan drill troubleshooting di lab Zimbra. Aturannya saya susun sendiri bersama Claude Code, Claude yang menyuntikkan fault ke server lab tanpa memberi tahu apa yang dirusak, saya yang mendiagnosis dan memperbaiki. Level 1 ini pemanasan, satu masalah dengan error yang seharusnya cukup terang kalau saya cek di tempat yang benar. Ada baiknya baca dulu Latihan Troubleshooting dengan Claude Code di tulisan saya sebelumnya agar paham konsep dan aturan main drill-nya.

    Tiket

    Sesi dimulai seperti biasa, saya pilih platform Zimbra dan level 1, Claude memastikan SSH ke node lab jalan dan snapshot sudah ada, lalu menyuntikkan fault-nya secara diam-diam. Yang saya terima cuma ini:

    Tiket: «User lapor email keluar dan masuk berhenti total sejak beberapa menit lalu. Webmail masih bisa login, tapi kirim email nyangkut.»

    Aturan mainnya disebutkan di awal: saya kerja sendiri, boleh minta hint kalau perlu, dan tiap hint mengurangi skor.

    Investigasi

    Tidak ada informasi lain selain tiket di atas. Karena webmail masih bisa diakses tapi pengiriman macet, langkah pertama saya selalu sama, lihat status zimbra dulu:

    Via CLI

    su - zimbra
zmcontrol status

    Ketemu. Komponen mta dan yang berhubungan dengan mta stopped, komponen yang menjalankan Postfix. Ini sesuai dengan tanda-tanda nya, webmail (mailbox) jalan, tapi pengiriman (mta) mati.

    Tips: Sebelum menyalakan apa pun, cek dulu antrian mail untuk pastikan email cuma tertahan, bukan hilang:

    su - zimbra -c 'mailq'

    Coba Fitur Hint

    Karena ada fitur hint di drill ini, saya sengaja minta supaya tahu seperti apa bentuk hint nya.

    Claude kasih Hint 1 (dari 3 hint) sesuai urutan bertingkat yang sudah dia siapkan: «Ini bukan masalah mailbox/store, gejalanya di layer pengiriman (MTA).» Isinya memang sudah ketemu lewat zmcontrol status, jadi saya lanjut ke fix tanpa minta hint kedua.

    Fix

    Tinggal nyalakan lagi komponen MTA-nya:

    su - zimbra 
zmmtactl start

    Setelah zmcontrol status saya cek ulang dan semua komponen kembali «Running», saya bilang ke Claude Code kalau saya sudah selesai.

    Verifikasi

    Claude tidak langsung percaya status «Running» saja. Dia jalankan verifikasi fungsional lewat SSH ke node lab: cek ulang zmcontrol status, cek mailq untuk pastikan antrian yang tadi tertahan mulai jalan, lalu kirim email uji dan bandingkan hasilnya ke baseline yang direkam sebelum fault disuntikkan. Semua cocok, gejalanya hilang karena root cause-nya memang sudah benar diperbaiki, bukan cuma ditutupi.

    Debrief dan skor

    Baru di titik ini Claude membuka kartunya. Root cause-nya persis seperti dugaan saya, service MTA (Postfix) dihentikan manual lalu dinyalakan kembali. Claude jelaskan kenapa fault ini realistis, di dunia nyata ini sering kejadian waktu ada maintenance atau restart manual yang lupa dinyalakan lagi setelahnya.

    Skor saya 8.5 dari 10, dipotong karena pakai satu hint meski sebenarnya lebih untuk coba-coba daripada kebutuhan. Hasil ini dicatat ke progress.md di project drill saya, jadi kelihatan riwayatnya kalau saya naik level nanti.

    Penutup

    Ronde ini singkat, cek status dulu secara menyeluruh sebelum menyentuh apa pun yang kelihatan mati. Level 1 memang dirancang begitu, satu masalah, error yang cukup terang asal dicek di tempat yang benar. Sampai jumpa di Level 2.

  • Latihan Troubleshooting dengan Claude Code

    Latihan Troubleshooting dengan Claude Code

    Jadi hari ini saya mencoba mengasah kemampuan troubleshooting, khususnya pada aplikasi yang dapat diimplementasikan secara on-premise seperti mail server (Zimbra dan Carbonio), platform virtualisasi (Proxmox VE), serta file management (Nextcloud). Menurut saya, kemampuan troubleshooting adalah salah satu keterampilan yang harus terus diasah karena sangat dibutuhkan saat mengelola infrastruktur. Namun, ada satu hal yang sampai sekarang masih sering membuat saya bingung ketika ingin belajar troubleshooting, diantara lain:

    • Saya gonta-ganti konfigurasinya sendiri (oprek)
    • Menunggu ada update/patch/bug terbaru
    • atau, menunggu aplikasi failure/error dengan sendirinya

    Kalau oprek sendiri dengan skill teknis minim seperti saya malah-malah merembet kemana-mana, kalau menunggu update bisa berbulan-bulan, dan apalagi kalau nunggu aplikasi failure nanti malah tidak latihan.

    Masalahnya, menunggu insiden itu tidak efisien. Jadi saya balik logikanya. Saya menjadikan Claude Code untuk merusak lab saya sendiri dengan pola yang realistis, lalu saya yang mendiagnosis dan memperbaiki. Anggap saja latihan tanding, tapi lawannya adalah AI yang paham error apa saja yang biasa terjadi di Proxmox, Nextcloud, Zimbra, atau Carbonio.

    Konsepnya

    Aturannya cuma satu yang penting: Claude berperan sebagai fasilitator, bukan tukang benerin. Tugas dia merusak, memberi gejala, dan memberi petunjuk kalau saya mentok. Yang mendiagnosis dan memperbaiki tetap saya.

    Alurnya kira-kira begini:

    1. Saya pilih platform dan level kesulitan.
    2. Claude menyuntikkan satu fault via SSH, tanpa memberi tahu apa yang dia rusak. (sebenernya mau pake MCP tapi belum paham)
    3. Saya cuma dikasih gejala, seperti tiket dari user. Misalnya “email keluar nyangkut sejak pagi”.
    4. Saya investigasi sendiri. Kalau mentok, boleh minta hint, tapi skornya berkurang.
    5. Setelah saya bilang selesai, Claude verifikasi dan kasih skor.

    Kuncinya ada di poin ketiga. Saya tidak dikasih tahu root cause-nya. Persis seperti simulasi production, saya cuma pegang gejala dan harus menelusuri sendiri sampai ke akar.

    Level 1 sampai 5

    Biar latihannya naik kelas, saya bagi lima level. Makin tinggi, makin dekat ke insiden produksi yang sebenarnya.

    LevelKarakter faultContoh
    1Satu masalah jelas, error terang di logService ke-stop, typo di config
    2Satu masalah, gejala kurang gamblangPort diblok firewall, cert expired
    3Gejala tak langsung lewat dependensiLDAP mati bikin semua auth gagal
    4Cascading, satu akar banyak gejalaDisk penuh, quorum cluster hilang
    5Beberapa masalah sekaligus, butuh metodeFault kombinasi lintas layer

    Level 1 itu pemanasan. Level 5 memaksa saya berpikir sistematis, memisahkan gejala satu per satu, dan menahan diri dari asumsi buru-buru.

    Penutup: Backup, backup, backup

    Sengaja merusak sistem tetap butuh rem. Ada dua aturan yang dibutuhkan

    • Pertama, backup atau snapshot dulu sebelum apa pun.
    • Kedua, kunci jawaban terpisah di folder sementara. Kalau saya baca duluan, latihan jadi percuma. Biar disiplin aja.

    Latihan ini akan dijalankan besok. Stay tune!