'Sshd::MatchElement' => {
accept => {
match_not =>  '/Match/i' ,
type => 'leaf',
value_type => 'string'
}
}

Since today morning, I was working on this feature and it is now available for testing, in slightly modified version. With my modifications, you can write a model like this:

[
          {
            'read_config' => [
                               {
                                 'file' => 'kismet.conf',
                                 'backend' => 'ComplexIni',
                                 'config_dir' => '/home/krzych/configmodel/test'
                               }
                             ],
            'name' => 'Kismet',
            'accept' => [
                           {
                            'match' => 'alert|defaultchannels',
                            'type' => 'list',
                            'cargo' => {
                                          'value_type' => 'string',
                                          'type' => 'leaf'
                                     },
                        },
                            {
                            'match' => '.*',
                            'type' => 'leaf',
                            'value_type' => 'string'
                        }
                        ],
            'element' => [
                           'version',
                           {
                             'value_type' => 'uniline',
                             'summary' => 'Version string',
                             'mandatory' => 1,
                             'type' => 'leaf'
                           },
                           'servername',
                           {
                             'value_type' => 'uniline',
                             'summary' => 'Server name',
                             'mandatory' => 1,
                             'type' => 'leaf',
                             'description' => 'Specifies the server name'
                           },
                           'networkmanagersleep',
                           {
                             'value_type' => 'enum',
                             'summary' => 'Try to put NM to sleep when launching Kismet',
                             'type' => 'leaf',
                             'description' => 'This feature requires  DBus support!',
                             'choice' => [
                                           'true',
                                           'false'
                                         ]
                           },
                           'source',
                           {
                             'cargo' => {
                                          'value_type' => 'string',
                                          'type' => 'leaf'
                                        },
                             'type' => 'list'
                           }
                         ]
          }
];

I decided to make accept parameter similar to element – so user can declare more than one rule. Also, the match field behaves in the same way like in element – instead of writing ‘/channel/’ one has to write ‘channel’. This may be perceived as a limitation, but I wanted to be consistent with existing code.

In this example, there are two accept rules. The first defines that all elements with ‘alert’ or ‘defaultchannels’ in name will be treated as lists – second one specifies that all remaining elements are to be treated like strings. Notice, that the element parameter is still preset – it has precedence over accept. So, the model will parse all items defined in element and then try to load the rest using accept.

Now you can use this model to edit regular Kismet configuration file:

Editing kismet config file

As you may see, this model has a small problem – there are config variables incorrectly recognized as lists (e.g. alertbacklog). It’s easy to fix, one only needs to modify regexp in accept declaration. I made this mistake on purpose – to show that one needs to define regexps carefully (or maybe it would be good idea to autodetect a type?)

How it works?

The most important part of this feature lies in Node.pm file:

1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371

    #Load elements matched by accept parameter
    if(defined $self->{model}{accept}){
 
        foreach my $acc (@{$self->{model}{accept}}){
            my $mr = eval {qr/$acc->{match}/; };
 
            my $nvh = dclone $acc;
            delete $nvh->{match};
 
            #Now, $h contains all elements not yet parsed
            foreach my $elt (keys %$h){
 
                if ($elt =~ $mr){
                    #add element...
                    $self->{model}{element}{$elt} = $nvh;
                    $self->create_element($elt);
 
                    #add to element list...
                    push @{$self->{model}{element_list}}, $elt;
 
                    $self->{model}{experience}{$elt} = 'beginner';
                    $self->{model}{summary}{$elt} = '';
                    $self->{model}{level}{$elt} = 'normal';
                    $self->{model}{description}{$elt} = '';
                    $self->{model}{status}{$elt} = 'standard';
 
                    #Setup 'original' values. These are extracted by reset_element_property.
                    #Without these two lines, aforementioned method would set experience and level for
                    #elements added here to 'undef' - rendering model uneditable.
 
                    $self->{config_model}{model}{$self->config_class_name}{level}{$elt} = 'normal';
                    $self->{config_model}{model}{$self->config_class_name}{experience}{$elt} = 'beginner';
 
                    #load value
                    #TODO: annotations
                    my $obj = $self->fetch_element($elt,'master', not $check) ;
                    $obj ->load_data(delete $h->{$elt}) ;
                }
            }
        }
    }

