diff options
31 files changed, 1287 insertions, 140 deletions
diff --git a/doc/authentication.txt b/doc/authentication.txt index aa741903d..2a72917a3 100644 --- a/doc/authentication.txt +++ b/doc/authentication.txt @@ -12,7 +12,7 @@ Scenarios Default settings work well; machines do not float, and a per-client password is not required. -2. :doc:`NAT_HOWTO` +2. `NAT_HOWTO <http://trac.mcs.anl.gov/projects/bcfg2/wiki/NAT_HOWTO>`_ * Build client records in advance with bcfg2-admin, setting a uuid for each new client. diff --git a/doc/client/index.txt b/doc/client/index.txt new file mode 100644 index 000000000..7762b677c --- /dev/null +++ b/doc/client/index.txt @@ -0,0 +1,10 @@ +.. client-index: + +The Bcfg2 Client +================ + +.. toctree:: + :maxdepth: 2 + :glob: + + tools/* diff --git a/doc/client/tools/index.txt b/doc/client/tools/index.txt new file mode 100644 index 000000000..5a8f80c2e --- /dev/null +++ b/doc/client/tools/index.txt @@ -0,0 +1,108 @@ +.. _client-tools-index: + +Client Tool Drivers +=================== + +Client tool drivers allow bcfg2 to execute configuration operations by interfacing with platform and distribution specific tools. + +Tool drivers handle any reconfiguration or verification operation. So far we have tools that primarily deal with packaging systems and service management. The POSIX tool also handles file system and permissions/groups operations. + +To write your own tool driver, to handle a new packaging format, or new service architecture see WritingClientToolDrivers. + +When the bcfg2 client is run, it attempts to instantiate each of these drivers. The succeeding list of drivers are printed as a debug message after this process has completed. Drivers can supercede one another, for example, the Yum driver conflicts (and unloads) the RPM driver. This behavior can be overridden by running the bcfg2 client with the -D flag. This flag takes a colon delimited list of drivers to use on the system. + +Currently these are the tool drivers that are distributed with bcfg2: + +Action +------ + +Pre and post-install tests and actions. This driver executes commands and supplies status information to the bcfg2 server via the statistics mechanism. It can also be used to prevent bundle installation when pre-conditions are not met. See the UsingActions page for more details. + +APT +--- + +Debian Packages. This tool driver is used to handle packages on dpkg based systems and employs the "apt" executable. + +Blast +----- + +Blastwave Packages. This tool driver is for blastwave packages on solaris + +Chkconfig +--------- + +Tool to manage services (primarily on Redhat based distros). + +.. note:: Start and stop are standard arguments, but the one for reload isn't consistent across services. You can specify which argument to use with the `reload` property in Service tags. Example: `<Service name="ftp" reload="condrestart" status="on" type="chkconfig">` + +DebInit +------- + +Debian Service Support; exec's update-rc.d to configure services. + +Encap +----- + +`Encap <http://www.encap.org>`_ Packages. + +FreeBSDInit +----------- + +FreeBSD Service Support. Only bundle updates will work. + +FreeBSDPackage +-------------- + +FreeBSD Packages. Verifies packages and their version numbers but can't install packages. + +launchd +------- + +Mac OS X Services. To use this tool, you must maintain a standard launch daemon .plist file in `/Library/LaunchDaemons/` (example ssh.plist) and setup a `<Service name="com.openssh.sshd" type="launchd" status="on" />` entry in your config to load or unload the service. Note the name is the ''Label'' specified inside of the .plist file + +Portage +------- + +Support for Gentoo Packages. + +POSIX +----- + +Files and Permissions are handled by the POSIX driver. Usage well documented other places. + +RcUpdate +-------- + +Uses the rc-update executable to manage services on distributions such as Gentoo. + +RPM +--- + +Executes rpm to manage packages most often on redhat based systems. +'''DEPRECATED:''' in favor of RPMng + +RPMng +----- + +Next-generation RPM tool, will be default in upcoming release. Handles RPM sublties like epoch and prelinking and 64-bit platforms better than RPM client tool. [wiki:ClientTools/RPMng RPMng/YUMng Documentation.] + +SMF +--- + +Solaris Service Support. + +SYSV +---- + +Handles System V Packaging format that is available on Solaris. + +Yum +--- + +Handles RPMs using the YUM package manager. +'''DEPRECATED: ''' in favor of YUMng + +YUMng +----- + +Handles RPMs using the YUM package manager. Handles sublties better than the Yum client tool. [wiki:ClientTools/RPMng RPMng/YUMng Documentation.] diff --git a/doc/client/tools/yumng.txt b/doc/client/tools/yumng.txt new file mode 100644 index 000000000..82360f1d5 --- /dev/null +++ b/doc/client/tools/yumng.txt @@ -0,0 +1,618 @@ +.. _client-tools-yumng: + +================================ +BCFG2 RPMng/YUMng Client Drivers +================================ + +Introduction +============ + +The goal of this driver is to resolve the issues that exist with the RPM and Yum client tool drivers. + +For the most part, the issues are due to RPM being able to have multiple packages of the same name installed. This is an issue on all Red Hat and SUSE based distributions. + +Examples of this are: + +* SLES10 and openSUSE 10.2 both install six GPG keys. From an RPM perspective this means that there are six packages with the name gpg-pubkey. +* YUM always installs, as opposed to upgrades, kernel packages. This is hard coded in YUM (actually it can be overridden in yum.conf), so systems using YUM will eventually have multiple kernel packages installed. +* Red Hat family x86_64 based systems frequently have both an x86_64 and an i386 version of the same package installed. + +The new Pkgmgr format files with Instances are therefore the only way to accurately describe an RPM based system. It is recommended that all RPM based systems be changed to use the new format configuration files and the RPMng driver. Alternatively, you can use the newer :ref:`Packages <plugins-generators-packages>` plugin. + +Development Status +================== + +Initial development of the drivers was done on Centos 4.4 x86_64, with testing on openSUSE 10.2 x86_64. Centos has been tested with a new style Pkgmgr file and openSUSE with an old style file (see the Configuration section below for what this means). Testing has now moved to Centos 5 x86_64 adn old style files are no longer (as of 0.9.5) being tested. + +RPMng/YUMng are the default RPM drivers from bcfg2 0.9.5 and later. + + +Features +======== + +* Limited support for 0.9.4 and earlier Pkgmgr configuration files. See Configuration below for details. +* Full RPM package identification using epoch, version, release and arch. +* Support for multiple instances of packages with the Instance tag. +* Better control of the RPM verification using the pkg_checks, pkg_verify and verify_flags attributes. +* Support for install only packages such as the kernel packages. +* Support for per instance ignoring of individual files for the RPM verification with the Ignore tag. +* Multiple package Instances with full version information listed in interactive mode. +* Support for installation and removal of gpg-pubkey packages. +* Support for controlling what action is taken on package verification failure with the install_action, version_fail_action and verify_fail_action attributes. + + +RPMng Driver Overview +===================== + +The RPMng driver uses a mixture of rpm commands and rpm-python as detailed in the sections below. + +rpmtools module +--------------- + +The rpmtools module conatins most of the rpm-python code and is imported by RPMng.py and YUMng.py. + +RPMng.RefreshPackages() +----------------------- + +The RPMng.RefreshPackages method generates the installed dict using rpm-python code from the rpmtools module. Full name, epoch, version, release and arch information is stored. + +RPMng.VerifyPackages() +---------------------- + +The RPMng.VerifyPackages method generates a number of structures that record the state of the of the system compared to the bcfg2 literal configuration retrieved from the server. These structures are mainly used by the RPMng.Install method. + +AS part of the verification process an rpm package level verification is carried out using rpm-python code from the rpmtools module. Full details of the failures are returned in a complicated dict/list structure for later use. + +RPMng.Install() +--------------- + +The RPMng.Install method attempts to fix what the RPMng.VerifyPackages method found wrong. It does this by installing, reinstalling, deleting and upgrading RPMs. RPMng.Install does not use rpm-python. It does use the following rppm commands as appropriate:: + + rpm -install + + rpm --import + + rpm -upgrade + +A method (RPMng.to reinstall_check()) to decide whether to do a reinstall of a package instance or not has been added, but is very simple at this stage. Currently it will prevent a reinstall if the only reason for a verification failure was due to an RPM configuration (%config) file. A package reinstall will not replace these, so there is no point reinstalling. + +RPMng.Remove() +-------------- + +The RPMng.Remove method is written using rpm-python code in the rpmtools module. Full nevra information is used in the selection of the package removal. + +Installation +============ + +isprelink +--------- + +This is a Python C extension module that checks to see if a file has been prelinked or not. It should be built and installed on systems that have the prelink package installed (only Red Hat family systems as far as I can tell). rpmtools will function without the isprelink module, but performance is not good. + +Source can be found here ftp://ftp.mcs.anl.gov/pub/bcfg/isprelink-0.1.2.tar.gz + +To compile and install prelink, execute:: + + python setup.py install + +in the rpmtools directory. The elfutils-libelf-devel package is required for the compilation. + +There are Centos x86_64 RPMs here ftp://ftp.mcs.anl.gov/pub/bcfg/redhat/ + +Configuration and Usage +======================= + +Loading of RPMng +---------------- + +The RPMng driver can be loaded by command line options, client configuration file options or as the default driver for RPM packages. + +From the command line:: + + bcfg2 -n -v -d -D Action,POSIX,Chkconfig,RPMng + +This produces quite a bit of output so you may want to redirect the output to a file for review. + +In the bcfg2.conf file:: + + [client] + #drivers = Action,Chkconfig,POSIX,YUMng + drivers = Action,Chkconfig,POSIX,RPMng + +.. note:: Note that loading this driver will unload the RPM driver, so the Yum driver will not work. + +Configuration File Options +-------------------------- + +A number of paramters can be set in the client configuration for both the RPMng and YUMng drivers. Each driver has its own section. A full client configuration file with all the options specified is below:: + + [communication] + protocol = xmlrpc/ssl + password = xxxxxx + user = yyyyyyy + fingerprint = 1234567890abcdef + + [components] + bcfg2 = https://bcfg2:6789 + + [client] + #drivers = Action,Chkconfig,POSIX,YUMng + drivers = Action,Chkconfig,POSIX,RPMng + + [RPMng] + pkg_checks = true + pkg_verify = true + erase_flags = allmatches + installonlypackages = kernel, kernel-bigmem, kernel-enterprise, kernel-smp, kernel-modules, kernel-debug, kernel-unsupported, kernel-source, kernel-devel, kernel-default, kernel-largesmp-devel, kernel-largesmp, kernel-xen, gpg-pubkey + install_action = install + version_fail_action = upgrade + verify_fail_action = reinstall + + [YUMng] + pkg_checks = True + pkg_verify = true + erase_flags = allmatches + autodep = true + installonlypackages = kernel, kernel-bigmem, kernel-enterprise, kernel-smp, kernel-modules, kernel-debug, kernel-unsupported, kernel-source, kernel-devel, kernel-default, kernel-largesmp-devel, kernel-largesmp, kernel-xen, gpg-pubkey + install_action = install + version_fail_action = upgrade + verify_fail_action = reinstall + +installOnlyPkgs +^^^^^^^^^^^^^^^ + +Install only packages are packages that should only ever be installed or deleted, not upgraded. + +The only packages for which this is an absolute on, are the gpg-pubkey packages. It is however 'best' practice to only ever install/delete kernel packages. The wisdom being that the package for the currently running kernel should always be installed. Doing an upgrade would delete the running kernel package. + +The RPMng driver follows the YUM practice of having a list of install only packages. A default list is hard coded in RPMng.py. This maybe over ridden in the client configuration file. + +Note that except for gpg-pubkey packages (which are always added to the list by the driver) the list in the client configuration file completely replaces the default list. An empty list means that there are no install only packages (except for gpg-pubkey), which is the behaviour of the old RPM driver. + +Example - an empty list:: + + [RPMng] + installonlypackages = + +Example - The default list:: + + [RPMng] + installonlypackages = kernel, kernel-bigmem, kernel-enterprise, kernel-smp, kernel-modules, kernel-debug, kernel-unsupported, kernel-source, kernel-devel, kernel-default, kernel-largesmp-devel, kernel-largesmp, kernel-xen, gpg-pubkey + +erase_flags +^^^^^^^^^^^ + +erase_flags are rpm options used by 'rpm -erase' in the client Remove() method. The RPMng erase is written using rpm-python and does not use the rpm command. + +The erase flags are specified in the client configuration file as a comma separated list and apply to all RPM erase operations. The default is:: + + [RPMng] + erase_flags = allmatches + +The following rpm erase options are supported, see the rpm man page for details.:: + + noscripts + notriggers + repackage + allmatches + nodeps + +.. note:: Note that specifying erase_flags in the configuration file completely replaces the default. + +pkg_checks +^^^^^^^^^^ + +The RPMng/YUMng drivers do the following three checks/status: + +# Installed +# Version +# rpm verify + +Setting pkg_checks = true (the default) in the client configuration file means that all three checks will be done for all packages. +Setting pkg_checks = false in the client configuration file means that only the Installed check will be done for all packages. + +The true/false value can be any combination of upper and lower case. + +.. note:: + #. pkg_checks must evaluate true for both the client (this option) and the package (see the Package Tag pkg_checks attribute below) for the action to take place. + #. If pkg_checks = false then the Pkgmgr entries do not need the version information. See the examples towards the bottom of the page. + +pkg_verify +^^^^^^^^^^ + +The RPMng/YUMng drivers do the following three checks/status: + +# Installed +# Version +# rpm verify + +Setting pkg_verify = true (the default) in the client configuration file means that all three checks will be done for all packages as long as pkg_checks = true. +Setting pkg_verify = false in the client configuration file means that the rpm verify wil not be done for all packages on the client. + +The true/false value can be any combination of upper and lower case. + +.. note:: + #. pkg_verify must evaluate true for both the client (this option) and the package instance (see the Instance Tag pkg_verify attribute below) for the action to take place. + +install_action +^^^^^^^^^^^^^^ + +The RPMng/YUMng drivers do the following three checks/status: + +#. Installed +#. Version +#. rpm verify + +install_action controls whether or not a package instance will be installed if the installed check fails (i.e. if the package instance isn't installed). + +If install_action = install then the package instance is installed. +If install_action = none then the package instance is not installed. + +.. note:: + #. install_action must evaluate true for both the client (this option) and the package instance (see the Instance Tag install_action attribute below) for the action to take place. + +version_fail_action +^^^^^^^^^^^^^^^^^^^ + +The RPMng/YUMng drivers do the following three checks/status: + +#. Installed +#. Version +#. rpm verify + +version_fail_action controls whether or not a package instance will be updated if the version check fails (i.e. if the installed package instance isn't the same version as specified in the configuration). + +If version_fail_action = upgrade then the package instance is upgraded (or down graded). +If version_fail_action = none then the package instance is not upgraded (or down graded). + +.. note:: + #. verion_fail_action must evaluate true for both the client (this option) and the package instance (see the Instance Tag version_fail_action attribute below) for the action to take place. + +verify_fail_action +^^^^^^^^^^^^^^^^^^ + +The RPMng/YUMng drivers do the following three checks/status: + +#. Installed +#. Version +#. rpm verify + +verify_fail_action controls whether or not a package instance will be reinstlled if the version check fails (i.e. if the installed package instance isn't the same version as specified in the configuration). + +If verify_fail_action = reinstall then the package instance is reinstalled. +If verify_fail_action = none then the package instance is not reinstalled. + +.. note:: + #. verify_fail_action must evaluate true for both the client (this option) and the package instance (see the Instance Tag verify_fail_action attribute below) for the action to take place. + #. yum cannot reinstall packages, so this option is really only relevant to RPMng. + #. RPMng will not attempt to reinstall a package instance if the only failure is an RPM configuration file. + #. RPMng will not attempt to reinstall a package instance if the only failure is an RPM dependency failure. + +Interactive Mode +---------------- + +Running the client in interactive mode (-I) prompts for the actions to be taken as before. Prompts are per package and may apply to multiple instances of that package. Each per package prompt will contain a list of actions per instance. + +Actions are encoded as + +D - Delete + +I - Install + +R - Reinstall + +U - Upgrade/Downgrade + + + +An example is below. The example is from a system that is still using the old Pkgmgr format, so the epoch and arch appear as '*'.:: + + Install/Upgrade/delete Package aaa_base instance(s) - R(*:10.2-38.*) (y/N) + Install/Upgrade/delete Package evms instance(s) - R(*:2.5.5-67.*) (y/N) + Install/Upgrade/delete Package gpg-pubkey instance(s) - D(*:9c800aca-40d8063e.*) D(*:0dfb3188-41ed929b.*) D(*:7e2e3b05-44748aba.*) D(*:a1912208-446a0899.*) D(*:9c777da4-4515b5fd.*) D(*:307e3d54-44201d5d.*) (y/N) + Install/Upgrade/delete Package module-init-tools instance(s) - R(*:3.2.2-62.*) (y/N) + Install/Upgrade/delete Package multipath-tools instance(s) - R(*:0.4.7-29.*) (y/N) + Install/Upgrade/delete Package pam instance(s) - R(*:0.99.6.3-29.1.*) (y/N) + Install/Upgrade/delete Package perl-AppConfig instance(s) - U(None:1.52-4.noarch -> *:1.63-17.*) (y/N) + Install/Upgrade/delete Package postfix instance(s) - R(*:2.3.2-28.*) (y/N) + Install/Upgrade/delete Package sysconfig instance(s) - R(*:0.60.4-3.*) (y/N) + Install/Upgrade/delete Package udev instance(s) - R(*:103-12.*) (y/N) + +GPG Keys +-------- + +GPG is used by RPM to 'sign' packages. All vendor packages are signed with the vendors GPG key. Additional signatures maybe added to the rpm file at the users discretion. + +It is normal to have multiple GPG keys installed. For example, SLES10 out of the box has six GPG keys installed. + +To the RPM database all GPG 'packages' have the name 'gpg-pubkey', which may be nothing like the name of the file specified in the rpm -import command. For example on Centos 4 the file name is RPM-GPG-KEY-centos4. For SLES10 this means that there are six packages with the name 'gpg-pubkey' installed. + +RPM does not check GPG keys at package installation, YUM does. + +RPMng uses the rpm command for installation and does not therefore check GPG signatures at package install time. RPMng uses rpm-python for verification and does by default do signature checks as part of the client Inventory process. To do the signature check the appropriate GPG keys must be installed. rpm-python is not very friendly if the required key(s) is not installed (it crashes the client). + +The RPMng driver detects, on a per package instance basis, if the appropriate key is installed. If it is not, a warning message is printed and the signature check is disabled for that package instance, for that client run only. + +GPG keys can be installed and removed by the RPMng driver. To install a GPG key configure it in Pkgmgr/Rules as a package and add gpg-pubkey to the clients abstract configuration. The gpg-pubkey package/instance is treated as an install only package. gpg-pubkey packages are installed by the RPMng driver with the rpm -import command. + +gpg-pubkey packages will be removed by bcfg2 -r packages if they are not in the clients configuration. + +.. code-block:: xml + + <PackageList uri='http://fortress/' priority='0' type='rpm'> + <Group name='Centos4.4-Standard'> + <Group name='x86_64'> + <Package name='gpg-pubkey' type='rpm'> + <Instance simplefile='mrepo/Centos44-x86_64/disc1/RPM-GPG-KEY-centos4' version='443e1821' release='421f218f'/> + <Instance simplefile='RPM-GPG-KEY-mbrady' version='9c777da4' release='4515b5fd'/> + </Package> + </Group> + </Group> + </PackageList> + +Example gpg-pubkey Pkgmgr configuration file. + +Pkgmgr Configuration +-------------------- + +Also see the general :ref:`Pkgmgr <plugins-generators-pkgmgr>` and [wiki:altsrc altsrc] pages. + +Package Tag (Old style) +^^^^^^^^^^^^^^^^^^^^^^^ + +Old style (meaning no Instance tag) Pkgmgr files have limited support. Specifically the multiarch and verify attributes are ignored. + +If multiarch type support is needed a new style format file must be used. + +If some control over the verification is needed, replace the verify attribute with the pkg_checks or verify_flags attributes. The pkg_checks and verify_flags attributes are detailed under the Instance tag heading. + +Package Tag (New Style) and Attributes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The new style package tag supports the name and pkg_checks attributes and requires the use of Instance tag entries. + +New style configuration files must be generated from the RPM headers. Either from RPM files or from the RPM DB. + +The included pkgmgr_gen.py can be used as a starting point for generating configuration files from directories of RPM package files. pkgmgr_gen.py --help for the options. + +The included pkgmgr_update.py can be used to update the package instance versions in configuration files from directories of package files. pkgmgr_update.py --help for the options. + +|| '' '''Attribute''' '' || '' '''Description''' '' || '' '''Values''' '' || +|| name || Package name. || String || +|| pkg_checks || Do the version and rpm verify checks. || true(default) or false || + +Instance Tag and Attributes +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The instance tag supports the following attributes: + +|| '' '''Attribute''' '' || '' '''Description''' '' || '' '''Values''' '' || +|| simplefile || Package file name. || String (see Notes below) || +|| epoch || Package epoch. || String (numeric only) (optional) || +|| version || Package version. || String || +|| release || Package release. || String || +|| arch || Package architecture. || Architecture String e.g. (i386|i586|i686|x86_64) || +|| verify_flags || Comma separated list of rpm --verify options. See the rpm man page for their details. || nodeps, nodigest, nofiles, noscripts, nosignature, nolinkto, nomd5, nosize, nouser, nogroup, nomtime, nomode, nordev || +|| pkg_verify || Do the rpm verify || true(default) or false|| +|| install_action || Install package instance if it is not installed. || install(default) or none || +|| version_fail_action || Upgrade package if the incorrect version is installed. || upgrade(default) or none || +|| verify_fail_action || Reinstall the package instance if the rpm verify failed. || reinstall(default) or none || + +.. note:: + The simplefile attribute doesn't need to be just the filename, meaning the basename. It is joined with the uri attribute from the PackageList Tag to form the URL that the client will use to download the package. So the uri could just be the host portion of the url and simple file could be the directory path. + + e.g. + + .. code-block:: xml + + <PackageList uri='http://fortress/' priority='0' type='rpm'> + <Group name='Centos4.4-Standard'> + <Group name='x86_64'> + <Package name='gpg-pubkey' type='rpm'> + <Instance simplefile='mrepo/Centos44-x86_64/disc1/RPM-GPG-KEY-centos4' version='443e1821' release='421f218f'/> + <Instance simplefile='RPM-GPG-KEY-mbrady' version='9c777da4' release='4515b5fd'/> + </Package> + </Group> + </Group> + </PackageList> + +The values for epoch, version, release and arch attributes must come from the RPM header, not the RPM file name. + +Epoch is a strange thing. In short:: + + epoch not set == epoch=None < epoch='0' < epoch='1' + +and it is an int, but elementtree attributes have to be str or unicode, so the driver is constantly converting. + +Ignore Tag +^^^^^^^^^^ + +The Ignore tag is used to "mask out" individual files from the RPM verification. This is done by comparing the verification failure results with the Ignore tag name. If there is a match, that entry is not used by the client to determine if a package has failed verification. + +Ignore tag entries can be specified at both the Package level, in which case they apply to all Instances, and/or at the Instance level, in which case they only apply to that instance. + +Ignore tag entries only work with the RPMng driver. They do not appear to be supported in YUMng as of 1.0pre5. + +Ignore tag entries can be specified in both old and new style Pkgmgr files. + +The Ignore Tag supports the following attributes: + +|| '' '''Attribute''' '' || '' '''Description''' '' || '' '''Values''' '' || +|| name || File name. || String || + +Example + +.. code-block:: xml + + <Package name='glibc' type='rpm'> + <Ignore name='/etc/rpc'/> + <Instance simplefile='glibc-2.3.4-2.25.x86_64.rpm' version='2.3.4' release='2.25' arch='x86_64'/> + </Package> + +Automated Generation of Pkgmgr Configuration Files +-------------------------------------------------- + +The two utilities detailed below are provided in the tools directory of the source tarball. + +Also see the general :ref:`Pkgmgr <plugins-generators-pkgmgr>` and [wiki:altsrc altsrc] pages. + +pkgmgr_gen.py +^^^^^^^^^^^^^ + +pkgmgr_gen will generate a Pkgrmgr file from a list of directories containing RPMs or from a list of YUM repositories.:: + + [root@bcfg2 Pkgmgr]# pkgmgr_gen.py --help + usage: pkgmgr_gen.py [options] + + options: + -h, --help show this help message and exit + -aARCHS, --archs=ARCHS + Comma separated list of subarchitectures to include. + The highest subarichitecture required in an + architecture group should specified. Lower + subarchitecture packages will be loaded if that + is all that is available. e.g. The higher of i386, + i486 and i586 packages will be loaded if -a i586 + is specified. (Default: all). + -dRPMDIRS, --rpmdirs=RPMDIRS + Comma separated list of directories to scan for RPMS. + Wilcards are permitted. + -eENDDATE, --enddate=ENDDATE + End date for RPM file selection. + -fFORMAT, --format=FORMAT + Format of the Output. Choices are yum or rpm. + (Default: yum) + -gGROUPS, --groups=GROUPS + List of comma separated groups to nest Package + entities in. + -iINDENT, --indent=INDENT + Number of leading spaces to indent nested entries in + the output. + (Default:4) + -oOUTFILE, --outfile=OUTFILE + Output file name. + -P, --pkgmgrhdr Include PackageList header in output. + -pPRIORITY, --priority=PRIORITY + Value to set priority attribute in the PackageList Tag. + (Default: 0) + -rRELEASE, --release=RELEASE + Which releases to include in the output. Choices are + all or latest. (Default: latest). + -sSTARTDATE, --startdate=STARTDATE + Start date for RPM file selection. + -uURI, --uri=URI URI for PackageList header required for RPM format + ouput. + -v, --verbose Enable verbose output. + -yYUMREPOS, --yumrepos=YUMREPOS + Comma separated list of YUM repository URLs to load. + NOTE: Each URL must end in a '/' character. + +.. note:: The startdate and enddate options are not yet implemented. + +pkgmgr_update.py +---------------- + +pkgmgr_update will update the release (meaning the epoch, version and release) information in an existing Pkgrmgr file from a list of directories containing RPMs or from a list of YUM repositories. All Tags and other attributes in the existing file will remain unchanged.:: + + [root@bcfg2 Pkgmgr]# pkgmgr_update.py --help + usage: pkgmgr_update.py [options] + + options: + -h, --help show this help message and exit + -cCONFIGFILE, --configfile=CONFIGFILE + Existing Pkgmgr configuration file name. + -dRPMDIRS, --rpmdirs=RPMDIRS + Comma separated list of directories to scan for RPMS. + Wilcards are permitted. + -oOUTFILE, --outfile=OUTFILE + Output file name or new Pkgrmgr file. + -v, --verbose Enable verbose output. + -yYUMREPOS, --yumrepos=YUMREPOS + Comma separated list of YUM repository URLs to load. + NOTE: Each URL must end in a '/' character. + +Pkgmgr Configuration Examples +----------------------------- + +verify_flags +^^^^^^^^^^^^ + +This entry was used for the Centos test client used during RPMng development. + +.. code-block:: xml + + <Package name='bcfg2' type='rpm'> + <Instance simplefile='bcfg2-0.9.3-0.0pre5.noarch.rpm' version='0.9.3' release='0.0pre5' arch='noarch' verify_flags='nomd5,nosize,nomtime'/> + </Package> + +Multiple Instances +^^^^^^^^^^^^^^^^^^ + +.. code-block:: xml + + <Package name='beecrypt' type='rpm'> + <Instance simplefile='beecrypt-3.1.0-6.x86_64.rpm' version='3.1.0' release='6' arch='x86_64'/> + <Instance simplefile='beecrypt-3.1.0-6.i386.rpm' version='3.1.0' release='6' arch='i386'/> + </Package> + +Kernel +^^^^^^ + +.. note:: Multiple instances with the same architecture must be in the installOnlyPkgs list. + +.. code-block:: xml + + <Package name='kernel' type='rpm'> + <Instance simplefile='kernel-2.6.9-42.0.8.EL.x86_64.rpm' version='2.6.9' release='42.0.8.EL' arch='x86_64'/> + <Instance simplefile='kernel-2.6.9-42.0.10.EL.x86_64.rpm' version='2.6.9' release='42.0.10.EL' arch='x86_64'/> + </Package> + +Per Instance Ignore +^^^^^^^^^^^^^^^^^^^ + +.. note:: In this case a per instance ignore is actually a bad idea as the verify failure is because of multiarch issues where the last package installed wins. So this would be better as a Package level ignore. + +Ignore tag entries only work with the RPMng driver. They do not appear to be supported in YUMng as of 1.0pre5. + +.. code-block:: xml + + <Package name='glibc' type='rpm'> + <Instance simplefile='glibc-2.3.4-2.25.x86_64.rpm' version='2.3.4' release='2.25' arch='x86_64'> + <Ignore name='/etc/rpc'/> + </Instance> + <Instance simplefile='glibc-2.3.4-2.25.i686.rpm' version='2.3.4' release='2.25' arch='i686'/> + </Package> + +pkg_checks +^^^^^^^^^^ + +If pkg_checks = false the version information is not required. If pkg_checks = true the full information is needed as normal. + +For YUMng a minimal entry is + +.. code-block:: xml + + <Package name="bcfg2" type="yum" pkg_checks="False"/> + +Infact for YUMng, with pkg_checks = false, any combination of the nevra attributes that will build a valid yum package name (see the Misc heading on the yum man page) is valid. + +.. code-block:: xml + + <Package name="bcfg2" type="yum" pkg_checks="False" arch="x86_64"/> + +For RPMng a minimal entry is + +.. code-block:: xml + + <Package name="bcfg2" type="rpm" pkg_checks="False" simplefile="bcfg2-0.9.4-0.0pre1.noarch.rpm"/> + +verify_fail_action +^^^^^^^^^^^^^^^^^^ + +The way I have bcfg2 configured for my development systems. This way it reports bad, but doesn't do anything about it. + +.. code-block:: xml + + <Package name='bcfg2' type='rpm'> + <Instance simplefile='bcfg2-0.9.3-0.0pre5.noarch.rpm' version='0.9.3' release='0.0pre5' arch='noarch' verify_fail_action='none'/> + </Package> diff --git a/doc/conf.py b/doc/conf.py index 52148bc16..aea2099d8 100644 --- a/doc/conf.py +++ b/doc/conf.py @@ -35,7 +35,7 @@ source_suffix = '.txt' #source_encoding = 'utf-8' # The master toctree document. -master_doc = 'index' +master_doc = 'contents' # General information about the project. project = u'Bcfg2' @@ -125,7 +125,7 @@ html_static_path = ['_static'] # If not '', a 'Last updated on:' timestamp is inserted at every page bottom, # using the given strftime format. -#html_last_updated_fmt = '%b %d, %Y' +html_last_updated_fmt = '%b %d, %Y' # If true, SmartyPants will be used to convert quotes and dashes to # typographically correct entities. diff --git a/doc/contents.txt b/doc/contents.txt new file mode 100644 index 000000000..953898066 --- /dev/null +++ b/doc/contents.txt @@ -0,0 +1,46 @@ +.. _contents: + +================================= +Welcome to Bcfg2's documentation! +================================= + +.. toctree:: + :maxdepth: 2 + + quickstart/index + faq/index + authentication + getting_started/index + plugins/index + client/index + testimonials + sites + + unsorted/index + + glossary + +Indices, glossary and tables +============================ + +* :ref:`genindex` +* :ref:`modindex` +* :ref:`glossary` +* :ref:`search` + +Deprecated/obsolete documentation +================================= + +The following documentation covers features that have been deprecated or that +have been replaced in newer versions of Django. + +.. toctree:: + :maxdepth: 2 + + obsolete/index + + +.. toctree:: + :hidden: + + index diff --git a/doc/faq/general.txt b/doc/faq/general.txt new file mode 100644 index 000000000..b846e58eb --- /dev/null +++ b/doc/faq/general.txt @@ -0,0 +1,18 @@ +.. _faq-general: + +FAQ: General +============ + +What does Bcfg2 stand for? +-------------------------- + +Initially, Bcfg stood for the bundle configuration system. Bcfg2 is the second major revision. At this point, the acronym is meaningless, but the name has stuck. Luckily, Bcfg2 googles better than Bcfg does. No, seriously. Try it. All I know is that I have no interest in a billion cubic feet of gas. + +What architectures does Bcfg2 support? +-------------------------------------- + +Bcfg2 should run on any POSIX compatible operating system, however direct support for an operating system's package and service formats are limited by the currently available :ref:`client-tools-index` (although new client tools are pretty easy to add). The following is an incomplete but more exact list of platforms on which Bcfg2 works. + +* GNU/Linux deb based distros +* GNU/Linux rpm based distros +* Solaris pkg based diff --git a/doc/faq/index.txt b/doc/faq/index.txt new file mode 100644 index 000000000..f24afc0a1 --- /dev/null +++ b/doc/faq/index.txt @@ -0,0 +1,10 @@ +.. _faq-index: + +========= +Bcfg2 FAQ +========= + +.. toctree:: + :maxdepth: 2 + + general diff --git a/doc/glossary.txt b/doc/glossary.txt index bbed9ebaf..ec13364bf 100644 --- a/doc/glossary.txt +++ b/doc/glossary.txt @@ -1,4 +1,4 @@ -.. -*- mode: rst -*- +.. _glossary: ======== Glossary diff --git a/doc/index.txt b/doc/index.txt index 05baefd22..ca96bfe1f 100644 --- a/doc/index.txt +++ b/doc/index.txt @@ -1,27 +1,94 @@ -.. -*- mode: rst -*- +.. _index: -Welcome to Bcfg2's documentation! -================================= +===================== +Bcfg2's documentation +===================== -.. toctree:: - :maxdepth: 2 +Getting help +============ - intro - quickstart/index - authentication - getting_started/index - plugins/index - testimonials - sites +Having trouble? We'd like to help! - unsorted/index +* Try the :ref:`FAQ <faq-index>` -- it's got answers to many common questions. - glossary +* Looking for specific information? Try the :ref:`genindex`, :ref:`modindex` or the :ref:`detailed table of contents <contents>`. -Indices and tables -================== +* Search for information in the `Bcfg2 mailing list archives`_. -* :ref:`genindex` -* :ref:`modindex` -* :ref:`search` +* Ask a question in the `#bcfg2 IRC channel`_, or search the `IRC logs`_ to see if its been asked before. +* Report bugs with Bcfg2 in our `ticket tracker`_. + +.. _Bcfg2 mailing list archives: http://trac.mcs.anl.gov/projects/bcfg2/wiki/MailingList +.. _#bcfg2 IRC channel: irc://irc.freenode.net/bcfg2 +.. _IRC logs: http://colabti.org/irclogger/irclogger_logs/bcfg2 +.. _ticket tracker: http://trac.mcs.anl.gov/projects/bcfg2/wiki + +Introduction +============ + +Bcfg2 helps system administrators produce a consistent, reproducible, +and verifiable description of their environment, and offers +visualization and reporting tools to aid in day-to-day administrative +tasks. It is the fifth generation of configuration management tools +developed in the `Mathematics and Computer Science Division`_ of +`Argonne National Laboratory`_. + +.. _Mathematics and Computer Science Division: http://www.mcs.anl.gov/ +.. _Argonne National Laboratory: http://www.anl.gov/ + +It is based on an operational model in which the specification can be +used to validate and optionally change the state of clients, but in a +feature unique to bcfg2 the client's response to the specification can +also be used to assess the completeness of the specification. Using +this feature, bcfg2 provides an objective measure of how good a job an +administrator has done in specifying the configuration of client +systems. Bcfg2 is therefore built to help administrators construct an +accurate, comprehensive specification. + +Bcfg2 has been designed from the ground up to support gentle +reconciliation between the specification and current client states. It +is designed to gracefully cope with manual system modifications. + +Finally, due to the rapid pace of updates on modern networks, client +systems are constantly changing; if required in your environment, +Bcfg2 can enable the construction of complex change management and +deployment strategies. + +Bcfg2 is fairly portable. It has been successfully run on: + +* `AIX`_, `FreeBSD`_, `OpenBSD`_, `Mac OS X`_, `OpenSolaris`_, + `Solaris`_. + +.. _AIX: http://www.ibm.com/aix +.. _FreeBSD: http://www.freebsd.org/ +.. _OpenBSD: http://www.openbsd.org/ +.. _Mac OS X: http://www.apple.com/macosx/ +.. _OpenSolaris: http://opensolaris.org/ +.. _Solaris: http://www.sun.com/software/solaris/ + +* Many `GNU/Linux`_ distributions, including `Blag`_, `CentOS`_, + `Debian`_, `Fedora`_, `Gentoo`_, `gNewSense`_, `Mandriva`_, + `OpenSUSE`_, `Redhat/RHEL`_, `SuSE/SLES`_, `Trisquel`_ and + `Ubuntu`_. + +.. _GNU/Linux: http://www.gnu.org/gnu/Linux-and-gnu.html +.. _Blag: http://www.blagblagblag.org/ +.. _CentOS: http://www.centos.org/ +.. _Debian: http://www.debian.org/ +.. _Fedora: http://www.fedoraproject.org/ +.. _Gentoo: http://www.gentoo.org/ +.. _gNewSense: http://www.gnewsense.org/ +.. _Mandriva: http://www.mandriva.com/ +.. _OpenSUSE: http://opensuse.org/ +.. _Redhat/RHEL: http://www.redhat.com/rhel/ +.. _SuSE/SLES: http://www.novell.com/linux/ +.. _Trisquel: http://trisquel.info/ +.. _Ubuntu: http://www.ubuntu.com/ + +Bcfg2 should run on any POSIX compatible operating system, however +direct support for an operating system's package and service formats +are limited by the currently available :ref:`client-tools-index` +(new client tools are pretty easy to add). Check the :ref:`FAQ +<faq-general>` for a more exact list of platforms on which Bcfg2 +works`. diff --git a/doc/intro.txt b/doc/intro.txt deleted file mode 100644 index c00108996..000000000 --- a/doc/intro.txt +++ /dev/null @@ -1,71 +0,0 @@ -.. -*- mode: rst -*- - -============ -Introduction -============ - -Bcfg2 helps system administrators produce a consistent, reproducible, -and verifiable description of their environment, and offers -visualization and reporting tools to aid in day-to-day administrative -tasks. It is the fifth generation of configuration management tools -developed in the `Mathematics and Computer Science Division`_ of -`Argonne National Laboratory`_. - -.. _Mathematics and Computer Science Division: http://www.mcs.anl.gov/ -.. _Argonne National Laboratory: http://www.anl.gov/ - -It is based on an operational model in which the specification can be -used to validate and optionally change the state of clients, but in a -feature unique to bcfg2 the client's response to the specification can -also be used to assess the completeness of the specification. Using -this feature, bcfg2 provides an objective measure of how good a job an -administrator has done in specifying the configuration of client -systems. Bcfg2 is therefore built to help administrators construct an -accurate, comprehensive specification. - -Bcfg2 has been designed from the ground up to support gentle -reconciliation between the specification and current client states. It -is designed to gracefully cope with manual system modifications. - -Finally, due to the rapid pace of updates on modern networks, client -systems are constantly changing; if required in your environment, -Bcfg2 can enable the construction of complex change management and -deployment strategies. - -Bcfg2 is fairly portable. It has been successfully run on: - -* `AIX`_, `FreeBSD`_, `OpenBSD`_, `Mac OS X`_, `OpenSolaris`_, - `Solaris`_. - -.. _AIX: http://www.ibm.com/aix -.. _FreeBSD: http://www.freebsd.org/ -.. _OpenBSD: http://www.openbsd.org/ -.. _Mac OS X: http://www.apple.com/macosx/ -.. _OpenSolaris: http://opensolaris.org/ -.. _Solaris: http://www.sun.com/software/solaris/ - -* Many `GNU/Linux`_ distributions, including `Blag`_, `CentOS`_, - `Debian`_, `Fedora`_, `Gentoo`_, `gNewSense`_, `Mandriva`_, - `OpenSUSE`_, `Redhat/RHEL`_, `SuSE/SLES`_, `Trisquel`_ and - `Ubuntu`_. - -.. _GNU/Linux: http://www.gnu.org/gnu/Linux-and-gnu.html -.. _Blag: http://www.blagblagblag.org/ -.. _CentOS: http://www.centos.org/ -.. _Debian: http://www.debian.org/ -.. _Fedora: http://www.fedoraproject.org/ -.. _Gentoo: http://www.gentoo.org/ -.. _gNewSense: http://www.gnewsense.org/ -.. _Mandriva: http://www.mandriva.com/ -.. _OpenSUSE: http://opensuse.org/ -.. _Redhat/RHEL: http://www.redhat.com/rhel/ -.. _SuSE/SLES: http://www.novell.com/linux/ -.. _Trisquel: http://trisquel.info/ -.. _Ubuntu: http://www.ubuntu.com/ - -Bcfg2 should run on any POSIX compatible operating system, however -direct support for an operating system's package and service formats -are limited by the currently available :ref:`client tools` -(new client tools are pretty easy to add). There is also an -:ref:`incomplete but more exact list of platforms on -which Bcfg2 works`. diff --git a/doc/obsolete/index.txt b/doc/obsolete/index.txt new file mode 100644 index 000000000..28fcf2b0c --- /dev/null +++ b/doc/obsolete/index.txt @@ -0,0 +1,11 @@ +.. -*- mode: rst -*- + +.. _obsolete-index: + +Deprecated/obsolete documentation +================================= + +These documents cover features that have been deprecated or that have been replaced in newer versions of Bcfg2. They're preserved here for folks using old versions of Bcfg2. + +.. toctree:: + :maxdepth: 1 diff --git a/doc/plugins/generators/account.txt b/doc/plugins/generators/account.txt index e07cef8b6..9a2718ce5 100644 --- a/doc/plugins/generators/account.txt +++ b/doc/plugins/generators/account.txt @@ -18,7 +18,7 @@ User access data is stored in three files in the Account directory: * rootlist (a list of user:host pairs for scoped root privs) * useraccess (a list of user:host pairs for login access) -SSH keys are stored in files named $username.key; these are installed into root's authorized keys for users in the superusers list as well as for the pertitent users in the rootlike file (for the current system). +SSH keys are stored in files named $username.key; these are installed into root's authorized keys for users in the superusers list as well as for the pertitent users in the rootlike file (for the current system). Authentication data is read in from (static|dyn).(passwd|group) The static ones are for system local ones, while the dyn. versions are for external synchronization (from ldap/nis/etc) There is also a static.limits.conf that provides the limits.conf header and any static entries. diff --git a/doc/plugins/generators/cfg.txt b/doc/plugins/generators/cfg.txt index 8ef9b17dc..e4e342842 100644 --- a/doc/plugins/generators/cfg.txt +++ b/doc/plugins/generators/cfg.txt @@ -89,7 +89,7 @@ info.xml files This feature is included in version 0.9.5pre3 and newer of the bcfg2 server. -info.xml files add the ability to specify different sets of file metadata on a group by group basis. These files are XML, and work similarly to those used by [wiki:Plugins/Rules Rules] or [wiki:Plugins/Pkgmgr Pkgmgr]. +info.xml files add the ability to specify different sets of file metadata on a group by group basis. These files are XML, and work similarly to those used by [wiki:Plugins/Rules Rules] or [wiki:Plugins/Pkgmgr Pkgmgr]. The following specifies a different global set of permissions (root/sys/0651) than on clients in group webserver (root/root/0652) diff --git a/doc/plugins/generators/decisions.txt b/doc/plugins/generators/decisions.txt index 17bc5c66c..079e748f9 100644 --- a/doc/plugins/generators/decisions.txt +++ b/doc/plugins/generators/decisions.txt @@ -4,9 +4,9 @@ Decisions ========= -This page describes the Decisions plugin. The client has support for a centralized set of per-entry installation decisions. This approach is needed when particular changes are deemed "high risk"; this gives the ability to centrally specify these changes, but only install them on clients when administrator supervision is available. Because collaborative configuration is one of the remaining hard issues in configuration management, these issues typically crop up in environments with several administrators and much configuration variety. +This page describes the Decisions plugin. The client has support for a centralized set of per-entry installation decisions. This approach is needed when particular changes are deemed "high risk"; this gives the ability to centrally specify these changes, but only install them on clients when administrator supervision is available. Because collaborative configuration is one of the remaining hard issues in configuration management, these issues typically crop up in environments with several administrators and much configuration variety. -In these cases, the client can be configured to run in either a whitelist or blacklist mode, wherein a list of entries is downloaded from the server. The client uses this list to determine which incorrect entries should be corrected during the current run of the installation tool. The Decision plugin is the only stock plugin that generates entries for client's whitelists or blacklists. +In these cases, the client can be configured to run in either a whitelist or blacklist mode, wherein a list of entries is downloaded from the server. The client uses this list to determine which incorrect entries should be corrected during the current run of the installation tool. The Decision plugin is the only stock plugin that generates entries for client's whitelists or blacklists. The Decision plugin uses a directory in the bcfg2 repository called Decisions. Files in the Decisions subdirectory are named similarly to files managed by Cfg, probes, TCheetah, and TGenshi. File basenames are either whitelist or blacklist. These files have a simple format; the following is an example. @@ -24,6 +24,6 @@ The Decision plugin uses a directory in the bcfg2 repository called Decisions. F vim: ft=xml --> -This example, included as a whitelist due to its name, enables all services, and the path entry named /etc/apt/apt.conf to be installed on systems running in whitelist mode; all other entry installation will be surpressed. +This example, included as a whitelist due to its name, enables all services, and the path entry named /etc/apt/apt.conf to be installed on systems running in whitelist mode; all other entry installation will be surpressed. When a client askes for its whitelist or blacklist, all of the files pertaining to that client of the correct type are aggregated into a single list. This list is sent to the client. Note that this list is only generated when a client is run with the appropriate option (-l (whitelist|blacklist)); client behavior is not controlled unless this option is used. diff --git a/doc/plugins/generators/hostbase.txt b/doc/plugins/generators/hostbase.txt index 4b85fecd0..a03dd2f82 100644 --- a/doc/plugins/generators/hostbase.txt +++ b/doc/plugins/generators/hostbase.txt @@ -34,9 +34,9 @@ Create the hostbase database and a user. For MySQL users:: mysql> CREATE DATABASE hostbase mysql> quit - + systemprompt#: mysql -u root hostbase - mysql> GRANT ALL PRIVILEGES ON *.* TO hostbaseuser@mycomputer.private.net IDENTIFIED + mysql> GRANT ALL PRIVILEGES ON *.* TO hostbaseuser@mycomputer.private.net IDENTIFIED BY 'password' WITH GRANT OPTION; mysql> quit @@ -164,7 +164,7 @@ Authentication Edit Django settings -------------------- -Django allows for custom authentication backends to its login procedure. Hostbase has an NIS authentication backend that verifies a user to be in the unix group allowed to modify Hostbase. +Django allows for custom authentication backends to its login procedure. Hostbase has an NIS authentication backend that verifies a user to be in the unix group allowed to modify Hostbase. To enable this feature: * first edit your {{{Hostbase/settings.py}}} file and uncomment the line {{{'Hostbase.backends.NISBackend',}}} in the list of {{{AUTHENTICATION_BACKENDS}}} diff --git a/doc/plugins/generators/nagiosgen.txt b/doc/plugins/generators/nagiosgen.txt index 55b6063a5..fd33fe374 100644 --- a/doc/plugins/generators/nagiosgen.txt +++ b/doc/plugins/generators/nagiosgen.txt @@ -4,7 +4,7 @@ NagiosGen ========= -This page describes the installation and use of the [http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/bcfg2/src/lib/Server/Plugins/NagiosGen.py NagiosGen] plugin. +This page describes the installation and use of the [http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/bcfg2/src/lib/Server/Plugins/NagiosGen.py NagiosGen] plugin. Update /etc/bcfg2.conf, adding NagiosGen to plugins:: @@ -55,7 +55,7 @@ Create default host, and group specs in: retain_status_information 1 retain_nonstatus_information 1 is_volatile 0 - + check_period 24x7 max_check_attempts 4 check_interval 5 diff --git a/doc/plugins/generators/packages.txt b/doc/plugins/generators/packages.txt index 837a6b14a..c7ac2deea 100644 --- a/doc/plugins/generators/packages.txt +++ b/doc/plugins/generators/packages.txt @@ -1,4 +1,4 @@ -.. -*- mode: rst -*- +.. _plugins-generators-packages: ======== Packages diff --git a/doc/plugins/generators/pkgmgr.txt b/doc/plugins/generators/pkgmgr.txt index b6940f9b1..fc15fad79 100644 --- a/doc/plugins/generators/pkgmgr.txt +++ b/doc/plugins/generators/pkgmgr.txt @@ -1,4 +1,4 @@ -.. -*- mode: rst -*- +.. _plugins-generators-pkgmgr: ====== Pkgmgr diff --git a/doc/plugins/generators/sshbase.txt b/doc/plugins/generators/sshbase.txt index 65fe1cca7..4741fc8eb 100644 --- a/doc/plugins/generators/sshbase.txt +++ b/doc/plugins/generators/sshbase.txt @@ -21,13 +21,13 @@ Interacting with SSHbase Aliases ======= -As of 1.0pre4, SSHbase has support for Aliases listed in clients.xml. The address for the entries are specified either through DNS (e.g. a CNAME), or via the address attribute to the Alias. +SSHbase has support for Aliases listed in clients.xml. The address for the entries are specified either through DNS (e.g. a CNAME), or via the address attribute to the Alias. Getting started =============== #. Add SSHbase to the generators line (plugins line in 1.0 or greater) in /etc/bcfg2.conf and restart the server -- This enables the SSHbase plugin in the bcfg2 server. -#. Add ConfigFile entries for /etc/ssh/ssh_known_hosts, and /etc/ssh/ssh_host_dsa_key, etc to a bundle or base. +#. Add Path entries for /etc/ssh/ssh_known_hosts, and /etc/ssh/ssh_host_dsa_key, etc to a bundle or base. #. Enjoy. At this point, SSHbase will generate new keys for any client without a recorded key in the repository, and will generate an ssh_known_hosts file appropriately. @@ -35,4 +35,4 @@ At this point, SSHbase will generate new keys for any client without a recorded Blog post ========= -[http://www.ducea.com/2008/08/24/using-the-bcfg2-sshbase-plugin/] +http://www.ducea.com/2008/08/24/using-the-bcfg2-sshbase-plugin/ diff --git a/doc/plugins/grouping/metadata.txt b/doc/plugins/grouping/metadata.txt index 2c169318f..f9ad44954 100644 --- a/doc/plugins/grouping/metadata.txt +++ b/doc/plugins/grouping/metadata.txt @@ -3,3 +3,145 @@ ======== Metadata ======== + +The metadata mechanism has two types of information, client metadata and group metadata. The client metadata describes which top level group a client is associated with.The group metadata describes groups in terms of what bundles and other groups they include. Each aspect grouping and clients' memberships are reflected in the Metadata/groups.xml and Metadata/clients.xml files, respectively. + +Usage of Groups in Metadata +=========================== + +Clients are assigned membership of groups in the Metadata descriptions. Clients can be directly assigned to 'profile' or 'public' groups. Client membership of all other groups is by those groups being associated with the profile or public groups. This file can be indirectly modified from clients through use of the -p flag to bcfg2. + +Clients are associated with profile groups in Metadata/clients.xml as shown below. + +Metadata/clients.xml +==================== + +The Metadata/clients.xml file contains the mappings of Profile Groups to clients. The +file is just a series of <Client /> tags, each of which describe one host. A sample +file is below: + +.. code-block:: xml + + <Clients version="3.0"> + <Client profile="backup-server" pingable="Y" pingtime="0" name="backup.example.com"/> + <Client profile="console-server" pingable="Y" pingtime="0" name="con.example.com"/> + <Client profile="kerberos-master" pingable="Y" pingtime="0" name="kdc.example.com"/> + <Client profile="mail-server" pingable="Y" pingtime="0" name="mail.example.com"/> + <Client name='foo' address='10.0.0.1' pingable='N' pingtime='-1'> + <Alias name='foo-mgmt' address='10.1.0.1'/> + </Client> + </Clients> + +Clients Tag +----------- + +The Clients tag has the following possible attributes: + +|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' || +|| version || Client schema version || String || + +Client Tag +---------- + +Each entry in clients.xml '''must''' have the following properties: +|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' || +|| name || Host name of client. This needs do be the name (possibly a FQDN) returned by a reverse lookup on the connecting IP address. || String || +|| profile || Profile group name to associate this client with || String || + +Additionally, the following properties can be specified: +|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' || +|| Alias || Alternative name and address for the client || XML Element || +|| address || Establishes an extra ip address that resolves to this client || ip address || +|| location || Requires requests to come from an IP address that matches the client record || fixed|floating || +|| password || Establishes a per-node password that can be used instead of the global password || String || +|| pingable || If the client is pingable (deprecated; for old reporting system) || (Y|N) || +|| pingtime || Last time the client was pingable (deprecated; for old reporting system) || String || +|| secure || Requires the use of the per-client password for this client || true|false || +|| uuid || Establishes a per-node name that can be used to bypass dns-based client resolution || String || + + +For detailed information on client authentication see [wiki:Authentication] + +Metadata/groups.xml +------------------- + +The Metadata/groups.xml file contains Group and Profile definitions. Here's a simple +Metadata/groups.xml file: + +.. code-block:: xml + + <Groups version='3.0'> + <Group name='mail-server' profile='true' + public='false' + comment='Top level mail server group' > + <Bundle name='mail-server'/> + <Bundle name='mailman-server'/> + <Group name='apache-server'/> + <Group name='rhel-as-4-x86'/> + <Group name='nfs-client'/> + <Group name='server'/> + </Group> + <Group name='rhel-as-4-x86' toolset='rh'> + <Group name='rhel'/> + </Group> + <Group name='apache-server'/> + <Group name='nfs-client'/> + <Group name='server'/> + <Group name='rhel'/> + </Groups> + + +Nested/chained groups definitions are conjunctive (logical and). For instance, in +the above example, a client associated with the Profile Group 'mail-server' is +also a member of the apache-server, rhel-as-4-x86, nfs-client, server and rhel +groups. + +Groups describe clients in terms for abstract, disjoint aspects. Groups can be +combined to form complex descriptions of clients that use configuration commonality +and inheritance. Groups have several attributes, described below: + + +Metadata Groups Tag +------------------- + +The Groups tag has the following possible attributes: + +|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' || +|| version || Group schema version || String || +|| origin || URL of master version (for common repo) || String || +|| revision || Master version control revision || String || + +Metadata Group Tag +------------------ + +The Group Tag has the following possible attributes: + +|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' || +|| name || Name of the group || String || +|| profile || If a client can be directly associated with this group || (True|False*) || +|| public || If a client can freely associate itself with this group. For use with bcfg2 -p option on the client. || (True|False*) || +|| toolset || Describes which client-side logic should be used to make configuration changes || (rh|debian|solaris|aix|auto|gentoo) || +|| category || A group can only contain one instance of a group in any category. This provides the basis for representing groups which are conjugates of one another in a rigorous way. It also provides the basis for negation. || String || +|| default || Set as the profile to use for clients that are not associated with a profile in clients.xml. || (True|False*) || +|| comment || English text description of group || String || + +Groups can also contain other groups and bundles. + +Use of XInclude +=============== + +[http://www.w3.org/TR/xinclude/ XInclude] is a W3C specification for the inclusion of external XML documents into XML source files. Much like the use of #include in C, this allows complex definitions to be split into smaller, more manageable pieces. As of bcfg2-0.9.0pre1, the Metadata plugin supports the use of XInclude specifications to split the clients.xml and groups.xml files. This mechanism allows the following specification to produce useful results: + +.. code-block:: xml + + <Groups version='3.0' xmlns:xi="http://www.w3.org/2001/XInclude"> + <xi:include href="my-groups.xml" /> + <xi:include href="their-groups.xml" /> + </Groups> + +Each of the included groups files has the same format. These files are properly validated by bcfg2-repo-validate. This mechanism is useful for composing group definitions from multiple sources, or setting different permissions in an svn repository. + +Probes +====== + +The metadata plugin includes client-side probing functionality. This is fully documented [wiki:Probes here]. diff --git a/doc/plugins/probes.txt b/doc/plugins/probes.txt index b6b69d754..a888b776d 100644 --- a/doc/plugins/probes.txt +++ b/doc/plugins/probes.txt @@ -6,7 +6,7 @@ Probes At times you need to gather information from a client machine before you can generate its configuration. For example, if some of your machines have both a local scratch disk and a system disk while others only have the system disk, you would want to know this information to correctly generate an `/etc/auto.master` autofs config file for each type. Here we will look at how to do this. -First you will need to set up the TCheetah plugin, as described on the [wiki:Plugins/TCheetah TCheetah Plugin] page. +First you will need to set up the TCheetah plugin, as described on the :doc:`generators/tcheetah` page. Next, we need to create a `Probes` directory in our toplevel repository location:: @@ -60,14 +60,18 @@ With all of these pieces in place, the following series of events will happen wh #. Server hands `/etc/auto.master` down to the client #. Client puts file contents in place. -Now we have a nicely dynamic `/etc/auto.master` that can gracefully handle machines with different numbers of disks. All that's left to do is to add the `/etc/auto.master` to a Bundle:: +Now we have a nicely dynamic `/etc/auto.master` that can gracefully handle machines with different numbers of disks. All that's left to do is to add the `/etc/auto.master` to a Bundle: + +.. code-block:: xml <ConfigFile name='/etc/auto.master'/> Other examples ============== -Dynamically assign a group based on the Ubuntu version:: +Dynamically assign a group based on the Ubuntu version: + +.. code-block:: sh #!/bin/sh @@ -75,7 +79,9 @@ Dynamically assign a group based on the Ubuntu version:: . /etc/lsb-release echo group:$DISTRIB_CODENAME -Detect if the server is a Linux-VServer host:: +Detect if the server is a Linux-VServer host: + +.. code-block:: sh #!/bin/sh diff --git a/doc/plugins/statistics/dbstats.txt b/doc/plugins/statistics/dbstats.txt index 4afca4afe..001067974 100644 --- a/doc/plugins/statistics/dbstats.txt +++ b/doc/plugins/statistics/dbstats.txt @@ -3,3 +3,5 @@ ======= DBStats ======= + + diff --git a/doc/plugins/structures/base.txt b/doc/plugins/structures/base.txt index ead775c10..b63ee5cc9 100644 --- a/doc/plugins/structures/base.txt +++ b/doc/plugins/structures/base.txt @@ -3,3 +3,5 @@ ==== Base ==== + +The Base plugin is a structure plugin that provides the ability to add lists of unrelated entries into client configuration entry inventories. Base works much like Bundler in its file format. The main difference between Base and Bundler is that Base files are included in all clients' configuration whereas bundles must be included explicitly in your Metadata. See the :doc:`bundler` page for details. diff --git a/doc/plugins/structures/bundler.txt b/doc/plugins/structures/bundler.txt index 1efbca878..9d663e90c 100644 --- a/doc/plugins/structures/bundler.txt +++ b/doc/plugins/structures/bundler.txt @@ -1,5 +1,139 @@ -.. -*- mode: rst -*- +.. _plugins-structures-bundler: ======= Bundler ======= + +Bundler is used to describe groups of inter-dependent configuration entries, such as the combination of packages, configuration files, and service activations that comprise typical Unix daemons. Bundles are used to add groups of configuration entries to the inventory of client configurations, as opposed to describing particular versions of those entries. For example, a bundle could say that the configuration file "/etc/passwd" should be included in a configuration, but will not describe the particular version of "/etc/passwd" that a given client will receive. + +Groups can be used inside of bundles to differentiate which entries particular clients will recieve; this is useful for the case where entries are named differently across systems; for example, one linux distro may have a package called openssh while another uses the name ssh. Configuration entries nested inside of Group elements only apply to clients who are a member of those groups; multiply nested groups must all apply. Also, groups may be negated; entries included in such groups will only apply to clients who are not a member of said group. + +The following is an annotated copy of a bundle: + +.. code-block:: xml + + <Bundle revision='$Revision: 2668 $' name='ssh' version='2.0' + origin='https://svn.mcs.anl.gov/repos/bcfg/trunk/repository/Bundler/ssh.xml'> + <ConfigFile name='/etc/ssh/ssh_host_dsa_key'/> + <ConfigFile name='/etc/ssh/ssh_host_rsa_key'/> + <ConfigFile name='/etc/ssh/ssh_host_dsa_key.pub'/> + <ConfigFile name='/etc/ssh/ssh_host_rsa_key.pub'/> + <ConfigFile name='/etc/ssh/ssh_host_key'/> + <ConfigFile name='/etc/ssh/ssh_host_key.pub'/> + <ConfigFile name='/etc/ssh/sshd_config'/> + <ConfigFile name='/etc/ssh/ssh_config'/> + <ConfigFile name='/etc/ssh/ssh_known_hosts'/> + <Group name='rpm'> + <Package name='openssh'/> + <Package name='openssh-askpass'/> + <Service name='sshd'/> + <Group name='fedora' > + <Group name='fc4' negate='true'> + <Package name='openssh-clients'/> + </Group> + <Package name='openssh-server'/> + </Group> + </Group> + <Group name='deb'> + <Package name='ssh'/> + <Service name='ssh'/> + </Group> + </Bundle> + +In this bundle, most of the entries are common to all systems. Clients in group "deb" get one extra package and service, while clients in group "rpm" get two extra packages and an extra service. In addition, clients in group "fedora" and group "rpm" get one extra package entries, unless they are not in the fc4 group, in which case, they get an extra package. Notice that this file doesn't describe which versions of these entries that clients should get, only that they should get them. (Admittedly, this example is slightly contrived, but demonstrates how group entries can be used in bundles) + +|| '' '''Group''' '' || '' '''Entry''' '' || +|| all || /etc/ssh/ssh_host_dsa_key || +|| all || /etc/ssh/ssh_host_rsa_key || +|| all || /etc/ssh/ssh_host_dsa_key.pub || +|| all || /etc/ssh/ssh_host_rsa_key.pub || +|| all || /etc/ssh/ssh_host_key || +|| all || /etc/ssh/ssh_host_key.pub || +|| all || /etc/ssh/sshd_config || +|| all || /etc/ssh/ssh_config || +|| all || /etc/ssh/ssh_known_hosts || +|| rpm || Package openssh || +|| rpm || Package openssh-askpass || +|| rpm || Service sshd || +|| rpm and fedora || Package openssh-server || +|| rpm and fedora and not fc4 || Package openssh-clients || +|| deb || Package ssh || +|| deb || Service ssh || + +Genshi templates +================ + +Genshi templates are used by adding a Genshi xml-style template to the Bundler directory with a `.genshi` file extension. Version 0.4 or newer of genshi is required. + +Motivation +---------- + +Static Bundles have served us relatively well, but have a relatively weak set of interal per-client differentiation mechanisms. In static Bundles, the group hierarchy (from the perspective of the current client) is available for use via boolean constraints with negation. This notion does not mesh well with the use of Probes, which can result in freeform data. In the presence of probe results, clients can have a wide array of data, and rendering down to a boolean logic may not always be desirable. Moreover, while static Bundles allow entry inclusion or exclusion based on group memberships, they do not allow programatic entry rendering. Hence, Genshi templates not only provide more control options, but it also provide the ability to perform new entry rendering operations. + +The [http://genshi.edgewall.org/ Genshi templating system] is used internally. + +Use +--- + +Bcfg uses the Genshi API for templates, and performs a XML format stream rendering of the template into an lxml entry, which is included in the client configuration. Client metadata is avilable inside of the template using the 'metadata' name. Note that only the markup Genshi template format can be used, as the target output format is XML. + +An Genshi template looks much like a Bundler file, except the Bundle tag has an additional `xmlns:py` attribute. See the examples. + +Examples +-------- + +In some cases, configuration files need to include the client's hostname in their name. The following template produces such a config file entry. + +.. code-block:: xml + + <Bundle name='foo' xmlns:py="http://genshi.edgewall.org/"> + <Path name='/etc/package-${metadata.hostname}'/> + </Bundle> + +Depending on the circumstance, these configuration files can either be handled by individual entries in :doc:`../generators/cfg`, :doc:`../generators/tcheetah`, or :doc:`../generators/tgenshi`, or can be mapped to a single entry by using the [wiki:altsrc] feature. + +In this example, configuration file names are built using probed results from the client. getmac is a probe that gathers client MAC addresses and returns them in a newline delimited string. + +.. code-block:: xml + + <Bundle name='networkinterfaces' xmlns:py="http://genshi.edgewall.org/"> + <?python + files = $metadata.Probes["getmacs"].split("\n") + ?> + <Path py:for="file in files" name="/etc/sysconfig/network/ifcfg-eth-${file}" altsrc='/etc/ifcfg-template'/> + </Bundle> + +.. note:: + * The use of the altsrc directive causes all ifcfg files to be handled by the same plugin and entry. + * The <?python ?> blocks have only been available in genshi since 0.4 (http://genshi.edgewall.org/ticket/84) + +If you want a file to be only on a per-client basis, you can use an if declaration: + +.. code-block:: xml + + <Bundle name='bacula' xmlns:py="http://genshi.edgewall.org/"> + <Path name="/etc/bacula/bconsole.conf"/> + <Path name="/etc/bacula/bacula-fd.conf"/> + <Path name="/etc/bacula/bacula-sd.conf"/> + <Path py:if="metadata.hostname == 'foo.bar.com'" name="/etc/bacula/bacula-dir.conf"/> + </Bundle> + +or alternately: + +.. code-block:: xml + + <Bundle name='bacula' xmlns:py="http://genshi.edgewall.org/"> + <Path name="/etc/bacula/bconsole.conf"/> + <Path name="/etc/bacula/bacula-fd.conf"/> + <Path name="/etc/bacula/bacula-sd.conf"/> + <py:if test="metadata.hostname == 'foo.bar.com'"> + <Path name="/etc/bacula/bacula-dir.conf"/> + </py:if> + </Bundle> + +The latter form is preferred if the if block contains multiple files. While this example is simple, the test in the if block can in fact be any python statement. + +Examples +-------- + +See [wiki:Plugins/Bundler/examples this] page for more Bundler examples. diff --git a/doc/plugins/version/bzr.txt b/doc/plugins/version/bzr.txt index 83bea745e..d4e624daf 100644 --- a/doc/plugins/version/bzr.txt +++ b/doc/plugins/version/bzr.txt @@ -3,3 +3,21 @@ === Bzr === + +Why use the Bazaar plugin +========================= + +The Bazaar plugin is useful if you would like to track changes to your bcfg2 repository using a `Bazaar <http://bazaar-vcs.org/>`_ backend. Currently, it enables you to get revision information out of your repository for reporting purposes. Future plans are to commit changes to the repo which are made by the server. + +How to enable the Bazaar plugin +=============================== + +Simply add "Bzr" to your plugins line in /etc/bcfg2.conf:: + + [server] + plugins = Base,Bundler,Cfg,...,Bzr + +Usage notes +=========== + +Unlike other VCS plugins for BCFG2, the Bazaar plugin checks whether there are uncommitted changes to the repository. If there are, this plugin appends a "+" after the version number. Essentially, this means you're using that version, "plus" some changes. diff --git a/doc/plugins/version/fossil.txt b/doc/plugins/version/fossil.txt index 893ab266e..d77e45693 100644 --- a/doc/plugins/version/fossil.txt +++ b/doc/plugins/version/fossil.txt @@ -3,3 +3,16 @@ ====== Fossil ====== + +Why use the Fossil plugin +========================= + +The Fossil plugin is useful if you would like to track changes to your bcfg2 repository using a `Fossil SCM <http://fossil-scm.org>`_ backend. Currently, It enables you to get revision information out of your repository for reporting purposes. Future plans are to commit changes to the repo which are made by the server. + +How to enable the Fossil plugin +=============================== + +Simply add "Fossil" to your plugins line in /etc/bcfg2.conf:: + + [server] + plugins = Base,Bundler,Cfg,...,Fossil diff --git a/doc/plugins/version/git.txt b/doc/plugins/version/git.txt index 621c64127..1b538f475 100644 --- a/doc/plugins/version/git.txt +++ b/doc/plugins/version/git.txt @@ -3,3 +3,16 @@ === Git === + +Why use the Git plugin +====================== + +The Git plugin is useful if you would like to track changes to your bcfg2 repository using a `Git <http://git-scm.com/>`_ backend. Currently, It enables you to get revision information out of your repository for reporting purposes. Future plans are to commit changes to the repo which are made by the server. + +How to enable the Git plugin +============================ + +The Git plugin uses `Dulwich <http://samba.org/~jelmer/dulwich/>`_ to interface with git repositories. Therefore, you will need to install Dulwich on the bcfg2 server first. Once installed, simply add Git to your plugins line in /etc/bcfg2.conf:: + + [server] + plugins = Base,Bundler,Cfg,...,Git diff --git a/doc/plugins/version/svn.txt b/doc/plugins/version/svn.txt index cfe44c707..e5ceb7aef 100644 --- a/doc/plugins/version/svn.txt +++ b/doc/plugins/version/svn.txt @@ -3,3 +3,16 @@ === Svn === + +Why use the Svn plugin +====================== + +The Svn plugin is useful if you would like to track changes to your bcfg2 repository using a `Subversion <http://subversion.tigris.org/>`_ backend. It deprecates the previous Subversion integration mentioned here at ftp://ftp.mcs.anl.gov/pub/bcfg/papers/directing-change-with-bcfg2.pdf. Currently, It enables you to get revision information out of your repository for reporting purposes. Future plans are to commit changes to the repo which are made by the server. + +How to enable the Svn plugin +============================ + +Simply add Svn to your plugins line in /etc/bcfg2.conf:: + + [server] + plugins = Base,Bundler,Cfg,DBStats,Decisions,Metadata,NagiosGen,Pkgmgr,Probes,Rules,SSHbase,TGenshi,Svn diff --git a/doc/quickstart/index.txt b/doc/quickstart/index.txt index 64a8faae6..53c6536e1 100644 --- a/doc/quickstart/index.txt +++ b/doc/quickstart/index.txt @@ -6,7 +6,7 @@ Quickstart The steps below should get you from just thinking about a configuration management system to an operational installation of -:ref:`Bcfg2`. If you get stuck, be sure to check the `mailing list`_ +Bcfg2. If you get stuck, be sure to check the `mailing list`_ or to drop in on our `IRC channel`_. .. _mailing list: https://trac.mcs.anl.gov/projects/bcfg2/wiki/MailingList @@ -23,14 +23,15 @@ Get and Install Bcfg2 Server We recommend running the server on a Linux machine for ease of deployment due to the availability of packages for the dependencies. -First, you need to download and install Bcfg2. Our :ref:`Download` has -both source and packages for common environments, while our -:ref:`Install` page describes what to do once you have the packages in -hand. To start you will need to install the server on one machine and -the client on one or more machines. Yes, your server can also be a -client (and should be by the time your environment is fully -managed). Detailed installation instructions can be found on the -:ref:`Install` page. +First, you need to download and install Bcfg2. The `Bcfg2 download +page`_ has both source and packages for common environments, while our +`Install page`_ describes what to do once you have the packages in hand. +To start, you will need to install the server on one machine and the +client on one or more machines. Yes, your server can also be a client +(and should be by the time your environment is fully managed). + +.. _Bcfg2 download page: http://trac.mcs.anl.gov/projects/bcfg2/wiki/Download +.. _Install page: http://trac.mcs.anl.gov/projects/bcfg2/wiki/Install Set up Repository ================= @@ -226,9 +227,9 @@ you will find that we now have a correct entry:: Done! Now we just have 242 (or more) entries to take care of! -:ref:`Bundler` is a relatively easy directory to populate. You can find -many samples of Bundles in the `Bundle Repository`_, many of which can be -used without editing. +:ref:`plugins-structures-bundler` is a relatively easy directory to +populate. You can find many samples of Bundles in the `Bundle +Repository`_, many of which can be used without editing. .. _Bundle Repository: http://trac.mcs.anl.gov/projects/bcfg2/wiki/Plugins/Bundler/examples diff --git a/doc/unsorted/index.txt b/doc/unsorted/index.txt index eccf489d4..bed264929 100644 --- a/doc/unsorted/index.txt +++ b/doc/unsorted/index.txt @@ -63,8 +63,6 @@ list below. * `Plugins` * `Plugins/Account` * `Plugins/Actions` -* `Plugins/Base` -* `Plugins/Bundler` * `Plugins/Bundler/examples` * `Plugins/Bundler/examples/kernel.xml` * `Plugins/Bundler/examples/moab.xml` @@ -73,19 +71,11 @@ list below. * `Plugins/Bundler/examples/snmpd.xml` * `Plugins/Bundler/examples/torque.xml` * `Plugins/Bundler/examples/yp.xml` -* `Plugins/Bzr` -* `Plugins/Cfg` -* `Plugins/Decisions` -* `Plugins/Deps` -* `Plugins/Fossil` -* `Plugins/Git` * `Plugins/GroupPatterns` * `Plugins/Hostbase` * `Plugins/Metadata` * `Plugins/NagiosGen` * `Plugins/Ohai` -* `Plugins/Packages` -* `Plugins/Pkgmgr` * `Plugins/Probes` * `Plugins/Probes/examples` * `Plugins/Probes/examples/current-kernel` @@ -96,12 +86,8 @@ list below. * `Plugins/Probes/examples/serial-console-speed` * `Plugins/Properties` * `Plugins/Rules` -* `Plugins/SGenshi` * `Plugins/SSHbase` * `Plugins/Snapshots` -* `Plugins/Svn` -* `Plugins/TCheetah` -* `Plugins/TGenshi` * `Plugins/TGenshi/examples` * `Plugins/TGenshi/examples/bcfg2_cron` * `Plugins/TGenshi/examples/clients.xml` |