A technology company you might have heard of named Microsoft once had an operating system and a suite of applications that maintained most system and configuration information in text files - they called them "INI" files. There were little INI files everywhere as well as a few quite large INI files. A few included nice documentation as to what that part of the file meant and was for - at least until that documentation got deleted (it would let you do that, they were just text files after all). Microsoft realized what a mess that was and how difficult it was to manage more than a few machines when changing something meant editing all those files over and over again - and how easy it was to screw them up. So they came up with the idea of a "registry"; the registry was a hierarchical key-value data store [nothing wrong with that] with an API that could be used to query and change values. It would have been great. Except the implementation was terrible. The registry was this binary wad that became useless if something went wrong. And the tools to manage it were of "
Why does the registry matter when discussing UNIX/LINUX system administration? It matters because it is important to understand the distinction between a concept and an implementation. There is simply nothing wrong with the concept of the registry. There was a problem and the registry was a solution. But the implementation was bad - the implementation added a whole bunch of new problems. It is relevant because every time someone tries to discuss the same problem facing UNIX/LINUX administrator's still have - legions of unverifiable and mostly undocumented text files - they will get the story of the Microsoft registry thrown in their face. But - concept vs. implementation - that argument against how most UNIX/LINUX administration works is complete fallacious. The fact remains that editing or patching configuration files is a dangerous business as likely to break things as to improve them.
At least now many of the configuration files are gathered together in /etc/sysconfig. Much of a system's basic configuration - such as the display manager, network configuration, etc... - can be managed by changing stuff in /etc/sysconfig. That is an improvement. But automating changes is still a business of tweaking text files.
Fortunately uses of SuSE and openSUSE have an escape route. One of the best features of openSUSE is YaST - YaST is "Yet another Setup Tool" with the important distinction that it (a) works, (b) is comprehensive, and (c) does not degrade your system's security. YaST has an excellent tool for editing all the common /etc/sysconfig relating things. YaST will run on the console [TUI], on your desktop [GUI], or you can access it via your browser [HTTP]. All well and good - but if you need to automate/script setting up a host ... All the aforementioned stuff still requires interacting with a user interface; it still is not as beautiful as an API.
... or maybe ....
$ sudo /sbin/yast2 sysconfig list all
Huh, would you look that that. There are all the documented /etc/sysconfig related directives. I just dumped them to standard out using a tool. I wonder if I can see the current value of a given directive and the related documentation?
$ sudo /sbin/yast2 sysconfig details variable=DISPLAYMANAGER_AD_INTEGRATION
Possible Values: yes,no
Default Value: no
Display a combobox for Active Directory domains.
Nice! And if I want to change the value?
$ sudo /sbin/yast2 sysconfig set variable=DISPLAYMANAGER_AD_INTEGRATION value=yes
Setting variable 'DISPLAYMANAGER_AD_INTEGRATION' to 'yes': Success
Shucks, that is almost as good as an API! So I can dump for backup or reference my current /etc/sysconfig related configuration to a single document? Yes. I can query a setting's value? Yes [without using grep and a regular expression!]. And I can change a setting without using vim? Yes. openSUSE users have yet another reason to be smug while users of other distributions do battle with vim? Yes.
What was by original though? Ah, of course: having to edit text files as the primary means of systems administration is failure. Fortunately we have YaST, and our lives now include less failure and more tool-based automation [aka "success"].