On Jul 5, 2004, at 12:17 PM, Ray Olszewski wrote:
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.
Sorry. I guess my assumption was a bit egocentric. I didn't intend it that way. I do hope however that your "ignore" comment is not a value judgment on either the code or design; it is extraordinarily easy to ignore code that is not complete! Comments inline.
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
We will likely be discovering these for some time to come...
... 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.
Please do not be distressed by hier.help. I have spent a sum total of a couple of hours thinking about and writing text into that file. I spent the majority of my time creating and thinking about a nice generic storage mechanism, which I believe is what we now have in cdb.
Seriously, the package maintainers and developers are the one's who are much more competent at laying out the hierarchy. I am just a humble(?) tool creator...
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.
Correct, not done. The problem(?) with generic storage of ip firewalling/tunneling/etc. parameters is that Tom has done such an outstanding job of breaking down the model in his own config file set. Frankly, the cdb model will likely look a lot like Tom's model, with the files as directory keys and the lines and their column headers as the individual name-value pairs. Again, package maintainers and developers are much stronger at this than I am, so please don't take it's absence as an indication of cdb's inadequecy.
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?
Again, package maintainers could speak better to this, but being a programmer, I would likely say something vague like "not necessarily." There might be global name resolution parameters to be used in /etc/resolv.conf, which might then be overridden by a "forwarders" key under the dns tree. On the dynamic stuff, that is exactly what I would like to discuss with people. Obviously, the easiest thing to do is put an indicator in the cdb that the configuration of a given element (in this case an interface) is dynamic, then the specifics of obtaining the interface-specific information are outside the purview of the cdb. But that breaks our nice encapsulation, doesn't it? Not to mention that there are (at least in the case of dhcp client) several different (package specific) ways of going about finding the information you desire...a conundrum, but definitely needs to be part of the upcoming discussion.
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).
Likely incomplete. There is no reason to define an interface as "internal" or "external" until you start giving it a job (acquiring an address, filtering packets, etc.) so these terms need to be logical terms laid on top of interfaces, not part of the definition of the hierarchy itself, right?
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.)
This is the biggest gap currently. But again, I think that much of this will come out in the discussion of what the hierarchy should look like. It really doesn't seem to depend on the tool that is used to store the parameters. These decisions would have to be made if you used a flat file to store configuration parameters.
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)?
In my opinion, it should not affect the shape or structure of the database. Our task is to create a configuration hierarchy that is unbound by the packages using the data. It's tough, but again, not related to the storage mechanism.
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.
I think what we have here is a generic facility. One of the beautiful things about UNIX is the way people have written small utilities with one thing in mind and they are used for something altogether different many moons later. It think once the thing is on the systems, many a hacker will find a novel use for it; they might even figure out a way to use it to help configure hardware!
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.
Really, you'd have to ask Eric and Lynn about that. I did not. I had a structure in mind for how updates would occur, etc. which maps onto the structure and layout of the tools, but had nothing in mind for a UI itself. I made a tool that was generic enough to handle any situation. This includes everything from the absolute degenerative case (think Belkin) all the way to full SNMP, centrally managed, hand-tuned and exported configs, etc.
As far as exporting messiness, the hierarchy design should not be messy when it is complete. That is a very important point. Similar to the design of Tom's shorewall configuration files, you should be able to look at the hierarchy and say to yourself, "That structure defines a LEAF!" and it should just feel right. I make no claim that the current hier.help does that. It needs work.
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.
I would not mind hearing this either. Always good to shake one's thoughts up a bit.
-------------------------------------------------------
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
