1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
* Config-Model
:PROPERTIES:
:CUSTOM_ID: config-model
:END:
Configuration schema on steroids.
* What is Config-Model project
:PROPERTIES:
:CUSTOM_ID: what-is-config-model-project
:END:
[[https://metacpan.org/pod/Config::Model][Config::Model]] is:
- a set of configuration editor and validator for several projects like
[[http://www.openssh.com/][OpenSSH]], [[https://freedesktop.org/wiki/Software/systemd/][Systemd]], [[http://www.lcdproc.org/][LcdProc]]... See [[https://github.com/dod38fr/config-model/wiki/Available-models-and-backends#Available_models_and_configuration_editors][full list of Configuration editors]]
- a framework that enables a project developer (or any advance user) to
provide a configuration editor and validator to his users.
To generate a configuration editor and validator for a project,
[[https://metacpan.org/pod/Config::Model][Config::Model]] needs:
- a description of the structure and constraints of a project
configuration. (this is called a model, but could also be called a
schema)
- a way to read and write configuration data. This can be provided by
[[https://github.com/dod38fr/config-model/wiki/Available-models-and-backends#Available_backend][built-in read/write backends]] or by a [[http://search.cpan.org/dist/Config-Model/lib/Config/Model/Backend/Any.pm#How_to_write_your_own_backend][new read/write backend]].
With the elements above, [[https://metacpan.org/pod/Config::Model][Config::Model]] generates
interactive configuration editors (with integrated help and data
validation) and support several kinds of user interface, e.g. graphical,
interactive command line. See the [[https://github.com/dod38fr/config-model/wiki/Available-models-and-backends#Available_user_interfaces][list of available user interfaces]]
** Installation
:PROPERTIES:
:CUSTOM_ID: installation
:END:
See [[https://github.com/dod38fr/config-model/blob/master/README.install.pod][installation instructions]]. Perl developers can also [[file:build-from-git.md][build Config::Model from git]]
** Getting started
:PROPERTIES:
:CUSTOM_ID: getting-started
:END:
- To manage your configuration files with existing modules, see
[[https://github.com/dod38fr/config-model/wiki/Using-cme][Using cme wiki page]]
- To create configuration tools for your favorite project, see this
[[https://metacpan.org/pod/Config::Model::Manual::ModelCreationIntroduction][introduction to model creation]]
** How does this work ?
:PROPERTIES:
:CUSTOM_ID: how-does-this-work
:END:
Using this project, a typical configuration editor will be made of 3
parts :
1. The user interface ([[http://search.cpan.org/dist/Config-Model/script/cme][cme]] program and some other optional modules)
2. The validation engine which is in charge of validating all the
configuration information provided by the user. This engine is made
of the framework provided by this module and the configuration
description (often referred as "configuration model", this could also
be known as a schema).
3. The storage facility that store the configuration information
(currently several backends are provided: ini files, perl files)
The important part is the configuration model used by the validation
engine. This model can be created or modified with a graphical editor
([[http://search.cpan.org/dist/Config-Model-Itself/lib/App/Cme/Command/meta.pm][cme meta edit]] provided by [[https://metacpan.org/pod/Config::Model::Itself][Config::Model::Itself]]).
** Don't we already have some configuration validation tools ?
:PROPERTIES:
:CUSTOM_ID: dont-we-already-have-some-configuration-validation-tools
:END:
You're probably thinking of tools like webmin. Yes, these tools exist
and work fine, but they have their set of drawbacks.
Usually, the validation of configuration data is done with a script
which performs semantic validation and often ends up being quite complex
(e.g. 2500 lines for Debian's xserver-xorg.config script which handles
xorg.conf file).
In most cases, the configuration model is expressed in instructions
(whatever programming language is used) and interspersed with a lot of
processing to handle the actual configuration data.
** What's the advantage of this project ?
:PROPERTIES:
:CUSTOM_ID: whats-the-advantage-of-this-project
:END:
[[https://metacpan.org/pod/Config::Model][Config::Model]] projects provide a way to get a validation engine where
the configuration model is completely separated from the actual
processing instructions.
A configuration model can be created and modified with the graphical
interface provided by [[#cme-meta-edit]["cme meta edit"]] distributed with
[[https://metacpan.org/pod/Config::Model::Itself][Config::Model::Itself]]. The model is saved in a declarative form
(currently, a Perl data structure). Such a model is easier to maintain
than a lot of code.
The model specifies:
- the structure of the configuration data (which can be queried by
generic user interfaces)
- the properties of each element (boundaries check, integer or string,
enum like type ...)
- the default values of parameters (if any)
- mandatory parameters
- Warning conditions (and optionally, instructions to fix warnings)
- on-line help (for each parameter or value of parameter)
So, in the end:
- maintenance and evolution of the configuration content is easier
- user will see a *common* interface for *all* programs using this
project.
- upgrade of configuration data is easier and sanity check is performed
- audit of configuration is possible to check what was modified by the
user compared to default values
** What about the user interface ?
:PROPERTIES:
:CUSTOM_ID: what-about-the-user-interface
:END:
[[https://metacpan.org/pod/Config::Model][Config::Model]] interface is launched with [[https://metacpan.org/pod/App::Cme::Command::edit][cme edit]] command. Cme
provides the follwing interfaces:
- Graphical with [[https://metacpan.org/pod/Config::Model::TkUI][Config::Model::TkUI]] (Perl/Tk interface).
- a shell-like interface (plain or based on [[https://metacpan.org/pod/Term::ReadLine][Term::ReadLine]] with
[[https://metacpan.org/pod/Config::Model::TermUI][Config::Model::TermUI]]) with =cme edit --ui shell=
- based on curses with [[https://metacpan.org/pod/Config::Model::CursesUI][Config::Model::CursesUI]] with =cme edit --ui
curses=
There'a also a [[https://en.wikipedia.org/wiki/Filesystem_in_Userspace][FUSE]] interface provided by [[https://metacpan.org/pod/App::Cme::Command::fusefs][cme fusefs]]. This commands
maps all configuration items to a file system. This can be used to
edit long text value in YAML configuration or in Debian package files.
All these interfaces are generated from the configuration model.
And configuration model can be created or modified with a graphical user
interface ([[#cme-meta-edit]["cme meta edit"]])
** What about configuration data storage ?
:PROPERTIES:
:CUSTOM_ID: what-about-configuration-data-storage
:END:
Since the syntax of configuration files vary wildly form one program to
another, most people who want to use this framework will have to provide
a dedicated parser/writer.
Nevertheless, this project provides a writer/parser for some common
format: ini style file, JSON and perl file. These are called backends.
Other backends are provided for [[https://metacpan.org/dist/Config-Model-Backend-Yaml][YAML]] and [[https://metacpan.org/dist/Config-Model-Backend-Augeas][Augeas]] by other modules.
** More information
:PROPERTIES:
:CUSTOM_ID: more-information
:END:
See
- the [[https://github.com/dod38fr/config-model/wiki][config-model wiki]] (i.e. the wiki tab above)
- [[https://ddumont.wordpress.com/category/perl/configmodel/]]
|
