Linux /etc/ .d directories.

[dos2unix]

Understanding .d Directories in /etc on Linux​

In Linux, the /etc directory is a central location for system configuration files. Within this directory, you'll often find subdirectories that end with .d, such as profile.d, httpd-conf.d, nginx-conf.d, and postgresql.d. These .d directories play a crucial role in organizing and managing configuration files. Let's explore what they are and how they work.

What Does the .d Suffix Mean?​

The .d suffix stands for "directory." This naming convention helps distinguish these directories from regular configuration files. The use of .d directories is a way to modularize and manage configurations more efficiently.

Purpose of .d Directories​

1. Modular Configuration: Instead of having a single, monolithic configuration file, .d directories allow configurations to be split into multiple smaller files. This modular approach makes it easier to manage and update configurations without affecting the entire system.
2. Package Management: When installing software packages, each package can drop its configuration file into the appropriate .d directory. This way, the main configuration file can include all the individual configurations from the .d directory. For example, the logrotate utility uses /etc/logrotate.d to manage log rotation settings for different applications.
3. Avoiding Conflicts: By using separate files for different configurations, .d directories help avoid conflicts that might arise from multiple programs or administrators editing the same configuration file. This is particularly useful for complex applications like web servers (e.g., Apache, Nginx) that have many configuration options.

How .d Directories Work​

1. Inclusion Mechanism: The main configuration file typically includes all the files in the corresponding .d directory. For example, in the case of logrotate, the main configuration file /etc/logrotate.conf includes all files in /etc/logrotate.d using an include directive.
2. Drop-in Files: These individual configuration files are often referred to as "drop-in" files. They allow administrators to add or override specific settings without modifying the main configuration file. This approach is also used by systemd, where drop-in files can override or extend unit configurations.
3. Organization by Function: Some applications use .d directories to organize configurations by function. For instance, Apache uses conf.d to manage configurations for virtual hosts, modules, and other settings. This organization helps in sharing administration duties and simplifies migration and recovery processes.

Examples of .d Directories​

• profile.d: Contains scripts that are sourced by the shell when a user logs in. These scripts can set environment variables or run commands.
• httpd-conf.d: Used by the Apache web server to manage additional configuration files for virtual hosts, modules, etc.
• nginx-conf.d: Similar to httpd-conf.d, but for the Nginx web server.
• postgresql.d: Contains configuration files for the PostgreSQL database server.
• yum.repos.d: Contains repository configuration files for the DNF package manager. Each file in this directory defines a repository from which DNF can install packages. This modular approach allows for easy addition, removal, and management of software repositories.
• apt/sources.list.d: For Debian-based systems using APT, the /etc/apt/sources.list.d directory serves a similar purpose to yum.repos.d. It contains individual files that specify additional software repositories. This allows for modular management of repository configurations, making it easier to add or remove repositories without modifying the main /etc/apt/sources.list file

Example Scenario: Hosting Multiple Websites with Apache​

Let's say you're using the Apache web server to host two websites: example1.com and example2.com. You can create separate configuration files for each site within the httpd-conf.d directory.

Benefits of Multiple Configuration Files​

1. Isolation of Configurations:
   • Each website can have its own configuration file, such as example1.conf and example2.conf. This isolation ensures that changes to one site's configuration do not affect the other site.
2. Ease of Management:
   • Managing configurations becomes easier when each site has its own file. You can quickly locate and edit the configuration for a specific site without sifting through a large, monolithic configuration file.
3. Custom Settings:
   • Different websites might have different requirements. For instance, example1.com might need specific rewrite rules, while example2.com might require custom error pages. Separate configuration files allow you to tailor settings for each site.
4. Simplified Troubleshooting:
   • When issues arise, having separate configuration files helps in pinpointing the problem. You can test and debug configurations for one site without disrupting the others.
5. Modular Updates:
   • If you need to update the configuration for one site, you can do so without risking unintended changes to other sites. This modularity is particularly useful during deployments and maintenance.

Example Configuration Files​

Here are simplified examples of what the configuration files might look like:

example1.conf​

<VirtualHost *:80>
ServerName example1.com
DocumentRoot /var/www/example1
<Directory /var/www/example1>
AllowOverride All
Require all granted
</Directory>
ErrorLog ${APACHE_LOG_DIR}/example1_error.log
CustomLog ${APACHE_LOG_DIR}/example1_access.log combined
</VirtualHost>

example2.conf​

<VirtualHost *:80>
ServerName example2.com
DocumentRoot /var/www/example2
<Directory /var/www/example2>
AllowOverride None
Require all granted
</Directory>
ErrorLog ${APACHE_LOG_DIR}/example2_error.log
CustomLog ${APACHE_LOG_DIR}/example2_access.log combined
</VirtualHost>

Conclusion​

The use of .d directories in /etc is a powerful and flexible way to manage system configurations in Linux. By modularizing configurations, these directories make it easier to maintain, update, and troubleshoot system settings. Whether you're managing log rotations, web server configurations, or database settings, understanding and utilizing .d directories can greatly enhance your system administration skills.

