diff options
Diffstat (limited to 'doc/server/plugins/generators')
18 files changed, 339 insertions, 204 deletions
diff --git a/doc/server/plugins/generators/cfg.txt b/doc/server/plugins/generators/cfg.txt index 2987e21b9..fce0439b5 100644 --- a/doc/server/plugins/generators/cfg.txt +++ b/doc/server/plugins/generators/cfg.txt @@ -20,7 +20,7 @@ repository location of ``/var/lib/bcfg2``. The contents of this directory are a series of directories corresponding to the real-life locations of the files on your clients, starting at the root level. For example:: - lueningh@tg-prez:~/bcfg2/repository> ls Cfg + % ls Cfg bin/ boot/ etc/ opt/ root/ usr/ var/ Specific config files go in like-named directories in this @@ -96,19 +96,175 @@ classes. Templates ========= +.. _server-plugins-generators-cfg-genshi: + Genshi Templates ---------------- -Genshi templates maybe used for entries as well. Any file ending in .genshi -will be processed using the new template style (like .newtxt in the TGenshi -plugin). +Genshi templates allow you to use the `Genshi +<http://genshi.edgewall.org>`_ templating system. This is similar to +the deprecated :ref:`server-plugins-generators-tgenshi-index` plugin. +Genshi templates should be named with a ``.genshi`` extension, e.g.:: + + % ls Cfg/etc/motd + info.xml motd.genshi + +See the genshi `documentation +<http://genshi.edgewall.org/wiki/Documentation>`_ for examples of +Genshi syntax. + +Inside Genshi Templates +~~~~~~~~~~~~~~~~~~~~~~~ + +Several variables are pre-defined inside templates: + +* **metadata** is the client's :ref:`metadata + <server-plugins-grouping-metadata-clientmetadata>` +* **name** is the path name specified in Bcfg2 +* **path** is the path to the TGenshi template. It starts with a + leading slash, and is relative to the Bcfg2 specification root. + E.g., ``/Cfg/etc/foo.conf/foo.conf.genshi`` or + ``/TGenshi/etc/foo.conf/template.newtxt.H_foo.example.com`` + +Troubleshooting +~~~~~~~~~~~~~~~ + +When developing a template, you can see what the template would +generate on a client with :ref:`bcfg2-info <server-bcfg2-info>`:: + + bcfg2-info buildfile <path> <hostname> + +E.g.:: + + bcfg2-info buildfile /etc/foo.conf foo.example.com + +To generate a file with an altsrc attribute, you can run:: + + bcfg2-info buildfile /etc/foo/foo.conf --altsrc=/etc/foo.conf \ + foo.example.com + +Sometimes, it's useful to be able to do more in-depth troubleshooting +by running the template manually. To do this, run ``bcfg2-info +debug``, and, once in the Python interpreter, run:: + + metadata = self.build_metadata("<hostname>") + path = "<relative path to template (see note below)>" + +``path`` should be set to the path to the template file with a leading +slash, relative to the Bcfg2 specification root. See `Inside Genshi +Templates`_ for examples. + +Then, run:: + + import os, Bcfg2.Options + from genshi.template import TemplateLoader, NewTextTemplate + name = os.path.dirname(path[path.find('/', 1):]) + setup = Bcfg2.Options.OptionParser({'repo': + Bcfg2.Options.SERVER_REPOSITORY}) + setup.parse('--') + template = TemplateLoader().load(setup['repo'] + path, cls=NewTextTemplate) + print template.generate(metadata=metadata, path=path, name=name).render() + +This gives you more fine-grained control over how your template is +rendered. + +You can also use this approach to render templates that depend on +:ref:`altsrc <server-plugins-structures-altsrc>` tags by setting +``path`` to the path to the template, and setting ``name`` to the path +to the file to be generated, e.g.:: + + metadata = self.build_metadata("foo.example.com") + path = "/Cfg/etc/sysconfig/network-scripts/ifcfg-template/ifcfg-template.genshi" + name = "/etc/sysconfig/network-scripts/ifcfg-bond0" + +Error handling +~~~~~~~~~~~~~~ + +Situations may arise where a templated file cannot be generated due to +missing or incomplete information. A TemplateError can be raised to +force a bind failure and prevent sending an incomplete file to the +client. For example, this template:: + + {% python + from genshi.template import TemplateError + grp = None + for g in metadata.groups: + if g.startswith('ganglia-gmond-'): + grp = g + break + else: + raise TemplateError, "Missing group" + %}\ + +will fail to bind if the client is not a member of a group starting with +"ganglia-gmond-". The syslogs on the server will contain this message:: + + bcfg2-server[5957]: Genshi template error: Missing group + bcfg2-server[5957]: Failed to bind entry: Path /etc/ganglia/gmond.conf + +...indicating the bind failure and message raised with the TemplateError. + +Handling Dollar Signs +~~~~~~~~~~~~~~~~~~~~~ + +In a Genshi template, ``$`` is a special character and must be escaped +by doubling, i.e., ``$$``. For instance, to embed the Subversion +``$Id$`` keyword in a Genshi template, you would have to do ``$$Id$$``. + +Examples +~~~~~~~~ + +.. toctree:: + :glob: + :maxdepth: 1 + + examples/genshi/* + +.. _server-plugins-generators-cfg-cheetah: Cheetah Templates ----------------- -Cheetah templates maybe used for entries as well. Simply name your file -with a .cheetah extenstion and it will be processed like the TCheetah -plugin. +Cheetah templates allow you to use the `cheetah templating system +<http://www.cheetahtemplate.org/>`_. This is similar to +the deprecated :ref:`server-plugins-generators-tcheetah` plugin. +Cheetah templates should be named with a ``.cheetah`` extension, e.g.:: + + % ls Cfg/etc/motd + info.xml motd.cheetah + +Inside Cheetah Templates +~~~~~~~~~~~~~~~~~~~~~~~~ + +Several variables are pre-defined inside templates: + +* **self.metadata** is the client's :ref:`metadata + <server-plugins-grouping-metadata-clientmetadata>` +* **self.path** is the path name specified in Bcfg2 +* **self.source_path** is the path to the Genshi template on the filesystem. + +Examples +~~~~~~~~ + +.. toctree:: + :glob: + :maxdepth: 1 + + examples/cheetah/* + +Comments and Cheetah +~~~~~~~~~~~~~~~~~~~~ + +As Cheetah processes your templates it will consider hash "#" style +comments to be actual comments in the template and will strip them +from the final config file. If you would like to preserve the comment +in the final config file you need to escape the hash character '\#' +which will tell Cheetah (and Python) that you do in fact want the +comment to appear in the final config file.:: + + # This is a comment in my template which will be stripped when it's processed through Cheetah + \# This comment will appear in the generated config file. + Notes on Using Templates ------------------------ diff --git a/doc/server/plugins/generators/decisions.txt b/doc/server/plugins/generators/decisions.txt index acb1de6ee..9a40ab8fd 100644 --- a/doc/server/plugins/generators/decisions.txt +++ b/doc/server/plugins/generators/decisions.txt @@ -30,10 +30,10 @@ client's whitelists or blacklists. The Decisions 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 (so you can use host- -and group-specific files and the like after their basename). File basenames -are either ``whitelist`` or ``blacklist``. These files have a simple format; -the following is an example. +files managed by Cfg and Probes, so you can use host- and +group-specific files and the like after their basename. File basenames +are either ``whitelist`` or ``blacklist``. These files have a simple +format; the following is an example. .. code-block:: xml diff --git a/doc/server/plugins/generators/examples/cheetah/crontab.txt b/doc/server/plugins/generators/examples/cheetah/crontab.txt new file mode 100644 index 000000000..4fe5485c3 --- /dev/null +++ b/doc/server/plugins/generators/examples/cheetah/crontab.txt @@ -0,0 +1,26 @@ +.. -*- mode: rst -*- + +============================ +Writing crontab with Cheetah +============================ + +This example randomizes the time of cron.daily +execution with a stable result. Cron.daily is run at a consistent, +randomized time between midnight and 7am.:: + + #import random + #silent random.seed($self.metadata.hostname) + + # /etc/crontab: system-wide crontab + # Unlike any other crontab you don't have to run the `crontab` + # command to install the new version when you edit this file. + # This file also has a username field, that none of the other crontabs do. + + SHELL=/bin/sh + PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin://bin + + # m h dom mon dow user command + 17 * * * * root run-parts --report /etc/cron.hourly + $random.randrange(0,59) $random.randrange(0,6) * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily + 47 6 * * 7 root test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly + 52 6 1 * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly. diff --git a/doc/server/plugins/generators/examples/cheetah/simple.txt b/doc/server/plugins/generators/examples/cheetah/simple.txt new file mode 100644 index 000000000..fd6048e84 --- /dev/null +++ b/doc/server/plugins/generators/examples/cheetah/simple.txt @@ -0,0 +1,53 @@ +.. -*- mode: rst -*- + +========================= + Basic Cheetah Templates +========================= + +This simple example demonstrates basic usage of Cheetah templates. + +``/var/lib/bcfg2/Cfg/foo/foo.cheetah`` + +.. code-block:: none + + Hostname is $self.metadata.hostname + Filename is $self.path + Template is $self.source_path + Groups: + #for $group in $self.metadata.groups: + * $group + #end for + Categories: + #for $category in $self.metadata.categories: + * $category -- $self.metadata.categories[$category] + #end for + + Probes: + #for $probe in $self.metadata.Probes: + * $probe -- $self.metadata.Probes[$probe] + #end for + +Output +====== + +.. code-block:: xml + + <Path type="file" name="/foo" owner="root" perms="0644" group="root"> + Hostname is topaz.mcs.anl.gov + Filename is /foo + Template is /var/lib/bcfg2/Cfg/foo/foo.cheetah + Groups: + * desktop + * mcs-base + * ypbound + * workstation + * xserver + * debian-sarge + * debian + * a + Categories: + * test -- a + + Probes: + * os -- debian + </Path> diff --git a/doc/server/plugins/generators/tgenshi/bcfg2-cron.txt b/doc/server/plugins/generators/examples/genshi/bcfg2-cron.txt index 56def1e3d..1c4bd3a3c 100644 --- a/doc/server/plugins/generators/tgenshi/bcfg2-cron.txt +++ b/doc/server/plugins/generators/examples/genshi/bcfg2-cron.txt @@ -1,7 +1,5 @@ .. -*- mode: rst -*- -.. _server-plugins-generators-tgenshi-bcfg2-cron: - bcfg2-cron ========== diff --git a/doc/server/plugins/generators/tgenshi/clientsxml.txt b/doc/server/plugins/generators/examples/genshi/clientsxml.txt index 87d6d728a..548c388d2 100644 --- a/doc/server/plugins/generators/tgenshi/clientsxml.txt +++ b/doc/server/plugins/generators/examples/genshi/clientsxml.txt @@ -1,14 +1,12 @@ .. -*- mode: rst -*- -.. _server-plugins-generators-tgenshi-clientsxml: - -clientsxml -========== +clients.xml +=========== As submitted by dclark Here is an example of maintaining the bcfg2 server's -``/var/lib/bcfg2/Metadata/clients.xml`` file using TGenshi. +``/var/lib/bcfg2/Metadata/clients.xml`` file using Genshi templates. There are two main advantages: @@ -16,7 +14,6 @@ There are two main advantages: file this helps maintain consistency, makes changing passwords easier, and also makes it easier to share your configurations with other sites/people. - #. You can template the file using Genshi's `{% def %}` syntax, which makes `clients.xml` much more readable. An important thing to note is how the `name` variable is handled - when @@ -40,11 +37,10 @@ Possible improvements: some kind of one-way hash based on the `name` might make more sense, and make ``Properties/passwords.xml`` easier to maintain. - * TGenshi/var/lib/bcfg2/Metadata/clients.xml/template.newtxt: + * Cfg/var/lib/bcfg2/Metadata/clients.xml/clients.xml.genshi: .. code-block:: xml - <!-- TGenshi/var/lib/bcfg2/Metadata/clients.xml/template.newtxt --> <!-- Do not edit this file directly - edit only the above template --> {# Doc: http://bcfg2.org/wiki/Authentication #}\ diff --git a/doc/server/plugins/generators/tgenshi/ganglia.txt b/doc/server/plugins/generators/examples/genshi/ganglia.txt index 3b844afda..3a20fde92 100644 --- a/doc/server/plugins/generators/tgenshi/ganglia.txt +++ b/doc/server/plugins/generators/examples/genshi/ganglia.txt @@ -1,40 +1,39 @@ .. -*- mode: rst -*- -.. _server-plugins-generators-tgenshi-ganglia: - ganglia ======= -Another interesting example of **TGenshi** templating is to automatically -generate ``gmond``/``gmetad`` configuration files. The idea is that each -cluster is headless: it communicates with the rest of the cluster members -on an isolated multicast IP address and port. Any of the cluster members -is therefore isolated on that particular ip/port pair. Additionally, -each ``gmond`` instance **also** listens on UDP. This allows for any of -the cluster members to be polled for information on the entire cluster! - -The second part of the trick is in ``gmetad.conf``. Here, we dynamically -generate a list of clusters (based on profiles names) and a list of -members to poll (based on the clients in said profiles). As the number of -profiles and client grows, this list will grow automatically as well. When -a new host is added, ``gmetad`` will receive an updated configuration and -act accordingly. - -There **is** one caveat though. The ``gmetad.conf`` parser is hard coded -to read 16 arguments per ``data_source`` line. If you have more than 15 -nodes in a cluster, you will see a warning in the logs. You can either -ignore it, or truncate the list to the first 15 members. +Another interesting example of Genshi templating is to automatically +generate ``gmond``/``gmetad`` configuration files. The idea is that +each cluster is headless: it communicates with the rest of the cluster +members on an isolated multicast IP address and port. Any of the +cluster members is therefore isolated on that particular ip/port +pair. Additionally, each ``gmond`` instance **also** listens on +UDP. This allows for any of the cluster members to be polled for +information on the entire cluster! + +The second part of the trick is in ``gmetad.conf``. Here, we +dynamically generate a list of clusters (based on profiles names) and +a list of members to poll (based on the clients in said profiles). As +the number of profiles and client grows, this list will grow +automatically as well. When a new host is added, ``gmetad`` will +receive an updated configuration and act accordingly. + +There **is** one caveat though. The ``gmetad.conf`` parser is hard +coded to read 16 arguments per ``data_source`` line. If you have more +than 15 nodes in a cluster, you will see a warning in the logs. You +can either ignore it, or truncate the list to the first 15 members. In our environment, a profile is a one to one match with the role of -that particular host. You can also do this based on groups, or any other -client property. +that particular host. You can also do this based on groups, or any +other client property. Bundler/ganglia.xml ------------------- .. code-block:: xml - <Bundle name='ganglia' version='2.0' revision='$Revision$' origin='$HeadURL$' > + <Bundle name='ganglia'> <Package name='ganglia-gmond' /> <Package name='ganglia-gmond-modules-python' /> <Path name='/etc/ganglia/gmond.conf' /> @@ -55,17 +54,17 @@ Rules/services-ganglia.xml .. code-block:: xml - <Rules priority='10' revision='$Revision$' origin='$HeadURL$' > + <Rules priority='10'> <Service name='gmond' type='chkconfig' status='on' /> <Group name='gmetad-server'> <Service name='gmetad' type='chkconfig' status='on' /> </Group> </Rules> -TGenshi/etc/ganglia/gmetad.conf/template.newtxt ------------------------------------------------ +Cfg/etc/ganglia/gmetad.conf/gmetad.conf.genshi +---------------------------------------------- -:: +.. code-block:: none {% python client_metadata = metadata.query.all() @@ -90,13 +89,12 @@ TGenshi/etc/ganglia/gmetad.conf/template.newtxt rrd_rootdir "/var/lib/ganglia/rrds" -TGenshi/etc/ganglia/gmond.conf/template.newtxt ----------------------------------------------- +Cfg/etc/ganglia/gmond.conf/gmod.conf.genshi +------------------------------------------- -:: +.. code-block:: none {% python - from genshi.builder import tag import random random.seed(metadata.profile) last_octet=random.randint(2,254) diff --git a/doc/server/plugins/generators/tgenshi/grubconf.txt b/doc/server/plugins/generators/examples/genshi/grubconf.txt index d4381f10b..11dc7e974 100644 --- a/doc/server/plugins/generators/tgenshi/grubconf.txt +++ b/doc/server/plugins/generators/examples/genshi/grubconf.txt @@ -1,9 +1,7 @@ .. -*- mode: rst -*- -.. _server-plugins-generators-tgenshi-grubconf: - -grubconf -======== +grub.conf +========= Automate the build of grub.conf based on probe data. In this case, we take the results from three probes, serial-console-speed, grub-serial-order, @@ -11,9 +9,9 @@ and current-kernel to fill in a few variables. In addition, we want at least two entries set up for the kernel: a multiuser and a single user option. -:: +.. code-block:: none - # grub.conf generated by anaconda + # grub.conf generated by Bcfg2 # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that diff --git a/doc/server/plugins/generators/tgenshi/hosts.txt b/doc/server/plugins/generators/examples/genshi/hosts.txt index fd3446df8..144816e65 100644 --- a/doc/server/plugins/generators/tgenshi/hosts.txt +++ b/doc/server/plugins/generators/examples/genshi/hosts.txt @@ -1,7 +1,5 @@ .. -*- mode: rst -*- -.. _server-plugins-generators-tgenshi-hosts: - hosts ===== diff --git a/doc/server/plugins/generators/tgenshi/iptables.txt b/doc/server/plugins/generators/examples/genshi/iptables.txt index 310f9ffab..b9b3f6904 100644 --- a/doc/server/plugins/generators/tgenshi/iptables.txt +++ b/doc/server/plugins/generators/examples/genshi/iptables.txt @@ -1,25 +1,22 @@ .. -*- mode: rst -*- -.. _server-plugins-generators-tgenshi-iptables: +========== + iptables +========== -iptables -======== - -* Setup a TGenshi base iptables file that contains the basic rules you +* Setup a Genshi base iptables file that contains the basic rules you want every host to have -* Create a custom dir that has group and host specific rules you want - to apply * To be safe you should have a client side IptablesDeadmanScript if you intend on having bcfg2 bounce iptables upon rule updates .. note:: When updating files in the ``includes`` directory, you will - need to `touch` the TGenshi template to regenerate the + need to `touch` the Genshi template to regenerate the template contents. -/repository/TGenshi/etc/sysconfig/iptables/template.newtxt ----------------------------------------------------------- +/repository/Cfg/etc/sysconfig/iptables/iptables.genshi +====================================================== -:: +.. code-block:: none {% python from genshi.builder import tag @@ -32,9 +29,8 @@ iptables repo = setup['repo'] basedir = '%s' % (repo) - # for instance: /var/lib/bcfg2/custom/etc/sysconfig/iptables/ - bcfg2BaseDir = basedir + '/includes' + name + '/' - + # for instance: + bcfg2BaseDir = basedir + name + '/' def checkHostFile(hostName, type): fileName = bcfg2BaseDir + type + '.H_' + hostName @@ -54,7 +50,6 @@ iptables # BCFG2 GENERATED IPTABLES # DO NOT CHANGE THIS # $$Id$$ - # $$HeadURL$$ # Templates live in ${bcfg2BaseDir} # Manual customization of this file will get reverted. # ----------------------------- FILTER --------------------------------- # @@ -200,10 +195,10 @@ iptables {% include ${checkHostFile(metadata.hostname, 'custom-mangle')} %}\ COMMIT -/var/lib/bcfg2/custom/etc/sysconfig/iptables/custom-filter.G_mysql-server -------------------------------------------------------------------------- +Cfg/etc/sysconfig/iptables/custom-filter.G_mysql-server +------------------------------------------------------- -:: +.. code-block:: none :MYSQL - [0:0] -A INPUT -p tcp -m state --state NEW -m tcp --dport 3306 --tcp-flags FIN,SYN,RST,ACK SYN -j MYSQL @@ -215,8 +210,7 @@ that looks like the following:: # BCFG2 GENERATED IPTABLES # DO NOT CHANGE THIS # $Id: template.newtxt 5402 2009-08-19 22:50:06Z unixmouse$ - # $HeadURL: https://svn.fakecompany.net/bcfg2/trunk/repository/TGenshi/etc/sysconfig/iptables/template.newtxt $ - # Templates live in /var/lib/bcfg2/custom/etc/sysconfig/iptables/ + # Templates live in /var/lib/bcfg2/Cfg/etc/sysconfig/iptables/ # Manual customization of this file will get reverted. # ----------------------------- FILTER --------------------------------- # # Default CHAINS for FILTER: diff --git a/doc/server/plugins/generators/tgenshi/motd.txt b/doc/server/plugins/generators/examples/genshi/motd.txt index 1e2f3e4b9..6f4a891d1 100644 --- a/doc/server/plugins/generators/tgenshi/motd.txt +++ b/doc/server/plugins/generators/examples/genshi/motd.txt @@ -1,33 +1,18 @@ .. -*- mode: rst -*- -.. _server-plugins-generators-tgenshi-motd: - -motd -==== +====== + motd +====== The following template automatically generates a MOTD (message of the day) file that describes the system in terms of its Bcfg2 metadata and probe responses. It conditionally displays groups, categories, and probe responses, if there exists any data for them. -New Style of TGenshi --------------------- - -This is the preferred way of creating TGenshi contents. It requires -Genshi 0.5 or later. - -On the Bcfg2 server -^^^^^^^^^^^^^^^^^^^ - -Where, **$bcfg2** is your Bcfg2 repository on your Bcfg2 server, the -following files need to be created: - -:: - - $bcfg2/TGenshi/etc/motd/info.xml - $bcfg2/TGenshi/etc/motd/template.newtxt +Cfg/etc/motd/motd.genshi +======================== -The contents of ``motd/template.newtxt`` could be something like this:: +.. code-block:: none ------------------------------------------------------------------------ GOALS FOR SERVER MANGED BY BCFG2 @@ -65,12 +50,9 @@ of the host (if any), and result of probes on the host (if any). The template formats this in with a header and footer that makes it visually more appealing. -A ``motd/info.xml`` file isn't strictly needed, because ``/etc/motd`` -has the Bcfg2 default permissions (i.e. root:root 0644), but it can be -included for completeness. Output -^^^^^^ +====== One possible output of this template would be the following:: @@ -111,59 +93,6 @@ One possible output of this template would be the following:: ------------------------------------------------------------------------- Please create a Ticket for any system level changes you need from IT. -Taking it to the next level -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - One way to make this even more useful, is to only include the result of certain probes. It would also be a nice feature to be able to include customer messages on a host or group level. - -Old Style of TGenshi --------------------- - -The following is a way to do the same thing using the older, -it-may-be-depreciated, style of Genshi (pre-0.5).:: - - Hostname is $metadata.hostname - - Groups: - #for group in metadata.groups - * $group - #end - - #if metadata.categories - Categories: - #for category in metadata.categories - * $category - #end - #end - - #if metadata.probes - Probes: - #for probe, value in metadata.probes.iteritems() - * $probe $value - #end - #end - -This template results in:: - - > buildfile /bar.conf ubik3 - <Path name="/bar.conf" type="file" owner="root" perms="0644" group="root">Hostname is ubik3 - - Groups: - * desktop - * computeserver - * mcs-base - * ypbound - * workstation - * mysql-4 - * debian-sarge-base - * debian-sarge - * base - * debian - - Categories: - * noyp - * mysql - - </Path> diff --git a/doc/server/plugins/generators/tgenshi/mycnf.txt b/doc/server/plugins/generators/examples/genshi/mycnf.txt index 7cf48ece0..76e2fc2bb 100644 --- a/doc/server/plugins/generators/tgenshi/mycnf.txt +++ b/doc/server/plugins/generators/examples/genshi/mycnf.txt @@ -1,16 +1,13 @@ .. -*- mode: rst -*- -.. _server-plugins-generators-tgenshi-mycnf: - -mycnf -===== +my.cnf +====== The following template generates a ``server-id`` based on the last two numeric parts of the IP address. The "slave" portion of the configuration -only applies to machines in the "slave" group.:: +only applies to machines in the "slave" group:: {% python - from genshi.builder import tag import socket parts = socket.gethostbyname(metadata.hostname).split('.') server_id = parts[2] + parts[3] diff --git a/doc/server/plugins/generators/tgenshi/test.txt b/doc/server/plugins/generators/examples/genshi/test.txt index c047b88d0..03d0becd9 100644 --- a/doc/server/plugins/generators/tgenshi/test.txt +++ b/doc/server/plugins/generators/examples/genshi/test.txt @@ -1,12 +1,8 @@ .. -*- mode: rst -*- -.. _server-plugins-generators-tgenshi-test: - test ==== -FIXME: This example needs to be retested with new Properties plugin. - As submitted by dclark This file just shows you what's available. It assumes a @@ -14,7 +10,6 @@ This file just shows you what's available. It assumes a .. code-block:: xml - #!text/xml <Properties> <password> <bcfg2>fakeBCFG2password</bcfg2> @@ -80,20 +75,10 @@ This file just shows you what's available. It assumes a ${var} \ {% end %} -When the above file is saved as -``/var/lib/bcfg2/TGenshi/test/template.newtxt`` and generated with -``bcfg2-info buildfile /test test.hostname.org``, the results look like -this (below reformatted a little bit to fit in 80 columns):: - - Failed to read file probed.xml - Processed 44 gamin events in 0.108 seconds. 0 collapsed - Processed 17 gamin events in 0.245 seconds. 0 collapsed - Processed 17 gamin events in 0.163 seconds. 0 collapsed - Processed 21 gamin events in 0.197 seconds. 0 collapsed - Processed 0 gamin events in 0.100 seconds. 0 collapsed - Processed 12 gamin events in 0.105 seconds. 0 collapsed - Processed 0 gamin events in 0.100 seconds. 0 collapsed - <?xml version='1.0' encoding='UTF-8'?> +When the above file is saved as ``Cfg/test/test.genshi`` and generated +with ``bcfg2-info buildfile /test test.hostname.org``, the results +look like this (below reformatted a little bit to fit in 80 columns):: + <Path type="file" name="/test" owner="root" perms="644" encoding="ascii" group="root" paranoid="false"> Hostname is test.hostname.org diff --git a/doc/server/plugins/generators/packages.txt b/doc/server/plugins/generators/packages.txt index 0315354a8..f0abf4af2 100644 --- a/doc/server/plugins/generators/packages.txt +++ b/doc/server/plugins/generators/packages.txt @@ -36,12 +36,14 @@ source to which they apply (based on group memberships, as described above). Packages and dependencies are resolved from all applicable sources. -.. note:: To recap, a client needs to be a member of the - **Architecture** group and any other groups defined in your - ``Packages/sources.xml`` file in order for the client to be - associated to the proper sources. If you are using - :ref:`server-plugins-generators-packages-magic-groups`, then - a client must also be a member of the appropriate OS group. +.. note:: + + To recap, a client needs to be a member of the **Architecture** + group and any other groups defined in your + ``Packages/sources.xml`` file in order for the client to be + associated to the proper sources. If you are using + :ref:`server-plugins-generators-packages-magic-groups`, then a + client must also be a member of the appropriate OS group. .. _server-plugins-generators-packages-magic-groups: @@ -458,7 +460,8 @@ See :ref:`configuration` for more details on these options. Support for generating Yum configs was added in 1.2.0, and Apt configs was added in 1.3.0. Before that, you could use - :doc:`./tgenshi/index` or :doc:`./tcheetah` to generate your + :ref:`server-plugins-generators-cfg-genshi` or + :ref:`server-plugins-generators-cfg-cheetah` to generate your configs. .. _native-yum-libraries: diff --git a/doc/server/plugins/generators/pkgmgr.txt b/doc/server/plugins/generators/pkgmgr.txt index 76a8ec1a5..0d992685c 100644 --- a/doc/server/plugins/generators/pkgmgr.txt +++ b/doc/server/plugins/generators/pkgmgr.txt @@ -310,7 +310,7 @@ Altogether, this should move policy decisions about package architectures to bundles/base. Automated Generation of Pkgmgr Configuration Files --------------------------------------------------- +================================================== The two utilities detailed below are provided in the tools directory of the source tarball. @@ -373,7 +373,7 @@ containing RPMs or from a list of YUM repositories.:: .. 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 @@ -398,7 +398,7 @@ and other attributes in the existing file will remain unchanged.:: NOTE: Each URL must end in a '/' character. Pkgmgr Configuration Examples ------------------------------ +============================= verify_flags ^^^^^^^^^^^^ diff --git a/doc/server/plugins/generators/sslca.txt b/doc/server/plugins/generators/sslca.txt index 36245cbf5..4c1845406 100644 --- a/doc/server/plugins/generators/sslca.txt +++ b/doc/server/plugins/generators/sslca.txt @@ -9,7 +9,8 @@ SSLCA SSLCA is a generator plugin designed to handle creation of SSL private keys and certificates on request. -Borrowing ideas from the TGenshi and SSHbase plugins, SSLCA automates +Borrowing ideas from :ref:`server-plugins-generators-cfg-genshi` and +the :ref:`server-plugins-generators-sshbase` plugin, SSLCA automates the generation of SSL certificates by allowing you to specify key and certificate definitions. Then, when a client requests a Path that contains such a definition within the SSLCA repository, the matching diff --git a/doc/server/plugins/generators/tcheetah.txt b/doc/server/plugins/generators/tcheetah.txt index ae56e4d02..894b35d31 100644 --- a/doc/server/plugins/generators/tcheetah.txt +++ b/doc/server/plugins/generators/tcheetah.txt @@ -6,6 +6,11 @@ TCheetah ======== +.. warning:: + + TCheetah is deprecated. You should instead use + :ref:`server-plugins-generators-cfg-cheetah` in the Cfg plugin. + This document reflects the ``TCheetah`` plugin. The ``TCheetah`` plugin allows you to use the `cheetah templating system diff --git a/doc/server/plugins/generators/tgenshi/index.txt b/doc/server/plugins/generators/tgenshi.txt index 0d4a7ffb0..5e0a7f1b5 100644 --- a/doc/server/plugins/generators/tgenshi/index.txt +++ b/doc/server/plugins/generators/tgenshi.txt @@ -6,6 +6,11 @@ TGenshi ======= +.. warning:: + + The TGenshi plugin is deprecated. You should instead use + :ref:`server-plugins-generators-cfg-genshi` in the Cfg plugin. + This page documents the TGenshi plugin. This plugin works with version 0.4 and newer of the genshi library. @@ -202,14 +207,7 @@ Examples ======== .. toctree:: + :glob: :maxdepth: 1 - bcfg2-cron - clientsxml - ganglia - grubconf - hosts - iptables - motd - mycnf - test + examples/genshi/* |