More Linuxconf Stuff
Manoj, this should answer a lot of your questions. Well, also, now that
we said we can include Linuxconf, can we start figuring out what Links we
will make for it to hook into.
Shaya
---------- Forwarded message ----------
Date: Sun, 23 Feb 1997 21:28:28 -0500 (EST)
From: Jacques Gelinas <jack@solucorp.qc.ca>
To: Shaya Potter <spotter@itd.nrl.navy.mil>
Subject: Re: The Debian guy again.
On Sun, 23 Feb 1997, Shaya Potter wrote:
>
> Well, I have gotten an agreement with the other develoeprs that we will
> include support for Linuxconf, but it won't be the default, at least for
> now. The way the Linuxconf dropins will be generated is what I described
> already. The same "database" file will also be used for people who are
> using SysV init. In debian we have our /etc/init.d scripts which are the
> daemons wrapped in a start-stop daemon. These are the files we will have
> the dropins call. Their is a standard interface to them,
> start/stop/restart (maybe reload, don't remember). They also keep track of
> the pid file, so we won't need Linuxconf to do that, (or will this break
> anything). It might be appropriate to include this start-stop daemon in
> Linuxconf, and show users how to wrap programs in it. This will porvide a
> little protection, i.e. some programs include switched to kill themselves,
> but these switches arn't always perfectly implemented with the start-stop
> daemon, this isn't a problem. It's not really a daemon, but I think that's
> what we call it.
Different things
-Finding a package/daemon PID for linuxconf is important.
-PID file are optionnal for linuxconf. It knows how to find process PID in
/proc.
-If a process creates many child (httpd, sendmail), the lack of PID file
may confuse linuxconf.
-The path of the different config files must be supplied in the dropin
-The process start date is used to decided if the package most be
restarted or not. This date is compared with the date of config file
to decide.
-If the PID file is provided, linuxconf knows which process to track.
-If there is no PID file, linuxconf use the process name (supplied in the
dropin) to track the PID
-If the dropin does no supply a process name, linuxconf extract this from
the start command
-For sure, if a stop procedure is supplied, linuxconf is using it, but the
PID is still useful to trigger start/stop/restart of a package
In the case of Debian and its init script, a process name should be
supplied unless the name of the init script is the same as the main
process.
Sometime, a package (nfs for example) start several daemons. The package
is named say nfs and is started with "/etc/init.d/nfs start". The process
name would be rpc.nfsd so linuxconf knows how to locate the pid (Linuxconf
has already internal rules to start NFS anyway).
As you see, if the init script of debian do contain methods to
start/stop/restart, then there is no problem entering this information in
the dropin.
> I am including a message on what developers want, do you think this is
> possible
>
> >Hi,
> > Ok. I would find Linuxconf acceptable if:
> > 1) linuxconf is optional
> > 2) It coexists with current init methods
Currently, linuxconf installation update the /etc/init.d/boot script. If
you add at the end if it simply
if [ -x /sbin/askrunlevel ] ; then
/sbin/askrunlevel
fi
the same script will be useful for both linuxconf and the same kind of
strategy can be used in the script activating one runlevel, avoiding the
modification of /etc/inittab. The script would look like
if [ -x /bin/netconf ] ; then
/bin/netconf --update
else
the normal stuff to activate a specific runlevel
fi
> > 3) The process is reversible, i.e., it is just as easy to remove
> > LinuxConf as it is to install it, without hosing the system
This is possible, except for some feature rather unique to linuxconf. For
example, linuxconf knows how to generate sendmail.cf which is behond any
configuration utilities in any OS. The same is true for IP alias
management and few others. For sure, you can reboot safely, but
features but some features won't activate.
> > 4) We don't scrap init in favourof the LinuxConf activator
linuxconf does not replace /sbin/init
> > Reason:Allowing one to choose activators at will requires a far
> > stricter auditing - we'll have to not only make sure that both
> > activators were working, but that one may switch back and forth
> > at will. Our bug list is long enough without adding this added
> > complexity. If the Linuxconf is that much better, move to it,
> > and junk init (it would have to be seriously better).
linuxconf does not replace init. This person has no idea what is
linuxconf. It is a seriously better. Have you ever boot with a broken
configuration. One customer once called me because his computer was
freezing at boot time. It turned out that he had specified an improper DNS
in his /etc/resolv.conf. The result was that all packages, from NFS to
sendmail were timing out trying to reach the bogus DNS. Further, the
packages were timing out one request at a time. This means that the
machine would have taken several minutes to boot. This person really
tought that linux had crashed.
He was not using linuxconf, but a nice bunch of scripts!
With linuxconf, he would have gotten a message that one daemon did not
complete its initialisation in less than 6 seconds. At this point, he
would have had the following choices (even with a help button)
- Don't wait for this process to complete
- Kill it and continue
- Continue to wait
- Enter directly linuxconf configuration.
The last option is unheard on ANY os. You can change the configuration
right on the spot, fully interactivly. From this, this person would have
known
-which package is blocking
-The computer is not crashed since linuxconf is
operationnal.
He then could have investigate different things and potentially fixed the
resolv.conf things. In fact, for the resolv.conf thing, linuxconf has a
special DNS connectivity test, so the message would have been loud and
clear that his computer could not reach the DNS and that was a bad thing.
(there is even an option in linuxconf, straight in the resolv.conf dialog,
to tell it not to test for DNS connectivity).
Now the nice things, is that after doing different configuration changes
(not just resolv.conf) he would have exited linuxconf configuration and
linuxconf would have resumed the boot process, potentially,
doing/undoing/redoing whatever has to be done to make this boot process
fully successful.
This is called "quality". No way a bunch of script executed sequentially
can even scratch the surface of this stuff.
The activator of linuxconf is what makes it really shine (even if it can
configure things no other package currently even attempt, from sendmail to
DNS and UUCP and DHCP).
I am consultant and do many linux configuration on the road, quite often
right next to another consultant who is doing NT
installation/administration. They are all surprised that I can change so
many things without ever rebooting and without entering criptic commands.
In fact, they understand that they TOO can do it.
btw, on the last job I did this week, I install a uucp mail gateway and
the mail server was a NT. I told the NT person that I had setup a DNS
(took me less than a minutes) providing full name to IP and IP to name for
the organisation. I told the NT person that it would be good if he could
point the NT server to my DNS. He told me it was a good idea but did not
do it!!! You know why
-He would have to reboot the computer even for such a simple
change and it was 3 in the afternoon, so he decide to do it
at another time.
Now the standard Linux is no better. Sure enough you can change
/etc/resolv.conf by hand or using any config tool and you don't have to
reboot to make this effective. Well you don't or do you ?
This is the problem, while you can do the change, you have no idea what
is the impact of it. This is very important. Linuxconf takes care of this
so you can safely administered the machine. Without linuxconf, you are
better to reboot unless you really know what you are doing. People
generally reboot uselessly!
Yes, I think it is seriously better and will continue to do more and more
test to make it better and better. You can pass this reply to other
people. I know that the activator stuff of linuxconf is bugging a lot of
poeple, until they start to really administered with it.
> > 5) LinuxConf uses /etc/init.d scripts where available
Yes, dropin may use the script in /etc/init.d as a start/stop/restart
procedure.
> > 6) We should not have to modify dpkg (hah!) or seriously modify
> > packaging policy.
I don't think so. Mostly, for each package, do provide another file which
will be droped in /etc/linuxconf/control in the same way to drop a new
file in /etc/init.d
> > 7) a config tool should be *only* a config tool.(IMHO)
One important thing and overlooked feature of linuxconf is that linuxconf
is not just a fancy boot monitor. In fact, there is no such a procedure in
linuxconf which says "Ok, we have finished /etc/init.d/boot, could you
proceed for the rest of the boot".
Linuxconf goes much further than that. In linuxconf, you select an
operation mode. Then, any time, you can tell linuxconf "make sure that
this is what am I getting". At the end of /etc/init.d/boot, init is
calling a script which calls "/bin/netconf --update" which makes sure the
target mode is reached. /bin/netconf --update may be called anytime while
the system is running and will do absolutly nothing, unless the system has
been reconfigure (by hand or by linuxconf) and linuxconf did not had the
chance to activate the needed changes.
Anytime you leave linuxconf, it will probe the system and make sure the
packages which need to run, do run and the package which should not run do
not run. While this looks a little bit like sysv init script, this is
fairly different, because linuxconf not only make sure a package run, but
also make sure it run with the current configuration file. This means that
linuxconf does that kind of check
-compare the date of daemons with the date of executable file
-compare the status of certain kernel information with the intent
configuration. This includes
-static routing
-IPX config
-IP alias
-Firewalling
-host name
-nis domain
-rarp table
-options of the mounted volumes
-configuration of the network devices
Linuxconf knows how to do and undo thoses things. No reboot
needed.
As you can see, the concept of activator is a wonderful things which avoid
costly error (change a config, and forgot the restart whatever has to be
restarted).
> > I'm not sure whether this can be done, and whether it would
> > still be worth considering. If this can be done, go ahead and package
> > it. If this can't be done, or requires major reworking of dpkg or our
> > package built methods, IMHO we have more pressing things to do at
> > the time (like fixing dselect and whittling down bug lists) than for
> > a enhncement of something that is not broken.
> >
> > Question: ``Linuxconf has its central config file and that only
> > contains the data that there is no standard place to put.''
> >
> > Can one configure what Linuxconf is data that has a standard
> > place? (/etc/news/organization contains the organization string on
> > Debian systems. but may well be considered non-standard as far as
> > unices are considered.
Linuxconf knows about standard config file associated with known package.
For example, nfsd use /etc/exports and linuxconf is aware of the syntax
of /etc/exports and provide a nice frontend to it.
There is no standard place to store static route information. Linuxconf
store that in /etc/conf.routes. There is no standard place either to store
the requested IP aliases need. Linuxconf stores that in
/etc/conf.linuxconf which is some sort of ascii database (using the same
format as a dropin).
The format of /etc/conf.linuxconf is trivial and it would be possible to
extract some configuration and translate it to /etc/conf.linuxconf
format. /etc/conf.linuxconf contains informations which has no counterpart
to most unix systems. For example, when an ISP want to setup say 50
virtual domains, it goes into some script and enter a bunch of
ifconfig eth0:0 domain_name
route add ...
ifconfig eth0:1 other_domain_name
While in linuxconf, he will simply enumarated the domain in the IP alias
dialog box of the proper network device. While this sounds equivalent,
this will be until the ISP read the help of this dialog. Then instead of
entering all these names here and then in the DNS, he will just enter
x.y.z.10-60
and linuxconf will create the 50 (51 indeed) aliases. Then he will go in
he DNS configurator and define an "IP range for virtual www". Then each
time he adds a new virtual www, he goes in the DNS configurator, add the
domain and add the www.domain host and let linuxconf compute the first
available IP number in the "IP range for virtual www".
> Well, this should cover as much as I know for now. The implentation of the
> database file has not been discused yet, so I/you can't start packaging
> Linuxconf for debian yet, but hopefully soon.
If I can be of any help. I just hope you are not alone using linuxconf in
the Debian team. Unless on has played with linuxconf, he can't figure out
how sophisticated it is.
There are many other things I should have mention (full logging of all
command generated and their output, classified by activation date).
Anyway. Keep me posted!
----------------------------------------------------------
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 Bruce@Pixar.com
Reply to: