Hello "Jeff Schroeder" <[EMAIL PROTECTED]> writes: > On Fri, Jun 13, 2008 at 2:13 PM, David Lutterkort <[EMAIL PROTECTED]> wrote: >> On Fri, 2008-06-13 at 13:07 -0700, Jeff Schroeder wrote: >>> How does Augeas deal with something like squid where the config file >>> will change in incompatible ways? >>> Some of the directives in the rhel4 squid vs rhel5 change and are not >>> backwards compatible. >> >> What exactly are the differences ? Is it possible to detect what version >> a file is for just from looking at the config file ? > > The example for this will be squid 2.5 in rhel4 vs squid 2.6 in rhel5. > This link summarizes the changes. > http://ftp.iasi.roedu.net/mirrors/ftp.squid-cache.org/squid-2/STABLE/squid-2.6.STABLE5-RELEASENOTES.html#s2 > > Squid 2.5 valid directives: > httpd_accel_host virtual > httpd_accel_port 80 > httpd_accel_with_proxy on > httpd_accel_uses_host_header on > > Squid 2.6 valid directives: > http_port 3128 transparent > http_port 80 vhost >
There's a possibility with Config::Model[1] (possibly on top of Augeas) In short, Config::Model is made of 2 parts: - a in-memory representation of the configuration structure in its values. This representation is made a model declaration. See config_sshd model [2] for instance - a parser/writer which does more or less the same thing as Augeas (I hope that David will forgive me this crude summary) To address the upgrade problem, the model declaration for squid 2.6 would feature a model declaration for both 2.5 and 2.6 features: - 2.5 parameters would be declared with "status" "deprecated" [3] - default values of 2.6. parameters would be computed from the deprecated 2.5 values (with Config::Model compute feature [4]) The Config::Model parser for squid would be able to load both 2.5 and 2.6 parameters. On the other hand, Config::Model writer for squid would not able to write back parameter marked deprecated. This way, you have a smooth migration path from 2.5 to 2.6 squid configuration files. >> Even more difficult is the question of how to get from an 'old' squid >> config file to a 'new' squid config file. It would be possible to >> address that with Augeas, and a bit of copying files around, but it's >> not something anybody has looked at in much detail. > But it seems like a valid use case for Augeas. This problem may be better addressed by a layer above Augeas. I'm working on Augeas Perl binding, so using Config::Model on top of Augeas will be possible. > Especially on debian based distributions where dist-upgrades are > often encouraged from release to release. If this technically > possible without nasty hacks we should "do the right thing TM". Agreed. I'm beginning to talk with Debian [5]. Let's see how this pans out. All the best [1] http://config-model.wiki.sourceforge.net/ [2] http://search.cpan.org/src/DDUMONT/Config-Model-OpenSsh-0.104/lib/Config/Model/models/Sshd.pl [3] http://search.cpan.org/~ddumont/Config-Model-0.623/lib/Config/Model/Node.pm#Configuration_class_declaration [4] http://search.cpan.org/~ddumont/Config-Model-0.623/lib/Config/Model/ValueComputer.pm [5] http://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase/Discussion _______________________________________________ augeas-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/augeas-devel
