Search Results: Config::Model

17 May 2021

Dominique Dumont: Important bug fix for OpenSsh cme config editor

The new release of Config::Model::OpenSsh fixes a bugs that impacted experienced users: the order of Hosts or Match sections is now preserved when writing back ~/.ssh/config file. Why does this matter ? Well, the beginning of ssh_config man page mentions that For each parameter, the first obtained value will be used. and Since the first obtained value for each parameter is used, more host-specific declarations should be given near the beginning of the file, and general defaults at the end. . Looks like I missed these statements when I designed the model for OpenSsh configuration: the Host section was written back in a neat, but wrong, alphabetical order. This does not matter except when there an overlap between the specifications of the Host (or Match) sections like in the example below:
Host foo.company.com
Port 22
Host *.company.com
Port 10022
With this example, ssh connection to foo.company.com is done using port 22 and connection to bar.company.com with port 10022. If the Host sections are written back in reverse order:
Host *.company.com
Port 10022
Host foo.company.com
Port 22
Then, ssh would be happy to use the first matching section for foo.company.com , i.e. *.company.com and would use the wrong port (10022) This is now fixed with Config::Model::OpenSsh 2.8.4.3 which is available on cpan and in Debian/experimental. While I was at it, I ve also updated Managing OpenSsh configuration with cme wiki page. All the best

25 April 2021

Dominique Dumont: An improved GUI for cme and Config::Model

I ve finally found the time to improve the GUI of my pet project: cme (aka Config::Model). Several years ago, I stumbled on a usability problem on the GUI. Some configuration (like OpenSsh or Systemd) feature a lot of configuration parameters. Which means that the GUI displays all these parameters, so finding a specfic parameter might be challenging:
To workaround this problem, I ve added a Filter widget in 2018 which did more or less the job, but it suffered from several bugs which made its behavior confusing. This is now fixed. The Filter widget is now working in a more consistent way. In the example below, I ve typed IdentityFile (1) in the Filter widget to show the identityFile used for various hosts (2):
Which is quite good, but some hosts use the default identity file so no value show up in the GUI. You can then click on hide empty value checkbox to show only the hosts that use a specific identity file:
I hope that this new behavior of the Filter box will make this project more useful. The improved GUI was released with Config::Model::TkUI 1.374. This new version is available on CPAN and on Debian/experimental). It will be released on Debian/unstable once the next Debian version is out. All the best

4 September 2017

Dominique Dumont: cme: some read-write backend features are being deprecated

Hello Config::Model and cme read and write configuration data with a set of backend classes, like Config::Model::Backend::IniFile. These classes are managed by Config::Model::BackendMgr. Well, that s the simplified view. Actually, the backend manager can handle several different backends to read and write data: read backends are tried until one of them succeeds to read configuration data. And write backend cen be different from the read backend, thus offering the possibility to migrare from one format to another. This feature came at the beginning of the project, back in 2005. This felt like a good idea to let user migrate from one data format to another. More than 10 years later, this feature has never been used and is handled by a bunch of messy code that hampers further evolution of the backend classes. So, without further ado, I m going to deprecate the following features in order to simplify the backend manager: Unless someone objects, actual removal of these feature will be done in the next few months, after a quite short deprecation period. All the best
Tagged: cme, config-model, Config::Model, configuration

1 July 2017

Paul Wise: FLOSS Activities June 2017

Changes

Issues

Review

Administration
  • Debian: redirect 2 users to support channels, redirect 1 person to the mirrors team, investigate SMTP TLS question, fix ACL issue, restart dead exim4 service
  • Debian mentors: service restarts, security updates & reboot
  • Debian QA: deploy my changes
  • Debian website: release related rebuilds, rebuild installation-guide
  • Debian wiki: whitelist several email addresses, whitelist 1 domain
  • Debian package tracker: deploy my changes
  • Debian derivatives census: deploy my changes
  • Openmoko: security updates & reboots.

Communication

Sponsors All work was done on a volunteer basis.

4 January 2017

Dominique Dumont: New with cme: a GUI to configure Systemd services

Hello Systemd is powerful, but creating a new service is a task that require creating several files in non obvious location (like /etc/systemd/system or ~/.local/share/systemd/user/). Each file features 2 or more sections (e.g. [Unit], [Service]). And each section supports a lot of parameters. Creating such Systemd configuration files can be seen as a daunting task for beginners. cme project aims to make this task easier by providing a GUI that: For instance, on my laptop, the command cme edit systemd-user shows 2 custom services ( free-imap-tunnel@ and gmail-imap-tunnel@ ) with: cme_edit_systemd_001 The GUI above shows the units for my custom systemd files:
$ ls ~/.config/systemd/user/
free-imap-tunnel@.service
free-imap-tunnel.socket
gmail-imap-tunnel@.service
gmail-imap-tunnel.socket
sockets.target.wants
and the units installed by Debian packages:
$ find /usr/lib/systemd/user/ -maxdepth 1 \
  '(' -name '*.service' -o -name '*.socket' ')' \
  -printf '%f\n'  sort  head -15
