At 10:13 AM 2/4/03 -0600, Charles Steinkuehler wrote:
A few quick points about some of the recent discussion: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.
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.
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? 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
#comment lines
and lines that do minor manipulation of VARIABLE_NAME lines
(e.g., something like
NETWORK_INTERNAL=$INTERFACE_INTERNAL/$NETMASK_INTERNAL
)
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.
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).
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.
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. Once simplified, front-ends to the configuration system can be provided for plain text (to replace the existing lrcfg system), web browsers, palm-pilots, pocket pagers, hexadecimal keypads, or whatever someone wants to implement. The key is to simplify and organize the configuration process enough to make such things possible.I think I agree with this, if we mean the same thing by "configuration process". 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.
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).
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.Well ... this assumes a local (on router) source for the LEAF distro that is big enough to hold a lot of options. The underlying reason why LEAF hardware setup is harder than (say) Debian or (probably) Red Hat is that only so much fits on a 1440 (or 1680) floppy. Debian's install kernel (2.2.20), for example, has support for the more comm,on types of NICs compiled it, so that, most of the time, I can skip adding modules entirely ... unless I've used some real oddball NIC ... and go right to a network install.
But doing that even for the limited purpose of an install keeps Debian at a 2-disk (bootdisk/rootdisk) install system. A LEAF system that loaded from a CD drive can accommodate the larger kernel and full array of modules needed to do automatic hardware detection ... but now we've lost the router-on-a-floppy character that has historically been one of LRP/LEAF's strengths. 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.
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.
Of course, you (Charles) may have more in mind in the way of automatic hardware detection than I am assuming here. While LEAF systems can pretty much assume vanilla video, I can easily see the desirability of detecting IDE devices, USB keyboards, serial ports and (Linux-supported) modems, 802.11b cards, specialized external interfaces like the Sangoma cards, and perhaps parallel ports ... and there may be more stuff I'm not thinking of this morning.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------
-------------------------------------------------------
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
