Debian Preseed dan Ubuntu Autoinstall: Panduan Lengkap Instalasi Otomatis Massal Server Linux

Bayangkan sebuah tim infrastruktur yang harus menyiapkan lima puluh server baru dalam satu malam untuk rollout data center. Jika setiap instalasi Linux dilakukan manual — mengklik “Next”, memilih zona waktu, mengetik partisi disk satu per satu — proses ini bukan hanya melelahkan, tapi juga rawan human error. Satu server dengan konfigurasi locale yang salah, satu lagi dengan skema partisi yang tidak konsisten, dan seluruh armada server menjadi sulit dikelola.

Di sinilah unattended installation — instalasi tanpa interaksi manual — menjadi kebutuhan wajib bagi sysadmin, DevOps engineer, dan tim infrastruktur modern. Dua mekanisme paling banyak dipakai untuk kebutuhan ini adalah Debian Preseed (untuk keluarga Debian) dan Ubuntu Autoinstall (berbasis installer Subiquity di Ubuntu Server). Keduanya memungkinkan sebuah file konfigurasi tunggal menjawab seluruh pertanyaan installer secara otomatis — mulai dari partisi disk, jaringan, akun pengguna, hingga paket yang diinstal — sehingga provisioning ratusan mesin bisa dilakukan secara identik dan berulang.

Artikel ini akan membahas tuntas cara kerja, struktur file konfigurasi, langkah praktis, kesalahan umum, dan best practice untuk kedua mekanisme tersebut, agar Anda bisa membangun pipeline provisioning server yang benar-benar hands-off.

Mengapa Instalasi Otomatis Itu Penting

Provisioning manual punya tiga masalah besar: lambat, tidak konsisten, dan sulit diaudit. Ketika sebuah organisasi mengelola puluhan hingga ribuan server (baik fisik maupun virtual), setiap detik yang dihabiskan mengklik installer adalah waktu yang bisa dipakai untuk pekerjaan lain yang lebih bernilai.

Dengan pendekatan infrastructure as code, file preseed atau autoinstall diperlakukan sebagai kode: disimpan di Git, di-review lewat pull request, dan diuji sebelum dipakai produksi. Hasilnya, setiap server yang lahir dari template yang sama akan punya konfigurasi dasar yang identik — locale sama, partisi sama, user default sama — sehingga proses debugging dan audit keamanan jauh lebih mudah.

Mengenal Debian Preseed

Preseed adalah mekanisme bawaan Debian Installer (d-i) yang memungkinkan seluruh pertanyaan debconf dijawab lebih dulu lewat sebuah file teks (biasanya preseed.cfg). Installer akan membaca file ini di awal proses boot, sehingga tidak perlu ada interaksi dari operator.

Preseed masih menjadi mekanisme resmi hingga rilis Debian 13 “Trixie” (rilis stabil saat ini), dan tetap didukung untuk instalasi berbasis Debian Installer klasik maupun netboot.

Format dasar file preseed menggunakan sintaks:

d-i package/question type value

Contoh potongan konfigurasi umum:

# Locale dan keyboard
d-i debian-installer/locale string en_US.UTF-8
d-i keyboard-configuration/xkb-keymap select us

# Jaringan
d-i netcfg/get_hostname string server01
d-i netcfg/get_domain string internal.local

# Partisi disk otomatis (guided, seluruh disk, LVM)
d-i partman-auto/method string lvm
d-i partman-auto/choose_recipe select atomic
d-i partman-lvm/confirm boolean true
d-i partman/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true

# User dan password (gunakan hash, jangan plaintext di produksi)
d-i passwd/root-login boolean false
d-i passwd/user-fullname string Admin Server
d-i passwd/username string admin
d-i passwd/user-password-crypted password $6$...hash...

# Zona waktu dan mirror
d-i clock-setup/utc boolean true
d-i time/zone string Asia/Jakarta
d-i mirror/country string manual
d-i mirror/http/hostname string deb.debian.org

# Paket tambahan
tasksel tasksel/first multiselect standard, ssh-server
d-i pkgsel/include string curl vim htop

# Selesai tanpa konfirmasi
d-i finish-install/reboot_in_progress note

File ini kemudian disuntikkan ke proses boot lewat beberapa cara: parameter boot auto url=http://server/preseed.cfg pada PXE/netboot, disematkan ke dalam image ISO kustom, atau diletakkan pada media USB sebagai preseed.cfg.

Mengenal Ubuntu Autoinstall

Sejak Ubuntu 20.04 LTS, installer server Ubuntu (Subiquity) meninggalkan mekanisme preseed lama dan beralih ke Autoinstall — format YAML yang lebih modern dan terstruktur, dan tetap menjadi mekanisme resmi hingga rilis terbaru Ubuntu 26.04 LTS. Konfigurasinya disebut autoinstall.yaml, dan idealnya dikirim bersama user-data cloud-init.

Struktur dasar autoinstall.yaml:

