Drop-In (.d) Directories In Linux Explained: A Safer Way to Manage Config Files

Linux configuration can be tricky for new Linux admins. Editing the main config file directly often works, until an upgrade overwrites your changes or a typo takes down a service. That's where .d directories come in.

These special directories let you manage configuration in small, modular files instead of touching the system defaults.

It's a safer, cleaner, and more automation-friendly approach used across most modern Linux systems.

What is a .d Directory?

A .d directory is simply a folder that holds multiple small configuration fragments for a single service.

For example:

/etc/ssh/sshd_config
/etc/ssh/sshd_config.d/

The first is the main SSH daemon config file and the second (ending in .d) is a directory where you can drop in extra .conf files that get merged at startup.

The .d suffix isn't an official standard, but it's now a common Linux convention. It stands for "directory of configuration fragments" and is often called a drop-in directory because you can just "drop in" your changes without editing the base file.

Advantages of Using Drop-in Configuration Directory (.d)

1. Safe from Package Upgrades

System updates may replace or modify main config files. Files in .d directories are not touched, so your settings remain intact.

Example:

/etc/ssh/sshd_config.d/99-custom.conf

Your file will override defaults even after an upgrade.

2. Better for Automation

Tools like Ansible or Puppet work best when configs are modular. You can:

• Deploy or remove a single file.
• Manage version-controlled snippets.
• Avoid parsing large monolithic files.

3. Order and Precedence

Files in .d directories load alphabetically. Later files override earlier ones.
That's why many admins prefix filenames with numbers:

10-defaults.conf
50-hardening.conf
99-local.conf

4. Safer Troubleshooting

You can disable a config temporarily by renaming a single file. No need to risk breaking a huge system config by editing it in place.

Real Examples

Best Practice

Keep distro defaults untouched and put your overrides in .d directories with clear naming:

/etc/ssh/sshd_config.d/99-hardening.conf

Only replace the main file if you truly need a full custom configuration, which is rare.

Key Takeaway

Even though .d directories aren't part of any strict standard, they've become a best practice for safe and maintainable Linux configuration.

They protect your settings from updates, simplify automation, and make system management less error-prone, which is exactly what you want when scaling with tools like Ansible.

Let's look at why you should use drop-In (.d) directories for Linux configuration management with an example, and how it makes automation tools like Ansible far more reliable.

1. The Old Way: Editing Main Config Files

Traditionally, sysadmins edited big configuration files directly:

sudo nano /etc/ssh/sshd_config

This works fine until:

• A package upgrade resets or merges the file
• A second admin overwrites your changes
• An automation tool tries to manage it differently

Result: config drift, merge conflicts, and headaches.

2. The Modern Way: Drop-In Config Directories

Modern Linux systems now support drop-in configuration directories like /etc/ssh/sshd_config.d/ and /etc/sudoers.d/. They let you safely extend or override defaults without touching the main file.

To fix this, most modern daemons now use a .d directory for modular configs.

An Example for SSH:

Include /etc/ssh/sshd_config.d/*.conf

Each .conf file inside that directory gets loaded in order, and later files override earlier ones.

So if you add /etc/ssh/sshd_config.d/99-custom.conf, it wins over everything else.

Other examples:

3. Why This Makes Automation Easier

When you use Ansible, Puppet, or Chef, these directories are a dream to manage.

You can simply drop a file instead of editing an existing one:

- name: Deploy SSH override
  copy:
    src: sshd_override.conf
    dest: /etc/ssh/sshd_config.d/99-ansible.conf
    mode: '0644'
  notify: Reload sshd

Benefits:

• No merge conflicts
• No overwriting distro defaults
• Fully idempotent (re-runs don't change anything unnecessarily)
• Works cleanly across OS versions

4. Practical Example: SSH Configuration

Instead of editing /etc/ssh/sshd_config to disable password login, just create:

/etc/ssh/sshd_config.d/99-hardening.conf

# Managed by Ansible
PermitRootLogin no
PasswordAuthentication no

Reload the service:

sudo systemctl reload sshd

Now your system is hardened, safe from package updates, and your automation remains clean.

5. When You Might Still Edit the Main File

• If the service does not yet support .d includes (rare today)
• If you must remove or change the Include directive itself
• For immutable images where you want total config control

But for everyday systems, overrides are safer and easier.

6. Key Takeaways

Frequently Asked Questions

Conclusion

Drop-in .d directories make Linux configuration safer, cleaner, and easier to maintain. Instead of replacing entire files, you only add what's needed. This approach keeps the original vendor defaults intact, makes upgrades smoother, and reduces the risk of breaking critical services.

For system administrators and automation tools like Ansible, drop-in directories provide a structured way to manage changes across multiple systems. They help you avoid conflicts, simplify version control, and maintain predictable behavior.

In short, if you're managing Linux at scale, or just want a more reliable setup, learning to use .d directories is a best practice worth adopting.

So next time you see /etc/something.conf, look for /etc/something.d/, that's where modern Linux expects you to customize.

Recommended Read:

• How To Backup And Restore Installed Packages In Ubuntu Linux