Tutorial Ubuntu 26.04 / Membangun server dan menyiapkan serah terima operasional

Pembangunan server Ubuntu selesai ketika administrator lain dapat mengakses, mengubah, dan memulihkannya berdasarkan catatan yang tersedia. Praktik terpadu ini menggunakan mesin virtual (VM) khusus Ubuntu 26.04 LTS, memasang layanan yang diperlukan, lalu mencatat hasil nyata pengujian akses, reboot, dan pemulihan cadangan dalam dokumen serah terima operasional.

Menentukan cakupan dan kriteria penerimaan

Proyek dasar menyediakan administrasi SSH dan layanan web Nginx dalam jaringan lokal (LAN). Siapkan VM khusus, akses konsol, rencana alamat, klien administrasi yang diizinkan, serta lokasi cadangan independen. Tambahkan HTTPS publik hanya jika domain dan jalur validasinya berada di bawah kendali Anda. Pilih Samba atau kontainer bila dibutuhkan; sasaran praktik bukan memasang semua layanan.

Membangun sesuai urutan dependensi dengan perubahan kecil

1. Catat rilis, perangkat, waktu, dan alamat dari konsol, lalu selesaikan pembaruan dan reboot yang diperlukan.
2. Identifikasi pengelola serta cakupan Netplan atau NetworkManager. Terapkan perubahan alamat dengan konsol, cadangan, dan verifikasi netplan try.
3. Pastikan autentikasi kunci SSH berhasil melalui sesi baru sebelum memperketat kebijakan. Periksa listener sebenarnya serta konfigurasi layanan atau socket.
4. Pasang layanan yang diperlukan saja. Cadangkan konfigurasi, periksa sintaksnya, lalu terapkan perubahan. Batasi klien dan port yang nyata pada UFW serta firewall eksternal.
5. Siapkan cadangan independen dan uji pemulihan, termasuk jalur pemberitahuan kegagalan. Simpan kondisi awal sebelum uji reboot.

Jika suatu tahap gagal, periksa perubahan dan log tahap itu sebelum menambahkan perubahan berikutnya. Mengubah port administrasi, autentikasi, dan firewall sekaligus menyulitkan penentuan penyebab putusnya akses serta perubahan yang harus dikembalikan. Pastikan jalur konsol untuk pemulihan benar-benar dapat dibuka.

Memisahkan pemeriksaan lokal dari layanan LAN

Situs Nginx pada 127.0.0.1:8080 diperiksa dari server itu sendiri. Mengarahkan alpha.example.test ke 192.168.56.20 tidak membuat listener loopback dapat dijangkau dari luar. Gunakan --resolve untuk menghubungkan nama host dan port ke alamat loopback pada permintaan ini, lalu pastikan isi respons memuat alpha-site. Latihan kontainer memakai port 8081; praktik LAN berikut memakai 8082.

curl --noproxy '*' --fail --show-error --connect-timeout 5 --max-time 10 --resolve alpha.example.test:8080:127.0.0.1 http://alpha.example.test:8080/

Opsi --noproxy '*' pada dua perintah curl latihan memastikan permintaan langsung menuju server latihan, bukan melalui proxy yang mungkin dikonfigurasi. --resolve tidak mengubah DNS atau berkas hosts secara permanen. Dokumentasi curl tentang resolve, noproxy, batas waktu, dan fail menjelaskan masing-masing opsi tersebut.

Untuk pengujian LAN, siapkan jaringan host-only seperti pada pelajaran jaringan, dengan server 192.168.56.20/24 dan klien Linux 192.168.56.10. Direktori dokumen /srv/ubuntu-course-alpha dari latihan Nginx harus sudah tersedia di VM ini. Pastikan port 8082 belum digunakan dan tidak berbenturan dengan listener wildcard lain. Jika alamat atau jalur berbeda, sesuaikan seluruh perintah dan aturan secara konsisten setelah memverifikasinya.

Blok berikut menyimpan konfigurasi Nginx ke direktori cadangan baru, membuat situs LAN tanpa menimpa berkas yang sudah ada, lalu memeriksa dan memuat ulang konfigurasi. Jika berhenti di tengah, catat berkas dan symlink yang sudah dibuat serta lokasi cadangan sebelum melanjutkan. Jangan menghapus penjagaan keberadaan berkas untuk memaksa pengulangan.