#cloud-config
autoinstall:
  version: 1
  locale: en_US.UTF-8
  keyboard:
    layout: us
  network:
    network:
      version: 2
      ethernets:
        eth0:
          dhcp4: true
  storage:
    layout:
      name: lvm
  identity:
    hostname: server01
    username: admin
    password: "$6$...hash..."
  ssh:
    install-server: true
    allow-pw: false
  packages:
    - curl
    - vim
    - htop
  late-commands:
    - curtin in-target --target=/target -- systemctl enable ssh

Beberapa poin penting dari struktur ini:

• version: 1 wajib ada sebagai penanda skema konfigurasi.
• identity mengatur user default; jika ingin delegasi penuh ke cloud-init, bagian ini bisa dikosongkan dan digantikan oleh user-data cloud-init terpisah.
• early-commands dijalankan sebelum instalasi dimulai (misalnya validasi jaringan), sedangkan late-commands dijalankan setelah sistem target selesai dipasang, tapi sebelum reboot.
• File ini bisa disajikan lewat HTTP (untuk PXE netboot), lewat drive data cloud-init (untuk cloud/VM), atau dibakar langsung ke ISO kustom via cloud-init.iso.

Analogi Sederhana

Bayangkan preseed dan autoinstall seperti formulir yang sudah diisi lengkap sebelum dikirim ke petugas loket. Alih-alih Anda antre dan menjawab satu per satu pertanyaan petugas (nama, alamat, keperluan), Anda cukup menyerahkan formulir yang sudah lengkap — petugas tinggal memprosesnya tanpa bertanya lagi. Semakin lengkap dan konsisten formulir tersebut diisi, semakin cepat dan seragam hasil akhirnya.

Materi Praktis: Studi Kasus Provisioning 20 Server Fisik

Misalkan tim infrastruktur perlu memasang Ubuntu Server 26.04 LTS pada 20 unit server fisik baru yang identik, menggunakan PXE boot dari jaringan internal.

1. Siapkan server PXE (TFTP + HTTP) yang menyajikan image installer Ubuntu Server dan file autoinstall.yaml.
2. Buat file user-data (autoinstall) dan meta-data kosong sebagai pasangan cloud-init.
3. Konfigurasikan DHCP agar mengarahkan client ke boot file netboot yang menyertakan parameter kernel autoinstall ds=nocloud-net;s=http://provision-server/ubuntu/.
4. Nyalakan seluruh 20 server secara bersamaan lewat PXE.
5. Setiap server akan mengunduh autoinstall.yaml, menjalankan instalasi tanpa interaksi, lalu reboot otomatis ke sistem baru dengan hostname unik (bisa didapat dari MAC address lewat skrip di sisi server HTTP).

Hasilnya: 20 server selesai terpasang dalam waktu yang hampir bersamaan, dengan konfigurasi dasar identik, siap dikonfigurasi lanjut oleh Ansible atau Terraform.

Tutorial Step-by-Step: Membuat Preseed Debian untuk Netboot

Langkah 1 — Siapkan server HTTP untuk menyajikan file preseed Letakkan file preseed.cfg di direktori yang bisa diakses lewat HTTP, misalnya /var/www/html/preseed/preseed.cfg.

Langkah 2 — Tulis konfigurasi dasar Isi file sesuai kebutuhan (locale, partisi, user, paket) seperti contoh pada bagian sebelumnya.

Langkah 3 — Siapkan boot netboot Debian Gunakan image netboot resmi (netboot.tar.gz) dari mirror Debian, ekstrak ke direktori TFTP.

Langkah 4 — Tambahkan parameter boot Pada konfigurasi PXE (pxelinux.cfg/default atau GRUB netboot), tambahkan baris:

APPEND auto=true priority=critical url=http://provision-server/preseed/preseed.cfg

Langkah 5 — Uji pada satu mesin (VM) terlebih dahulu Selalu uji di lingkungan virtual sebelum diterapkan ke server fisik produksi.

Langkah 6 — Validasi hasil instalasi Periksa hostname, partisi, user, dan service yang berjalan sesuai ekspektasi.

Langkah 7 — Standarkan dan simpan di Git Setelah teruji, commit file preseed ke repository sebagai bagian dari infrastructure as code.

Kesalahan yang Sering Terjadi

1. Password disimpan dalam bentuk plaintext Penyebab: menyalin contoh dari internet tanpa mengganti ke hash. Dampak: kredensial mudah dibaca siapa pun yang mengakses file konfigurasi. Solusi: selalu gunakan password ter-hash (mkpasswd -m sha-512) dan simpan file di lokasi terbatas akses, idealnya dengan secret management.

2. Skema partisi tidak sesuai disk target Penyebab: recipe partman/storage layout ditulis untuk satu disk, padahal server tujuan punya beberapa disk berbeda ukuran. Dampak: instalasi gagal atau salah menimpa disk yang salah. Solusi: gunakan matching berdasarkan serial atau path disk, dan uji di hardware yang representatif.

