At 10:30 AM 7/5/2004 -0700, Chad Carr wrote:
On Jul 5, 2004, at 9:47 AM, Ray Olszewski wrote:
Erich -- I'll be a bit happier when this discussion starts to attract comments from someone other than the two of us (and Mike). Until then, a couple of small responses to what you wrote.
I guess you probably meant myself, Lynn or Eric, hmm?
Actually no. I meant people other than Erich who are either upstream developers (e.g., Tom) or packagers (e.g., Charles). That is, the sorts of people who will actually have to use, or to ignore (as they have up to now, saving the occasional e-mail), whatever gets implemented. But any thoughts from the old development team would be great too.
I don't want to go into detail regarding what you wrote. For the most part, I pretty much agree with it, especially now that I've taken the time to review some of the early discussion -- from around Feb 2003 -- on this topic.
I think your closing comment is to the point: [...]
I am a simple type of guy, but I truly believe that we need to start up the discussion not at cdb, which has been discussed to death (and is, frankly, complete), but at a (believe it or not) much more difficult and contentious problem, which is what to do with the stuff once we have it in there! Seriously, think about this: what if you did have the most perfect unified configuration and database interface in the universe? What would you do then?
Well, I almost agree with this. Especially the "difficult and contentious" part.
While I agree that the structure of config-db probably doesn't deserve much more disussion ... except at the nitpicky level of loose ends in the implementation ... a discussion fo the "stuff" one puts in it is worth having. A lot of my concern about the overall approach stemmed from reading through the draft Bering DB structure document (hier-help). It left me very confused about how the system would actually hold data. Here are some of the concerns is raises in my mind.
The really really hard parts -- e.g., the structure of the Shorewall subsection -- are not yet done. Or at least I hope not ... this area lacks very basic details, such as a way to specify port forwarding/DNAT.
Some of the simpler parts are described a bit too vaguely for me to get a handle on them. dns is a good example of this. Is it intended that the design force the router's own DNS resolution (in /etc/resolv.conf) to match the DNS resolution provided to dnscache? How does it handle DNS server info provided as part of a DHCP lease?
Some parts seem either incorrect or incomplete. For example, where in this hierarchy does one describe the internal network? I'd guess it is in an /interface specification ... but the illustrations for this spec use the sorts of variables I associate with external networks (dhcp, pppoe, gateway), not internal networks (NAT, proxy arp, locally authoritative DNS server).
Another thing that would help my thinking is a few examples of how you'd expect init or install scripts to use the database. How, for example, would a package that needs to know the IP address of the external interface (if static) or how it is provided (if ppp or pppoe) get this info from the database? How would an ntp server or client get the address(es) of the timeserver(s) it is to use?
More generally, how would dynamic address assignment on the external interface be handled? Would every update of the address cause an update to the database, with anything that needs the address (e.g., Shorewall) getting the info from the updated database? Or would the daabase just store the fact that the address is dynamic, with changes handled as they are today? (I think you intend the second.)
How would the system handle a package change? For example, if the user were to replace dnscache with a different resolver, or Shorewall with a different firewall, how would that get reflected in the database? Or even more basically, just adding a package not on the list (an SMTP forwarder, or a proxy server)?
Is the system intended to handle hardware issues at all? I wonder especially about what always seems to be the #1 hardware issue for LEAF -- NIC detection and module support. My guess here is NO -- that the process of configuring LEAF to match the hardware ... and generally, adding kernel modules of any sort ... will remain outside the config system. We might ask ourselves if we are happy with that limitation.
Finally, what would a setup User Interface -- console based or Web based -- to this system look like? Yes, I know this is a big question, but I'd hope you and your co-developers had something in mind when you designed the database. The database contents seem very messy in some ways, and I'd be unhappy with a UI that simply exported that messiness for a naive user to confront directly.
Probably some of this was discussed a year ago, though I didn't find that discussion today when I looked.
BTW, I'd still like to read Erich's explanation of why he thinks package config files should have priority over the central db. Though I obviously agree with Chad's comments (deleted here, they basically said they agreed with my prior comments), I really would like to read the othe side of this argument, and a packager or developer is the likely person to make in in its best form. I worry that I am (and you are) missing something important.
-------------------------------------------------------
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
