NAME

App::Regather::Config - config file processing class

SYNOPSIS

DESCRIPTION

This is a class to log messages.

CONSTRUCTOR

new: Creates a new App::Regather::Config object

filename => config-file-name: Name of the file to parse.
cli => = delete $_{cli};: Hash with CLI provided config options.
logger => = delete $_{logger};: App::Regather::Logg object created preliminary.
fg => 0 | 1: wheather we run in foreground
verbose => N: verbosity level

METHODS

get_ldap_config_file

ldap.conf processing (with Config::Parser::ldap) to add options from it to config object

files searched are:

    $ENV{LDAP_CONF}
    /usr/local/etc/openldap/ldap.conf
    /etc/ldap.conf
    /etc/ldap/ldap.conf
    /etc/openldap/ldap.conf );

the first one found is used.

mangle

modify the created source tree. (resolve uid/gid symbolic to number, add altroot)

config_help

print config lexicon help

output is not sorted, it is in todo

chk_dir

check wheather the target directory exists

chk_file_tt

.tt file existance checker

core_only

informer (to spawn error if core section option been used in not core section)

chk_notify_email

email address validation against regex

    ^[a-z0-9]([a-z0-9.]+[a-z0-9])?\@[a-z0-9.-]+$

chk_plugin

check plugin name against existent plugins list

error

error handler

sub error { my $self = shift; my $err = shift; local %_ = @_;

  $self->{logger}->cc( pr => 'err',
                       fm => "%s: config parser error: %s%s",
                       ls => [ __PACKAGE__,
                               exists $_{locus} ? $_{locus} . ': ' : '',
                               $err ] );
}

CONFIG FILE

An ini-style configuration file is a textual file consisting of settings grouped into one or more sections.

1. do read Config::Parser::Ini documentation section DESCRIPTION for general description of the format used.

2. look at the output of: regather -c regather.conf --config-help

3. look into sources ... (this section is to be amended yet)

So, in general, config file consists of mandatory sections (with theirs subsections) core, ldap and service

core must go first, all other after it.

Each section can have mandatory options.

Each service must have these options:

1. at least one (can be set multiple times, and in that case all of them are checked) option ctrl_attr which contains name of the attribute to check in event LDAP object. In case it is present, the object is considered to be processed, in case it is absent, we skip that event (since LDAP object has no ctrl_attr)

2. one ctrl_srv_re option which is regular expression to match service against LDAP event object DN

3. at least one plugin option. This option should be placed in the end of the section

If both, 1. and 2. checks are positive, then object considered to be processed for that service.

Each service must have atleast one of two possible maps. Those maps are for mapping .tt variables to LDAP attributes values. Maps have names s for single value attributes and m for attributes which can have multiple values.

AUTHOR

Zeus Panchenko <zeus@gnu.org.ua>

COPYRIGHT

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.