.. -*- mode: rst -*-
.. _unsorted-annotated_examples:
==================
Annotated Examples
==================
ntp example
===========
Author: Jason Pepas
Here is a series of example configurations for bcfg2, each introducing
another layer of functionality.
* After each change, run 'bcfg-repo-validate -v'.
* Run the server with 'bcfg2-server -v'.
* Update the client with 'bcfg2 -v -d -n'. (will not actually make client changes)
package only
------------
Our example starts with the bare minimum configuration setup. We have
a client, a profile group, a list of packages, and a base configuration.
::
# cat Metadata/clients.xml
# cat Metadata/groups.xml
# cat Base/base.xml
# cat Pkgmgr/packages.xml
add service
-----------
Configure the service, and add it to the base.::
# cat Svcmgr/services.xml
# cat Base/base.xml
add config file
---------------
Setup an etc directory structure, and add it to the base.::
# cat Cfg/etc/ntp.conf/ntp.conf
server ntp1.utexas.edu
# cat Base/base.xml
create a bundle
---------------
The above configuration layout works fine for a single service, but
that method of organization would quickly become a nightmare as you
approach the number of packages, services, and config files required to
represent a fully configured host. Bundles allow the grouping of related
configuration entries that are used to provide a single service. This
is done for several reasons:
* Grouping related things in one place makes it easier to add those
entries for a multiple groups of clients
* Grouping entries into bundles makes their validation occur
collectively. This means that config files can override the
contents of packages. Also, config files are rechecked after
packages are upgraded, so that they can be repaired if the package
install clobbered them.
* Services associated with a bundle get restarted whenever any
entity in that bundle is modified. This ensures that new
configuration files and software are used after installation.
The config file, package, and service are really all related components
describing the idea of an ntp client, so they should be logically
grouped together. We use a bundle to accomplish this.::
# cat Bundler/ntp.xml
After this bundle is created, it must be associated with a group (or
groups). Add a bundle child element to the group(s) which should install
this bundle.::
# cat Metadata/groups.xml
...
...
Once this bundle is created, a client reconfigure will install these
entries. If any are modified, then the ntpd service will be
restarted. If you only want ntp configurations to be updated (and
nothing else), the bcfg2 client can be run with a -b
option that will only update entries in the specified bundle.
mysql example
=============
Author: Patrick Ruckstuhl
I had some time ago to continue with putting my configuration into
bcfg2 and maybe this helps someone else.
I added a new bundle:
.. code-block: xml
The `users.sh` script looks like this:
.. code-block: sh
#!/bin/sh
mysql --defaults-extra-file=/etc/mysql/debian.cnf mysql \
< /root/bcfg2-install/mysql/users.sql
On debian there is a user account in ``/etc/mysql/debian.cnf``
automatically created, but you could also (manually) create a user in
the database that has enough permissions and add the login information
in a file yourself. This file looks like this::
[client]
host = localhost
user = debian-sys-maint
password = XXXXXXXXXX
The ``users.sql`` looks like this::
DELETE FROM db;
INSERT INTO db VALUES ('localhost', 'phpmyadmin', 'pma', 'Y', 'Y',
'Y', 'Y', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N');
DELETE FROM user WHERE User <> 'debian-sys-maint';
INSERT INTO user VALUES ('localhost', 'root', 'XXXXXXXXXXX', 'Y', 'Y',
'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y',
'Y', 'Y', 'Y', 'Y', 'Y', '', '', '', '', 0, 0, 0);
INSERT INTO user VALUES ('localhost', 'pma', '', 'N', 'N', 'N', 'N',
'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N',
'N', 'N', 'N', '', '', '', '', 0, 0, 0);
FLUSH PRIVILEGES;