Quit letting your package manager overwrite your local configuration without permission

Technical Briefing | 11/11/2026

You spend all morning fine-tuning a daemon configuration file, restart the service, and verify it behaves exactly how you want. Then, you run a routine system upgrade later that day. Next thing you know, the service is broken, and you realize the package manager happily replaced your hard work with the maintainer’s default file. This is a rite of passage, but it shouldn’t be a recurring cost of doing business.

The trap of dpkg’s configuration handling

When apt encounters a modified config file, it doesn’t just nuke your changes. It usually tosses them into a file ending in .dpkg-dist. But if you aren’t paying attention to the terminal output during a mass update, those files sit there, ignored, while your application runs with whatever defaults it pulled down. Stop blindly saying yes to package updates and start checking the wreckage.

find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old'

• Use configuration management tools like Ansible to enforce idempotency rather than editing files by hand
• Keep your manual overrides in drop-in directories like /etc/systemd/system/service.d/ so the package manager never touches them
• Set the dpkg force-confold flag to preserve your existing version if you absolutely cannot risk a wipe

If you really want to lock a file down so even a forced update doesn’t touch it, you can use chattr. It is a bit of a nuclear option because it prevents even you from editing the file without removing the attribute, but it stops the automated processes from overriding your state. Once you flag a file as immutable, the package manager will throw an error instead of silently swapping your config.

Try tagging your most sensitive firewall or kernel configs with that immutable bit once you have them settled. It saves a lot of headaches when you have juniors or over-eager automation running updates on your boxes.