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 <[EMAIL PROTECTED]> To: Shaya Potter <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] 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. [EMAIL PROTECTED] [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .