Hello Paul, > I'm glad to hear that someone with energy and good ideas is looking at > this. > > "In a perfect world" what I'd like to see is binaries come with default > sensible configurations, and the user is simply responsible for specifying > and maintaining divergences from that configuration. There are a whole > lot of ways to skin this cat, some are difficult and work well, some are > simple and work poorly. > Absolutely agree with that.
> In the most simplistic solution, we could make the binary .lrp packages > read-only. They always carry the "default" /etc configuration files. When > a LRP package is installed, we look up the package config files, check our > own local config patches (from a config area possibly stored in a > config.lrp?), and apply them. In theory, tools like ucf(1) make this > fairly painless. > In the current situation with LEAF something like lrcfg is used to provide an user interface, the names of the config files are stored in /var/lib/lrpkg/<package>.conf. When lrcfg is started the <package>.conf files are parsed and listed as config items. In lrcfg you can select the configuration items and edit the config files directly. If you store "originals" and config patches, what would be a possible userinterface to the configuration files? > In reality, most of the binaries that we ship have configuration files > with tons of needless text and comments and examples in them, these > inactive sections of the configuration files are often changed since they > are the defacto documentation for a given config file, so 3 way diffs and > merges almost never work without manual intervention. That's wrong. > > For example, a typical dnsmasq.conf has 9 lines of active commands in it > and some of those may even mirror compiled in defaults, but with comments, > my dnsmasq.conf is 380+ lines. Shorewall is another example, the > documentation is in the configuration files. The average shorewall > configuration file has 0 lines of active commands in it (grin) but has at > least 150 lines of comments. > True, but the examples also have a purpose in a lot of packages. In some cases it's enough to uncomment an option to get the desired behaviour. It also makes clear which options are possible without looking in all kinds of documents on the net. But I agree that in a lot of cases this is overkill. > A junos or IOS configuration is just the minimal changes off of the > default to turn on the bits you need. There's a little semantic or > syntactic structure to make it easy to migrate back and forward between > binary versions. > > We could auto-generate config /etc files from a database. This is what > we did in the JUNOS UI (my baby). Later on, we decided that XML constructs > work very nicely for this kind of thing, but the overhead and bloat are > high, and I think that the re-engineering effort alone for any database > driven project would make such a project a non-starter, no matter how > appealing it is. > > Eric ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
