Menyimpan Riwayat Konfigurasi Server dengan etckeeper

etckeeper adalah alat kecil yang menyimpan isi folder /etc ke dalam repositori git, sehingga setiap perubahan konfigurasi server tercatat dan bisa dibandingkan atau dikembalikan.

Kenapa ini penting? Hampir semua masalah server yang "tiba-tiba" muncul berawal dari perubahan konfigurasi: baris Nginx yang disunting malam-malam, sshd_config yang diubah rekan kerja, atau file yang ditimpa saat update paket. Tanpa catatan, kamu hanya bisa menebak. Dengan etckeeper, kamu cukup melihat riwayat dan menemukan perubahan terakhir sebelum masalah muncul.

Apa yang dicatat etckeeper?

Semua file di /etc, folder tempat Linux menyimpan konfigurasi sistem dan layanan. Kalau kamu belum akrab dengan isi folder itu, struktur folder Linux dari /etc sampai /var bisa jadi pengantar.

Menurut dokumentasinya, etckeeper membuat commit dalam tiga situasi:

• Saat paket dipasang, diperbarui, atau dihapus lewat apt (dan pengelola paket sejenis), sebelum dan sesudah proses berjalan.
• Sekali sehari lewat tugas terjadwal, bila ada perubahan yang belum di-commit.
• Saat kamu sendiri menjalankan etckeeper commit.

Git secara bawaan tidak menyimpan pemilik dan izin file. etckeeper menutup kekurangan itu dengan menyimpan data tersebut di file /etc/.etckeeper, yang ikut di-commit dan bisa dipakai untuk memulihkan izin.

Bagaimana cara memasangnya?

Di Ubuntu dan Debian:

sudo apt install etckeeper

Pada paket Debian dan Ubuntu, repositori biasanya langsung dibuat dan commit pertama dijalankan otomatis saat pemasangan. Cek dengan sudo git -C /etc log --oneline | head. Bila kosong, jalankan sudo etckeeper init lalu sudo etckeeper commit "commit awal".

Di AlmaLinux atau Rocky, etckeeper tersedia dari repositori EPEL. Setelah dipasang, jalankan etckeeper init dan commit awal secara manual, lalu pastikan integrasi dengan dnf aktif dengan memasang ulang satu paket kecil dan melihat apakah commit baru muncul.

Pengaturan ada di /etc/etckeeper/etckeeper.conf. Bawaannya memakai git, dan untuk kebanyakan server tidak perlu diubah.

Perintah sehari-hari yang paling berguna

Biasakan commit dengan pesan yang jelas setiap selesai mengubah sesuatu. Commit harian otomatis tetap berguna sebagai jaring pengaman, tapi pesannya generik dan bisa menggabungkan beberapa perubahan sekaligus.

Setelah mengembalikan file, jangan lupa uji konfigurasi lalu muat ulang layanannya, misalnya sudo nginx -t && sudo systemctl reload nginx. Mengembalikan file tidak otomatis memberi tahu layanan yang sedang berjalan.

Contoh menelusuri masalah setelah update

Misalkan website tiba-tiba menampilkan error 502 pagi ini, padahal kemarin normal. Langkah pertama, lihat commit terbaru dengan sudo git -C /etc log --oneline --since=yesterday. Kalau ada commit dari apt, misalnya setelah pembaruan PHP, buka isinya dengan git show dan perhatikan file di folder php atau nginx yang ikut berubah. Sering kali penyebabnya terlihat jelas, misalnya file pool PHP-FPM yang ditimpa versi bawaan paket sehingga path socket berbeda dari yang ditulis di konfigurasi Nginx.

Dari situ kamu bisa memilih: mengembalikan file lama, atau menyesuaikan konfigurasi lain dengan versi baru. Keputusannya diambil berdasarkan bukti, bukan tebakan. Bila server juga rutin diaudit, catatan ini membantu menjelaskan temuan alat seperti Lynis, karena kamu bisa melihat kapan sebuah setelan berubah.

Perlukah repositori didorong ke server lain?

Repositori di /etc/.git ikut hilang bila disk server rusak. Karena itu ada pilihan PUSH_REMOTE di etckeeper.conf untuk mendorong setiap commit ke remote secara otomatis. Dokumentasinya menyarankan memakai jalur aman seperti SSH, hanya ke server yang dipercaya, dan menjaga salinan di remote dengan izin 700.

Untuk kebanyakan bisnis kecil, cara yang lebih sederhana adalah memastikan /etc (termasuk folder .git di dalamnya) ikut masuk ke backup terenkripsi yang sudah berjalan. Cara membuat backup seluruh server ada di backup server Linux dengan restic.

Apa bedanya dengan Ansible atau alat manajemen konfigurasi?

Ansible dan alat sejenis mendefinisikan konfigurasi yang seharusnya ada, lalu menerapkannya ke banyak server. etckeeper hanya mencatat apa yang sudah terjadi di satu server. Keduanya tidak saling menggantikan.

Kalau kamu mengelola banyak server, konfigurasi sebaiknya dikelola dari satu tempat seperti dijelaskan di cara memakai Ansible untuk mengatur banyak VPS. etckeeper tetap berguna di tiap server untuk menangkap perubahan yang dibuat langsung di luar Ansible, sehingga perbedaan antara rencana dan kenyataan kelihatan.

Kebiasaan kecil yang membuat etckeeper benar-benar berguna

• Commit sebelum dan sesudah perubahan besar. Commit sebelum mulai memastikan titik awal yang bersih, commit sesudahnya memberi pesan yang jelas.
• Isi pesan dengan alasan, bukan hanya apa. "naikkan client_max_body_size untuk upload katalog" jauh lebih membantu daripada "ubah nginx".
• Periksa status sesekali. Perubahan yang tidak di-commit berhari-hari tanda ada yang mengubah server diam-diam.
• Pakai identitas yang benar. Commit dibuat oleh root, jadi bila server dikelola beberapa orang, sebutkan nama di pesan commit agar jelas siapa pelakunya.