Hello The new version of libconfig-model-perl 1.229 is now available in Debian/Sid. This new version provides a model of Debian s DEP-5 copyright file specification updated according to the CANDIDATE version. (Among other features, like editor/validator for debian/control). The DEP-5 editor must be run in the source package directory (I ll provide an example below) with the following command:

config-edit -application dpkg-copyright

Features:

• check copyright file (with option -ui none )
• migrate from old format to new format ( with option -ui none -save )
• graphical editor (no option, but libconfig-model-tkui-perl must be installed)

Known issues:

• some keywords from older versions of DEP-5 specs may have been missed. In this case, feel free to send a mail to config-model-users mailing list or to log a bug in BTS.
• the update of the content of the format string is silent. This behavior is a bit cavalier. This will change in the next version

Example: The copyright file of libconfig-model-backend-augeas-perl needs to be updated: Here s the original copyright file (slightly edited to protect my mail box and save electrons) :

$ cat debian/copyright
Format-Specification: http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=196 Upstream-Maintainer: Dominique Dumont (ddumont at cpan.org)
Upstream-Source: http://search.cpan.org/dist/Config-Model-Backend-Augeas/
Upstream-Name: Config-Model-Backend-Augeas Copyright: 2008-2009, Dominique Dumont (ddumont at cpan.org)
License: LGPL-2+ Files: debian/*
Copyright: 2009, Dominique Dumont
License: LGPL-2+ License: LGPL-2+
This program is free software; you can redistribute it and/or
[snip]

First, let s just check issues:

$ config-edit -application dpkg-copyright -ui none
Element Upstream-Maintainer of node Debian::Dpkg::Copyright is deprecated
Element Upstream-Source of node Debian::Dpkg::Copyright is deprecated
Element Upstream-Name of node Debian::Dpkg::Copyright is deprecated
Missing Files: specification at top of section number 2. Adding Files: * spec

Then, let s see what s config-edit can fix all by itself:

$ config-edit -application dpkg-copyright -ui none -save
[ same warnings displayed ]

Let s check the result of the migration:

$ config-edit -application dpkg-copyright -ui none
[ good: no more warnings ]

And here s the content of the upgraded file (drum rolls, please):

$ cat debian/copyright
Format: http://dep.debian.net/deps/dep5/
Upstream-Name: Config-Model-Backend-Augeas
Upstream-Contact: Dominique Dumont (ddumont at cpan.org)
Source: http://search.cpan.org/dist/Config-Model-Backend-Augeas/ Files: *
Copyright: 2008-2009, Dominique Dumont (ddumont at cpan.org)
License: LGPL-2+ Files: debian/*
Copyright: 2009, Dominique Dumont
License: LGPL-2+ License: LGPL-2+
This program is free software; you can redistribute it and/or
[snip]

You can see that:

• keywords were changed while keeping the correct content
• Format: was updated with the right URL
• Files: * line was added in the right place

Please provide feedback! If you have problem migrating DEP5 files, yell, and we ll fix them. If this migration works fine, don t be shy, please say so. Under the hood:

Most of the migration work is specified in DEP-5 model [2]. Using config-model s GUI [3] to update DEP-5 model, about one hour was spent to:

• flag old parameters as deprecated
• introduce new parameters from candidate version (mostly done by cut n'paste old parameters into their new name, done within the model editor GUI )
• cut n'paste the doc bits from the web page into the model editor GUI
• specify migrate_from instruction to copy semantic content from old parameters to new ones. (*)

This shows one important feature of Config::Model: maintenance and evolution of a model is not a huge task. Even though copyright files are not configuration files, the same approach can be used to specify model and migration of other configuration files. Now comes the question of the migration as seen by the user. Well, it s your turn now. Try it and tell us how it works! Hopefully, encouraged by your feedback, other people will apply config-model to other specifications or other configuration. All the best (*) E.g, in the text format produced by the model editor GUI: 'Upstream-Contact',

'value_type' => 'string',
'migrate_from' =>
'formula' => '$old_maintainer',
'variables' =>
'old_maintainer' => '- Maintainer'

,
'type' => 'leaf',
'description' => '* Syntax: line based list [snip]'
,


Hello During the Config::Model presentation at Debian mini-conf, I was asked whether Config::Model could be used from other languages than Perl. Of course, config-edit command line can be launched from any program with any language, but we can hardly call it an API. There s also the possibility to use Config::Model::SimpleUI to fork a process and send commands on its STDIN and get results on STDOUT. But using this from another program is awkward. On kernel side, /proc and /sys are widely used to get information from the kernel and set kernel configuration. How about using a similar approach with system configuration data ? Configuration data from config files is already mapped into a tree within Config::Model. This tree can also be mapped to a file system structure. This file system structure could have the following layout:

/conf/
system/
sshd/
PermitRootLogin # contain 0 or 1
ssh/

popcon/

As a bonus, this file system would provide a unified access to all system configuration data available through Config::Model. In any case, people would still be able to tinker configuration with their favorite text editor on a file in /etc. The modification will be propagated to the corresponding entry in the /conf virtual file system. The reverse will also be done. Anyone interested ? All the best PS: Further technical discussion will be held on Config::Model mailing list: config-model-users at lists.sourceforge.net 2010.11.25 edit: specified that config data can still be written in usual config file.

Hello I m a Perl author working on a Debian unstable system. The great thing about Debian is that a lot of Perl modules are available though Debian packages. I follow Debian way of life to the point that I no longer install my modules (under development) with sudo make install (or its Module::Build equivalent). I ve often been bitten by weird test errors due to old version of module lingering in /usr/local. Now, I always create Debian package of my modules under development with dh-make-perl. This way, I avoid installing Perl module in /usr/local and my developement versions are cleaned up when actual package are availalble through Debian unstable. () This method has an unfortunate side effect: I never test installation the CPAN way. And Config::Model did fail to install with CPANPLUS. Now here s a way to create a barebone Debian chroot with cowbuilder to test CPANPLUS installation. First create a new chroot: $ sudo cowbuilder --create --distribution sid

Loging into this chroot (the bindmount option is necessary for cpanp to work correctly) : $ sudo cowbuilder --login --bindmounts /dev

In the chroot: Run cpan to configure CPAN: # cpan

Hit return to configure CPAN automatically. Then install your module: # cpanp i Config::Model

Or, if your module is not yet uploaded: # cpanp i http://<path-to-tar.gz>

Once you quit, the chroot is restored to its barebone state. Et voila. I tested full installation with dependencies the CPAN way without mucking up my system. Many thanks to Christian Kuelker of Cipux project for his comments that enable me to improve Config::Model All the best

Hello fellow developers, The summer is over but I m happy to announce that this year s Summer of Code at Debian has been better than ever! This is indeed the 4th time we had the privilege of participating in the Google Summer of Code and each year has been a little different. This year, 8 of our 10 students succeeded in our (very strict!) final evaluations, but we have reasons to believe that they will translate into more long-term developers than ever, all thank to you. The highlight this year has been getting almost all of our students at DebConf10. Thanks again this year to generous Travel Grants from the Google Open Source Team, we managed to fly in 7 of our students (up from 3!). You certainly saw them, presenting during DebianDay, hacking on the grass of Columbia, hacking^Wcheering our Debian Project Leader throwing the inaugural pitch of a professional baseball game or hacking^Wsun-tanning on the tr s kitsch Coney Island beach. Before I give the keyboard to our Students, I d like to tell you that it will be the pleasure and honor of Obey Arthur Liu (yours truly, as Administrator) and Bastian Venthur (as Mentor) to represent Debian at the Summer of Code 2010 Mentors Summit on 23-24 October 2010, at the Google Headquarters in Mountain View. Like last year, we expect many other DDs to be present under other hats. We will be having 2 days of unconference on GSoC and free software related topics. We all look forward to reporting from California on Planet and soc-coordination@l.a.d.o! All of our students had a wonderful experience, even if they couldn t come to DebConf, that is best shared in their own voice, so without further ado, our successful projects: Multi-Arch support in APT by David Kalnischkies, mentored by Michael Vogt apt-get install MultiArch does mostly work now as most code is already merged in squeeze, but if not complain about us at deity@l.d.o! Still, a lot left on the todo list not only in APT so let us all add MultiArch again to the Release Goals and work hard on squeezing it into wheezy. Debbugs Bug Reporting and Manipulation API by David Wendt Jr., mentored by Bastian Venthur Hello, I m David Wendt, and I went to Debconf10 to learn more about the development side of Debian. Having used it since the 9th grade, I ve been intimately familiar with many of Debian s internals. However, I wanted to see the developers and other Debian users. At DebConf, I was able to see a variety of talks from Debian and Ubuntu developers. I also got to meet with my mentor as well as the maintainer of Debbugs. Content-aware Config Files Upgrading by Krzysztof Tyszecki, mentored by Dominique Dumont Config::Model is now capable of manipulating files using shorter and easier to write models. Thanks to that, packagers may start experiment with creating upgrade models. Further work is needed to support more complicated config files Dominique Dumont is working on DEP-5 parser, I ll shortly start working on a cupsd config file parser.
The best thing about DebConf10 is that every person I talked with knew what I was doing. I had a mission to get some feedback on my project. Everybody liked the idea of making upgrades less cumbersome. On the other side, it was my first visit to United States, so I decided to go on a daytrip on my own (instead of staying inside the building, despite heat warnings). I had a chance to visit many interesting places like Ground Zero, the UN headquarters, Grand Central Terminal, Times square and Rockefeller Center that was a great experience. Hurd port and de-Linux-ization of Debian-Installer by J r mie Koenig, mentored by Samuel Thibault Debconf10 was great! Among other people working on the installer, I met Aur lien Jarno from the Debian/kFreeBSD team and we worked together on a cross-platform busybox package. Besides, the talks were very interesting and I ve filled my TODO-list for the year.
For instance I learned about the Jigsaw project of OpenJDK, and how Debian would be the ideal platform to experiment with it. More generally, some people think Debian could push Java 7 forward and I d like to see this happen. Smart Upload Server for FTP Master by Petr Jasek, mentored by Joerg Jaspert I must say that it was great time for me in NY, I ve met and talked and coded with people from ftp-master team like Torsten Werner who helped me to push the project a bit further and with some other people who were looking forward to release of the tool which I hope they will use quite soon. Everybody interested, everybody excited, really cool place and time. And I can t forget the Coney Island beach and stuff, lot of fun, lot of sun;) Aptitude Qt by Piotr Galiszewski, mentored by Sune Vuorela Currently, development branches support full features searching, viewing extended package s informations, performing cache and packages operations. Code and GUI still require a lot of work which will be continued. Informations about further progress could be found on aptitude mailing list and repository rss channel. Debian-Installer on Neo FreeRunner and Handheld Devices by Thibaut Girka, mentored by Gaudenz Steinlin For me, DebConf 10 started at the airport, where Sylvestre Ledru (whom I didn t know of before) was wearing a GSoC 2007 t-shirt, that is, given the circumstances, almost equivalent to say I m a hacker, I m going to DebConf 10 .
I ve spent my time at the conference attending various talks, hacking, meeting DDs and other hackers (amongst others, my co-mentor Per Andersson, Paul Wise, Julien Cristau, Christian Perrier, Cyril Brulebois, Martin Michlmayr, Colin Watson and Otavio Salvadores who I have to thank for his patience while dealing with my questions), chatting, cross-signing keys, rushing to finish eating before 7pm, getting sunburnt, sightseeing (thanks, Arthur, for the lightning-fast tour of Manhattan!), and so on. Debian Developers and community, we count on you. See you next year! (cross-posted to debian-devel-announce@l.d.o and soc-coordination@l.a.d.o)

Hello Following a discussion on #debian-perl IRC channel, I ve proposed to provide a script to parse DEP-5 files. The goal is to be able to parse *and* validate DEP-5 files. DEP-5 is a
proposal to make debian/copyright machine-interpretable. This proposal is driven by Lars Wirzenius. With Config::Model, any evolution of DEP-5 specification will
be easy to include in the DEP-5 model read by Config::Model. What DEP-5 model ? To keep a long story short, let s say that DEP-5 model is a description of DEP-5 syntax and semantic that can be used by Config::Model to perform validation. For more detail on how to create a model, please read this doc. In other word, DEP-5 model is DEP-5 document translated into a special format. First step was to directly edit the doc and munge it into a YAML document describing the structure of DEP-5. Here s a small extract of this YAML file (slightly edited to remove most long descriptions) :

 
---
class:
  Debian::Dep5:
    class_description: >
       Machine-readable debian/copyright
    accept:
      name_match: X-.*
      type: leaf
      value_type: string
    element:
      Format-Specification:
        mandatory: 1
        type: leaf
        value_type: uniline
        description: >-
          URI of the format specification, such as ...
      Name:
        type: leaf
        value_type: uniline
      Files:
        type: hash
        index_type: string
        ordered: 1
        cargo:
          type: node
          config_class_name: Debian::Dep5::Content

During this YAML file creation step, the problem raised by the License keyword became obvious because of License properties:

• Limited number of valid License (no problem, let s use an enum)
• License names are not case sensitive (optimism goes somewhat down)
• License names have version number and an optional + suffix (ok, let s use a regular expression with Config::Model s brand new match specification)
• License can be combined with and or or . (uh oh, the match regexp will not be enough. A grammar would be better.)
• License can specify an abbreviation or the full text of the license.

Long story short, I had to add to Config::Model the possibility to specify a Parse::RecDescent grammar to validate a value. More on this later. Of course, the first draft of a model in YAML was far from being perfect. So the second step was to load it with config-edit-model. I had to fix a number of YAML errors and then some errors in the model description. Then, I had to write a parser to load the DEP-5 data into Config::Model tree. I first used Rapha l Hertzog s Dpkg::Control::Hash module. But this one is not able to cope with repeated fields without clobbering them. So I had to provide my own parser. The parser is divided in 2 parts:
- the parse function to load DEP-5 data in a simple data structure
- the read function to load the simple data structure into Config::Model s configuration tree You can view the code on Config::Model repository. Then the model is divided in 3 configuration classes:

• Debian::Dep5: the root class
• Debian::Dep5::Content: To represent Files specification
• Debian::Dep5::License

And the full model of Dep-5 can be also read on Config::Model repository:

• Dep5.pl.
• Dep5::Content
• Dep5::License

(The models are biggish because they include help text taken from DEP-5 documentation) Now some explanation is required on how is performed the License validation. The trick is that each License used must be listed in Dep5 s license parameter which is specified this way (in YAML syntax):

 
License:
  type: hash
  index_type: string
  allow_keys_matching: '^(?i:Apache Artistic BSD etc... other)[\d\.\-]*\+?$'
  cargo:
     type: leaf
     value_type: string

So this License element contains the list of licenses with their full text and only Licenses whose name matches the regular expression are accepted. Now, let s explain how the files are tied to the declaredlicenses. The Debian::Dep5::Content class had a License element that represent the relation between the files and the License(s). This bond is represented by Debian::Dep5::License configuration class. The abbrev and full_license elements are fairly obvious. The abbrev element is another matter. Here s its declaration (minus the description and help):

 abbrev:
 type: leaf
 value_type: uniline
 default: other

So far, so good. Now the meaty part: the validation requirement based on Parse::RecDescent

grammar: "license (oper license)(s?)
          oper: 'and'   'or'
          license: /[\\w\\-\\.\\+]+/i\n
               # PRD action to check if the license text is provided
               $return = $arg[0]->grab('! License')->defined($item[0]);
               "

This grammar specifies:

• The syntax of the License line itself (hence something like Perl or GPL )
• An action performed when the grammar is matched. Using Config::Model API, this Perl snippet checks that the License abbreviation has a corresponding License declared in Debian::Dep5 License hash

This way, an abbreviation cannot be used without a proper License statement. This code is the first stab. Some more work is to be done soon:

• Implement exception parsing
• Provided DEP-5 writer
• Provide config-edit-dep5 cli

Anyway, I ll soon release Config::Model with this first version of DEP-5 parser. As always feedback are more than welcome. All the best update: added missing Parse::RecDescent link

Hello Thanks to Google, Debian and more importantly Krzysztof Tyszecki, the accept feature discussed in episode 2 is now implemented and tested in Config::Model 1.206 and Config::Model::Itself 1.216. Next task is to create a minimal model to enable upgrades for cupsd.conf. This minimal model will heavily use the new accept feature coded during this GSoC. Cups configuration is an interesting use case because:

• cupsd.conf is often upgraded (at least in Debian/sid)
• its syntax and structures are more complex than configuration found in INI files (although, cupsd.conf needs a new apache like read/write backend :-/ )

Next episode should provide more details on the work required to provide this minimal model. All the best

Hello I was on business trip last week in Frankfurt. During the preparation of this trip, I had a sudden inspiration: why not benefit from this HP paid trip to meet other Perl or Debian guys. I googled for some Frankfurt am Main Perl or Debian group. (Please mind the am Main part, it s important as I ve learned there are several Frankfurt city in Germany ) I was lucky enough that Frankfurt-pm monthly meeting occurred on one free evening during my trip. So I looked for the agenda (good, they welcome presentations), subscribed to their mailing list (mostly German, but English is accepted) and proposed a presentation similar to the one I gave in Fosdem. So here I am, Tuesday evening, after a long meeting day for business, ready to give this presentation in a Japanese restaurant in Frankfurt. Since the audience was different from FOSDEM s, I offered to tune the presentation with more Perl related details. Thanks to LyX, Beamer and some evil red TeX, I quickly re-inserted some Perlish slides, and off we go. Well almost. Food came in just after the first slide. So we interrupted the session for excellent japanese plates :-p Among the audience, one guy was following the presentation with acute concentration. Max was already thinking on how to use Config::Model for Padre s configuration. After the presentations, We discussed a bit on the work needed to use Config::Model with Padre. Roughly and not necessarily in that order:

• Create a model for Padre s config
• Call Config::Model API from Padre
• Provide a Wx GUI interface instead of a Perl/Tk interface for a smooth integration (although a proof of concept may be possible with Perl/Tk and Wx )

Time will tell if this idea will be done or not, but I really enjoy the idea. This would be a great use case for Config::Model. All the best

Hello Currently Config::Model can upgrade /etc/ssh/sshd_config file because Sshd model is complete. All 80 parameters mentioned in sshd_config man pages are described there. The whole model (including doc is about 1000 lines long). If one just want configuration upgrade capability, requiring a complete model is too much work. The aim of this GSoC project is to find a way to provide upgrades at a reasonable cost. Ep 01 focused on what feature was missing from Config::Model to provide a model that could handle unknown parameters in most cases to enable upgrades without a complete model. This covered the use case of an unmaintained model facing software evolution. Now, let s go on with the OpenSsh example and let s see what would be the minimal model that would enable upgrades from older sshd_config version to a more recent one. (Note that this blog is based on upgrade requirements mentioned in sshd_config man page). This will cover the use case of a maintained model targeted for upgrades. From last blog, we know that this minimal model must feature:

• structural information (i.e. Match parameter)
• upgrade information (KeepAlive to TCPKeepAlive)

Let s tackle the structure of this minimal model by re-using the current model structure. We will need 2 classes:

1. Sshd: to handle all leaf parameters a the the Match parameter
2. Sshd::MatchElement: to handle parameters within a Match block

Sshd::MatchElement will need to handle unknown leaf parameters (exceptd Match parameters), so its declaration should be like: 'Sshd::MatchElement' =>
accept =>
match_not => '/Match/i'' ,
type => 'leaf',
value_type => 'string'


Note that there s no element declaration. The accept structure means that Config::Model will accept any parameter that does not contain match in its name and will handle it as a string parameter. (Note that this feature is not yet implemented in Config::Model) Now, we must declare the main class: Sshd. It will feature the a wider accept statement and element declarations for the following parameters:

• Match (the only structural element)
• KeepAlive (obsolete parameter)
• TCPKeepAlive (value migrated from KeepAlive)

Here we go: Any unknown parameter will be accepted by Sshd configuration class: accept =>
type => 'leaf',
value_type => 'string'
, Here are the element that require a special treatment: Match just refer to the class declared above
Match =>
type => 'hash',
index_type => 'uniline',
cargo =>
type => 'node',
config_class_name => 'Sshd::MatchElement'
, KeepAlive is the obsolete parameter. Parameter with status 'deprecated' are handled by Config::Model but will not be written back in the configuration file. Hence re-using the deprecated information elsewhere is more than recommended.
KeepAlive =>
type => 'leaf',
value_type => 'enum',
status => 'deprecated',
choice => [ 'no', 'yes' ]
, Here's the new parameter. It's value is computed from KeepAlive.
TCPKeepAlive =>
type => 'leaf',
value_type => 'enum',
choice => [ 'no', 'yes' ],
migrate_from =>
formula => '$keep_alive',
variables => keep_alive => '- KeepAlive'
,
,
Now that we have the model, we must figure out how to read and write value with minimal coding efforts. Due to the mismatch between the syntax of the file (flat structure) and the actual structure (special Match parameter), a dumb parser/writer cannot be used. A parser that takes into account Match is required. Either dedicated Perl code (like the parser/writer delivered with Config::Model::OpenSsh) or use Augeas and its sshd lenses. In summary, we ve seen that the model required to perform upgrades is about 30 lines instead of the 1000 lines required for a complete model. On the other hand, the syntax of sshd_config makes the parser and writer harder to write. But, normally, this parser/writer should not evolve during the life of OpenSsh project. Now the question that I cannot answer is: Can a packager handle the extra work to maintain this minimal model ? Feedback is welcome here Next episode will study how upgrades based on Config::Model can be applied on files with other syntaxes. All the best

Hello The GSoC project Krzysztof and I are working aims to facilitate configuration upgrade during package upgrades. Most of the cases, this upgrade should not require any input from the user, even if the user had previously customized his configuration file. Currently configuration upgrade may ask questions to the user which may be hard to answer for most non-technical users. For more details see PackageConfigUpgrade on Debian wiki. (If you are not familiar with upgrade issues, you might want to read this page.) At the 2 extremes of upgrade tools, we have:

• tools based on diff3 (like ucf)
• Config::Model based upgrades

Each tool has its own advantages and drawbacks. On the plus side of diff3 tools :

• minimal work required on upstream or packager

On the other hand, here are the issues with diff3 based tools:

• may produce syntactically wrong files
• may leave conflicts unresolved
• may leave duplicated (and conflicting) statements
• may loose user data

For more details on diff3 issues, see Benjamin Pierce s paper (thanks to David Lutterkort from Augeas for the info) On the other end of the spectrum, Config::Model pros are:

• Very robust, should work in most cases
• Can be set up to migrate user data from old config format to new format
• Leave upstream more room to change their project

But, Config::Model main problem is:

• Lot of work required from upstream or packager to create models

diff3 tools is lackluster for users. While Config::Model puts too much strain on packagers because it requires configuration models where all parameters are defined and declared in the model. For fast evolving projects, this can be a huge recurrent task (been there, done that for Xorg) . (Well, this recurrent task is a problem until doc, implementation and config model can be extracted from a single meta-description But I digress, this may be a project for GSoC 2011 :-p ) So, this GSoC project (for 2010) aims to find a compromise between these 2 extreme cases. On Config::Model, I ve always had a drawer statement whenever I was asked why Config::Model does not handle unknown parameter:

a configuration file cannot be validated if an unknown parameter can t be distinguished from a user typo.

This stance is fine for casual user interaction on a stable system: an unknown parameter is most likely an error. And the user must be warned of his error as soon as possible. For a stable distro release, packagers should have the time to provide complete models, so basing upgrade on complete models should be possible (famous last words ?). On the other hand, a lot of configuration upgrades will be done on unstable systems where software evolve quite fast, where models will likely fall behind software evolutions. Another shorcoming of my drawer statement is that it assumes user interaction where erroneous input is more likely. In case of configuration upgrades, there should be no user interaction. And we can assume that the config file to be upgraded was used (and thus validated) by the old version of the software. So unknown parameters should be tolerated and managed as best as possible. Now, the big question is: how ? In all attempts I ve seen in managing upgrades that goes beyond diff3 tools, the configuration is stored as structured data. Sometimes this structure can be infered from the configuration file syntax (shell vars, INI files, YAML, XML), sometimes not (sshd config file). In the latter case, some structural knowledge must be built in the upgrade tool. Currently, Config::Model is designed to bring a complete description of the structure and semantics of a configuration file. This is perceived as bringing too much structural and semantic knowledge ( too semantic ). So the maintenance cost is perceived as too important. That may be right or wrong, but that does not matter. Perception is more important here. So, let s figure out a way to reduce the amount of work required to perform upgrades (you may want to read a little bit more on configuration model creation before going on ) One possibility would be to support configuration models that allow unknown leaves in nodes. Such a model would provide a kind of fallback leaf description. Something like: this parameter is unknown, let s assume it s a simple string value . Let s consider sshd_config example to see how such a behavior would pan out for some upgrade scenarios. sshd model is made of 2 main classes:
- Sshd
- SshdMatchElement The second one contains all parameters allowed in a Match class (in fact, Match parameter is the only one in sshd that defines a new hierarchical level. All other parameters are simple leaves). Now let s consider typical upgrade scenarios from old version (with old models) to a more modern version. Let s assume that the model is lagging behind and the model does not follow sshd evolutions. So Config::Model will face 3 upgrade cases (extracted from sshd config history):

1. Unexpected parameter that are actually simple leaf parameters. E.g. introduction of ClientAliveInterval.
2. Obsolete parameters that should be migrated. E.g KeepAlive is renamed into TCPKeepAlive
3. New structural parameters (introduction of Match element)

So what would happen with a model allowing unknown parameters but lacking specific instructions for these upgrades:

1. ClientAliveInterval value would be kept.
2. KeepAlive would be kept as is.TCPKeepAlive would also be kept. No migration is performed, but the configuration would be good. As long as sshd supports the old parameter, we re good. :-/
3. Without knowledge of the structure brought by Match parameters, Config::Model would consider that parameter in Match block would duplicate parameters in the main block and remove the duplicate. User data may be lost.

So, there s not silver bullet. Let s resume what we ve learnt:

• to perform upgrade, the structure of the configuration must be specified
• A minimal model that would perform upgrade for Sshd without any validation would require only knowledge of Match parameter

Next step is to figure out what would happen if the same strategy is applied to other types of configuration files. But that will be for another blog. All the best

Hello As the author of Config::Model, I ve often pondered whether my project was mature enough to be released as 1.0. After all, every time I seriously use it, I find new bugs or need to make it easier to use or even add some new features. So I thought that my software was not good enough for V1.0. Then again, all other software have the same issues: fix bugs, improve usage and follow user requirements. Then, I ve realized that wondering about software quality is not the right question. Sure, you need a decent quality level for 1.0. But the more important is not there. The most important is the compatibility pledge. Do I pledge to keep backward compatibility so people can rely on me and my software? Will I do my utmost to preserve the work done by others ? In fact, that s what I ve been doing for several months now, all the changes I ve made are backward compatible (even if warnings are issued) and people have a smooth migration path. So, yesterday, I ve released Config::Model V1.001. Ta-da !