Changes between Version 8 and Version 9 of TracNav


Ignore:
Timestamp:
04/27/10 04:57:34 (12 years ago)
Author:
http://fab.id.fedoraproject.org/
Comment:

some minor changes

Legend:

Unmodified
Added
Removed
Modified
  • TracNav

    v8 v9  
    66machines and diverse architectures. The ultimate goal of 
    77configuration management is to make machines as consistent, easily 
    8 manageable, and up to date as possible. This document describes a typical installation of bcfg2. 
     8manageable, and up to date as possible. This document describes a 
     9typical installation of Bcfg2. 
    910 
    1011== Bcfg2 Server == 
    1112 
    1213Each deployment will have a central bcfg2 server. 
    13 This machine runs 
    14 the Bcfg2 server daemon as well as keeps the Bcfg2 configuration 
     14This machine runs the Bcfg2 server daemon as well as keeps the Bcfg2 configuration 
    1515repository as well as serving package data when needed. The server uses XML-RPC 
    1616for its communications and this channel is encrypted using SSL. The 
    17 Bcfg2 server and client get the connection information from the /etc/ 
    18 bcfg2.conf configuration file. An example /etc/bcfg2.conf looks like: 
     17Bcfg2 server and client get the connection information from the `/etc/ 
     18bcfg2.conf` configuration file. An example `/etc/bcfg2.conf` looks like: 
    1919 
    2020{{{ 
    2121[server] 
    22 repository = /var/db/bcfg 
     22repository = /var/lib/bcfg2 
    2323structures = Bundler,Base 
    24 generators = SSHbase,Cfg,Pkgmgr,Svcmgr,TCheetah 
    25 metadata = /var/db/bcfg/etc 
     24generators = SSHbase,Cfg,Pkgmgr,Rules 
     25# Uncomment to use the DBStats plugin (0.9.6pre2 and later) 
     26plugins = DBStats 
    2627 
    2728[statistics] 
    28 sendmailpath = /usr/sbin/sendmail 
     29sendmailpath = /usr/lib/sendmail 
     30database_engine = sqlite3 
     31# 'postgresql', 'mysql', 'mysql_old', 'sqlite3' or 'ado_mssql'. 
     32database_name = 
     33# Or path to database file if using sqlite3. 
     34#<repository>/etc/brpt.sqlite is default path if left empty 
     35database_user = 
     36# Not used with sqlite3. 
     37database_password = 
     38# Not used with sqlite3. 
     39database_host = 
     40# Not used with sqlite3. 
     41database_port = 
     42# Set to empty string for default. Not used with sqlite3. 
     43web_debug = True 
    2944 
    3045[communication] 
    3146protocol = xmlrpc/ssl 
    32 password = verysecret 
    33 key = /usr/share/ssl/bcfg2/server-key.pem 
     47password = PASSWORD 
     48key = /etc/bcfg2.key 
     49# fingerprint of server (from bcfg2-admin fingerprint) 
     50#fingerprint = [server fingerprint] 
    3451 
    3552[components] 
     
    5370A config file 
    5471Service 
    55 A service to start or stop on boot (usually kept in /etc/init.d) 
     72A service to start or stop on boot (usually kept in `/etc/init.d/`) 
    5673Directory 
    5774A directory that should be present 
     
    7693 
    7794Here we can see that for the Group rhel, the syslog Bundle contains a 
    78 !ConfigFile element /etc/syslog.conf, a Package element sysklogd, and 
     95!ConfigFile element `/etc/syslog.conf`, a Package element sysklogd, and 
    7996a Service element syslog. This defines a relationship between all 
    8097these elements, so that if one of these changes, examination of all 
    8198the elements should be taken more closely. For example, say you 
    82 update the /etc/syslog.conf file. Once it's been updated the syslog 
     99update the `/etc/syslog.conf` file. Once it's been updated the syslog 
    83100service should be restarted. Bcfg2 takes care of this automatically 
    84101for you. 
     
    86103Bundles should be fairly discrete and simple and their relationship 
    87104should be tight. We wouldn't want to put the sshd service in the 
    88 syslog Bundle even though sshd does use syslog. Restarting sshd when / 
    89 etc/syslog.conf changes or when a new sysklogd package comes out 
     105syslog Bundle even though sshd does use syslog. Restarting sshd when `/ 
     106etc/syslog.conf` changes or when a new sysklogd package comes out 
    90107doesn't make sense. 
    91108 
     
    150167file, but it could easily be automated. Enter Generators. 
    151168With a Generator you can have it so the it takes care of the 
    152 management of the particular !ConfigFile elements such as /etc/ssh/ 
    153 known_hosts and the host keys. What would happen is when a client 
     169management of the particular !ConfigFile elements such as `/etc/ssh/ 
     170known_hosts` and the host keys. What would happen is when a client 
    154171contacts the Bcfg2 server and requests those !ConfigFile elements 
    155172handled by the Generator, the Generator will take care of auto- 
     
    173190The Bcfg2 repository is just a collection of directories and files 
    174191that direct the Bcfg2 server how to build configurations for hosts. 
    175 The majority of the repository is kept in /var/db/bcfg on ci- 
     192The majority of the repository is kept in `/var/db/bcfg` on ci- 
    176193www.uchicago.edu but the package repository is kept on ci- 
    177194nfs.uchicago.edu and NFS exported. The package repository is 
    178 automounted at /autonfs/media, for the original installation media, 
    179 and /autonfs/updates, for updated packages. Within the central Bcfg2 
     195automounted at `/autonfs/media`, for the original installation media, 
     196and `/autonfs/updates`, for updated packages. Within the central Bcfg2 
    180197repository there are several directories that contain configuration 
    181 parameters for establishing a paprticular configuration for a host. 
     198parameters for establishing a particular configuration for a host. 
    182199 
    183200==== Metadata/ Directory ==== 
    184201 
    185 The Metadata/ directory contains several configuration files that 
     202The `Metadata/` directory contains several configuration files that 
    186203dictate how to start generating a configuration for a host. 
    187204 
    188205===== Metadata/groups.xml ===== 
    189206 
    190 The groups.xml contains Group and Profile definitions. Here's a very 
    191 basic Metadata/groups.xml: 
     207The `groups.xml` contains Group and Profile definitions. Here's a very 
     208basic `Metadata/groups.xml`: 
    192209 
    193210{{{ 
     
    208225===== Metadata/clients.xml ===== 
    209226 
    210 The Metadata/clients.xml file contains the mappings of Profiles to 
     227The `Metadata/clients.xml` file contains the mappings of Profiles to 
    211228clients. A sample from this file is: 
    212229 
     
    226243==== Bundler/ Directory ==== 
    227244 
    228 The Bundler/ directory is where all the Bcfg2 bundle XML files are 
     245The `Bundler/` directory is where all the Bcfg2 bundle XML files are 
    229246kept. These are the files described above. 
    230247 
    231248==== Pkgmgr/ Directory ==== 
    232249 
    233 The Pkgmgr/ directory keeps the XML files that define what packages 
     250The `Pkgmgr/` directory keeps the XML files that define what packages 
    234251are available for a host or image and where to find those packages. 
    235252Here's an example of the files: 
     
    298315==== Svcmgr/ Directory ==== 
    299316 
    300 The Svcmgr directory is responsible for defining the state of 
    301 Services. Like the Pkgmgr directory, the Svcmgr directory can contain 
     317The `Svcmgr` directory is responsible for defining the state of 
     318Services. Like the `Pkgmgr` directory, the `Svcmgr` directory can contain 
    302319multiple files to allow the administrator to divide the definitions 
    303320of services up. Here's a simple example: 
     
    336353}}} 
    337354 
    338 Like the Pkgmgr directory and the Svcmgr directory, the Base 
     355Like the `Pkgmgr` directory and the `Svcmgr` directory, the Base 
    339356directory can contain multiple files and the appropriate file is 
    340357chosen based on the Group membership: 
     
    354371!ConfigFile element listed in a Bundle you need to provide Bcfg with 
    355372the actual configuration file to give to the host. The directory 
    356 structure under the Cfg/ directory defines where the configuration 
     373structure under the `Cfg/` directory defines where the configuration 
    357374file should be placed on the host machine relative to the / 
    358 directory. For example, if you want to manage /etc/motd you would 
    359 create the directory Cfg/etc/motd/ and then place the /etc/motd file 
     375directory. For example, if you want to manage `/etc/motd` you would 
     376create the directory `Cfg/etc/motd/` and then place the `/etc/motd` file 
    360377in that directory. 
    361378 
    362379===== Specialized Configuration Files ===== 
    363380 
    364 Some hosts or Groups might need a different version of /etc/motd or 
     381Some hosts or Groups might need a different version of `/etc/motd` or 
    365382might just need to add or remove lines from it. You can create 
    366383specialized versions for a particular host by appending .H_ to the 
     
    413430Bcfg2 has finer grained control over how to deliver configuration 
    414431files to a host. Let's say we have a Group named file-server. Members 
    415 of this group need the exact same /etc/motd as all other hosts except 
     432of this group need the exact same `/etc/motd` as all other hosts except 
    416433they need one line added. We could copy motd to motd.G01_file-server, 
    417434add the one line to the Group specific version and be done with it, 
     
    428445 
    429446Continuing our example for cat files, we would first create a file 
    430 named motd.G01_file-server.cat. The .cat suffix designates that the 
     447named `motd.G01_file-server.cat`. The .cat suffix designates that the 
    431448file is a diff. We would then edit that file and add the following 
    432449line: 
     
    456473If our machine isn't foo.example.com then here's what would happen: 
    457474 
    458 Bcfg2 would choose motd.G01_web-server as the base file. It is the 
     475Bcfg2 would choose `motd.G01_web-server` as the base file. It is the 
    459476most specific base file for this host. 
    460 Bcfg2 would apply the motd.G01_mail-server.cat delta to the 
    461 motd.G01_web-server base file. It is the least specific delta. 
    462 Bcfg2 would then apply the motd.G02_file-server.cat delta to the 
     477Bcfg2 would apply the `motd.G01_mail-server.cat` delta to the 
     478`motd.G01_web-server` base file. It is the least specific delta. 
     479Bcfg2 would then apply the `motd.G02_file-server.cat` delta to the 
    463480result of the delta before it. 
    464481If our machine is foo.example.com then here's what would happen: 
    465482 
    466 Bcfg2 would choose motd.G01_web-server as the base file. It is the 
     483Bcfg2 would choose `motd.G01_web-server` as the base file. It is the 
    467484most specific base file for this host. 
    468 Bcfg2 would apply the motd.H_foo.example.com.cat delta to the 
    469 motd.G01_web-server base file. 
     485Bcfg2 would apply the `motd.H_foo.example.com.cat` delta to the 
     486`motd.G01_web-server` base file. 
    470487The reason the other deltas aren't applied to foo.example.com is 
    471488because a .H_ delta is more specific than a .G##_ delta. Bcfg2 
     
    480497=== Report Configuration === 
    481498 
    482 Report generation requires the etc/report-configuration.xml and looks 
     499Report generation requires the `etc/report-configuration.xml` and looks 
    483500something like: 
    484501 
     
    515532=== Report Scripts === 
    516533 
    517 Reports are generated by the /usr/sbin/StatReports script.  
     534Reports are generated by the `/usr/sbin/StatReports` script.  
    518535!GenerateHostInfo 
    519 gathers the data about the given hosts and writes out etc/hostinfo.xml.  
    520 !StatReports reads the etc/hostinfo.xml and generates 
    521 the reports based on etc/report-configuration.xml. !StatReports will  
     536gathers the data about the given hosts and writes out `etc/hostinfo.xml`.  
     537!StatReports reads the `etc/hostinfo.xml` and generates 
     538the reports based on `etc/report-configuration.xml`. !StatReports will  
    522539automatically run !GenerateHostInfo if it has not run within 24 hours.  
    523540!StatReports is usually run nightly from cron. 
     
    526543 
    527544For the www and rss mechanisms, you need to define a way to get to 
    528 the reports generated. The CI reports are stored in /var/db/bcfg/www 
    529 and we need to define an Apache Alias to access it. /etc/httpd/conf.d/ 
    530 bcfg2.conf defines the Apache configuration: 
     545the reports generated. The CI reports are stored in `/var/db/bcfg/www` 
     546and we need to define an Apache Alias to access it. `/etc/httpd/conf.d/ 
     547bcfg2.conf` defines the Apache configuration: 
    531548 
    532549{{{