Rafi Harlianto

Informatics Engineering

Author: Rafi Harlianto

  • Thin Provision di ZFS Proxmox: Kelalaian Kecil yang Bikin I/O Error

    Thin Provision di ZFS Proxmox: Kelalaian Kecil yang Bikin I/O Error

    Minggu lalu saya ikut training Proxmox yang berlangsung Sabtu dan Minggu. Salah satu materinya membahas storage tipe ZFS. Di sela sesi saya lupa mencentang opsi Thin Provision saat membuat storage ZFS. Hasilnya, penggunaan disk cepat mencapai 100 persen dan VM langsung kena I/O error. Tulisan ini saya buat supaya kejadian ini tidak terulang, sekaligus jadi catatan untuk kalian yang baru belajar Proxmox.

    Apa itu Thin Provision

    Thin provision adalah metode alokasi storage di mana ruang disk hanya dipakai sesuai data yang benar benar ditulis, bukan sesuai ukuran disk yang didefinisikan di awal.

    Di ZFS, istilah resminya adalah sparse volume. Menurut dokumentasi resmi Proxmox, sparse volume adalah volume yang reservation nya tidak sama dengan ukuran volume itu sendiri.

    Gambarannya seperti ini:

    ModeUkuran disk virtualRuang yang langsung dikunci di pool
    Thin (sparse)100 GBSesuai data terpakai, misal 10 GB
    Thick (non sparse)100 GB100 GB langsung dikunci dari pool

    Kenapa Lupa Centang Bikin I/O Error

    Kalau opsi Thin Provision tidak dicentang, Proxmox membuat zvol dengan refreservation penuh. Artinya seluruh ukuran disk yang didefinisikan langsung dikunci dari pool ZFS sejak awal, walau isinya masih kosong.

    Kejadian saya waktu training kira kira begini:

    • Storage ZFS dibuat dengan ukuran pool yang terbatas.
    • Beberapa disk VM dibuat dengan ukuran cukup besar.
    • Karena Thin Provision tidak aktif, seluruh ukuran disk langsung teralokasi penuh di pool.
    • Pool ZFS cepat penuh walau data yang benar benar ditulis jauh lebih kecil.
    • Begitu pool mencapai 100 persen, VM langsung I/O error karena tidak ada ruang kosong untuk menulis data baru.

    Hal ini juga dikonfirmasi di forum resmi Proxmox. Salah satu pengguna menjelaskan kalau opsi thin dicentang saat membuat storage, virtual disk akan benar benar thin provisioned dan ruang yang belum terpakai tidak akan memakan kapasitas pool.

    Cara Mengaktifkan Thin Provision

    Saat membuat storage baru

    1. Buka Datacenter > Storage > Add > ZFS.
    2. Isi ID dan pilih ZFS Pool yang dipakai.
    3. Centang opsi Thin provision.
    4. Klik OK.

    Posisinya seperti di gambar yang saya lampirkan, opsi Thin provision ada di kolom kanan, sejajar dengan Enable dan Block Size.

    Mengaktifkan di storage yang sudah ada

    Kalau storage sudah dibuat seperti kasus saya, caranya:

    1. Datacenter > Storage > pilih storage ZFS yang dimaksud > Edit.
    2. Centang Thin provision.
    3. Klik OK.

    Catatan penting, perubahan ini hanya berlaku untuk disk VM yang dibuat setelah opsi diaktifkan. Disk yang sudah ada sebelumnya tetap thick provision. Kalau mau disk lama jadi thin juga, ada dua cara:

    • Pindahkan disk ke storage lain lalu kembalikan lagi ke storage ZFS yang sama, proses ini akan membuat ulang zvol.
    • Set manual lewat CLI dengan zfs set refreservation=none nama-pool/nama-zvol.

    Lewat file konfigurasi

    Opsi ini juga bisa diatur langsung di /etc/pve/storage.cfg dengan menambahkan baris sparse:

    zfspool: nama-storage
    pool nama-pool
    content images,rootdir
    sparse

    Yang Perlu Diperhatikan

    • Thin provision butuh dukungan discard atau TRIM yang jalan penuh, dari sistem di dalam VM, lewat virtio, sampai ke pool ZFS. Kalau salah satu putus, ruang yang sudah dihapus di VM tidak akan balik kosong di pool.
    • Pakai controller Virtio SCSI single dan aktifkan opsi Discard di hardware disk VM.
    • Pantau penggunaan pool secara rutin dengan zfs list atau dari menu Datacenter > Storage, supaya tidak kejadian pool penuh tanpa disadari, sekalipun sudah thin provision.

    Penutup

    Satu centang kecil ternyata berdampak besar ke operasional. Sejak kejadian ini saya selalu cek ulang opsi Thin provision setiap kali membuat storage ZFS baru, baik di homelab maupun di environment client.

    Referensi

    • Dokumentasi resmi Proxmox, Storage ZFS: https://pve.proxmox.com/wiki/Storage:_ZFS
    • Forum Proxmox, How to enable thin provisioning on ZFS: https://forum.proxmox.com/threads/how-to-enable-thin-provisioning-on-zfs.92801/
    • Forum Proxmox, Thin Provision after the fact: https://forum.proxmox.com/threads/thin-provision-after-the-fact.132568/
  • Cicak di Dinding

    Cicak di Dinding

    Waktu kecil kita semua hafal lagu cicak yang merayap pelan di dinding, lalu datang nyamuk dan langsung disambar. Lagu sederhana, tapi kalau direnungkan lagi sebagai orang dewasa, ada satu hal yang menarik.

    Cicak tidak bisa terbang. Gerakannya lambat, cuma merayap, menempel di dinding. Sementara mangsanya, nyamuk, punya sayap dan bisa terbang bebas. Secara logika, harusnya cicak kesulitan. Tapi kenyataannya cicak tetap kenyang. Nyamuk yang lincah itu tetap saja masuk ke mulutnya.

    Buat saya, ini gambaran yang pas soal rezeki. Yang sudah jadi bagian kita akan sampai juga dengan caranya sendiri, sekalipun lewat jalan yang tidak masuk akal. Kita sering merasa kalah saing, merasa orang lain lebih cepat dan lebih lincah, lalu khawatir bagian kita keduluan diambil. Padahal cicak menunjukkan sebaliknya.

    Tapi bukan berarti diam saja. Cicak tetap merayap, tetap mengincar, tetap menyergap di waktu yang tepat. Ia tidak menganga menunggu nyamuk jatuh sendiri. Artinya, percaya rezeki sudah ada bagiannya bukan alasan untuk malas. Diamnya cicak di dinding itu juga bentuk usaha, bukan pasrah total.

    Jadi lain kali kalau kalian lihat cicak menempel di dinding, ingat lagi pelajaran sederhananya. Yang tidak bisa terbang tetap bisa makan yang bersayap. Tugas kita cuma satu: terus berusaha di posisi masing-masing.

  • Checklist Keamanan Proxmox VE: 2FA, RBAC, Firewall, Update, dan Remote Access

    Checklist Keamanan Proxmox VE: 2FA, RBAC, Firewall, Update, dan Remote Access

    Sebagian besar insiden di lingkungan virtualisasi itu bukan karena teknik hacking canggih. Biasanya pemicunya sederhana: password dipakai ulang, web UI bisa diakses dari internet, atau patch ditunda terus karena dianggap merepotkan.

    Yang bikin Proxmox beda dari server biasa, dia itu management plane. Anggap saja Proxmox sebagai panel kendali untuk seluruh VM dan container kalian. Jadi kalau penyerang berhasil masuk ke Proxmox, dia tidak cuma menguasai satu VM. Dia bisa mount disk VM lain, menyalin datanya, membaca output console (yang sering memuat password), sampai mengubah jaringan. Singkatnya, “admin di UI Proxmox” itu hampir sama bahayanya dengan “root di servernya langsung”.

    Tulisan ini rangkuman dari checklist keamanan Proxmox di cr0x.net, saya tulis ulang biar lebih mudah dipahami.

    Lima prioritas

    Kalau bingung mau mulai dari mana, kerjakan lima hal ini dulu sesuai urutan:

    1. Buat panel Proxmox tidak bisa diakses dari jaringan sembarangan. Idealnya cuma lewat VPN atau jaringan admin khusus.
    2. Wajibkan 2FA untuk semua akun manusia. Proses otomatis (script, automation) cukup pakai API token.
    3. Atur hak akses (RBAC) seperlunya saja. Pisahkan yang cuma “menjalankan VM” dari yang boleh “mengubah cluster”.
    4. Nyalakan firewall dengan prinsip tutup dulu lalu buka seperlunya, dan pastikan benar-benar jalan.
    5. Rutin patch secara bertahap, dan jangan takut reboot kalau memang perlu.

    Lima ini saya jabarkan satu per satu di bawah.

    2FA

    2FA (two-factor authentication) itu lapisan kedua selain password. Jadi walaupun password kalian bocor, penyerang tetap butuh kode dari HP kalian untuk bisa masuk. Anggap saja seperti sabuk pengaman, dia tidak mencegah semua masalah, tapi mencegah masalah kecil jadi fatal.

    Di Proxmox kalian bisa pakai TOTP (kode 6 digit dari aplikasi seperti Google Authenticator, ini paling gampang) atau WebAuthn (security key fisik).

    • Wajibkan untuk semua akun yang bisa login ke UI atau shell.
    • Jangan ada akun yang dipakai ramai-ramai. Kalau satu akun dipakai banyak orang, kalian tidak akan tahu siapa melakukan apa.
    • Untuk automation, pakai API token. Token bisa dibatasi haknya dan dirotasi tanpa mengganggu akun manusia.
    • Siapkan jalur darurat (break-glass) kalau HP 2FA hilang: kredensial disimpan offline, dengan prosedur dan catatan yang jelas.

    Satu hal yang sering bikin pusing: TOTP bergantung pada jam yang akurat. Kalau jam server melenceng karena NTP mati, kodenya bakal gagal terus untuk banyak orang sekaligus. Solusinya perbaiki NTP, bukan malah mematikan 2FA.

    RBAC

    RBAC itu sistem hak akses berbasis peran. Intinya kalian menentukan siapa boleh melakukan apa, dan di bagian mana.

    Yang perlu diingat, hak akses di Proxmox itu menurun dari atas ke bawah, mengikuti struktur datacenter ke node ke VM. Jadi kalau kalian kasih seseorang hak di level paling atas (/), otomatis dia punya hak itu di semua node dan semua VM. Ini sumber masalah yang paling sering: niatnya cuma kasih akses sementara, ujungnya orang itu bisa mengutak-atik seluruh infrastruktur.

    • Berikan peran ke group, bukan ke orang per orang. Orang bisa keluar masuk, group lebih mudah dikelola.
    • Pakai cakupan yang sempit. Misal operator VM cukup diberi akses di /vms atau pool tertentu, bukan di /.
    • Pisahkan “menjalankan” (start/stop VM) dari “mengubah infrastruktur” (menambah storage, gabung cluster).
    • Peran PVEAdmin di / itu praktis kekuasaan penuh. Simpan hanya untuk segelintir admin inti.

    Firewall

    Firewall bawaan Proxmox sebenarnya bagus, tapi banyak orang mengira cukup mencentang satu kotak di GUI lalu merasa aman. Padahal keamanan tidak boleh bergantung pada satu centang. Kalian perlu yakin rule-nya benar-benar diterapkan.

    Beberapa aturan yang sebaiknya tidak dilanggar:

    • Web UI (port 8006) dan SSH (port 22): hanya boleh diakses dari jaringan admin atau VPN.
    • Trafik cluster (Corosync, untuk komunikasi antar node): hanya antar node di jaringan cluster, dan jangan di-NAT.
    • Storage (NFS, iSCSI, Ceph): hanya antar pihak yang memang perlu, jangan dibuka ke semua.

    Prinsipnya tutup semua inbound dulu di interface management, baru buka yang benar-benar dibutuhkan. Setelah itu cek di dua tempat, level datacenter dan level node, lalu pastikan rule-nya benar-benar aktif di server, bukan cuma kelihatan aktif di UI. Dan ingat, server yang “bisa di-ping” itu belum tentu aman, karena penyerang tidak butuh ping, dia butuh port yang terbuka.

    Update

    Soal update ini lebih ke disiplin daripada teknis. Kuncinya jangan menunda, tapi juga jangan gegabah.

    • Update bertahap, satu node dulu. Kalau aman, baru lanjut ke node berikutnya. Tujuannya supaya kalau ada masalah, tidak semua node ikut tumbang.
    • Sediakan jadwal maintenance rutin, walau cuma sejam seminggu. Downtime yang terencana jauh lebih murah daripada downtime mendadak.
    • Update kernel artinya harus reboot. Boleh ditunda sebentar, tapi jangan dibiarkan berbulan-bulan.
    • Sesudah update, cek hal penting: quorum cluster, storage ke-mount, VM bisa start, backup jalan, dan firewall masih benar.

    Pisahkan juga di kepala kalian, security update itu mendesak, sedangkan feature update bisa diteliti dulu sebelum diterapkan.

    Remote access

    Cara paling aman mengelola Proxmox dari jarak jauh bukan dengan memperkuat pintu yang terbuka, tapi dengan mengurangi jumlah pintunya. “Boleh diakses dari internet asal pakai password kuat” itu bukan strategi yang aman.

    Pilih salah satu pola, jangan dicampur asal-asalan:

    1. VPN ke jaringan admin. Paling sederhana. Admin masuk VPN dulu, baru bisa mengakses Proxmox.
    2. Bastion atau jump host. Login dulu ke satu server perantara, baru lompat ke node Proxmox.
    3. Jaringan management khusus yang hanya bisa diakses dari kantor atau VPN.

    Untuk SSH-nya sendiri:

    • Pakai key, matikan login pakai password.
    • Matikan login root langsung. Pakai user biasa lalu sudo, supaya jejaknya tercatat.
    • Batasi IP yang boleh masuk ke subnet admin saja.

    Catatan penting: sebelum mengutak-atik konfigurasi SSH, pastikan kalian masih punya akses console (lewat IPMI, iLO, atau KVM). Buka juga sesi kedua saat menguji perubahannya. Ini biar kalau salah konfigurasi, kalian tidak terkunci dari server sendiri.

    Audit cepat

    Beberapa perintah ini bisa kalian jalankan di tiap node untuk mengecek kondisi saat ini:

    PerintahUntuk mengecek
    pvecm statusStatus quorum cluster. Kalau tidak quorate, jangan dulu ubah konfigurasi
    timedatectlApakah jam server sinkron (penting buat 2FA)
    pveum acl listDaftar siapa punya hak apa, di path mana
    pveum user token list <user>API token yang ada beserta masa berlakunya
    ss -lntpService apa saja yang listen dan di alamat mana
    sshd -TKonfigurasi SSH yang benar-benar berlaku
    journalctl -u pveproxyPercobaan login. Kalau ada IP asing, berarti panel kalian terekspos

    Langkah minggu ini

    Kalau mau langsung action, ini yang bisa dikerjakan minggu ini:

    1. Pastikan port 8006 dan 22 tidak bisa diakses dari jaringan luar.
    2. Aktifkan 2FA untuk semua orang (perbaiki NTP dulu).
    3. Bersih-bersih RBAC, terutama hapus PVEAdmin yang menempel di /.
    4. Cek firewall benar-benar aktif di datacenter dan node.
    5. Mulai biasakan patch bertahap.

    Tujuannya bukan bikin benteng yang mustahil ditembus. Tujuannya membuat akses ke Proxmox itu sengaja dibatasi, hak akses sengaja dipersempit, dan perubahan dilakukan secara rutin dan terkontrol.

    Referensi

  • Percobaan SSO dengan Authentik di Proxmox dan Hubungkan ke Nested Proxmox

    Percobaan SSO dengan Authentik di Proxmox dan Hubungkan ke Nested Proxmox

    Hari ini saya coba pasang Authentik sebagai Identity Provider (IdP) di homelab, lalu saya hubungkan ke nested Proxmox untuk testing. Tulisan ini rangkuman singkat dari instalasi sampai konfigurasi login OIDC-nya. Saya pakai metode LXC di Proxmox, bukan VM, karena lebih ringan untuk lab.

    Yang saya siapkan

    • LXC Debian, unprivileged, fitur nesting aktif
    • Spek: 2 core, 4 GB RAM, disk 20 GB
    • Nested Proxmox sebagai target testing login SSO

    1. Buat LXC atau VM

    2. Install Docker di dalam LXC

    apt update && apt install -y curl
