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.
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 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.
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.
------------------------------------------------------- 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