at-spi-dbus-bus.service
colord-session.service
dbus.service
dbus.socket
dirmngr.service
dirmngr.socket
glib-pacrunner.service
gpg-agent-browser.socket
gpg-agent-extra.socket
gpg-agent.service
gpg-agent.socket
gpg-agent-ssh.socket
obex.service
pulseaudio.service
pulseaudio.socket
The screenshot above shows the content of the service defined by the following file:
$ cat ~/.config/systemd/user/free-imap-tunnel@.service
[Unit]
Description=Tunnel IMAPS connections to Free with Systemd
[Service]
StandardInput=socket
# no need to install corkscrew
ExecStart=-/usr/bin/socat - PROXY:127.0.0.1:imap.free.fr:993,proxyport=8888
Note that empty parameters are not shown because the hide empty value checkbox on top right is enabled. Likewise, cme is able to edit system files like user files with sudo cme edit systemd: cme_edit_systemd_001 For more details on how to use the GUI to edit systemd files, please see: Using a GUI may not be your cup of tea. cme can also be used as a validation tool. Let s add a parameter with an excessive value to my service:
$ echo "CPUShares = 1000000" >> ~/.local/share/systemd/user/free-imap-tunnel@.service
And check the file with cme:
$ cme check systemd-user 
cme: using Systemd model
loading data
Configuration item 'service:"free-imap-tunnel@" Service CPUShares' has a wrong value:
        value 1000000 > max limit 262144
ok, let s fix this with cme. The wrong value can either be deleted:
$ cme modify systemd-user 'service:"free-imap-tunnel@" Service CPUShares~'
cme: using Systemd model
Changes applied to systemd-user configuration:
- service:"free-imap-tunnel@" Service CPUShares: '1000000' -> ''
Or modified:
$ cme modify systemd-user 'service:"free-imap-tunnel@" Service CPUShares=2048'
cme: using Systemd model
Changes applied to systemd-user configuration:
- service:"free-imap-tunnel@" Service CPUShares: '1000000' -> '2048'
You can also view the specification of a service using cme:
$ cme dump systemd-user 'service:"free-imap-tunnel@"'---
Service:
  CPUShares: 2048
  ExecStart:
    - '-/usr/bin/socat -  PROXY:127.0.0.1:imap.free.fr:993,proxyport=8888'
  StandardInput: socket
Unit:
  Description: Tunnel IMAPS connections to Free with Systemd
The output above matches the content of the service configuration file:
$ cat ~/.local/share/systemd/user/free-imap-tunnel@.service
## This file was written by cme command.
## You can run 'cme edit systemd-user' to modify this file.
## You may also modify the content of this file with your favorite editor.
[Unit]
Description=Tunnel IMAPS connections to Free with Systemd
[Service]
StartupCPUWeight=100
CPUShares=2048
StartupCPUShares=1024
StandardInput=socket
# no need to install corkscrew now
ExecStart=-/usr/bin/socat -  PROXY:127.0.0.1:imap.free.fr:993,proxyport=8888
Last but not least, you can use cme shell if you want an interactive ui but cannot use a graphical interface:
$ cme shell systemd-user 
cme: using Systemd model
 >:$ cd service:"free-imap-tunnel@"  Service  
 >: service:"free-imap-tunnel@" Service $ ll -nz Exec*
name        type   value                                                             
 
ExecStart   list   -/usr/bin/socat -  PROXY:127.0.0.1:imap.free.fr:993,proxyport=8888
 >: service:"free-imap-tunnel@" Service $ ll -nz
name               type      value                                                             
 
StartupCPUWeight   integer   100                                                               
CPUShares          integer   2048                                                              
StartupCPUShares   integer   1024                                                              
StandardInput      enum      socket                                                            
ExecStart          list      -/usr/bin/socat -  PROXY:127.0.0.1:imap.free.fr:993,proxyport=8888
 >: service:"free-imap-tunnel@" Service $ set CPUShares=1024
 >: service:"free-imap-tunnel@" Service $ ll -nz CPUShares 
name        type      value
 
CPUShares   integer   1024 
 >: service:"free-imap-tunnel@" Service $ quit
Changes applied to systemd-user configuration:
- service:"free-imap-tunnel@" Service CPUShares: '2048' -> '1024'
write back data before exit ? (Y/n)
Currently, only service, socket and timer units are supported. Please create a bug report on github if you need more. Installation instructions are detailed at the beginning of Managing Systemd configuration with cme wiki page. As all softwares, cme probably has bugs. Please report any issue you might have with it. For more information: All in all, systemd is quite complex to setup. I hope I made a little bit easier to deal with. All the best
Tagged: config-model, configuration, Perl, systemd

18 June 2016

Dominique Dumont: An improved Perl API for cme and Config::Model

