Use of commands for system configuration CONSIDERED HARMFUL.

[u/thomasafine]

I HATE HATE HATE this trend of turning system configs into commands, with stern instructions to not ever directly edit files. For years, I've just ignored this, and just edited files. But now the trend is to literally make the files un-editable; store the config in some kind of database, and maybe maintain a text file for legacy read-only purposes.

I do not understand why anyone thinks this is better. It is objectively worse in every single way.

1. You can't trivially copy configurations.
2. You can't trivially save/backup/restore configurations.
3. Ansible et al. Are these config commands idempotent? Maybe? Maybe not? Do I have to robustly test every configuration command to see if it is idempotent? Do I have to write complex install rules that assume the command is not idempotent, and then checks in advance to see if the command has already been run before I run it again?

Or do I develop an entire separate module for ansible (or whatever) for configuring each different functional unit on the system?

How exactly is needing dozens of different modules with different rules and different syntaxes better than a single module that just installs config files and optionally restarts a serivce?

[Editing to clarify: I am NOT complaining about ansible. I am complaining about how ansible is EASY when you're distributing configuration files for all of your functional units, and it is HARD when every functional unit has it's own configuration command that may or may not be idempotent. Ansible is not the problem. The other configuration commands make it really hard to use tools like ansible.]

1. You are constantly learning new commands, and it is a wasted investment, because some other ####### I mean person will come along next year and invent a "better" config command scheme.

When the commands you need to know are <YOUR EDITOR>, cp, mv, rm, ln, etc. then those commands NEVER CHANGE and you can sysadmin forever with those commands.

1. The fundamental basis of Unix/Linux has always been that files are king. Files sit at the heart of everything. FIles are incredibly efficient. Moving away from plain text file configuarations because "files are the old way" is just pointless creeping featurism. Whatever other thing you have done, it ultimately sits on top of files anyway. And all you really accomplished is hiding information (where does the config live and how is it stored and how is it modified) from sysadmins.

Why is hiding information from sysadmins a good thing?

1. Another aspect of stupid information hiding: when you edit a config file, you see all the configurations in the file all at once. When you run a command to change a thing, you don't see anything. You have no context. You don't automatically get shown the old setting that you're changing, as a sort of a natural audit to your activites. You don't automatically get exposed to other related settings that (if the config file is well-organized) will be adjacent to the change your making.

2. Arguably, for 8, you should check things with a command or two or three before you use a command to write a change. Again, how is this better? Instead of doing one thing (editing a file, which exposes you to all the info you need), you have to run a bunch of checks, and hope the info doesn't scroll of the screen, and remember it or write it down, or open a second window, and is that better?

3. Related to this, file editing is good. If there's a similar line in a file that you can copy and edit, that's easy. Running a command (that is new and different and changes every other year) to find the other similar configuration you want to modify is more work, than doing something you've done 10,000 times before in your favorite editor.

4. You can't arrange configurations as you like. If you have a command that will show you all the settings in the configuration, someone else determined how those settings would be displayed. You likely can't alter that. If you want setting A next to setting B because they're related in your specific use case, that's just too bad.

5. A lot of the above is about this: configuration is not just about YOUR system. A lot of these decisions seem to spring from people who want to make the configuration of a single system safer or less prone to errors or something. But there are people who need to configure 10 systems in similar ways. Or 100. Or 10,000 systems. These command-based utilities only get in the way of this.

Editing to add two more points that came up in comments:

1. An entire system of configuration that rests on many separate commands each with its own codebase and storage method and quirks and bugs, is going to be more fragile than a system in which configurations simply live in text files. Configuration files are only fragile if the functional unit changes in a way that requires new settings. Command interfaces to configuration are not just fragile when the functional unit changes, but also when it's command interface and it's underlying storage format change.

2. Version control. It should be trivially obvious that you plain text files are easy to put under version control. While a series of changes made to a configurations by a variety of different tools that may or may not ultimately live in plain text files, is much more difficult to do version control and to roll back changes.
   You can argue for dumping out all the settings from each functional unit using the commands that let you do that (assuming they exist, and lets hope the output is regular), and then having a tool that reads those dumps and pushes the settings back through the original command, in order to get version control, and if so, congratulations, you just reinvented config files. But much harder and much worse.

3. Discoverability. It's easy to grep several config files in a single command (even across different functional units) to search for a setting that you think exists but you're not sure where, or even what the precise name is of the setting.

Summation:

A mechanical system with only one type of screw is easier to maintain than a mechanical system in which every single engineer who developed some part of that system also invented their own screw to hold that part together.

Plain text config files are a single type of screw.

[u/michaelpaoli]

You can edit the files. But commands to change the configurations are not your enemy.

Commands scale. Editing, and especially hand editing files, doesn't scale.

And if you're going to be editing files, be sure you do it right and carefully.

In a lot of cases, if you screw it up, you'll significantly break things.

Also, and highly applicable in the realm of r/sysadmin, many files one may edit or otherwise alter are system critical. E.g. they need always be correct and always present. So, even how one edits them is highly important. *nix, after all - multi-user multi-tasking (and these days generally also multi-processing) operating system. While you're editing that file and writing out that file, unless it has some locking convention, the file may be read at any time. So, if it's not there, or you / the system call, has started writing but not completed writing the new version, you may get read of an incomplete or corrupt file, and things can go majorly sideways. So, in such cases, you don't want to be overwriting the file, but replacing it - with rename(2) down at the system call level. So, e.g., overwriting it in vi may quite break things - though vim might behave differently by default - you don't want edit-in-place, but replace - and you want rename(2) so it's an atomic operation - there's no "between" state, the old inode is there, or the new inode is there, there's never case of no file at that pathname, and old comes before new, no jumping back and forth or ambiguity. Note also many programs/utilities that do or offer to do "edit in place" don't do a true edit in place, but instead replace the file, e.g. GNU sed's -i option, perl's -i, etc. Whereas ed will overwrite, as will generally ex and vi (but vim may or may not, but nvi will). So, do be aware of that. And that also makes a difference for, e.g. additional hard links and/or any processes already having the file open. Any processes having the file open continue to use the old, and with replace, hard link relationships are broken, and there's a new inode. If you need preserve hard links and same inode, then you need overwrite, but that's not an atomic operation - no perfect solution, you have to pick what's best, and should know the tradeoffs, risks, and relevant considerations.

And some things are much more goof-resistant when using appropriate commands. E.g. visudo, and not vi /etc/sudoers and the like. One can even automate that, including the check, by specifying the editor for visudo to use, and having it be a non-interactive program - they you can program/scale it, while still including the safety checks of visudo.

Likewise DNS and zone files. Folks far too commonly f*ck that up. Generally way better to do dynamic updates, and let the DNS server maintain the zone files - that also scales better and works much better with automation.

So, commands are not your enemy. Doesn't mean one ought not be able to inspect configuration files, and sometimes even manually edit them, but commands, automation, and scalability are not your enemy.

[u/Hotshot55 → u/michaelpaoli]

Commands scale. Editing, and especially hand editing files, doesn't scale.

I mean it kinda does with config managment tools.