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?
(After I wrote this, I got Mike's mail forwarding Chad's messages. At this point, they don't change my thinking ... but I haven't had the time to look at the attachment he provided, to see how it amplifies what is in CVS.)
One of the problems with the code that I have written is that it is extraordinarily abstract. I think that I am having a difficult time illustrating its possibilities. This has distracted and stalled things much more than I like and I am sorry for that. If there had been a clearer path, people might have achieved more in the past year. Myself included. One of the hazards, I'm afraid, of open source design. I have put comments inline.
At 05:47 PM 7/5/2004 +0200, Erich Titl wrote: [...]>(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...
I disagree, especially with the "easily", but in general with this philosophy.
If we take this approach, then any changes made "by hand" to a non-database config file will propagate back to the database (or probably will, which is even worse than certainly will). This invites packagers to adopt procedures that break the UI. I would recommend that the system instead be set up so that every package is expected to create its separate config files during boot/init, drawing on the common database ... so we can be confident that changes made to the database always get propagated to the apps by a save-and-reboot procedure (the easiest thing to tell beginners to do).
Ray has this correct. I do realize that there are many ways to do this, but the one that will cause the least surprise (and potential damage) is to let there be one centralized repository, and the package maintainers consult this repository during boot and reconfiguration. This must, naturally, be the abstract repository (the cdb, in the current implementation of leaf-tools) since the problem to be solved is providing unified access to a decidedly un-unified set of configuration files.
I'm not dead set on this ... I'm happy to listen to an argument for doing it the other way ... but I don't see the case for doing it the way you propose to be so obvious that it doesn't require an explanation.
What motivates me to propose my approach is:
1. If we don't force packagers to use the config system, some of them won't, and that breaks the UI and makes things hard for naive users. (This is a perpetual battle between upstream developers and distro packagers, not something peculiar to LEAF.)
Exactly. We must create a system that _all_ packagers use, or we can have no drop-in package support. The UI (or multiple UIs) must have unified access to the dhcp configuration, for example, so that you can drop in dhclient, dhcpcd or udhcp at a whim. The packages know the abstract values they need for operation, they retrieve these from the cdb, then they write their peculiar configuration files, substituting the abstract values.
2. Having information propagate back from the app files to the database creates the risk that the configuration for one package might corrupt settings for another. Consider any of the old-days situations where users were required to enter their IP address in 2 or more places as an illustration of how this might happen. For a more current example (though one I am less certain of), what would happen to the config database if the "true" config files /etc/resolv.conf and wehatever dnscache uses contained inconsistent information? I'd bet that Shorewall could provide additional examples, simply because it has the most complex configuration system of anything that is a stock LEAF package.
Yes. We must have exactly _one_ canonical source for each configuration parameter. Every package must know where that is stored and how to retrieve it.
3. Creating that part of the API, and getting it right, is more work, and projects ... especially ones that have languished for 18 months due to lack of developer interest ... should not require more work than they absolutely must. (At this point, you and I, and Mike, are the only people exhibiting even a passing interest in this topic ... and I haven't noticed any of us yet voluntering to complete this API.)
Yes. I suppose you are right. But, while you assume developer disinterest, I think there are other possible explanations for the lack of recent development. The other thing is, over 18 months, nobody has started another, right?
There is much code of value in the project: "cdb" is complete. It works and even has a fairly good regression test script. "trig" also works (very simple, I suppose not much to it). the major sticking point is "tmpl" which may just be a bit aggressive in its scope. It may not be possible to reliably do what I wanted to do.
Because of that, I think this is where we should pick up the discussion: what is tmpl meant to do, why does it fail, and is it possible to make it do what it was supposed to do? If it is possible, is it attractive? I have looked over my target syntax a couple of times and am not sure that I like it anymore even if I could make it work!
I'll be interested to read what you see as the strengths of doing it the other way.
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.
Just to be clear ... I agree 100% with this. What I was questioning in the long discussion I deleted here is whether this *particular* API was suitable for the task, or whether it combined too much complexity with too little flexibility. After all, a file that sets a bunch of shell variables, in PARAMETER=value format, is also a "standardized API", albeit a very simple one.
Wow. I think I remember this discussion. It very nearly approximates the beginning of the one we started a year and a half ago. Except last time Lynn was the skeptic.
I would find it helpful if someone could illustrate how the proposed API offers more genuine flexibility than a simple system of that sort, one that would be a fairly basic extension of the approach used by the old lrcfg system.
1) Locking - it is possible to implement a sort of "row-level" locking scheme with the cdb method, even in shell.
2) Speed - as configuration DBs get larger, the speed of sourcing a single file config db gets prohibitive. Memory usage ditto.
3) Namespace - enforcement of namespaces to avoid naming conflicts
4) Flexibility - Anything can be stored as a value using the cdb method without horrific escaping escapades. The current interface may not be perfect in this respect, but it is at least theoretically possible with cdb to easily grant access even to binary data in the backing store. In a single sourceable shell file, this could be a nightmare.
There are others, but I was up late last night and can't think of them right now.
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?
Thanks, Chad
-------------------------------------------------------
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