Hello While hacking on a script to update build dependencies on a Debian package, it occured to me that using Config::Model in a Perl program should be no more complicated than using cme from a shell script. That was an itch that I scratched immediately. Fast forward a few days, Config::Model now features new cme() and modify() functions that have a behavior similar to cme modify command. For instance, the following program is enough to update popcon s configuration file:
use strict; # let's not forget best practices ;-)
use warnings;
use Config::Model qw(cme); # cme function must be imported
cme('popcon')->modify("PARTICIPATE=yes");
The object returned by cme() is a Config;:Model::Instance. All its methods are available for a finer control. For instance:
my $instance = cme('popcon');
$instance->load("PARTICIPATE=yes");
$instance->apply_fixes;
$instance->say_changes; 
$instance->save;
When run as root, the script above shows:
Changes applied to popcon configuration:
- PARTICIPATE: 'no' -> 'yes'
If need be, you can also retrieve the root node of the configuration tree to use Config;:Model::Node methods:
my $root_node = cme('popcon')->config_root;
say "is popcon active ? ",$root_node->fetch_element_value('PARTICIPATE');
In summary, using cme in a Perl program is now as easy as using cme from a shell script. To provide feedback, comments, ideas, patches or to report problems, please follow the instructions from CONTRIBUTING page on github. All the best
Tagged: config-model, configuration, Perl

31 May 2015

Dominique Dumont: Improving update of existing debian/copyright file

Hello One of my last blog introduced the new cme update dpkg-copyright command and explained how to use this command to create a debian/copyright file from scratch. We will see in this blog how cme update dpkg-copyright command can also be used if a debian/copyright file already exists. During the lifetime of a package, creating a new debian/copyright copyright file should only happen once. When updating a package to a new upstream version, the content of the copyright file should be modified to reflect upstream changes by: cme update dpkg-copyright can be run with an existing debian/copyright file: the information extracted by licensecheck are merged in debian/copyright. Unfortunately, this merge may bring back the errors coming from licensecheck that you ve cleaned up manually last time. This last part is not optimal as the manual clean up must be repeated after cme update dpkg-copyright is run. Here s a way to avoid the last problem: cme update dpkg-copyright supports a way to modify the content of debian/copyright after the merge: the optional file debian/fix.scanned.copyright contains instructions to tweak the content of debian/copyright. (See Config::Model::Dpkg::Copyright man page for more details) You may remember that Config::Model handles all configuration information as a tree. The information contained in the copyright file is also stored in a tree structure. debian/fix.scanned.copyright contains instructions to navigate this tree and modify the content of the tree. Imagine that there s a robot (or a monkey) in that configuration tree. Each instruction tells the robot either to move in the tree or to perform an operation. The most useful instructions for debian/fix.scanned.copyright are: Otherwise: Let s see a commented example:
# go to the root of the tree (with '!')
# and remove a bogus Files entry (with ":~")
! Files:~"foo/bogus.c"
// go to a Files entry and append (operator '.=') some info to   owner
! Files:"foo/bar.h"
  Copyright.=" Appended info."
# go back to tree root and assign   info
! Files:"foo/baz.c" Copyright="2014, FooBar"
# add a global license and a file entry missed by licensecheck
# global license must be set before using it in Files entry
# note: MIT text license is provided by cme
! License=MIT
! Files:"3rdparty/missed.c" Copyright="2005 FooBar" License short_name=MIT
Other possible instructions for this file are described in Config::Model::Loader doc. The number of instructions depends on the accuracy of licencecheck command. Hopefully, this number can be reduced by improving licensecheck. Last but not least, the following packages are required: You may want to install also libconfig-model-tkui-perl to update the copyright file with cme GUI. In summary, the command cme updated dpkg-copyright associated with instructions stored in debian/fix.scanned.copyright enable Debian packagers to update with less effort debian/copyright file when updating a package. All the best

21 February 2015

Dominique Dumont: Performance improvement for cme check dpkg

Hello Thanks to Devel::NYTProf, I ve realized that Module::CoreList was used in a not optimal way (to say the least) in Config::Model::Dpkg::Dependency when checking the dependency between Perl packages. (Note that only Perl packages with many dependencies were affected by this lack of performance) After a rework, the performance are much better. Here s an example comparing check time before and after the modification of libconfig-model-dpkg-perl. With libconfig-model-dpkg-perl 2.059:
$ time cme check dpkg
Using Dpkg
loading data
Reading package lists... Done
Building dependency tree
Reading state information... Done
checking data
check done
real 0m10.235s
user 0m10.136s
sys 0m0.088s With libconfig-model-dpkg-perl 2.060:
$ time cme check dpkg
Using Dpkg
loading data
Reading package lists... Done
Building dependency tree
Reading state information... Done
checking data
check done
real 0m1.565s
user 0m1.468s
sys 0m0.092s All in all, a 8x performance improvement on the dependency check. Note that, due to the freeze, the new version of libconfig-model-dpkg-perl is available only in experimental. All the best
Tagged: Config::Model, debian, dpkg, package

3 October 2014

Ian Donnelly: Config::Model and Elektra

Hi Everybody, Today I want to talk about the different approaches of Elektra and Config::Model. We have gotten a lot of questions lately about why Elektra is necessary and what differentiates it between similar tools like Config::Model. While there are a lot of similarities between Config::Model and Elektra, there are some key differences and that is what I will be focusing on in this post. Once a specification is defined for Elektra and a plug-in is written to work with that specification, other developers will be able to reuse these specifications for programs that have similar configurations (such a specification and plug-in for the ini file type.) Additionally, specifications, once defined in KDB can be used across multiple programs. For instance, if I were to define a specification for my program within KDB:
[/myapp/file_dialog/show_hidden_files]
type=Boolean
default=true

