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).
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/
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."
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.
If I make such changes in several programs (without running
SuSEconfig) and then run SuSEconfig much later, does it make
When you run it it will do whatever it needs to do, so any pending
updates would be done then.
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).
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
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.
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).