Latihan pemulihan gangguan Linux: bukti layanan, log, dan respons HTTP

Latih pemulihan gangguan Linux dalam lingkungan terisolasi: pastikan keadaan awal bekerja, ubah satu penyebab, lalu pulihkan kondisi yang diubah berdasarkan bukti. Nyatakan pemulihan selesai setelah status layanan dan respons yang benar-benar diterima pengguna sama-sama kembali normal.

Siapkan snapshot VM dan pemulihan konsol dalam panduan berbahasa Inggris. Bandingkan bukti sebelum dan sesudah setiap perubahan menggunakan penyelidikan berdasarkan log.

Acuan latihan konfigurasi adalah mesin virtual (VM) dengan instalasi biasa Ubuntu 26.04 LTS, yaitu rilis dukungan jangka panjang, atau Rocky Linux seri 9. Konfigurasi layanan serta paket pada kontainer, Windows Subsystem for Linux (WSL), dan rilis lain dapat berbeda. Siapkan konsol pemulihan dan catat versi melalui panduan persiapan VM berbahasa Inggris.

Menentukan lingkungan terisolasi dan keadaan awal yang normal

Gunakan VM latihan Ubuntu atau Rocky Linux yang memiliki pengelola systemd pengguna, Python 3, curl, dan grep. Jalankan sebagai pengguna latihan biasa. Latihan ini memakai layanan pengguna khusus dan server HTTP loopback; Nginx produksi, SSH, firewall, dan disk sistem tidak perlu diubah.

Periksa ss -lnt untuk memastikan port loopback 18080 kosong. Jika sudah digunakan, ganti semua nilai port latihan secara konsisten dengan port kosong lain. Konfirmasi jalur Python melalui command -v python3. Contoh memakai /usr/bin/python3; bila berbeda, sesuaikan ExecStart dan ekspresi sed pada uji pertama dengan jalur yang telah diverifikasi.

Pastikan unit linux-course-recovery.service dan direktori linux-recovery-lab belum digunakan. Jika sudah ada, pilih nama latihan lain tanpa menimpa data. Server pengembangan http.server Python dibatasi ke 127.0.0.1 untuk latihan ini dan tidak sesuai sebagai server produksi internet.

Blok berikut menolak direktori lab yang sudah ada dan memakai noclobber untuk pembuatan unit. Jika salah satu tahap gagal, blok berhenti; berkas yang telanjur dibuat dapat tetap ada. Periksa hasilnya sebelum mengulang.

(
set -o pipefail
mkdir "$HOME/linux-recovery-lab" || exit 1
mkdir -p "$HOME/.config/systemd/user" || exit 1
mkdir "$HOME/linux-recovery-lab/site" || exit 1
printf "recovery baseline\n" > "$HOME/linux-recovery-lab/site/index.html" || exit 1
(
set -C
cat > "$HOME/.config/systemd/user/linux-course-recovery.service" <<'EOF'
[Unit]
Description=Isolated Linux recovery lab

[Service]
Type=simple
WorkingDirectory=%h/linux-recovery-lab/site
ExecStart=/usr/bin/python3 -m http.server 18080 --bind 127.0.0.1
EOF
) || exit 1
systemctl --user daemon-reload || exit 1
systemctl --user start linux-course-recovery.service || exit 1
systemctl --user is-active linux-course-recovery.service || exit 1
curl --fail --max-time 5 --retry 3 --retry-connrefused --retry-delay 1 --retry-max-time 10 http://127.0.0.1:18080/ | grep -Fx "recovery baseline" || exit 1
cp "$HOME/.config/systemd/user/linux-course-recovery.service" "$HOME/linux-recovery-lab/service.good"
)

Lanjutkan ke gangguan hanya setelah melihat active dan teks tepat recovery baseline. Pipefail memastikan kegagalan curl tidak tersembunyi oleh pemeriksaan teks; grep memeriksa satu baris yang harus cocok. Curl memberi hingga tiga percobaan ulang untuk penolakan koneksi saat server baru mulai. Batas tiap transfer lima detik tetap berlaku, sedangkan batas waktu retry membatasi dimulainya percobaan berikutnya dan bukan batas mutlak keseluruhan.

Unit yang lolos pemeriksaan disalin ke service.good. Layanan hanya dimulai, tanpa enable untuk menambahkan aktivasi otomatis saat boot. Jika keadaan awal gagal, periksa jalur Python, konfigurasi unit, port, dan akses pengelola pengguna sebelum melanjutkan. Status active sesaat saja belum membuktikan server siap menerima permintaan.

Percobaan pertama: merusak hanya jalur executable

Pastikan unit latihan masih sama dengan konfigurasi yang baru diverifikasi. Jalankan sed dan daemon-reload terlebih dahulu; lanjutkan ke restart setelah keduanya berhasil dan ExecStart benar-benar menunjuk jalur /nonexistent/course-python. Perintah status atau restart dapat berstatus gagal sesuai tujuan percobaan; tetap baca journal setelah mencatat hasilnya.

