Hi Ray and List At 07:50 05.07.2004 -0700, Ray Olszewski wrote: >At 08:36 AM 7/5/2004 +0200, Erich Titl wrote: >>Mike >... >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.
Right >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. Mhhhh... I believe in the end the _true_ files, the ones that are actually used by the LEAF box (for example /etc/network/interfaces) should have precedence over the _config_ files, because those are the files that actually get loaded. IMHO the contents of these files should be parsed and the converted to the _config_ values which could then be used in a standardized way. >The idea is to force everything to use this config database, not just to make it >another option. This is achieved easily by letting the _config_ package just manipulate the config database. The above mentioned method just makes sure that all manual modifications get passed back to the database, e.g. If I modify the network configuration manually (bad habit) and then save etc.lrp and go home, the next poor luser that uses the configuration UI will get wrong information eeeek... >If we don't force that, then we've let package creators break the config UI again.) Agreed >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.) I believe for the sake of a more modern UI we need a standardized API to store and retrieve config parameters. I believe also that we need the agreement of the developers involved to move towards such an API, just because they will have to maintain interface code for it. cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 ------------------------------------------------------- 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
