Category: Linux

  • Cara Membuat Repository Lokal Sederhana di Rocky Linux

    Cara Membuat Repository Lokal Sederhana di Rocky Linux

    Saya sedang menyiapkan skenario lab CloudStack lokal tanpa internet. Langkah awalnya adalah membuat Rocky Linux bisa memasang paket dari penyimpanan lokal. Contoh paling sederhana adalah menggunakan DVD ISO Rocky Linux 9 sebagai sumber paket. Pastikan ISO sesuai dengan versi dan arsitektur server. Gunakan DVD ISO, bukan minimal atau boot ISO.

    Di contoh ini, file ISO sudah tersedia di /root/Rocky-9-dvd.iso. Sesuaikan nama file dengan ISO yang dimiliki, dan sediakan ruang disk yang cukup untuk menyalin isinya. Langkah ini membuat repo untuk server tersebut, belum membagikannya ke server lain.

    1. Salin isi repository dari ISO

    # sudo mkdir -p /mnt/rocky-dvd /srv/repo/rocky
    # sudo mount -o loop /root/Rocky-9-dvd.iso /mnt/rocky-dvd
    # ls /mnt/rocky-dvd/{BaseOS,AppStream}/repodata/repomd.xml
    # sudo cp -a /mnt/rocky-dvd/BaseOS /mnt/rocky-dvd/AppStream /srv/repo/rocky/
    # sudo umount /mnt/rocky-dvd

    Folder BaseOS dan AppStream berisi paket serta metadata yang sudah bisa dibaca DNF. Karena itu, untuk contoh ini saya tidak perlu menjalankan createrepo lagi.

    2. Daftarkan repository lokal

    Pastikan kunci GPG Rocky Linux tersedia dengan ls /etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9, lalu buat file /etc/yum.repos.d/rocky-local.repo:

    [local-baseos]
    name=Rocky Linux 9 - BaseOS Lokal
    baseurl=file:///srv/repo/rocky/BaseOS
    enabled=1
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9
    
    [local-appstream]
    name=Rocky Linux 9 - AppStream Lokal
    baseurl=file:///srv/repo/rocky/AppStream
    enabled=1
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9

    DNF membaca konfigurasi repository dari file .repo di /etc/yum.repos.d/. Red Hat Documentation

    3. Uji tanpa repository internet

    # dnf --disablerepo='*' --enablerepo=local-baseos --enablerepo=local-appstream --refresh makecache
    # dnf --disablerepo='*' --enablerepo=local-baseos --enablerepo=local-appstream install vim-enhanced

    Jika metadata terbaca dan vim-enhanced terpasang, repo lokal Rocky Linux sudah berfungsi. Bila paket itu sudah terpasang sebelumnya, gunakan paket lain yang tersedia di ISO untuk menguji instalasi. Opsi --disablerepo='*' membuat kedua perintah hanya memakai repo lokal; repo internet bawaan tetap aktif untuk perintah DNF biasa sampai dinonaktifkan.

    Kalo Ada Update?

    Repository dari DVD ISO tidak diperbarui otomatis. Paket yang tersedia mengikuti isi ISO saat dibuat.

    Jika ada DVD ISO Rocky Linux 9 yang lebih baru, salin kembali folder BaseOS dan AppStream ke direktori baru, misalnya /srv/repo/rocky-baru. Setelah itu, ubah kedua baseurl di rocky-local.repo agar mengarah ke direktori baru. Jangan mencampur isi repo lama dan baru supaya paket tetap sesuai dengan metadatanya.

    Jalankan pembaruan hanya dari repo lokal:

    # dnf --disablerepo='*' --enablerepo=local-baseos \
      --enablerepo=local-appstream --refresh upgrade

    Jika membutuhkan patch yang terbit sebelum ada ISO baru, sinkronkan paket beserta metadata di mesin yang memiliki internet menggunakan dnf reposync --download-metadata, lalu pindahkan hasilnya ke server offline.

    Referensi

  • Mengatasi Mismatch Versi DRBD di LINSTOR

    Mengatasi Mismatch Versi DRBD di LINSTOR

    Beberapa waktu terakhir saya sedang mendalami implementasi storage terdistribusi menggunakan LINSTOR di cluster Proxmox VE. Tujuannya sederhana: membuat storage yang bisa direplikasi antar node (HA) sehingga VM tetap aman walaupun salah satu node mati. Semua setup awal terlihat normal—node sudah terdaftar, storage pool sudah dibuat, dan integrasi ke Proxmox juga sudah masuk.

    Namun saat mencoba clone VM ke storage LINSTOR, muncul error autoplace yang cukup membingungkan. Setelah ditelusuri, ternyata akar masalahnya bukan di konfigurasi storage pool atau resource group, melainkan di layer yang lebih dalam: versi DRBD yang tidak selaras antara kernel dan userspace. Di sinilah perjalanan troubleshooting dimulai.


    Mengenal DRBD dan LINSTOR

    Sebelum masuk ke teknis, kita pahami dulu perannya:

    • DRBD adalah teknologi replikasi block storage (mirip RAID 1 tapi via network).
    • LINSTOR adalah orchestrator yang mengatur DRBD secara otomatis di banyak node.

    Secara sederhana:

    • DRBD = mesin replikasi
    • LINSTOR = otaknya

    LINSTOR tidak menyimpan data sendiri, tapi memanfaatkan DRBD untuk membuat disk yang direplikasi antar node.


    Masalah yang Terjadi

    Saat melakukan pengecekan:

    linstor node info

    Hasilnya:

    Padahal:

    • drbdadm ada
    • modprobe drbd berhasil
    • service linstor jalan normal

    Pas dicek lebih dalam:

    cat /proc/drbd

    Output:

    version: 8.4.11 ()

    Sementara:

    dkms status

    Output:

    drbd/9.3.2-1, 7.0.0-3-pve, x86_64: installed ()

    Intinya

    Terjadi mismatch versi DRBD:

    KomponenVersi
    Kernel moduleDRBD 8 ❌
    UserspaceDRBD 9 ✔️

    Masalahnya:

    • LINSTOR hanya support DRBD 9
    • DRBD 8 dianggap tidak ada

    Kenapa Bisa Terjadi?

    Kernel Proxmox secara default masih membawa DRBD 8. Saat menjalankan:

    modprobe drbd

    Yang ter-load bukan DRBD 9 dari DKMS, tapi DRBD 8 bawaan kernel

    Akibatnya:

    • DRBD terlihat “aktif”
    • tapi tidak usable oleh LINSTOR

    Solusi: Selaraskan Versi DRBD

    Berikut langkah yang saya lakukan untuk memperbaiki mismatch ini.


    1. Blacklist DRBD lama (bawaan kernel)

    echo "blacklist drbd" > /etc/modprobe.d/blacklist-drbd.conf

    2. Update initramfs

    update-initramfs -u

    3. Reboot semua node

    reboot

    Lakukan di semua node cluster


    4. Load ulang DRBD

    modprobe drbd

    5. Verifikasi versi DRBD

    cat /proc/drbd

    Hasil yang benar:


    6. Restart LINSTOR

    systemctl restart linstor-satellite
    systemctl restart linstor-controller

    7. Cek ulang LINSTOR

    linstor node info

    Hasil:


    Hasil Akhir

    Setelah versi DRBD selaras:

    • Clone VM berhasil
    • Resource bisa autoplace ke semua node
    • Replikasi berjalan normal

    Error sebelumnya hilang

    does not support the following layers: [DRBD]

    Insight Penting (Pelajaran yang Didapat)

    Beberapa hal penting yang saya pelajari dari kasus ini:

    • DRBD harus versi yang sama untuk LINSTOR
    • modprobe drbd tidak menjamin versi yang digunakan benar
    • Selalu cek versi dari drbd di /proc/drbd
    • Kernel module bisa override DKMS jika tidak di-blacklist
    • LINSTOR sangat bergantung pada layer DRBD yang valid

    Kesimpulan

    Masalah yang terlihat seperti error konfigurasi LINSTOR ternyata berasal dari layer paling bawah: kernel module DRBD. Ini menunjukkan bahwa dalam implementasi storage terdistribusi, setiap layer harus selaras—mulai dari kernel, userspace, hingga orchestration.

    Dengan memastikan DRBD versi 9 aktif di semua node, LINSTOR dapat bekerja optimal dan seluruh fitur seperti replication, HA, dan cloning bisa berjalan dengan lancar.

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

  • 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
  • Tips SSH Tanpa Password dari Windows ke Server

    Tips SSH Tanpa Password dari Windows ke Server

    Awalnya saya sering SSH ke beberapa server dan harus ketik password terus. Kelihatannya sepele, tapi kalau dilakukan berkali-kali itu cukup mengganggu—apalagi kalau lagi troubleshooting cepat.

    Akhirnya saya coba setup SSH tanpa password (key-based authentication) langsung dari Windows. Tujuannya simpel: sekali setup, setelah itu tinggal login tanpa input password lagi.

    Selain itu, tidak perlu install aplikasi tambahan karena Windows sekarang sudah punya SSH bawaan.


    Teori Sedikit untuk SSH Tanpa Password

    Secara sederhana, SSH tanpa password menggunakan:

    • Private key (di laptop kita)
    • Public key (disimpan di server)

    Saat login:

    • Server akan mencocokkan key
    • Kalau cocok → langsung masuk tanpa password

    Lebih cepat dan sebenarnya lebih aman dibanding password (kalau dikelola dengan benar).


    Contoh

    Saya punya 3 server contoh di lokal:

    • 192.168.14.21
    • 192.168.14.22
    • 192.168.14.23

    Semua pakai:

    • User: root
    • Port: 22

    Target:
    SSH ke ketiga server tanpa password


    Step 1 — Generate SSH Key di Windows

    Buka CMD atau PowerShell:

    ssh-keygen

    Tekan Enter terus (default saja).

    Output:

    👉 Artinya:

    • id_rsa = private key (JANGAN dibagikan)
    • id_rsa.pub = public key (boleh dikirim ke server)

    Step 2 — Kirim Public Key ke Server

    Seharusnya bisa menggunakan ssh-copy-id jika sesama linux, namun tidak tersedia di Windows, maka dari itu alternatif nya:

    type $env:USERPROFILE\.ssh\id_rsa.pub | ssh root@192.168.14.21 "cat >> ~/.ssh/authorized_keys"

    Output:

    Tidak ada output error

    Artinya key berhasil ditambahkan.


    Step 3 — Coba SSH Tanpa Password

    Sekarang tes:

    ssh root@192.168.14.21

    Output:

    
    
    
    
    
    
    
    
    

    Tidak diminta password lagi 🎉

    Dan coba juga untuk server lain

    ssh root@192.168.14.22
    ssh root@192.168.14.23

    Penjelasan Singkat

    • Server menyimpan key di:
    ~/.ssh/authorized_keys
    • Saat login:
      • SSH kirim identitas dari private key
      • Server cek ke authorized_keys
      • Jika cocok → langsung login

    Manfaatnya

    Dari pengalaman saya:

    1. Lebih cepat

    2. Lebih praktis

    3. Tidak perlu aplikasi tambahan


    ⚠️ Catatan

    Meskipun enak, setup ini tidak selalu direkomendasikan.

    Karena kalau:

    • Laptop hilang
    • Laptop dicuri

    Maka orang lain dapat:

    • Akses SSH ke semua server kalian
    • Tanpa password

    🔐 Tips Keamanan

    Kalau tetap mau pakai, minimal lakukan ini:

    1. Gunakan passphrase saat generate key

    ssh-keygen

    Walaupun jadi seperti pakai password, passphrase tidak perlu sekompleks password


    2. Batasi akses root (opsional)

    Edit:

    /etc/ssh/sshd_config
    PermitRootLogin prohibit-password

    3. Backup & proteksi laptop

    • Pakai password / fingerprint
    • Encrypt disk (BitLocker)

    Kesimpulan

    Dari pengalaman saya:

    • SSH tanpa password itu super praktis
    • Sangat membantu saat manage banyak server
    • Tidak perlu aplikasi tambahan di Windows

    Tapi… Harus dipakai dengan bijak karena ada risiko keamanan kalau device kita tidak aman.

  • Instalasi dan Konfigurasi Qemu Guest Agent di VM Alpine

    Instalasi dan Konfigurasi Qemu Guest Agent di VM Alpine

    Hari ini saya ingin mencoba belajar dan praktik Qemu Guest Agent di VM Alpine yang saya jalankan di Proxmox. Sebenarnya ini masih tahap percobaan, jadi saya ingin mencatat semua langkah, kendala yang mungkin muncul, dan penjelasannya, supaya bisa jadi catatan pribadi sekaligus berbagi pengetahuan bagi pembaca.

    Dari teori yang saya baca, Qemu Guest Agent itu semacam “jembatan” antara VM dengan host Proxmox. Fungsinya untuk membuat Proxmox bisa membaca status VM lebih lengkap, shutdown VM lebih rapi, dan bahkan membaca IP guest langsung dari host. Saya penasaran seberapa berguna ini untuk VM Alpine yang ringan dan minimalis.


    Apa itu Qemu Guest Agent?

    Secara singkat, ini adalah service yang berjalan di dalam VM supaya Proxmox bisa “ngobrol” langsung dengan sistem operasi di dalam VM. Beberapa hal yang biasanya bisa dilakukan dengan agent ini:

    • Menampilkan IP VM langsung di Proxmox
    • Shutdown VM lebih rapi tanpa paksa
    • Mendukung snapshot konsisten
    • Memperbaiki integrasi monitoring

    Kalau saya analogikan, agent ini seperti “penerjemah” antara host dan guest VM. Tanpa agent, Proxmox hanya tahu VM jalan atau mati, tapi tidak tahu kondisi di dalamnya.


    Percobaan di Alpine Linux

    Alpine itu ringan, namun karena minimalis, banyak service standar tidak aktif. Jadi saya ingin lihat apakah dengan memasang Qemu Guest Agent, integrasinya bisa lebih rapi. Tujuan saya:

    • Belajar instalasi dan konfigurasi agent
    • Mengetahui bagaimana host Proxmox membaca status Alpine
    • Mencatat langkah-langkahnya sebagai catatan pribadi dan referensi pembaca

    Langkah-langkah yang akan dicoba

    Sebelum praktik, saya siapkan beberapa hal:

    • VM Alpine sudah berjalan di Proxmox
    • Bisa login ke shell Alpine
    • Repository Alpine aktif
    • Mengetahui VM ID di Proxmox

    1. Update repository

    Langkah pertama yang ingin dicoba adalah update daftar package supaya terbaru:

    apk update

    2. Install Qemu Guest Agent

    Setelah itu, install package utama:

    apk add qemu-guest-agent

    Catatan: Ini package yang membuat VM bisa berkomunikasi dengan Proxmox. Nanti kita bisa lihat info IP guest, shutdown rapi, dan snapshot lebih stabil.


    3. Aktifkan agar service jalan otomatis

    Supaya agent jalan otomatis saat VM boot:

    rc-update add qemu-guest-agent

    Output:

    Catatan: Ini supaya tidak perlu start manual setiap kali VM di restart.


    4. Jalankan service sekarang

    service qemu-guest-agent start

    Output:

    Catatan: Service sedang berjalan


    5. Cek status service

    service qemu-guest-agent status

    Output:

    Catatan: Kalau sudah started, berarti agent aktif dan siap berkomunikasi dengan Proxmox.


    6. Aktivasi di Proxmox

    Selain di VM, agent juga perlu diaktifkan di sisi Proxmox:

    Lewat GUI

    • Masuk ke VM → Options → Qemu Guest Agent → Enable

    Lewat CLI

    qm set <VMID> --agent enabled=1

    Contoh:

    qm set 100 --agent enabled=1

    Output:

    Catatan: Ini memastikan Proxmox tahu kalau VM ini sudah punya guest agent.


    7. Verifikasi

    Setelah aktif, saya bisa cek di Proxmox:

    qm config 100

    Output:

    Catatan: Kalau ada agent: enabled=1, berarti Proxmox siap membaca data guest dari VM.

    Kalau dicek di Web Proxmox

    Catatan: Jika belum familiar dengan Alpine Linux, disarankan membaca dokumentasinya terlebih dahulu agar tidak seperti saya tergocek oleh Alpine Linux 😀