how to write lcfg components for edg

PartnerLogo

German Cancio – WP4-install LCFG HOW-TO - n° 1

How to write LCFG components for EDG

Updated 9/2002

[email protected]


Overview

•LCFG – short reminder

Slides stolen from Enrico and Massimo / INFN

•Writing Components for EDG usage

•Outlook: LCFGng and => release 2

•Documentation and links


LCFG – short reminder


WP4 & LCFG

LCFG is originally developed by the Computer Science Department of Edinburgh University

Handles automated installation, configuration and management of machines

Basic features: automatic installation of O.S.

installation/upgrade/removal of all (rpm-based) software packages

centralized configuration and management of machines

extendible to configure and manage custom application software


A collection of agents read configuration parameters and either generate traditional config files or directly manipulate various services

Abstract configuration parameters for all nodes stored in a central repository

ldxprof

LoadProfile

Generic

Component

ProfileObject

rdxprof

ReadProfile

LCFG Objects

Local cache

Client nodes

Web Server

HTTP

XML Profile

LCFG Config Files

Make XMLProfile

Server

LCFG diagram

+inet.services telnet login ftp

+inet.allow telnet login ftp sshd

+inet.allow_telnet ALLOWED_NETWORKS

+inet.allow_login ALLOWED_NETWORKS

+inet.allow_ftp ALLOWED_NETWORKS

+inet.allow_sshd ALL

+inet.daemon_sshd yes

.....

+auth.users myckey

+auth.userhome_mickey /home/mickey

+auth.usershell_mickey /bin/tcsh

+inet.services telnet login ftp

+inet.allow telnet login ftp sshd

+inet.allow_telnet ALLOWED_NETWORKS

+inet.allow_login ALLOWED_NETWORKS

+inet.allow_ftp ALLOWED_NETWORKS

+inet.allow_sshd ALL

+inet.daemon_sshd yes

.....

+auth.users myckey

+auth.userhome_mickey /home/mickey

+auth.usershell_mickey /bin/tcsh

Config files

<inet>

<allow cfg:template="allow_$ tag_$ daemon_$">

<allow_RECORD cfg:name="telnet">

<allow>192.168., 192.135.30.</allow>

</allow_RECORD>

.....

</auth>

<user_RECORD cfg:name="mickey">

<userhome>/home/MickeyMouseHome</userhome>

<usershell>/bin/tcsh</usershell>

</user_RECORD>

<inet>

<allow cfg:template="allow_$ tag_$ daemon_$">

<allow_RECORD cfg:name="telnet">

<allow>192.168., 192.135.30.</allow>

</allow_RECORD>

.....

</auth>

<user_RECORD cfg:name="mickey">

<userhome>/home/MickeyMouseHome</userhome>

<usershell>/bin/tcsh</usershell>

</user_RECORD>

XML profiles

ProfileObject

inet auth

/etc/services/etc/services

/etc/inetd.conf/etc/inetd.conf

/etc/hosts.allow

in.telnetd : 192.168., 192.135.30.

in.rlogind : 192.168., 192.135.30.

in.ftpd : 192.168., 192.135.30.

sshd : ALL

/etc/hosts.allow

in.telnetd : 192.168., 192.135.30.

in.rlogind : 192.168., 192.135.30.

in.ftpd : 192.168., 192.135.30.

sshd : ALL

/etc/shadow/etc/shadow

/etc/group/etc/group

/etc/passwd

....

mickey:x:999:20::/home/Mickey:/bin/tcsh

....

/etc/passwd

....

mickey:x:999:20::/home/Mickey:/bin/tcsh

....


LCFG configuration (I)

Most of the configuration data are common for a category of nodes (e.g. diskservers, computing nodes) and only a few are node-specific (e.g. hostname, IP-address)

Using the cpp preprocessor it is possible to build a hierarchical structure of config files containing directives like #define, #include, #ifdef, comments with /* */, etc...

The configuration of a typical LCFG node looks like this:

#define HOSTNAME pc239 /* Host specific definitions */

#include "site.h" /* Site specific definitions */

#include "linuxdef.h" /* Common linux resources */

#include "client.h" /* LCFG client specific resources */


LCFG configuration (II)From "site.h"

#define LCFGSRV grid01

#define URL_SERVER_CONFIG http://grid01/lcfg

#define LOCALDOMAIN .lnl.infn.it

#define DEFAULT_NAMESERVERS 192.135.30.245

[...]

From "linuxdef.h"

update.interfaces eth0

update.hostname_eth0 HOSTNAME

update.netmask_eth0 NETMASK

[...]

From "client.h"

update.disks hda

update.partitions_hda hda1 hda2

update.pdetails_hda1 free /

update.pdetails_hda2 128 swap

auth.users mickey

auth.usercomment_mickey Mickey Mouse

auth.userhome_mickey /home/Mickey

