On Fri, 9 Oct 1998, aurelio marinho jargas - ctba wrote:
> just forwarding a message i saw bout linuxconf
The information below is not true. static-routes is fully used
on redhat-5.1 as well as all other files in /etc/sysconfig, including the
/etc/sysconfig/network-scripts/ifcfg...
It is not obvious from the scripts though. Here is how it works.
As most linuxconf users knows, linuxconf has the ability when you quit
from it (or using the "activate changes" option of the control panel) to
compute the proper course of action needed to enable the configuration
changes.
Normally, sysv init script are used at boot time to bring the system up.
For example, the script managing /etc/sysconfig/static-routes used to just
read the file and issue "/sbin/route" commands for each line, blindly.
This is appropriate at boot time, when the routing table is empty.
But what happen later if you change the routing on your workstation.
Should you reboot. In fact, what happen when you do any config changes..
Experts knows what to do (but may forget to do it :-) ) and beginners have
simply no clue (They reboot all the time with other OS anyway :-) ).
This is where linuxconf enter. It has the ability to compare
/etc/sysconfig/static-routes with the current routing table. It can tell
from there
-if a route must be added (missing)
-must be modified (deleted then added)
-must be deleted
In the later case, this is even trickier as one must not remove route
added dynamically (routed/gated) or manually by the admin (by hand).
Linuxconf compare a third file in /var/run holding the content of the
route previously added by the sysv script.
This kind of process is well behond what a script can do. This is why
redhat sysv script relies on the --hint feature of linuxconf. Mostly, they
ask linuxconf "What should I do here" and linuxconf will provide on stdout
a list of things to do.
In many case, "linuxconf --hint ..." produce a simple report. For example,
if you do
ifconfig eth0 down
linuxconf --hint netdev
it will simply gives you the list of net device to reconfigure. It will
compare standard redhat config file with the state of the device. On my
system, it produces
DEV_UP=""
DEV_RECONF="eth0 "
DEV_DOWN=""
DEV_RECONF_ALIASES=""
IPV4ROUTING="true"
DEV_RECONF_ROUTES="eth0"
this tells the scripts exactly what to do, but not how. In the case of the
routing table, the course of action might be more complex. Just telling
that the routing table must be updated is not enough. So in that case,
linuxconf will send to the caller the list of route to add and delete.
this list nevertheless comes from static-routes. So if I do
/sbin/route del default
linuxconf --hint routing
I am getting
DEV_RECONF_ROUTES="eth0"
then if I do
linuxconf --hint routing eth0
I get
add -net default gw 10.0.0.10
the same stuff is true for IP aliases. This comes from the unique ability
of linuxconf to assign ranges of IP aliases. Again behond what a script
can do, so the script /etc/sysconfig/network-scripts/ipup-aliases will use
the linuxconf hinting to get a list of aliases to configure (as well as
the kernel aliases limit). This list comes from the files
/etc/sysconfig/network-scripts/ifcfg-xxx:y.
Note that if you tried the case above (ifconfig eth0 down), simply doing
linuxconf<enter>
quit
will let you bring your system back to life. Or
linuxconf --update
Note that linuxconf is checking much more than the networking stuff. When
I am asked to do something on a server, one of the first thing I do is
this
linuxconf --status
Which produces the list of things to do to enable configuration changes.
If the list is empty, I know the server is healthy. If not, I probably
know immediatly why the customer called me :-)
the question one must asked is why the original poster of this message is
complaining or came to the conclusion that linuxconf was using other
config files for routing on redhat 5.1. I am not sure here. For sure, in
the script if one does not know what "linuxconf --hint routing" is about,
it is very easy to jump to some conclusion. But the point is that unless
you have a good reason, you do not study the files in
/etc/sysconfig/network-scripts (boring, well something, quite cute). On
early redhat 5.1, there were bugs in linuxconf and in the network-scripts.
I guess that at that point, the poster was mislead by those bugs and
came to that conclusion.
I am cc'ing to him, we will probably know.
Have fun!
> > ---------- Forwarded message ----------
> > Date: Tue, 6 Oct 1998 22:17:20 +0200
> > From: Lars Marowsky-Br�e <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > Subject: linuxconf and other bugs
> >
> > linuxconf is in itself a really powerful administration tool.
> >
> > OTOH, there are some things in R H I would call "bugs" with respect to
> > linuxconf. Actually there is just one thing, which struck my eye and which is
> > part of the reason linuxconf isn't a part of any my systems anymore ;-)
> >
> > linuxconf vs /etc/sysconfig/static-routes. This is _BAD_. The network start
> > scripts test for the existence of linuxconf and if it exists, ignore the
> > static-routes file.
> >
> > I am not sure what should happen - most likely, merge both routing tables if
> > anything, and issue a warning.
> >
> > Ignoring either is a bad choice and such behaviour is bound to lead to
> > strange, unexpected effects.
> >
> > I don't know where else linuxconf effectively voids the "standard" config
> > without any warning, but it would be interesting to know ;-)
> >
> > Sincerely,
> > Lars Marowsky-Br�e
> >
> > --
> > Lars Marowsky-Br�e
> > Network Management
> >
> > teuto.net Netzdienste GmbH - DPN Verbund-Partner
>
> []s - s/&:(/&:)/g
> aurelio
>
> linuxconf-1.12r5-1
> 2.0.36
>
> =-=-=-=-=-=-=--=-=-=-=-=-=-=
> [EMAIL PROTECTED]
> aurelio marinho jargas
> curitiba - PR - Brasil
> "juntos por um mundo melhor"
> =-=-=-=-=-=-=--=-=-=-=-=-=-=
>
>
> ---
> You are currently subscribed to linuxconf as: [EMAIL PROTECTED]
> To unsubscribe, forward this message to [EMAIL PROTECTED]
>
>
--------------------------
Jacques Gelinas
[EMAIL PROTECTED]
---
You are currently subscribed to linuxconf as: [[email protected]]
To unsubscribe, forward this message to [EMAIL PROTECTED]
