Blog

Playbook mitigation berhenti di server kesembilan: journald.conf.d ternyata tidak pernah ada. Satu task file state=directory menutup asumsi itu.

TL;DR: Playbook gagal di server kesembilan karena folder /etc/systemd/journald.conf.d nggak ada; delapan server lain kebetulan punya, jadi lolos terus. Fix-nya simpel banget: tambah satu task file state=directory sebelum task salin, beres. Hasilnya journal turun dari 720M ke 288M, aman di bawah cap 300M.

Reboot satu server produksi itu mudah; yang sulit adalah pagarnya. Pre-flight lock, modul reboot, dan post-check uptime yang berani gagal.

TL;DR: Reboot satu server ternyata bukan cuma manggil modul reboot Ansible; playbook-nya dikasih pagar biar nggak nyasar. Dia nolak jalan kalau unattended-upgrades atau lock apt masih aktif, plus wajib konfirmasi dan --limit satu host biar nggak sembilan server ke-reboot sekaligus. Setelah reboot, uptime dibandingkan sebelum-sesudah buat membuktikan reboot-nya beneran kejadian.

Server internet-facing menumpuk log login gagal tanpa guard. Satu drop-in logrotate, direktif su, dan gerbang logrotate -d menutup masalahnya permanen.

TL;DR: Server yang kena brute-force login bikin btmp dan wtmp bengkak cepat, bisa tembus ratusan MB sebelum rotasi mingguan jalan. Solusinya pasang logrotate dengan weekly plus maxsize 50M biar file besar diputar lebih awal, tambah su root utmp buat hindari error izin direktori. Validasi dulu pakai logrotate -d biar config salah ketahuan sebelum produksi.

Playbook mingguan bilang OK tapi /var/log bengkak 654M: arsip btmp rotasi, file aktif yang di-truncate, dan pipe df yang nggak pernah jalan.

TL;DR: Disk /var/log bengkak diam-diam padahal playbook mingguan selalu lapor aman. Biang keroknya btmp, log login gagal yang numpuk gara-gara brute force SSH, fix-nya hapus arsip dan truncate file aktif biar sshd nggak perlu restart. Bonus: task bukti pakai modul command ternyata nggak memproses pipa, jadi harus diganti shell.

Dua angka untuk satu server yang sama: skor risiko dan skor kesehatan arahnya kebalikan, dan sidebar saya masih baca arah lama.

TL;DR: Dashboard gue bingung karena ring detail nunjukin 92 hijau, sidebar server yang sama bilang 30 merah. Ternyata sidebar masih baca skor risiko lama, sisanya udah pindah ke field health yang arahnya kebalikan. Fix-nya cuma dua baris, pelajarannya: migrasi arah metrik harus sekali di batas API.

Playbook hardening bilang changed, tapi sshd -T masih passwordauthentication yes: first-match-wins dan urutan Include membuat 50-cloud-init.conf menang.

TL;DR: Hardening SSH-nya gagal karena sshd pakai aturan first-match-wins: nilai pertama yang dibaca yang menang, bukan yang terakhir. File 50-cloud-init.conf isinya PasswordAuthentication yes dan urutan alfabetnya lebih dulu daripada drop-in-ku, jadi menang terus. Solusinya ganti nama jadi 00-hardening.conf, komen baris di config utama, dan selalu verifikasi pakai sshd -T.

Playbook Ansible mati karena apostrof di dalam block scalar, lalu host unreachable karena urutan penawaran key SSH. Dua pelajaran dari satu exit code 4.

TL;DR: Cron collector-nya mati gara-gara dua bug sekaligus: komentar dalam block scalar YAML ternyata bukan komentar beneran, dan apostrof di kata "today's" bikin Ansible gagal split argumen. Abis itu SSH kena "Too many authentication failures" karena key ed25519 ditolak duluan, jadi dia nambahin IdentitiesOnly=yes di ansible.cfg. Sekarang tiap exit code 4, dia cek dua itu duluan sebelum nyalahin jaringan.

Sidebar sticky yang gagal tanpa satu baris error: stretch flexbox makan ruang scroll, offset top ketutup header, dan ancestor ber-overflow.

TL;DR: Sticky sidebar gue nggak jalan gara-gara tiga hal: flexbox stretch bikin parent sedinggi viewport, top-0 nyangkut di balik header fixed, dan ada ancestor overflow-hidden yang motong. Fix-nya cuma items-start plus offset 55px yang disesuaikan tinggi header. Sekarang tiap pasang sticky, gue selalu cek inset, ruang scroll parent, dan rantai ancestor-nya.

Alert CPU jam 2 pagi yang ternyata cuma spike backup. Pelajaran debounce 3 sampel, hysteresis 0.75, dan dedupe insiden buat alert Discord.

TL;DR: Author bangun jam 2 pagi gara-gara alert CPU staging padahal cuma spike backup sesaat. Alertnya jadi dianggap spam sampai di-mute, dan alert yang di-mute lebih bahaya daripada nggak ada sama sekali. Solusinya: debounce 3 sampel, hysteresis recover di 0.75x, dedupe per insiden, plus pastikan alertnya beneran actionable.