FAQ and call for help: Linuxconf and Debian
Hi!
I'm getting a lot of mails full of questions about my Linuxconf Debian
package so I've put together a little FAQ (attached).
I also want to further intergate Linuxconf into Debian but this requires
a lot of work. If you want to help me with this please contact me.
If you want to reply to this mail please choose the right mailing list. For
general Linuxconf questions please use linuxconf@xc.org, for Debian specific
issues please use debian-admintool@lists.debian.org.
--
Stefan Gybas
1. What is Linuxconf?
Linuxconf is a program for Linux systems with three major functions:
(a) configuration utility
With Linuxconf you can do basic and advanced system administration
and configuration. Linuxconf has some core functionality (like
creating and managing users, groups and file systems) and several
modules for other system components, e.g. bind, apache, sendmail,
samba and squid. Currently there are over 20 modules available.
The configuration is done using a GUI with lot of help texts that can
either use a text, X11 or web interface.
Linuxconf does not use a database to store the configuration, instead
it just uses the normal system configuration files like /etc/fstab,
/etc/hosts - while trying very hard to preserve their structure (like
manually added comments). So you can always switch between a text
editor and Linuxconf.
(b) configuration activator and manager
Linuxconf can keep track of changes made to configuration files
(either using Linuxconf itself of some text editor) and then update
the system to reflect those changes. An example might be
vi /etc/inetd.conf
vi /etc/apache/httpd.conf
linuxconf --update # This will cause inetd and apache to
# reload their configuration files
Another feature is the ability to archive and restore configuration
files (using RCS if available):
linuxconf --archive
linuxconf --diff
linuxconf --extract
(c) boot selector
The third main feature of Linuxconf is called askrunlevel and
this is exactly what it does. It shows a little menu during boot up
where you can select the system runlevel and the profile.
A profile is a name for an archived configuration (see section b)
like "office" or "home", so you can e.g. have different IP addresses
or XFree configurations with your laptop depending on your location.
Each of these features can be turned on or off independently, that means
you don't need to activate the boot selector if you just want to do some
Samba configuration. And you can always De-install the Linuxconf package
and everything is as it was before.
2. Where can I get the Linuxconf Debian package?
I've split up Linuxconf into four seperate Debian packages:
linuxconf The main Linuxconf binary (text and web interface
only, with all modules)
linuxconf-x The X11 GUI for Linuxconf (this is in a sperate
package so the main package does not depend on
xlib6g, wxxt1 and xpm4g)
linuxconf-locale The foreign language files (all except English)
linuxconf-boot The boot selector (see 1c) - if you don't want to
enable this features, simply don't install this
package and Linuxconf will not make any grave
modifications to your system.
All packages are in the "experimental" distribution - available on
all Debian mirrors in project/experimental/. They can be installed
on a Debian 2.1 (slink) system but require a newer netbase package.
3. What is working on Debian GNU/Linux? And what is not?
All of the configuration stuff (see 1a) except network configuration is
working on Debian. The configuration activator (1b) and boot selector (1c)
are partly working (see question 4).
4. What needs to be done in order to make the other features work?
The problem with network configuration is that this is done differently
on each Linux distribution and thus Linuxconf does not know where to store
the host name, IP addresses and routing table. So distribution specific
modules were written to handle this part, but unfortunately there is none
available for Debian yet.
For the configuration activator, Linuxconf needs to know which config file
belongs to which service/daemon and how to make this daemon reload its
configuration. Again, this is distribution specific but Linuxconf has
a little bit basic knowledge here, e.g. it knows that inetd uses
/etc/inetd.conf and can be restarted using "kill -HUP".
But as you might probably know, Debian uses SysV init scripts in
/etc/init.d/ that can also make a daemon reload its configuration, like
in "/etc/init.d/proftpd reload". So it would be a good idea to tell
Linuxconf which init script starts which daemon(s) and which config file(s)
they are using. This is done using some special tags in those init scripts,
please read http://www.solucorp.qc.ca/linuxconf/tech/sysvenh/index.html
for details.
In recent versions of Linuxconf, those "init script tags" can also be
stored in different files, so they don't have to be in the init scripts
provided by the package maintainers, although the former would allow better
consistency (and this is the way it is done in Red Hat).
To summarize what needs to be done:
(a) Create the required tags for all possible init scripts, so Linuxconf
can use those init scripts to reload a configuration instead of using
its own built-in rules. Maybe at a later point these tags can even
be put inside the init scripts if this should become Policy.
(b) Write a Debian module to handle the network configuration. This
module would have to read in the current network configuration from
/etc/init.d/network and store the changes in this file. Unfortunately,
this file is currently very hard to parse (as it is a shell script that
can use variables and commands in any order) so this modules would
be very difficult if you want to preserve the structure of this file.
A proposal was made on Debian-devel to switch to a different network
configuration scheme using easy to parse files (see e.g.
http://www.debian.org/Lists-Archives/debian-devel-9902/msg01420.html).
I think the only way for Linuxconf (and any other configuration tool)
to handle network configuration on Debian is to use this new scheme or
the Red Hat scheme so we could simply use parts of the Linuxconf Red Hat
module.
5. What are the future plans for the Linuxconf package?
I plan to upload one of my next releases to the unstable distribution
(potato) instead of experimental. I will not include the linuxconf-boot
package (which is providing the boot selector - see 1c) in this upload
as it might cause some trouble because of the not working network
configuration. It is also not very useful in Debian because the runlevels
2 to 5 are all equal and the network configuration in done in runlevel S
so Linuxconf has no way to disable network configuration if the user
selects this option in askrunlevel.
The Red Hat modules has PAM support, so you can e.g. change a user's
password using PAM. I will copy this part into a Debian module which
I hope to create soon.
But the first step should be to create files with the tags for the
SysV init scripts (see question 4) - this can be done step by step. Once
we have tags for most init scripts, we can tell Linuxconf to forget its
built-in rules and just use the information from the tags. I'm looking
for helping hands, so if you want to help, please read
http://www.solucorp.qc.ca/linuxconf/tech/index.html (especially
http://www.solucorp.qc.ca/linuxconf/tech/sysvenh/index.html) and then
mail me if you are still interested.
The next step could be to make network configuration work, but as
explained in question 4 above, Debian would have to adopt a new
/etc/init.d/network first.
Reply to: