Ray Olszewski wrote:
At 10:13 AM 2/4/03 -0600, Charles Steinkuehler wrote:
A few quick points about some of the recent discussion:
Regarding the config-db format: It really doesn't matter. The files
should be human-readable (plain text), with enough structure (probably
via filesystem directories and filenames) to be easily navigated, but
all access to the database information by the packaging and any
configuration system will be through a defined API, allowing the
back-end format to change if required. Who knows...future versions
might move to a packed binary format with small C or assembly programs
for access, to save space and/or gain speed. While initially a lack
of tools may require "power-users" to hand-edit database entries, I
would generally consider this unsafe and discourage the practice.
I'd like to disagree with this. It really does matter. One of the big
strengths of the anscestral LRP (Dave Cinege's version, I mean) was the
simplicity of its basic network.conf file. As LRP first went to the
mountains, then evolved into LEAF, and as LEAF tried harder and harder
to incorporate many specialized packages, each with its own config files
and syntax, much of this simplicity was lost.
Yes there was some amount of simplicity across a LRP release
that stemmed from his tight-a## control over it. I guess that
was a pretty big benefit. I think part of that simplicity was
inherent to the lack of complex networking it could do combined
with it's lack of firewall. When Charles built those into his
releases, combined with PPPoE and ipchains and all the other
new challenges, it made spaghetti at first glance.
I think the central config-db idea gets us right back to simplicity.
I've probably typed more keystrokes on this subject than it would take
to gather all the variables and make a test config-db.
Let me say that I am only one voice, with no expectations that I'm
right about these discussions, but that being said, I'll voice my
thoughts, if only to flesh this out a bit....
* Ok Ray. I agree with you on the need for a simple file
of name=value pairs.
* Ok Charles, I agree that the format shouldn't matter much,
and that XML has many advantages.
But it was pointed out to me that the XML database in Chad's idea
was something to be kept seperate from LEAF and not stored on it.
I think that the XML is used on seperate OS to configure the system.
I think the idea of Chad's was to combine an XML config-db with a
remote based gui and produce template-built runtime conf files
that would be used on the LEAF.
But back to the discussion of a LEAF based XML or flat db....
Proposed Solution:
==================
Can we merge the two ideas by making the master-db maybe XML
but also unleash sed on it to output a running config of
name=value pairs to a single file, /var/run/flat?
If we do that, then you'd have your choice of using the api
to access the XML db, or using /var/run/flat:
a) If you use the api to change the xml, the api also updates /var/run/flat.
b) If you hand edit /var/run/flat, you would run leafill which would
"refill" the XML db and trigger all dependant files to be reloaded.
Sound good?
It's merely an extra sed and an update.sh. It may be worth it to
have this redundancy. Anyone concur? It would mean a big XML
or similar db stored on your leaf diskette and an api to handle it.
To be used with LEAF, packages typically require some modification
anyway. Why not adopt a "one-stop-shopping" standard for config
variables that makes them easily available to any package?
I think we all concur on this, Ray.
Then when
someone adapts a package, he or she at least has the option of having it
get its config info from a standard place in an easy fashion. What I
mean here is a single text file, with a simple name=value format, that
contains all the basic information needed by networking packages, in a
form that init and config scripts can use easily (like the old
network.conf, which used a format that allowed all entries to be loaded
as shell variables). The key to keeping this manageable is that it
contains nothing but
VARIABLE_NAME=value lines
Yes.
#comment lines
Yes.
and lines that do minor manipulation of VARIABLE_NAME lines
(e.g., something like
NETWORK_INTERNAL=$INTERFACE_INTERNAL/$NETMASK_INTERNAL
)
I disagree. I'd want the db to be literal.
"name" = "some value"
so spaces and special characters don't matter, and the
# comment
lines. I'm not sure why, but I don't think it's the
db's responsibility to do 2nd level substitutions.
The other key is to enter each value exactly once. Consider again the
recent thread on leaf-user where someone wanted to change his
(Dachstein) internal network to 10.10.10.0/24. After he made way too
many separate changes in network.conf, he had to edit the DHCP config
file separately. If he were to use other .lrp packages, he'd have to do
this again and again. (I've never actually set up Bering. How many
individual changes would it require to its config files to accomplish a
change in internal network number?)
This is the sort of complexity I would like us to find a way around, at
least for the core packages used on a LEAF router/firewall.
I think we all concur. Any variable that can be common
to several packages gets put in the global section.
Ideally, to handle the example change, a config file would need only to
have the router's internal address changed (and perhaps the netmask, if
it also changed) and would calculate everything else it needed from that
information (in much the same way that typical network-init scripts can
figure out a basic routing table from the interface info).
Yes.
You could accomplish something similar with a complex configuration
editor that made changes to a bunch of behind-the-curtain files ... but
doing it that way forces use of the config tools, which (for a reason I
suggest later on) is unduly restrictive. That is, I also disagree with
Charles' final sentence above, but I leave that discussion for later in
this message.
Yes a remote GUI would be restrictive until all variables are progammed
for, thus adding complexity. But I don't think GUIs are your topic in
this thread, Ray. Really you're talking about the db.
This is all about making a GUI configuration tool: Wrong. Trying to
make a simple web or other GUI configuration system simply points out
the complexity and inconsistencies in the existing configuration
system. This is about *SIMPLIFYING* configuration, making it easier
to configure and maintain a LEAF install.
Charles, the GUI is goal 3.
The package system is goal 2.
The central config system is goal 1.
The central config system will simplify configuring and maintaining.
I think we agree here, at least that's what I'm trying to gather
from people's opinions.
>> ...
But it leaves one thing out ... an important way to simplify
the interface for configuration is to restrict the range of choices
available.
LEAF tends to be pulled in two directions all the time --
simplicity, so that common uses of it can be configured easily
by relatively inexperienced users.
flexibility, so that unusual uses of it are possible for
relatively skilled, experienced users.
My interest has always been in the first direction, but the diversity of
our interests means that both directions need to be accommodated.
Perhaps, though, not in the same configuration system. A very simple but
restrictive configuration interface that supports (say) just three sorts
of NAT'd configuration --
modem dialup connections
Ethernet external connections (including static, DHCP, and PPPoE
addressing)
both of the above with and without a 3d interface for a DMZ
-- might be a good goal for a Web-based config tool (one that handles
everything except NIC-module selection). The starting model for such a
tool could be the setup systems of the embedded routers, which typically
does all of this except the DMZ stuff.
Advanced users need, and can master, a setup tool that is considerably
more complex, one that does more and that permits more customization. I
don't have the experience to offer a starting model here, but people who
do the trickier sorts of setup might be familiar with the setup systems
used in Cisco and other routers and able to suggest a good starting point.
David D. tried to go down this road with Oxygen, and
once he started, his development here drifted off.
So I can't tell you much about it, because it didn't
work very well, but here's what he did.
He made a syslinux boot option to boot into setup
mode where you were presented with several options
on the overall use of your LEAF box: router, print-server,
DMZ, some other choices along those lines. I probably
got them wrong, but you get the idea. I thought it
was bad to begin with.
What I think is a good idea, however, is a gui-based, drag
and drop interface where you have a big outline of a computer,
and you drag a couple of nic icons onto it. Then you drag a
clock icon onto it (ntpdate) and then you drag a firewall
icon into the middle of it, and maybe some other objects.
Then you are walked through configuring each one.
It'd be easy enough, but I don't know if it could handle
complex setups too easily without endless revisions to
deal with new options. It also requires a complete analysis
of all possible network setups and the ability to create
the necessary glue in .conf files.
A gui is begining to sound unsimple :)
The biggest risk here is that you end up replacing an existing complex
system with a new system that is equally complex. We see this happen all
the time, with config files for tools to write sendmail.cf files, the
configure system to create Makefiles, and many others (including some
closer to home that I won't name to avoid offending people).
I laughed when I read that about sendmail.cf.
In the end, you always want to preserve the option of fixing intractable
problems by hand-editing the relevant files. No matter how many config
wrappers Debian comes up with, I still find in my development work that
I need to hand-edit /etc/network/interfaces, or the DHCP config files,
or even XF86Config-4. Preserving this capability permits the extremely
skilled user to cope with unusual situations him- or herself, rather
than waiting until a developer has the time and interest to modify a
configuration system fo accommodate a rare (or just a new) requirement.
This need comes from more than an "initial" lack of tools ... it derives
from the ongoing evolution of the applications that routers and
firewalls use, a proces that will always cause new "exceptions" to crop up.
Pre-Configuration: I like the concept, but in my mind, this also
benifits greatly from a simplified configuration system. The biggest
benifit to pre-configuration is the ability to use powerful tools
unavailable on most LEAF systems to deal with the complexity of
configuring current distributions. With the configuration system
simplified, a lot of this becomes moot. I think the real driving
force for pre-configuration is automatic hardware detection, which
would be a good thing.
The driving force behind preconfig is not necessarily auto-detecting
hardware, I'd say it's more about having to roll these things out,
and being able to prepare 10 different diskettes for all your LEAFs
on one system, your regular workstation. It also makes it easier
for a 1 LEAF setup, because when you pop in your preconfigured diskette,
it's going to work well.
> The desire to keep the floppy-based option is the
underlying reason for wanting to do initial configuration, in particular
specification of NIC modules, on something other than the router itself.
I disagree for the same reason as above. Preconfig is always useful,
because editing all those scripts is a pain, and downing your running
network to put in place an unconfigured LEAF box is not how to deploy,
in a best case. It hampers your ability to access leaf.sf.net ;-)
And you probably won't get it running the first time....
If we accept this limitation ... and if the automatic hardware detection
requirement really just means the ability to find the external and
internal NICs, not to auto-configure anything more exotic ... the
biggest problem I see is with older modules like ne.o that require a
specified iobase ... then we can look to the config systems of the
embedded routers for guidence about how to proceed. The other limitation
they consistently impose (on their Web-based config systems, anyway) is
that the LAN IP address of the router, and its network, are
pre-specified, at least for starting configuration. This presents both
costs and benefits.
Autodetecting hardware is fun, but it has to be run
on the LEAF box, and that's not necessary or always
logistically feasable.
Ok then,
Matt
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
