Changes between Version 8 and Version 9 of TracNav

Timestamp:

04/27/10 04:57:34 (13 years ago)

Author:

http://fab.id.fedoraproject.org/

Comment:

some minor changes

TracNav

@@ -6 +6 @@
 machines and diverse architectures. The ultimate goal of
 configuration management is to make machines as consistent, easily
-manageable, and up to date as possible. This document describes a typical installation of bcfg2.
+manageable, and up to date as possible. This document describes a
+typical installation of Bcfg2.
 
 == Bcfg2 Server ==
 
 Each deployment will have a central bcfg2 server.
-This machine runs
-the Bcfg2 server daemon as well as keeps the Bcfg2 configuration
+This machine runs the Bcfg2 server daemon as well as keeps the Bcfg2 configuration
 repository as well as serving package data when needed. The server uses XML-RPC
 for its communications and this channel is encrypted using SSL. The
-Bcfg2 server and client get the connection information from the /etc/
-bcfg2.conf configuration file. An example /etc/bcfg2.conf looks like:
+Bcfg2 server and client get the connection information from the `/etc/
+bcfg2.conf` configuration file. An example `/etc/bcfg2.conf` looks like:
 
 {{{
 [server]
-repository = /var/db/bcfg
+repository = /var/lib/bcfg2
 structures = Bundler,Base
-generators = SSHbase,Cfg,Pkgmgr,Svcmgr,TCheetah
-metadata = /var/db/bcfg/etc
+generators = SSHbase,Cfg,Pkgmgr,Rules
+# Uncomment to use the DBStats plugin (0.9.6pre2 and later)
+plugins = DBStats
 
 [statistics]
-sendmailpath = /usr/sbin/sendmail
+sendmailpath = /usr/lib/sendmail
+database_engine = sqlite3
+# 'postgresql', 'mysql', 'mysql_old', 'sqlite3' or 'ado_mssql'.
+database_name =
+# Or path to database file if using sqlite3.
+#<repository>/etc/brpt.sqlite is default path if left empty
+database_user =
+# Not used with sqlite3.
+database_password =
+# Not used with sqlite3.
+database_host =
+# Not used with sqlite3.
+database_port =
+# Set to empty string for default. Not used with sqlite3.
+web_debug = True
 
 [communication]
 protocol = xmlrpc/ssl
-password = verysecret
-key = /usr/share/ssl/bcfg2/server-key.pem
+password = PASSWORD
+key = /etc/bcfg2.key
+# fingerprint of server (from bcfg2-admin fingerprint)
+#fingerprint = [server fingerprint]
 
 [components]
@@ -53 +70 @@
 A config file
 Service
-A service to start or stop on boot (usually kept in /etc/init.d)
+A service to start or stop on boot (usually kept in `/etc/init.d/`)
 Directory
 A directory that should be present
@@ -76 +93 @@
 
 Here we can see that for the Group rhel, the syslog Bundle contains a
-!ConfigFile element /etc/syslog.conf, a Package element sysklogd, and
+!ConfigFile element `/etc/syslog.conf`, a Package element sysklogd, and
 a Service element syslog. This defines a relationship between all
 these elements, so that if one of these changes, examination of all
 the elements should be taken more closely. For example, say you
-update the /etc/syslog.conf file. Once it's been updated the syslog
+update the `/etc/syslog.conf` file. Once it's been updated the syslog
 service should be restarted. Bcfg2 takes care of this automatically
 for you.
@@ -86 +103 @@
 Bundles should be fairly discrete and simple and their relationship
 should be tight. We wouldn't want to put the sshd service in the
-syslog Bundle even though sshd does use syslog. Restarting sshd when /
-etc/syslog.conf changes or when a new sysklogd package comes out
+syslog Bundle even though sshd does use syslog. Restarting sshd when `/
+etc/syslog.conf` changes or when a new sysklogd package comes out
 doesn't make sense.
 
@@ -150 +167 @@
 file, but it could easily be automated. Enter Generators.
 With a Generator you can have it so the it takes care of the
-management of the particular !ConfigFile elements such as /etc/ssh/
-known_hosts and the host keys. What would happen is when a client
+management of the particular !ConfigFile elements such as `/etc/ssh/
+known_hosts` and the host keys. What would happen is when a client
 contacts the Bcfg2 server and requests those !ConfigFile elements
 handled by the Generator, the Generator will take care of auto-
@@ -173 +190 @@
 The Bcfg2 repository is just a collection of directories and files
 that direct the Bcfg2 server how to build configurations for hosts.
-The majority of the repository is kept in /var/db/bcfg on ci-
+The majority of the repository is kept in `/var/db/bcfg` on ci-
 www.uchicago.edu but the package repository is kept on ci-
 nfs.uchicago.edu and NFS exported. The package repository is
-automounted at /autonfs/media, for the original installation media,
-and /autonfs/updates, for updated packages. Within the central Bcfg2
+automounted at `/autonfs/media`, for the original installation media,
+and `/autonfs/updates`, for updated packages. Within the central Bcfg2
 repository there are several directories that contain configuration
-parameters for establishing a paprticular configuration for a host.
+parameters for establishing a particular configuration for a host.
 
 ==== Metadata/ Directory ====
 
-The Metadata/ directory contains several configuration files that
+The `Metadata/` directory contains several configuration files that
 dictate how to start generating a configuration for a host.
 
 ===== Metadata/groups.xml =====
 
-The groups.xml contains Group and Profile definitions. Here's a very
-basic Metadata/groups.xml:
+The `groups.xml` contains Group and Profile definitions. Here's a very
+basic `Metadata/groups.xml`:
 
 {{{
@@ -208 +225 @@
 ===== Metadata/clients.xml =====
 
-The Metadata/clients.xml file contains the mappings of Profiles to
+The `Metadata/clients.xml` file contains the mappings of Profiles to
 clients. A sample from this file is:
 
@@ -226 +243 @@
 ==== Bundler/ Directory ====
 
-The Bundler/ directory is where all the Bcfg2 bundle XML files are
+The `Bundler/` directory is where all the Bcfg2 bundle XML files are
 kept. These are the files described above.
 
 ==== Pkgmgr/ Directory ====
 
-The Pkgmgr/ directory keeps the XML files that define what packages
+The `Pkgmgr/` directory keeps the XML files that define what packages
 are available for a host or image and where to find those packages.
 Here's an example of the files:
@@ -298 +315 @@
 ==== Svcmgr/ Directory ====
 
-The Svcmgr directory is responsible for defining the state of
-Services. Like the Pkgmgr directory, the Svcmgr directory can contain
+The `Svcmgr` directory is responsible for defining the state of
+Services. Like the `Pkgmgr` directory, the `Svcmgr` directory can contain
 multiple files to allow the administrator to divide the definitions
 of services up. Here's a simple example:
@@ -336 +353 @@
 }}}
 
-Like the Pkgmgr directory and the Svcmgr directory, the Base
+Like the `Pkgmgr` directory and the `Svcmgr` directory, the Base
 directory can contain multiple files and the appropriate file is
 chosen based on the Group membership:
@@ -354 +371 @@
 !ConfigFile element listed in a Bundle you need to provide Bcfg with
 the actual configuration file to give to the host. The directory
-structure under the Cfg/ directory defines where the configuration
+structure under the `Cfg/` directory defines where the configuration
 file should be placed on the host machine relative to the /
-directory. For example, if you want to manage /etc/motd you would
-create the directory Cfg/etc/motd/ and then place the /etc/motd file
+directory. For example, if you want to manage `/etc/motd`  you would
+create the directory `Cfg/etc/motd/` and then place the `/etc/motd` file
 in that directory.
 
 ===== Specialized Configuration Files =====
 
-Some hosts or Groups might need a different version of /etc/motd or
+Some hosts or Groups might need a different version of `/etc/motd` or
 might just need to add or remove lines from it. You can create
 specialized versions for a particular host by appending .H_ to the
@@ -413 +430 @@
 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
+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,
@@ -428 +445 @@
 
 Continuing our example for cat files, we would first create a file
-named motd.G01_file-server.cat. The .cat suffix designates that the
+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:
@@ -456 +473 @@
 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
+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
+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
+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.
+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
@@ -480 +497 @@
 === Report Configuration ===
 
-Report generation requires the etc/report-configuration.xml and looks
+Report generation requires the `etc/report-configuration.xml` and looks
 something like:
 
@@ -515 +532 @@
 === Report Scripts ===
 
-Reports are generated by the /usr/sbin/StatReports script. 
+Reports are generated by the `/usr/sbin/StatReports` script. 
 !GenerateHostInfo
-gathers the data about the given hosts and writes out etc/hostinfo.xml. 
-!StatReports reads the etc/hostinfo.xml and generates
-the reports based on etc/report-configuration.xml. !StatReports will 
+gathers the data about the given hosts and writes out `etc/hostinfo.xml`. 
+!StatReports reads the `etc/hostinfo.xml` and generates
+the reports based on `etc/report-configuration.xml`. !StatReports will 
 automatically run !GenerateHostInfo if it has not run within 24 hours. 
 !StatReports is usually run nightly from cron.
@@ -526 +543 @@
 
 For the www and rss mechanisms, you need to define a way to get to
-the reports generated. The CI reports are stored in /var/db/bcfg/www
-and we need to define an Apache Alias to access it. /etc/httpd/conf.d/
-bcfg2.conf defines the Apache configuration:
+the reports generated. The CI reports are stored in `/var/db/bcfg/www`
+and we need to define an Apache Alias to access it. `/etc/httpd/conf.d/
+bcfg2.conf` defines the Apache configuration:
 
 {{{