Ray and List
At 18:47 05.07.2004, 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.
(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.)
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.
easily does not mean it's no work, my _easily_ means that the UI should _only_ manipulate the config database, the rest should be done by the _adapters_
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).
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.)
Force.... such a strong word. It will be hard to force anyone to change his API when his product is distributed a zillion times, successful and he's moved on to other chores. Of course you are right, but this is not the ideal world. I would prefer the _invite_ method :-)
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.
Good point, something that bothered me a long time.
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.)
I'll be interested to read what you see as the strengths of doing it the other way.
Your analysis is convincing, especially as it covers the most important part of getting the system configured the way the user wants it.
My suggestion to allow the inverse way was wrong in the way it was formulated. I would actually love if the UI showed the _actual_ state of the system. regardless of the config files, because the end user will typically also use such tools to check the actual system status.
If this is consistent with the system status at load of the UI we'd have a good starting point.
Whenever a change is confirmed in the UI this state should be written to the config database _and_ the system which would keep us in a consistent state. This would, of course, require quite a sophisticated control mechanism, e.g. when the user changes an IP address, subsystems like shorewall and ipsec would probably have to be reconfigured and restarted.
Hope this makes sense. 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
