Every sysadmin has been there. You tweak a config file in /etc/nginx/ to fix a weird buffer overflow issue, and the next time you run your update script, the package manager wipes your changes without so much as a warning. It is not trying to be malicious; it is just following orders you gave it years ago when you installed the package. If the checksum of the file on disk doesn’t match the one in the package database, the manager assumes you want the upstream version back.

Why DPKG silently clobbers your work

Under the hood, apt and dpkg handle conffiles using a strict logic. If you edit a file marked as a conffile, it creates a md5 hash at installation. During an upgrade, it checks the current file against that hash. If they differ, you get that annoying interactive prompt. But in automated pipelines, the default answer is often to keep the existing one or overwrite it entirely. Most folks assume these tools track local deviations like a VCS, but they don’t. You need to know which files are even flagged as conffiles before you start hacking on them.

grep -E '^/etc/.*' /var/lib/dpkg/info/*.conffiles | cut -d: -f2 | sort -u

• Use dpkg-query to see if a specific file is actually tracked by the package database.
• Keep your custom overrides in separate files like /etc/nginx/conf.d/local.conf instead of touching the main nginx.conf.
• Check /etc/apt/apt.conf.d/ for settings that force non-interactive overwrites during upgrades.
• Always keep a backup of your /etc directory under version control so you can revert these silent wipes in seconds.

If you are managing machines at scale, stop manually editing the managed config files directly on the box. Use a configuration management tool or a simple symlink to a managed directory. If you must edit the file in place, consider marking it as immutable with chattr +i to prevent accidental overwrites, though remember to unset it before you trigger an upgrade or your package manager will start throwing errors that are far more confusing than a simple file overwrite.