Any other program could use my specification just by referring to show_hidden_files. These features allow Elektra to solve the problem of cross-platform configurations by providing a consistent API and also allow users to easily be aware of other applications configurations which allows for easier integration between programs. Config:: Model also moves to provide a unified interface for configuration data and it also supports validation such as the type=Boolean like in the above example. The biggest differences between these two projects is that Elektra is intended for use by the programs themselves and by external GUIs and validation tools unlike Config::Model. Config::Model provides a tool allowing developers to provide a means for users to interactively edit configuration data in a safe way. Additionally, Elektra uses self-inscribing data. This means that all the specifications are saved within KDB and in metadata. More differences are that validators can be written in any language for Elektra because the specifications are just stored as data and they can enforce constraints on any access because plug-ins define the behavior of KDB itself. Tying this all together with my GSoC project is the topic of three-way merges. Config::Model actually does not rely on a base for merges since the specifications all must be complete. This is a very good approach to handle merges in an advanced way too. This is an avenue that Elektra would like to explore in the future when we have enough specifications to handle all types on configuration. I hope that this post clarifies the different approaches of Elektra and Config::Model. While both of these tools offer a better answer to configuration files they do have different goals and implementations that make them unique. I want to mention that we have a good relationship with the developers of Config::Model, who supported my Google Summer of Code Project. We believe that both of these tools have their own place and uses and they do not compete to achieve the same goals. For now,
Ian S. Donnelly

6 July 2014

Dominique Dumont: Status and next step on lcdproc automatic configuration upgrade with Perl and Config::Model

Back in March, I uploaded a Debian s version of lcdproc with a unique feature: user and maintainer configurations are merged during package upgrade: user customizations and developers enhancements are both preserved in the new configuration file. (See this blog for more details). This avoids tedious edition of the configuration LCDd.conf file after every upgrade of lcdproc package. At the beginning of June, a new version of lcdproc (0.5.7-1) was uploaded. This triggered another round of automatic upgrades on user s systems. According to the popcon rise of libconfig-model-lcdproc-perl, about 100 people have upgraded lcdproc on their system. Since automatic upgrade has an opt-out feature, one cannot say for sure that 100 people are actually using automatic upgrade, but I bet a fair portion are them are. So far, only one people has complained: a bug report was filed about the many dependencies brought by libconfig-model-lcdproc-perl. The next challenge for lcdproc configuration upgrade is brought by a bug reported on Ubuntu: the device file provided by imon kernel module is a moving target: The device file created by the kernel can be /dev/lcd0 or /dev/lcd1 or even /dev/lcd2. Static configuration files and moving target don t mix well. The obvious solution is to provide a udev rule so that a symbolic link is created from a fixed location (/dev/lcd-imon) to the moving target. Once the udev rule is installed, the user only has to update LCDd.conf file to use the symlink as imon device file and we re done. But, wait The whole point of automatic configuration upgrade is to spare the user this kind of trouble: the upgrade must be completely automatic. Moreover, the upgrade must work in all cases: whether udev is available (Linux) or not. If udev is not available, the value present in the configuration file must be preserved. To know whether udev is available, the upgrade tool (aka cme) will check whether the file provided by udev (/dev/lcd-imon) is present or not. This will be done by lcdproc postinst script (which is run automatically at the end of lcdproc upgrade). Which means that the new udev rule must also be
activated in the postinst script before the upgrade is done. In other words, the next version of lcdproc (0.5.7-2) will: In the lcdproc configuration model installed by libconfig-model-lcdproc-perl, the imon device parameter is enhanced so that running cme check lcdproc or cme migrate lcdproc issues a warning if /dev/lcd-imon exists and if imon driver is not configured to use it. This way, the next installation of lcdproc will deliver a fix for imon and cme will fix user s configuration file without requiring user input. The last point is admittedly bad marketing as users will not be aware of the magic performed by Config::Model Oh well In the previous section, I ve briefly mentioned that imon_device parameter is enhanced in lcdproc configuration model. If you re not already bored, let s lift the hood and see what kind of enhancements was added. Let s peek in lcdproc configuration file, LCDd.conf file which is used to generate lcdproc configuration model. You may remember that the formal description of all LCDd.conf parameters and their properties is generated from LCDd.conf to provide lcdproc configuration model. The comments in LCDd.conf follow a convention so that most properties of the parameters can be extracted from the comments. In the example below, the comments show that NewFirmware is a boolean value expressed as yes or no, the latter being the default :
# Set the firmware version (New means >= 2.0) [default: no; legal: yes, no]
NewFirmware=no
Back to the moving target. In LCDd.conf, imon device file parameter is declared this way:
# Select the output device to use
Device=/dev/lcd0
This means that device is a string where the default value is /dev/lcd0. Which is wrong once the special udev rule provided with Debian packages is activated. With this rule, the default value must be /dev/lcd-imon. To fix this problem, a special comment is added in the Debian version of LCDd.conf to tune further the properties of the device parameter:
# select the device to use
#  %
#   default~
#   compute
#     use_eval=1
#     formula="my $l = '/dev/lcd-imon'; -e $l ? $l : '/dev/lcd0';"
#     allow_override=1 -
#   warn_if:not_lcd_imon
#     code="my $l = '/dev/lcd-imon';defined $_ and -e $l and $_ ne $l ;"
#     msg="imon device does not use /dev/lcd-imon link."
#     fix="$_ = undef;"
#   warn_unless:found_device_file
#     code="defined $_ ? -e : 1"
#     msg="missing imon device file"
#     fix="$_ = undef;"
#   - % 
Device=/dev/lcd0
This special comment between % and % follows the syntax of Config::Model::Loader. A small configuration model is declared there to enhance the model generated from LCDd.conf file. Here are the main parts: In both warn_unless and warn_if parts, the fix code snippet is run when by the command cme fix lcdproc and is used to repair the warning condition. In this case, the fix consists in resetting the device configuration value so the computed value above can be used. cme fix lcdproc is triggered during package post install script installed by dh_cme_upgrade. Come to think of it, generating a configuration model from a configuration file can probably be applied to other projects: for instance, php.ini and kdmrc are also shipped with detailed comments. May be I should make a more generic model generator from the example used to generate lcdproc model Well, I will do it if people show interest. Not in the form yeah, that would be cool , but in the form, yes, I will use your work to generate a configuration model for project [...] . I ll let you fill the blank ;-)
Tagged: Config::Model, configuration, debian, lcdproc, Perl, upgrade