[...]


LCFG: configuration changes

Server-side: when the config files are modified, a tool (mkxprof) recreates the new xml profile for all the nodes affected by the changes

this can be done manually or with a daemon periodically checking for config changes and calling mkxprof

mkxprof can notify via UDP the nodes affected by the changes

Client-side: another tool (rdxprof) downloads the new profile from the server

usually activated by an LCFG component at boot

can be configured to work as daemon periodically polling the server daemon waiting for notifications started by cron at predefined times


LCFG components for EDG usage


LCFG: what’s a component?

Component == object

It's a simple shell script (but in LCFGng it can be a perl script)

Each component provides a number of “methods” (start, stop, reconfig,...) which are invoked at appropriate times

A simple and typical object behaviour: Started when notified of a configuration change

Loads its configuration (locally cached)

Configures the appropriate services, by translating config parameters into a traditional config file and reloading a service if necessary (e.g. restarting a init.d service).


LCFG: custom components

LCFG provides components to manage the configuration of services of a machine: inet, auth, nfs, cron, ...

Admins can build new custom components to configure and manage their own applications:

define your custom “resources” (configuration parameters)

Write a script containing standard methods with your custom code.

Include in your script a generic library, which contains the definition of common function used by all components (config loading, log, output, ...)

For simple components usually just a few lines of code


Writing LCFG components for EDG

Software written for EDG should be portable to whatever farm management system is used.

It is therefore recommended to use whenever possible, standard SysV procedures for managing services: init.d scripts and chkconfig.

LCFG should not be used for replacing existing SysV init.d functionality!

LCFG should be used for retrieving configuration information from the CDB and recreate

local config files

Restarting services if needed via init.d scripts (restart/reload)

Enabling/disabling SysV services to match the configuration DB’s contents (using chkconfig)


LCFG component methods for EDG

Methods to implement:

Configure(): Reconfigures the service and notifies running processes. The most important method for EDG usage.

Start(): ‘starts’ the component. Should only call Configure() for EDG usage.

Methods not recommended for EDG: Stop(), Run(), Suspend(), Resume(), Lock(), Query()

Doc(): use a .pod file instead.


EDG / LCFG component template (I)

#!/bin/bash2

class=mycomp # set the name of the component (mycomp)

. /etc/obj/generic # include std methods and definitions

# Start the component

Start() {

}

# Do the configuration

Configure() {

}

# 'main' program

Case “$1” in

configure) Configure;;

*) DoMethod “$@”;;

esac


LCFG component template (II)

Start() method:

# ‘Start’ the component

Start() {

Generic_Start; # standard setup steps

Configure; # reconfigure the component

if [ $? = 0 ]; then

OK "Component mycomp started"

else

Fail "Starting component mycomp"

fi

}


LCFG component template (III)

Configure() method:

# Do the configuration

Configure() {

LoadResources myresource1 myresource2 …

CheckResources myresource1 myresource2 …

# your code

do_whatever …

return status;

}


LCFG component template (IV)

The specific part in the configure() method will usually contain three steps:

# 1. Load myconfig resource as environment variable

LoadResources myconfig

CheckResources myconfig

# 2. Generate (or update) config file

sed –e “s%MYCONFIG%$myconfig%” \ /etc/obj/conf/myconfigtemplate > /etc/myconfig

# 3. Reload/restart a service if neccessary

/etc/rc.d/init.d/myservice reload


EDG relevant built-in standard functions

LoadResources resource1 resource2 …: loads resources into the environment

CheckResources resource1 resource2 …: checks that resources are defined in the environment, fails otherwise

Fail string: prints out a [FAIL] message and exits ($? = 1)

Warn string: prints out [WARNING] message

OK string: prints out [OK] message

LogMessage string: Adds message to logfile

(see also the /etc/obj/generic file)


Configuration information (I)

Configuration information is stored on the LCFG server in two types of files:

1. The resource definition files (.def)

2. The normal .h & machine configuration files.


Configuration information (II)

1. The .def files contain default resource information:

mycomp.def

# component name

class mycomp

# implemented methods

methods start configure

# defined resources and defaults

myconfig1

myconfig2 defaultvalue2


Configuration information (III)

2. The normal .h & machine config files, where the default configuration is enhanced/overwritten:

mycomponent.<resource> <value>

mycomp.myconfig1 whatevervalue

mycomp.myconfig2 whateverothervalue

Some special resources have to be declared for including a component to be deployed:

# add to profile (always needed)

EXTRA(profile.components) mycomp

# start on boot time (if required)

EXTRA(boot.services) mycomp

# method to call on runtime config changes (if required)

profile.reconfig_mycomp configure


More complex configurations

Sometimes, key-value pairs are not sufficient for the required configurations.

For example: arrays or lists

LCFG has a mechanism for mapping hierarchical structures into key-value pairs…

