Rafi Harlianto

Informatics Engineering

Category: IT

  • Troubleshooting “Undefined array key node” di Nextcloud Notes

    Troubleshooting “Undefined array key node” di Nextcloud Notes

    Jadi ceritanya minggu ini saya lagi dalam proses memahami Nextcloud lebih dalam, mulai dari instalasi sampai monitoring. Nah, waktu saya buka Log Reader di Settings, saya menemukan warning yang terus muncul berulang:

    Warning ini muncul dalam selang waktu yang berdekatan, sekitar jam 1 siang. Levelnya “Warning” dari aplikasi PHP. Karena penasaran, saya coba telusuri sendiri penyebabnya. Dan ternyata cukup menarik.

    Sedikit Teori

    Sebelum masuk ke proses troubleshoot-nya, saya mau jelasin dulu beberapa konsep yang relevan biar lebih mudah dipahami.

    Apa itu occ? occ adalah command-line tool milik Nextcloud, semacam “remote control” untuk server Nextcloud kalian. Hampir semua konfigurasi, pengecekan, dan perbaikan bisa dilakukan lewat sini tanpa harus buka browser.

    Apa itu Undefined array key? Di PHP, ini adalah warning yang muncul ketika sebuah kode mencoba mengakses key tertentu dari sebuah array, tapi key itu tidak ada. Analoginya seperti kalian mencari laci bernama “node” di lemari, tapi lacinya tidak ada — PHP akan komplain, tapi tidak langsung crash.

    Apa itu Destructuring Assignment? Ini adalah cara PHP modern untuk mengambil beberapa nilai dari array sekaligus dalam satu baris. Contohnya:

    ['nama' => $nama, 'umur' => $umur] = $dataOrang;

    Artinya: ambil nilai dari key ‘nama’ masukkan ke variabel ‘nama’ dan key ‘umur’ masuk ke variabel ‘umur’. Kalau salah satu key tidak ada di array-nya, PHP akan kasih warning Undefined array key.

    Langkah 1 — Cek Versi dan Status Aplikasi Notes

    Langkah pertama yang saya lakukan adalah mengecek versi aplikasi Notes yang terpasang, sekaligus mencoba update kalau ada versi baru.

    sudo -u www-data php /var/www/nextcloud/occ app:list | grep notes

    Output:

    Lalu saya coba update:

    sudo -u www-data php /var/www/nextcloud/occ app:update notes

    Output:

    Ternyata Notes sudah di versi terbaru. Artinya bug ini bukan karena versi yang ketinggalan, melainkan memang ada di kode versi tersebut. Ini petunjuk bahwa saya perlu masuk lebih dalam ke kodenya.

    Langkah 2 — Lihat Langsung Baris yang Bermasalah

    Karena log sudah menunjukkan lokasi persis masalahnya (NoteUtil.php#201), saya langsung buka baris tersebut:

    sed -n '201p' /var/www/nextcloud/apps/notes/lib/Service/NoteUtil.php

    Output:

    Baris ini menggunakan destructuring assignment. Kode ini mengharapkan fungsi getDefaultNotesNode() mengembalikan array yang punya key 'path' dan 'node'. Tapi kalau salah satu key tidak ada, PHP langsung lempar warning. Pertanyaannya sekarang: apa yang sebenarnya dikembalikan oleh fungsi getDefaultNotesNode()?

    Langkah 3 — Cari dan Baca Fungsi Sumbernya

    Kemudian saya tanya ClaudeAI fungsi tersebut dan akhirnya disarankan mencari di file SettingsService.php di mana fungsi getDefaultNotesNode itu didefinisikan:

    grep -n "getDefaultNotesNode" /var/www/nextcloud/apps/notes/lib/Service/SettingsService.php

    Output:

    Lalu saya baca isi fungsinya:

    nano /var/www/nextcloud/apps/notes/lib/Service/SettingsService.php

    Output:

    Nah, ketemu. Fungsi getDefaultNotesNode() di SettingsService.php selalu mengembalikan array dengan key 'folder', bukan 'node'. Tapi di NoteUtil.php baris 201, kode justru mengharapkan key 'node'. Ini inkonsistensi yang jelas — satu file bilang 'folder', file lain ekspektasi 'node'. Inilah penyebab warning yang terus muncul.

    Langkah 4 — Backup File Sebelum Edit

    Sebelum mengubah apapun, saya backup file aslinya dulu. Ini kebiasaan yang sebaiknya tidak pernah dilewati:

    cp /var/www/nextcloud/apps/notes/lib/Service/NoteUtil.php /var/www/nextcloud/apps/notes/lib/Service/NoteUtil.php.bak

    Output:

    File backup ini akan berguna kalau edit yang dilakukan ternyata malah memperburuk keadaan. Tinggal restore dari file .bak dan kondisi kembali seperti semula.

    Langkah 5 — Perbaiki Baris

    Sekarang saatnya perbaiki. Buka file NoteUtil.php dan cari baris 201:

    nano /var/www/nextcloud/apps/notes/lib/Service/NoteUtil.php

    Cari baris ini (Ctrl + / lalu ketik 201 untuk langsung ke baris 201 di nano):

    Sebelum:

    Sesudah:

    Simpan dengan Ctrl + X lalu Y dan Enter.

    Perubahan yang dilakukan sangat kecil — hanya mengganti kata 'node' menjadi 'folder' agar sesuai dengan key yang benar-benar dikembalikan oleh fungsi getDefaultNotesNode(). Sekarang destructuring assignment-nya akan berhasil menemukan key yang dicari.

    Langkah 6 — Bersihkan Cache dan Repair

    Setelah edit kode, saya jalankan repair untuk membersihkan cache dan memastikan tidak ada efek samping:

    sudo -u www-data php /var/www/nextcloud/occ maintenance:repair

    Output:

    Perintah maintenance:repair akan membersihkan cache, memeriksa ulang struktur database, dan menjalankan berbagai perbaikan otomatis. Ini langkah standar setelah melakukan perubahan manual di file Nextcloud.

    Langkah 7 — Verifikasi, Cek Log Lagi

    Terakhir, saya buka lagi Notes di browser dan pantau log:

    sudo -u www-data php /var/www/nextcloud/occ log:tail

    Output:

    Warning tidak muncul lagi. Fix berhasil.

    Ternyata penyebab warning ini bukan dari konfigurasi server yang salah, bukan dari instalasi yang keliru, dan bukan dari masalah permission. Ini murni bug inkonsistensi nama key di kode aplikasi Notes itu sendiri fungsi di satu file mengembalikan key 'folder', tapi file lain mengharapkan key 'node'.

    Hal yang saya pelajari dari troubleshoot kali ini:

    • Log Nextcloud sangat informatif dan menunjukkan lokasi masalah dengan tepat (saya pakai cron setiap 5 menit)
    • Selalu backup sebelum edit file apapun
    • Bug di aplikasi pihak ketiga Nextcloud bisa saja ada meski sudah versi terbaru
    • sed -n 'Np' adalah cara cepat untuk melihat baris tertentu di file tanpa harus membuka seluruh file
  • Mengaktifkan dan Mengelola Fitur-Fitur Nextcloud

    Mengaktifkan dan Mengelola Fitur-Fitur Nextcloud

    Nextcloud menyediakan berbagai fitur tambahan yang dapat diaktifkan melalui sistem Apps. Fitur-fitur ini mencakup kolaborasi, komunikasi, manajemen proyek, hingga pengelolaan file yang lebih canggih. Instalasi aplikasi dapat dilakukan melalui dua metode, yaitu Graphical User Interface (GUI) melalui browser, dan Command Line Interface (CLI) menggunakan perintah occ.

    Dokumen ini menjelaskan kedua metode tersebut secara teknis, lengkap dengan contoh penggunaan dan best practice.

    Metode Instalasi App

    1. Instalasi via GUI (Browser)

    Metode ini direkomendasikan untuk pengguna atau admin yang lebih nyaman dengan antarmuka visual.

    Langkah-langkah:

    • Login ke dashboard Nextcloud sebagai user admin
    • Klik ikon profil di kanan atas
    • Pilih menu Apps
    • Gunakan fitur pencarian atau pilih menu di side bar untuk mencari aplikasi yang diinginkan
    • Klik tombol Download and Enable

    Kelebihan:

    • Mudah digunakan
    • Tidak perlu akses terminal
    • Cocok untuk instalasi cepat

    Kekurangan:

    • Tidak efisien untuk bulk install
    • Kurang fleksibel untuk automasi

    2. Instalasi via CLI (occ Command)

    Metode ini digunakan untuk administrasi tingkat lanjut, automasi, dan deployment.

    Struktur command:

    sudo -u www-data php /var/www/nextcloud/occ app:install <nama_app>

    Daftar Aplikasi dan Perintah Instalasi

    Calendar & Contacts

    Digunakan untuk manajemen jadwal dan buku kontak.

    sudo -u www-data php /var/www/nextcloud/occ app:install calendar
sudo -u www-data php /var/www/nextcloud/occ app:install contacts

    Notes

    Digunakan untuk mencatat informasi sederhana dan sinkronisasi antar perangkat.

    sudo -u www-data php /var/www/nextcloud/occ app:install notes

    Talk (Chat, Voice, Video Call)

    Digunakan untuk komunikasi real-time antar user.

    sudo -u www-data php /var/www/nextcloud/occ app:install spreed

    Catatan:

    • Peer-to-peer (1-on-1 di LAN) dapat langsung digunakan
    • Group call dan akses dari luar LAN memerlukan TURN/STUN server (HPB)

    Mail (Email Client)

    Mengintegrasikan email ke dalam Nextcloud.

    sudo -u www-data php /var/www/nextcloud/occ app:install mail

    Untuk fitur ini perlu pengaturan SMTP

    Tasks

    Manajemen to-do list yang terintegrasi dengan Calendar.

    sudo -u www-data php /var/www/nextcloud/occ app:install tasks

    Photos

    Pengelolaan galeri foto dengan tampilan yang lebih optimal.

    sudo -u www-data php /var/www/nextcloud/occ app:install photos

    Deck

    Digunakan untuk manajemen proyek berbasis Kanban.

    sudo -u www-data php /var/www/nextcloud/occ app:install deck

    Forms

    Digunakan untuk membuat formulir atau survey.

    sudo -u www-data php /var/www/nextcloud/occ app:install forms

    Bookmarks

    Menyimpan dan mengelola bookmark secara terpusat.

    sudo -u www-data php /var/www/nextcloud/occ app:install bookmarks

    Password Manager

    Mengelola password secara aman di dalam Nextcloud.

    sudo -u www-data php /var/www/nextcloud/occ app:install passwords

    Tahap Setelah Instalasi

    Setelah melakukan instalasi aplikasi, disarankan untuk menjalankan proses maintenance untuk memastikan integrasi berjalan optimal.

    Maintenance Repair Otomatis

    sudo -u www-data php /var/www/nextcloud/occ maintenance:repair --include-expensive

    Clear Cache

    sudo -u www-data php /var/www/nextcloud/occ cache:clear

// Jika pakai redis cache
sudo -u www-data php /var/www/nextcloud/occ memcache:distributed:clear

    Upgrade Nextcloud

    sudo -u www-data php /var/www/nextcloud/occ upgrade

    Restart PHP dan Nginx Web Server

    systemctl restart php8.4-fpm.service nginx.service

// Jika pakai redis cache tambahkan
redis-server.service

    Penjelasan:

    • maintenance:repair: Memperbaiki struktur sistem dan database
    • cache:clear: Membersihkan cache untuk menghindari konflik
    • upgrade: Sinkronisasi versi app dan core
    • restart service: Reload konfigurasi PHP dan web server

    Manajemen Aplikasi via CLI

    Melihat daftar aplikasi

    sudo -u www-data php /var/www/nextcloud/occ app:list

    Mengaktifkan aplikasi

    sudo -u www-data php /var/www/nextcloud/occ app:enable <nama_app>

    Menonaktifkan aplikasi

    sudo -u www-data php /var/www/nextcloud/occ app:disable <nama_app>

    Update semua aplikasi

    sudo -u www-data php /var/www/nextcloud/occ app:update --all

    Melihat informasi aplikasi

    sudo -u www-data php /var/www/nextcloud/occ app:info <nama_app>

    Catatan Nextcloud Talk dan TURN Server

    Nextcloud Talk memiliki beberapa skenario penggunaan yang menentukan apakah TURN server diperlukan.

    SkenarioPerlu TURNKeterangan
    Chat teks antar user LANTidakLangsung berjalan
    Video/voice call 1-on-1 LANTidakPeer-to-peer
    Group call (lebih dari 2 user)DisarankanMembutuhkan HPB
    Akses dari luar jaringanWajibMembutuhkan TURN/STUN

    Kesimpulan:

    • Untuk penggunaan internal LAN, konfigurasi tambahan tidak diperlukan
    • Untuk produksi (internet/public), wajib menggunakan TURN server dan domain
  • Menambahkan OSD Baru dan Mengatur Class SSD/HDD pada Ceph

    Menambahkan OSD Baru dan Mengatur Class SSD/HDD pada Ceph

    Hari ini saya mencoba melanjutkan latihan pada cluster Proxmox yang sudah saya bangun sebelumnya. Saya menulis catatan ini karena saya merasa masih perlu banyak latihan dan troubleshooting, terutama pada bagian storage. Saat ini saya memang masih sering menemukan hal-hal yang perlu saya pahami lebih dalam, baik di Nextcloud maupun di Ceph, sehingga saya ingin mendokumentasikan setiap percobaan yang saya lakukan supaya alurnya tidak hilang dan bisa saya pelajari ulang ketika dibutuhkan.

    Tujuan percobaan hari ini adalah menambahkan disk baru pada Proxmox, menjadikannya sebagai OSD Ceph, lalu mengatur class storage supaya bisa dibedakan antara SSD dan HDD. Hal ini penting karena di lingkungan storage seperti Ceph, pengelompokan disk berdasarkan class sangat membantu untuk mengatur distribusi data, menentukan pool, dan memisahkan storage yang dipakai untuk kebutuhan cepat dan kebutuhan biasa. Dengan begitu, saya bisa mulai memahami bagaimana Ceph bekerja bukan hanya sebagai storage cluster, tetapi juga sebagai sistem yang mengatur penempatan data berdasarkan aturan tertentu.

    1. Mengecek disk baru yang tersedia

    Langkah pertama yang saya lakukan adalah memastikan disk baru benar-benar terdeteksi di node. Saya cek dengan lsblk.

    lsblk | grep sdd

    Dari hasil pengecekan, disk sdd muncul sebagai disk 20 GB. Ini menandakan bahwa disk tersebut sudah terbaca oleh sistem dan siap untuk dipakai sebagai kandidat OSD.

    Pada tahap ini saya hanya memastikan disk baru tersedia dan belum dipakai oleh partisi lama, LVM, atau Ceph. Ini penting karena kalau disk masih memiliki sisa konfigurasi lama, proses pembuatan OSD bisa gagal atau menghasilkan status yang tidak sehat.

    2. Membuat OSD baru dari disk tersebut

    Setelah yakin disk tersedia, saya langsung mencoba menjadikannya OSD dengan ceph-volume.

    ceph-volume lvm create --data /dev/sdd

    Dari output yang muncul, terlihat bahwa physical volume berhasil dibuat di /dev/sdd.

    Saya memahami bahwa perintah ini cukup penting karena Ceph akan menangani proses pembuatan LVM dan OSD secara otomatis. Jadi saya tidak perlu membuat PV, VG, atau LV satu per satu secara manual. Dengan ceph-volume, proses pembuatan OSD menjadi lebih singkat dan terstruktur.

    3. Mengecek hasil OSD di cluster

    Setelah OSD dibuat, saya cek lagi struktur OSD yang ada dengan:

    ceph osd tree

    Dari hasil ini saya melihat bahwa OSD baru sudah masuk ke cluster dan statusnya up. Namun, class yang digunakan masih default, yaitu hdd.

    Di tahap ini saya membuktikan bahwa OSD baru memang sudah berhasil bergabung ke cluster. Artinya disk baru tidak hanya terbaca di sistem, tetapi juga sudah dikenal oleh Ceph sebagai bagian dari storage cluster.

    4. Mencoba mengubah class OSD menjadi SSD

    Karena saya ingin mensimulasikan pemisahan storage antara HDD dan SSD, saya mencoba mengubah salah satu OSD menjadi class SSD.

    ceph osd crush set-device-class ssd osd.3

    Namun ternyata muncul error bahwa OSD tersebut sudah terikat pada class hdd, sehingga class tidak bisa langsung diganti.

    Dari sini saya belajar bahwa Ceph tidak mengizinkan class OSD diubah secara langsung jika OSD tersebut sudah memiliki class sebelumnya. Jadi saya tidak bisa langsung melakukan perubahan dari hdd ke ssd tanpa menghapus class lama terlebih dahulu. Ini cukup penting karena saya sempat mengira class bisa diganti begitu saja.

    5. Menghapus class lama terlebih dahulu

    Untuk mengatasi error tadi, saya terlebih dahulu menghapus class yang lama.

    ceph osd crush rm-device-class osd.3

    Setelah perintah ini dijalankan, Ceph menghapus class yang menempel pada OSD tersebut.

    Langkah ini menunjukkan bahwa perubahan class di Ceph harus dilakukan secara berurutan. Saya harus membersihkan label class lama sebelum menetapkan class baru. Jadi alurnya bukan langsung mengganti, tetapi hapus dulu lalu set ulang.

    6. Menetapkan class baru menjadi SSD

    Setelah class lama dihapus, barulah saya bisa menetapkan class baru untuk osd.3, osd.4 dan osd.5.

    ceph osd crush set-device-class ssd osd.3

    Setelah itu saya cek kembali hasilnya dengan ceph osd tree.

    Pada titik ini saya berhasil mengubah OSD tersebut menjadi class SSD. Ini penting karena sekarang saya bisa mulai memisahkan storage berdasarkan jenis disk, walaupun di lab ini semua masih berupa simulasi. Hasil akhirnya, di cluster saya ada OSD dengan class HDD dan ada OSD dengan class SSD.

    7. Hasil akhir pembagian class OSD

    Setelah dicek kembali, hasil akhirnya menjadi seperti ini:

    • rafi1
      • osd.0 → hdd
      • osd.3 → ssd
    • rafi2
      • osd.2 → hdd
      • osd.4 → ssd
    • rafi3
      • osd.1 → hdd
      • osd.5 → ssd

    Dari hasil ini saya berhasil membuat simulasi storage tiering sederhana. Dengan adanya pemisahan class, saya bisa melanjutkan ke tahap berikutnya yaitu membuat CRUSH rule dan pool berdasarkan class tersebut. Ini membuka jalan agar saya bisa memisahkan storage cepat dan storage biasa dalam satu cluster Ceph.

    Dari percobaan hari ini, saya mendapatkan beberapa poin penting:

    Pertama, disk baru harus dipastikan benar-benar terbaca dan bersih sebelum dijadikan OSD. Kedua, ceph-volume sangat membantu karena proses pembuatan OSD bisa dilakukan otomatis. Ketiga, class OSD di Ceph tidak bisa langsung diganti, sehingga saya harus menghapus class lama terlebih dahulu sebelum menetapkan class baru. Keempat, pembagian class seperti SSD dan HDD sangat berguna untuk menyiapkan struktur storage yang lebih rapi dan mudah diatur.

    Akhir Kata

    Percobaan hari ini membuat saya lebih paham bagaimana Ceph mengelola OSD dan class storage. Walaupun terlihat sederhana, ternyata ada alur yang harus diikuti dengan benar supaya hasilnya sesuai. Saya juga jadi lebih mengerti bahwa Ceph sangat ketat dalam hal metadata storage, terutama saat mengatur device class.

    Catatan ini saya buat sebagai dokumentasi pribadi supaya ketika saya mengulang setup ini lagi, saya tidak perlu menebak-nebak dari awal. Ke depannya mungkin saya melanjutkan ke pembuatan CRUSH rule, pool berdasarkan class, lalu menghubungkannya dengan pengujian VM dan storage yang lebih real.

  • Backup File ke PBS Menggunakan proxmox-backup-client

    Backup File ke PBS Menggunakan proxmox-backup-client

    Hari ini saya melanjutkan training Proxmox VE, dan seperti biasa, saya mencoba mensimulasikan skenario yang mendekati kondisi production. Kali ini yang saya uji adalah backup file langsung dari dalam VM menggunakan Proxmox Backup Client, bukan hanya backup VM atau LXC ke PBS seperti biasanya, tapi backup folder spesifik seperti /etc langsung dari dalam sistem operasi guest.

    Setup lab saya waktu itu cukup sederhana:

    Semuanya terlihat lancar sampai saya jalanin perintah ini:

    Command:

    apt install proxmox-backup-client

    Output nya malah:

    Saya sempat bingung. Ini fitur Proxmox, tapi kenapa tidak ada di Ubuntu?

    Penyebabnya

    Setelah saya telusuri dan tanya-tanya AI, jawabannya ternyata sederhana, “Ubuntu tidak memiliki repository Proxmox secara default.”

    Paket proxmox-backup-client memang tidak ada di repo bawaan Ubuntu. Jadi apt tidak tahu harus mengambilnya dari mana. Ini berbeda dengan node Proxmox VE atau PBS yang sudah menyertakan repository mereka sendiri sejak awal instalasi.

    Di sinilah saya mulai memahami satu hal yang sebelumnya tidak terlalu saya perhatikan, ekosistem Proxmox tidak bergantung pada repository Ubuntu atau Debian standar. Proxmox punya repository sendiri, dan kalau kita ingin menggunakan tool seperti Proxmox Backup Client di luar ekosistem itu, kita harus menambahkan repository-nya secara manual.

    Langkah-langkah

    Berikut cara yang saya gunakan sampai akhirnya berhasil:

    1. Tambahkan repository Proxmox Backup Client

    echo "deb http://download.proxmox.com/debian/pbs-client bookworm main" > /etc/apt/trusted.gpg.d/pbs-client.list

    2. Tambahkan GPG key

    wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release.gpg

    3. Update package list

    apt update

    4. Install ulang

    apt install proxmox-backup-client

    Setelah itu, instalasi berjalan tanpa error. Verifikasi dengan menjalankan:

    proxmox-backup-client version

    Output versi muncul — client sudah siap digunakan.

    Percobaan Backup

    Kemudian saya langsung jalankan backup folder /etc dengan command: 

    proxmox-backup-client backup etc.pxar:/etc --repository pvebackup@pbs@192.168.X.X:pbsstore

    Hasilnya: backup berhasil, file muncul di datastore PBS, dan bisa dilihat langsung dari web UI. Persis seperti yang diharapkan.

    Catatan

    Pertama, soal repository. Ubuntu 24.04, meskipun sudah modern, tidak secara otomatis menyertakan paket-paket dari ekosistem Proxmox. Kita perlu menambahkan repository-nya sendiri.

    Kedua, soal versi codename. Harus menggunakan bookworm karena Proxmox berbasis Debian Bookworm, dan repository PBS Client pun mengikuti codename yang sama. Ini penting agar tidak terjadi konflik dependensi.

    Ketiga, dan ini yang paling saya highlight, error ini bukan sesuatu yang salah. Ini normal, dan banyak orang yang baru masuk ke dunia Proxmox pasti akan menemuinya.

    Akhir Kata Rafi

    Dari uji coba hari ini, saya jadi lebih paham bahwa belajar Proxmox bukan hanya tentang virtualisasi atau manajemen VM. Ada sisi ekosistem yang perlu dipahami juga, mulai dari bagaimana repository-nya bekerja, sampai bagaimana tool seperti PBS Client berinteraksi dengan sistem operasi guest.

    Seharusnya sih saya menulis tentang cara pembuatan PBS dulu ya. Tapi tidak apa lah ini untuk catatan saya untuk kedepannya. Kalau kalian sedang di tahap yang sama, sedang mengeksplorasi PBS dan ingin mencoba backup client langsung dari dalam VM — kemungkinan besar kamu juga akan menemui error yang sama. Semoga tulisan ini bisa menghemat waktu yang biasanya habis untuk trial and error.

  • Langkah Pengecekan Rutin Nextcloud via CLI

    Langkah Pengecekan Rutin Nextcloud via CLI

    Minggu ini saya dapat tugas yang cukup menarik sekaligus bikin penasaran, yaitu mempelajari Nextcloud lebih dalam. Bukan sekadar pakai, tapi benar-benar pahami cara kerjanya dari dalam. Untuk instalasi sendiri sudah selesai saya lakukan, tapi jujur saja saya belum 100% yakin instalasinya sudah benar atau masih ada yang kekeliruan di sana-sini. Daripada langsung dipakai dan nanti kaget kalau ada masalah, saya pikir langkah yang paling masuk akal adalah melakukan pengecekan dulu secara menyeluruh.

    Nah, dari situ saya mulai cari-cari cara pengecekan yang bisa dilakukan lewat CLI (Command Line Interface). Kenapa CLI? Karena menurut saya, CLI memberikan informasi yang lebih langsung dan detail dibanding antarmuka web, dan ini cocok untuk kondisi saya yang sedang “investigasi” kondisi server. Untuk semua perintah di bawah ini, saya sudah masuk sebagai root, jadi tidak perlu tambahan sudo di setiap perintah.

    Ini dia langkah-langkah pengecekan yang saya coba:

    1. Cek Status Umum Nextcloud

    Langkah pertama yang selalu saya jalankan adalah mengecek status dasar Nextcloud. Ini penting untuk memastikan Nextcloud sudah terinstal dengan benar dan tidak ada masalah mendasar di awal.

    Command

    sudo -u www-data php /var/www/nextcloud/occ status

    Output yang diharapkan kurang lebih seperti ini:

    • installed: true → Nextcloud sudah terinstal
    • version → Menampilkan versi yang sedang berjalan
    • maintenance: false → Nextcloud tidak sedang dalam mode maintenance

    Output:

    Kalau ada yang tidak sesuai di sini, biasanya memang ada yang perlu diperbaiki dari proses instalasi sebelumnya.

    2. Cek Maintenance Mode

    Command:

    sudo -u www-data php /var/www/nextcloud/occ maintenance:mode

    Perintah ini saya jalankan untuk memastikan maintenance mode dalam kondisi mati (disabled). Kalau maintenance mode menyala, user tidak akan bisa mengakses Nextcloud sama sekali. Beberapa hal yang perlu diperhatikan:

    • Kalau outputnya disabled, artinya Nextcloud bisa diakses normal
    • Kalau ternyata enabled, bisa dimatikan dengan menambahkan flag --off di akhir perintah
    • Mode ini biasanya aktif secara otomatis saat proses update berjalan

    3. Cek Apakah Ada Update Tersedia

    Command:

    sudo -u www-data php /var/www/nextcloud/occ update:check

    Meskipun baru instalasi, saya tetap mengecek apakah versi yang saya pasang sudah yang terbaru atau belum. Kenapa ini penting?

    • Versi lama bisa punya celah keamanan yang sudah dipatch di versi baru
    • Beberapa fitur yang saya butuhkan mungkin baru tersedia di versi terbaru
    • Lebih baik tahu dari awal daripada nanti update di tengah-tengah pemakaian

    4. Update Semua Aplikasi yang Terpasang

    bash

    sudo -u www-data php /var/www/nextcloud/occ app:update --all

    Nextcloud punya banyak aplikasi tambahan yang bisa dipasang, dan masing-masing punya versinya sendiri. Saya jalankan perintah ini untuk memastikan semua aplikasi yang terpasang sudah dalam versi terbaru. Beberapa catatan:

    • Proses ini mungkin butuh beberapa menit tergantung jumlah aplikasi
    • Kalau ada aplikasi yang gagal diupdate, akan muncul pesan error yang bisa ditindaklanjuti
    • Pastikan koneksi internet server stabil sebelum menjalankan perintah ini

    5. Scan File di Storage

    Command:

    sudo -u www-data php /var/www/nextcloud/occ files:scan --all

    Ini langkah yang cukup penting, terutama karena saya baru saja selesai instalasi dan belum yakin apakah semua file sudah terdaftar dengan benar di database Nextcloud. Fungsinya:

    • Mendeteksi file yang ada di storage tapi belum terdaftar di database Nextcloud
    • Berguna jika ada file yang diupload langsung ke server (misalnya lewat rsync atau FTP)
    • Memastikan index file sinkron antara yang ada di disk dan yang ada di database

    Proses ini bisa cukup lama kalau data sudah banyak, jadi bersabar saja.

    6. Cek Log Error Terbaru

    Command:

    sudo -u www-data php /var/www/nextcloud/occ log:tail

    Nah, ini favorit saya yang bikin pemahaman penuh. Lewat perintah ini saya bisa melihat error atau warning terbaru yang dicatat oleh Nextcloud. Dari hasil instalasi saya, ada beberapa hal yang biasanya muncul di log:

    • Warning soal permission folder yang kurang tepat
    • Error koneksi ke database (kalau konfigurasi kurang pas)
    • Peringatan soal konfigurasi PHP yang belum optimal
    • Notifikasi background job yang gagal berjalan

    Semua catatan ini sangat membantu saya untuk menilai apakah instalasi saya sudah benar atau masih perlu penyesuaian.

    7. Perbaiki Indeks Database yang Hilang

    Command:

    sudo -u www-data php /var/www/nextcloud/occ db:add-missing-indices

    Setelah instalasi baru, kadang ada indeks database yang belum terbuat secara otomatis. Ini bisa membuat performa Nextcloud terasa lambat meski belum banyak data. Dengan menjalankan perintah ini:

    • Nextcloud akan otomatis mendeteksi indeks yang kurang
    • Menambahkan indeks yang hilang ke database
    • Query database jadi lebih cepat dan efisien
    • Biasanya Nextcloud juga memberi peringatan soal ini di halaman admin jika ada indeks yang kurang

    8. Cek Penggunaan Storage

    Command:

    df -h
du -sh /var/www/nextcloud/data

    Dua perintah sederhana ini saya jalankan untuk memantau kondisi penyimpanan server. Penjelasannya:

    • df -h → Menampilkan keseluruhan penggunaan disk di semua partisi. Saya perhatikan terutama partisi tempat Nextcloud dipasang
    • du -sh /var/www/nextcloud/data → Menampilkan total ukuran folder data Nextcloud secara spesifik

    Ini penting agar saya tahu sejak awal berapa kapasitas yang tersedia, sehingga bisa merencanakan pengelolaan storage ke depannya.

    9. Cek dan Restart Service Jika Diperlukan

    Command

    systemctl status nginx
systemctl status php8.4-fpm

    Terakhir, saya cek status service yang menjalankan Nextcloud. Kalau ternyata ada yang tidak berjalan normal, saya restart dengan:

    Command:

    systemctl restart nginx
systemctl restart php8.4-fpm

    Pastikan versi PHP disesuaikan dengan yang terpasang di server kalian. Untuk mengecek versi PHP yang aktif, bisa pakai perintah php -v.

    Itu dia langkah-langkah pengecekan yang saya coba lakukan setelah instalasi Nextcloud selesai. Mungkin belum sempurna dan masih ada banyak hal yang perlu saya pelajari lebih jauh, tapi setidaknya dari pengecekan ini saya bisa punya gambaran awal tentang kondisi server saya.

    Kalau ternyata dari hasil log atau status ada yang aneh, itu justru bagus, berarti saya bisa tahu lebih awal dan memperbaikinya sebelum benar-benar dipakai. Buat yang juga lagi belajar Nextcloud, semoga catatan ini bermanfaat. Dan kalau ada yang punya masukan atau cara yang lebih efisien, saya sangat terbuka di kolom komentar.

    https://www.excellent.co.id/tag/nextcloud

  • Clone VM ke Storage Ceph via GUI Proxmox

    Clone VM ke Storage Ceph via GUI Proxmox

    Saya sedang membangun belajar Proxmox dengan Ceph untuk memahami konsep Hyper-Converged Infrastructure (HCI). Salah satu hal yang saya uji adalah bagaimana memindahkan VM dari storage lokal ke shared storage, dalam hal ini Ceph, dengan cara yang aman.

    Alih-alih langsung memindahkan disk (move), saya memilih metode clone. Pendekatan ini lebih aman karena VM asli tetap utuh, sehingga jika terjadi kesalahan, saya masih memiliki backup yang bisa digunakan.

    Teori Singkat

    Sebelum masuk ke langkah praktis, saya memahami dulu konsep dasarnya.

    VM yang berada di storage lokal seperti local-lvm hanya bisa diakses oleh satu node. Artinya, jika saya ingin melakukan live migration ke node lain, disk tersebut tidak bisa diakses oleh node tujuan.

    Sebaliknya, Ceph adalah shared storage. Semua node dalam cluster dapat mengakses disk yang sama. Inilah yang memungkinkan live migration tanpa perlu memindahkan disk secara fisik.

    Dengan kata lain:

    • Storage lokal = terbatas pada satu node
    • Ceph = bisa diakses semua node

    Kondisi Awal

    Saya memiliki VM dengan detail berikut:

    VM ID: 100
Node: rafi1
Storage: local-lvm
OS: Alpine Linux

    VM ini masih berada di storage lokal, sehingga belum bisa digunakan untuk live migration.

    Langkah 1 — Clone VM melalui GUI

    Saya membuka Proxmox Web UI, lalu memilih VM yang ingin di-clone, yaitu VM 100. Setelah itu saya klik tombol Clone.

    Di form yang muncul, saya mengisi beberapa parameter:

    • Node: rafi1
    • VM ID: 105
    • Name: alphine-ceph
    • Target Storage: ceph-data tipe RBD
    • Mode: Full Clone

    Klik VM yang ingin diclone -> Klik More -> Pilih Clone

    Pilih Target Storage

    Pilih Ceph

    Pemilihan storage di sini sangat penting. Jika salah memilih, hasil clone tetap akan berada di storage lama. Saya juga memilih Full Clone agar disk benar-benar disalin ke Ceph, bukan sekadar referensi.

    Langkah 2 — Proses Clone

    Setelah menekan tombol Clone, saya melihat proses berjalan di bagian task Proxmox.

    • Baris pertama menunjukkan bahwa proses cloning dimulai dari disk sumber
    • Baris kedua menandakan disk baru berhasil dibuat
    • Baris ketiga menunjukkan proses transfer data ke Ceph beserta kecepatannya

    Dari sini saya bisa memastikan bahwa data benar-benar disalin, bukan dipindahkan.

    Langkah 3 — Verifikasi

    Meskipun saya menggunakan GUI, saya tetap melakukan verifikasi untuk memastikan semuanya benar. Pilih di hardware VM yang sudah dibuat tadi

    Ini menunjukkan bahwa disk VM sudah berada di Ceph. Ini adalah indikator paling penting bahwa proses clone berhasil sesuai tujuan.

    Langkah 4 — Menjalankan VM Clone

    Setelah memastikan konfigurasi benar, saya menjalankan VM hasil clone.

    Saya kemudian melakukan pengujian sederhana:

    • Ping ke IP VM berhasil
    • SSH ke VM juga berjalan normal

    Dari sini saya bisa menyimpulkan bahwa hasil clone tidak mengalami kerusakan dan siap digunakan.

    Insight dari Pengujian

    Dari pengalaman ini, saya memahami bahwa penggunaan Ceph benar-benar mengubah cara kerja migration.

    Pada storage lokal:

    • Disk harus ikut dipindahkan
    • Proses lebih lama
    • Berpotensi downtime

    Pada Ceph:

    • Disk tetap di tempat
    • Hanya memory yang dipindahkan
    • Hampir tidak ada downtime

    Ini menjelaskan mengapa Ceph sering digunakan di lingkungan production.

    Kendala yang Ditemui

    Selama pengujian, ada beberapa masalah yang sempat muncul:

    • Storage Ceph tidak muncul di GUI
      Ternyata saya belum menambahkan RBD ke Proxmox
    • Clone gagal
      Biasanya karena pool belum benar atau konfigurasi Ceph belum lengkap
    • Migration gagal
      Terjadi jika disk masih berada di storage lokal

    Semua masalah ini pada akhirnya berkaitan dengan satu hal: memastikan storage benar-benar shared.

    Kesimpulan

    Dari pengalaman saya, clone VM ke Ceph melalui GUI adalah metode yang sangat efektif dan aman. Prosesnya cukup sederhana, tetapi dampaknya besar karena memungkinkan penggunaan fitur lanjutan seperti live migration.

    Beberapa poin penting yang saya pelajari:

    • Selalu gunakan clone untuk percobaan awal
    • Pastikan memilih target storage yang benar
    • Gunakan Full Clone agar disk benar-benar berada di Ceph
    • Verifikasi hasil menggunakan CLI
    • Uji migration untuk memastikan semuanya berjalan sesuai harapan

    Penutup

    Langkah ini menjadi fondasi penting dalam memahami arsitektur Proxmox dengan Ceph. Setelah berhasil di tahap ini, saya merasa lebih siap untuk melanjutkan ke tahap berikutnya seperti High Availability dan desain infrastruktur yang lebih kompleks.

    Pengalaman ini juga menunjukkan bahwa memahami konsep di balik sistem jauh lebih penting daripada sekadar menjalankan perintah.

  • Belajar Nextcloud: Pengertian, Fitur, dan Kelebihan

    Belajar Nextcloud: Pengertian, Fitur, dan Kelebihan

    Belakangan ini saya mulai belajar tentang sistem cloud yang bisa di-host sendiri, dan salah satu yang paling sering muncul adalah Nextcloud. Awalnya saya kira ini cuma seperti Google Drive versi open-source, tapi ternyata setelah dipelajari lebih dalam, fiturnya jauh lebih luas dari sekadar file storage.

    Di tulisan ini saya ingin merangkum pemahaman saya tentang Nextcloud, mulai dari pengertian, service yang tersedia, kelebihan, sampai manfaatnya.

    Apa Itu Nextcloud?

    Dari yang saya pelajari, Nextcloud adalah platform open-source yang digunakan untuk membuat layanan cloud pribadi. Artinya, kita bisa punya sistem seperti Google Drive, tapi berjalan di server kita sendiri.

    Jadi konsepnya bukan lagi “nitip data ke orang lain”, tapi kita yang pegang kendali penuh:

    • file disimpan di server sendiri
    • akses diatur sendiri
    • keamanan ditentukan sendiri

    Ini yang menurut saya jadi nilai utama dari Nextcloud, terutama kalau dipakai untuk kebutuhan internal.

    Nextcloud Bukan Cuma Storage

    Awalnya saya pikir Nextcloud cuma untuk upload dan download file. Tapi ternyata, setelah saya lihat fiturnya, Nextcloud itu lebih ke platform kolaborasi lengkap.

    Beberapa service yang saya temui:

    1. File Storage & Sharing

    Ini fitur dasar. Kita bisa upload file, bikin folder, lalu share ke user lain atau generate link publik. Permission juga bisa diatur (read, write, dll).

    2. Sinkronisasi Antar Device

    Nextcloud punya client desktop dan mobile. Jadi file bisa otomatis sinkron antara server dan device kita. Mirip seperti Dropbox, tapi versi self-hosted.

    3. Online Office (OnlyOffice / Collabora)

    Ini yang menurut saya menarik. File seperti Word, Excel, dan PowerPoint bisa dibuka dan diedit langsung dari browser, tanpa download.

    4. Calendar & Contacts

    Nextcloud juga bisa dipakai untuk manajemen kalender dan kontak. Bisa disinkron ke device juga, jadi cukup praktis.

    5. Nextcloud Talk

    Ada fitur chat, voice, dan video call. Jadi bisa dipakai untuk komunikasi internal tanpa perlu aplikasi tambahan seperti Zoom atau Teams.

    6. Task & Notes

    Ada juga fitur untuk mencatat dan mengelola tugas. Cocok untuk kebutuhan kerja atau sekadar manajemen pribadi.

    7. App Tambahan

    Nextcloud punya banyak plugin/app tambahan. Dari sini saya mulai sadar kalau Nextcloud itu fleksibel banget. Tinggal install sesuai kebutuhan.

    Kelebihan Nextcloud

    Setelah mulai memahami konsepnya, ada beberapa hal yang menurut saya jadi keunggulan Nextcloud:

    1. Full Control

    Semua ada di tangan kita. Mulai dari data, user, sampai konfigurasi server.

    2. Lebih Privat

    Karena tidak bergantung ke layanan cloud publik, data tidak “keluar” ke pihak ketiga.

    3. Open Source

    Ini penting banget buat saya yang lagi belajar. Kita bisa lihat cara kerjanya, eksplorasi, bahkan modifikasi kalau mau.

    4. Fleksibel Deployment

    Bisa dipasang di:

    • VPS
    • server lokal (on-premise)
    • Proxmox VM
    • bahkan untuk lab/testing

    5. Bisa Dikembangkan

    Awalnya mungkin cuma file storage, tapi bisa berkembang jadi:

    • sistem kolaborasi
    • internal cloud perusahaan
    • bahkan alternatif Google Workspace sederhana

    Manfaat Nextcloud

    Dari yang saya pahami, Nextcloud ini bisa dipakai di berbagai skenario:

    Untuk Pribadi

    • backup file penting
    • sync data antar device
    • simpan foto/video

    Untuk Tim Kecil

    • sharing file internal
    • kolaborasi dokumen
    • komunikasi sederhana

    Untuk Perusahaan / Instansi

    • sistem penyimpanan terpusat
    • kontrol akses user
    • keamanan data lebih terjaga

    Hal yang Perlu Dipertimbangkan

    Karena saya juga masih belajar, ada beberapa hal yang saya rasa perlu diperhatikan:

    • butuh resource server yang cukup
    • perlu maintenance (update, backup, monitoring)
    • setup awal tidak selalu “plug and play”
    • kalau user banyak, harus mulai mikir optimasi

    Jadi walaupun powerful, tetap ada effort dari sisi pengelolaan.

    Kenapa Harus Nextcloud?

    Jujur, karena Nextcloud ini menyentuh banyak hal dalam dunia IT:

    • server management
    • networking
    • storage
    • security
    • bahkan sedikit DevOps

    Jadi bukan cuma install aplikasi, tapi benar-benar belajar bagaimana membangun sebuah service.

    Akhir Kata Rafi

    Dari yang saya pelajari sejauh ini, Nextcloud bukan sekadar cloud storage, tapi sebuah platform yang bisa berkembang jadi sistem kolaborasi lengkap.

    Kalau kamu lagi belajar server, self-hosting, atau ingin punya kontrol penuh atas data, Nextcloud menurut saya sangat worth untuk dipelajari.

    Dan yang paling menarik, kita bisa mulai dari kecil, lalu berkembang sesuai kebutuhan.

  • Cara Download ISO via Proxmox Web UI (dengan Verifikasi Checksum)

    Cara Download ISO via Proxmox Web UI (dengan Verifikasi Checksum)

    Di percobaan kali ini, saya ingin mencoba download ISO langsung dari Proxmox Web UI ke storage NFS, sekaligus mencoba fitur verifikasi checksum langsung dari UI tanpa perlu masuk shell atau CLI.

    Biasanya workflow lama itu:

    • ssh ke server → wget → attach ke nfs, atau
    • download di laptop → upload ke Proxmox → baru dipakai.

    Masalahnya:

    • makan waktu (double transfer)
    • ribet kalau file besar
    • dan yang paling sering dilupakan: tidak diverifikasi integritas file-nya

    Di sini saya setup:

    • Proxmox di 192.168.14.22
    • Storage NFS dengan ID: nfs-iso
    • Cluster: rafi2

    Yang menarik, Proxmox ternyata sudah menyediakan fitur verifikasi checksum langsung saat download (di bagian Advanced), jadi bisa pastikan ISO yang didapat benar-benar valid tanpa perlu command line lagi.

    Source ISO & Checksum

    Gunakan file resmi berikut:

    • File ISO Debian 12:
    https://cdimage.debian.org/cdimage/archive/12.0.0/amd64/iso-cd/debian-12.0.0-amd64-netinst.iso
    • SHA256 Checksum:
    https://cdimage.debian.org/cdimage/archive/12.0.0/amd64/iso-cd/SHA256SUMS

    Kenapa Ini Lebih Mudah?

    Dengan kombinasi:

    • Download langsung dari server
    • Storage NFS
    • Verifikasi checksum di UI

    Kita dapat:

    • Lebih cepat
    • Lebih aman (tidak pakai ISO corrupt)
    • Lebih clean (tanpa CLI tambahan)

    Langkah-Langkah

    1. Masuk ke Storage NFS

    Di Proxmox Web UI:

    • Masuk ke node salah satu cluster
    • Pilih storage nfs-iso
    • Masuk ke tab ISO Images
    • Klik Download from URL

    Di sini akan terlihat tombol:

    2. Input URL ISO

    Klik Download from URL, lalu akan muncul pop-up.

    Isi:

    • URL:
    https://cdimage.debian.org/cdimage/archive/12.0.0/amd64/iso-cd/debian-12.0.0-amd64-netinst.iso

    3. Gunakan Fitur “Query URL”

    Klik tombol Query URL, maka Proxmox akan mengambil metadata file.

    Akan muncul:

    • File Name
    • File Size
    • MIME Type

    Ini berguna untuk memastikan:

    • Link valid
    • File benar ISO
    • Ukuran sesuai ekspektasi

    4. Aktifkan Advanced (Checksum di UI)

    Centang opsi:
    ➡️ Advanced

    Setelah dicentang, akan muncul:

    • Checksum
    • Hash Algorithm
    • Decompression Algorithm

    • Pilih
      • Hash Algorithm: SHA256
      • Decompression: biarkan default (karena file ISO tidak dikompres)

    5. Isi Checksum SHA256

    Ambil nilai checksum dari file:

    SHA256SUMS

    Lalu:

    • Paste checksum untuk file:
    debian-12.0.0-amd64-netinst.iso

    Proxmox akan otomatis memverifikasi file setelah download selesai.

    6. Download ISO

    Klik Download

    Akan muncul:

    Di sini kita bisa lihat:

    • Progress download
    • Status verifikasi checksum

    7. Hasil Akhir

    Kalau semua sukses:

    • Task status: OK
    • File .iso muncul di:
    nfs-iso → ISO Images

    Dan yang paling penting:
    ✔️ ISO sudah terverifikasi (tidak corrupt)

    Penjelasan Singkat SHA256

    SHA256 adalah algoritma hash yang menghasilkan “sidik jari digital” dari sebuah file.

    Artinya:

    • File asli → hash tertentu
    • File berubah sedikit saja → hash berubah total

    Dengan fitur ini di Proxmox:

    • Kita tidak perlu manual sha256sum
    • Tidak perlu SSH
    • Semua langsung di UI

    Insight dari Percobaan Ini

    Jujur, fitur Advanced + Checksum di Proxmox ini underrated banget.

    Karena biasanya orang:

    • download ISO
    • langsung pakai

    Padahal idealnya:

    Download + Verify = Standard Practice

    Dengan cara ini:

    • Lebih aman dari ISO corrupt
    • Lebih cepat troubleshooting (kalau gagal)
    • Lebih cocok untuk environment production

    Akhir Kata Rafi

    Workflow terbaik versi saya untuk download dan import ISO:

    1. Download ISO via Proxmox
    2. Simpan di NFS
    3. Aktifkan checksum verification di UI
    4. Pakai ISO yang sudah pasti valid

    Simple, cepat, dan tetap profesional.

  • Memahami Swap Usage di Linux

    Memahami Swap Usage di Linux

    Setiap kali saya login ke server, selalu muncul informasi seperti system load, CPU usage, memory usage, sampai swap usage. Awalnya saya hanya melihat sekilas tanpa terlalu memperhatikan, tapi lama-lama jadi penasaran, terutama di bagian swap usage yang angkanya kadang terlihat cukup besar dibanding yang lain.

    Kalau system load atau memory usage masih cukup mudah dipahami, swap ini terasa agak “abu-abu”. Kadang nilainya tinggi, tapi server tetap terasa normal, tidak ada tanda-tanda lambat atau error. Dari situ mulai muncul pertanyaan, sebenarnya swap ini apa, kenapa bisa terpakai, dan apakah itu sesuatu yang harus dikhawatirkan atau tidak.

    Karena penasaran, saya akhirnya coba cari tahu lebih dalam, bukan hanya dari sisi definisi, tapi juga bagaimana cara kerjanya di sistem Linux. Di sini saya jelaskan dari konsep sampai teknis, pakai sudut pandang real case supaya lebih mudah dipahami dan tidak terasa terlalu teoritis.

    Apa Itu Swap?

    Swap adalah bagian dari storage (disk) yang dipakai sebagai “memori cadangan” ketika RAM mulai penuh. Di sistem seperti Ubuntu, swap bisa berupa file atau partisi.

    Secara sederhana:

    • RAM = cepat
    • Swap = lambat (karena di disk)

    Ketika RAM tidak cukup, sistem akan memindahkan sebagian data dari RAM ke swap supaya sistem tetap jalan.

    Cara Kerja Swap (Technically)

    Linux menggunakan konsep virtual memory. Artinya, setiap proses tidak benar-benar tahu apakah datanya ada di RAM atau di swap.

    Ketika RAM mulai penuh:

    1. Kernel akan mencari data yang jarang dipakai
    2. Data tersebut dipindahkan ke swap
    3. RAM jadi kosong untuk proses yang aktif

    Kalau data yang sudah dipindahkan itu dibutuhkan lagi:

    1. Sistem akan ambil dari swap
    2. Dimasukkan kembali ke RAM

    Masalahnya, proses ini jauh lebih lambat dibanding akses RAM, karena disk I/O jauh lebih lambat dari memory access.

    Mengapa Swap bisa terpakai padahal RAM banyak?

    Ini salah satu hal yang paling sering membingungkan. Secara logika, kalau RAM masih banyak, seharusnya swap tidak digunakan. Tapi kenyataannya tidak begitu.

    Misalnya:

    • RAM sempat penuh sebelumnya
    • Sistem memindahkan data ke swap

    Setelah itu:

    • RAM sudah lega lagi
    • Tapi data di swap tidak langsung dipindahkan balik

    Jadi kondisi seperti ini bisa terjadi:

    • RAM masih banyak tersedia
    • Tapi swap usage tetap tinggi

    Ini normal behavior di Linux, bukan bug.

    Apa harus khawatir saat Swap tinggi?

    Swap usage sering disalahartikan sebagai indikator bahwa server sedang dalam kondisi buruk. Padahal tidak selalu seperti itu. Nilai swap yang tinggi tidak otomatis berarti sistem bermasalah.

    Kondisi normal

    • Swap terpakai sedikit
    • Sistem tetap responsif

    Kondisi tidak normal

    • Swap tinggi
    • Server terasa lambat
    • Banyak delay saat akses aplikasi

    Biasanya ini terjadi kalau:

    • RAM memang kurang
    • Aplikasi terlalu berat
    • Atau konfigurasi tidak optimal

    Jadi swap usage lebih tepat dilihat sebagai indikator tambahan, bukan satu-satunya acuan.

    Swappiness: Seberapa Agresif Swap Digunakan

    Linux punya parameter bernama swappiness. Ini menentukan seberapa cepat sistem mulai menggunakan swap.

    Cek nilai:

    # cat /proc/sys/vm/swappiness

    Nilai default biasanya:

    Interpretasi:

    • Nilai tinggi → swap lebih sering dipakai
    • Nilai rendah → lebih mengutamakan RAM

    Untuk VPS kecil, biasanya lebih aman pakai:

    vm.swappiness=10

    Tujuannya supaya sistem tidak terlalu cepat “buang data” ke swap.

    Ubah dengan command:

    # sysctl vm.swappiness=10

    Melihat Penggunaan Swap

    Ketikkan di CLI:

    # free -h

    Output:

    Artinya:

    • Total swap: 255MB
    • Terpakai: 200MB
    • Padahal penggunaan RAM 437 MB dan available ~523 MB

    Reset Swap

    Kalau swap sudah tinggi tapi RAM sebenarnya masih lega, kamu bisa reset swap:

    # swapoff -a && swapon -a

    Apa yang terjadi:

    • Semua data di swap dipindahkan kembali ke RAM
    • Swap jadi kosong

    Catatan:
    Pastikan RAM cukup sebelum menjalankan ini.

    Jenis Swap: File vs Partisi

    1. Swap Partition

    • Dibuat saat install OS
    • Lebih stabil
    • Lebih jarang dipakai di VPS modern

    2. Swap File

    • Dibuat manual
    • Fleksibel (bisa resize)
    • Paling umum di VPS

    Contoh membuat swap file:

    fallocate -l 512M /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

    Kapan Swap Dibutuhkan

    Swap tetap penting, terutama di VPS kecil:

    • Mencegah sistem crash saat RAM habis
    • Memberi “buffer” untuk lonjakan beban
    • Menghindari OOM (Out Of Memory Killer)

    Tanpa swap, kalau RAM habis:

    • proses bisa langsung dimatikan paksa

    Akhir Kata Rafi

    Swap bukan musuh, tapi juga bukan sesuatu yang bisa diabaikan.

    • Swap adalah backup saat RAM tidak cukup
    • Swap lambat karena berbasis disk
    • Swap usage tinggi tidak selalu berarti masalah
    • Tapi kalau disertai lag, itu tanda harus optimasi

    Untuk VPS kecil:

    • gunakan swap secukupnya
    • turunkan swappiness
    • dan pastikan konfigurasi service efisien

    Kalau dipahami dengan benar, swap justru membantu menjaga sistem tetap stabil, bukan sebaliknya.

  • Pre-Setup Rocky Linux 8 via Cloud-Init di Proxmox

    Pre-Setup Rocky Linux 8 via Cloud-Init di Proxmox

    Hari ini saya ingin mencoba sesuatu yang menurut saya cukup menarik di Proxmox, yaitu membuat VM yang sudah langsung siap pakai tanpa perlu setup manual di dalamnya. Target saya sederhana: deploy Rocky Linux 8 yang sudah punya user, password, dan IP sejak pertama kali boot. Ini masih tahap saya belajar dan ingin uji coba, jadi saya catat semua prosesnya sebagai referensi pribadi sekaligus bahan belajar.

    Dari yang saya pahami, Cloud-Init memungkinkan kita melakukan konfigurasi awal VM langsung dari sisi Proxmox. Jadi bukan lagi install OS lalu konfigurasi manual, tapi kita “siapkan semuanya dari luar” sebelum VM dinyalakan. Ini yang ingin saya buktikan apakah benar-benar mempermudah workflow.

    STEP 1 — Download Image Rocky Linux

    Langkah pertama yang saya lakukan adalah mengambil image Rocky Linux yang memang sudah mendukung Cloud-Init. Saya download langsung dari node Proxmox agar lebih cepat dan tidak perlu upload manual lewat web.

    wget https://download.rockylinux.org/pub/rocky/8/images/x86_64/Rocky-8-GenericCloud.latest.x86_64.qcow2

    Output yang muncul menunjukkan proses download hingga selesai dengan ukuran sekitar 1GB lebih. Image ini berbeda dengan ISO biasa karena sudah disiapkan khusus untuk Cloud-Init, jadi tidak perlu proses instalasi OS lagi.

    STEP 2 — Membuat VM Kosong

    Setelah image siap, saya membuat VM baru tanpa menggunakan ISO. Tujuannya karena disk utama nanti akan diisi dari hasil import image Rocky tadi, bukan dari installer.

    • Masuk Web UI Proxmox
    • Create VM dengan spesifikasi
      • OS: Do not use any media
      • Disk Size: 10 GB
      • CPU: 2 Cores
      • Memory: 2GB

    Di tahap ini VM sebenarnya belum bisa dipakai karena belum memiliki disk OS. Tapi ini jadi fondasi awal sebelum disk dimasukkan.

    STEP 3 — Import Disk ke Storage

    Selanjutnya saya import image ke storage Proxmox yang saya gunakan, yaitu nfs-vm. Proses ini akan mengubah file .qcow2 menjadi format yang sesuai dengan storage.

    qm importdisk 200 Rocky-8-GenericCloud.latest.x86_64.qcow2 nfs-vm

    Output:

    




    




    Artinya disk sudah berhasil masuk, tapi masih status unused0. Ini penting dipahami karena disk belum otomatis terpasang ke VM.
    




    




    STEP 4 — Attach Disk ke VM
    




    Di sini saya mulai menghubungkan disk ke VM sebagai disk utama. Saya menggunakan controller virtio-scsi supaya performanya lebih optimal.
    




    qm set 200 --scsihw virtio-scsi-pci --scsi0 nfs-vm:200/vm-200-disk-0.raw
    




    




    




    Setelah ini, disk sudah berubah dari unused0 menjadi scsi0. Artinya sekarang VM sudah punya disk OS dan siap untuk boot.
    




    Hal penting yang saya perhatikan di step ini:
    




      

    • Disk harus hanya satu (jangan double .raw dan .qcow2)
      • 




    • Disk utama harus di scsi0
      • 




    • Format NFS harus storage:VMID/file
      • 

    




    




    STEP 5 — Menambahkan Cloud-Init Drive
    




    Langkah ini cukup krusial karena tanpa Cloud-Init drive, semua konfigurasi tidak akan terbaca oleh VM saat boot.
    




    




    




    Via CLI
    




    qm set 200 --ide2 nfs-vm:cloudinit
    




    Output:
    




    




    




    Setelah ditambahkan, Proxmox akan punya media khusus untuk menyimpan konfigurasi Cloud-Init. Ini yang nantinya dibaca oleh Rocky Linux saat pertama kali dijalankan.
    




    




    




    




    STEP 6 — Pre-Setup Konfigurasi VM
    




    Di tahap ini saya mulai melakukan konfigurasi awal sesuai tujuan saya. 
    




    




    




    Di bagian ini, Proxmox sebenarnya sedang membuat file konfigurasi Cloud-Init yang berisi:
    




      

    • user baru
      • 




    • password
      • 




    • konfigurasi network
      • 

    




    Yang saya set di sini:
    




      

    • user: rafi
      • 




    • password: ******
      • 




    • IP: statis
      • 

    




    




    STEP 7 — Mengatur Boot dan Console
    




    Sebelum VM dijalankan, saya memastikan boot sudah mengarah ke disk utama dan console aktif untuk troubleshooting jika diperlukan.
    




    qm set 200 --boot c --bootdisk scsi0
    qm set 200 --serial0 socket --vga serial0
    




    Step ini penting walaupun terlihat sederhana, karena salah boot order bisa bikin VM tidak jalan dengan benar.
    




    




    STEP 8 — Menjalankan VM
    




    Setelah semua konfigurasi selesai, jalankan VM untuk melihat apakah semua yang saya setup benar-benar bekerja.
    




    




    




    Di tahap ini terlihat bahwa konfigurasi langsung diterapkan dan benar-benar jalan via Cloud-Init.
    




      

    • user sudah otomatis dibuat
      • 




    • password bisa dipakai login
      • 




    • IP langsung aktif
      • 




    • tidak perlu setup manual
      • 

    




    




    Catatan Penting dari Percobaan Ini
    




    Selama menyusun dan memahami step ini, ada beberapa hal yang menurut saya cukup penting:
    




      

    • Cloud-Init tidak akan jalan tanpa ide2 (step ke 5)
      • 




    • Disk harus benar-benar di scsi0
      • 




    • Error paling sering biasanya di attach disk atau format storage
      • 

    




    




    Akhir Kata Rafi…
    




    Dari yang saya pelajari, Cloud-Init ini sebenarnya sangat powerful untuk automation, tapi setup awalnya cukup sensitif. Salah satu step saja bisa bikin semuanya tidak jalan, jadi harus benar-benar teliti di awal.
    




    Kalau ini berhasil, saya merasa ini bisa sangat membantu untuk:
    




      

    • bikin template VM
      • 




    • deploy banyak VM sekaligus
      • 




    • automation environment
      •