15 June 2014

Dominique Dumont: Edit your debian patch header for DEP-3 compliance with cme

While not required by Debian policy, the patch tagging guidelines (aka DEP-3) recommends to add a structured header to source package patches. Long story short, patches should begin with something like :
Description: tweak lcdproc config for debian
patch LCDd.conf to:
* use syslog instead of stderr to show message
* run LCDd as root (to read /dev/lcd* file)
.
The latter could be done better by tweaking udev rule
Author: dod
Applied-Upstream: NA
Making sure that the DEP-3 recommendation is respected may not be fun. Do not despair: once libconfig-model-dpkg-perl is installed on your system, you can check whether your patches respect the DEP3 recommendation with the following command: $ cme check dpkg-patches
loading data
checking data
check done
You can also check individual patches with: cme check dpkg-patch tweak-conf Note that bash auto-completion is provided only from version 2.049 of libconfig-model-dpkg-perl package. If editing the header of your patches with your favorite editor does not strike you as fun, you can also use cme graphical editor provided by libconfig-model-tkui-perl. Once this package is installed, you can run: cme edit dpkg-patches You will get this editor to update your patches: -usr-bin-cme Dpkg::Patches_001 This editor will show you the available parameters and the associated documentation to let you provide relevant information. Last but not least, patch header check is also performed when you check your whole package with cme check dpkg All the best
Tagged: Config::Model, debian, package, patch

4 May 2014

Dominique Dumont: Deprecating experience level and preset value in Config::Model

Hello The next releases of Config::Model will deprecate 2 (mis)features: The behavior of cme check will not change. People using cme edit with the GUI will see many more configuration parameters. All the best

23 March 2014

Dominique Dumont: Easier Lcdproc package upgrade with automatic configuration merge

Hello This blog explains how next lcdproc package provide easier upgrader with automatic configuration merge. Here s the current situation: lcdproc is shipped with several configuration files, including /etc/LCDd.conf. This file is modified upstream at every lcdproc release to bring configuration for new lcdproc drivers. On the other hand, this file is always customized to suit the specific hardware of the user s system. So upgrading a package will always lead to a conflict during upgrade. User will always be required to choose whether to use current version or upstream version. Next version of libconfig-model-lcdproc-perl will propose user whether to perform automatic merge of the configuration: upstream change are taken into account while preserving user change. The configuration upgrade shown is based on Config::Model can be applied to other package. Current lcdproc situation To function properly, lcdproc configuration must always be adapted to suit the user s hardware. On the following upgrade, upstream configuration is often updated so user will often be shown this question:
Configuration file '/etc/LCDd.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** LCDd.conf (Y/I/N/O/D/Z) [default=N] ?
This question is asked in the middle of an upgrade and can be puzzling for an average user. Next package with automatic merge Starting from lcdproc 0.5.6, the configuration merge is handled automatically by the packaging script with the help of Config::Model::Lcdproc. When lcdproc is upgraded to 0.5.6, the following changes are visible:
* lcdproc depends on libconfig-model-lcdproc-perl
* user is asked once by debconf whether to use automatic configuration upgrades or not.
* no further question are asked (no ucf style questions). For instance, here s an upgrade from lcdproc_0.5.5 to lcdproc_0.5.6:
$ sudo dpkg -i lcdproc_0.5.6-1_amd64.deb 
(Reading database ... 322757 files and directories currently installed.)
Preparing to unpack lcdproc_0.5.6-1_amd64.deb ...
Stopping LCDd: LCDd.
Unpacking lcdproc (0.5.6-1) over (0.5.5-3) ...
Setting up lcdproc (0.5.6-1) ...
Changes applied to lcdproc configuration:
- server ReportToSyslog: '' -> '1' # use standard value
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Starting LCDd: LCDd.
Processing triggers for man-db (2.6.6-1) ...
Note: the automatic upgrade currently applies only to LCDd.conf. The other configuration files of lcdproc are handled the usual way. Other benefits User will also be able to:
* check lcdproc configuration with sudo cme check lcdproc
* edit the configuration with a GUI (see Managing Lcdproc configuration with cme for more details) Here s a screenshot of the GUI: GUI to edit lcdproc configuration More information * libconfig-model-lcdproc-perl package page. This package provides a configuration model for lcdproc.
* This blog explains how this model is generated from upstream LCDd.conf.
* How to adapt a package to perform configuration upgrade with Config::Model Next steps Automatic configuration merge can be applied to other packages. But my free time is already taken by the maintenance of Config::Model and the existing models, there s no room for me to take over another package. On the other hand, I will definitely help people who want to provide automatic configuration merge on their packages. Feel free to contact me on:
* config-model-user mailing list
* debian-perl mailing list (where Config::Model is often used to maintain debian package file with cme)
* #debian-perl IRC channel All the best
Tagged: config-model, configuration, debian, Perl, upgrade

