HomeBanner

SuSEConfig: Behind the scenes

Understanding how SuSEconfig works

This section tries to explain the purpose of SuSEconfig, what it does, why one needs to run it, when it should be run and what happens if you don't run it

1. I'm confused over the purpose of the SuSEconfig program. What does it do?
2. Why do I have to run it? When do I have to run it? What happens if I don't run it?
3. I've read the scripting for the program and can see that, after setting a bunch of variables and checking this and that, it runs a series of configuration files /sbin/conf.d/SuSEconfig.*. But why is this necessary?
4. If I change an application configuration file (e.g. httpd.conf or my.cnf), without running SuSEconfig, do I screw up my system?
5. If I make such changes in several programs (without running SuSEconfig) and then run SuSEconfig much later, does it make everything OK?
6. If I install a new program, using config, make, make install, (not a RPM), does SuSEconfig recognize anything about that new application? Does the use of SuSEconfig depend at all on using RPM's?
7. I've read the manuals that came with SuSE 8.1 and they only go a limited way in answering my questions.
8. I thought the individual programs had configuration files that were independent of other applications and that one could reliably configure any one of them (e.g. apache or mysql) without having to worry about messing up other programs or the system. However, this does not really seem to be the case. - Or is it?
9. I'm trying to learn SuSE (and Linux in general) entirely on my own and am having a devil of a time, figuring it out. Could someone give me a professional's view of this and help me understand what I should and should not do in configuring my system?
1.

I'm confused over the purpose of the SuSEconfig program. What does it do?

It takes config options from lots of files and process them, often converting them into another file format usable by specific apps (for example, it configures the menus for several window managers based on what apps you have installed).

2.

Why do I have to run it? When do I have to run it? What happens if I don't run it?

That depends largely on the situation. In pre-8.0 you need to run it after editing /etc/rc.config. In 8.x that file becomes absolete, and SuSEConfig uses the data from /etc/sysconfig/

3.

I've read the scripting for the program and can see that, after setting a bunch of variables and checking this and that, it runs a series of configuration files /sbin/conf.d/SuSEconfig.*. But why is this necessary?

Setting up menus for your windowmanager, for example. Unfortunately, SC does about 20x more than you normally need it to on any given run, and is way overkill in most cases. After installing software with yast, SC will run it's whole shebang, even though you just installed one application which has no effect on anything relating to SC. The reason for this is that SC cannot know what is (however indirectly) related to anything else, and it must therefore assume that it should be run "just in case."

4.

If I change an application configuration file (e.g. httpd.conf or my.cnf), without running SuSEconfig, do I screw up my system?

What normally happens is SuSEconfig detects that you have edited the config file yourself, and says ok, a power user, I won't touch the config file then, I'll just tell the user I made a version which she may choose to use.

5.

If I make such changes in several programs (without running SuSEconfig) and then run SuSEconfig much later, does it make everything OK?

When you run it it will do whatever it needs to do, so any pending updates would be done then.

6.

If I install a new program, using config, make, make install, (not a RPM), does SuSEconfig recognize anything about that new application? Does the use of SuSEconfig depend at all on using RPM's?

You do not need to run SC after make/make install because building software that way is completely independent of the Linux flavor you use, and completely independent of your RPM database. i tend to install all of my software from source tarballs (unless it's on the Suse CD or updated by YOU), but this is not something your average user should do, as most users want their RPM db to reflect what's on the system (and me, i don't give a damn what my RPM db says).

7.

I've read the manuals that came with SuSE 8.1 and they only go a limited way in answering my questions.

SC has fallen more into the background since 8.0

8.

I thought the individual programs had configuration files that were independent of other applications and that one could reliably configure any one of them (e.g. apache or mysql) without having to worry about messing up other programs or the system. However, this does not really seem to be the case. - Or is it?

Looking at it another way, SuSEconfig attempts to put a simplifying layer on top of the config files of various applications.

9.

I'm trying to learn SuSE (and Linux in general) entirely on my own and am having a devil of a time, figuring it out. Could someone give me a professional's view of this and help me understand what I should and should not do in configuring my system?

If you stick to using YaST to configure you will be ok. If you edit /etc/sysconfig/* manually and run SuSEconfig afterwards, you're ok too. If you are a power user who knows what to do to config files, you'll be ok naturally. It's only when you mix and don't understand the result you got, that's when you are in trouble.

In such an advanced system as Unix i think there is no simple answer for this. Changing the One Wrong Thing, whether related to SC or not, can potentially hose your system (normally in the sense that it won't boot properly, only Very Rarely in the sense that you lose data). i've never heard of a case of someone rendering their system unusable by changing any settings which SC processes, however (that doesn't mean it hasn't happened - i'm just not aware of it).


Updated: Tue, 03 Feb 2004
Valid CSS!Valid HTML 4.01!