Linux Distributions

[mikebw at bilow.bilow.uu.ids.net (Mike Bilow)]

Jerry Feldman wrote in a message to Mike Bilow:

 JF> One Debian question. Is there a tools analogous to the Red Hat 
 JF> Control Panel.

Not to my knowledge, but something like that could be available.

 JF> While I generally do most of the system admin things by hand,  
 JF> such as host names, ip address, adding something to multiple 
 JF> run levels  is a bit of a pain by hand. For example, I needed 
 JF> to add NFS to my  Alpha since I now need to have Linux on my 
 JF> Intel box. The procedure  was to rm the Knnnfs and Knnnfsfs 
 JF> links in run levels 2-5 and add Snn  links. While the procedure 
 JF> was easy, I messed them up (ln -s ../inetd/nfs  S20nfs and ln 
 JF> -s ../inet.d/nfs S99nfsfs). With the run level editor, this is  
 JF> not as error prone. You can see that in the first entry I left 
 JF> out the dot and  the second, I linked to the wrong script. 
 JF> System admin tools to not  preemt the old way, but they can 
 JF> prevent dumb errors which can be  difficult to track down.

Debian packages can vary in configuration quality.  Each package can have a
configuration tool of its own, usually shell or Perl scripts, and this is run
by the package manager.  It can also be invoked manually with command line
switches on "dpkg."  However, it is up to each package to handle these kinds of
installation issues, creating links, and so forth.  Only the package can be
expected to know the names of its own binaries, for example.

There are a number of configuration issues which are just too advanced for
automated tools to perform without a lot of effort.  For example, creating
virtual addresses on a multihomed network interface, usually motivated by a
need to do virtual web hosting with Apache, is hard to do without rebooting.

 JF> Purists would say, if you are going to do system  admin, you 
 JF> should know what you are doing, but the addition of these tools 
 JF> tend to make Linux easier to install and maintain, so that more 
 JF> non- Unix people can use it more effectively. 

The problem is that there is an inherent trade-off, especially with something
as system-specific as run levels.  Technically, administrators can define the
run levels with any semantics they choose, but the distribution has certain
defaults and these tend to be the same across all distributions.  If packages
can modify the semantics of system run levels, then it forces the administrator
to adhere to the official definitions.  Debian is not quite as rigid in this
respect as Red Hat, but they both have to be pretty rigid in order to avoid
breaking major packages such as X/Windows.
 
-- Mike


***
Subcription/unsubscription/info requests: send e-mail with subject of
"subscribe", "unsubscribe", or "info" to discuss-request at blu.org