1 January 2014

Dominique Dumont: Config::Model::OpenSsh now supports OpenSSH 6.4 configuration

Hello This was long overdue. I ve released Config::Model::OpenSsh 1.232. This new release
supports a lot of new parameters that were added to OpenSSH 6.0 and later versions, like AllowAgentForwarding, AuthenticationMethods or AuthorizedKeysCommand. This new version is also available in Debian. Happy new year !
Tagged: Config::Model, OpenSsh, Perl

2 July 2013

Dominique Dumont: Seeking help to update OpenSSH configuration editor (Config::Model)

Hello OpenSsh 6.0 has been out for more than a year and the OpenSSH configuration editor still lacks the new parameters introduced by this release (like AllowAgentForwarding). Technically, the task is not difficult, but I lack time to address it: I m swamped by real life job, maintenance of Config::Model, Debian packaging activities So I m looking for volunteer(s) to help me on Config::Model. Updating OpenSSH model is a great way to start ! If you want to help, please: Be sure that you won t be forgotten in the change log ;-) Feel free to contact config-model-users at lists.sourceforge.net to get help, exchange ideas, or to discuss how to handle deprecation or upgrade of OpenSSH parameters All the best update: OpenSSH project name was corrected after Rafal s comment.
Tagged: Config::Model, OpenSsh, Perl

12 June 2013

Dominique Dumont: Improving error messages of Dpkg dependency parser

Hello Config::Model::Dpkg project (a Debian source package model based on Config::Model) is partly based on a ParseRec::Descent grammar. This grammar is used to parse the dependency of a Debian source package. This article will show how such a grammar is written, its limitation regarding error handling and how to improve the situation. Debian package main data is described in debian/control file. This file can feature a list of dependencies, i.e. a list of package that must be installed for the package to work. These dependencies are declared in fields like Build-Depends , or Depends as a list of package. For Dpkg model purpose, I needed only to parse one item of a dependency list at a time. This dependency item can be a simple package name: foo or a package name with a version requirement: foo ( > 1.24 ) or a package name with architectures restrictions: foo [alpha amd64 hurd-arm linux-armeb] or both: foo ( > 1.24 ) [alpha amd64 hurd-arm linux-armeb] or a list of alternate choices combining the possibilities above: foo ( > 1.24 ) bar [ linux-any] baz ( << 3.14 ) [ ! hurd-armel !hurd-armeb ] or a variable that is replaced during package build: $ perl-depends Writing a Parse::RecDescent grammar to parse this is relatively straightforward. The first production handles alternate dependencies separated by and raises an error if some text was not consumed by the dependencies:
dependency_item: depend(s /\ /) eofile  
A dependency as explained above is expressed as:
depend: pkg_dep   variable
A variable like $ foo or $ bar -1.24~ is parsed with:
variable: /\$ [\w:\-]+ [\w\.\-~+]*/
This rule handles a package name with optional version or arch restriction:
pkg_dep: pkg_name dep_version(?) arch_restriction(?) 
pkg_name: /[a-z0-9][a-z0-9\+\-\.]+/
The remaining rules are quite simple:
dep_version: '(' oper version ')' 
oper: '<<'   '<='   '='   '>='   '>>'
version: variable   /[\w\.\-~:+]+/
arch_restriction: '[' arch(s) ']'
arch:  /!?[\w-]+/
eofile: /^\Z/
The grammar above works well to parse the dependency. You can test it with this small Perl script:
#!/usr/bin/perl
use strict;
use warnings;
use 5.010 ;
use Parse::RecDescent ;
my $parser = Parse::RecDescent->new(join('',));
my $dep = shift ;
say "parsing '$dep'";
my $ret = $parser->dependency_item($dep) ;
say "result is ", $ret if $ref ;
__DATA__
# insert grammar here !!!
Unfortunately, any error in the optional parts (i.e version requirements and arch restriction) leads to an error message which is not very helpful. The error message only mention that some text could not be parsed:
parsing 'foo ( != 1.24 )   bar'
       ERROR (line 1): Invalid dependency item: Was expecting /\ / but found
                       "( != 1.24 )   bar" instead
