HI, I'm really glad that this thread started up!
I can help modifying package to take care of the reading config values from the repository !! One thing that I like in ipcop is its abstract way of naming interfaces - red= internet - green= local lan - orange =dmz - blue = wireless by using such ( or other names) abstraction and, I think, ifrename could be helpfull, we could reach a very usable config system where e.g., changing the ip range for the internal lan should only be done a one place, I started such a kind of thing a few years ago on a dachstein ( there was a setup.sh that was called, if present, at linuxrc end ( before init) I just wrote a script that fed template to a sed script to replace parameters read from a single config file. I just gave up because it's something that only works if it's the "standard" I'd be glad to help migration to such a system Regards Etienne ----- Original Message ----- From: "Chad Carr" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 05, 2004 7:30 PM Subject: Re: [leaf-devel] Source: config > > 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 ------------------------------------------------------- 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
