Are you using *.d/99-example for your configurations (or the "legacy" way)?
Such as /etc/security/limits.d/99-vdsm.conf (as opposed to simply updating /etc/security/limits.conf
Has your team adopted the newer strategy, or are you still holding out on managing a single configuration file?
Responses
Guru
6222 points
Hi James,
Being unaware of this change, I still use the legacy approach.
What do you do yourself?
Kind regards,
Jan Gerrit
Guru
6863 points
I'm "in transition" at this point. Trying to move towards the *.d/XX-env approach. I like the idea (a lot) and actually stumbled upon it while troubleshooting an issue (and I wonder how many folks actually know this exists):
# cat 90-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
* soft nproc 1024
root soft nproc unlimited
I also found the *.d approach while researching some best practices for running an Enterprise DB on RHEL 6.
I am awaiting the day where I suddenly realize that I did not have enough foresight to avoid an issue, but I just don't know what issues might arise from using *.d
Guru
6435 points
Three biggest:
1) Configurations that are sensitive to the order that directives are processed
2) Depending just how many files and how some applications handle reading things in, you may run out of filehandles (not generally a problem on newer systems, but still something to be cognizant of)
3) Friction caused between people who absolutely expect a configuration directive to be in a given monolithic file and can't cope with stuff being broken out (usual suspects being the less-qualified IA guys).
Guru
6435 points
Not sure you can really call using configuration subdirs as a "new" way of doing things. I mean, I've been using include-via-directory in various products that have supported it for a decade and a half, now (when you're running hundreds of Apache NameVirtualHosts on a single system, its' the only to maintain your sanity).
I'm trying to get the organization I'm currently working for to do /etc/sudoers.d per-user and per-group include files ...mostly because I've a touch of the OCD and making the whitespace line up isn't exactly a concern in a single directive per file.
Maintainining included and blacklisted modules via individual files makes things a lot more self-documenting "hey, everything in the /etc/modprobe.d/USB file is related to the USB subsystems" ...similar for udevd.
Only real problem I've encountered with this method of doing things is when directives are order-sensitive. Then you have to contort the filenames to ensure proper directive processing-order. Worse, you have to ensure that those who follow behind you understand what you've done and why such filename-torture became necessary.
Oh... And depending on your security folks, not using the monolithic configurations is a great way to end up with your blood boiling:
IA: My script says this lockdown is missing...
Me: The lockdown is present, it's just not where your script is looking
IA: But my script says this lockdown is missing
(muffled sounds of an IA guy being strangled).
Using 'Newer' if you want to call it that :)
I have used X.d directories as soon as they are made available for different services (I wish sshd would get this feature.. what are people doing for user specific config in sshd?, I am currently using augeas for this edge case).
I see benefit in rpm packaging of config (for SOE) using X.d as the rpm can validate the file (ie. it's not in rpm scripts). More recently I am using it with Puppet. In Puppet, using a monolithic configuration file really limits you to using augeas if you want to do it well, but augeas has quirks of its own that you need to get used to (config blocks come to mind). With X.d directories + Puppet templates configuration deployment is extremely straightforward.
As above I am using it for sudoers for group/user specific access so admins can quickly determine the additional privileges that have been made available to users/groups by looking in /etc/sudoers.d. Have been caught with sudoers and ordering, but some reshuffling of filenames resolved it.
Also hit issue 3 raised above by Tom Jones. Some security scanning tool authors seem adamant that security config must exist in the .conf monolithic file, in these cases I have generally moved the one or two items required for the check back into the .conf file (reluctantly).
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.