or
parsing 'foo [ arm & armel]   bar'
       ERROR (line 1): Invalid dependency item: Was expecting /\ / but found
                       "[ arm & armel]   bar" instead
The problem comes from the fact that version requirements or arch restrictions are optional. For instance if a version requirement has a syntax error, Parse::RecDescent will try to parse it as an arch restriction. This arch restriction rule will also fail and the last terminal ( eofile ) will fail. So the error message does not hint at the actual syntax problem. To generate better error messages, I improved the suggestion made in Parse::RecDescent FAQ. Instead of calling a plain subroutine, I use a sub reference that will store the error messages in a closure. This sub ref is declared in a start-up action. Note that the sub ref explicitly returns undef. I ll explain why later.
 
    my @dep_errors ;
    my $add_error = sub  
        my ($err, $txt) = @_ ;
        push @dep_errors, "$err: '$txt'" ;
        return ;
      ;
 
The following production always fails while ensuring that the error list is reset. This production is always run at the beginning of the dependency parsing:
dependency:   @dep_errors = ();  
Here s the actual dependency production that is run when dependency method is called on the parser. It will return an array ref containing (1, data) if the dependency is valid or (0, errors) otherwise:
dependency: depend(s /\ /) eofile
   
    $return = [ 1 , @ $item[1]  ] ;
   
   
   
    push( @dep_errors, "Cannot parse: '$text'" ) unless @dep_errors ;
    $return =  [ 0, @dep_errors ];
   