As you can see, accept rules are parsed one by one – when a match is found, element is added to the model and data is then loaded. Since this is a fresh code written today, it may has a lot of problems, but is a good base to extend this feature.

P.S. Dominique, I knew that I should make some testcases and then ask you abut further work, but I couldn’t resist the urge to code

# Sources are defined as:
# source=sourcetype,interface,name[,initialchannel]
 
source = ipw2100,eth1,intel
source = madwifi,ath0,atheros

As you can see, source variable is repeated – in this case, backend based on Config::Tiny will report only one occurrence of it.

New backend

I decided to write a new backend. Patching Config::Tiny is not a good idea in my humble opinion – modifying this module could break applications dependent on it. Dominique suggested that repeated variables should be handled as lists. I had some trouble with Config::Model docs, but with his help I managed to create a fully working backend today.

Reading file

64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100

    my $data = {};
    my $section;
 
    foreach ($args{io_handle}->getlines) {
	next if /^[;#]/ ;
	chomp ;
	next if/^\s*$/;
 
	#Update section name
	if(/\[(.*)\]/)
	{
		$section = $1;
		next;
	}
 
	my ($name,$val) = split(/\s*=\s*/);
 
	#Get the 'right' ref
	my $r = $data;
 
	if (defined $section)
	{
		$data->{$section} = {} if not defined $data->{$section};
		$r = $data->{$section}
	}
 
	if (defined $r->{$name})
	{
		$r->{$name} = [$r->{$name}] if ref($r->{$name}) ne 'ARRAY';
		push @{$r->{$name}}, $val;
	}
	else
	{
		$r->{$name} = $val;
	}
    }
    $self->node->load_data($data);

This simple loop goes through all of the lines of a config file and builds a Perl data structure of it. All values are initially stored as strings. When a variable name appears for the second time, it’s converted to an array of values. Finally, data is loaded into a model using load_data method.

Problems

This approach solves only one problem of Config::Tiny – comments in the file are still lost. However, this can be easily solved – all I need to do is store comments separately (like in ShellVar backend). Some basic file validation would be good too.

Files

New backend
Modified Kismet model (source parameter as list)

P.S.
I promised to post some notes about Config::Model docs, but I’ll do it after some more investigation.

Hi everybody!

I’m happy to announce that I have been chosen as a student working on GSoC “Improve Config file Upgrades” project for Debian (mentored by Dominique Dumont). Since it’s my first blog post, it’s time to introduce myself:

My name is Krzysztof Tyszecki and I’m third year CS student at Wroclaw University of Technology (faculty of Fundamental Problems of Technology). I’m using GNU/Linux since about 5 years (Gentoo Linux for about ~4 years, now Debian and Arch).

If after a few months you will simply forget about manually editing configuration files after upgrades, that will mean that this project had succeeded. Dominique nicely described some technical details in post at his blog.

The model

Since the project will use Config::Model, I was asked to create a simple model to familiarize myself with this tool. I decided to create one for my favorite wireless tool – Kismet. Kismet config file has the INI structure, as you may see on the snippet below:

# Version of Kismet config
version=2007.09.R1
 
# Name of server (Purely for organizational purposes)
servername=Kismet
 
# User to setid to (should be your normal user)
#suiduser=your_user_here
 
# Do we try to put networkmanager to sleep?  If you use NM, this is probably
# what you want to do, so that it will leave the interfaces alone while
# Kismet is using them.  This requires DBus support!
networkmanagersleep=true
 
# Sources are defined as:
# source=sourcetype,interface,name[,initialchannel]
# Source types and required drivers are listed in the README under the
# CAPTURE SOURCES section.
# The initial channel is optional, if hopping is not enabled it can be used
# to set the channel the interface listens on.
# YOU MUST CHANGE THIS TO BE THE SOURCE YOU WANT TO USE
source=none,none,addme
 
# Users outside the US might want to use this list:
# defaultchannels=IEEE80211b:1,7,13,2,8,3,14,9,4,10,5,11,6,12
defaultchannels=IEEE80211b:1,6,11,2,7,3,8,4,9,5,10
 
# 802.11g uses the same channels as 802.11b...
defaultchannels=IEEE80211g:1,6,11,2,7,3,8,4,9,5,10

Of course, it’s only a small part of the file. Since I didn’t manage to create a model using config-model-edit, I used Vim, after all a model is just a nice Perl data structure. Part of the results of my work are below:

[
  {
     'read_config' =>  [
                 {
                  'file' => 'kismet.conf',
                  'backend' => 'ini_file',
                  'config_dir' => '/etc/kismet'
                }
              ],
    'name' => 'Kismet',
    'element' => [
            'version',
            {
              'value_type' => 'uniline',
              'summary' => 'Version string',
              'type' => 'leaf',
            },
            'servername',
            {
              'value_type' => 'uniline',
              'summary' => 'Server name',
              'type' => 'leaf',
              'description' => 'Specifies the server name'
            },
            'suiduser',
            {
              'value_type' => 'uniline',
              'summary' => 'User to setid to',
              'type' => 'leaf'
            },
            'networkmanagersleep',
            {
              'value_type' => 'enum',
              'choice' => [ qw/true false/],
              'summary' => 'Try to put NM to sleep when launching Kismet',
              'type' => 'leaf',
              'description' => 'This feature requires  DBus support!'
            },
            'source',
            {
              'type' => 'leaf',
              'value_type' => 'uniline'
            },
            'configchannels',
            {
              'type' => 'leaf',
              'value_type' => 'uniline',
              'match' => 'IEEE80211(a|ab|b|g):(\d,)*\d'
            }
          ]
  },
];

The model is far from being complete, but from now, code for other variables can be easily added. Some variables should be also labeled as mandatory.

The problems

The biggest problem is that, as you may probably see, my model allows only one “source” and “configchannels” variable. It’s because the INI file backend doesn’t support repeated variables. If you run the following Perl code, you will see that Config::Tiny module used for INI parsing reports only one (last) instance of repeated variable:

#!/usr/bin/perl
use Config::Tiny;
use Data::Dumper;
print Dumper(Config::Tiny->new()->read('/etc/kismet/kismet.conf'));

Besides that, I didn’t found a way to check the correctness of the value other than regular expression yet. While regexps are powerful and it’s entirely possible to define constraints using only regexps – sometimes they’re just not the best choice. Ability to define a function that would perform the check would be great.

The GUI Editor

Dominique asked me for some feedback on config-model-edit, since I had a hard time using it. After loading a model created by hand, it’s easy to edit it using aforementioned tool, but creating one from scratch may be a hard task, especially if somebody is using config-model-edit for the first time.

After issuing command “config-model-edit -model Test” and clicking on the root node, user is presented with such screen:

config-model-edit main window

User can switch between ‘Edit’ and ‘View’ modes using right and left mouse buttons, respectively. This is a nice shortcut, but I think that having a button in UI for that would be a nice usability improvement. Well, after switching to edit mode, situation looks like this:

Editing a model

Color overlays are added by me. Let’s suppose that the user wants to add a configuration class. He clicks the “Add” button and sees an error message with random text:

Error message

It turns out, that he needs to enter the text in edit field and then hit “Add” (this button should be disabled if there’s nothing in the edit field). This is the biggest usability problem and this was the moment when I thought “Well, I’ll just use plain, old Vim”. Other problems, as seen by me:

• “Move” and “Copy” (green overlay) buttons are related more to the list box than to the edit field. These buttons could be in a context menu for the list item.
• If “Move” would be placed in the context menu, instead of renaming highlighted item to the contents of the edit field, it could turn on in-line editing for the list item (I’m not sure if Tk allows this).
• In my humble opinion, “Rename” is a more suitable name for “Move” button.
• “Copy” could make a copy of selected item, naming it “Copy #n of _item_” and turn on in-line editing on the newly added item.
• “Delete selected” and “Remove All” (red) could be placed below the list box or in the context menu.
• “Are you sure you want to delete all of the items” confirmation box after clicking “Remove All” would be nice.
• In this case, “Info” box (yellow) takes a lot of space, and it’s contents are not essential.
• The “keep” checkbox could be a part of the context menu for the edit field.

Of course, current UI may be good once you get used to it and may speedup the process of creating a model. But for a lot of people it can be unnatural and obnoxious. I’m aware that Tk may not be capable of some of proposed changes. Here’s the mockup of the interface as I would seen it (created using Qt Designer):

Quick and dirty mockup

If Tk is limiting the GUI then maybe it would be a good idea to create GTK2 based one, since there are Perl bindings available?