Re: Debian and Linuxconf (again :-) ) (fwd)
This is the message I got from the developer. If you have any comments
cc: me, as I have resubscribed to the lists yet.
Shaya
---------- Forwarded message ----------
Date: Mon, 12 May 1997 23:37:51 -0400 (EDT)
From: Jacques Gelinas <jack@solucorp.qc.ca>
To: Shaya Potter <spotter@capaccess.org>
Cc: wkulin@ikp.atm.com.pl, rickya@siservices.net
Subject: Re: Debian and Linuxconf (again :-) )
On Sat, 3 May 1997, Shaya Potter wrote:
> Since I have had a lot of time off for exams, I have been thinking about
> what whould be neccesary for Linuxconf and Debian to coexist. (and a
> method that the debian developers would go for). Is it possible, that
> some of Linuxconf's init features could be folded into SysV init. Then
> Linuxconf wouldn't have to start up applications. However, Linuxconf
> would still be able to manage the applications, because the init.d
> scripts would be written in a standard way to give Linuxconf all the
> information it needs. With a simple parsing of the
> /etc/rc{1,2,3,4,5,6}.d scripts. and /etc/init.d. Linuxconf would be
> able to tell the users what daemons are running, and to give them the
> ability to start and stop them. With a little more work, Linuxconf
> would also be able to move the links around the rc{1,2,3,4,5,6}.d tree
> and give the user many different run levels.
>
> The main advantage that I see in going in this direction would be that
> the people who are nervous about replacing init, will have all their
> fears assuaged, and Linuxconf will still run like you want it to. or am
> I missing something.
Hello Shaya
Before I start, I would like to point something. Currently, I am dealing
with two other Debian users. By far they are the most "demanding" testers.
(which is a quality btw) I am including their email address as I know
they have voiced their interest for linuxconf on Debian mailing list. It
would be good if you could exchange with them.
wkulin@ikp.atm.com.pl
rickya@siservices.net
They are also CC on this mail (hello both of you) as I feel we have
something going on here. I am writting this line before sending this
pretty long message, so read it up to the end. I hope this is
constructive.
---------------------------
I understand your idea about letting linuxconf get in more easily. There
is a major drawback with your scheme. One big issue with linuxconf is that
it is monitoring and controlling the boot process. This give a level a
quality that no bunch of scripts could emulate. To give you an example, I
suggest the following experiment.
unplug your ethernet adaptor (or give a faulty config
in /etc/conf.modules)
reboot
Do the experiment with and without linuxconf.
Then take a picture of the one without linuxconf and show that to your a
friend for a clue (for sure you know what is going on). Linuxconf will
tell you that the ethernet adaptor is not working. The scripts will be
called one after the other and produce all kind of neat result like
-long timeout
-meaningless error message
Further, there is no hierarchy in the sysV scripts. They are executed in
order, without a clue that if one does not succeed (generally the result
code of the commands is not even looked at) the next one should not even
be attempted (why setting IP alias on eth0 if there is no eth0).
While linuxconf is already providing something, it will have to be enhance
to make error condition much more useful and allow reconfiguration on the
spot available in more place (This is available only on some error
condition). The current framework of linuxconf is there to grow, while
the sysv script system is oversimple.
If you are attacking the mass market, sysv script are not the solution,
especially in a world where the idea that "unix is difficult" is a trend.
With linuxconf, we stand a fair chance of providing something that is open
and yet informative and easy (as oppposed to close and broken like w95,
but looking good: You have no idea what is going when it boots).
Think of something you want to give to a newbie.
Ok, linuxconf publicity done :-)
Now, this being said, I understand most people don't realise the benefit
of this concept for a very simple reason: Once you have a working
"workstation" setup (read simple configuration), the sysv scripts will
reliably activate it any time. If you had a service, it will be activated
also. This is only when something goes wrong that the sysv init script are
falling apart (user interface wise).
Now, to say something useful :-)
Maybe we have a strategy along what you are proposing. One key concept of
linuxconf is that it does not have a "boot" or "goto this state"
command. Linuxconf have indeed a more complex concept where it can compute
the proper path (set of commands) to bring the current state (whatever it
is) to the "configured" or "wanted" state. For example, you can do
netconf --update
netconf --update
several time. The first will do something, while the others will do
nothing since all is up to date.
Here is my proposition. Make linuxconf installation in two steps
(this is mostly what you are proposing, so forgive me if I am explaining
your own idea :-) )
step 1:
Linuxconf does not start anything. The askrunlevel utility is
nevertheless a good feature as it lets you select the
runlevel and other gadget and reconfigure before booting.
Normal sysv init scripts are run.
dropins are either supplied with each package, or
a mean is provide to "extract" a dropin from a rc script
when missing. dropin may or may not be supplied.
Once a system is booted, linuxconf has full access to the
dropins to configure (stop/restart/start) the different systems.
The control panel/service activity menu may be used to
link/unlink services from the proper rcx.d
step 2:
Install linuxconf as the startup mecanism.
This would be a check box in linuxconf.
I don't have Debian available right now but looking at the sysv init
script from RedHat, I think it is possible to have linuxconf folded in the
standard init script. Mostly, from redhat, there is a script called
/etc/rc.d/rc. This script receive a runlevel and from there, play the
proper script sets in /etc/rc.d/rc$RUNLEVEL.d/.
Imagine that the rc script looks like this
if [ -x /bin/linuxconf -a /bin/linuxconf --is_managing ]
then
/bin/netconf --update
else
...
normal processing of the sysv script
...
fi
Going into linuxconf features menu, one could switch linuxconf startup
mode on or off. On an heavily administered server (potentially customised
startup scripts) , one could install linuxconf (which default to off) and
later switch control to on if needed/recommended.
This way, no special scripts would have to be supplied for linuxconf,
since the supplied one would be linuxconf aware.
Other aspect of linuxconf would have to be adapted. For example, linuxconf
stores the host name and IP in /etc/hosts with the alias loghost. This has
many beneficial aspect (formalise the usage of the loghost alias for one)
and avoid invalid configuration in /etc/hosts which do not agree with the
config file used to configure the ethernet adaptor. Linuxconf would have
to know how to read/update the different non standard config file used by
debian (non standard mean that they are specific to debian as opposed to
/etc/exports which is a standard config file, fully documented).
The key concepts here are
-debian would supply linuxconf aware (minimal changes) rc script (the one
used on debian).
-A mecanism should be done to create dropin out of rc scripts when
missing.
There is also another "pretty cheap" alternative to the "step 2" above.
Imagine the following behavior.
-Linuxconf is aware of the script directory associated with
the current runlevel.
-it reads it. It parses the name of the different scripts. They
normally have some prefix which provide the ordering (S80nfs for
example).
-Linuxconf classify those scripts in 3 categories
a)This is a known script and linuxconf is providing internal
rules to do the same thing (start NFS server for example).
b)This is not a known script, but a dropin with the same name
exist
c)This is not a known script, no dropin available
-After this linuxconf execute the scripts one after the other with some
exceptions based on the category
a)Use its internal rules instead of the script
b)Use the dropin instead of the script
(The dropin may very well use the script as its
start/stop/restart method)
c)Use the script without knowing much (provide
the proper start argument)
Further, for the c) category, make sure that the ordering is somewhat
preserved.
This strategy will allow linuxconf to properly emulate the sysv init
scrips while providing its added value in a peace by peace strategy
instead of a whole replacement.
A recap again (this is a pretty long one)
-inittab would never be modified
-Debian could be shipped with a rc script (The one which triggers the
others in each runlevel directory) linuxconf ready
-User can switch from native sysv script startup to linuxconf monitored
one, potentially back and forth.
-Service started without dropins would not be manageable later. Linuxconf
has no clue if they should be restarted or not.
-A dropin migration mecanism could be devised allowing one to create
dropin from those unknown scripts or at least dropins could be promote
more easily to developpers.
So mostly, I am proposing the same thing or the opposite indeed as you.
The sysv scripts would be folded (intermixed) with normal linuxconf
startup processing and this would be an interactive option anyway.
This can be done. I suspect that this work is reusable for redhat also
anyway. This represent a pretty centralised work in linuxconf so is not
that difficult to implement.
Comments are welcome!
--------------------------------------------------------
Jacques Gelinas (jacques@solucorp.qc.ca)
Linuxconf: The ultimate administration system for Linux.
see http://www.solucorp.qc.ca/linuxconf
new development: linuxconf configure dhcpd since 1.9r7
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: