Search Results: Config::Model

20 April 2012

Dominique Dumont: A success story for Config::Model

Hello Here s a mail telling how the Config::Model Perl module was used to refactor existing configuration tools in Perl. Some punctuation and blank lines were added to improve the flow of this text. The full name and mail address of gkr is withheld on his request.
I took over a perl script that was responsible to pull data from several sources and push it after validation and re-packaging including some meta data into one of our production systems. The script was never intended to be used for more then a few month. But as things go, we were still using it after a few years. Only now for a lot more sources. Since all the configuration of sources and meta data were contained as a single hash in this script, it became very unwieldy. Although the configuration seldom changed, once it got added it was not an option to keep it like this especially as we decided to prepare a Debian package for faster installation and version tracking. So I had to re-work it and was looking for some library that was allowing me to define how the configuration has to look like, providing sensible hard coded and computed defaults for some of the values. This was when I found Config::Model on Cpan. It was, after some digging into the documentation, quite simple to define a rough first version of the complete config, including global default values as ini file and very simple to read in and write out. A more advanced version was not working because the Config::Model in Debian squeeze did not provide needed features. Switching to yaml as configuration file format not only increased readability but also worked with the standard Squeeze package. Consistency is checked automatically inside the model so broken configurations are more unlikely in the future. Of course I had some work re-factoring the original source but Config::Model allowed an easy addition of a value-checked and documented configuration file. To access the Config::Model::Instance I added small wrapper packages that allowed an easy access of the config elements by name to make the source easier to understand. The re-factoring needed for creating a Debian package for the Script which is now a set of modules and a small executable was simple once I had Config::Model working, since I was able to add new configuration items effortlessly and remove a lot of hard coded parameters. I don t use the cli tool yet for configuration editing but that s going to be the next step.
Many thanks to gkr for this feedback. Let s hope he will continue to give feedback on his usage of Config::Model. All the best
Tagged: config-model, configuration, debian, Perl

13 April 2012

Gregor Herrmann: cme fix dpkg-copyright

a short note to all fans of Copyright-Format 1.0: if you have debian/copyright files formatted according to one of the myriads of revisions of DEP5 & want to convert them to the released format, just run
cme fix dpkg-copyright
& be done with it.

cme is in the libconfig-model-perl package, & you should try to use the version from unstable, since Dominique constantly improves it (& he's also always open to proposals & nit-pickings from me merci beaucoup !).

More info about Config::Model on its homepage.

5 April 2012

Dominique Dumont: My activities during Perl/QA hackathon in Paris

Hello Last week-end, I ve participated Perl/QA hackathon in Paris. Here s a short summary of the main activities during this week-end. I was not in the best of shape due to a nasty (biological) bug that wore me down before the hackathon. First of all, I discussed with rjbs about the bunch of debian patches I ve written for Software::License. These patches (and hacks) are used in Debian to provide licenses summaries in Debian::Dpkg::Copyright model to help write Debian copyright files. License management is boring but necessary. cme and Software::License help in making this task slightly less boring. Ricardo kindly suggested some modifications and agreed to include my patches. I implemented these modifications directly during the hackathon. The other tasks during this week-end were (not necessarily in that order): Many thanks to FreeSide who sponsored my travel, to the hackathons organisers and to all the participants for their welcome. All the best

16 March 2012

Dominique Dumont: Config::Model and cme to help debian transitions

Hello As maintainer of libwx-scintilla-perl, I had to update the package to update a dependency declation to close bug #662427. The dependency was good enough for the package to work but it blocked the linpng15 transition. This is yet another detail to remember when updating package: whether the dependencies are impacted by a transition. As I m really bad at remembering such details, I ve added the relevant check in the dpkg control source model used by cme. Now running cme check dpkg will warn you if a dependency impacts a transition. And cme fix dpkg will fix you dependency list as resquested by a transition. Well, that holds true for the transition I m aware of. Feel free to contact me if more transition checks are needed. For those who are curious (or want to send me a patch for another transition), here s the actual implementation of these new checks. All the best

8 March 2012

Raphaël Hertzog: People Behind Debian: Gregor Herrmann, member of the Perl team

Photo by Aigars Mahinovs

I followed Gregor s evolution within Debian because I used to be somewhat active in the Perl team. His case is exemplar because it shows that you don t need to be an IT professional to join Debian and to make a difference. His QA page is impressive with hundreds of packages maintained and hundreds of non-maintainer uploads too. While he started out slowly, I remember meeting him at Debconf 7 in Edinburgh and after that he really got more implicated. Again a case of someone joining for technical reasons but getting more involved and staying there for social reasons! :-) Let s jump into the interview and learn more about him. Raphael: Who are you? Gregor: I m 41 years old, and I live in Innsbruck, Austria, in a shared apartment with a friend of mine. In my day job, I m working at the regional addiction prevention agency, so I m one of the few Debian guys who s not an IT student or professional. I started maintaining packages in 2006, and I am a DD since April 2008. Raphael: How did you start contributing to Debian? Gregor: After having used Debian on servers for some years, I finally switched to it on the desktop after some procrastinating. Soon afterwards I wanted to know more about the making-of , started to join mailing lists, filed bugs, and tried to learn packaging. Luckily I quickly found a permanent sponsor Tony Mancill, and we re still co-maintaining each others packages. And when I packaged my first Perl modules, Gunnar Wolf invited me to join the Debian Perl Group, an offer I accepted a few days later. And I m still there :) Later, the NM process, although it involved some waiting times, was also a good learning experience due to my AM Wouter Verhelst. (And in the meantime the organization of the NM process has vastly improved, from what I hear.) So my starting point for joining Debian was my curiosity but what really helped me to find my way into the project was the support of the people who invited and helped me. Raphael: What s your biggest achievement within Debian or Ubuntu? Gregor: I m not sure I can name a single big achievement but I guess I can say that my contributions to the Debian Perl Group have helped to make and keep the team a success story. Raphael: The pkg-perl team seems to work very well. As an active member, can you explain us how it is organized? How do you explain its success? In particular it seems to be a great entry point for new contributors. Gregor: The team is huge, both in numbers of members and packages (over 2200). Since last DebConf we manage our source packages in git, we have 2 mailing lists and an IRC channel, and we manage to keep an overview by using PET, the Package Entropy Tracker. It s true that we get new members on a regular basis; we try to invite people (like it happened to me 6 years ago :) ) but there are also quite a few new contributors who find our docs and introduce themselves on the mailing list. Maybe someone should conduct a study and ask them what motivated them to join. :) We hand out group membership/commit access quickly, and we try to mentor new contributors actively during their early times in the group. Some of them leave for other projects after some time, but many also stay and become DDs later. I m not sure what the reasons for the group s success are, maybe a combination of: For everyone interested in joining the Debian Perl Group, our Welcome page on the wiki is a good starting point. Raphael: What are your plans for Debian Wheezy? Gregor: Nothing overly exciting. What I should do is getting a newer JabRef into Debian (which involves packaging some new Java libraries any takers?). A solution for libdatetime-timezone-perl (which ships timezone data converted to Perl modules and tends to get outdated when the timezone data change) would be nice; let s see if #660404 leads to some results And some Perl packages will also need a bit of work for the hardening build flags release goal (cf. #657853). Raphael: What s the biggest problem of Debian? Gregor: Inertia. While I really like the fact that Debian is a volunteer project, and that every contributor works when and on what they decide to work on, I get the feeling that Debian could do better in moving forward, innovating, taking decisions. I also think that more uniformity in managing source packages would make things easier; it s quite amazing to see how many source formats, packaging helpers, patch systems, RCSs etc. are used all over the archive. I m not advocating for mono-cultures, and I consider this diversity a strength in general, but having to find out first how this particular package works when preparing a bug fix can be annoying. On the bright side, I think that the myth Debian and its mailing lists are mostly about flames can be seen as dispelled in the meantime. Sure, sometimes the tone could be a bit more civil, but in general most of the interactions I ve seen in the last years were friendly and helpful. IMO, the Debian Project consists of mostly nice and cooperative people, and that s what makes it fun for me. Raphael: You re one of the most dedicated participants to RCBW (Release Critical Bugs of the Week), an initiative to fix RC bugs every week. How much time do you spend on it? What would you advise to people who are considering to join the movement? Gregor: I got into the habit of fixing RC bugs after having been invited to my first Bug Squashing Party in Munich some years ago. During this weekend I saw that fixing RC bugs can be fun, is often not that difficult, and gives a warm fuzzy feeling :) I can definitely recommend attending a BSP if one happens to be organized near you. After tasting blood at this first BSP I tried to continue looking at RC bugs, and I guess I spend something around half an hour per day on it. I usually blog about it once a week, in order to motivate others to join in. And joining is easy: just take a look at the tips people like Zack, Vorlon, or me have written. You don t have to be a DD to help, many of my NMUs are based on patches that others kindly prepare and send to the BTS kudos! Another nice aspect is that the RC bug list contains problems from different fields: general packaging problems, language-specific issues, policy violations, etc. So there s something for everybody, and you don t have to be an expert in all fields to fix a specific bug. What s rewarding about fixing RC bugs is not only the feeling of accomplishment and the knowledge about having helped the next release I also received quite a few Thank you mails from maintainers who were busy at that time and appreciated the help. Raphael: Do you have wishes for Debian Wheezy? Gregor: Well, there s not so much left of the Wheezy release cycle if we manage to freeze in June :) Some quick thoughts for Wheezy and Wheezy+1: Raphael: Is there someone in Debian that you admire for their contributions? Gregor: There are many people in Debian I admire, too many to name them all. The first one that comes to my mind is Russ Allbery who not only does great work from lintian to Debian policy but who also sets a great example of communicating in a perfectly polite and respectful way even in heated discussions.
Thank you to Gregor for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

24 February 2012

Dominique Dumont: Config::Model: new cme command is available

Hello I ve (finally) released a new version of Config::Model. The main change for users is the deprecation of the config-edit program in favor of cme program. Instead of using options, this cme uses command keywords like git, so users will have more possibilities while typing less. bash completion is provided for cme command and options. Following Debian annoucement regarding the recommended format of Debian copyright file (aka DEP-5), I ve also updated the URL in Debian copyright model. If your package is already in a DEP-5 format, you can update the URL with this simple command: cme fix dpkg-copyright Check the wiki on github for more example of cme command. All the best

10 February 2012

Dominique Dumont: Dpkg: edit debian/control description without worrying about leading . and

Hello In Debian package, the debian/control file has a specific syntax where each line must begin with a space and paragraphs are separated by a single . . If you want to follow DEP-5 syntax for debian/copyright files, you have a similar problem when comes the time to fill the license text for creative-common license: it s easy to miss a space or a dot. Let s say I want to add a new section in the description of my package. Here s the current description:
Description: module to automate definition of a DBIx::Class::Schema
 DBIx::Class::Schema::Loader is an extension to DBIx::Class that automates the
 definition of a DBIx::Class::Schema by scanning table schemas and setting up
 columns and primary keys appropriately. It supports MySQL, PostgreSQL, SQLite
 and DB2.
 .
 Bare table definitions are fairly straightforward, but relationship creation
 is somewhat heuristic, especially with respect to choosing relationship types
 and names, as well as join types. The relationships generated by this module
 will probably never be as well-defined as hand-generated ones.
I want to add This package is awesome but I don t want to be bothered by leading dots and white spaces. First, I go in the package directory, then check the syntax with cme:
$ cme check dpkg
Then create a loop directory, where the dpkg content will be mapped to a fuse directory:
$ mkdir loop
$ cme fusefs dpkg -fuse-dir loop/
Mounting config on loop/ in background.
Use command 'fusermount -u loop/' to unmount
$ cat loop/control/binary/libdbix-class-schema-loader-perl/Description
DBIx::Class::Schema::Loader is an extension to DBIx::Class that automates the
definition of a DBIx::Class::Schema by scanning table schemas and setting up
columns and primary keys appropriately. It supports MySQL, PostgreSQL, SQLite
and DB2.
Bare table definitions are fairly straightforward, but relationship creation
is somewhat heuristic, especially with respect to choosing relationship types
and names, as well as join types. The relationships generated by this module
will probably never be as well-defined as hand-generated ones.
Then edit loop/control/binary/libdbix-class-schema-loader-perl/Description with your favorite editor. For the sake of this blog, I will use echo to edit this file:
$ echo -e "\nThis module is awesome" >> loop/control/binary/libdbix-class-schema-loader-perl/Description
Now umount the loop (note that the actual debian/control is not changed before this step):
fusermount -u loop
Now the result:
$ cat debian/control
[...]
Description: module to automate definition of a DBIx::Class::Schema
 DBIx::Class::Schema::Loader is an extension to DBIx::Class that automates the
 definition of a DBIx::Class::Schema by scanning table schemas and setting up
 columns and primary keys appropriately. It supports MySQL, PostgreSQL, SQLite
 and DB2.
 .
 Bare table definitions are fairly straightforward, but relationship creation
 is somewhat heuristic, especially with respect to choosing relationship types
 and names, as well as join types. The relationships generated by this module
 will probably never be as well-defined as hand-generated ones.
 .
 This module is awesome
Here s another example to fill the license text for a license while respecting DEP-5 syntax, (done after the cme command):
# creating this dir will create a new DEP-5
# standalone license section with name CC-BY-30
mkdir loop/copyright/License/CC-BY-30
# fill the text part of the  license
wget http://creativecommons.org/licenses/by/3.0/legalcode -O - \
   html2text -style pretty > loop/copyright/License/CC-BY-30/text
$ fusermount -u loop
$ cat debian/copyright
[...]
License: CC-BY-30
 .
 .
 .
                                Creative_Commons
 .
 .
 Creative Commons Legal Code
 .
 .
 Attribution 3.0 Unported
[...]
And that s it. (note that cme command is new and is available only from version 2.004 of Config::Model) Of course, there s more than a awy to do it: you can also run cme edit dpkg and add or edit license text in the GUI (or in an editor launched by the GUI). cme will take care of the syntax details. All the best

16 December 2011

Dominique Dumont: Config::Model new command line: And the winner is

Hello Following the suggestions provided after my post What name for Config::Model s new command line ? cfg or something else ? , I ve considered cmc and cme as a good candidates. But, cmc is used by a C mol compiler software (don t ask me what it is ). cme is also a very good name. So the winner is cme Next version of Config::Model will provide /usr/bin/cme. The old config-edit command will be provided for a few months to preserve backward compatibility. Thanks to all people who took the time to reply :-) All the best

12 December 2011

Dominique Dumont: What name for Config::Model s new command line ? cfg or something else ?

Hello As Damyan mentioned last summer in Debconf, the current command interface to Config::Model Perl module is rather cumbersome as it involves quite a lot of typing. First, config-edit command name is too long. Even with the help bash completion, this does not compare well with git or hg command. Then all operation require options. For instance, the -application option is required to specify what you will be working on. A required option is a good example of an oxymoron. Which may be funny but which is not user friendly So, here s the synopsis of the new command I m working on:
# edit dpkg config with GUI (Tk or curses, or readline)
cfg edit dpkg 
# just check the validity of the file, show warnings
# and suggested fixes
# does not modify the file
cfg check dpkg
# check the file, remove deprecated parameters,
# migrate data to new parameters and save
cfg migrate dpkg 
# like migrate, but also apply all suggested fixes
cfg fix dpkg 
# like migrate and modify configuration
# with command line argument
cfg modify dpkg source format="quilt (3.0)"
# access dpkg parameters through a fuse file
# system. data are saved when fs is unmounted
cfg fusefs dpkg fuse-dir
# dump configuration data in config-model format
cfg dump dpkg   
# list all available applications
cfg list 
# more general synopsis
cfg [ global_options ] command application [ options ] arguments
This synopsis use dpkg as an example, but it could be used for any of the available models (e.g. ssh, lcdproc, multistrap ). The main question I have for you is: Is cfg name good ? I mean it s short, descriptive enough. But it s also quite ugly. Does anyone have a better idea ? And what do you think of the synopsis shown above ? Are the sub-command name descriptive enough ? All the best

30 October 2011

Dominique Dumont: Config::Model: How to test configuration models

Hello With Config::Model, configuration models are created to validate configuration data. But, before that, how can we validate a model ? This has long been a sore spot of Config::Model. During its development, I ve progressively enhanced a test script to tests the various models (and their corner cases) shipped with Config::Model. This script is able to test several models with several subtests. Currently, more that 400 unit tests are done on 5 models and about 50 configuration files. Which is great, but usable only inside Config::Model distribution. Which is not so great So I ve bitten the bullet and created a new Config::Model::Tester class from this test script. This new class is shipped with Config::Model 1.260 (also available on Debian/sid). For instance, let s see how this tester is used to test Xorg model (shipped in Config::Model::Xorg). Xorg features a small test file (t/model_test.t):
use warnings;
use strict;
use Config::Model::Tester ;
use ExtUtils::testlib;
my $arg = shift   '';
my $test_only_model = shift   '';
my $do = shift ;
run_tests($arg, $test_only_model, $do) ;
The xorg files to test are specified by t/model_tests.d/xorg-test-conf.pl:
$conf_file_name = "xorg.conf" ;
$conf_dir = "etc/X11" ;
$model_to_test = "Xorg" ;
@tests = (
      name => 'fglrx',  ,
      name => 'modern',  ,
      name => 'vesa',  ,
      name => 'xorg',  ,
      name => 'xorg-ati',  ,
);
1;
And the xorg.conf files are there:
$ ls t/model_tests.d/xorg-examples/
fglrx  modern  vesa  xorg  xorg-ati
Here s the output of the xorg-ati subtest:
$ perl -Ilib t/model_tests.t x xorg xorg-ati
ok 1 - compiled
# Beginning xorg test (t/model_tests.d/xorg-test-conf.pl)
# xorg uses Xorg model on file xorg.conf
# Beginning subtest xorg xorg-ati
ok 2 - Copied xorg example xorg-ati
ok 3 - Read wr_root/test-xorg-ati/etc/X11/xorg.conf and created instance with init() method with warning check
ok 4 - Ran dump_tree
ok 5 - Dumped xorg config tree in full mode
ok 6 - Dumped xorg config tree in custom mode
ok 7 - xorg write back done
ok 8 - Created instance xorg-test-xorg-ati-w
ok 9 - Dumped xorg 2nd config tree in custom mode
ok 10 - compare original xorg custom data with 2nd instance custom data
ok 11 - check that original xorg file was not clobbered
# End of subtest xorg xorg-ati
# End of xorg test
1..11
Now, it s quite easy to create non regression tests for bug triggered by err, unexpected, configuration files: Just drop the file in the example directory and edit the *-test-conf.pl file. This saves a lot of typing. All the best

6 August 2011

Bdale Garbee: FreedomBox in Banja Luka

