1 / 34

How to write LCFG components for EDG

How to write LCFG components for EDG. Updated 9/2002 German.Cancio@cern.ch. 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.

abner
Télécharger la présentation

How to write LCFG components for EDG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. How to write LCFG components for EDG Updated 9/2002 German.Cancio@cern.ch

  2. Overview • LCFG – short reminder Slides stolen from Enrico and Massimo / INFN • Writing Components for EDG usage • Outlook: LCFGng and => release 2 • Documentation and links

  3. LCFG – short reminder

  4. 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

  5. <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 Config files +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 LCFG Config Files Read Profile Load Profile HTTP rdxprof ldxprof /etc/shadow Profile Generic /etc/group Object Make XML Profile Component /etc/passwd .... mickey:x:999:20::/home/Mickey:/bin/tcsh .... Web Server Local cache /etc/services XML Profile LCFG Objects /etc/inetd.conf Profile /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 Object Client nodes Server inet auth LCFG diagram Abstract configuration parameters for all nodes stored in a central repository A collection of agents read configuration parameters and either generate traditional config files or directly manipulate various services

  6. 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 */

  7. 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 [...]

  8. 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

  9. LCFG components for EDG usage

  10. 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).

  11. 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

  12. 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)

  13. 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.

  14. 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

  15. 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 }

  16. LCFG component template (III) • Configure() method: # Do the configuration Configure() { LoadResources myresource1 myresource2 … CheckResources myresource1 myresource2 … # your code do_whatever … return status; }

  17. 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

  18. 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)

  19. Configuration information (I) Configuration information is stored on the LCFG server in two types of files: • The resource definition files (.def) • The normal .h & machine configuration files.

  20. 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

  21. 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

  22. 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_$

  23. 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.

  24. 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)

  25. 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.

  26. Some tipps • Avoiddumping 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.

  27. 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

  28. 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 $?;}

  29. LCFGng and => release 2

  30. 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.

  31. 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.

  32. 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

  33. 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

  34. 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/COMPONENTS-HOWTO • WP4-install homepage: http://cern.ch/wp4-install

More Related