curl -fsSL https://get.docker.com | sh
docker compose version

    3. Deploy Authentik

    mkdir -p /opt/authentik && cd /opt/authentik
wget https://docs.goauthentik.io/compose.yml

echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env

docker compose pull
docker compose up -d

    Catatan: jangan ubah atau mount /etc/timezone dan /etc/localtime di kontainer Authentik. Authentik jalan dengan timezone internal UTC, kalau diubah bisa merusak autentikasi OAuth dan SAML.

    4. Setup awal Authentik

    Buka http://IP-LXC:9000/if/flow/initial-setup/, lalu set password untuk user akadmin.

    5. Buat Application dan Provider untuk Proxmox

    Di admin interface, Applications > Applications > Create with provider:

    FieldNilai
    Application nameProxmox
    Provider typeOAuth2/OpenID Connect
    Redirect URIStrict, Authorization, https://IP-PVE:8006
    Signing keypilih yang tersedia
    Encryptionnonaktif
    Subject modeBased on the User’s Email

    Setelah submit, catat Client ID, Client Secret, dan slug aplikasi. Issuer URL-nya jadi http://IP-LXC:9000/application/o/<slug>/.

    6. Tambah realm OIDC di nested Proxmox

    Datacenter > Permissions > Realms > Add > Realm:

    FieldNilai
    Issuer URLhttp://IP-LXC:9000/application/o/<slug>/
    Realmauthentik
    Client ID(dari Authentik)
    Client Key(client secret dari Authentik)
    Username claimusername
    Autocreate usersaktif

    Atau lewat CLI:

    pveum realm add authentik --type openid \
  --issuer-url http://IP-LXC:9000/application/o/<slug>/ \
  --client-id <client_id> --client-key <client_secret> \
  --username-claim username --autocreate 1

    7. Beri hak akses user

    User hasil autocreate muncul tanpa role. Tambahkan lewat Datacenter > Permissions > Add > User Permission, path /, role Administrator saja untuk lab, misal akadmin@authentik.

    8. Tes login

    Logout dari Proxmox, di layar login pilih Realm > authentik, lalu login pakai akun Authentik. Kalau berhasil, Proxmox bikin user baru otomatis dan saya tinggal pakai sesuai role yang sudah diberikan.

    Penutup

    Authentik di LXC ini cukup ringan untuk lab, dan integrasi OIDC ke Proxmox tidak butuh banyak field. Bagian yang paling sering bikin gagal biasanya cuma dua, Issuer URL yang tidak persis sama, dan redirect URI yang tidak match dengan alamat Proxmox-nya.

  • Pengalaman Pertama Kunjungan Klien

    Pengalaman Pertama Kunjungan Klien

    Semua orang pasti pernah mengalami yang namanya pengalaman pertama, dalam hal apa pun. Entah itu pertama kali masuk sekolah, pertama kali bawa motor sendiri, atau pertama kali mulai kerja. Rasanya biasanya mirip-mirip, campuran antara gugup, penasaran, dan sedikit takut salah. Tapi justru dari momen pertama itulah biasanya kita belajar paling banyak.

    Nah, hari ini saya juga baru saja mengalami salah satu pengalaman pertama yang menurut saya cukup berkesan. Untuk pertama kalinya saya diberi kesempatan ikut kunjungan klien bersama tim, dan kebetulan lokasi yang kami tuju juga bukan klien sembarangan, clue tempatnya adalah “Istana”, jadi rasanya campur aduk (senang iya, gugup iya, semangat pun iya).

    Pagi-pagi sekitar jam delapan kurang, saya sudah sampai di markas bareng Pak Arif dan Mas Ridwan. Kami menyiapkan berkas-berkas yang perlu dibawa dulu, memastikan semuanya lengkap, lalu berangkat naik Grab menuju lokasi.

    Sesampainya di sana, suasananya langsung terasa berbeda. Kami masuk lewat pos penjagaan, dan ternyata pemeriksaannya cukup ketat, mirip seperti yang biasa kalau masuk bandara. Setelah itu kami diminta mengisi data identitas dan menukarnya dengan tanda pengenal tamu. Yang bikin saya cukup kaget, untuk bisa sampai ke ruangan yang dituju, kami harus menukar tanda pengenal tamu itu sampai tiga kali. Baru kali ini saya merasakan prosedur masuk suatu tempat seketat itu.

    Jujur saja, di awal saya cukup gugup. Maklum, ini pengalaman pertama dan saya belum terbiasa dengan situasi seperti ini. Tapi justru karena itu, saya jadi lebih fokus memperhatikan bagaimana para senior bekerja. Saya mengamati cara mereka berkomunikasi dengan klien, bagaimana menyampaikan materi dengan tenang, dan bagaimana menjawab pertanyaan secara teknis tanpa terlihat kaku. Buat saya, ini ilmu yang nggak bisa didapat cuma dari teori.

    Setelah pemaparan materi selesai, kami berpisah. Pak Arif harus kembali dulu untuk mengantarkan dokumen yang sempat tertinggal, sementara saya dan Mas Ridwan memutuskan mencari makan. Kami memilih daerah Summarecon Bekasi karena lokasinya dekat dengan markas dan pilihan tempat makannya banyak. Selesai makan, kami sempatkan ngopi sambil ngobrol santai soal pekerjaan dan menulis artikel ini, baru setelah itu kembali ke markas.

    Kalau ditanya gimana rasanya, saya senang sekali. Rasa gugup di awal tadi rasanya terbayar dengan pengalaman yang menurut saya tak tergantikan. Bisa melihat langsung bagaimana kunjungan klien berjalan, dari persiapan sampai pemaparan, adalah pelajaran berharga yang bakal saya ingat selalu.

  • Level-Level dalam System Administrator (Sysadmin)

    Level-Level dalam System Administrator (Sysadmin)

    Saya coba memetakan jenjang kemampuan sysadmin, dari yang baru mulai sampai yang jadi rujukan orang lain. Awalnya cuma catatan pribadi, tapi ternyata berguna buat melihat saya sendiri ada di mana dan apa yang masih kurang. Model lima level di bawah disusun dengan brainstorming dengan AI, tapi polanya sejalan dengan beberapa referensi karier sysadmin yang saya cantumkan di bagian akhir.

    Urutannya penting. Tiap level mengasumsikan level di bawahnya sudah solid, jadi tidak bisa loncat.

    Lima level sysadmin

    LevelNamaBisa apaIndikator lulus
    L0OperatorMenjalankan command yang diberikan, baca status servicePaham filesystem, proses, permission, systemd dasar
    L1AdministratorMengelola satu server sendirian dari awal sampai akhirPasang, konfigurasi, amankan satu service produksi tanpa dipandu
    L2Senior AdminTroubleshoot masalah tak terduga, kelola banyak serverBisa baca log dan menemukan root cause tanpa menebak
    L3ArchitectMendesain topologi multi-server, HA, dan disaster recoveryBisa menjelaskan trade-off tiap keputusan desain
    L4SpecialistAhli mendalam di satu domain plus otomasi penuhOrang lain yang bertanya ke kalian saat mereka mentok

    Beberapa catatan singkat untuk tiap lompatan:

    • L0 ke L1. Bedanya bukan jumlah command yang dihafal, tapi kemandirian. Di L1 kalian bisa dilepas mengurus satu server tanpa panik.
    • L1 ke L2. Ini lompatan terpenting. Troubleshooting jadi kemampuan utama, bukan lagi sekadar menjalankan instruksi. Masalah yang kelihatannya di satu layer kadang akarnya di layer lain, dan di L2 kalian mulai bisa membedakannya.
    • L2 ke L3. Berhenti cuma menjalankan dan memperbaiki, mulai mendesain. Yang membedakan: bisa menjelaskan kenapa memilih desain tertentu, bukan cuma tahu cara menjalankannya.
    • L3 ke L4. Spesialisasi mendalam plus otomasi sampai operasional harian minim sentuhan manual.

    Di mana saya sekarang

    Saya rasa posisi saya ada di L1. Kerjaan harian saya banyak soal Zimbra, Carbonio, dan Proxmox, dan sebagian besar waktu habis buat troubleshooting. Untuk arah L3, saya sudah pegang cluster Proxmox tiga node dengan Ceph di homelab, tapi masih banyak keputusan desain yang perlu saya pertajam alasannya, bukan cuma karena ini yang biasa dipakai.

    Kenapa ini penting

    Satu hal yang makin terasa sambil menjalani kerja sehari-hari: gampang terjebak merasa sudah jago hanya karena hafal banyak command. Padahal command itu cuma alat, bukan tujuan. Yang benar-benar membedakan level adalah seberapa dalam paham kenapa sesuatu bisa bekerja, dan seberapa berani mulai mendesain, bukan sekadar menjalankan.

    Buat yang juga pegang infrastruktur, coba taruh diri di salah satu level tadi. Tidak usah kaget kalau fondasinya ternyata masih ada yang bolong walau sehari-hari sudah ngurus sistem yang rumit. Saya pun begitu, baru ketahuan waktu balik mengecek ulang dasar-dasar sistem.

    Sumber

    Model di atas susunan saya sendiri, tapi konsep jenjang sysadmin dari operasional sampai arsitek ini umum dibahas. Beberapa referensi yang sejalan:

  • Belajar Sysadmin dengan Bantuan AI

    Bulan ini saya kebetulan menjalani dua hal sekaligus: membuat panduan belajar sysadmin untuk diri sendiri, dan mengikuti training AI yang diselenggarakan perusahaan. Dua hal yang awalnya terasa tidak berhubungan, tapi ternyata saling mengisi.

    Masalahnya bukan kurang materi

    Kalau kalian bekerja di bidang infrastruktur, pasti tahu rasanya: materi belajar melimpah, tapi arah belajarnya yang tidak jelas. Tutorial bertebaran di mana-mana, dokumentasi resmi panjang, forum penuh jawaban yang kadang kontradiktif. Yang susah bukan menemukan konten, tapi menyusun urutan belajar yang masuk akal untuk situasi kerja nyata.

    Saya sendiri sehari-hari mengelola Zimbra, Carbonio, Proxmox, dan beberapa layanan terkait. Sudah cukup lama berkutat di sana. Tapi saya sadar ada juga celah, teori yang saya lewati karena sibuk troubleshooting, konsep yang saya pakai tanpa benar-benar memahami dasarnya.

    Dari situlah ide membuat panduan belajar sendiri muncul.

    AI sebagai partner menyusun, bukan sekadar menjawab

    Yang saya lakukan bukan meminta AI menulis panduan untuk saya. Saya sudah punya konteks kerja, sudah punya pengalaman di lapangan, dan tahu celah apa yang ingin saya tutup. Yang saya butuhkan adalah partner untuk menyusun semua itu jadi struktur yang kohesif.

    Hasilnya adalah sepuluh file Markdown yang mencakup Linux fundamental, jaringan dan DNS, mail server, Zimbra dan Carbonio, Proxmox, otomasi dengan Ansible, security dan monitoring, strategi backup, plus roadmap proyek dari level dasar sampai level arsitek. Ditambah satu cheatsheet command untuk referensi cepat saat kerja.

    Prosesnya tidak instan. Saya harus menjelaskan konteks pekerjaan saya, menyebutkan celah yang ingin diisi, dan memberikan arah yang cukup spesifik supaya outputnya relevan, bukan panduan generik yang bisa ditemukan di mana saja. Saya perlu berpikir dulu sebelum mengetik, bukan sekadar mengetik lalu berpikir.

    Dan di situlah training AI di kantor jadi terasa nyambung.

    Prompt engineering itu pada dasarnya berpikir lebih keras sebelum bertanya

    Training yang saya ikuti berfokus pada produktivitas: cara memakai AI tools secara efektif, termasuk dasar-dasar prompt engineering. Intinya sederhana: kualitas output sangat bergantung pada kualitas input. AI tidak membaca pikiran. Kalau pertanyaannya kabur, jawabannya juga akan kabur.

    Itu bukan prinsip baru sebetulnya. Kalau kalian pernah membuka tiket support yang baik, atau menulis runbook yang jelas, kalian sudah mempraktikkan hal yang sama. AI hanya memperlihatkannya dengan lebih eksplisit, karena feedback-nya langsung.

    Yang berubah setelah training itu bukan kemampuan teknis saya. Yang berubah adalah cara saya memulai percakapan dengan AI: lebih dulu merumuskan masalah, menyebutkan konteks, menentukan output yang diinginkan, baru mengetik. Hasilnya memang berbeda.

    Yang tidak bisa digantikan AI

    Ada satu hal yang menjadi jelas selama proses ini: AI tidak bisa menggantikan pengalaman lapangan sebagai fondasi.

    Panduan yang saya buat terasa relevan dan tidak generik justru karena saya bisa mengevaluasi setiap bagiannya dari pengalaman nyata. Saat AI memberikan penjelasan tentang Ceph device class misalnya, saya tahu apakah itu sudah cukup detail atau perlu diperdalam, karena saya pernah mengonfigurasinya langsung. Tanpa konteks itu, hasilnya mungkin tetap panjang tapi tidak akan berguna untuk situasi kerja saya.

    AI mempercepat penyusunan. Pengalaman yang menentukan arahnya.

    Apa yang bisa kalian coba

    Kalau kalian juga sedang belajar di bidang teknis dan ingin mencoba pendekatan serupa, beberapa hal yang saya pelajari dari prosesnya:

    Mulai dari apa yang sudah kalian tahu, bukan dari nol. AI bekerja jauh lebih baik sebagai partner diskusi untuk orang yang sudah punya konteks, dibandingkan sebagai guru untuk yang benar-benar asing dengan topiknya.

    Tentukan output sebelum bertanya. Bukan “jelaskan Proxmox”, tapi “saya sedang menyusun materi latihan untuk tim yang sudah familiar Linux tapi belum pernah pegang Proxmox, apa urutan konsep yang paling masuk akal?”

    Evaluasi hasilnya. Jangan langsung percaya setiap detail, terutama untuk hal-hal yang sangat spesifik versi seperti command Carbonio atau nama unit systemd. Verifikasi ke dokumentasi resmi.

    Panduan sysadmin yang saya buat itu pada akhirnya bukan produk akhir. Ia adalah kerangka belajar yang akan saya isi dan perbarui seiring pengalaman bertambah. AI membantu saya membangunnya lebih cepat dari yang saya bayangkan, tapi arahnya tetap saya yang tentukan.

    Dan mungkin itu cara yang paling jujur untuk memakai AI: bukan sebagai pengganti berpikir, tapi sebagai alat yang membuat berpikir jadi lebih produktif.

  • Pemilihan OSD untuk Proxmox VE Ceph dan Alasannya

    Pemilihan OSD untuk Proxmox VE Ceph dan Alasannya

    Pertanyaan ini sering muncul dari teman-teman yang baru mulai dan mendalami Ceph. Jawabannya ada dua tingkatan: minimal supaya bisa jalan untuk uji coba, dan minimal yang dianjurkan untuk cluster yang benar-benar dipakai.

    OSD (Object Storage Daemon) adalah proses yang menyimpan objek data Ceph lewat jaringan. Aturan dasarnya, satu OSD untuk satu disk.

    Jawaban singkat

    KondisiOSDKeterangan
    Tingkat lab atau uji coba1 OSDBisa jalan, misalnya di laptop pakai VirtualBox atau di Raspberry Pi. Bukan untuk produksi.
    Best Practice Proxmox VE Ceph12 OSDMinimal 3 node, masing-masing minimal 4 OSD (3 x 4 = 12 disk).

    Jadi untuk cluster production, patokannya 3 node dengan total 12 OSD. Angka 1 OSD hanya untuk lab.

    Kenapa minimal 3 node/cluster

    Default replikasi pool Ceph di Proxmox VE adalah 3, artinya setiap objek disimpan tiga kali dengan satu salinan per host. Supaya tiga salinan itu bisa diletakkan di host yang berbeda, jumlah node minimalnya tiga.

    Dokumentasi Ceph juga menyarankan node yang lebih banyak dan lebih kecil supaya blast radius atau cakupan dampak kegagalan lebih kecil. Alasannya, kalau satu node memegang porsi kapasitas yang besar lalu mati, proses recovery bisa mendorong OSD lain melewati batas penuh (full ratio), dan Ceph akan berhenti menulis untuk mencegah kehilangan data.

    Kenapa minimal 4 OSD per node

    • Paralelisme. Makin banyak OSD, makin tinggi pemrosesan paralel dan distribusi beban. Operasi baca tulis tersebar ke banyak disk.
    • Hindari bottleneck. Kalau OSD terlalu sedikit, beban menumpuk di sedikit disk dan jadi titik macet sehingga performanya jelek.
    • Jangan berlebihan juga. Terlalu banyak OSD menaikkan kebutuhan bandwidth jaringan dan resource CPU/RAM. Intinya cari keseimbangan.

    Aturan dasar tiap OSD

    • Satu OSD untuk satu disk. Menaruh banyak OSD di satu HDD SATA/SAS bukan ide bagus. Satu disk satu OSD, kecuali mungkin SSD berkapasitas di atas 30 TB.
    • Minimal ukuran disk 1 TiB. Disk yang jauh lebih kecil habis sebagian besar kapasitasnya untuk metadata, dan disk di bawah 100 GiB praktis tidak berguna.
    • Pisahkan dari OS dan layanan lain. Jangan satukan disk OS dengan disk OSD, dan jangan gabungkan data OSD dengan data MON, MGR, atau MDS di disk yang sama.
    • Hitung resource per OSD. Tiap OSD butuh minimal 4 GB RAM (lebih banyak lebih baik, di bawah 2 GB tidak dianjurkan) ditambah jatah CPU thread. Makin banyak OSD, makin besar kebutuhan CPU dan RAM tiap node.

    Soal jaringan

    Karena replikasi antar-OSD jalan lewat jaringan, faktor ini ikut menentukan. Sediakan minimal 10 Gbit/s kalau pakai HDD, dan minimal 25 Gbit/s kalau pakai NVMe SSD.

    Ringkasnya

    • Uji coba: cukup 1 OSD.
    • Cluster nyata di Proxmox VE: minimal 3 node, 4 OSD per node, total 12 OSD.
    • Alasannya: replikasi default 3 butuh minimal 3 host, dan jumlah OSD yang cukup supaya beban tersebar, tidak jadi bottleneck, dan blast radius tetap kecil.
    • Patuhi aturan dasar: satu OSD satu disk, minimal 1 TiB, pisah dari OS, dan siapkan RAM serta CPU yang cukup per OSD.

    Referensi

  • Memahami PVE Electrified: Mod UI di Proxmox

    Memahami PVE Electrified: Mod UI di Proxmox

    Saat saya baca-baca artikel tentang Proxmox di virtualizationhowto, saya menemukan satu proyek menarik bernama PVE Electrified. Ini bukan UI Proxmox resmi, tapi sebuah modifikasi tampilan web Proxmox VE yang menambahkan fitur-fitur yang menurut saya sudah seharusnya ada sejak awal, khususnya untuk homelab. Di tulisan ini saya tidak membahas cara instalasi nya, cuma sedikit rangkuman saja tentang apa isinya.

    Apa itu PVE Electrified

    • Modifikasi antarmuka web Proxmox VE, dibuat oleh developer independen (bukan dari perusahaan Proxmox).
    • Sasaran utamanya pengguna homelab, developer, dan kalian yang suka oprek.
    • Bukan add-on resmi dan tidak didukung Proxmox, jadi tidak disarankan dipasang di server produksi.
    • Membutuhkan Proxmox VE versi 9.x atau lebih baru.

    Fitur yang sudah tersedia

    • CPU usage bars di tree. Penggunaan CPU tiap guest tampil langsung di panel kiri secara realtime (interval sekitar 1 detik), jadi tidak perlu buka tab Summary dulu.
    • Tombol power management di tree. Start, stop, dan reset VM maupun LXC bisa langsung dari pohon objek, dengan feedback status yang lebih cepat. Praktis buat kalian yang sering cycling mesin lab.
    • Instant cloning guest. Ini fitur favorit saya. Memanfaatkan mekanisme copy-on-write ZFS, jadi clone terjadi instan dan tidak memakan disk tambahan. Bisa clone langsung dari snapshot untuk mengintip kondisi VM yang lama, bisa clone beserta RAM, dan dialognya dirancang lebih cepat. Catatan: fitur clone ini hanya jalan di ZFS.
    • Dialog konflik hardware. Saat menyalakan guest yang memakai resource eksklusif seperti USB atau GPU, akan muncul peringatan konflik. Berguna kalau kalian gantian pakai satu GPU passthrough antar VM.
    • Sistem plugin. Ada mekanisme untuk membuat dan mempublikasikan plugin UI sendiri. Ini poin penting karena selama ini UI Proxmox sulit dimodifikasi, sehingga ekosistem mod komunitas hampir tidak ada.

    Fitur yang masih direncanakan

    • Menampilkan thin disk usage sebenarnya di tree.
    • Dukungan Docker.
    • Asisten untuk optimasi homelab, antara lain GPU passthrough, dynamic IP, mencegah SSD cepat aus, update microcode, perbaikan setting memory ZFS, dan penanganan disk stalling.

    Sedikit soal arsitektur

    Yang membuat proyek ini menarik secara teknis adalah perubahan tech stack-nya. UI asli Proxmox ditulis dengan Perl dan ExtJS dalam satu file JavaScript besar yang susah di-debug. PVE Electrified memindahkannya ke tumpukan yang lebih modern: Node.js dan TypeScript di backend, serta React dan Vite di frontend. Komponen React dipakai berdampingan dengan komponen ExtJS lama. Webserver Node.js berjalan di port 8006 dan mem-proxy sebagian path ke pveproxy asli yang dipindah ke port internal 8005. Pendekatan inilah yang membuka pintu untuk sistem plugin tadi.

    Penutup

    Buat saya, PVE Electrified adalah contoh bagus bagaimana komunitas homelab sering jadi tempat lahirnya fitur yang belum ada di produk resmi. Sifatnya quality-of-life: tidak mengubah arsitektur secara besar, tapi memperbaiki workflow yang sehari-hari terasa kurang. Selama kalian paham ini mod tidak resmi dan menjauhkannya dari server produksi, proyek ini layak dicoba di lab pribadi.

    Sumber:

    https://www.virtualizationhowto.com/2026/06/i-found-a-proxmox-mod-that-adds-features-i-wish-were-built-in

    https://github.com/bogeeee/pve-manager-electrified

    https://www.pve-electrified.net

  • Ceph Full Mesh Network di Proxmox VE

    Ceph Full Mesh Network di Proxmox VE

    Kalau kalian membangun cluster Proxmox 3 node dengan Ceph, salah satu kendala yang sering muncul adalah switch. Ceph butuh jaringan storage cepat (minimal 10 Gbit), sedangkan switch 10/25/40/100 Gbit harganya mahal. Solusinya adalah full mesh network. Di tulisan ini saya jelaskan dari pengertian sampai cara konfigurasinya di Proxmox VE, termasuk cara terbaru lewat SDN Fabrics di PVE 9.

    Apa itu full mesh network

    Full mesh adalah topologi di mana setiap node terhubung langsung ke node lain lewat kabel point-to-point, tanpa melewati switch. Untuk cluster 3 node, artinya tiap node punya koneksi langsung ke dua node sisanya. Pada Ceph, jaringan inilah yang dipakai untuk lalu lintas storage (public dan cluster network) berkecepatan tinggi.

    Topologinya seperti ini:

             ┌───────┐
    ┌────┤ Node1 ├────┐
    │    └───────┘    │
