Category: IT

  • Cara Mengatasi NAKIVO Replication Gagal karena Temporary Overlay di Proxmox

    Cara Mengatasi NAKIVO Replication Gagal karena Temporary Overlay di Proxmox

    Saat melakukan pengujian replication NAKIVO pada Proxmox dengan backend storage Ceph, job gagal karena NAKIVO tidak memiliki ruang yang cukup untuk membuat temporary overlay. Masalah ini terjadi walaupun kapasitas Ceph masih tersedia.

    Artikel ini membahas penyebabnya, proses pemeriksaan, dan solusi yang digunakan pada lab.

    Kondisi Lab

    KomponenKonfigurasi
    Proxmoxpve-nakivo.local
    IP Proxmox192.168.14.45
    Disk OS awal30 GB, ext4 dan LVM
    Backend storage VMCeph
    Ceph OSD3 × 50 GB
    VM pengujiantest1

    VM sumber berada di Ceph, sedangkan replication dijalankan melalui NAKIVO.

    Pesan Error

    Pada replication pertama, NAKIVO menampilkan error berikut:

    ReplicationDataCopy: Host has no free space for overlay files
    
    Not enough space for creation of temporary overlay file in "/tmp" location.
    Please make sure there is sufficient free space in the specified location.

    Error tersebut menunjukkan bahwa masalah berada pada temporary file location di host Proxmox, bukan pada kapasitas Ceph.

    Memahami Alur Replication NAKIVO

    Pada storage berbasis block seperti Ceph RBD, NAKIVO membutuhkan overlay sementara selama pemrosesan VM.

    VM test1 di Ceph
    → temporary overlay di host Proxmox
    → data diproses oleh NAKIVO
    → VM replica dibuat pada storage tujuan
    → temporary overlay dibersihkan

    Jadi, /tmp bukan lokasi akhir replica. Hasil replication tetap berupa VM pada Proxmox dan storage tujuan yang dipilih dalam job.

    Penyebab

    Pada Proxmox VE 9, /tmp menggunakan tmpfs. Artinya, kapasitas /tmp berasal dari memory dan swap, bukan dari filesystem root.

    Karena itu, memperbesar disk OS dan pve-root tidak otomatis menambah kapasitas /tmp. Root sudah memiliki ruang kosong 97 GB, tetapi NAKIVO masih menggunakan /tmp yang hanya 2 GB.

    Memperbesar tmpfs juga bukan pilihan yang digunakan pada pengujian ini karena akan menambah batas penggunaan memory atau swap. Solusinya adalah membuat direktori temporary NAKIVO pada filesystem ext4 yang sudah diperbesar.

    Membuat Lokasi Temporary Baru

    Buat direktori khusus pada filesystem root:

    mkdir -p /var/lib/nakivo-temp
    chown root:root /var/lib/nakivo-temp
    chmod 700 /var/lib/nakivo-temp

    Periksa filesystem yang digunakan:

    df -hT /var/lib/nakivo-temp

    Hasilnya harus mengarah ke filesystem root, bukan tmpfs:

    /dev/mapper/pve-root  ext4  112G  11G  97G  10%  /

    Uji akses tulis:

    touch /var/lib/nakivo-temp/test-write
    rm /var/lib/nakivo-temp/test-write

    Mengubah Temporary File Location di NAKIVO

    Buka konfigurasi inventory Proxmox pada NAKIVO:

    Settings
    → Inventory
    → pve-nakivo.local
    → Edit
    → Options
    → Temporary file location

    Ubah lokasi dari:

    /tmp

    menjadi:

    /var/lib/nakivo-temp

    Simpan perubahan, kemudian lakukan Refresh Inventory.

    Menjalankan Ulang Replication

    Jalankan kembali replication job melalui NAKIVO. Selama proses berlangsung, kapasitas dan penggunaan direktori temporary dapat dipantau dengan:

    watch -n 5 'df -h /var/lib/nakivo-temp; du -sh /var/lib/nakivo-temp 2>/dev/null'

    Hasil yang diharapkan:

    • Job replication berstatus Successful.
    • VM replica muncul pada Proxmox.
    • Disk replica berada pada storage tujuan yang dipilih.
    • Temporary overlay dibersihkan setelah job selesai.
    • VM sumber tetap berjalan normal.

    Catatan Penting

    Penggunaan /var/lib/nakivo-temp sesuai untuk pengujian lab karena root sudah memiliki ruang yang cukup. Namun, direktori tersebut masih berada pada root volume Proxmox.

    Untuk production atau VM dengan perubahan data tinggi, gunakan disk atau filesystem terpisah sebagai temporary file location. Tujuannya agar pertumbuhan overlay tidak memenuhi root dan mengganggu service Proxmox.

    Selain itu, replication ke node dan Ceph yang sama hanya membuktikan fungsi replication. Skenario tersebut belum memberikan perlindungan disaster recovery karena VM sumber dan replica tetap bergantung pada host yang sama.

    Kesimpulan

    Replication gagal bukan karena Ceph kehabisan ruang, tetapi karena /tmp pada Proxmox hanya berupa tmpfs 2 GB. Memperbesar disk OS tidak menambah kapasitas /tmp secara otomatis.

    Solusi pada lab ini adalah membuat /var/lib/nakivo-temp, kemudian mengarahkannya sebagai Temporary file location pada inventory NAKIVO. Dengan begitu, overlay dapat memakai ruang kosong filesystem ext4 tanpa bergantung pada tmpfs.

    Referensi

  • Memahami Kelebihan Proxmox ARM64 untuk Homelab

    Memahami Kelebihan Proxmox ARM64 untuk Homelab

    Selama ini Proxmox VE identik dengan server berbasis x86-64, seperti Intel dan AMD. Namun pada 5 Agustus 2026, Proxmox resmi merilis Proxmox VE untuk ARM64. Ini bukan lagi sekadar port komunitas atau eksperimen, tetapi sudah menjadi arsitektur resmi Proxmox VE.

    Lalu, apa yang membuat ARM64 menarik untuk sebuah homelab?

    ARM64 Itu Apa?

    Secara sederhana, ARM64 adalah arsitektur prosesor yang berbeda dari x86-64.

    Kita banyak menemukan ARM pada perangkat seperti:

    • Raspberry Pi
    • Single Board Computer
    • Apple Silicon
    • Ampere Server
    • NVIDIA Grace
    • Berbagai server hemat daya

    ARM terkenal menarik untuk perangkat yang membutuhkan efisiensi daya tinggi.

    Sebelumnya kita bisa menjalankan berbagai workload langsung pada Linux ARM, tetapi jika ingin pengalaman virtualisasi seperti Proxmox, dukungannya tidak semudah pada Intel atau AMD.

    Sekarang Proxmox mulai mengubah kondisi tersebut.


    1. Proxmox Bisa Berjalan pada Hardware yang Lebih Hemat Daya

    Menurut saya, ini adalah kelebihan paling menarik untuk homelab.

    Banyak homelab berjalan 24 jam setiap hari, padahal workload yang dijalankan belum tentu membutuhkan server dengan konsumsi daya besar.

    ARM membuka kemungkinan membangun node Proxmox untuk workload ringan seperti:

    • DNS Server
    • Monitoring
    • Home Automation
    • Git Server
    • CI/CD Runner
    • Kubernetes Node
    • Container
    • Development Environment

    Artikel Virtualization Howto juga menyoroti ARM64 sebagai platform yang menarik untuk layanan always-on, terutama ketika tujuan homelab adalah menjalankan banyak service dengan konsumsi daya sekecil mungkin.

    Artinya konsepnya bisa seperti:

    Proxmox ARM64
    │
    ├── LXC DNS
    ├── LXC Monitoring
    ├── VM Kubernetes
    ├── VM Git Server
    └── LXC Home Automation
    

    Satu perangkat ARM kecil bisa menjadi host untuk beberapa service sekaligus.


    2. Bukan Proxmox Versi “Lite”

    Hal menarik lainnya adalah Proxmox ARM64 bukan versi Proxmox yang fiturnya banyak dipangkas.

    Proxmox menyatakan ARM64 memiliki feature parity untuk komponen utama seperti:

    • KVM
    • LXC
    • Networking
    • Clustering
    • High Availability
    • ZFS
    • Ceph
    • Backup
    • Web Management

    Jadi pengalaman administrasinya pada dasarnya tetap seperti Proxmox yang biasa kita gunakan pada Intel atau AMD.

    Ini penting karena kita tidak perlu mempelajari platform virtualisasi baru hanya karena menggunakan CPU ARM.


    3. ZFS dan Ceph Tetap Tersedia

    Ini mungkin salah satu bagian paling menarik.

    Proxmox tidak hanya membawa kemampuan menjalankan VM dan container ke ARM64, tetapi juga melakukan validasi pada ZFS dan Ceph.

    Artinya secara arsitektur kita tetap bisa membangun environment seperti:

    ARM64 Node 1
         │
    ARM64 Node 2
         │
    ARM64 Node 3
         │
         └── Ceph Storage
    

    atau menggunakan ZFS sebagai local storage seperti pada deployment Proxmox biasa.

    Untuk homelab, mungkin Ceph ARM64 masih cukup berlebihan. Tetapi keberadaan fitur tersebut menunjukkan bahwa Proxmox ARM64 bukan sekadar proyek untuk menjalankan VM pada sebuah SBC.


    4. Homelab Bisa Menjadi Lebih Kecil

    ARM juga menarik karena banyak tersedia dalam bentuk perangkat yang sangat compact.

    Bayangkan dibanding menggunakan beberapa server besar:

    Rack Server
    Rack Server
    Rack Server

    kita berpotensi memiliki:

    ARM Node
    ARM Node
    ARM Node

    dengan ukuran yang jauh lebih kecil.

    Ini cocok dengan tren homelab sekarang yang mulai banyak menggunakan:

    • Mini PC
    • Mini rack
    • SBC
    • Low-power server

    Tujuannya bukan mengejar performa maksimal, tetapi mencari titik seimbang antara:

    Performance + Power Consumption + Size + Cost


    Apakah Bisa Menggunakan Raspberry Pi?

    Di sinilah ada hal yang perlu diperhatikan.

    ARM64 support tidak berarti Raspberry Pi resmi didukung Proxmox.

    Dukungan resmi Proxmox saat ini ditujukan pada hardware ARM yang menggunakan:

    • UEFI
    • ACPI

    NVIDIA Grace Hopper dan NVIDIA Vera menjadi platform yang mendapatkan dukungan resmi sejak rilis awal. Hardware ARM lain berbasis UEFI ARMv9-A, serta umumnya ARMv8-A, berada pada kategori best-effort support.

    Sedangkan Raspberry Pi secara resmi belum termasuk platform yang didukung karena karakteristik boot dan hardware discovery-nya. Meski demikian, pengguna komunitas sudah melaporkan keberhasilan menjalankan Proxmox VE ARM64 pada Raspberry Pi 5.

    Jadi bedakan antara:

    HardwareStatus
    NVIDIA Grace / VeraOfficially Supported
    UEFI ARM ServerBest Effort
    Raspberry PiTidak resmi didukung

    Artinya Raspberry Pi lebih cocok untuk eksperimen, bukan deployment yang membutuhkan support resmi.


    ARM64 Belum Menggantikan x86

    Ini juga penting.

    ARM64 tidak otomatis membuat Intel dan AMD menjadi tidak relevan.

    Untuk kompatibilitas software, x86-64 masih menjadi pilihan paling aman.

    Terutama jika kita membutuhkan:

    • Windows VM
    • Software legacy
    • Commercial application
    • Appliance yang hanya menyediakan image x86
    • Driver tertentu

    Selain itu, VM ARM hanya dapat berjalan pada node ARM dan VM x86 hanya dapat berjalan pada node x86. Live Migration juga hanya dapat dilakukan antar-node dengan arsitektur yang sama. Mixed ARM64/x86 cluster secara teknis tidak diblokir, tetapi belum menjadi konfigurasi yang resmi didukung.

    Jadi jangan menganggap:

    VM x86
      ↓
    Live Migration
      ↓
    ARM64
    

    Hal tersebut tidak bisa dilakukan begitu saja.


    Jadi Apa Kelebihan Proxmox ARM64?

    Jika diringkas:

    KelebihanManfaat untuk Homelab
    Efisiensi dayaCocok untuk server 24/7
    Hardware compactHomelab lebih kecil
    Proxmox full featureTetap dapat KVM, LXC, cluster, HA
    ZFS & CephStorage tetap fleksibel
    ARM ecosystemBanyak pilihan hardware baru
    Virtualisasi ARMCocok untuk Kubernetes dan Linux
    Management samaTidak perlu belajar hypervisor baru

    Menurut saya bukan berarti kita harus mengganti seluruh homelab menjadi ARM.

    Yang lebih menarik justru menggabungkannya dengan x86.

    Contohnya:

                  HOMELAB
                     │
            ┌────────┴────────┐
            │                 │
         ARM64              x86-64
            │                 │
     DNS / Git /          Windows VM
     Monitoring           Legacy Apps
     Kubernetes           Heavy Workload
     Containers           General VM

    ARM digunakan untuk workload ringan dan always-on, sedangkan Intel atau AMD tetap digunakan ketika membutuhkan kompatibilitas dan performa yang lebih luas.

    Kesimpulan

    Hadirnya Proxmox ARM64 menarik bukan hanya karena sekarang Proxmox bisa berjalan pada prosesor ARM.

    Yang lebih penting adalah kita mendapatkan pengalaman Proxmox yang hampir sama pada arsitektur yang membuka peluang server lebih kecil dan hemat daya.

    Untuk homelab, ini membuat berbagai eksperimen seperti Kubernetes, container, monitoring, DNS, Git server, dan development environment semakin menarik untuk dijalankan pada node ARM yang aktif 24/7.

    Namun ARM64 belum sepenuhnya menggantikan x86.

    Untuk saat ini saya melihatnya lebih cocok sebagai tambahan untuk homelab, bukan pengganti seluruh node Intel atau AMD.

    Dan justru di situlah bagian menariknya: kita sekarang punya pilihan arsitektur yang lebih luas ketika membangun Proxmox homelab.

    Referensi

    Proxmox ARM64 Changes Everything for Home Labs
    Brandon Lee — Virtualization Howto
    6 Agustus 2026

    Proxmox Virtual Environment launches official Arm64 Support
    Proxmox Server Solutions
    5 Agustus 2026

  • Hasil Deploy VM Ubuntu di Proxmox dengan Terraform

    Hasil Deploy VM Ubuntu di Proxmox dengan Terraform

    Pada artikel sebelumnya, saya sudah menyiapkan seluruh kebutuhan Terraform untuk Proxmox, mulai dari Terraform Controller, API Token, konfigurasi network, hingga file Terraform untuk membuat tiga VM Ubuntu.

    Kali ini saya akan mengaplikasikan konfigurasi yang sudah dibuat tersebut dan melihat hasil deployment-nya langsung di homelab.

    Topologi homelab

    Seluruh perangkat berada pada network 192.168.14.0/24.

    HostnameFungsiIP Address
    terraform-controllerMenjalankan Terraform192.168.14.80
    ubuntu-tf-01VM hasil Terraform192.168.14.81
    ubuntu-tf-02VM hasil Terraform192.168.14.82
    ubuntu-tf-03VM hasil Terraform192.168.14.83

    Alurnya kurang lebih seperti berikut:

    Terraform Controller
    192.168.14.80
            │
            │ Proxmox API
            ▼
         Proxmox VE
            │
            ├── ubuntu-tf-01 → 192.168.14.81
            ├── ubuntu-tf-02 → 192.168.14.82
            └── ubuntu-tf-03 → 192.168.14.83
    

    Cara Kerjanya

    Saya menggunakan provider bpg/proxmox sebagai penghubung antara Terraform dengan Proxmox API.

    Secara sederhana, Terraform tidak membuat VM dengan mengklik Web UI. Terraform mengirim request ke API Proxmox menggunakan API Token yang sudah dibuat.

    Konfigurasi Terraform
            │
            ▼
    bpg/proxmox Provider
            │
            │ API Request
            ▼
    Proxmox API :8006
            │
            ▼
    Resource dibuat di Proxmox
    

    API tersebut memungkinkan Terraform untuk mengunduh image, membuat VM, mengatur disk, network, Cloud-init, hingga menyalakan VM.

    Terraform kemudian menjalankan beberapa proses secara otomatis:

    1. Mengunduh Ubuntu 24.04 Cloud Image.
    2. Mengimport image ke storage Proxmox.
    3. Membuat tiga VM.
    4. Membuat disk dari Ubuntu Cloud Image.
    5. Mengatur CPU, RAM, disk, dan network.
    6. Mengatur IP statis melalui Cloud-init.
    7. Memasukkan SSH public key.
    8. Menyalakan seluruh VM.

    Dengan cara ini, saya tidak perlu menulis resource VM sebanyak tiga kali. Terraform melakukan iterasi berdasarkan hostname, VM ID, dan IP yang sudah ditentukan.

    Menjalankan Plan yang Sudah Disimpan

    Pada artikel panduan sebelumnya, konfigurasi sudah diperiksa menggunakan:

    terraform init
    terraform validate

    Kemudian rencana deployment dibuat dan disimpan ke file tfplan:

    terraform plan -out=tfplan

    Hasil plan menunjukkan:

    Plan: 4 to add, 0 to change, 0 to destroy.

    Empat resource tersebut terdiri dari:

    ResourceJumlah
    Ubuntu Cloud Image1
    VM Ubuntu3

    Untuk menjalankan rencana yang sudah disimpan tersebut, saya cukup menjalankan:

    terraform apply tfplan

    Dengan menggunakan saved plan, Terraform menerapkan perubahan yang sebelumnya sudah diperiksa pada saat terraform plan.

    Hasil Deployment

    Setelah proses selesai, Terraform berhasil membuat ketiga VM sesuai konfigurasi.

    181  ubuntu-tf-01  → 192.168.14.81
    182  ubuntu-tf-02  → 192.168.14.82
    183  ubuntu-tf-03  → 192.168.14.83

    Masing-masing VM sudah memiliki CPU, RAM, disk, IP statis, Cloud-init, dan SSH key sesuai konfigurasi Terraform.

    Ketiga VM juga langsung terlihat pada Proxmox dan berada dalam kondisi Running.

    Konfigurasi cloud-init

    Untuk memastikan VM benar-benar dapat digunakan, saya mencoba mengakses salah satunya dari Terraform Controller:

    ssh ubuntu@192.168.14.81

    Artinya VM tidak hanya berhasil dibuat di Proxmox, tetapi juga sudah mendapatkan konfigurasi awal dan dapat diakses melalui SSH.

    Terraform State

    VM yang dibuat tidak hanya dibuat sekali oleh Terraform, tetapi selanjutnya juga dikelola oleh Terraform.

    Resource tersebut dapat dilihat menggunakan:

    terraform state list

    Contohnya:

    proxmox_download_file.ubuntu_cloud_image
    proxmox_virtual_environment_vm.ubuntu_vm["ubuntu-tf-01"]
    proxmox_virtual_environment_vm.ubuntu_vm["ubuntu-tf-02"]
    proxmox_virtual_environment_vm.ubuntu_vm["ubuntu-tf-03"]

    State digunakan Terraform untuk mencatat resource yang dikelolanya. Karena itu, konfigurasi yang sama nantinya dapat digunakan untuk menambah, mengubah, atau menghapus VM.

    Kesimpulan

    Percobaan ini berhasil membuat 3 VM Ubuntu di Proxmox secara otomatis menggunakan Terraform.

    Rancang dan konfigurasi
          ↓
    terraform plan -out=tfplan
          ↓
    terraform apply tfplan
          ↓
    3 VM Ubuntu Running

    Jika sebelumnya pembuatan VM dilakukan satu per satu melalui Web UI, sekarang konfigurasi infrastrukturnya sudah tersimpan sebagai kode dan dapat digunakan kembali.

    Percobaan ini juga menjadi dasar sebelum melanjutkan otomatisasi berikutnya menggunakan Ansible untuk melakukan konfigurasi sistem setelah VM selesai dibuat.

    Referensi

  • Mengintegrasikan Proxmox dengan Terraform untuk Deploy Virtual Machine

    Mengintegrasikan Proxmox dengan Terraform untuk Deploy Virtual Machine

    Pada artikel sebelumnya saya membahas gambaran otomatisasi homelab Proxmox menggunakan Terraform dan Ansible.

    Kali ini saya mulai mempraktikkannya di homelab, dimulai dari Terraform terlebih dahulu. Targetnya adalah menyiapkan Terraform Controller yang nantinya dapat membuat 3 VM Ubuntu secara otomatis di Proxmox.

    Pada bagian ini proses hanya sampai terraform plan, sehingga belum ada perubahan yang diterapkan ke Proxmox.

    Rancangan Homelab

    Seluruh server menggunakan network 192.168.14.0/24.

    HostnameFungsiIP Address
    terraform-controllerTerraform Controller192.168.14.80
    ubuntu-tf-01VM Target192.168.14.81
    ubuntu-tf-02VM Target192.168.14.82
    ubuntu-tf-03VM Target192.168.14.83

    Konfigurasi Proxmox:

    ParameterNilai
    Nodepverafi1
    APIhttps://192.168.14.31:8006/
    Gateway192.168.14.31
    Bridgevmbr0
    Image Storagelocal
    VM Storagelocal-lvm

    Alur yang akan dibuat:

    Terraform Controller
    192.168.14.80
            │
            │ Proxmox API
            ▼
         Proxmox VE
            │
            ├── ubuntu-tf-01 → 192.168.14.81
            ├── ubuntu-tf-02 → 192.168.14.82
            └── ubuntu-tf-03 → 192.168.14.83
    

    1. Menyiapkan Terraform Controller

    Saya membuat satu VM Ubuntu Server 24.04 secara manual di Proxmox dengan spesifikasi:

    ResourceKonfigurasi
    CPU2 Core
    RAM2 GB
    Disk20 GB
    Networkvmbr0
    IP192.168.14.80/24

    VM ini hanya digunakan sebagai controller untuk menjalankan Terraform.

    Setelah Ubuntu selesai diinstal, pastikan controller dapat berkomunikasi dengan Proxmox:

    ping -c 3 192.168.14.31
    

    2. Install Terraform

    Install dependency:

    sudo apt update
    sudo apt install -y gnupg software-properties-common wget curl

    Tambahkan GPG key HashiCorp:

    wget -O- https://apt.releases.hashicorp.com/gpg |
    gpg --dearmor |
    sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null

    Tambahkan repository:

    echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(grep -oP '(?<=UBUNTU_CODENAME=).*' /etc/os-release || lsb_release -cs) main" |
    sudo tee /etc/apt/sources.list.d/hashicorp.list

    Kemudian install Terraform:

    sudo apt update
    sudo apt install -y terraform

    Verifikasi instalasi:

    root@terraform:~/terraform-proxmox# terraform version
    Terraform v1.15.8
    on linux_amd64

    3. Mengaktifkan Import Storage Proxmox

    Terraform nantinya akan mengunduh Ubuntu Cloud Image dan memasukkannya ke storage Proxmox.

    Buka:

    Datacenter
    └── Storage
        └── local
            └── Edit

    Pada bagian Content, aktifkan:

    Import

    Ini dibutuhkan agar Terraform dapat menggunakan Ubuntu Cloud Image sebagai sumber disk VM.

    4. Membuat User Terraform

    Sebaiknya Terraform menggunakan user khusus, bukan akun administrator utama Proxmox.

    Buka:

    Datacenter
    └── Permissions
        └── Users
            └── Add

    Buat:

    terraform@pve

    Untuk percobaan homelab ini saya memberikan role:

    Administrator

    pada path:

    /

    Untuk lingkungan production, permission sebaiknya dibatasi sesuai kebutuhan.

    Membuat API Token

    Buka:

    Datacenter
    └── Permissions
        └── API Tokens
            └── Add

    Gunakan:

    ParameterNilai
    Userterraform@pve
    Token IDprovider
    Privilege SeparationNonaktif

    Setelah dibuat, simpan:

    Token secret hanya ditampilkan satu kali.

    5. Test Proxmox API

    Dari Terraform Controller:

    curl -k https://192.168.14.31:8006/api2/json/version

    Kemudian masukkan API token sebagai environment variable:

    read -rsp "API token: " PROXMOX_VE_API_TOKEN
    export PROXMOX_VE_API_TOKEN
    echo ${#PROXMOX_VE_API_TOKEN}  -> output harus > 0

    Formatnya:

    terraform@pve!provider=TOKEN_SECRET

    Test autentikasi:

    curl -k -H \ "Authorization:PVEAPIToken=${PROXMOX_VE_API_TOKEN}" \
    https://192.168.14.31:8006/api2/json/version

    Jika berhasil, Proxmox akan mengembalikan informasi versi dalam format JSON.

    6. Membuat SSH Key

    SSH key nantinya akan dimasukkan ke setiap VM melalui Cloud-init.

    ssh-keygen -t ed25519 -C "terraform-controller"

    Gunakan lokasi default:

    ~/.ssh/id_ed25519

    7. Membuat Project Terraform

    Buat directory:

    mkdir -p ~/terraform-proxmox
    cd ~/terraform-proxmox

    Struktur project:

    terraform-proxmox/
    ├── versions.tf
    ├── variables.tf
    ├── main.tf
    ├── terraform.tfvars
    └── outputs.tf
    

    8. Konfigurasi Provider

    Buat versions.tf:

    terraform {
      required_version = ">= 1.5.0"
    
      required_providers {
        proxmox = {
          source  = "bpg/proxmox"
          version = "~> 0.111.0"
        }
      }
    }
    
    provider "proxmox" {
      endpoint = var.proxmox_endpoint
      insecure = true
    }

    Saya menggunakan provider bpg/proxmox.

    insecure = true digunakan karena Proxmox homelab masih menggunakan sertifikat self-signed.

    9. Membuat Variable

    Buat variables.tf:

    variable "proxmox_endpoint" {
      type = string
    }
    
    variable "proxmox_node" {
      type = string
    }
    
    variable "image_datastore" {
      type    = string
      default = "local"
    }
    
    variable "vm_datastore" {
      type    = string
      default = "local-lvm"
    }
    
    variable "bridge" {
      type    = string
      default = "vmbr0"
    }
    
    variable "gateway" {
      type = string
    }
    
    variable "dns_servers" {
      type    = list(string)
      default = ["8.8.8.8", "1.1.1.1"]
    }
    
    variable "ssh_public_key_file" {
      type    = string
      default = "~/.ssh/id_ed25519.pub"
    }

    10. Mendefinisikan 3 VM Ubuntu

    Konfigurasi utama berada pada main.tf.

    Pertama, tentukan VM yang ingin dibuat:

    locals {
      ubuntu_vms = {
        "ubuntu-tf-01" = {
          vm_id = 181
          ip    = "192.168.14.81/24"
        }
    
        "ubuntu-tf-02" = {
          vm_id = 182
          ip    = "192.168.14.82/24"
        }
    
        "ubuntu-tf-03" = {
          vm_id = 183
          ip    = "192.168.14.83/24"
        }
      }
    }

    Kemudian definisikan Ubuntu Cloud Image:

    resource "proxmox_download_file" "ubuntu_cloud_image" {
      content_type = "import"
      datastore_id = var.image_datastore
      node_name    = var.proxmox_node
    
      url       = "https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img"
      file_name = "noble-server-cloudimg-amd64.qcow2"
    
      overwrite = false
    }

    Selanjutnya resource VM:

    resource "proxmox_virtual_environment_vm" "ubuntu_vm" {
      for_each = local.ubuntu_vms
    
      name        = each.key
      description = "Ubuntu 24.04 deployed by Terraform"
      tags        = ["terraform", "ubuntu"]
    
      node_name = var.proxmox_node
      vm_id     = each.value.vm_id
    
      started = true
      on_boot = true
    
      boot_order    = ["scsi0"]
      scsi_hardware = "virtio-scsi-single"
    
      cpu {
        cores = 2
        type  = "x86-64-v2-AES"
      }
    
      memory {
        dedicated = 2048
      }
    
      disk {
        datastore_id = var.vm_datastore
        import_from  = proxmox_download_file.ubuntu_cloud_image.id
        interface    = "scsi0"
        size         = 20
        discard      = "on"
        iothread     = true
      }
    
      initialization {
        datastore_id = var.vm_datastore
    
        dns {
          servers = var.dns_servers
        }
    
        ip_config {
          ipv4 {
            address = each.value.ip
            gateway = var.gateway
          }
        }
    
        user_account {
          username = "ubuntu"
    
          keys = [
            trimspace(
              file(
                pathexpand(var.ssh_public_key_file)
              )
            )
          ]
        }
      }
    
      network_device {
        bridge = var.bridge
        model  = "virtio"
      }
    
      operating_system {
        type = "l26"
      }
    
      serial_device {}
    }

    Dengan looping for_each, satu resource dapat digunakan untuk mendefinisikan tiga VM sekaligus.

    Target konfigurasinya:

    VMVM IDIPCPURAMDisk
    ubuntu-tf-01181192.168.14.812 Core2 GB20 GB
    ubuntu-tf-02182192.168.14.822 Core2 GB20 GB
    ubuntu-tf-03183192.168.14.832 Core2 GB20 GB

    11. Konfigurasi Environment Homelab

    Buat terraform.tfvars:

    proxmox_endpoint = "https://192.168.14.31:8006/"
    proxmox_node     = "pverafi1"
    
    image_datastore = "local"
    vm_datastore    = "local-lvm"
    
    bridge  = "vmbr0"
    gateway = "192.168.14.31"
    
    dns_servers = [
      "8.8.8.8",
      "1.1.1.1"
    ]
    
    ssh_public_key_file = "~/.ssh/id_ed25519.pub"

    Nama node dapat diperiksa pada Proxmox:

    hostname

    Sedangkan storage:

    pvesm status

    12. Membuat Output

    Buat outputs.tf:

    output "deployed_vms" {
      value = {
        for name, vm in local.ubuntu_vms : name => {
          vm_id = vm.vm_id
          ip     = split("/", vm.ip)[0]
          ssh    = "ssh ubuntu@${split("/", vm.ip)[0]}"
        }
      }
    }

    Output ini nantinya menampilkan informasi VM setelah deployment dilakukan.

    13. Inisialisasi dan Validasi Terraform

    Rapikan konfigurasi:

    terraform fmt

    Download dan inisialisasi provider:

    terraform init

    Kemudian lakukan validasi:

    terraform validate

    Jika konfigurasi benar:

    Success! The configuration is valid.

    Sampai tahap ini Terraform sudah siap berkomunikasi dengan Proxmox dan konfigurasi VM sudah berhasil divalidasi.

    14. Melihat Terraform Plan

    Sebelum benar-benar membuat VM, periksa terlebih dahulu perubahan yang akan dilakukan Terraform.

    Pastikan API token masih tersedia:

    echo "${PROXMOX_VE_API_TOKEN:+API token sudah tersedia}"

    Kemudian:

    terraform plan

    Targetnya Terraform menampilkan:

    Plan: 4 to add, 0 to change, 0 to destroy.

    Empat resource tersebut adalah:

    ResourceJumlah
    Ubuntu Cloud Image1
    Ubuntu VM3
    Total4

    Plan juga dapat disimpan:

    terraform plan -out=tfplan

    File tfplan inilah yang nantinya dapat diterapkan menggunakan terraform apply.

    Referensi

    • HashiCorp Terraform Documentation
    • bpg/proxmox Terraform Provider
    • Proxmox VE Documentation
    • Ubuntu Cloud Images
  • Memilih Storage Proxmox Sesuai Kebutuhan: Homelab hingga Production

    Memilih Storage Proxmox Sesuai Kebutuhan: Homelab hingga Production

    Saat mencari bahan bacaan seputar Proxmox, saya menemukan halaman Mr.PlanB yang membahas berbagai teknologi storage. Dari sana, saya menyadari bahwa memilih storage sebaiknya tidak dimulai dari pertanyaan “Teknologi mana yang paling bagus?”, tetapi dari “Storage ini akan digunakan untuk kebutuhan apa?”

    Proxmox VE mendukung storage lokal maupun shared storage. VM dan container dapat ditempatkan pada directory, LVM-thin, ZFS, NFS, iSCSI, hingga Ceph. Banyaknya pilihan tersebut bukan berarti kita harus menggunakan semuanya. Kita cukup memilih arsitektur yang sesuai dengan jumlah node, workload, performa, dan kebutuhan ketersediaan layanan.

    Mulai dari kebutuhan

    Pada fitur storage picker milik Mr.PlanB, pemilihan storage dimulai dari tiga pertanyaan:

    • Berapa jumlah node yang digunakan?
    • Apa platform utamanya?
    • Apa prioritas utama storage tersebut?

    Prioritasnya dibagi menjadi integritas data, kemudahan penggunaan, scalability dan high availability, serta backup dan archive. Kebutuhan performa, kapasitas, dan redundancy juga tetap menjadi pertimbangan.

    Untuk lingkungan Proxmox, variabel tersebut dapat disederhanakan menjadi:

    PertimbanganVariabel
    Jumlah nodeSingle node, cluster kecil, atau cluster besar.
    Jenis workloadVM pengujian, file server, database, atau layanan production.
    AvailabilityLayanan harus tetap berjalan saat node gagal.
    PerformaApakah workload membutuhkan IOPS atau throughput tinggi.
    PengelolaanSeberapa kompleks storage yang mampu kita rawat.
    BackupBagaimana data dipulihkan ketika VM terhapus atau rusak.

    1. Storage lokal untuk single node

    Untuk Proxmox single node, storage lokal biasanya sudah mencukupi.

    Pilihan yang dapat digunakan antara lain:

    • Directory untuk ISO, template, backup, dan disk VM
    • LVM-thin untuk disk VM dan container
    • ZFS untuk snapshot, compression, checksum, dan integritas data

    Directory dan LVM-thin cocok untuk memulai homelab karena konfigurasinya sederhana. Sementara itu, ZFS menarik ketika kita ingin mempelajari pengelolaan pool, snapshot, compression, serta perlindungan data berbasis checksum.

    Mr.PlanB menempatkan ZFS sebagai pilihan yang kuat untuk integritas data dan menyebutnya sebagai fondasi yang banyak digunakan pada homelab Proxmox maupun TrueNAS.

    Contoh penggunaan:

    • Satu server Proxmox untuk belajar
    • Beberapa VM dan container internal
    • Media server atau server pengujian
    • Workload yang tidak membutuhkan failover otomatis

    2. Cluster kecil: storage lokal atau shared NAS

    Ketika menggunakan dua atau tiga node Proxmox, kita memiliki beberapa pilihan.

    ZFS Replication

    Setiap node menggunakan storage ZFS lokal, kemudian disk VM direplikasi ke node lain berdasarkan jadwal.

    Kelebihannya:

    • Arsitektur lebih sederhana
    • Tidak membutuhkan shared storage
    • Cocok untuk cluster kecil
    • Mengurangi waktu migrasi karena salinan disk sudah tersedia pada node tujuan

    Namun, replication berjalan secara asynchronous. Jika node gagal sebelum proses replication berikutnya selesai, perubahan terbaru masih mungkin hilang.

    NFS atau iSCSI

    Kita juga dapat menggunakan NAS atau SAN sebagai shared storage:

    • NFS menyediakan file storage melalui jaringan dan relatif mudah dikelola.
    • iSCSI menyediakan block storage melalui jaringan dan umum digunakan untuk virtualisasi.

    Shared storage memungkinkan beberapa node mengakses storage yang sama. Namun, server NAS, SAN, dan jaringan storage harus dirancang dengan baik agar tidak menjadi titik kegagalan tunggal. Proxmox secara resmi mendukung VM pada shared storage seperti NFS dan iSCSI.

    Contoh penggunaan:

    • Homelab tiga node dengan NAS terpisah
    • Cluster kantor kecil
    • Infrastruktur yang sudah memiliki NAS atau SAN

    3. Scale dan High Availability dengan Ceph

    Untuk cluster production dengan beberapa node, kebutuhan storage biasanya tidak lagi hanya soal kapasitas. Storage juga harus tetap tersedia ketika disk atau node mengalami kegagalan.

    Di sinilah Ceph dapat dipertimbangkan.

    Ceph merupakan distributed storage yang menyediakan block, object, dan file storage. Data didistribusikan ke beberapa node sehingga storage dapat berkembang secara horizontal dan melakukan pemulihan ketika terjadi kegagalan.

    Pada Proxmox, Ceph cocok ketika kita membutuhkan:

    • Shared storage terdistribusi
    • High availability
    • Live migration yang cepat
    • Penambahan kapasitas melalui node baru
    • Tidak bergantung pada satu server NAS

    Namun, Ceph membutuhkan lebih banyak node, disk, jaringan cepat, monitoring, dan kemampuan troubleshooting. Untuk homelab kecil, ZFS Replication sering lebih mudah dirawat. Artikel komunitas Mr.PlanB menggambarkan ZFS sebagai pilihan praktis untuk cluster kecil, sedangkan Ceph lebih sesuai ketika kebutuhan scale dan HA memang sebanding dengan kompleksitasnya.

    4. Backup tetap menggunakan PBS

    Apa pun storage utama yang dipilih, kita tetap membutuhkan backup.

    Untuk Proxmox, pilihan yang paling sesuai adalah Proxmox Backup Server karena terintegrasi langsung dengan Proxmox VE dan mendukung backup VM, container, serta physical host.

    PBS menyediakan:

    • Incremental backup
    • Deduplication
    • Compression
    • Verifikasi integritas
    • Client-side encryption
    • Sinkronisasi datastore ke lokasi lain

    Backup dikirim secara incremental dan dideduplicasi pada server sehingga penggunaan storage dan jaringan dapat ditekan.

    Replication, RAID, ZFS, dan Ceph tidak menggantikan backup. Data yang terhapus, rusak, atau terkena kesalahan konfigurasi tetap memerlukan recovery point yang terpisah.

    Rangkuman pilihan untuk Proxmox

    SkenarioPilihan awal
    Homelab single nodeDirectory, LVM-thin, atau ZFS
    Homelab dengan fokus integritas dataZFS
    Cluster kecil 2–3 nodeZFS Replication atau shared NFS
    Sudah memiliki NAS/SANNFS atau iSCSI
    Production multi-node dengan HACeph
    Backup VM dan containerProxmox Backup Server
    Backup di lokasi lainPBS Remote dan Sync Job

    Platform lain tentu memiliki pendekatan berbeda. Kubernetes, misalnya, dapat menggunakan Longhorn atau Rook-Ceph, sedangkan bare metal dan NAS dapat menggunakan ZFS, Unraid, NFS, atau iSCSI. Namun, untuk lingkungan Proxmox, pilihan umumnya tetap berputar pada storage lokal, shared storage, distributed storage, dan backup terpisah.

    Kesimpulan

    Tidak ada satu storage yang terbaik untuk semua kondisi.

    Untuk homelab, pilihan sederhana seperti LVM-thin, ZFS, NFS, atau ZFS Replication sering sudah mencukupi. Pada skala production, kebutuhan shared storage, high availability, performa, redundancy, dan kemampuan recovery menjadi lebih penting sehingga NFS, iSCSI, atau Ceph dapat dipertimbangkan.

    Menurut saya, storage terbaik bukan storage dengan teknologi paling rumit, tetapi storage yang sesuai dengan workload dan masih dapat kita kelola dengan baik.

    Mulailah dari kebutuhan, ukur kemampuan hardware dan jaringan, kemudian pastikan seluruh VM dan container tetap memiliki backup terpisah di Proxmox Backup Server.

    Referensi

    • Homelab Storage Guide: ZFS, Ceph, PBS, Unraid, NFS, iSCSI — Mr.PlanB
    • Ceph Is a Beast, ZFS Just Works: Inside the Storage Wars of the Proxmox Community — Mr.PlanB
  • Mengenal Otomatisasi Homelab Proxmox dengan Terraform dan Ansible

    Mengenal Otomatisasi Homelab Proxmox dengan Terraform dan Ansible

    Membuat virtual machine di Proxmox melalui web interface cukup mudah. Namun, jika VM yang dibuat semakin banyak, proses mengatur CPU, RAM, disk, jaringan, dan sistem operasi secara manual akan terasa berulang.

    Artikel ini membahas cara mengotomatisasi homelab Proxmox menggunakan Terraform, Cloud-init, dan Ansible.

    Gambaran Homelab

    Dalam skenario ini, Terraform digunakan untuk membuat tiga virtual machine Ubuntu di Proxmox.

    Setelah VM tersedia, Cloud-init memasukkan SSH key. Selanjutnya, Ansible terhubung ke masing-masing VM untuk menginstal Docker dan menjalankan container.

    Alur Otomatisasi

    File konfigurasi
           │
           ▼
    Terraform
    Membuat 3 VM Ubuntu
           │
           ▼
    Cloud-init
    Memasukkan SSH key
           │
           ▼
    Ansible
    Menginstal Docker
           │
           ▼
    Container berjalan
    

    Fungsi Setiap Komponen

    KomponenFungsi
    ProxmoxMenjalankan virtual machine
    TerraformMembuat dan mengelola VM
    Cloud-initMenyiapkan konfigurasi awal dan SSH key
    AnsibleMengatur server setelah VM tersedia
    DockerMenjalankan aplikasi dalam container

    Peran Terraform

    Terraform digunakan untuk menyediakan infrastruktur di Proxmox.

    Konfigurasi VM seperti nama, CPU, RAM, disk, dan jaringan dituliskan dalam file Terraform. Dengan demikian, VM tidak perlu dibuat satu per satu melalui web interface.

    Terraform juga menyimpan state untuk mencatat infrastruktur yang sudah dibuat dan perubahan yang perlu diterapkan.

    Peran Cloud-init

    Cloud-init menjalankan konfigurasi awal ketika VM pertama kali dibuat.

    Dalam artikel ini, Cloud-init digunakan untuk memasukkan SSH key ke dalam VM Ubuntu. SSH key tersebut memungkinkan Ansible masuk ke server tanpa menggunakan password secara manual.

    Peran Ansible

    Setelah VM aktif dan dapat diakses melalui SSH, Ansible menjalankan konfigurasi di dalam server.

    Tugas Ansible dalam skenario ini meliputi:

    • Menghubungkan ke VM melalui SSH.
    • Menginstal Docker.
    • Menyiapkan kebutuhan server.
    • Menjalankan container.

    Terraform dan Ansible

    Terraform dan Ansible memiliki tugas yang berbeda.

    TerraformAnsible
    Membuat infrastrukturMengonfigurasi server
    Membuat virtual machineMenginstal aplikasi
    Mengelola resource ProxmoxMenjalankan Docker dan container
    Menggunakan stateMenggunakan inventory dan playbook

    Secara sederhana:

    Terraform membuat server, sedangkan Ansible mengatur isi server.

    Keuntungan Pendekatan Ini

    Dengan menyimpan konfigurasi sebagai kode, homelab menjadi:

    • Lebih konsisten.
    • Mudah dibuat ulang.
    • Tidak bergantung pada langkah manual.
    • Dapat disimpan dalam version control.
    • Lebih mudah dikelola ketika jumlah VM bertambah.

    Rencana Percobaan di Homelab

    Untuk mempraktikkan skenario ini, saya akan menggunakan satu VM sebagai controller dan tiga VM Ubuntu sebagai target. Seluruh server berada pada network 192.168.14.0/24.

    Rancangan IP Address

    HostnameFungsiIP Address
    automation-controllerMenjalankan Terraform dan Ansible192.168.14.80
    ubuntu-target01VM target pertama192.168.14.81
    ubuntu-target02VM target kedua192.168.14.82
    ubuntu-target03VM target ketiga192.168.14.83

    Konfigurasi jaringan yang digunakan:

    KonfigurasiNilai
    Network192.168.14.0/24
    Gateway192.168.14.31
    Proxmox bridgevmbr0
    Metode IPStatic melalui Cloud-init

    Topologi Homelab

                        Network 192.168.14.0/24
                                  │
                        Proxmox VE / vmbr0
                                  │
              ┌───────────────────┴───────────────────┐
              │                                       │
    automation-controller                     VM Target Ubuntu
       192.168.14.80                    ┌────────────────────────┐
       Terraform                        │ target01 192.168.14.81 │
       Ansible                          │ target02 192.168.14.82 │
                                       │ target03 192.168.14.83 │
                                       └────────────────────────┘
    

    Alur Percobaan

    1. Menyiapkan VM automation-controller.
    2. Menginstal Terraform dan Ansible pada controller.
    3. Menyiapkan template Ubuntu Cloud-init di Proxmox.
    4. Menghubungkan Terraform dengan Proxmox.
    5. Menjalankan Terraform untuk membuat tiga VM target.
    6. Cloud-init mengatur hostname, IP address, user, dan SSH key.
    7. Ansible mengakses seluruh VM target melalui SSH.
    8. Ansible menginstal Docker dan menjalankan container.
    9. Memastikan seluruh VM dan container berjalan dengan baik.

    Pembagian Tugas

    TahapTools
    Membuat VM di ProxmoxTerraform
    Mengatur IP dan SSH keyCloud-init
    Menginstal DockerAnsible
    Menjalankan aplikasiDocker container

    Hasil yang Diharapkan

    Setelah percobaan selesai, tiga VM Ubuntu dapat dibuat secara otomatis tanpa konfigurasi manual melalui web interface Proxmox.

    Seluruh VM memiliki IP statis, dapat diakses melalui SSH dari controller, dan sudah menjalankan Docker serta container yang ditentukan melalui Ansible.

    Kesimpulan

    Artikel ini menunjukkan cara menggabungkan Proxmox, Terraform, Cloud-init, dan Ansible untuk membangun homelab otomatis.

    Terraform membuat tiga VM Ubuntu, Cloud-init menyiapkan SSH key, kemudian Ansible menginstal Docker dan menjalankan container.

    Dengan pembagian tersebut, proses pembangunan homelab menjadi lebih terstruktur, dapat diulang, dan lebih mudah dikelola.

    Referensi

    Proxmox Homelab Automation with Ansible & Terraform
    https://proxmox.mrplanb.com/proxmox-ansible-terraform-homelab

  • Memahami Zimlet pada Zimbra

    Memahami Zimlet pada Zimbra

    Zimbra bukan hanya sekadar mail server yang menyediakan layanan email, kalender, kontak, dan task. Salah satu fitur yang membuat Zimbra fleksibel adalah Zimlet, sebuah mekanisme yang memungkinkan system admin maupun developer mengintegrasikan Zimbra dengan aplikasi, layanan, atau sistem lain tanpa harus mengubah kode inti Zimbra. Zimlet telah menjadi salah satu fitur unggulan sejak awal pengembangan Zimbra dan terus berkembang hingga versi modern.

    Pada artikel ini kita akan membahas apa itu Zimlet, bagaimana cara kerjanya, jenis-jenis Zimlet, contoh implementasinya, hingga cara admin mengelolanya di server Zimbra.


    Apa Itu Zimlet?

    Zimlet adalah ekstensi (plugin) yang dirancang untuk menambahkan kemampuan baru pada Zimbra Collaboration. Dengan Zimlet, informasi di dalam email dapat menjadi interaktif (actionable content) sehingga pengguna dapat berinteraksi langsung dengan aplikasi atau layanan lain tanpa meninggalkan antarmuka Zimbra.

    Sederhananya, Zimlet dapat:

    • Menambahkan menu baru pada antarmuka Zimbra.
    • Menghubungkan email dengan aplikasi pihak ketiga.
    • Menampilkan informasi tambahan ketika pengguna mengarahkan kursor ke suatu objek.
    • Menambahkan fitur drag-and-drop.
    • Menambahkan tab atau panel baru pada Zimbra Web Client.

    Mengapa Zimlet Dibuat?

    Pada umumnya, ketika menerima email yang berisi alamat, nomor resi, atau nomor penerbangan, pengguna harus membuka browser lalu mencari informasi tersebut secara manual.

    Dengan Zimlet, proses tersebut menjadi jauh lebih sederhana.

    Contohnya:

    • Alamat pada email langsung dapat dibuka di Google Maps.
    • Nomor penerbangan dapat menampilkan status penerbangan secara real-time.
    • Nomor tiket helpdesk langsung membuka halaman tiket.
    • Nomor telepon dapat langsung dihubungkan ke aplikasi VoIP.
    • Link meeting dapat langsung membuka Zoom atau Microsoft Teams.

    Semua proses tersebut berlangsung tanpa harus keluar dari Zimbra.

    Contoh Zimlet Bawaan Zimbra

    Beberapa Zimlet sudah tersedia secara default pada instalasi Zimbra.

    Contohnya:

    ZimletFungsi
    URLPreview website
    EmailMenampilkan informasi kontak
    CalendarMembuka jadwal pada tanggal tertentu
    PhoneIntegrasi VoIP
    MapsMembuka lokasi pada peta
    Skype / Zoom (tergantung versi)Membuka aplikasi meeting

    Admin dapat mengaktifkan atau menonaktifkan Zimlet sesuai kebutuhan.


    Jenis-Jenis Zimlet

    Secara umum terdapat beberapa jenis Zimlet.

    1. Content Zimlet

    Jenis ini bekerja dengan mendeteksi pola tertentu pada isi email.

    Misalnya:

    • alamat email
    • URL
    • tanggal
    • nomor telepon
    • alamat fisik

    Kemudian objek tersebut dibuat menjadi interaktif.


    2. Panel Zimlet

    Panel Zimlet muncul pada panel sebelah kiri Zimbra.

    Biasanya digunakan sebagai launcher aplikasi.

    Contohnya:

    • CRM
    • Helpdesk
    • ERP
    • Dashboard internal

    Pengguna dapat melakukan drag-and-drop email ke Panel Zimlet untuk menjalankan aksi tertentu.


    3. Tab Zimlet

    Jenis ini membuat tab baru pada menu utama Zimbra.

    Contohnya:

    Mail
    Calendar
    Contacts
    Tasks
    CRM
    Helpdesk
    Inventory

    Dengan begitu aplikasi perusahaan dapat diakses langsung dari dalam Zimbra.


    4. Integrated Zimlet

    Jenis ini merupakan Zimlet yang terintegrasi lebih dalam dengan antarmuka Zimbra.

    Contohnya:

    • menambahkan tombol baru
    • menambahkan menu klik kanan
    • membuat dialog baru
    • mengubah perilaku UI tertentu

    Jenis ini biasanya digunakan pada implementasi enterprise.


    Struktur Dasar Zimlet

    Sebuah paket Zimlet biasanya didistribusikan dalam bentuk file ZIP yang berisi beberapa komponen.

    Contohnya:

    com_example_demo.zip
    
    ├── com_example_demo.xml
    ├── com_example_demo.js
    ├── com_example_demo.properties
    ├── config_template.xml
    ├── images/
    ├── css/
    └── jsp/

    Penjelasan singkat:

    FileFungsi
    XMLMendefinisikan Zimlet
    JSLogika JavaScript
    JSPKomunikasi server (opsional)
    PropertiesMulti bahasa
    CSSTampilan
    ImagesIkon

    File yang paling penting adalah file XML, karena di sinilah perilaku dasar Zimlet didefinisikan.

    Mengelola Zimlet di Zimbra

    System admin dapat mengelola Zimlet menggunakan utilitas zmzimletctl.

    Melihat daftar Zimlet

    su - zimbra
    
    zmzimletctl listZimlets

    Deploy Zimlet

    zmzimletctl deploy nama-zimlet.zip

    Menonaktifkan Zimlet

    zmzimletctl disable nama_zimlet

    Mengaktifkan kembali

    zmzimletctl enable nama_zimlet

    Menghapus Zimlet

    zmzimletctl undeploy nama_zimlet

    Perintah-perintah tersebut memungkinkan admin mengelola siklus hidup Zimlet langsung dari command line.

    Kesimpulan

    Zimlet merupakan salah satu fitur yang menjadikan Zimbra lebih dari sekadar mail server. Dengan kemampuannya mengintegrasikan email dengan aplikasi dan layanan lain, Zimlet mampu meningkatkan produktivitas pengguna sekaligus menyederhanakan alur kerja di lingkungan perusahaan.

    Bagi system admin, Zimlet dapat dikelola dengan mudah melalui zmzimletctl, sedangkan bagi developer, Zimlet menyediakan kerangka kerja yang fleksibel untuk membangun integrasi dengan berbagai sistem internal maupun layanan pihak ketiga. Memahami konsep dan cara kerja Zimlet menjadi langkah awal yang penting sebelum mulai mengembangkan atau menerapkan integrasi pada lingkungan Zimbra.


    Referensi

    1. Zimbra Wiki – Zimlets
      https://wiki.zimbra.com/wiki/Zimlets
    2. GitHub – Zimbra Zimlet Guide
      Zimbra zm-zimlet-guide Repository
    3. Zimbra Developers Guide (Modern UI Zimlet Development)
      https://wiki.zimbra.com/wiki/DevelopersGuide#Zimlet_Development_Guide
  • Cara Mengatasi zmamavisdctl Gagal Start Setelah Upgrade Zimbra NE 10.1.20

    Cara Mengatasi zmamavisdctl Gagal Start Setelah Upgrade Zimbra NE 10.1.20

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

    Akibatnya:

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

    Gejala

    Cek status service:

    zmcontrol status

    Hasil:

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

    Log Postfix menunjukkan:

    connect to 127.0.0.1:10026: Connection refused

    Artinya Amavis tidak berhasil membuka port filtering SMTP.


    Proses Troubleshooting

    1. Pastikan penyebab

    Jalankan:

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

    Jika tidak ada output, berarti konfigurasi Amavis valid.


    2. Jalankan Amavis secara foreground

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

    Didapatkan error:

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

    3. Periksa SpamAssassin

    Lakukan pengecekan:

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

    Hasil akhirnya menunjukkan:

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

    Padahal direktori rules masih lengkap.


    4. Jalankan sa-update

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

    Didapatkan error:

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

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


    Solusi

    1. Buat direktori key

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

    2. Download GPG Key resmi

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

    3. Import GPG Key

    Jalankan sebagai user zimbra.

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

    4. Update SpamAssassin Rules

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

    Pastikan proses selesai tanpa error GPG.

    5. Restart Service

    zmamavisdctl restart

    atau

    zmcontrol restart

    Verifikasi

    Pastikan service kembali berjalan:

    zmcontrol status

    Hasil yang diharapkan:

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

    Lalu pastikan dapat mengirim email secara normal kembali.


    Kesimpulan

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

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

    Referensi

  • 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/