sed -i 's@ExecStart=/usr/bin/python3 @ExecStart=/nonexistent/course-python @' "$HOME/.config/systemd/user/linux-course-recovery.service"
systemctl --user daemon-reload
systemctl --user restart linux-course-recovery.service
systemctl --user status linux-course-recovery.service --no-pager
journalctl --user -u linux-course-recovery.service --since "5 minutes ago" --no-pager

Unit kini merujuk ke executable yang tidak ada, sehingga tidak dapat tetap aktif. Bergantung pada waktunya, restart dapat langsung gagal atau kegagalan baru terlihat saat status dibaca. Cari galat eksekusi pada journal, termasuk kemungkinan 203/EXEC. Catat pesan sebenarnya, waktu, dan status keluar; kegagalan layanan tidak selalu merupakan masalah jaringan.

Memulihkan konfigurasi dan memverifikasi respons

(
set -o pipefail
cp "$HOME/linux-recovery-lab/service.good" "$HOME/.config/systemd/user/linux-course-recovery.service" &&
systemctl --user daemon-reload &&
systemctl --user reset-failed linux-course-recovery.service &&
systemctl --user start linux-course-recovery.service &&
systemctl --user is-active linux-course-recovery.service &&
curl --fail --max-time 5 --retry 3 --retry-connrefused --retry-delay 1 --retry-max-time 10 http://127.0.0.1:18080/ | grep -Fx "recovery baseline"
)

Pulihkan hanya unit latihan dari berkas yang diketahui baik, muat ulang konfigurasi pengelola, lalu mulai layanan. Reset-failed dapat membersihkan keadaan gagal dan penghitung batas mulai, tetapi tidak memperbaiki isi konfigurasi yang salah. Rangkaian && berhenti jika tahap sebelumnya gagal. Keadaan layanan dan teks halaman yang diharapkan harus sama-sama kembali.

Percobaan kedua: membedakan port tertutup dan galat HTTP

Jalankan baris berikut satu per satu dan catat status keluar setiap curl sebelum perintah lain mengubahnya. Pastikan stop benar-benar berhasil sebelum menguji koneksi saat layanan berhenti. Setelah start terakhir, tunggu server siap dan ulangi pemeriksaan halaman jika permintaan pertama terlalu cepat.

curl -i --max-time 5 http://127.0.0.1:18080/missing-resource
systemctl --user stop linux-course-recovery.service
curl -i --connect-timeout 2 --max-time 5 http://127.0.0.1:18080/
ss -lnt
systemctl --user start linux-course-recovery.service
curl --fail --max-time 5 http://127.0.0.1:18080/

Permintaan pertama menerima HTTP 404 dari server yang sedang berjalan karena jalur itu tidak ada. Setelah layanan dihentikan, permintaan berikutnya gagal pada lapisan koneksi, biasanya dengan connection refused; ia tidak menerima respons HTTP 404. Cocokkan hasilnya dengan listener pada ss.

Tanpa --fail, curl dapat keluar dengan status 0 meskipun respons HTTP adalah 404. Bandingkan dengan permintaan beropsi --fail, yang memperlakukan respons HTTP galat sebagai kegagalan. Dengan cara ini Anda membedakan kegagalan layanan, transport, dan HTTP tanpa mengubah firewall.

Mencatat satu perubahan dan bukti pemulihannya

Jangan memenuhi disk sistem, memblokir SSH pengelolaan, atau menghapus berkas acak dalam latihan ini. Uji yang lebih mengganggu memerlukan VM klona terpisah, penyimpanan yang dibatasi, konsol yang sudah diverifikasi, dan backup. Tujuannya adalah melatih penalaran dari bukti menuju pemulihan.

Menghentikan lab dan menghapus hanya unitnya

systemctl --user stop linux-course-recovery.service &&
systemctl --user reset-failed linux-course-recovery.service &&
rm -- "$HOME/.config/systemd/user/linux-course-recovery.service" &&
systemctl --user daemon-reload &&
ss -lnt

Pastikan listener loopback latihan telah hilang. Jika rangkaian pembersihan berhenti, periksa galat sebelum menghapus berkas secara manual; jangan menganggap layanan sudah berhenti. Tinjau direktori lab secara terpisah sebelum membersihkannya, karena di dalamnya masih ada konfigurasi normal dan halaman statis. Batasi reset-failed ke unit latihan agar catatan kegagalan layanan pengguna lain tetap terjaga.

Dokumentasi resmi

• Kegagalan eksekusi dan status keluar systemd
• Status dan reset-failed systemctl
• Python http.server dan keterbatasan keamanannya
• Kegagalan transport dan HTTP pada curl