/usr/share/perl5/Config/Model/Manual/ModelCreationIntroduction.pod is in libconfig-model-perl 2.097-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 | # PODNAME: Config::Model::Manual::ModelCreationIntroduction
# ABSTRACT: Introduction to model creation with Config::Model
__END__
=pod
=encoding UTF-8
=head1 NAME
Config::Model::Manual::ModelCreationIntroduction - Introduction to model creation with Config::Model
=head1 VERSION
version 2.097
=head1 Introduction
This page describes how to write a simple configuration
model. Creation of more complex models are described in
L<Creating a model with advanced features|Config::Model::Manual::ModelCreationAdvanced>.
Note that this document shows a lot of Perl data structure to
highlight the content of a model. A Perl data structure is very
similar to a JSON structure. The only thing you need to know are:
=over
=item *
Curly braces C<{ ... }> contain a dictionary of key, value pairs (a
C<hash> in Perl land))
=item *
Square brackets C<[ ... ]> contain a list of items (C<array> or
C<list> in Perl land)
=back
=head1 Some definitions
=over
=item configuration file
Text file where configuration data are stored. This configuration file
is used by an application -- the I<target application>
=item configuration tree
The semantic content of the configuration file stored in a tree
representation
=item configuration model
Structure and constraints of the configuration tree. Like a schema for
the configuration tree
=item target application
The application that uses the configuration file. The application
can be of type C<system> (i.e. the configuration file is located in
C</etc>), C<user> (i.e. the configuration file is located in a user
directory like C<~/.config>) or C<application> (the configuration file
is in or below the current directory)
=item end user
User of the target application
=item application developer
Target application developer
=item model developer
People developing the configuration model. Not necessarily the
application developer
=back
=head1 What is a configuration tree?
Most configuration files are actually organized mostly as a tree
structure. Depending on the syntax of the file, this structure may be
obvious to see (e.g. for XML, Apache) or not so obvious (C<Xorg> syntax,
INI syntax).
For some files like C<approx.conf> or C<adduser.conf>, this tree
structure is quite flat. It looks much like a rake than a tree, but
still, it's a tree.
For instance, this C<approx.conf>:
$pdiffs 1
$max_wait 14
debian http://ftp.fr.debian.org/debian
can have this tree representation:
root
|--pdiff=1
|--max_wait=14
`--distrib(debian)=http://ftp.fr.debian.org/debian
Other configuration files like C<apache2.conf> or C<xorg.conf> have a
structure that look more like a tree.
For instance, consider this C<xorg.conf> snippet:
Section "Device"
Identifier "Device0"
Driver "nvidia"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Device0"
Option "AllowGLXWithComposite" "True"
Option "DynamicTwinView" "True"
SubSection "Display"
Depth 24
EndSubSection
EndSection
Knowing that Xorg.conf can have several Device or Screen sections
identified by their C<Identifiers>, the configuration can be
represented in this tree as:
root
|--Device(Device0)
| `--Driver=nvidia
`--Screen(Screen0)
|--Device=Device0
|--Option
| |--AllowGLXWithComposite=True
| `--DynamicTwinView=True
`--Display
`--Depth=24
One may argue that some C<Xorg> parameter refer to others
(i.e.C<Device> and C<Monitor> value in C<Screen> section) and so they
cannot be represented as a tree. That's right, there are some more
complex relations that are added to the tree structure. This will be
covered in more details when dealing with complex models.
In some other case, the structure of a tree is not fixed. For
instance, C<Device> options in C<Xorg.conf> are different depending on
the value of the C<Device Driver>. In this case, the structure of the
configuration tree must be adapted (morphed) depending on a parameter
value.
Just like XML data can have Schema to validate their content, the
configuration tree structure needs to have its own schema to validate
its content. Since the tree structure cannot be represented as a
static tree without reference, XML like schema are not enough to
validate configuration data.
L<Config::Model> provides a kind of schema for configuration data that
takes care of the cross references mentioned above and of the dynamic
nature of the configuration tree required for C<Xorg> (and others).
=head1 What is a model?
A configuration model defines the configuration tree structure:
=over
=item *
A model defines one or more configuration class
=item *
At least one class is required to define the configuration tree root
=item *
Each class contains several elements. An element can be:
=over
=item *
A leaf to represent one configuration parameter
=item *
A list of hash of leaves to represent several parameter
=item *
A node to hold a node of a configuration tree
=item *
A list or hash of nodes
=back
=back
These basic relations enable to define the main parts of a
configuration tree.
If we refer to the C<approx.conf> example mentioned above, one only
class is required (let's say the C<Approx> class). This class must
contain (see approx.conf man page):
=over
=item *
A boolean leaf for C<pdiff> (1 if not specified)
=item *
An integer leaf for C<max_wait> (10 seconds unless specified
otherwise)
=item *
A hash of string leaves for C<distrib> (no default).
=back
A configuration model is stored this way by Config::Model:
{
name => 'Approx',
element => [
pdiffs => {
type => 'leaf',
value_type => 'boolean',
upstream_default => '1'
},
max_wait => {
type => 'leaf',
value_type => 'integer',
upstream_default => '10'
},
distributions'=> {
type => 'hash',
index_type => 'string' ,
cargo => {
value_type => 'uniline',
type => 'leaf',
},
}
]
}
The C<Xorg> example leads to a slightly more complex model with several classes:
=over
=item *
C<Xorg> (root class)
=item *
C<Xorg::Device>
=item *
C<Xorg::Screen>
=item *
C<Xorg::Screen::Option> for the Screen options
=item *
C<Xorg::Screen::Display> for theC<Display> subsection
=back
The root class is declared this way:
{
name => 'Xorg',
element => [
Device => {
type => 'hash',
index_type => 'string'
cargo => {
type => 'node',
config_class_name => 'Xorg::Device'
},
},
Screen => {
type => 'hash',
index_type => 'string'
cargo => {
type => 'node',
config_class_name => 'Xorg::Screen'
},
},
]
}
TheC<Xorg::Screen> class is:
{
name => 'Xorg::Screen',
element => [
Device => {
type' => 'leaf',
value_type => 'uniline',
},
Display => {
type => 'hash',
index_type => 'integer'
cargo => {
type => 'node',
config_class_name => 'Xorg::Screen::Display'
},
}
Option => {
type => 'node',
config_class_name => 'Xorg::Screen::Option'
},
]
}
It's now time to detail how the elements of a class are constructed.
=head1 Model analysis
To define the required configuration classes, you should
read the documentation of the target application to :
=over
=item *
Find the structure of the configuration tree
=item *
Identify configuration parameters, their constraints and relations
=back
Last but not least, you should also find several valid examples of
your application configuration. These examples can be used as
non-regression tests and to verify that the application documentation
was understood.
=head1 Model declaration
=head2 Configuration class declaration
Since writing the data structure shown below is not fun (even with
Perl), you are encouraged to use the model editor provided by L<cme>
using C<cme meta edit> command (provided by L<Config::Model::Itself>).
This commands provides a GUI to create or update your model.
When saving, C<cme> writes the data structure in the correct directory.
=head2 Configuration class declaration (the hard way)
In summary, configuration documentation is translated in a format
usable by Config::Model:
=over
=item *
The structure is translated into configuration classes
=item *
Configuration parameters are translated into elements
=item *
Constraints are translated into element attributes
=back
All models files must be written in a specific directory. For
instance, for model C<Xorg>, you must create
C<./lib/Config/Model/models/Xorg.pl>. Other classes
like C<Xorg::Screen> can be stored in their own file
C<./lib/Config/Model/models/Xorg/Screen.pl> or included in C<Xorg.pl>
A model file is a Perl file containing an array for hash ref. Each
Hash ref contains a class declaration:
[ { name => 'Xorg', ... } , { name => 'Xorg::Screen', ... } ] ;
A class can have the following parameters:
=over
=item *
name: mandatory name of the class
=item *
class_description: Description of the configuration class.
=item *
generated_by: Mention with a descriptive string if this class was
generated by a program. This parameter is currently reserved
for C<Config::Model::Itself> model editor.
=item *
include: Include element description from another class.
=back
For more details, see L<Config::Model/Configuration_Model>.
For instance:
$ cat lib/Config/Model/models/Xorg.pl
[
{
name => 'Xorg',
class_description => 'Top level Xorg configuration.',
include => [ 'Xorg::ConfigDir'],
element => [
Files => {
type => 'node',
description => 'File pathnames',
config_class_name => 'Xorg::Files'
},
# snip
]
},
{
name => 'Xorg::DRI',
element => [
Mode => {
type => 'leaf',
value_type => 'uniline',
description => 'DRI mode, usually set to 0666'
}
]
}
];
=head2 Common attributes for all elements
This first set of attributes helps the user by providing guidance
(with C<level> and C<status>) and documentation
(C<summary> and C<description>).
All elements (simple or complex) can have the following attributes:
=over
=item *
C<description>: full length description of the attribute
=item *
C<summary>: one line summary of the above description
=item *
C<level>: is C<important>, C<normal> or C<hidden>. The level is used
to set how configuration data is presented to the user in browsing
mode. Important elements are shown to the user no matter
what. hidden elements are explained with the warp notion.
=item *
C<status>: is C<obsolete>, C<deprecated> or C<standard>
(default). Warnings are shown when using a deprecated element and an exception
is raised when an obsolete element is used.
=back
See L<Config::Model/Configuration_class> for details.
=head2 Leaf elements
Leaf element is the most common type to represent configuration data.
A leaf element represents a specific configuration parameter.
In more details, a leaf element have the following attributes (See
L<Config::Model::Value/Value_model_declaration> doc):
=over
=item type
Set to C<leaf> (mandatory)
=item value_type
Either C<boolean>, C<integer>, C<number>, C<enum>, C<string>,
C<uniline> (i.e. a string without "\n") (mandatory)
=item min
Minimum value (for C<integer> or C<number>)
=item max
Maximum value (for C<integer> or C<number>)
=item choice
Possible values for an enum
=item mandatory
Whether the value is mandatory or not
=item default
Default value that must be written in the configuration file
=item upstream_default
Default value that is known by the target application and thus does
not need to be written in the configuration file.
=back
To know which attributes to use, you should read the
documentation of the target application.
For instance, C<AddressFamily> parameter (sshd_config(5)) is specified
with: I<Specifies which address family should be used by sshd(8).
Valid arguments are "any", "inet" (use IPv4 only), or "inet6" (use
IPv6 only). The default is "any".>
For Config::Model, C<AddressFamily> is a type C<leaf> element,
value_type C<enum> and the application falls back to C<any> if this
parameter is left blank in C<sshd_config> file.
Thus the model of this element is :
AddressFamily => {
type => 'leaf',
value_type => 'enum',
upstream_default => 'any',
description => 'Specifies which address family should be used by sshd(8).',
choice => [ 'any', 'inet', 'inet6' ]
}
=head2 Simple list or hash element
Some configuration parameters are in fact a list or a hash of
parameters. For instance, C<approx.conf> can feature a list of remote
repositories:
# remote repositories
debian http://ftp.fr.debian.org/debian
multimedia http://www.debian-multimedia.org
These repositorie URLs must be stored as a hash where the key is
I<debian> or I<multimedia> and the associated value is a URL. But
this hash must have something which is not explicit in C<approx.conf>
file: a parameter name. Approx man page mentions that:
I<The name/value pairs [not beginning with '$' are used to map distribution names to remote repositories.>.
So let's use C<distribution> as a parameter name.
The example is stored this way in the configuration tree:
root
|--distribution(debian)=http://ftp.fr.debian.org/debian
`--distribution(multimedia)=http://www.debian-multimedia.org
The model needs to declare that C<distribution> is:
=over
=item *
a type C<hash> parameter
=item *
the hash key is a string
=item *
the values of the hash are of type C<leaf> and value_type C<uniline>
=back
distribution => {
type => 'hash',
index_type => 'string',
cargo => {
type => 'leaf',
value_type => 'uniline',
},
summary => 'remote repositories',
description => 'The other name/value pairs are ...',
}
For more details on list and hash elements, see
L<hash or list model declaration|Config::Model::AnyId/Hash_or_list_model_declaration> man page.
=head2 node element
A node element is necessary if the configuration file has more than a
list of variable. In this case, the tree is deeper than a rake and a
node element if necessary to provide a new node within the tree.
In the Xorg example above, the options of C<Xorg::Screen> need their
own sub-branch in the tree:
Screen(Screen0)
`--Option
|--AllowGLXWithComposite=True
`--DynamicTwinView=True
For this, a new dedicated class is necessary>Xorg::Screen::Option>
(see its declaration above). This new class must be tied to the Screen
class with a node element.
A node element has the following parameters:
=over
=item *
type (set to C<node>)
=item *
the name of the configuration class name (>config_class_name>)
=back
So the C<Option> node element is declared with:
Option => {
type => 'node',
config_class_name => 'Xorg::Screen::Option'
},
=head2 Hash or list of nodes
Some configuration files can feature a set of rather complex
configuration entities. For instance C<Xorg.pl> can feature several
Screen or Device definitions. These definitions are identified by the
C<Identifier> parameter:
Section "Device"
Identifier "Device0"
Driver "nvidia"
BusID "PCI:3:0:1"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Device0"
DefaultDepth 24
EndSection
The Xorg configuration tree features 2 elements (Screen and
Device) that use the Identifier parameters as hash keys:
root
|--Device(Device0)
| |--Driver=nvidia
| `--BusId=PCI:3:0:1
`--Screen(Screen0)
|--Device=Device0
`--DefaultDepth=24
And the Xorg model must define these 2 parameters as C<hash>. The
cargo of this hash is of type C<node> and refers to 2 different
configuration classes, one for C<Device> (C<Xorg::Device>) and one for
C<Screen> (C<Xorg::Screen>):
{
name => 'Xorg',
element => [
Device => {
type => 'hash',
index_type => 'string'
cargo => {
type => 'node',
config_class_name => 'Xorg::Device'
},
},
Screen => {
type => 'hash',
index_type => 'string'
cargo => {
type => 'node',
config_class_name => 'Xorg::Screen'
},
},
]
}
=head1 Configuration wizard
Both Perl/Tk and Curses interfaces feature a configuration wizard
generated from a configuration model.
The wizard works by exploring the configuration tree and stopping on
each I<important> element and on each error (mostly missing mandatory
parameter).
When designing a model, you have to ponder for each element:
=over
=item *
The importance level of the parameter (important, normal or
hidden). C<level> is used to set how configuration data is presented
to the user in wizard and browsing mode. Important elements are
shown in the wizard. hidden elements are explained with the warp
notion in L<Creating a model with advanced features|Config::Model::Manual::ModelCreationAdvanced>.
=back
=head1 Reading configuration files
Once the model is specified, Config::Model can generate a nice user
interface, but there's still no way to load or write the configuration
file.
For Config::Model to read the file, the model designer must declare in
the model how to read the file (the read backend).
The read method can use one or more of the following mechanisms:
=over
=item *
Built-in, e.g Perl file, INI file...
=item *
A plugin, i.e. a Perl C<Config::Model::Backend::*> class like C<Config::Model::Backend::Augeas>
=item *
A custom class where a read call-back must be provided
=back
For more details, see L<Config::Model::BackendMgr>.
The name of the backend parameter must be specified in all cases.
=head2 Using built-in read mechanism
C<Config::Model> comes with 3 read/write built in mechanisms:
=over
=item perl_file
A perl data structure (like the ones produced by L<Data::Dumper>).
See L<Config::Model::DumpAsData> for details.
=item ini_file
Windows INI file (note that only simple tree structure can use this backend)
=item cds_file
Config::Model own serialization format (a bit like YAML).
See L<Config::Model::Dumper> for details.
=back
With the backend name, the following parameters must be defined:
=over
=item config_dir
The configuration directory
=item file
Config file name (optional). defaults to C<< <config_class_name>.[pl|ini|cds] >>
=back
read_config => [ { backend => 'cds_file' ,
config_dir => '/etc/cfg_dir',
file => 'cfg_file.cds', # optional
} ],
See L<Config::Model::BackendMgr.pm/Built-in_backend> for details
Note that these parameters can also be set with the graphical
configuration model editor.
=head2 Using a plugin read mechanism
A plugin backend class can also be specified with:
read_config => [ { backend => 'foo' ,
config_dir => '/etc/cfg_dir'
} ]
In this case, Config::Model tries to load C<Config::Model::Backend::Foo>.
(The class name is constructed with C<ucfirst($backend_name)>)
C<read_config> can also have custom parameters that are passed
verbatim to C<Config::Model::Backend::Foo> methods:
read_config => [ { backend => 'foo' ,
config_dir => '/etc/cfg_dir',
my_param => 'my_value',
} ]
This C<Config::Model::Backend::Foo> class is expected to provide the following methods:
=over
=item new
=item read
=item write
=back
Their signatures are explained in
L<Config::Model::BackendMgr doc on plugin backends|Config::Model::BackendMgr/Plugin_backend_classes>
=head2 Using a custom class
In case the plugin mechanism is not possible, a class with an
arbitrary name can be specified:
read_config => [ { backend => 'custom' ,
class => 'MyRead',
config_dir => '/etc/foo', # optional
file => 'foo.conf', # optional
} ]
Even the read method can have an arbitrary name by specifying a
C<function> parameters.
For more details on available parameters on custom backends, see
L<Config::Model::BackendMgr doc on custom backends|Config::Model::BackendMgr/Custom_backend>
=head2 Using several read mechanisms
Several read mechanism can be specified to enable:
=over
=item *
Migration from one syntax to another
=item *
Usage of different libraries (e.g. L<Augeas|http://augeas.net> or pure Perl backend)
=back
For instance, to try Augeas and fall back on a custom class in case of problem, specify:
read_config => [ {
save => 'backup',
file => 'sshd_config',
backend => 'augeas',
config_dir => '/etc/ssh'
},
{
function => 'sshd_read',
backend => 'custom',
class => 'Config::Model::OpenSsh',
config_dir => '/etc/ssh'
} ],
Both specifications are tried in order. If Augeas backend fails
(e.g. Augeas is not installed), the custom backend is used.
An exception is raised if both methods fails. This behavior is
correct for C<OpenSsh>, but it can be a problem if you want to use
Config::Model to create a configuration file from scratch. In this
case you should also specify the C<auto_create> parameter:
read_config => [ { backend => 'custom' ,
class => 'ProcessRead' ,
config_dir => '/etc/foo',
file => 'foo.conf',
auto_create => 1,
} ],
=head1 Writing configuration files
Read and write specifications were designed to be very similar. Most
of the times, the C<read> and C<write> specification are
identical. In this case, there's no need to enter them: the data
specified in the C<read> specification is used to write the
configuration file.
Here's an example:
write_config => [ { backend => 'custom',
class => 'NewFormat'
function => 'my_write',
}
],
Several C<write> specification can be used. They are tried in order,
until the first succeeds.
For more information, see
L<write specification doc|Config::Model::BackendMgr.pm/write_specification>
=head1 Syntax migration example
By combining multiple read specification with C<'one>' write
specification, a configuration file can be migrated from old to new
syntax. The following example migrates a configuration file from a
custom syntax to a perl data file:
{
name => 'Example',
element => [ ... ] ,
read_config => [ { backend => 'perl_file',
config_dir => '/etc/my_cfg/'
} ,
{ backend => 'custom',
class => 'Bar'
},
],
write_config => [ { backend => 'perl_file',
config_dir => '/etc/my_cfg/'
}
],
}
How does this work ? Here's the sequence:
=over
=item 1.
Configuration is stored in old file C</etc/my_cfg/bar.conf>
=item 2.
Config::Model tries to read the config with C<perl_file> read backend
and looks for C</etc/my_cfg/example.pl>. This file is not found so the
read fails.
=item 3.
Config::Model tries the second backend which succeeds and load
configuration data in the configuration tree
=item 4.
Config::Model writes data back from configuration tree using
C<write_config> backend which writes C</etc/my_cfg/example.pl>
=item 5.
At the next invocation, the first C<read> backend will successfully
read the perl configuration file. The old file is left alone and can
be removed later by the system admin.
=back
Thanks to this mechanism, this operation is idempotent so it can
safely be scripted in package scriplets.
=head1 SEE ALSO
=over
=item *
More complex models: L<Config::Model::Manual::ModelCreationAdvanced>
=item *
L<Config::Model::Manual::ModelForUpgrade>: Writing a model for configuration upgrades
=item *
L<Configuration upgrades within Debian packages|http://wiki.debian.org/PackageConfigUpgrade>
=back
=head1 Feedback welcome
Feel free to send comments and suggestion about this page at
config-model-users at lists dot sourceforge dot net.
=head1 AUTHORS
Dominique Dumont <ddumont at cpan.org>
=head1 AUTHOR
Dominique Dumont
=head1 COPYRIGHT AND LICENSE
This software is Copyright (c) 2005-2016 by Dominique Dumont.
This is free software, licensed under:
The GNU Lesser General Public License, Version 2.1, February 1999
=cut
|