(
set -eu
site=/etc/nginx/sites-available/ubuntu-course-lan
enabled=/etc/nginx/sites-enabled/ubuntu-course-lan
sudo test -f /srv/ubuntu-course-alpha/index.html
if ! ip -4 -o address show | grep -Fq ' 192.168.56.20/24 '; then
    printf 'Konfigurasikan dahulu alamat server latihan yang telah diverifikasi.\n' >&2; exit 1
fi
for path in "$site" "$enabled"; do
    if sudo test -e "$path" || sudo test -L "$path"; then
        printf 'Situs latihan sudah ada: periksa sebelum mengubahnya.\n' >&2; exit 1
    fi
done
backup_dir=$(sudo mktemp -d /root/nginx-before-lan.XXXXXX)
sudo cp -a /etc/nginx "$backup_dir/"
sudo sh -c 'set -C; cat > "$1"' sh "$site" <<'EOF'
server {
    listen 192.168.56.20:8082;
    server_name course-lab.example.test;
    root /srv/ubuntu-course-alpha;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s "$site" "$enabled"
sudo nginx -t
sudo systemctl reload nginx
sudo ss -lntp
printf 'Cadangan situs LAN: %s\n' "$backup_dir"
)

Tambahkan aturan berikut pada lingkungan yang sudah menerapkan kebijakan masuk ditolak secara baku sambil mempertahankan akses SSH. Periksa aturan yang benar-benar aktif: izin 8082 yang lebih luas dapat membuat klien yang seharusnya ditolak tetap tersambung. Jangan meneruskan port host-only ini ke internet.

sudo ufw allow from 192.168.56.10 to 192.168.56.20 port 8082 proto tcp
sudo ufw status numbered

Dari klien Linux yang diizinkan, yaitu .10, jalankan permintaan berikut dan cocokkan isi alpha-site.

curl --noproxy '*' --fail --show-error --connect-timeout 5 --max-time 10 --resolve course-lab.example.test:8082:192.168.56.20 http://course-lab.example.test:8082/

Uji koneksi baru yang sama dari klien yang dikecualikan, misalnya host .1, dan catat penolakannya. Jika koneksi gagal, periksa aturan serta log untuk membedakan penolakan yang diharapkan dari layanan yang memang mati. Jika kebijakan juga mensyaratkan penolakan nama host yang tidak dikenal, buat virtual host penolakan baku yang sesuai. server_name memilih konfigurasi, bukan menggantikan firewall atau autentikasi; dokumentasi pemrosesan permintaan Nginx menjelaskan pemilihan server baku ketika nama tidak cocok.

Untuk pembersihan, cocokkan catatan dengan situs serta aturan UFW yang dibuat oleh latihan ini, lalu hapus hanya keduanya. Setelah sudo nginx -t berhasil, muat ulang Nginx. Pertahankan situs loopback dan layanan lainnya. Sesudah reboot, ukur kembali alamat, listener, serta koneksi dari klien yang diizinkan dan dikecualikan.

Membuat skrip pemeriksaan HTTP sederhana

Simpan skrip lengkap berikut sebagai ~/check-web-lab.sh. Skrip membutuhkan Bash, curl, serta utilitas umum grep, mktemp, rm, dan date pada Ubuntu. Dua argumennya adalah URL nyata dan teks yang diharapkan. Jangan menimpa berkas skrip yang sudah digunakan untuk keperluan lain.

Untuk pemeriksaan lokal, cadangkan berkas hosts server sebelum menghubungkan alpha.example.test ke 127.0.0.1 di /etc/hosts, lalu jalankan bash ~/check-web-lab.sh http://alpha.example.test:8080/ alpha-site. Opsi --resolve pada perintah sebelumnya hanya berlaku pada satu eksekusi curl; skrip ini memakai resolusi nama yang berlaku di mesin tempat ia dijalankan. Periksa juga konfigurasi proxy, dan kecualikan nama atau alamat latihan melalui NO_PROXY atau no_proxy sesuai kebijakan jaringan setempat.

set -eu
if [ "$#" -ne 2 ]; then
    printf "Penggunaan: bash check-web-lab.sh URL TEKS_YANG_DIHARAPKAN\n" >&2
    exit 2
fi
url=$1
expected=$2
case "$url" in
    http://*|https://*) ;;
    *) printf "Gunakan URL HTTP atau HTTPS.\n" >&2; exit 2 ;;
esac
if [ -z "$expected" ]; then
    printf "Teks yang diharapkan tidak boleh kosong.\n" >&2
    exit 2
fi
body_file=$(mktemp)
trap 'rm -f -- "$body_file"' EXIT
if ! curl --fail --silent --show-error --connect-timeout 5 --max-time 10 "$url" -o "$body_file"; then
    printf "FAIL: permintaan atau verifikasi TLS gagal\n" >&2
    exit 1
fi
if ! grep -Fq -- "$expected" "$body_file"; then
    printf "FAIL: teks yang diharapkan tidak ditemukan\n" >&2
    exit 1
