diff options
Diffstat (limited to 'doc')
29 files changed, 81 insertions, 1294 deletions
diff --git a/doc/appendix/contributors.txt b/doc/appendix/contributors.txt index 1afc62706..9f99d25be 100644 --- a/doc/appendix/contributors.txt +++ b/doc/appendix/contributors.txt @@ -35,7 +35,7 @@ In alphabetical order of the given name: Bcfg client and server and implemented a common logging infrastructure. - Fabian Affolter <mail@fabian-affolter.ch> made some patches, added some new features and plugins, and restructured the manual for Bcfg2. -- Jack Neely <jjneely@ncsu.edu> worked on YUMng. +- Jack Neely <jjneely@ncsu.edu> worked on YUMng (now YUM). - James Yang <jjyang@mcs.anl.gov> worked on ``bcfg2-admin`` and ``bcfg2-reports``. - Jason Pepas <cell@ices.utexas.edu> has written a RPM package list creator diff --git a/doc/appendix/files/mysql.txt b/doc/appendix/files/mysql.txt index 81104ec17..6c6c83e3e 100644 --- a/doc/appendix/files/mysql.txt +++ b/doc/appendix/files/mysql.txt @@ -17,7 +17,7 @@ I added a new bundle: <Bundle name="mysql-server" version="3.0"> <Path name="/root/bcfg2-install/mysql/users.sh"/> <Path name="/root/bcfg2-install/mysql/users.sql"/> - <PostInstall name="/root/bcfg2-install/mysql/users.sh"/> + <Action name="mysql_users"/> <Package name="mysql-server-4.1"/> <Service name="mysql"/> </Bundle> diff --git a/doc/appendix/guides/centos.txt b/doc/appendix/guides/centos.txt index 5a2d1bed0..afec18ff5 100644 --- a/doc/appendix/guides/centos.txt +++ b/doc/appendix/guides/centos.txt @@ -102,7 +102,7 @@ Run bcfg2 to be sure you are able to communicate with the server:: Excluding Packages in global exclude list Finished Loaded tool drivers: - Action Chkconfig POSIX YUMng + Action Chkconfig POSIX YUM Phase: initial Correct entries: 0 @@ -147,7 +147,7 @@ Now if you run the client, no more warning:: Excluding Packages in global exclude list Finished Loaded tool drivers: - Action Chkconfig POSIX YUMng + Action Chkconfig POSIX YUM Phase: initial Correct entries: 0 @@ -176,7 +176,7 @@ First, replace **Pkgmgr** with **Packages** in the plugins line of ``bcfg2.conf``. Then create Packages layout (as per :ref:`packages-exampleusage`) in ``/var/lib/bcfg2`` -.. note:: I am using the RawURL syntax here since we are using `mrepo`_ +.. note:: I am using the rawurl syntax here since we are using `mrepo`_ to manage our yum mirrors. .. _mrepo: http://dag.wieers.com/home-made/mrepo/ @@ -184,43 +184,36 @@ line of ``bcfg2.conf``. Then create Packages layout (as per .. code-block:: xml <Sources> - <!-- CentOS (5.4) sources --> - <YUMSource> - <Group>centos-5.4</Group> - <RawURL>http://mrepo/centos5-x86_64/RPMS.os</RawURL> - <Arch>x86_64</Arch> - </YUMSource> - <YUMSource> - <Group>centos-5.4</Group> - <RawURL>http://mrepo/centos5-x86_64/RPMS.updates</RawURL> - <Arch>x86_64</Arch> - </YUMSource> - <YUMSource> - <Group>centos-5.4</Group> - <RawURL>http://mrepo/centos5-x86_64/RPMS.extras</RawURL> - <Arch>x86_64</Arch> - </YUMSource> + <Group name="centos5"> + <!-- CentOS 5 sources --> + <Source type="yum" + rawurl="http://mrepo/centos5-x86_64/RPMS.os"> + <Arch>x86_64</Arch> + </Source> + <Source type="yum" + rawurl="http://mrepo/centos5-x86_64/RPMS.updates"> + <Arch>x86_64</Arch> + </Source> + <Source type="yum" + rawurl="http://mrepo/centos5-x86_64/RPMS.extras"> + <Arch>x86_64</Arch> + </Source> + </Group> </Sources> -Due to the :ref:`server-plugins-generators-packages-magic-groups`, -we need to modify our Metadata. Let's add a **centos5.4** group which -inherits a **centos** group (this should replace the existing **redhat** -group) present in ``/var/lib/bcfg2/Metadata/groups.xml``. The resulting -file should look something like this - -.. note:: - - The reason we are creating a release-specific group in this case is - that the YUMSource above is specific to the 5.4 release of centos. - That is, it should not apply to other releases (5.1, 5.3, etc). +To make these sources apply to our centos 5 clients, we need to modify +our Metadata. Let's add a **centos5** group which inherits a +**centos** group (this should replace the existing **redhat** group) +present in ``/var/lib/bcfg2/Metadata/groups.xml``. The resulting file +should look something like this .. code-block:: xml <Groups version='3.0'> <Group profile='true' public='true' default='true' name='basic'> - <Group name='centos-5.4'/> + <Group name='centos-5'/> </Group> - <Group name='centos-5.4'> + <Group name='centos-5'> <Group name='centos'/> </Group> <Group name='ubuntu'/> @@ -277,7 +270,7 @@ profile group might look something like this <Group profile='true' public='true' default='true' name='basic'> <Bundle name='base-packages'/> - <Group name='centos5.4'/> + <Group name='centos5'/> </Group> Now if we run the client, we can see what this has done for us.:: @@ -291,7 +284,7 @@ Now if we run the client, we can see what this has done for us.:: Excluding Packages in global exclude list Finished Loaded tool drivers: - Action Chkconfig POSIX YUMng + Action Chkconfig POSIX YUM Package pam failed verification. Phase: initial @@ -336,7 +329,7 @@ entries?:: Excluding Packages in global exclude list Finished Loaded tool drivers: - Action Chkconfig POSIX YUMng + Action Chkconfig POSIX YUM Extra Package openssh-clients 4.3p2-36.el5_4.4.x86_64. Extra Package libuser 0.54.7-2.1el5_4.1.x86_64. ... @@ -394,7 +387,7 @@ package:: Excluding Packages in global exclude list Finished Loaded tool drivers: - Action Chkconfig POSIX YUMng + Action Chkconfig POSIX YUM Extra Package gpg-pubkey e8562897-459f07a4.None. Extra Package gpg-pubkey 217521f6-45e8a532.None. @@ -562,7 +555,7 @@ Now we run the client and see there are no more unmanaged entries!:: Excluding Packages in global exclude list Finished Loaded tool drivers: - Action Chkconfig POSIX YUMng + Action Chkconfig POSIX YUM Phase: initial Correct entries: 205 diff --git a/doc/appendix/guides/fedora.txt b/doc/appendix/guides/fedora.txt index 1e49084ef..1c2a33f3b 100644 --- a/doc/appendix/guides/fedora.txt +++ b/doc/appendix/guides/fedora.txt @@ -106,7 +106,7 @@ Run ``bcfg2`` to be sure you are able to communicate with the server: import md5 Loaded plugins: presto, refresh-packagekit Loaded tool drivers: - Action Chkconfig POSIX YUMng + Action Chkconfig POSIX YUM Extra Package imsettings-libs 0.108.0-2.fc13.i686. Extra Package PackageKit-device-rebind 0.6.4-1.fc13.i686. ... @@ -209,8 +209,10 @@ near your location according the `Mirror list`_ . .. code-block:: xml <Sources> - <Group name="fedora-13"> - <Source type="yum" url="ftp://fedora.tu-chemnitz.de/pub/linux/fedora/linux/releases/" version="13"> + <Group name="fedora13"> + <Source type="yum" + url="ftp://fedora.tu-chemnitz.de/pub/linux/fedora/linux/releases/" + version="13"> <Component>Fedora</Component> <Arch>i386</Arch> <Arch>x86_64</Arch> @@ -219,11 +221,11 @@ near your location according the `Mirror list`_ . </Sources> -Due to the :ref:`server-plugins-generators-packages-magic-groups`, -we need to modify our Metadata. Let's add a **fedora13** group which -inherits a **fedora** group (this should replace the existing **redhat** -group) present in ``/var/lib/bcfg2/Metadata/groups.xml``. The resulting -file should look something like this +In order to make these sources apply to our clients, we need to modify +our Metadata. Let's add a **fedora13** group which inherits a +**fedora** group (this should replace the existing **redhat** group) +present in ``/var/lib/bcfg2/Metadata/groups.xml``. The resulting file +should look something like this .. note:: diff --git a/doc/appendix/guides/ubuntu.txt b/doc/appendix/guides/ubuntu.txt index 5a67d0a37..06813f50b 100644 --- a/doc/appendix/guides/ubuntu.txt +++ b/doc/appendix/guides/ubuntu.txt @@ -82,7 +82,7 @@ You are now ready to start your bcfg2 server for the first time.:: root@lucid:~# tail /var/log/syslog Dec 17 22:07:02 lucid bcfg2-server[17523]: serving bcfg2-server at https://lucid:6789 Dec 17 22:07:02 lucid bcfg2-server[17523]: serve_forever() [start] - Dec 17 22:07:02 lucid bcfg2-server[17523]: Processed 16 fam events in 0.502 seconds. 0 coalesced + Dec 17 22:07:02 lucid bcfg2-server[17523]: Handled 16 events in 0.502 seconds Run bcfg2 to be sure you are able to communicate with the server:: @@ -181,9 +181,9 @@ Create Packages layout (as per :ref:`packages-exampleusage`) in </Group> </Sources> -Due to the :ref:`server-plugins-generators-packages-magic-groups`, -we need to modify our Metadata. Let's add an **ubuntu-lucid** -group which inherits the **ubuntu** group already present in +To make these sources apply to our clients, we need to modify our +Metadata. Let's add an **ubuntu-lucid** group which inherits the +**ubuntu** group already present in ``/var/lib/bcfg2/Metadata/groups.xml``. The resulting file should look something like this @@ -256,7 +256,7 @@ Now we restart the bcfg2-server:: Dec 17 22:37:27 lucid bcfg2-server[17937]: service available at https://lucid:6789 Dec 17 22:37:27 lucid bcfg2-server[17937]: serving bcfg2-server at https://lucid:6789 Dec 17 22:37:27 lucid bcfg2-server[17937]: serve_forever() [start] - Dec 17 22:37:28 lucid bcfg2-server[17937]: Processed 17 fam events in 0.502 seconds. 0 coalesced + Dec 17 22:37:28 lucid bcfg2-server[17937]: Handled 17 events in 0.502 seconds Start managing packages ----------------------- @@ -364,7 +364,7 @@ while, I ended up with a minimal bundle that looks like this <Package name='deborphan'/> <Package name='diffutils'/> <Package name='e2fsprogs'/> - <Package name='fam'/> + <Package name='gamin'/> <Package name='grep'/> <Package name='grub-pc'/> <Package name='gzip'/> @@ -379,7 +379,7 @@ while, I ended up with a minimal bundle that looks like this <Package name='mlocate'/> <Package name='ncurses-base'/> <Package name='openssh-server'/> - <Package name='python-fam'/> + <Package name='python-gamin'/> <Package name='tar'/> <Package name='ubuntu-minimal'/> <Package name='ubuntu-standard'/> @@ -422,7 +422,7 @@ As you can see below, I no longer have any unmanaged packages. :: Incorrect entries: 0 Total managed entries: 247 Unmanaged entries: 10 - Service:bcfg2 Service:fam Service:killprocs Service:rc.local Service:single + Service:bcfg2 Service:killprocs Service:rc.local Service:single Service:bcfg2-server Service:grub-common Service:ondemand Service:rsync Service:ssh Manage services @@ -436,7 +436,6 @@ entries to our bundle... <!-- basic services --> <Service name='bcfg2'/> <Service name='bcfg2-server'/> - <Service name='fam'/> <Service name='grub-common'/> <Service name='killprocs'/> <Service name='ondemand'/> @@ -455,7 +454,6 @@ entries to our bundle... <!-- basic services --> <Service type='deb' status='on' name='bcfg2'/> <Service type='deb' status='on' name='bcfg2-server'/> - <Service type='deb' status='on' name='fam'/> <Service type='deb' status='on' name='grub-common'/> <Service type='deb' status='on' name='killprocs'/> <Service type='deb' status='on' name='ondemand'/> diff --git a/doc/client/tools.txt b/doc/client/tools.txt index 1dbb33b1a..09ea76230 100644 --- a/doc/client/tools.txt +++ b/doc/client/tools.txt @@ -133,8 +133,6 @@ RPM Executes RPM to manage packages on Redhat-based and similar systems. Consider using the :ref:`YUM <client-tools-yum>` tool instead if possible. -Formerly called ``RPMng``, but was renamed for the 1.3 release. - SMF --- @@ -166,13 +164,5 @@ Upstart service support. Uses `Upstart`_ to configure services. YUM --- -Handles RPMs using the YUM package manager. Renamed from ``YUMng`` for -the 1.3 release. See :ref:`client-tools-yum` for more details. - -YUM24 ------ - -.. warning:: Deprecated in favor of :ref:`YUM <client-tools-yum>` - -Handles RPMs using older versions of the YUM package manager. - +Handles RPMs using the YUM package manager. See +:ref:`client-tools-yum` for more details. diff --git a/doc/client/tools/yum.txt b/doc/client/tools/yum.txt index 47ef3d5e9..ed1a3d5fd 100644 --- a/doc/client/tools/yum.txt +++ b/doc/client/tools/yum.txt @@ -7,9 +7,7 @@ Bcfg2 RPM/YUM Client Drivers ============================ The RPM and YUM client drivers provide client support for RPMs -(installed directly from URLs) and Yum repositories. These drivers -were formerly called ``RPMng`` and ``YUMng``, respectively, but were -renamed for Bcfg2 1.3.0. +(installed directly from URLs) and Yum repositories. Features ======== diff --git a/doc/development/cfg.txt b/doc/development/cfg.txt index c3b8d12af..71c455b52 100644 --- a/doc/development/cfg.txt +++ b/doc/development/cfg.txt @@ -80,18 +80,11 @@ Creators .. autoclass:: Bcfg2.Server.Plugins.Cfg.CfgPrivateKeyCreator.CfgPrivateKeyCreator .. autoclass:: Bcfg2.Server.Plugins.Cfg.CfgPublicKeyCreator.CfgPublicKeyCreator -Filters -------- - -.. autoclass:: Bcfg2.Server.Plugins.Cfg.CfgCatFilter.CfgCatFilter -.. autoclass:: Bcfg2.Server.Plugins.Cfg.CfgDiffFilter.CfgDiffFilter - Info Handlers ------------- .. autoclass:: Bcfg2.Server.Plugins.Cfg.CfgDefaultInfo .. autoclass:: Bcfg2.Server.Plugins.Cfg.CfgInfoXML.CfgInfoXML -.. autoclass:: Bcfg2.Server.Plugins.Cfg.CfgLegacyInfo.CfgLegacyInfo Verifiers --------- diff --git a/doc/development/fam.txt b/doc/development/fam.txt index c2c3b14f5..e967aaf68 100644 --- a/doc/development/fam.txt +++ b/doc/development/fam.txt @@ -56,11 +56,6 @@ Pseudo .. automodule:: Bcfg2.Server.FileMonitor.Pseudo -Fam ---- - -.. automodule:: Bcfg2.Server.FileMonitor.Fam - Gamin ----- diff --git a/doc/getting_started/index.txt b/doc/getting_started/index.txt index a9e91e6b8..5f84117d4 100644 --- a/doc/getting_started/index.txt +++ b/doc/getting_started/index.txt @@ -70,7 +70,7 @@ That can be translated as "bcfg2 quick verbose no-op". The output should be something similar to:: Loaded tool drivers: - Chkconfig POSIX YUMng + Chkconfig POSIX YUM Phase: initial Correct entries: 0 @@ -175,7 +175,7 @@ Next, we create a motd.xml file in the Bundler directory: Now when we run the client, we get slightly different output:: Loaded tool drivers: - Chkconfig POSIX YUMng + Chkconfig POSIX YUM Incomplete information for entry Path:/etc/motd; cannot verify Phase: initial @@ -205,7 +205,7 @@ real ``/etc/motd`` file to that location, run the client again, and you will find that we now have a correct entry:: Loaded tool drivers: - Chkconfig POSIX PostInstall RPM + Chkconfig POSIX Action RPM Phase: initial Correct entries: 1 diff --git a/doc/help/troubleshooting.txt b/doc/help/troubleshooting.txt index 35c1e93a2..c3abab9e7 100644 --- a/doc/help/troubleshooting.txt +++ b/doc/help/troubleshooting.txt @@ -69,13 +69,13 @@ included with the source distribution and all packages. If the bcfg2 server is not reflecting recent changes, try restarting the bcfg2-server process ============================================================================================= -If this fixes the problem, it is either a bug in the -underlying file monitoring system (fam or gamin) or a bug in -Bcfg2's file monitoring code. In either case, file a `ticket +If this fixes the problem, it is either a bug in the underlying file +monitoring system (inotify or gamin) or a bug in Bcfg2's file +monitoring code. In either case, file a `ticket <https://trac.mcs.anl.gov/projects/bcfg2/newticket>`_ in the tracking system. In the ticket, include: -* filesystem monitoring system (fam or gamin) +* filesystem monitoring system (inotify or gamin) * kernel version (if on linux) * if any messages of the form "Handled N events in M seconds" appeared between the modification event and the client @@ -259,8 +259,7 @@ Server Errors :ref:`server-info` file for this entry. .. [s11] Verify that you have the proper prefix set in bcfg2.conf. .. [s12] Ensure that the client is a member of all the appropriate - :ref:`server-plugins-generators-packages-magic-groups` as - well as any additional groups you may have defined in your + groups you may have defined in your :ref:`server-plugins-generators-packages` configuration. FAQs diff --git a/doc/installation/distributions.txt b/doc/installation/distributions.txt index 3dcfd7721..eccd6e723 100644 --- a/doc/installation/distributions.txt +++ b/doc/installation/distributions.txt @@ -73,7 +73,7 @@ to get it marked as stable. If you don't use portage to install Bcfg2, you'll want to make sure you have all the prerequisites installed first. For a server, you'll need: -* ``app-admin/gamin`` or ``app-admin/fam`` +* ``app-admin/gamin`` * ``dev-python/lxml`` Clients will need at least: diff --git a/doc/installation/prerequisites.txt b/doc/installation/prerequisites.txt index 0cb721bb9..eaa2a0393 100644 --- a/doc/installation/prerequisites.txt +++ b/doc/installation/prerequisites.txt @@ -50,9 +50,9 @@ Bcfg2 Server +-------------------------------+----------+--------------------------------+ | lxml | 0.9+ | lxml: libxml2, libxslt, python | +-------------------------------+----------+--------------------------------+ -| gamin or fam | Any | | +| gamin or inotify | Any | | +-------------------------------+----------+--------------------------------+ -| python-gamin or python-fam | Any | gamin or fam, python | +| python-gamin or pyinotify | Any | gamin or inotify, python | +-------------------------------+----------+--------------------------------+ | M2crypto or python-ssl (note | Any | python, openssl | | that the ssl module is | | | diff --git a/doc/reports/static.txt b/doc/reports/static.txt deleted file mode 100644 index 00c1867f8..000000000 --- a/doc/reports/static.txt +++ /dev/null @@ -1,100 +0,0 @@ -.. -*- mode: rst -*- - -.. _reports-static: - -============================= -Bcfg2 Static Reporting System -============================= - -The Bcfg2 reporting system collects and displays information about the -operation of the Bcfg2 client, and the configuration states of target -machines. - -Goals -===== - -The reporting system provides an interface to administrators describing -a few important tasks - -* Client configuration state, particularly aspects that do not match the configuration specification. - Information about bad and extra configuration elements is included. -* Client execution results (a list of configuration elements that were modified) -* Client execution performance data (including operation retry counts, and timings for several critical execution regions) - -This data can be used to understand the current configuration state -of the entire network, the operations performed by the client, how the -configuration changes propagate, and any reconfiguration operations that -have failed. - -Retention Model -=============== - -The current reporting system stores statistics in an XML data store, by -default to ``<repo>/etc/statistics.xml``. It retains either one or two -statistic sets per host. If the client has a clean configuration state, -the most recent (clean) record is retained. If the client has a dirty -configuration state, two records are retained. One record is the last -clean record. The other record is the most recent record collected, -detailing the incorrect state. - -This retention model, while non-optimal, does manage to persistently -record most of the data that users would like. - -Setup -===== - -In order to configure your Bcfg2 server for receiving reports, you -will need to list the Statistics plugin in the plugins line of your -``bcfg2.conf``. You will also need a [statistics] section -in your ``bcfg2.conf``. You can find out more about what goes there in the -``bcfg2.conf`` manpage. - -Output -====== - -Several output reports can be generated from the statistics store with -the command line tool ``bcfg2-build-reports``. - -* Nodes Digest -* Nodes Individual -* Overview Statistics -* Performance - -The data generated by these reports can be delivered by several -mechanisms: - -* HTML -* Email -* RSS - -Shortcomings and Planned Enhancements -===================================== - -When designing the current reporting system, we were overly concerned with -the potential explosion in data size over time. In order to address this, -we opted to use the retention scheme described above. This approach has -several shortcomings: - -* A comprehensive list of reconfiguration operations (with associated - timestamps) isn't retained -* Client results for any given day (except the last one) aren't uniformly - retained. This means that inter-client analysis is difficult, if - not impossible - -We plan to move to a database backend to address the dataset size -problem and start retaining all information. The move to a SQL backend -will allow many more types of queries to be efficiently processed. It -will also make on-demand reports simpler. - -Other sorts of information would also be useful to track. We plan to -add the ability to tag a particular configuration element as security -related, and include this in reports. This will aid in the effective -prioritization of manual and failed reconfiguration tasks. - -Capability Goals (posed as questions) -------------------------------------- - -* What machines have not yet applied critical updates? -* How long did critical updates take to be applied? -* What configuration did machine X have on a particular date? -* When did machine X perform configuration update Y? diff --git a/doc/server/admin/index.txt b/doc/server/admin/index.txt index ee03cedda..8ea765aac 100644 --- a/doc/server/admin/index.txt +++ b/doc/server/admin/index.txt @@ -24,7 +24,6 @@ functionality. Available modes are listed below. perf pull query - snapshots tidy viz xcmd diff --git a/doc/server/admin/snapshots.txt b/doc/server/admin/snapshots.txt deleted file mode 100644 index 25a7286c2..000000000 --- a/doc/server/admin/snapshots.txt +++ /dev/null @@ -1,8 +0,0 @@ -.. -*- mode: rst -*- - -.. _server-admin-snapshots: - -snapshots -========= - -Interact with the Snapshots system. diff --git a/doc/server/configuration.txt b/doc/server/configuration.txt index 2c5879ff0..be421207c 100644 --- a/doc/server/configuration.txt +++ b/doc/server/configuration.txt @@ -52,9 +52,7 @@ itself, which would prevent the ``bcfg2`` user from enabling a new plugin. If you depend on this capability (e.g., if your specification is stored in a VCS and checked out onto the Bcfg2 server by a script running as the ``bcfg2`` user), then you would want to ``chown`` and -``chmod`` ``/var/lib/bcfg2`` rather than ``/var/lib/bcfg2/*``. Note -also that the recursive ``chmod`` will change permissions on any files -that are using ``mode="inherit"`` in :ref:`server-info`. +``chmod`` ``/var/lib/bcfg2`` rather than ``/var/lib/bcfg2/*``. The Bcfg2 server also needs to be able to read its SSL certificate, key and the SSL CA certificate: diff --git a/doc/server/index.txt b/doc/server/index.txt index 2ccc9c923..42abb454c 100644 --- a/doc/server/index.txt +++ b/doc/server/index.txt @@ -26,7 +26,6 @@ clients. admin/index configurationentries info - snapshots/index bcfg2-info selinux configuration diff --git a/doc/server/info.txt b/doc/server/info.txt index b4d1f7113..2c50f0031 100644 --- a/doc/server/info.txt +++ b/doc/server/info.txt @@ -53,25 +53,3 @@ A more complex example for a template that generates both See :ref:`server-selinux` for more information on the ``secontext`` attribute and managing SELinux in general. - -:info and info files -==================== - -.. deprecated:: 1.3.0 - -Historically, Bcfg2 also accepted the use of ``:info`` and ``info`` -files, which function the same as ``info.xml``, but are not XML. They -lack the ability to specify different permissions based on client, -group, or path, and cannot be used to specify ACLs, either. - -An example ``:info`` or ``info`` file would look like:: - - owner: www - group: www - mode: 0755 - -All attributes allowed on the ``<Info>`` tag of an ``info.xml`` file -can be used in an ``:info`` or ``info`` file. - -You should not use more than one ``:info``, ``info``, or ``info.xml`` -file for a single entry. diff --git a/doc/server/plugins/generators/account.txt b/doc/server/plugins/generators/account.txt deleted file mode 100644 index 99c35c814..000000000 --- a/doc/server/plugins/generators/account.txt +++ /dev/null @@ -1,115 +0,0 @@ -.. -*- mode: rst -*- - -.. _server-plugins-generators-account: - -======= -Account -======= - -The account plugin manages authentication data, including - -* ``/etc/passwd`` -* ``/etc/group`` -* ``/etc/security/limits.conf`` -* ``/etc/sudoers`` -* ``/root/.ssh/authorized_keys`` - -User access data is stored in three files in the Account directory: - -* superusers (a list of users who always have root privs) -* 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). - -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. - -Files in the Account directory: - -``<username>.key`` - - **Format**: The SSH public key for user <username>. - - If the user is in the "rootlike" or "superusers" group, these - keys will be appended to ``/root/.ssh/auth`` - -``useraccess`` - - **Format**: "user:hostname" on each line. - - Describes who may login where (via PAMs - ``/etc/security/limits.conf``). Everybody else will be denied - access.(?) - - **Example**: - - If Alice should be able to access host "foo", Bob should access - "foo" and "bar":: - - alice:foo.example.com - bob:foo.example.com - bob:bar.example.com - -``rootlike`` - - **Format**: "user:hostname" on each line. - - Describes who will be allowed root access where. The user may - login via public key and use sudo. - - **Example**: - - If Chris should be root only on host "foo":: - - chris:foo.example.com - -``superusers`` - - **Format**: usernames, separated by spaces or newlines. (Any whitespace that makes pythons split() happy.) - - Describes who will be allowed root access on all hosts. The user - may login via public key and use sudo. - - **Example**: - - Daniel, Eve and Faith are global admins:: - - daniel eve - faith - -``static.passwd``, ``static.group`` - - **Format**: Lines from ``/etc/passwd`` or ``/etc/group`` - - These entries are appended to the passwd and group files - (in addition to the auto-generated entries from "useraccess", - "rootlike" and "superusers" above) without doing anything else. - -``dyn.passwd``, ``dyn.group`` - - **Format**: Lines from ``/etc/passwd`` or ``/etc/group`` - - Similar to "static.*" above, but for entries that are managed "on - the network" (yp, LDAP, ...), so it is most likely periodically - (re)filled. - -``static.limits.conf`` - - **Format**: Lines from ``/etc/security/limit.conf`` - - These limits will be appended to limits.conf (in addition to - the auto-generated entries from "useraccess", "rootlike" and - "superusers" above). - -``static.sudoers`` - - **Format**: Lines from ``/etc/sudoers`` - - These lines will be appended to to sudoers file (in addition - to the auto-generated entries from "useraccess", "rootlike" and - "superusers" above). diff --git a/doc/server/plugins/generators/cfg.txt b/doc/server/plugins/generators/cfg.txt index 1cb4b8727..8339c8080 100644 --- a/doc/server/plugins/generators/cfg.txt +++ b/doc/server/plugins/generators/cfg.txt @@ -102,9 +102,8 @@ Genshi Templates ---------------- 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.:: +<http://genshi.edgewall.org>`_ templating system. Genshi templates +should be named with a ``.genshi`` extension, e.g.:: % ls Cfg/etc/motd info.xml motd.genshi @@ -214,9 +213,8 @@ Cheetah Templates ----------------- 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.:: +<http://www.cheetahtemplate.org/>`_. Cheetah templates should be +named with a ``.cheetah`` extension, e.g.:: % ls Cfg/etc/motd info.xml motd.cheetah @@ -586,73 +584,6 @@ influenced by several options in the ``[sshkeys]`` section of See :ref:`server-encryption` for more details on encryption in Bcfg2 in general. -Deltas -====== - -.. note:: - - In Bcfg2 1.3 and newer, deltas are deprecated. It is recommended - that you use templates instead. The - :ref:`TemplateHelper plugin - <server-plugins-connectors-templatehelper>` comes with an example - helper that can be used to include other files easily, a subset of - cat file functionality. ``bcfg2-lint`` checks for deltas and - warns about them. - -Bcfg2 has finer grained control over how to deliver configuration -files to a host. Let's say we have a Group named file-server. Members -of this group need the exact same ``/etc/motd`` as all other hosts except -they need one line added. We could copy motd to ``motd.G01_file-server``, -add the one line to the Group specific version and be done with it, -but we're duplicating data in both files. What happens if we need to -update the motd? We'll need to remember to update both files then. Here's -where deltas come in. A delta is a small change to the base file. There -are two types of deltas: cats and diffs. The cat delta simply adds or -removes lines from the base file. The diff delta is more powerful since -it can take a unified diff and apply it to the base configuration file -to create the specialized file. Diff deltas should be used very sparingly. - -Cat Files ---------- - -Continuing our example for cat files, we would first create a file named -``motd.G01_file-server.cat``. The .cat suffix designates that the file is -a diff. We would then edit that file and add the following line:: - - +This is a file server - -The **+** at the begining of the file tells Bcfg2 that the line should be -appended to end of the file. You can also start a line with **-** to tell -Bcfg2 to remove that exact line wherever it might be in the file. How do -we know what base file Bcfg2 will choose to use to apply a delta? The -same rules apply as before: Bcfg2 will choose the highest priority, -most specific file as the base and then apply deltas in the order of -most specific and then increasing in priority. What does this mean in -real life. Let's say our machine is a web server, mail server, and file -server and we have the following configuration files:: - - motd - motd.G01_web-server - motd.G01_mail-server.cat - motd.G02_file-server.cat - motd.H_foo.example.com.cat - -If our machine **isn't** *foo.example.com* then here's what would happen: - -Bcfg2 would choose ``motd.G01_web-server`` as the base file. It is -the most specific base file for this host. Bcfg2 would apply the -``motd.G01_mail-server.cat`` delta to the ``motd.G01_web-server`` -base file. It is the least specific delta. Bcfg2 would then apply the -``motd.G02_file-server.cat`` delta to the result of the delta before -it. If our machine **is** *foo.example.com* then here's what would happen: - -Bcfg2 would choose ``motd.G01_web-server`` as the base file. It -is the most specific base file for this host. Bcfg2 would apply the -``motd.H_foo.example.com.cat`` delta to the ``motd.G01_web-server`` base -file. The reason the other deltas aren't applied to *foo.example.com* -is because a **.H_** delta is more specific than a **.G##_** delta. Bcfg2 -applies all the deltas at the most specific level. - .. _server-plugins-generators-cfg-validation: Content Validation diff --git a/doc/server/plugins/generators/hostbase.txt b/doc/server/plugins/generators/hostbase.txt deleted file mode 100644 index c6007f70e..000000000 --- a/doc/server/plugins/generators/hostbase.txt +++ /dev/null @@ -1,228 +0,0 @@ -.. -*- mode: rst -*- - -.. _server-plugins-generators-hostbase: - -======== -Hostbase -======== - -IP management system built on top of Bcfg2. It has four main parts: a -django data model, a web frontend, command-line utilities, and a Bcfg2 -plugin that generates dhcp, dns, and yp configuration files. - -Installation -============ - -Installation of Hostbase requires installation of a python module, -configuration of database (mysql or postgres), and configuration of an -Apache webserver with mod_python. Hostbase was developed using MySQL, -so this document is aimed at MySQL users. - -Prerequisites -------------- - -* `mysql`_ -* `python-mysqldb`_ -* `Django`_ - -.. _Django: http://www.djangoproject.com -.. _python-mysqldb: http://mysql-python.sourceforge.net/MySQLdb.html -.. _mysql: http://www.mysql.com/ - -Configure the database ----------------------- - -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 - BY 'password' WITH GRANT OPTION; - mysql> quit - -As of Bcfg2 v0.8.7 configuration options for Hostbase have moved to -``/etc/bcfg2.conf``. There is an example bcfg2.conf with Hostbase -options located at ``bcfg2-tarball/examples/bcfg2.confHostbase``. -Edit the hostbase options to correspond to the database you've -initialized and copy the configuration to ``/etc/bcfg2.conf``. To -finish creating the database, from your ``path to -python/Bcfg2/Server/Hostbase`` directory, run ``python manage.py -syncdb`` to do all table creation. - -Configure the web interface ---------------------------- - -Now it's possible to explore the Hostbase web interface. For -curiosity, you can run Django's built-in development server to take a -peek. Do this by running ``python manage.py runserver -[servername:port]`` from your Hostbase directory. Django will -default to ``localhost:8000`` if no server or port is entered. Now -you can explore the web interface. Try adding a host and a zone. -You'll see that a ".rev" zone already exists. This is where -information for reverse files will go. - -For production, you'll want to have this configured for Apache with -mod_python. Here is an example of how to configure Hostbase as a -virtual host. - -.. code-block:: html - - <VirtualHost hostbase.mcs.anl.gov:80> - ServerAdmin systems@mcs.anl.gov - - DocumentRoot /var/www/hostbase/ - <Directory /> - AllowOverride None - </Directory> - - # Possible values include: debug, info, notice, warn, error, crit, - # alert, emerg. - LogLevel warn - - ServerSignature Off - - # Stop TRACE/TRACK vulnerability - <IfModule mod_rewrite.c> - RewriteEngine on - RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) - RewriteRule .* - [F] - </IfModule> - - Redirect / https://hostbase.mcs.anl.gov/ - </VirtualHost> - - <VirtualHost hostbase.mcs.anl.gov:443> - ServerAdmin systems@mcs.anl.gov - - DocumentRoot /var/www/hostbase/ - <Directory /> - AllowOverride None - </Directory> - - # Possible values include: debug, info, notice, warn, error, crit, - # alert, emerg. - LogLevel warn - - ServerSignature Off - - # Stop TRACE/TRACK vulnerability - <IfModule mod_rewrite.c> - RewriteEngine on - RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) - RewriteRule .* - [F] - </IfModule> - - SSLEngine On - SSLCertificateFile /etc/apache2/ssl/hostbase_server.crt - SSLCertificateKeyfile /etc/apache2/ssl/hostbase_server.key - - <Location "/"> - SetHandler python-program - PythonHandler django.core.handlers.modpython - SetEnv DJANGO_SETTINGS_MODULE Bcfg2.Server.Hostbase.settings - PythonDebug On - </Location> - <Location "/site_media/"> - SetHandler None - </Location> - </VirtualHost> - - -You'll need to copy the contents of ``Hostbase/media`` into -``/var/www/hostbase/site_media`` in this configuration to serve the -correct css files. - -Enable the Hostbase plugin --------------------------- - -Now that the database is accessible and there is some data in it, you can -enable the Hostbase plugin on your Bcfg2 server to start generating some -configuration files. All that needs to be done is to add ``Hostbase`` -to the end of the list of generators in your bcfg2.conf file. To see -what's being generated by Hostbase, fire up a Bcfg2 development server: -``bcfg2-info``. For more information on how to use the Bcfg2 development -server, type help at the prompt. For our purposes, type ``debug``. -This will bring you to an interactive python prompt where you can access -bcfg's core data. - -.. code-block:: python - - for each in bcore.plugins['Hostbase'].filedata: - print each - - -The above loop will print out the name of each file that was generated -by Hostbase. You can see the contents of any of these by typing ``print -bcore.plugins['Hostbase'].filedata[filename]``. - -Create a bundle ---------------- - -Bcfg2 needs a way to distribute the files generated by Hostbase. -We'll do this with a bundle. In bcfg's ``Bundler`` directory, touch -``hostbase.xml``. - -.. code-block:: xml - - <Bundle name='hostbase' version='0.1'> - <Package name='dhcp3-server'/> - <Package name='bind9'/> - <Service name='dhcp3-server'/> - <Service name='bind9'/> - <Path name='/etc/dhcp3/dhcpd.conf'/> - <Path name='/etc/bind/[your domain]'/> - <Path name='/etc/bind/xxx.xxx.xxx.rev'/> - </Bundle> - -The above example is a bundle that will deliver both dhcp and dns files. -This can be trivially split into separate bundles. It is planned that -Hostbase will eventually be able to generate the list of ``Paths`` -in its bundles automatically. - -Do a Hostbase push ------------------- - -You'll want to be able to trigger the Hostbase plugin to rebuild -it's config files and push them out when data has been modified -in the database. This can be done through and XMLRPC function -available from the Bcfg2 server. From a client that is configured -to receive one or more hostbase bundles, you'll need to first -edit your ``python/site-packages/Bcfg2/Client/Proxy.py`` file. -Add ``'Hostbase.rebuildState'`` to the list of methods in the Bcfg2 -client proxy object. The modified list is shown below: - -.. code-block:: python - - class bcfg2(ComponentProxy): - '''bcfg2 client code''' - name = 'bcfg2' - methods = ['AssertProfile', 'GetConfig', 'GetProbes', 'RecvProbeData', 'RecvStats', 'Hostbase.rebuildState'] - -Now copy the file ``hostbasepush.py`` from ``bcfg2/tools`` in the Bcfg2 -source to your machine. When this command is run as root, it triggers -the Hostbase to rebuild it's files, then runs the Bcfg2 client on your -local machine to grab the new configs. - -NIS Authentication -================== - -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* -* enter the name of the unix group you want to give access to Hostbase - in the *AUTHORIZED_GROUP* variable -* in your ``Hostbase/hostbase/views.py`` file at the very bottom, - uncomment the block(s) of lines that give you the desired level - of access - -Hostbase will now direct the user to a login page if he or she is not -authorized to view a certain page. Users should log in with their -regular Unix username and password. diff --git a/doc/server/plugins/generators/packages.txt b/doc/server/plugins/generators/packages.txt index e45864ef9..a7987260a 100644 --- a/doc/server/plugins/generators/packages.txt +++ b/doc/server/plugins/generators/packages.txt @@ -18,14 +18,10 @@ through those channels. Limiting sources to groups ========================== -`sources.xml`_ processes ``<Group>`` and ``<Client>`` tags just like -Bundles. In addition to any groups or clients specified that way, -clients must be a member of the appropriate architecture group as -specified in a Source stanza. In total, in order for a source to be -associated with a client, the client must be in any explicit groups or -clients specified in `sources.xml`_, and any specified architecture -groups. If `"Magic Groups"`_ are enabled, then the client must be a -member of a matching magic group as well. +``Packages/sources.xml`` processes ``<Group>`` and ``<Client>`` tags +just like Bundles. In addition to any groups or clients specified that +way, clients must be a member of the appropriate architecture group as +specified in a Source stanza. Memberships in architecture groups is needed so that Packages can map software sources to clients. There is no other way to handle this than @@ -36,62 +32,6 @@ 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 - `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: - -"Magic Groups" -============== - -.. deprecated:: 1.3.0 - -Packages has the ability to use a feature known as "magic groups"; it -is the only plugin to use that feature. Most plugins operate based on -client group memberships, without any concern for the particular names -chosen for groups by the user. The Packages plugin is the sole -exception to this rule. Packages needs to "know" two different sorts -of facts about clients. The first is the basic OS/distro of the -client, enabling classes of sources. The second is the architecture of -the client, enabling sources for a given architecture. In addition to -these magic groups, each source may also specify non-magic groups to -limit the source's applicability to group member clients. - -+--------+----------+--------------+ -| Source | OS Group | Architecture | -+========+==========+==============+ -| Apt | debian | i386 | -+--------+----------+--------------+ -| Apt | ubuntu | amd64 | -+--------+----------+--------------+ -| Apt | nexenta | | -+--------+----------+--------------+ -| Apt | apt | | -+--------+----------+--------------+ -| Yum | redhat | i386 | -+--------+----------+--------------+ -| Yum | centos | x86_64 | -+--------+----------+--------------+ -| Yum | fedora | | -+--------+----------+--------------+ -| Yum | yum | | -+--------+----------+--------------+ - -Magic OS groups are disabled by default in Bcfg2 1.3 and greater. If -you require magic groups, you can enable them by setting -``magic_groups`` to ``1`` in the ``[packages]`` section of -``bcfg2.conf``. - -Magic groups will be removed in a future release. - -Magic architecture groups cannot be disabled. - Setup ===== @@ -102,14 +42,13 @@ Three basic steps are required for Packages to work properly. software repositories should be used, and which clients are eligible to use each one. #. Ensure that clients are members of the proper groups. Each client - should be a member of all of the groups listed in the `sources.xml` - (like ubuntu-intrepid or centos-5.2 in the following examples), one - of the architecture groups listed in the source configuration - (i386, amd64 or x86_64 in the following examples), and one of the - magic groups listed above, if magic groups are enabled. '''Failure - to do this will result in the source either not applying to the - client, or only architecture independent packages being made - available to the client.''' + should be a member of all of the groups listed in the + ``sources.xml`` (like ubuntu-intrepid or centos-5.2 in the + following examples), and one of the architecture groups listed in + the source configuration (i386, amd64 or x86_64 in the following + examples). '''Failure to do this will result in the source either + not applying to the client, or only architecture independent + packages being made available to the client.''' #. Add Package entries to bundles. #. Sit back and relax, as dependencies are resolved, and automatically added to client configurations. diff --git a/doc/server/plugins/generators/tcheetah.txt b/doc/server/plugins/generators/tcheetah.txt deleted file mode 100644 index ab147ce56..000000000 --- a/doc/server/plugins/generators/tcheetah.txt +++ /dev/null @@ -1,197 +0,0 @@ -.. -*- mode: rst -*- - -.. _server-plugins-generators-tcheetah: - -======== -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 -<http://www.cheetahtemplate.org/>`_ to create files, instead of the -various diff-based methods offered by the ``Cfg`` plugin. It also allows -you to include the results of probes executed on the client in the -created files. - -To begin, you will need to download and install the Cheetah templating -engine from http://www.cheetahtemplate.org/. Once it is installed, -you can enable it by adding ``TCheetah`` to the ``plugins`` line in -``/etc/bcfg2.conf`` on your Bcfg server. For example:: - - plugins = Base,Bundler,Cfg,...,TCheetah - -The ``TCheetah`` plugin makes use of a ``Cfg``-like directory structure -located in in a ``TCheetah`` subdirectory of your repository, usually -``/var/lib/bcfg2/TCheetah``. Each file has a directory containing two -files, ``template`` and ``info``. The template is a standard Cheetah -template with two additions: - -* `self.metadata` is the client's :ref:`metadata <server-plugins-grouping-metadata-clientmetadata>` -* `self.metadata.Properties.xdata` is an xml document of unstructured data - -The ``info`` file is formatted like ``:info`` files from Cfg. - -Mostly, people will want to use client metadata. - -File permissions -================ - -File permissions for entries handled by TCheetah are controlled via the -use of :ref:`server-info` files. Note that you **cannot** use both a -Permissions entry and a Path entry to handle the same file. - -self.metadata variables -======================= - -self.metadata is an instance of the class ClientMetadata and documented -:ref:`here <server-plugins-grouping-metadata-clientmetadata>`. - -self.metadata.Properties.xdata -============================== - -.. note:: - - If you want to use Properties, you will need to enable the - :ref:`server-plugins-connectors-properties` plugin in - ``/etc/bcfg2.conf``. - -Properties.xdata is a python `ElementTree <http://codespeak.net/lxml/>`_ -object, loaded from the data in ``/var/lib/bcfg2/Properties/<properties -file>.xml``. That file should have a ``Properties`` node at its root. - -Example ``Properties/example.xml``: - -.. code-block:: xml - - <Properties> - <host> - <www.example.com> - <rootdev>/dev/sda</rootdev> - </www.example.com> - </host> - </Properties> - -You may use any of the ElementTree methods to access data in your -template. Several examples follow, each producing an identical result -on the host 'www.example.com':: - - $self.metadata.Properties['example.xml'].xdata.find('host').find('www.example.com').find('rootdev').text - $self.metadata.Properties['example.xml'].xdata.find('host').find($self.metadata.hostname).find('rootdev').text - ${self.metadata.Properties['example.xml'].xdata.xpath('host/www.example.com/rootdev')[0].text} - ${self.metadata.Properties['example.xml'].xdata.xpath('host/' + self.metadata.hostname + '/rootdev')[0].text} - #set $path = 'host/' + $self.metadata.hostname + '/rootdev' - ${self.metadata.Properties['example.xml'].xdata.xpath($path)[0].text} - ${self.metadata.Properties['example.xml'].xdata.xpath(path)[0].text} - -Other Variables -=============== - -* **Template.searchList(self)[1]['path']** is the Path name specified in a Bundle -* **Template.searchList(self)[1]['source_path']** is the path to the TCheetah template on the Bcfg2 server - -Simple Example -============== - -TCheetah works similar to Cfg in that you define all literal information -about a particular file in a directory rooted at TGenshi/path_to_file. -The actual file contents are placed in a file named `template` in that -directory. Below is a simple example a file ``/foo``. - -``/var/lib/bcfg2/TCheetah/foo/template`` - -.. code-block:: none - - > buildfile /foo <clientname> - Hostname is $self.metadata.hostname - Filename is $Template.searchList(self)[1]['path'] - Template is $Template.searchList(self)[1]['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 - -``/var/lib/bcfg2/TCheetah/foo/info`` - -.. code-block:: none - - mode: 624 - -Output ------- - -The following output can be generated with bcfg2-info. Note that probe -information is not persistent, hence, it only works when clients directly -query the server. For this reason, bcfg2-info output doesn't reflect -current client probe state. - -.. code-block:: xml - - <Path type="file" name="/foo" owner="root" mode="0624" group="root"> - Hostname is topaz.mcs.anl.gov - Filename is /foo - Template is /var/lib/bcfg2/TCheetah/foo/template - Groups: - * desktop - * mcs-base - * ypbound - * workstation - * xserver - * debian-sarge - * debian - * a - Categories: - * test -- a - - Probes: - </Path> - -Example: Replace the crontab plugin -=================================== - -In many cases you can use the TCheetah plugin to avoid writing custom -plugins in Python. 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. - -.. note:: 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. diff --git a/doc/server/plugins/generators/tgenshi.txt b/doc/server/plugins/generators/tgenshi.txt deleted file mode 100644 index 43a02f253..000000000 --- a/doc/server/plugins/generators/tgenshi.txt +++ /dev/null @@ -1,213 +0,0 @@ -.. -*- mode: rst -*- - -.. _server-plugins-generators-tgenshi-index: - -======= -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. - -The TGenshi plugin allows you to use the `Genshi -<http://genshi.edgewall.org>`_ templating system to create files, -instead of the various diff-based methods offered by the Cfg -plugin. It also allows you to include the results of probes executed -on the client in the created files. - -To begin, you will need to download and install the Genshi templating engine. - -To install on CentOS or RHEL, run:: - - sudo yum install python-genshi - -Once it is installed, you can enable it by adding ``TGenshi`` to the -generators line in ``/etc/bcfg2.conf`` on your Bcfg server. For example:: - - plugins = Base,Bundler,Cfg,...,TGenshi - -The TGenshi plugin makes use of a Cfg-like directory structure -located in in a TGenshi subdirectory of your repository, usually -``/var/lib/bcfg2/TGenshi``. Each file has a directory containing two file -types, template and info. Templates are named according to the genshi -format used; template.txt uses the genshi text format, and template.xml -uses the XML format. - -If used with Genshi 0.5 or later the plugin also supports the `new -style -<http://genshi.edgewall.org/wiki/Documentation/0.5.x/text-templates.html>`_ -text template format for files named template.newtxt. One of the -advantages of the new format is that it does not use # as a command -delimiter, making it easier to utilize for configuration files that -use # as a comment character. - -Only one template format may be used per file served. Info files are -identical to those used in ``Cfg``, and ``info.xml`` files are -supported. - -Inside of templates -=================== - -* **metadata** is the client's :ref:`metadata - <server-plugins-grouping-metadata-clientmetadata>` -* **metadata.Properties** is an xml document of unstructured data (only - available when used in conjunction with the - :ref:`server-plugins-connectors-properties` plugin) -* **name** is the path name specified in bcfg -* **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`` - -See the genshi `documentation -<http://genshi.edgewall.org/wiki/Documentation>`_ for examples of -Genshi syntax. - -Examples: Old Genshi Syntax ---------------------------- - -Genshi's web pages recommend against using this syntax, as it may -disappear from future releases. - -Group Negation -^^^^^^^^^^^^^^ - -Templates are also useful for cases where more sophisticated boolean -operations than those supported by Cfg are needed. For example, the -template:: - - #if "ypbound" in metadata.groups and "workstation" in metadata.groups - client is ypbound workstation - #end - #if "ubuntu" not in metadata.groups and "desktop" in metadata.groups - client is a desktop, but not an ubuntu desktop - #end - -Produces: - -.. code-block:: xml - - <Path type="file" name="/bar.conf" owner="root" mode="0644" group="root">client is ypbound workstation - client is a desktop, but not an ubuntu desktop - </Path> - -This flexibility provides the ability to build much more compact and -succinct definitions of configuration contents than Cfg can. - -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 of -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" - -File permissions -================ - -File permissions for entries handled by TGenshi are controlled via the -use of :ref:`server-info` files. Note that you **cannot** use both a -Permissions entry and a Path entry to handle the same file. - -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. - -FAQs -==== - -**Question** - -How do I escape the $ (dollar sign) in a TGenshi text template? For -example, if I want to include SVN (subversion) keywords like $Id$ or -$HeadURL$ in TGenshi-generated files, or am templating a bourne shell -(sh/bash) script or Makefile (make). - -**Answer** - -Use $$ (double dollar sign) to output a literal $ (dollarsign) -in a TGenshi text template. So instead of $Id$, you'd use -$$Id$$. See also Genshi tickets `#282: Document $$ escape -convention <http://genshi.edgewall.org/ticket/282>`_ and -`#283: Allow for redefinition of template syntax per-file -<http://genshi.edgewall.org/ticket/283>`_. - -Examples -======== - -.. toctree:: - :glob: - :maxdepth: 1 - - examples/genshi/* diff --git a/doc/server/plugins/statistics/statistics.txt b/doc/server/plugins/statistics/statistics.txt deleted file mode 100644 index d16f5a828..000000000 --- a/doc/server/plugins/statistics/statistics.txt +++ /dev/null @@ -1,7 +0,0 @@ -.. -*- mode: rst -*- - -.. _server-plugins-statistics-statistics: - -========== -Statistics -========== diff --git a/doc/server/plugins/structures/bundler/kernel.txt b/doc/server/plugins/structures/bundler/kernel.txt index 2e3d84e93..c6aa5e3f3 100644 --- a/doc/server/plugins/structures/bundler/kernel.txt +++ b/doc/server/plugins/structures/bundler/kernel.txt @@ -30,7 +30,7 @@ some of which might be better than this one. Feel free to hack as needed. <Path name='/boot/initrd'/> <Path name='/boot/vmlinuz.old'/> <Path name='/boot/initrd.old'/> - <PostInstall name='/sbin/lilo'/> + <Action name='lilo'/> <!-- Current kernel --> <Package name='linux-2.4.21-314.tg1'/> <Package name='linux-2.4.21-314.tg1-source'/> diff --git a/doc/server/snapshots/index.txt b/doc/server/snapshots/index.txt deleted file mode 100644 index 13a9fe2c0..000000000 --- a/doc/server/snapshots/index.txt +++ /dev/null @@ -1,156 +0,0 @@ -.. -*- mode: rst -*- - -.. _server-snapshots-index: - -=============== -Bcfg2 Snapshots -=============== - -.. versionadded:: 1.0.0 - -This page describes the Snapshots plugin. This plugin is meant to replace -the older :ref:`reports-dynamic`. It stores various aspects of a client's -state when the client checks into the server. - -Before you begin -================ - -Make sure you have version 0.5 or greater of sqlalchemy. - -On CentOS/RHEL 5 ----------------- - -* Download a tarball of SQLAlchemy. -* Extract and build the RPM:: - - tar xzf SQLAlchemy-0.5.6.tar.gz - cd SQLAlchemy-0.5.6 - python setup.py bdist_rpm - -* Copy the RPM in ``SQLAlchemy-0.5.6/dist/`` to your Yum repository, - and rebuild the repository using ``createrepo``. -* Clear the Yum cache:: - - sudo yum clean all - -* Install SQLAlchemy:: - - sudo yum install SQLAlchemy - -* Manage the package in Bcfg2 as you would any other package. - -Configuration -============= - -* A database location needs to be added to ``bcfg2.conf``. Three drivers - are currently supported; mysql, postgres, and sqlite. When using the - sqlite driver, only the driver and database lines are required. - - * For MySQL:: - - [snapshots] - driver = mysql - database = snapshots - user = snapshots - password = snapshots - host = dbserver - - * For SQLite:: - - [snapshots] - driver = sqlite - database = /var/lib/bcfg2/var/snapshots.sqlite - -* The database needs to be initialized.:: - - $ bcfg2-admin snapshots init - 2009-03-22 21:40:24,683 INFO sqlalchemy.engine.base.Engine.0x...3e2c PRAGMA table_info("connkeyval") - PRAGMA table_info("connkeyval") - 2009-03-22 21:40:24,684 INFO sqlalchemy.engine.base.Engine.0x...3e2c () - () - 2009-03-22 21:40:24,686 INFO sqlalchemy.engine.base.Engine.0x...3e2c PRAGMA table_info("package") - PRAGMA table_info("package") - 2009-03-22 21:40:24,687 INFO sqlalchemy.engine.base.Engine.0x...3e2c () - () - ..... - COMMIT - -* The Snapshots plugin needs to be enabled for the bcfg2-server (by adding - Snapshots to the plugins line in ``/etc/bcfg2.conf``). Once done, - this will cause the the server to store statistics information when - clients run. - -Using the reports interface -=========================== - -All hosts:: - - $ bcfg2-admin snapshots reports -a - - ============= ========= ========================================== ============================ - Client Correct Revision Time - ============= ========= ========================================== ============================ - bcfg2client True f46ac7773712bd3c3cfb765ae5d2a3b2a37ac9b7 2009-04-23 11:27:54.378941 - ============= ========= ========================================== ============================ - -List bad entries for a single host:: - - $ bcfg2-admin snapshots reports -b bcfg2client - Bad entries: - Package:nscd - Package:cupsys - File:/etc/ldap.conf - -List extra entries for a single host:: - - $ bcfg2-admin snapshots reports -e bcfg2client - Extra entries: - Package:python-pyxattr - Package:librsync1 - Package:python-pylibacl - Package:gcc-4.2-multilib - Package:nxlibs - Package:freenx-session-launcher - Package:dx-doc - Package:dirdiff - Package:libhdf4g - Package:nxclient - Package:freenx-rdp - Package:freenx-vnc - Package:libxml2-dev - Package:mysql-client - Package:mysql-client-5.0 - Package:libxcompext3 - Package:lib32gomp1 - Package:dx - Package:freenx-media - Package:dxsamples - Package:gcc-multilib - Package:rdiff-backup - Package:libdbd-mysql-perl - Package:libxcomp3 - Package:freenx-server - Package:smbfs - Package:planner - Package:nxagent - Package:libc6-dev-i386 - Package:libfltk1.1-dev - Package:freenx - Package:libdx4 - Package:libxcompshad3 - Service:freenx-server - -Detailed view of hosts for a particular date:: - - $ bcfg2-admin snapshots reports --date 2009 5 30 - ============= ========= ========================================== ============================ - Client Correct Revision Time - ============= ========= ========================================== ============================ - bcfg2client False 10c1a12c62c57c0861cc453b8d2640c4839a7357 2009-05-29 10:52:34.701056 - -TODO/Wishlist -============= - -* Identify per-client changes in correctness over time -* Detailed view for a particular date -* Track entry changes over time (glibc updated on these dates to these versions) diff --git a/doc/unsorted/index.txt b/doc/unsorted/index.txt index a369ee1b3..74d045990 100644 --- a/doc/unsorted/index.txt +++ b/doc/unsorted/index.txt @@ -13,7 +13,6 @@ list below. .. _TitleIndex: https://trac.mcs.anl.gov/projects/bcfg2/wiki/TitleIndex -* `Plugins/Snapshots` * `PrecompiledPackages` * `SchemaEvolution` * `SecurityDevPlan` |