┌───┴───┐         ┌───┴───┐
│ Node2 ├─────────┤ Node3 │
└───────┘         └───────┘

    Kenapa pakai full mesh

    Alasan utamanya hemat. Kalian bisa dapat koneksi antar node yang sangat cepat tanpa beli switch mahal. Selain itu bandwidth antar node penuh dan latency rendah, jadi cocok untuk cluster kecil termasuk homelab.

    Catatan: Proxmox merekomendasikan full mesh maksimal untuk 3 node. Kalau cluster kalian berencana lebih dari 3 node atau mau diekspansi ke depan, lebih baik langsung investasi switch sejak awal.

    Syarat

    Tiap node butuh minimal 2 NIC kosong (di luar NIC management/WAN), masing-masing terhubung ke salah satu node lain.

    Sebagai contoh, saya pakai penamaan dari dokumentasi resmi. Sesuaikan dengan punya kalian:

    • 3 node dengan IP storage .50, .51, .52 di subnet 10.15.15.0/24
    • ens18 dan ens19: untuk mesh, direct ke dua node lain
    • ens20: ke WAN/management lewat vmbr0
    • ens21 (opsional): LAN untuk corosync/cluster

    Koneksi fisiknya:

    • Node1/ens18 ke Node2/ens19
    • Node2/ens18 ke Node3/ens19
    • Node3/ens18 ke Node1/ens19

    Pilihan metode

    Ada 4 cara setup mesh di Proxmox. Singkatnya:

    MetodeKelebihanKekurangan
    Routed (simple)Performa terbaik, tanpa software tambahanKalau 1 link putus, antar node bisa kehilangan komunikasi
    Routed with fallback (OpenFabric/FRR)Performa mirip, tetap jalan kalau 1 link putus (dirouting lewat node tengah)Sedikit lebih kompleks
    RSTPTahan 1 link putus, recovery beberapa detikButuh Open vSwitch
    BroadcastPaling gampang di-setupBoros bandwidth (kirim ke 2 node sekaligus)

    Rekomendasi: routed with fallback pakai OpenFabric. Performanya bagus dan cluster tetap jalan kalau salah satu kabel atau NIC bermasalah. Mulai PVE 9, cara ini bisa dilakukan lewat GUI dengan fitur SDN Fabrics, jadi jauh lebih gampang dari sebelumnya.

    Cara 1: SDN Fabrics (PVE 9, direkomendasikan)

    Ini cara paling baru dan paling rapi karena semuanya lewat GUI.

    1. Buka Datacenter > SDN > Fabrics.
    2. Klik Add Fabric, lalu pilih protokol OpenFabric. Proxmox mendukung OSPF dan OpenFabric, tapi untuk setup sederhana seperti ini OpenFabric lebih gampang.
    3. Isi nama fabric, misalnya ceph. Lalu isi IPv4 prefix, misalnya 10.15.15.0/24. Prefix ini menentukan subnet untuk semua IP node di dalam fabric.
    4. Opsional, ubah Hello-Interval jadi 1 dan CSNP-Interval jadi 2. Angka lebih kecil bikin failover lebih cepat saat link putus, tapi traffic keep-alive jadi lebih banyak.
    5. Tambahkan node. Klik tombol + di baris fabric, pilih node, isi IPv4-nya (sekaligus jadi router-id), misalnya 10.15.15.50. Lalu pilih interface yang dipakai, di contoh ini ens18 dan ens19. Field lain biarkan kosong. Kalau interface tidak diberi IP, dia jalan di mode unnumbered, yaitu mewarisi IP dari node.
    6. Ulangi untuk semua node, .51 dan .52.
    7. Terakhir, buka Datacenter > SDN lalu klik Apply Configuration. Ini akan generate dan apply konfigurasi FRR di tiap node secara otomatis.

    Cek apakah fabric sudah converge lewat shell FRR:

    vtysh