The following productions don t change much:
depend: pkg_dep   variable
variable: /\$ [\w:\-]+ [\w\.\-~+]*/
pkg_dep: pkg_name dep_version(?) arch_restriction(?) 
dep_version: '(' oper version ')'
The first rule of this production parses the package name which must be followed by a space, end of string ( or ['. A positive look-ahead assertion is used so only the package name is consumed. If the first rule fails, the second rule provides a meaningful error message. The second rule will match anything which is not a space and create an error message. Since $add_error returns undef, the second rule returns undef and the production fails. So the text stored in the error message is not consumed:
pkg_name: /[a-z0-9][a-z0-9\+\-\.]+(?=\s \Z \( \[)/
      /\S+/   $add_error->("bad package name", $item[1]) ; 
The same trick is used with these productions:
oper: '<<'   '='   '>>'
      /\S+/   $add_error->("bad dependency version operator", $item[1]) ; 
version: variable   /[\w\.\-~:+]+(?=\s \) \Z)/
      /\S+/   $add_error->("bad dependency version", $item[1]) ; 
The action of this production is a little bit more tricky. The action ensures that '!' are either added before all arch or not at all. Otherwise an error message is generated and added to the list of errors:
arch_restriction: '[' osarch(s) ']'
     
        my $mismatch = 0;
        # $ref contains ['!',os,arch] or ['',os,arch]
        my $ref = $item[2] ;
        for (my $i = 0; $i < $#$ref -1 ; $i++ )  
            $mismatch  = ($ref->[$i][0] xor $ref->[$i+1][0]) ;
         
        my @a = map   ($_->[0]   '') . ($_->[1]   '') . $_->[2]   @$ref ;
        if ($mismatch)  
            $add_error->("some names are prepended with '!' while others aren't.", "@a") ;
         
        else  
            $return = 1 ;
         
     
The check above is possible only if the "osarch" production returns an array ref containing something like ('!','linux','any') for "!linux-any' or ('','linux','any') for "linux-any":
osarch: not(?) os(?) arch
     
        $return =  [ $item[1][0], $item[2][0], $item[3] ];
     
      /.?(?=\s \] \Z)/   $add_error->("bad arch specification: ", $item[1]) ;  
not: '!'
Here's the remaining of the grammar:
os: /(any uclibc-linux linux kfreebsd knetbsd etc...)-/
     /\w+/ '-'   $add_error->("bad os in architecture specification", $item[1]) ; 
arch: / (any  alpha amd64  arm\b  arm64  etc... )
        (?=(\]  ))
      /x
        /\w+/   $add_error->("bad arch in architecture specification", $item[1]) ; 
eofile: /^\Z/
That's all for grammar 2.0... Before someone yells: "Show me the message ! ", here are some example of bad dependencies and their error message generated by the parser:
parse 'foo ( != 1.24 )   bar'
result is: 0 bad dependency version operator: '!='
parsing 'foo [ arm & armel]   bar'
result is: 0 bad arch specification: : '&'
parsing 'foo [ arm armel ]   bar [!moo]'
result is: 0 bad arch specification: : ']' bad arch in architecture specification: 'moo'
The 2 first error messages are spot on the actual error. The second one has a false positive (']' is correct) but correctly highlights the wrong arch name ('moo'). Mission accomplished. In order to keep this post (relatively) simple, I've removed the part that actually store parsed data. They don't really matter for error handling. Nevertheless, you may see the whole grammar in Config::Model::Dpkg::Dependency module. All the best
Tagged: Config::Model, debian, dpkg, package, Parse::RecDescent, Perl

23 March 2013

Dominique Dumont: Next version of Config::Model will use asynchronous check

Hello To check the validity of Debian dependencies in Debian package, Config::Model queries a remote web server to get the list of package version known to Debian. The first version of this check did sequential requests: when the cache was not very fresh, I had to wait more than 60s before getting results for complex package like padre. That was very frustrating (but less frustrating than checking package names manually) For the following version, I addedhacked AnyEvent in Dpkg model to run parrallel queries. This went much faster but gaves weird results: before getting a response from Debian server, the packages were flagged as unknown. To get consistent results, running twice cme check dpkg was required. So, at new year, I ve decided to bite the bullet and implement correctly value checks with asynchronous queries to remote server. This new feature is now ready and will be delivered in Config::Model 2.030. cme will now return consistent results. This new release is mostly backward compatible. You may notice some quirks with some other modules based on Config::Model: These quirks will disappear once these modules are updated. This should not be long since all the updates are ready in github. All the best
Tagged: Config::Model, debian, dpkg, Perl

7 October 2012

Dominique Dumont: Dpkg source editor/checker is going native

Hello As Config::Model was becoming too big with too many dependencies, I ve moved all Debian stuff from Config::Model repository into a separate Debian repository. If you install only libconfig-model-perl 2.026-1 (from experimental), the command cme check dpkg will not work. You must also install libconfig-model-dpkg-perl to get it back. libconfig-model-dpkg-perl is currently in experimental. libconfig-model-dpkg-perl repository is hosted on Alioth in debian perl-packaging team and is a Debian native package. Nevertheless, it will be uploaded to CPAN. (just like dh-make-perl).
All people involved in packaging are welcome to hack it or suggest improvements I ll upload both packages into unstable once the dust settles. All the best
Tagged: config-model, debian, dpkg, Perl

2 July 2012

Dominique Dumont: Kerberos configuration editor looking for a maintainer

Hello A while ago, Peter Knowles wrote a configuration model for Kerberos. Unfortunately, his priorities shifted before he completed this work. He was kind enough to send me the prototype in hope someone could take over. Although I do not know Kerberos, I believe the model is rather complete. Just click on the image below to judge for yourself: Class diagram of Kerberos configuration model This work was released under a LGPL-2+ license. There are some tasks left to get a Kerberos configuration editor. These are mentioned in config-model-kerberos readme file. To look at the code, just clone config-model-kerberos with
git://github.com/dod38fr/config-model-kerberos.git
If you need more information on Config::Model, see: If you are interested in adopting Kerberos model, please keep us informed on config-model-users at lists.sourceforge.net. This will avoid duplicated work. On my side, I ll gladly answer questions related to Config::Model to help you get started. All the best
Tagged: Config::Model, Kerberos, Perl

31 May 2012

Dominique Dumont: cme fix dpkg now track and display changes

Hello I ve released Config::Model 2.018 which is now able to track the changes done with cme to your configuration data. Thw GUI now features a new menu entry File -> show unsaved change that will give you a list of the changes done since running the command or since the last save (whichever occured last). For instance: This feature is also available in non-graphic mode. As an example, let s refresh the lcdproc package:
$ cme fix dpkg
Fixing...
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Warning in 'control source Standards-Version' value '3.9.2': Current standards version is 3.9.3
Warning in 'copyright Format' value 'http://dep.debian.net/deps/dep5/': Format does not match the recommended URL for DEP-5
Changes:
- control source Standards-Version: '3.9.2' -> '3.9.3' # applied fix
- copyright Format: 'http://dep.debian.net/deps/dep5/' -> 'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/' # applied fix
The Changes list can be reused to update the changelog, but the author does not dare injecting this directly in debian/changelog Let s check the resulting changes:
$ git diff
diff --git a/debian/control b/debian/control
index 11a5b8a..2b81192 100644
--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,7 @@ Build-Depends: autoconf,
                libxosd-dev,
                pkg-config,
                texinfo
-Standards-Version: 3.9.2
+Standards-Version: 3.9.3
 Vcs-Browser: http://git.debian.org/?p=collab-maint/lcdproc.git;a=summary
 Vcs-Git: git://git.debian.org/collab-maint/lcdproc.git
 Homepage: http://www.lcdproc.org/
diff --git a/debian/copyright b/debian/copyright
index 6cea444..4b48619 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,4 +1,4 @@
-Format: http://dep.debian.net/deps/dep5/
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: lcdproc
 Upstream-Contact: William W. Ferrell 
 Source: http://www.lcdproc.org/
domi@ylum:~/debian-dev/lcdproc-stuff/lcdproc$ 
Last but not least, this track and display changes features is also available for other models, like OpenSsh, lcdproc, multistrap All the best
Tagged: Config::Model, dpkg, Perl

Next.