FreedomBox activities at Debconf11 I spent the last two weeks of July 2011 in Banja Luka. The occasion was the annual Debian developer's conference, Debconf11 and preceding work week known as Debcamp. This was my tenth successive year attending Debconf, and I had a very productive and pleasant time! The facilities were good, the local team was friendly, enthusiastic, and very helpful, and in addition to giving three talks and hosting a couple panel discussions, I managed to put a burst of energy into work on FreedomBox. Several other developers working on FreedomBox were also present, and a good number of Sheeva and Dream plugs were evident in the hacklabs sporting new FreedomBox stickers. Working together in the same place for several days, we made good progress on several projects, and also had some great discussions about what we want to do going forward. image building tools For some time, I've been working towards a light-weight tool set to build FreedomBox software images. Shortly before Debconf started, I chose the name 'freedom-maker' for this tool and shared a link to a readable copy of my git repository with other developers I expected to work with in Banja Luka. With input from Bert Agaz and Jonas Smedegaard during Debcamp, freedom-maker went from almost useful to actually useful. It still deserves work to be more useful to others, but I have now pushed a copy of the git repository to git.debian.org so that we can take advantage of the tools supported there to enable others to more easily contribute to the code. Very soon, Bert plans to add support to freedom-maker for using Lars Wirzenius' vmdebootstrap to build x86 images suitable for testing in a virtualized environment. At the same time, we plan to refactor the existing code slightly to enable lists of desired packages for the various image flavors we expect to produce independently of the configuration for each specific image building tool. Jonas continued in parallel to work on his alternate packaging toolset boxer. It offers some potentially interesting features for the future, and we may eventually merge some or all of it into freedom-maker, but for now it remains a separate utility. uAP user space tools Several weeks ago, we received from Marvell the source code to two user space programs that are necessary for configuring and monitoring the binary firmware provided for the uAP wireless chip used in the DreamPlug. Early during my stay in Banja Luka, I packaged these for Debian as uaputl and uapevent, and I am pleased to note that they were quickly accepted into the archive and are now present in Debian mirrors. u-boot Another bit of code received very shortly before Debconf started was the source for the version of u-boot shipped by Globalscale in the DreamPlug units we're working with. During Debcamp, Clint Adams passed a copy of this source to Jason Cooper, who was already trying to add support for the DreamPlug to upstream u-boot, but had stalled due to a lack of information. Jason has now merged his own work with the sources we got from the manufacturer, and is making good progress towards merging DreamPlug support into upstream u-boot. Once that happens, we should be able to flash our Sheeva and Dream plug devices with a u-boot image built from the source in the Debian u-boot package, in the process enabling things that matter to us like the ability to boot from an ext2 partition, and hopefully the ability to execute command scripts from that partition instead of having to hard-code kernel filenames in flash. This will allow us to support the ongoing effort in Debian to move away from the need for kernel symlinks. DreamPlug kernels With respect to kernels, another work stream at Debconf primarily involving H ctor Or n and Nick Bane was to analyze the current state of the patches from Marvell and Globalscale used to support the DreamPlug against both upstream and current Debian kernel sources. To my surprise and our collective pleasure, the remaining patch set required against current upstream kernels is much smaller than we previously believed! There are still several patches critical to us that are not merged upstream, but the work remaining to be able to build images for our devices from mainline and Debian kernel source trees now seems like something we might be able to complete before Debian's next stable release. One of our discoveries during the u-boot and kernel work during Debconf was that Globalscale did not obtain a new machine id for the DreamPlug, but instead re-used the one for the GuruPlug series, despite there being some differences in the hardware that require at least one additional driver. After much discussion, we plan to continue using the existing machine id instead of requesting another, particularly because the ARM kernel community has apparently stopped issuing new ids for the moment. We will add a new kernel config option for the DreamPlug, however, and are likely to build distinct Sheeva and Dream kernel packages that do not require initrd for use in FreedomBox images, even if doing so is not strictly necessary. This will allow us to optimize both the in-memory footprint and boot times for our devices. software configuration Another area of investigation in Banja Luka was technology for package configuration. Mirsal Ennaime performed various tests using debconf and Config::Model, with some results reflected in this commit relating to configuring the bitcoind daemon in the bitcoin package for Debian. identity and trust management While we did not actually do any FreedomBox specific work on the trust management layer we know is necessary, after several rounds of conversation, I am now more convinced than ever that the right path forward is to base our trust relationships on OpenPGP keys using GnuPG and Monkeysphere as starting software elements. Our thinking to date is captured on an Identity Management page in the wiki. communication services Another thing that became fairly clear to me during discussions at Debconf is that in the near term, planning to build communication services around XMPP is the approach most likely to give good results. Investigating the software choices available to build an interesting XMPP infrastructure is now a high priority for me. Jonas has done some work towards configuring and integrating ejabberd or Prosody, I've started studying yate as a possible call manager and VoIP server choice with XMPP/jingle support, and we await with great interest a release from the Buddycloud developers to evaluate as a possible basis for deploying social network services. Some of these software choices will lead us to use Apache as our web services base technology because of the need for features that only it supports well among daemons that are Free Software. Jonas completed packaging GNU Sip Witch for Debian, and it is now available in the mirror network. Tzafrir Cohen and Jonas did some initial testing on its use. documentation A number of new wiki pages were written (or at least started) in order to sum up ideas, design various aspects of FreedomBox, and reflect discussions that happened during DebConf11. A lot of work is needed to complete these pages though, as well as others to capture more of the current state of the project. press coverage Finally, while in Banja Luka I got some great press coverage for FreedomBox! On Sunday the 24th, I was interviewed by the main television network serving the Republika Srpska. This led to a couple of minutes of coverage near the top of the national news program that night, immediately following the lead story about the President and several ministers appearing at Debian Day that morning to help open the conference. This interview was later re-used in another TV program that summarized Debconf11. On the morning of Thursday the 28th, I was part of a small group that spent more than an hour meeting with the Minister of Science and Technology in his office, and the relationship between Debian and our work on FreedomBox was one of the items of discussion in that meeting and the associated press conference. I'm told this resulted in more press coverage, but if true I have not seen it yet. summary On Friday afternoon the 29th, I gave a talk in the main Debconf program containing a FreedomBox Progress Report . In it, I talked about the structure of the FreedomBox Foundation, progress the foundation has made, and the work that was still then underway in Banja Luka. It was streamed live over the internet, and replays are available online. The reaction from Debian developers present was very positive, which was good to learn since by that time my energy level was quite low after the nearly two weeks of intense technical and social interaction that is Debconf! All in all, we got lots of work done on FreedomBox in Banja Luka, enough that I think at least the next few steps along the road towards an eventual "1.0" release of a reference implementation are now much clearer than they were two weeks ago!

3 July 2011

Dominique Dumont: Generate a configuration editor from a config template file with Perl: lcdproc example

Hello Creating a configuration model for Config::Model can be a boring task: When a configuration system has a lot of parameters, a lot of details need to be specified to have a complete configuration validation tool. So, all tricks are permitted to make this task more bearable. Let s see how this can be applied to lcdproc. This project requires a configuration file that supports more than 40 drivers. Each driver has it own set of parameters for a total of about 250 parameters. That s a lot to specify.. Fortunately, LCDd.conf template file is written in a way which makes it relatively easy to parse and get all required information to build a model. All drivers are listed in this template file, most parameters have default values and legal values are written in comments in a uniform way. Hence this file (and comments) can be parsed to retrieve information required for the model. This blog will describe how this task can be implemented in Perl using Config::Model modules. The code will be slightly trimmed down to keep this blog (relatively) short. All initialisation code and error checks are removed. You can get the whole script on sourceforge. The main steps are:
  1. prepare a parser for LCDd.conf template
  2. parse LCDd.conf template
  3. prepare a LCDd model skeleton
  4. translate LCDd.conf template information in a format suitable to create a model.
  5. Write the resulting LCDd model
First, here s the necessary incantation to start properly a Perl program:
use strict;
use warnings;
Then load all required libraries. Their use will be described later:
use Config::Model;
use Config::Model::Itself 1.225;
use Config::Model::Backend::IniFile;
use 5.10.0;
use IO::File;
use IO::String;
Perform some initialisation to avoid upsetting the logging system:
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init($WARN);
Let s also initialize a model object that will be very useful later:
my $model = Config::Model->new();
Now we can really start the fun part. Step 1: Create a parser for LCDd.conf (INI file)
Problem: LCDd.conf comments must also be analysed to get more semantic information. The comments must be retrieved and associated with the INI classes and parameters found in this file. Fortunately, Config::Model::Backend::IniFile is able to associate comments with the relevant parameters. But Config::Model::Backend::IniFile must store its values in a configuration tree. So let s create a model suitable for LCDd.conf template that accepts any INI class and any INI parameter Dummy::Class is used to store any parameter found in an INI class. The accept keyword with .* regular expression means that any INI parameter will be accepted in each INI class.
$model->create_config_class(
  name   => 'Dummy::Class',
  accept => [
    '.*' =>  
       type => 'leaf',
       value_type => 'uniline'
        ,
    ],
);
Now the Dummy model must provide a configuration class to hold all INI classes:
$model->create_config_class(
    name   => 'Dummy',
    accept => [
       '.*' =>  
           type => 'node',
           config_class_name => 'Dummy::Class'
        ,
    ],
);
Note that an INI backend could be specified directly here. But, some useful parameters are commented out in LCD.conf. Some some processing is required to be able to create a model with these commented parameters. See below for this processing. Step 2: Parse LCDd.conf Now the dummy configuration class is created. Let s create a configuration tree from this dummy class to store the data from LCDd.conf
my $dummy = $model->instance(
    instance_name   => 'dummy',
    root_class_name => 'Dummy',
)-> config_root;
Now, read LCDd.conf:
my $lcd_file
  = IO::File->new('examples/lcdproc/LCDd.conf');
