Mike
At 10:17 04.07.2004 -0700, Mike Noyes wrote: >Everyone, >I'd like us to complete the work Chad Carr started on the leaf config >system. This is one of the main deficiencies I feel we have presently. >lrcfg isn't viable as a sole option anymore. Chad's system allows for >multiple front-end support from command line to http using templates.
I have contemplated some time to write a new front end to our configuration system. I am not sure just a new standardized database and API (that's what I understood Chad's system is) will be sufficient to reach this goal. IMHO what we are missing are parser and converter routines _to_and_from the existing Debian configuration files. In order to achieve this, each and every package maintainer would also have to maintain the interface routines to the respective package, else modifications to the _original_ format will go unnoticed.
thoughts
After Mike posted the request yesterday, I took a look at this sub-project too. I read it, and its limitations, exactly as you do, Erich. It's designed not to solve the config problem by itself, but to provide a standard method to let package maintainers ... who can be the upstream providers or distro packagers ... convert config info maintained by LEAF into whatever formats the upstream packages expect.
So, in concept at least, one could use this toolset to write both console and Web interfaces that would collect settings changes from the system's operator and put them in the database. (MIke's description of the project.) The act of updating the database could also trigger the running of other scripts that used the system to update other config files and to restart or re-HUP relevant apps. (The TRIG component seems to do this.) These other scripts could also run at boot/init to extract approproate values from the "official" LEAF database.
Assuming the system itself works ... it's sat idle sufficiently long that someone would have to test it and fix any bugs or omissions in the API ... its completion would need to be followed by creation of scripts that (for example)
extract nameserver info and put it in /etc/resolv.conf
extract interface info and put it in (I think) /etc/network/interfaces
extract nameserver info and put it wherever dnscache expects to find it
extract DHCP *server* info and put it wherever DHCPD expects to find it
extract a lot of firewalling info, convert it to the formats that Shorewall expects, and put it where Shorewall expects to find it. (This one is, I think, pretty complicated, since iptables rulesets work as sets, not as individual rules; order matters.
extract timeserver info and put it wherever ntpdate (or whatever ntp package a distro uses) expects to find it
(This part is, I believe, Erich's observation, just fleshed out with examples. But I think we need conversion routines only to each package's own config files, not "to *and* from" them as Erich writes. The idea is to force everything to use this config database, not just to make it another option. If we don't force that, then we've let package creators break the config UI again.)
More fundamentally, though, it is unclear to me if the complexity of this API buys us valuable flexibility. It would help if someone involved in its design disccussed the dseign philosophy it represents. This is more than man-page descriptions of the API and a proposed Bering hierarchy.
Just to pick an obvious example, I can't tell from the docs in the package how one would tell the system to use a firewall package other than Shorewall.
Similarly, I did not see how (or even if) the system would provide for the selection and installation of kernel modules (for non-standard NICs). The config system may by design stop short of handling this; I just can't tell from what is there.
Finally, the Shorewall section of the draft hierarchy is pretty sketchy. Some examples here would help. How, for instance, would one add entries related to port forwarding? The examples should address both standard services and oddball ones.
These three are only examples. We'd need to go over the draft Bering hierarchy fot the database to figure out what is needed and how to provide it in a way that does not hogtie us when new packages, ones that require both existing and new information, come on the scene.
What I am afraid of here is that this API does what all too many Linux projects do ... replaces a complex but familiar interface with an equally complex but novel one. This sort of change is rarely a win ... I always see it as just one more thing to learn ... and I think it would not be a win for LEAF in this instance. I may be wrong, though ... this API may offer excellent flexibility for a low price, and I'm just ot seeing how. So I'd like better to understand the intent of its designers, to get a handle on this uncertainty.
Although I remember seeing some passing references to this sub-project as year or two ago on one or another leaf-* list, I don't remember any in-depth discussion of the design philosophy or details, so I assume that much has taken place off-list among the sub-project's active developers. Any new development team would want to see that discussion, I think, or at least have it summarized by someone from the old team who is still around.
The other option is to define a far less ambitious database standard, but one that has far greater ease of use ... something much closer to the existing lrpkg system, but a bit less weird to edit and a bit more complete in contents. Were I to do something like that, I would start by defining a UI for the system -- an updated version of Weblet, or perhaps a set of console screens -- to figure out what information we expect a user to enter (or modify), and what the system should figure out on its own. (Postings from self-identified "newbies", like the one I responded to on leaf-user last week, are a good source for learning what naive users expect to need to do, and what they find puzzling or unneeded.)
From that UI, I would then figure out simple ways to store the results, to tell the system to act on changes (save and reboot is the crudest solution, but it may be good enough), and to export the config-system's values to other apps that expect to get them from other places. (This last is a real rat's nest. But that's a Lijux problem ... I have it on my Debian routers as much as we have it on any LEAF distro.)
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