fi
printf "PASS: %s %s\n" "$(date -u +%FT%TZ)" "$url"

Keberhasilan mengembalikan status keluar 0 dan baris PASS. Kegagalan permintaan, verifikasi TLS (Transport Layer Security), atau pencocokan isi mengembalikan 1; argumen tidak valid mengembalikan 2. Jalankan lagi dengan teks yang sengaja tidak ada untuk memastikan kegagalan terdeteksi. Pemeriksaan memakai pencarian teks tetap, bukan ekspresi reguler.

Opsi --fail menolak respons HTTP 400 ke atas, tetapi bukan pemeriksaan bahwa status tepat 200. Skrip juga tidak mengikuti redirect secara otomatis. Gunakan URL akhir yang benar dan teks yang cukup khas untuk halaman sasaran; jika kebijakan membutuhkan status tertentu, tambahkan pemeriksaan status secara terpisah. PASS hanya membuktikan pemeriksaan HTTP dan teks tersebut, bukan keberhasilan login, penulisan basis data, atau cadangan. Jangan menaruh kata sandi atau token rahasia dalam URL, dan tentukan cara mengumpulkan waktu eksekusi serta status keluar saat dijalankan otomatis.

Untuk pemeriksaan LAN, hubungkan course-lab.example.test ke 192.168.56.20 melalui hosts pada klien .10 atau DNS yang dikelola. Jalankan bash ~/check-web-lab.sh http://course-lab.example.test:8082/ alpha-site dari klien tersebut. Simpan hosts sebelum menyunting dan hindari entri nama yang bertentangan. Bedakan URL lokal, LAN, dan HTTPS publik serta penolakan yang diharapkan dari gangguan layanan.

Mencatat uji izin, penolakan, reboot, dan pemulihan

Selain pengujian dari server sendiri, lakukan pengujian dari klien yang benar-benar diizinkan dan dikecualikan. Pertahankan koneksi SSH lama saat membuka sesi baru. Jadwalkan reboot, lakukan pada waktu yang disepakati, lalu periksa kembali akses dan layanan setelah sistem hidup.

Pulihkan cadangan ke lokasi terpisah yang masih kosong. Periksa isi, izin, serta fungsi yang diperlukan aplikasi; pemulihan berkas saja belum membuktikan seluruh layanan kembali bekerja. Tinggalkan pengujian yang belum dilakukan sebagai pekerjaan tertunda. Gunakan panduan firewall Ubuntu bersama catatan aturan yang benar-benar diterapkan dan hasil koneksi yang diukur.

Mengisi dokumen serah terima dengan hasil pengukuran

Gunakan templat berikut sebagai awal catatan operasional. Ganti isian dalam tanda kurung siku dengan hasil pemeriksaan. Untuk rahasia, catat hanya rujukan lokasi penyimpanan yang disetujui, bukan nilainya. Tentukan penanggung jawab operasi dan pemulihan; jangan menyalin alamat contoh atau menganggap pemasangan yang berhasil sebagai bukti semua uji lulus.

Sistem: [hostname, tujuan, penanggung jawab]
Platform: [rilis Ubuntu, kernel, host VM, jalur konsol]
Jaringan: [antarmuka, renderer, alamat, gateway, DNS]
Akses: [klien yang diizinkan, listener SSH nyata, lokasi penyimpanan kunci]
Layanan: [versi, jalur konfigurasi, perintah validasi dan reload]
Paparan: [listener, aturan UFW, firewall eksternal, binding kontainer]
TLS: [nama host, mekanisme perpanjangan, pemantauan kedaluwarsa/kegagalan]
Cadangan: [cakupan, identitas tujuan independen, retensi, penyimpanan kunci]
Uji pemulihan: [waktu, tujuan, hasil pemeriksaan isi/izin/aplikasi]
Penerimaan: [pengujian, klien, hasil yang diharapkan/nyata, lokasi bukti]
Rollback: [batas perubahan, kondisi awal tersimpan, prosedur pemulihan]
Tertunda: [pengujian belum dilakukan, risiko belum selesai, pemilik, tenggat]

Simpan bukti verifikasi bersama riwayat perubahan, lalu periksa apakah administrator lain dapat menyiapkan akses, pemeriksaan, dan pemulihan dari catatan itu saja. Tentukan penerima pemberitahuan, jadwal pemeriksaan pembaruan, sertifikat, dan cadangan, serta pemilik pekerjaan tertunda. Dengan tanggung jawab yang jelas, operasi dapat dilanjutkan tanpa bergantung pada ingatan pembangun server.