my @lines    = $lcd_file->getlines;
And perform the pre-processing on LCDd.conf mentioned above. Just un-commenting commented parameters is required:
foreach (@lines)   s/^#(\w+=)/$1/  
Store the pre-processed LCDd.conf in a IO::Handle usable by INI backend
my $ioh = IO::String->new( join( '', @lines ) );
Create an INI backend to read the data from pre-processed LCDd.conf and store it in the configuration tree:
my $ini_backend = Config::Model::Backend::IniFile
  ->new( node => $dummy );
$ini_backend->read( io_handle => $ioh );
Step 3: Prepare LCDd configuration model Your attention please. You may remember that we invoked instance on object to create the dummy configuration tree to hold LCDd.conf data. The instance method used the Dummy configuration class. Now, we must invoke instance again on object. But this time, instance will use Config::Model::Itself. This model is Config::Model s way of eating its own dog food. The configuration tree created there will be able to hold LCDd model. Hence the root of this special configuration tree will be called meta_root to avoid confusion with the other configuration root defined above (for the Dummy model). Still with me? Good, let s create this meta tree that will contain LCDd model:
my $meta_root = $model->instance(
    root_class_name => 'Itself::Model',
    instance_name   => 'meta_model',
) -> config_root;
Create the main LCDd configuration class and store the first comment from LCDd.conf as class description:
my $first_comment = $dummy->annotation ;
$meta_root
  ->grab("class:LCDd class_description")
  ->store( $first_comment );
Append my own text in this description:
my $extra_description =
    "Model information extracted from template /etc/LCDd.conf"
  . "\n\n=head1 BUGS\n\nThis model does not support to load "
  . "several drivers. Loading several drivers is probably a "
  . "marginal case. Please complain to the author if this "
  . "assumption is false";
$meta_root->load(
     qq!class:LCDd
        class_description.="\n\n$extra_description"!
);
Add legal stuff in the model:
$meta_root->load( qq!
  class:LCDd
    copyright:0="2011, Dominique Dumont"
    copyright:1="1999-2011, William Ferrell and others"
    license="GPL-2"
!
);
Add INI backend so configuration object created from LCDd model will be able to read user s INI files:
$meta_root->load( qq!
  class:LCDd
    read_config:0
      backend=ini_file
      config_dir="/etc"
      file="LCDd.conf"
!
);
Note that all the load calls above could be done as one call. They were split for better clarity. Step 4:Extracting LCDd.conf information Now that all information from LCDd.conf template file is stored in $dummy configuration tree, it s time to use this information to enhance the skeleton of LCDd model created above. Let s first find all the INI classes defined in LCDd.conf:
my @ini_classes = $dummy->get_element_name;
Now before actually mining LCDd.conf information, we must prepare several subs to handle them. This is done using a dispatch table:
my %dispatch;
First create the default entry which will be used for most parameters. This subs is passed: the INI class name, the INI parameter name, the comment attached to the parameter, the INI value, and an optional value type. It will return a string describing a model for simple elements. For instance: class:"LCDd::MD8800" element:Device type=leaf value_type=uniline default="/dev/ttyS1" description="device to use [default: /dev/ttyS1]" Here s the subroutine invoked by default. Let s create a an anonymous subroutine and store it in the dispatch table:
$dispatch _default_  = sub  
    my ( $ini_class, $ini_param, $ini_note,
         $ini_v, $value_type ) = @_;
    $value_type  = 'uniline';
Now, prepare a string that will be used later to create the ini_class model. This string uses Config::Model s serialisation format described in Config::Model::Loader:
    my $load = qq!class:"$ini_class"
                  element:$ini_param type=leaf !;
Get semantic information from LCDd.conf template comments (written between square brackets):
    my $info = $ini_note =~ /\[(.*)\]/ ? $1 : '';
    $info =~ s/\s+//g;
Use this semantic information to better specify the parameter:
    $load .=
        $info =~ /legal:(\d+)-(\d+)/
           ? " value_type=integer min=$1 max=$2"
      : $info =~ /legal:([\w\,]+)/
           ? " value_type=enum choice=$1"
      :    " value_type=$value_type";
    if ( $info =~ /default:(\w+)/ )  
        # specify upstream default value
        # if it was found in the comment
        $load .= qq! upstream_default="$1"!
           if length($1);
     
    else  
        # or use the value found in INI
        # file as default
        $ini_v =~ s/^"//g;
        $ini_v =~ s/"$//g;
        $load .= qq! default="$ini_v"!
           if length($ini_v);
     
The model (in serialised format) is ready, let s return it and exit the subroutine:
    return $load;
 ;
Now let s take care of the special cases. This one deals with Driver parameter found in INI [server] class. This sub will create a string for an enum element. The possible values of the enum are extracted from the comment found in the LCDd.conf file:
$dispatch "LCDd::server" Driver  = sub  
    my ( $class, $elt, $info, $ini_v ) = @_;
    my $load = qq!class:"$class"
                    element:$elt
                      type=leaf
                      value_type=enum
    !;
    my @drivers = split /\W+/, $info;
    while ( @drivers
            and ( shift @drivers ) !~ /supported/ )  
      # nothing, the work is done by shift operator
      # in loop test to skip all words in $info until
      # 'The following drivers are supported:'.
      # ok, that's a hack
     
    $load .= 'choice='
          . join( ',', @drivers ) . ' ';
    return $load;
 ;
This sub invokes the default sub and add a small feature to the model to ensure that DriverPath ends with / . This is ensured by the match="/$" snippet:
$dispatch "LCDd::server" DriverPath  = sub  
    my ( $class, $elt, $info, $ini_v ) = @_;
    return   $dispatch _default_ ->(@_)
           . q! match="/$" !;
 ;
Likewise, this sub invokes the default sub with the optional 4th parameter that forces the value_type of the element. In this case, we enforce an integer element:
 $dispatch "LCDd::server" WaitTime 
 = $dispatch "LCDd::server" ReportLevel 
 = $dispatch "LCDd::server" Port 
 = sub  
    my ( $class, $elt, $info, $ini_v ) = @_;
    return $dispatch _default_ ->( @_, 'integer' );
   ;
This sub returns a string for a list element with default values:
  $dispatch "LCDd::server" GoodBye 
= $dispatch "LCDd::server" Hello 
= sub  
    my ( $class, $elt, $info, $ini_v ) = @_;
    my $ret = qq( class:"$class"
                    element:$elt
                      type=list
                ) ;
    $ret .= 'cargo type=leaf
             value_type=uniline - ' ;
    $ret .= 'default_with_init:0="\" '.$elt.'\"" ' ;
    $ret .= 'default_with_init:1="\" LCDproc!\""';
    return $ret ;
 ;