show openfabric neighbor
show openfabric route

    Pasang Ceph di atas mesh

    Kalau pakai SDN Fabrics, instalasi Ceph normal saja. Pas langkah konfigurasi network awal, pilih fabric tadi dari dropdown jaringan yang tersedia. Selesai.

    Catatan untuk yang setup FRR manual: kalau IP dikonfigurasi di FRR dan bukan di /etc/network/interfaces, GUI Ceph tidak akan menampilkannya. Jadi inisialisasi Ceph lewat CLI:

    pveceph init --network 10.15.15.50/24
pveceph mon create

    Tambahkan opsi –cluster-network kalau cluster network mau dipisah ke subnet lain.

    Cara 2: Broadcast (paling simpel, via CLI)

    Kalau kalian mau yang paling cepat atau masih pakai versi PVE lama, broadcast bonding bisa jadi pilihan. Tinggal buat bond mode broadcast di tiap node. Contoh untuk Node1, edit /etc/network/interfaces:

    iface ens18 inet manual

iface ens19 inet manual

auto bond0
iface bond0 inet static
        address 10.15.15.50
        netmask 255.255.255.0
        slaves ens18 ens19
        bond_miimon 100
        bond_mode broadcast

    Lalu jalankan ifup bond0 atau reboot. Bisa juga lewat GUI: pilih node > System > Network > Create > Linux Bond, mode broadcast, tanpa gateway.

    Di konfigurasi Ceph, set Public Network dan Cluster Network ke subnet 10.15.15.0/24.

    Kekurangannya, broadcast mengirim semua data ke dua node sekaligus jadi boros bandwidth, dan kalau satu link putus node bisa kehilangan komunikasi. Untuk menambah toleransi, broadcast atau routed simple bisa dikombinasikan dengan bond, konsekuensinya butuh lebih banyak NIC dan kabel.

    Catatan untuk PVE 9

    Kalau kalian setup FRR manual (bukan lewat SDN Fabrics), mulai PVE 9 ada satu hal penting. Tambahkan cek kecil di post-up vmbr0 supaya tidak terjadi deadlock saat urutan start service. Contohnya:

    post-up /usr/bin/systemctl is-active --quiet frr.service && /usr/bin/systemctl restart frr.service || true

    Penutup

    Full mesh adalah cara paling hemat untuk dapat jaringan Ceph cepat di cluster 3 node tanpa beli switch mahal. Untuk pemakaian sekarang, saya sarankan langsung pakai SDN Fabrics dengan OpenFabric di PVE 9 karena paling rapi, tahan terhadap link putus, dan semuanya bisa dari GUI. Tapi sekali lagi, kalau cluster kalian berencana lebih dari 3 node, lebih baik pakai switch sejak awal.

    Referensi:

    dokumentasi resmi Proxmox VE, “Full Mesh Network for Ceph Server” (pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server).