3. Late-commands/early-commands tidak idempotent Penyebab: skrip custom dijalankan tanpa pengecekan kondisi awal. Dampak: instalasi ulang bisa gagal atau menghasilkan konfigurasi ganda. Solusi: tulis skrip yang aman dijalankan berkali-kali (idempotent).

4. Versi installer tidak cocok dengan sintaks konfigurasi Penyebab: menyalin contoh dari versi Ubuntu/Debian lama ke rilis baru. Dampak: field yang sudah deprecated menyebabkan validasi gagal (terutama pada Subiquity versi baru yang memperlakukan key tak dikenal sebagai fatal error). Solusi: selalu cek dokumentasi resmi sesuai versi rilis yang digunakan.

5. Tidak ada mekanisme rollback/testing Penyebab: konfigurasi langsung diterapkan ke server produksi tanpa staging. Dampak: kesalahan konfigurasi berdampak masif ke banyak server sekaligus. Solusi: selalu uji di VM/staging environment sebelum rollout massal.

Tips dan Rekomendasi

• Simpan file preseed/autoinstall di repository Git dengan versioning yang jelas per rilis OS.
• Pisahkan konfigurasi sensitif (password hash, kunci SSH) dari konfigurasi umum, dan kelola lewat secret manager.
• Gunakan hostname dinamis berbasis MAC address atau serial number agar tidak perlu file terpisah untuk tiap mesin.
• Gabungkan dengan alat konfigurasi lanjutan seperti Ansible atau cloud-init lanjutan untuk konfigurasi pasca-instalasi (hardening, monitoring agent, dsb).
• Selalu validasi file YAML autoinstall dengan linter sebelum dipakai, karena kesalahan indentasi adalah penyebab kegagalan paling umum.

Kesimpulan

Debian Preseed dan Ubuntu Autoinstall adalah dua jalan berbeda menuju tujuan yang sama: instalasi Linux yang konsisten, cepat, dan bebas interaksi manual. Preseed mengandalkan format d-i package/question type value yang klasik namun sangat fleksibel, sementara Autoinstall memakai YAML terstruktur yang terintegrasi erat dengan ekosistem cloud-init. Keduanya sama-sama krusial untuk provisioning server skala besar, dan keduanya paling efektif ketika diperlakukan sebagai kode — diuji, di-review, dan disimpan dalam version control.

Poin penting yang perlu diingat:

• Selalu gunakan password ter-hash, jangan plaintext.
• Uji konfigurasi di lingkungan staging sebelum produksi.
• Sesuaikan sintaks dengan versi OS yang dipakai.
• Kombinasikan dengan tools konfigurasi lanjutan untuk hasil provisioning yang benar-benar end-to-end.

Sudah pernah mencoba membuat pipeline provisioning otomatis dengan Preseed atau Autoinstall? Bagikan pengalaman, tantangan, atau pertanyaan Anda di kolom komentar —

mari berdiskusi dan saling belajar! Jangan lupa bagikan artikel ini ke rekan tim infrastruktur Anda, dan jelajahi artikel terkait lainnya seputar automasi server di blog ini.

---

FAQ

Pertanyaan: Apa perbedaan utama antara Debian Preseed dan Ubuntu Autoinstall? Jawaban: Preseed menjawab pertanyaan debconf memakai format teks klasik d-i package/question type value, sedangkan Autoinstall Ubuntu memakai YAML terstruktur yang terintegrasi dengan cloud-init.

Pertanyaan: Apakah Preseed masih didukung di Debian versi terbaru? Jawaban: Ya, preseed masih menjadi mekanisme resmi Debian Installer pada rilis stabil terkini (Debian 13 “Trixie”).

Pertanyaan: Bagaimana cara mengirim file autoinstall ke server saat PXE boot? Jawaban: File autoinstall dapat disajikan lewat HTTP dengan parameter kernel ds=nocloud-net;s=http://server/path/, atau lewat drive data cloud-init pada VM/cloud.

Pertanyaan: Apakah aman menyimpan password langsung di file preseed atau autoinstall? Jawaban: Tidak disarankan menyimpan password plaintext; gunakan hash (misalnya SHA-512) dan batasi akses ke file konfigurasi tersebut.

Pertanyaan: Apa yang terjadi jika ada key konfigurasi yang tidak dikenali di autoinstall.yaml? Jawaban: Pada versi Subiquity yang lebih baru, key tak dikenal dapat menyebabkan validasi gagal secara fatal dan instalasi terhenti, sehingga penting mengikuti dokumentasi resmi sesuai versi.

---

Punya pengalaman atau kendala saat setup Preseed maupun Autoinstall?

Tulis di kolom komentar, ajak diskusi rekan tim Anda, dan bagikan artikel ini agar lebih banyak sysadmin terbantu. Ikuti terus blog ini untuk update konten seputar automasi infrastruktur, Linux, dan DevOps terbaru.