Now that the dispatch table is ready, let s really mine LCDd.conf information. First handle all INI classes in the foreach loop:
foreach my $ini_class (@ini_classes)  
Let s retrieve parameters for this INI class from the LCDd.conf template:
  my $ini_obj = $dummy->grab($ini_class);
This will be the name of the lcdproc driver configuration class (e.g. LCDd::imonlcd):
  my $config_class   = "LCDd::$ini_class";
The configuration class will also be created in a serialised format. Let s create config class in case there s no parameter in INI file:
  $meta_root->load(qq!class:"LCDd::$ini_class"!);
Now, loop over all INI parameters and create LCDd::$ini_class elements:
  my @all_ini_params = $ini_obj->get_element_name ;
  foreach my $ini_param ( @all_ini_params )  
Retrieve the value provided in template LCDd.conf:
    my $ini_v = $ini_obj->grab_value($ini_param);
Retrieve the comment attached to the value provided in template LCDd.conf:
    my $ini_comment
      = $ini_obj->grab($ini_param)->annotation;
    # escape embedded quotes
    $ini_comment =~ s/"/\\"/g;
Retrieve the correct sub from dispatch table:
    my $sub = $dispatch $config_class $ini_param 
              $dispatch _default_ ;
Run the sub to get the model string:
    my $model_spec
      = $sub->( $config_class, $ini_param,
                   $ini_comment, $ini_v );
Attach the comment from LCDd.conf as class description:
    $model_spec .= qq! description="$ini_comment"!
      if length($ini_comment);
Then, last but not least, load class specification in the model, and end the loop aroung INI parameters:
    $meta_root->load($model_spec);
   
Now create a an $ini_class element in LCDd class (to link LCDd class and LCDd::$ini_class):
  my $driver_class_spec = qq!
    class:LCDd
      element:$ini_class
  ! ;
Since server and menu are not drivers, they have a special treatment:
  if (   $ini_class eq 'server'
      or $ini_class eq 'menu' )  
    $driver_class_spec .= qq!
      type=node
      config_class_name="LCDd::$ini_class"
    ! ;
   
Here s the treatment for LCDd drivers. Setup the model with a warped node so that a driver configuration class is shown only if the driver was selected in the [server] class:
  else  
    $driver_class_spec .= qq!
      type=warped_node
      config_class_name="LCDd::$ini_class"
      level=hidden
      follow:selected="- server Driver"
      rules:"\$selected eq '$ini_class'"
        level=normal
    !;
   
Now we can load the LCDd driver model in meta root:
  $meta_root->load($driver_class_spec);
 
Step 5: save LCDd model Still with me ? Good. Here s the last part, now that the model was created in memory, let s save it in files. Config::Model::Itself constructor returns an object to read or write the data:
my $rw_obj = Config::Model::Itself
     ->new( model_object => $meta_root );
say "Writing all models in file (please wait)";
$rw_obj->write_all(
    model_dir => 'lib/Config/Model/models/'
);
That s it. Once this script is run, the directory lib/Config/Model/models/ contains a bunch of files: You can see the resulting editor in my first blog on lcdproc. Conclusion and future steps (with you?) As mentioned at the end of this blog, the result of this model generation process is far from perfect, because the information retrieved from LCDd.conf template are not complete for this task (which is normal since these comments were targeted for users). Now, I d really like to discuss with project developers to improve configuration template to generate better models. For project owner, such an improvement would give them: Please leave a comment on this blog (or send a message to config-model-users at lists.sourceforge.net) if you are interested in configuration tool generation for a project you contribute to. All the best

29 June 2011

Dominique Dumont: New configuration editor for LCDPROC

Hello The last version (1.247, available in Debian unstable as libconfig-model-perl) of Config::Model provides a brand new model for /etc/LCDd.conf. With this model, you can edit or validate your lcdproc configuration. To edit this configuration the first time, you will have to run:
config-edit -application lcdproc -force
The -force option is required to load the file the first time. (because the default LCDd.conf file contains configuration options for all drivers, even though only one them if usefull). You will get this screen:
lcdproc configuration editor

config-edit on lcdproc configuration

In this screen, you can setup the driver for your adress with a right click on Driver parameter. Once youv e selected the driver and clicked on store , the driver will be listed in the left part of the window so you can tune the parameters of this specific driver:

editing imonclcd paramaters