Additionally, using separate configuration files for different websites allows for better organization, easier management, and more robust configurations. This approach is widely used in web hosting environments to ensure that each site operates smoothly and independently.

 

[MikeWalsh]

@dos2unix :-

'Kay, I'll "bite". So; where does init.d fit into all this? We often use this in Puppy for 'startup' apps we want to fire up automatically at boot.....


Mike.

 

[dos2unix]

This isn't really a sysVinit, busyBox init or systemd init thing.

This is more of a "I want to have two or more different configurations" for some thing.

I don't know about puppy, but in many distro's, you used to have a /etc/httpd/httpd.conf file.
You would put all of your configurations for all your websites in this one file. If you made a mistake for one site.
All the sites were down until you fixed it.

Now, many distro's have a /etc/httpd/httpd.conf.d directory. I can creates a website1.conf and a website2.conf and
a website3.conf and so on, they can all have different configurations, and if I mess one of these files up, the other two
will still function.

Maybe a better example would be, I have two user groups on my computer. One is general users group, but the
other group is developers group. They might have a different shell, or a different default path, or something else.
In my /etc/profile.d directory, instead of having one profile.conf, I can have different conf files for different users, or different groups.

It's not really a startup thing. But I know it's a little confusing because of the .d thing. It sounds like it's systemd related, but it really isn't.

 

[dos2unix]

Understanding the Difference Between init.d and .d Directories​

In Linux, the /etc directory contains various subdirectories that serve different purposes. Two common types of directories you'll encounter are init.d directories and .d directories (like profile.d, httpd-conf.d, etc.). While they might seem similar at first glance, they serve distinct functions.

init.d Directories​

The init.d directory is part of the traditional System V init system. It contains scripts used to control the starting, stopping, and managing of system services (daemons) during the boot process and while the system is running. Each script in /etc/init.d corresponds to a specific service and can be used to start, stop, restart, or reload that service


For example, you might find scripts for services like Apache (apache2), MySQL (mysql), and networking (networking) in /etc/init.d. These scripts are executed at different runlevels to manage the state of the services.

.d Directories​

On the other hand, .d directories are used to modularize and manage configuration files. These directories allow configurations to be split into multiple smaller files, making it easier to manage and update settings without affecting the entire system. Examples include profile.d, httpd-conf.d, nginx-conf.d, and postgresql.d.

Each file within a .d directory typically contains configuration settings for a specific aspect of the application or service. For instance, httpd-conf.d might contain separate configuration files for different virtual hosts or modules in the Apache web server.

Key Differences​

• Purpose:
  • init.d: Contains scripts to manage the lifecycle of services (start, stop, restart).
  • .d directories: Contain configuration files to modularize and manage settings for applications and services.
• Usage:
  • init.d: Used during system boot and runtime to control services.
  • .d directories: Used to organize configuration files for easier management and updates.

Example: Using init.d and .d Directories​

Let's consider an example to illustrate the difference:

• /etc/init.d/apache2: This script can be used to start, stop, or restart the Apache web server. For example, running /etc/init.d/apache2 start will start the Apache service.
• /etc/httpd-conf.d/example1.conf: This configuration file might contain settings for a specific virtual host in Apache. It is included in the main Apache configuration and helps manage settings for example1.com without modifying the main configuration file.

Conclusion​

While both init.d and .d directories are important for managing Linux systems, they serve different purposes. init.d directories are used for service management, while .d directories are used for modularizing and managing configuration files. Understanding this distinction can help you better manage and troubleshoot your Linux system.

 

[MikeWalsh]

@dos2unix :-

Thanks for the clarification. I was pretty sure that was the case. Puppy uses something of a mish-mash of protocols, but I know there are a few other smaller distros that still use SysVinit. I thought clarification on this point might be useful for others, too.

Due to her single-user, hobbyist nature, Puppy probably never will move fully to systemd, although we make use of certain bits as & when it's deemed necessary.

Cheers!


Mike.

 

[dos2unix]

One of the most common places people use a .d folder is for their repo files.

For rpm based systems.
/etc/yum.repos.d

For apt based systems.
/etc/apt/sources.list.d/

These come with the standard repo files from the distro vendor ( ubuntu, fedora, redhat, debian, etc... )
But what if I want to download something that doesn't come from the vendor?

There are other ways to do this. You can use curl, wget, ftp, or even download a package from a webpage.
But more often than not we add a repo file to our repos.d directory.

a microsoft.repo for ms edge or visual-studio
a docker.repo for... well, docker
a google.repo for chrome
a spotify.repo for spotify media files.
an rpm-fusion.repo or epel.repo for misc addition programs that aren't included from the distro vendor.

... etc.

@MikeWalsh
Which now that this comes up, does Puppy have a concept of repo files?
How does puppy handle this?

Ahhh- I did just find this. - https://forum.puppylinux.com/viewtopic.php?t=104