Table with person names, ages, and phone numbers (.def file)

@persons age_$ phone_$

persons

age_$

phone_$


More complex configurations (II)

Now we want to add the following to the node config:

John, 35, 12346 and Phil, 21, 54321

The node config file will look like:

mycomp.persons John Phil

mycomp.age_John 35

mycomp.phone_John 12346

mycomp.age_Phil 21

mycomp.phone_Phil 54321

The persons, age_John, phone_John, age_Phil, phone_Phil resources will be accessible as environment variables as any other resource.


More complex configurations (III)

The component accessing the info needs to do:

LoadResources persons

for i in $persons ; do

LoadResources age_$i phone_$i

agehlp=age_$i ; age=${!agehlp}

phonehlp=phone_$i ; phone=${!phonehlp}

echo name: $i – age: $age – phone: $phone ;

done

(using bash2 semantics)


More complex configurations (IV)

Note that there is no limit in the nesting of resources (lists of lists are possible as well as lists of lists of lists)

There are some examples (obj-update)

However it is complex to handle in the current production testbed LCFG.


Some tipps

Avoid dumping configuration files literally into the database

@configlines configline_$

configlines 01 02 03 04 05 …

configline_01 FARM=MOOH_BAR

configline_02 MILK_NODE=COW_001

...

This leads to some problems, eg. when you overwrite values for host specific values

How do you know that configline_324 is still the line you wanted to change?

Rather use a template configuration file shipped with the component RPM Substitute relevant entries in the template cf file With LCFGng (release 1.3) you can use a built-in template processor for this.

Keep explicit configuration information in the LCFG config files.


Example

ldconf - Configures /etc/ld.so.conf (Cal Loomis)

.def file:

class ldconf

methods start configure

conffile

paths

Resources defined on server:

conffile /etc/ld.so.conf

paths /usr/local/lib /opt/globus/lib


Example (II)

Component: Configure() method

Configure() {

LoadResources conffile paths CheckResources conffile paths # Update ld.so.conf file. for i in $paths; do line=`grep $i $conffile` if [ -z "$line" ]; then echo "$i" >> $conffile fi done /sbin/ldconfig; return $?;}


LCFGng and => release 2


LCFGng (release 1.4)

Changes:

LoadResources/CheckResources disappear (all resources loaded from the beginning)

Resources are accessed as LCFG_<component>_myresource (eg. $LCFG_mycomponent_myresource)

The default start() method already calls Configure()

Improved log rotating

A template substitution processor allows for fast generation of config files

Changes documented under http://www.lcfg.org/doc/lcfg-ngeneric.pdf. Example components available from EDG CVS.

A backwards compatibility module allows to import old-style components without any modifications.

The EDG recommendations outlined in this talk still apply.


LCFGng (II)

Perl component support

Components can be written also in Perl (same functionality available). We recommend to phase out shell components. See examples later on.

(EDG only) New component configuration access library

This library allows true hierarchical configuration structure access on the client side

Implements a subset of the Node View Access API http://cern.ch/hep-proj-grid-fabric/config/documents/nva

Implemented only for Perl components.

The server side (configuration and .def files) will continue to use key-value pairs until after release 2.


Perl components in LCFGng for EDG#!/usr/bin/perl -w

package LCFG::MyComp;

@ISA = qw(LCFG::Component);

use strict;

use LCFG::Component;

use LCFG::Config; # EDG specific

sub Configure($$@) {

my ($self,$res) = @_;

my $config=LCFG::Config->new($res);

my $age=$config->getValue('/persons/John/age');

$self->Fail( "too young") unless ($age>18);

}

new LCFG::MyComp() -> Dispatch();

The component methods are the same,

but configuration access is simplified


Perl components (II)

$self->Info ("disks configured: "); my $disks=$config->getElement('/disks');

while ($disks->isNextElement()) { my $disk_name=$disks->getNextElement(); $self->Info (“found disk: ".$disk_name); my $partitions=$config->getElement ('/disks/'.$disk_name.'/partitions');

while ($partitions->isNextElement()) { my $part_name=$partitions->getNextElement(); $self->Info (“found partition: ".$part_name); } }

With the NVA API, components can browse complex configurations,

structured as trees


Documentation and links

LCFGng ‘out of the box’: http://www.lcfg.org

EDG components and extensions: Check on the EDG CVS repository, http://datagrid.in2p3.fr -> fabric_mgt/edg-lcfg

New EDG configuration access API: http://cern.ch/hep-proj-grid-fabric/config/documents/nva

Documentation (HOW-TO): http://datagrid.in2p3.fr/cgi-bin/cvsweb.cgi/fabric_mgt/edg-lcfg/COM

PONENTS-HOWTO

WP4-install homepage: http://cern.ch/wp4-install

how to write lcfg components for edg

Documents