In this screen, I ve turned the backlight off and added a small note to remember why. This small note will be writted in a comment in /etc/LCDd.conf. Once all required modifications are done, it s time to save the configuration file using the menu entry File -> save Now, let s see the resulting file (which is a bit long due to the amount of comments in the original LCDd.conf file):
## This file was written by Config::Model
## You may modify the content of this file. Configuration
## modifications will be preserved. Modifications in
## comments may be mangled.
# LCDd.conf -- configuration file for the LCDproc server daemon LCDd
#
# This file contains the configuration for the LCDd server.
#
# The format is ini-file-like. It is divided into sections that start at
# markers that look like [section]. Comments are all line-based comments,
# and are lines that start with '
#
# The server has a 'central' section named [server]. For the menu there is
# a section called [menu]. Further each driver has a section which
# defines how the driver acts.
#
# The drivers are activated by specifiying them in a driver= line in the
# server section, like:
#
#   Driver=curses
#
# This tells LCDd to use the curses driver.
# The first driver that is loaded and is capable of output defines the
# size of the display. The default driver to use is curses.
# If the driver is specified using the -d  command line option,
# the Driver= options in the config file are ignored.
#
# The drivers read their own options from the respective sections.
[server]
# Where can we find the driver modules ?
# IMPORTANT: Make sure to change this setting to reflect your
#            specific setup! Otherwise LCDd won't be able to find
#            the driver modules and will thus not be able to
#            function properly.
# NOTE: Always place a slash as last character !
DriverPath=/usr/lib/lcdproc/
# Tells the server to load the given drivers. Multiple lines can be given.
# The name of the driver is case sensitive and determines the section
# where to look for further configuration options of the specific driver
# as well as the name of the dynamic driver module to load at runtime.
# The latter one can be changed by giving af File= directive in the
# driver specific section.
#
# The following drivers are supported:
#   bayrad, CFontz, CFontz633, CFontzPacket, curses, CwLnx, ea65,
#   EyeboxOne, g15, glcdlib, glk, hd44780, icp_a106, imon, imonlcd,
#   IOWarrior, irman, joy, lb216, lcdm001, lcterm, lirc, lis, MD8800,
#   mdm166a, ms6931, mtc_s16209x, MtxOrb, mx5000, NoritakeVFD, picolcd,
#   pyramid, sed1330, sed1520, serialPOS, serialVFD, shuttleVFD, sli,
#   stv5730, svga, t6963, text, tyan, ula200, xosd
Driver=imonlcd
# Tells the driver to bind to the given interface
Bind=127.0.0.1
# Listen on this specified port; defaults to 13666.
Port=13666
ReportLevel=3
# Sets the reporting level; defaults to 2 (warnings and errors only).
# ReportLevel=3
# Should we report to syslog instead of stderr ? [default: no; legal: yes, no]
# ReportToSyslog=yes
# User to run as.  LCDd will drop its root priviledges, if any,
# and run as this user instead.
User=nobody
Foreground=no
Hello=    Hello
Hello=    LCDproc!
GoodBye=    GoodBye
GoodBye=    LCDproc!
# The server will stay in the foreground if set to true.
# Foreground=no
# Hello message: each entry represents a display line; default: builtin
# Hello="  Welcome to"
# Hello="   LCDproc!"
# GoodBye message: each entry represents a display line; default: builtin
# GoodBye="Thanks for using"
# GoodBye="   LCDproc!"
# Sets the default time in seconds to displays a screen.
WaitTime=5
# If yes, the the serverscreen will be rotated as a usual info screen. If no,
# it will be a background screen, only visible when no other screens are
# active. The special value 'blank' is similar to no, but only a blank screen
# is displayed. [default: on; legal: on, off, blank]
# ServerScreen=no
# Set master backlight setting. If set to 'open' a client may control the
# backlight for its own screens (only). [default: open; legal: off, open, on]
# Backlight=open
# Set master heartbeat setting. If set to 'open' a client may control the
# heartbeat for its own screens (only). [default: open; legal: off, open, on]
# Heartbeat=open
# set title scrolling speed [default: 10; legal: 0-10]
# TitleSpeed=10
# The "...Key=" lines define what the server does with keypresses that
# don't go to any client.
# These are the defaults:
ToggleRotateKey=Enter
PrevScreenKey=Left
NextScreenKey=Right
ScrollUpKey=Up
ScrollDownKey=Down
# ScrollUpKey=Up
# ScrollDownKey=Down
# If you have only 4 keys, you can choose to use this:
# ToggleRotateKey=Enter
# PrevScreenKey=Up
# NextScreenKey=Down
# If you have only 3 keys, you can choose to use this:
# ToggleRotateKey=Enter
# PrevScreenKey=Up
[menu]
# You can configure what keys the menu should use. Note that the MenuKey
# will be reserved exclusively, the others work in shared mode.
# The following works excellent with 4 keys or more.
MenuKey=Escape
EnterKey=Enter
UpKey=Up
DownKey=Down
LeftKey=Left
RightKey=Right
[imonlcd]
Protocol=0
OnExit=2
Device=/dev/lcd0
# My fishes dont like the glow
Backlight=off
DiscMode=0
You will notice a few things: If you need to update the file, you will have to run:
sudo config-edit -application lcdproc
The -force option is no longer needed. If you don t like to click, you can run:
config-edit -application lcdproc -ui none -save
For instance:
config-edit -application lcdproc -ui none -save 'server driver=imonlcd - imonlcd Device="/dev/lcd1" '
Further reading If you want to know more about lcdproc model, you can view: Under the hood I was too lazy to write myself the models of all drivers (about 3500 lines for them all). All models were generated from the LCDd.conf template file provided by lcdproc project. This blog explains how this was done. But the result is far from perfect. Event though LCDd.conf comments give a lot of semantic information, parameter types could be better adjusted and some of the examples provided in LCDd.conf confuse the model generator.
So the current comments are good, but not enough. In the future, we could decide on better structural conventions for the comments that would give users the information they need and give a model generator enough information to generate better models. This will hopefully be the topic of yet another blog All the best

8 May 2011

Dominique Dumont: Checking versioned dependencies in Debian packages Take 2

One of my last blog suggested a way to systematically clean up versioned dependencies in packages. Given the comments posted thereafter, it s clear that the one-size-fits-all strategy is ill-advised. Sorry about that. So, should these versioned dependencies be cleaned up or not ? Well It depends. Cleaning up versioned dependencies will hurt people when the package you re working on may be back-ported to old version of Debian. In corporate world, upgrading a machine may cost a lot, so you can still find production machine running etch. I would not be surprised to hear about older systems still used in production. In consumer world (mostly desktop or multimedia), people will mostly run more recent versions of Debian. All in all, the following elements must be considered before removing old versioned dependencies: Unfortunately, there s no universal strategy. In case you want to clean up old dependencies, the latest version of Dpkg::Control model for Config::Model will be helpful. The last version of this models provides a bunch of meta Dpkg parameters. These parameters are used to customize the behavior of the Dpkg editor tool to suit your needs (For more details, see Config::Model::models::Debian::Dpkg::Meta). The dependency meta parameters will enable you to tune the behavior of config-edit to your needs. There are 3 dependency parameters, from the most global to the most specific ones: Before applying a cleanup, config-edit will check the policies in the above order. The most specific one will be applied. Ie. the group policy will supersede your personal policy and the package specific policy will override the group policy. Here s a screenshot of config-edit GUI invoked on a package: config-edit with a view on dpkg meta parameters From the parameters set in the GUI above, you can see that a warning will be raised for : Last but not least, if you want to use config-edit without any dependency filtering, just make sure that all these filter parameters are empty. You will still benefits from other features, like warning if a package dependency is unknown, which is useful to catch typos. All the best

11 April 2011

Dominique Dumont: Changing e-mail in package control file is now easy

I often see on debian-perl IRC changelog related to e-mail changes. For instance, when a Debian contributor becomes a Debian developer, he often wants to change his old e-mail address in his brand new debian e-mail address. This change is mostly done while updating packages to fix bugs or ship a new upstream releases. Since this change is trivial and mostly boring, forgetting about it is likely. Well, at least, that s true for the author of this blog who did have to change he e-mail address recently. The last version Config::Model Perl module (and its Dpkg model) offers a way to automatically perform this boring update task for you while you work on more interesting problems. Dpkg model now provides a bunch of meta Dpkg parameters. These Meta parameters are used to customize the behavior of the Dpkg editor tool to suit your needs. Among these parameters, the email-updates meta parameters enable you to specify which email address to update and how. Here s a screenshot of config-edit GUI invoked on a package (with config-edit -application dpkg): GUI to set up e-mail replacement In this case, all occurrences of the dominique.dumont email will be replaced with the new domi.dumont email in the control and in the copyright file. You can change or add new addresses using the GUI. When the package data (i.e. control, copyright and source) is saved, all meta information is also saved. Meta dpkg data is saved in its own file, so the email change will be applied to all packages you will be working on: E-mail address changes can also be specified in a command line:
$ config-edit -application dpkg \
  'meta email-updates:"domi@old.fr"="dod@new.fr"' \
 -ui none -save
Note: this command must be run in a source package directory. This new address change is stored in ~/.local/share/.dpkg-meta.yml or ~/.local/share/.dpkg-meta.yml:
---
email-updates:
  domi@old.fr: dod@new.fr
From now on, anytime you run config-edit -application dpkg (and save the data) while you work on a package, all occurrences of your old e-mail adress in debian.control will be changed with the new email address. All the best

8 April 2011

Dominique Dumont: Configuration doc generation with Config::Model

