ssh

db-push mengganti seluruh database staging dari dump dev, akun ikut lenyap. Dua dump kecil dan guard jujur menahaninya.

TL;DR: db-push ternyata nge-replace seluruh database staging pakai dump dev, dan tabel users nggak ikut, jadi akun admin hilang terus. Solusinya: dump data users dari staging dulu sebelum DROP, terus di-restore lagi abis import. Ditambah guard kayak --complete-insert, sanity check sebelum DROP, dan chmod 600 biar aman.

Membalik arah db-push jadi db-pull bukan cuma menukar panah: backup lokal dulu, dump divalidasi sebelum dipercaya, aturan backtick berubah di SSH.

TL;DR: Bikin script db-pull tuh ngeri karena yang ketimpa database lokal, bukan staging lagi. Makanya urutannya dibalik, wajib backup lokal dulu, terus dump staging dicek ukuran sama tanda Dump completed baru di-replace. Terus verifikasinya ketat banget, hitung baris tiap tabel harus sama persis, backtick juga diakalin biar aman di SSH.

Image Docker Hub tertinggal dari rilis npm. Bangun image di mesin besar, kirim via save, gzip, dan scp, lalu load di VPS kecil tanpa build.

TL;DR: Rilis npm 9router 0.5.81 udah keluar tapi image Docker Hub-nya masih mentok di 0.5.75. Karena RAM server cuma 964MB dan gak mungkin build Next.js di situ, imagenya dibangun di mesin lokal terus dikirim pakai docker save, gzip, dan scp. Container lama cukup di-rename, jadi rollback gampang kalau yang baru bermasalah.

Prometheus TargetDown di server ke-10 fleet: node_exporter nggak ada, Ansible gagal deploy karena SSH MaxAuthTries terbakar oleh urutan kunci ed25519. Fix = hardening SSH dulu (key-only, urutan kunci), baru monitoring — semua idempoten.

TL;DR: Monitor nyala merah alert TargetDown server kesepuluh, kira cuma kurang scrape config tapi SSH gagal total karena node_exporter nggak ada dan Ansible kena batas MaxAuthTries dari terlalu banyak kunci ed25519. Akhirnya benerin urutan playbook: hardening SSH dulu (hanya kunci, urutin biar nggak kebakar limit), baru deploy node_exporter. Sekarang idempoten, server baru jalanin playbook sama aja.

Server ke-10 fleet bongkar ilusi otomatisasi: SSH MaxAuthTries terbakar, cloud-init timpa hardening, node_exporter nggak ter-deploy. Pelajaran: fleet discipline berarti pipeline idempoten, bukan manual one-off.

TL;DR: Tambah server ke-10 gagal karena SSH MaxAuthTries 6 habis dipakai kunci salah urutannya, plus cloud-init override PasswordAuthentication lewat file drop-in yang menang leksikal. Server baru juga nggak pasang node_exporter jadi monitoring buta. Pelajarannya: playbook harus idempoten kelola config cloud-init eksplisit, jangan asumsikan rollout lama pasti jalan.

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.

Satu service Compose dengan env FORGEJO__: SSH bawaan loopback, push-to-create tanpa UI, LFS aktif, dan healthcheck yang benar.

Setiap login SSH ke VPS muncul setlocale: LC_CTYPE cannot change locale. Ternyata pengirimnya laptop Debian sendiri lewat default SendEnv.