Hello When a project comes with configuration files, project developers have to write configuration doc. Be it as man pages or as comments in configuration files. This is a boring, but necessary task to provide documentation to users. There s a way to get more with a similar effort. By writing this doc as models (i.e. in a format usable by Config::Model), you will get:
- generated man pages
- configuration GUIs
- configuration command line And with a little extra effort, you will also get:
- immediate validation data entered by user
- configuration upgrade tools But let s focus on generating documentation. A configuration model is more or less a list of configuration parameters with their constraints and description. In previous versions of Config::Model, the parameter description was used to generate online help in the GUI. Parameter description is now also used to generate configuration documentation. The constraints which are used to validate user input, are also used to provide more details to the documentation of the parameters. The help text in the model that will be used to generate doc can be plain text or contain pod markups to enhance the look of the doc (be it generated or displayed in the GUI). Here are some links to some example of models and the corresponding generated documents:
Debian::Dpkg::Source model generated doc
Debian::Dpkg::Copyright model generated doc
Sshd model generated doc
To generate these doc, a command like this one was added to the build process: config-edit -model Sshd -model_dir lib/Config/Model/models -gen_pod lib The generated pod files can then be converted to man pages, plain text, html depending on your needs. Feel free to send a mail on config-model users list (config-model-users at lists.sourceforge.net) if you need help. All the best

27 February 2011

Dominique Dumont: How to clean up dependencies with version in Debian packages

Hello Now that Squeeze is out, a lot of cleanup is going in Debian packages. One of them is getting rid of unnecessary dependencies with minimal versions in packages. I.e. getting rid if unnecessary versions like perl (>= 5.8.1).
Because Lenny was shipped with Perl 5.10, requiring Perl with version greater than 5.8 is not necessary and needlessly loads dependencies resolvers. In other words, you re not only doing this cleanup to make your source package lighter, you re doing it also for your users so that package upgrade go faster. Anyway, checking these versioned in a real PITA. So I ve enhanced Dpkg control model in Config::Model to take care of this check. To check your package, install libconfig-model-perl (from Sid), go in your package directory and run this command: config-edit -application dpkg -ui none This command will check your control file, your copyright file and may issue warnings or errors. Some warnings like the versioned dependencies can be fixed automatically with this command: config-edit -application dpkg -ui none -apply-fixes -save Be sure to archive your files before running this command to check what s been done by -apply-fixes options. For more information on using config-edit, please read Using config-model wiki page. All the best

2 February 2011

Dominique Dumont: My synopsis suck

Hello I ve taken a step back and looked at the synopsis of the Config::Model man
pages. Boy, I m not proud of what I ve released. Except the ones I ve reworked recently, most of them are worthless. The next release of Config::Model will feature new synopsis. Each synopsis will contain a valid example that can be run with a cut n'paste in a test file. The code in the synopsis will actually do something visible. Here s an example extracted from the next version of Config::Model::Dumper:
 use Config::Model ;
 use Log::Log4perl qw(:easy) ;
 Log::Log4perl->easy_init($WARN);
 # define configuration tree object
 my $model = Config::Model->new ;
 $model ->create_config_class (
    name => "MyClass",
    element => [
        [qw/foo bar/] =>  
            type => 'leaf',
            value_type => 'string'
         ,
        baz =>  
            type => 'hash',
            index_type => 'string' ,
            cargo =>  
                type => 'leaf',
                value_type => 'string',
             ,
         ,
    ],
 ) ;
 my $inst = $model->instance(root_class_name => 'MyClass' );
 my $root = $inst->config_root ;
 # put some data in config tree the hard way
 $root->fetch_element('foo')->store('yada') ;
 $root->fetch_element('bar')->store('bla bla') ;
 $root->fetch_element('baz')->fetch_with_id('en')->store('hello') ;
 # put more data the easy way
 my $step = 'baz:fr=bonjour baz:hr="dobar dan"';
 $root->load( step => $step ) ;
 # dump data
 print $root->dump_tree;
Feel free to log bugs on Debian BTS or on CPAN RT if the next synopsis still have problems. All the best

30 January 2011

Dominique Dumont: How to configure OpenSsh through a virtual filesystem

Hello My blog How about a configfs with Config::Model ? mentioned the on-going work to provide an access to configuration data through a virtual file system , i.e. through fuse. This new feature is now working since Config::Model 1.231. As an example, let s see how Fuse can be used to your ssh client. I.e. how to use config-edit command to modify your ~/.ssh/config through a virtual file system. Note that this is just an example, Fuse can also be used for other configuration withan existing model. First, you need to install Config::Model and Fuse and the fuse software. If you re on Debian/Sid, installing all this is straightforward:
$ sudo aptitude install libconfig-model-perl libfuse-perl
On other systems, you can use CPAN to install the Perl modules
$ cpanp i Fuse
$ cpanp i Config::Model
Hopefully, fuse library will be available through a package on your favorite repository. Let s start from an empty ssh configuration file. First you need to create a directory that will be used by Fuse as a mount point:
$ mkdir my_fuse_dir
Then run config-edit-ssh (which will be changed later to config-edit -applit ssh ):
$ config-edit-ssh -ui fuse -fuse_dir my_fuse_dir
Mounting config on my_fuse_dir in background.
Use command fusermount -u my_fuse_dir to unmount
Now, all parameters that can be configured in /.ssh/config are shown as files and directories in the fuse directory (the list was reduced to save electrons):
$ tree my_fuse_dir/
my_fuse_dir/
AddressFamily
BatchMode
BindAddress
ForwardX11
ForwardX11Trusted
[snip]
HashKnownHosts
Host
*
ConnectionAttempts
[snip]
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation
HostbasedAuthentication
HostKeyAlgorithms
[snip] 14 directories, 119 files
Let s say that we want to configure specific settings for 2 hosts: First step is to create the repoman entry:
$ mkdir my_fuse_dir/Host/repoman
A ls command in that new directory will show a lot of files:
$ ls my_fuse_dir/Host/repoman
IdentityFile Protocol Tunnel
CheckHostIP ForwardX11 KbdInteractiveAuthentication ProxyCommand TunnelDevice
Lo and behold, one of them is ForwardX11 ! Let s check what s in there:
$ cat my_fuse_dir/Host/repoman/ForwardX11
Since the entry is new, it s still empty. Enabling X11Forward for repoman is quite easy:
$ echo 1 > my_fuse_dir/Host/repoman/ForwardX11
Let s check:
$ cat my_fuse_dir/Host/repoman/ForwardX11
1
Now, unmount the fuse directory:
$ fusermount -u my_fuse_dir
And see the modified .ssh/config file:
$ cat ~/.ssh/config
Host repoman
ForwardX11 yes
You can see that ForwardX11 is indeed set to yes for host repoman. Last but not least, you may consider that handling files and directories through shell commands is not very easy for the end user. You re right. But that s not the point. The idea is to enable programmers to access and edit configuration data with any language (not only Perl). Just like a lot of program can access kernel data through /proc and /sys, configuration data can now be accessed in a unified way through this virtual file system. May be, one day, exploring /config will be as common as exploring /sys All the best

28 January 2011

Dominique Dumont: FOSDEM: see you there

I'm going to FOSDEM, the Free and Open Source Software Developers' European Meeting I ll make 2 presentations about Config::Model applications. One on configuration upgrades. The other one is more presenting ideas on sharing packaging work between distributions. Note that I ll make these presentations quite late Sunday and I ll have to leave about 30mns after the last presentation. So if you already have questions about Config::Model, it would be better to contact me before the presentations. See you there

Next.

Previous.