5 | | * Foo |
| 5 | Configuration management is a necessary piece of maintaining many |
| 6 | machines and diverse architectures. The ultimate goal of |
| 7 | configuration management is to make machines as consistent, easily |
| 8 | manageable, and up to date as possible. This document describes a typical installation of bcfg2. |
| 9 | |
| 10 | == Bcfg2 Server == |
| 11 | |
| 12 | Each deployment will have a central bcfg2 server. |
| 13 | This machine runs |
| 14 | the Bcfg2 server daemon as well as keeps the Bcfg2 configuration |
| 15 | repository as well as serving package data when needed. The server uses XML-RPC |
| 16 | for 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: |
| 19 | |
| 20 | {{{ |
| 21 | [server] |
| 22 | repository = /var/db/bcfg |
| 23 | structures = Bundler,Base |
| 24 | generators = SSHbase,Cfg,Pkgmgr,Svcmgr,TCheetah |
| 25 | metadata = /var/db/bcfg/etc |
| 26 | |
| 27 | [statistics] |
| 28 | sendmailpath = /usr/sbin/sendmail |
| 29 | |
| 30 | [communication] |
| 31 | protocol = xmlrpc/ssl |
| 32 | password = verysecret |
| 33 | key = /usr/share/ssl/bcfg2/server-key.pem |
| 34 | |
| 35 | [components] |
| 36 | bcfg2 = https://server:6789 |
| 37 | }}} |
| 38 | |
| 39 | This file should be owned by user and group root and readable only by |
| 40 | user root, as it contains a shared secret password. |
| 41 | |
| 42 | == Bcfg2 Abstractions == |
| 43 | |
| 44 | === Bcfg2 Elements === |
| 45 | |
| 46 | Creating a specification for a host is a modular process. A |
| 47 | specification is built of several pieces and at the base are |
| 48 | configuration elements. The following are all valid configuration |
| 49 | elements: |
| 50 | Package |
| 51 | A package for the given system (RPM. Deb, ebuild, etc) |
| 52 | ConfigFile |
| 53 | A config file |
| 54 | Service |
| 55 | A service to start or stop on boot (usually kept in /etc/init.d) |
| 56 | Directory |
| 57 | A directory that should be present |
| 58 | SymLink |
| 59 | A symbolic link that should be present |
| 60 | |
| 61 | === Bcfg2 Bundles === |
| 62 | |
| 63 | Bundles are the simplest reusable configuration blocks. A Bcfg2 |
| 64 | Bundle is a collection of Elements that are tightly related. Bundles |
| 65 | are written in XML. An example Bundle might be one for syslog: |
| 66 | |
| 67 | {{{ |
| 68 | <Bundle name="syslog" version="2.0"> |
| 69 | <Group name="rhel"> |
| 70 | <ConfigFile name="/etc/syslog.conf"/> |
| 71 | <Package name="sysklogd"/> |
| 72 | <Service name="syslog"/> |
| 73 | </Group> |
| 74 | </Bundle> |
| 75 | }}} |
| 76 | |
| 77 | Here we can see that for the Group rhel, the syslog Bundle contains a |
| 78 | ConfigFile element /etc/syslog.conf, a Package element sysklogd, and |
| 79 | a Service element syslog. This defines a relationship between all |
| 80 | these elements, so that if one of these changes, examination of all |
| 81 | the elements should be taken more closely. For example, say you |
| 82 | update the /etc/syslog.conf file. Once it's been updated the syslog |
| 83 | service should be restarted. Bcfg2 takes care of this automatically |
| 84 | for you. |
| 85 | |
| 86 | Bundles should be fairly discrete and simple and their relationship |
| 87 | should 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 |
| 90 | doesn't make sense. |
| 91 | |
| 92 | === Bcfg2 Groups === |
| 93 | |
| 94 | Groups are the next abstraction up from Bundles. Groups can contain |
| 95 | Bundles, other Groups, or simply nothing at all. An example Group |
| 96 | might be for a mail-server: |
| 97 | |
| 98 | {{{ |
| 99 | <Group profile='false' name='server'> |
| 100 | <Bundle name='kerberos-client'/> |
| 101 | <Group name='backup-client'/> |
| 102 | <Group name='base'/> |
| 103 | <Group name='ldap-client'/> |
| 104 | <Group name='serial-console'/> |
| 105 | </Group> |
| 106 | }}} |
| 107 | |
| 108 | Here we see that the server Group is actually made up of a Bundle and |
| 109 | several other Groups. Groups are used throughout Bcfg2. They can be |
| 110 | used in Bundles to help distinguish which elements a host gets |
| 111 | depending on its group membership. They are also used in the Pkgmgr |
| 112 | plugin, the Svcmgr plugin, and the Cfg plugin. |
| 113 | |
| 114 | === Bcfg2 Profiles === |
| 115 | |
| 116 | The highest level of abstraction is that of Profiles. A Profile is a |
| 117 | special Group and is then mapped to a host. A host can have one and |
| 118 | only one profile mapped to it. Note that a Profile can also contain |
| 119 | other Profiles, but these Profiles aren't mapped to the host, they |
| 120 | are simple associated with the host as a Group. A mail-server Profile |
| 121 | might look like: |
| 122 | |
| 123 | {{{ |
| 124 | <Group profile='true' public='false' name='mail-server'> |
| 125 | <Bundle name='mail-server'/> |
| 126 | <Bundle name='mailman-server'/> |
| 127 | <Group name='apache-server'/> |
| 128 | <Group name='linux-rhel-server-as-4-x86'/> |
| 129 | <Group name='nfs-client'/> |
| 130 | <Group name='server'/> |
| 131 | </Group> |
| 132 | }}} |
| 133 | |
| 134 | Here we can see that a mail-server is actually made up of a couple of |
| 135 | Bundles and a few Groups as well. |
| 136 | |
| 137 | == Bcfg2 Plugins == |
| 138 | |
| 139 | Generators are a special case for Bcfg2. A Generator is a piece of |
| 140 | code that is run to generate Bcfg2 Elements automatically for a host. |
| 141 | To explain this the best way it's best to look at an example. |
| 142 | If you run SSH, one of the most tedious processes is keeping track of |
| 143 | SSH host keys. If you have to rebuild an existing machine you want to |
| 144 | keep its existing keys so that user's don't get warnings that the key |
| 145 | has changed. When you build a brand new machine, host keys are |
| 146 | automatically created for a machine. And you probably also want to |
| 147 | manage the global known_hosts file to contain all the host keys for |
| 148 | your machines. This can all be done by hand or even by copying each |
| 149 | host's key into the Cfg repository and hand updating the known_hosts |
| 150 | file, but it could easily be automated. Enter Generators. |
| 151 | With 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 |
| 154 | contacts the Bcfg2 server and requests those ConfigFile elements |
| 155 | handled by the Generator, the Generator will take care of auto- |
| 156 | generation of new host keys for a host or giving a host the host key |
| 157 | that it had before. On top of that, if a new host key is created and |
| 158 | added to the repository, the Generator will automatically update the |
| 159 | known_hosts file with the new key and make it available for all the |
| 160 | hosts to install so that they automatically have the proper key for |
| 161 | the new host. And here's the kicker. Let's say a machine is |
| 162 | compromised. You have to rebuild the machine, but in this case you |
| 163 | don't want it to get the same host key and you have to remove the |
| 164 | host key out of all the other machine's known_hosts file. All you |
| 165 | have to do is remove the compromised key out of the repository and |
| 166 | rebuild the machine. When the machine runs Bcfg2 again, a new key |
| 167 | will be generated for the host and the known_hosts file will be |
| 168 | updated to have the new key and remove the old compromised key. |
| 169 | Pretty slick huh? |
| 170 | |
| 171 | === Bcfg2 Repository === |
| 172 | |
| 173 | The Bcfg2 repository is just a collection of directories and files |
| 174 | that direct the Bcfg2 server how to build configurations for hosts. |
| 175 | The majority of the repository is kept in /var/db/bcfg on ci- |
| 176 | www.uchicago.edu but the package repository is kept on ci- |
| 177 | nfs.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 |
| 180 | repository there are several directories that contain configuration |
| 181 | parameters for establishing a paprticular configuration for a host. |
| 182 | |
| 183 | ==== Metadata/ Directory ==== |
| 184 | |
| 185 | The Metadata/ directory contains several configuration files that |
| 186 | dictate how to start generating a configuration for a host. |
| 187 | |
| 188 | ===== Metadata/groups.xml ===== |
| 189 | |
| 190 | The groups.xml contains Group and Profile definitions. Here's a very |
| 191 | basic Metadata/groups.xml: |
| 192 | |
| 193 | {{{ |
| 194 | <Groups version='3.0'> |
| 195 | ... |
| 196 | <Group profile='true' public='false' name='mail-server'> |
| 197 | <Bundle name='mail-server'/> |
| 198 | <Bundle name='mailman-server'/> |
| 199 | <Group name='apache-server'/> |
| 200 | <Group name='linux-rhel-server-as-4-x86'/> |
| 201 | <Group name='nfs-client'/> |
| 202 | <Group name='server'/> |
| 203 | </Group> |
| 204 | ... |
| 205 | </Groups> |
| 206 | }}} |
| 207 | |
| 208 | ===== Metadata/clients.xml ===== |
| 209 | |
| 210 | The Metadata/clients.xml file contains the mappings of Profiles to |
| 211 | clients. A sample from this file is: |
| 212 | |
| 213 | {{{ |
| 214 | <Clients version="3.0"> |
| 215 | <Client profile="backup-server" pingable="Y" pingtime="0" name="ci-backup.uchicago.edu"/> |
| 216 | <Client profile="console-server" pingable="Y" pingtime="0" |
| 217 | name="ci-con.uchicago.edu"/> |
| 218 | <Client profile="kerberos-master" pingable="Y" pingtime="0" |
| 219 | name="ci-kdc.uchicago.edu"/> |
| 220 | <Client profile="mail-server" pingable="Y" pingtime="0" name="ci- |
| 221 | mail.uchicago.edu"/> |
| 222 | ... |
| 223 | </Clients> |
| 224 | }}} |
| 225 | |
| 226 | ==== Bundler/ Directory ==== |
| 227 | |
| 228 | The Bundler/ directory is where all the Bcfg2 bundle XML files are |
| 229 | kept. These are the files described above. |
| 230 | |
| 231 | ==== Pkgmgr/ Directory ==== |
| 232 | |
| 233 | The Pkgmgr/ directory keeps the XML files that define what packages |
| 234 | are available for a host or image and where to find those packages. |
| 235 | Here's an example of the files: |
| 236 | |
| 237 | {{{ |
| 238 | $ ls Pkgmgr/ |
| 239 | ci-backup.uchicago.edu.xml |
| 240 | linux-fedora-core-4-noarch-updates.xml |
| 241 | linux-fedora-core-4-x86-updates.xml |
| 242 | linux-fedora-core-4-x86.xml |
| 243 | linux-rhel-client-ws-4-noarch-udpates.xml |
| 244 | linux-rhel-client-ws-4-x86.xml |
| 245 | linux-rhel-client-ws-4-x86-updates.xml |
| 246 | linux-rhel-client-ws-4-x86_64.xml |
| 247 | linux-rhel-client-ws-4-x86_64-updates.xml |
| 248 | linux-rhel-server-as-4-noarch-updates.xml |
| 249 | linux-rhel-server-as-4-x86-updates.xml |
| 250 | linux-rhel-server-as-4-x86.xml |
| 251 | linux-rhel-server-es-4-noarch-updates.xml |
| 252 | linux-rhel-server-es-4-x86.xml |
| 253 | linux-rhel-server-es-4-x86-updates.xml |
| 254 | }}} |
| 255 | |
| 256 | Here we can see a pattern of files. Looking at the names of these |
| 257 | files you can make a pretty good guess as to what they contain. |
| 258 | Let's take a look at what the contents of one of these files, linux- |
| 259 | rhel-server-as-4-x86.xml, might look like: |
| 260 | |
| 261 | {{{ |
| 262 | <PackageList uri='http://ci-www.uchicago.edu/media/rhel-server-as-4/x86/install/RedHat/RPMS' type='rpm' priority='0'> |
| 263 | <Group name='linux-rhel-server-as-4-x86'> |
| 264 | <Package file='4Suite-1.0-3.i386.rpm'/> |
| 265 | <Package file='Canna-3.7p3-7.EL4.i386.rpm'/> |
| 266 | <Package file='Canna-devel-3.7p3-7.EL4.i386.rpm'/> |
| 267 | <Package file='Canna-libs-3.7p3-7.EL4.i386.rpm'/> |
| 268 | <Package file='ElectricFence-2.2.2-19.i386.rpm'/> |
| 269 | <Package file='FreeWnn-1.10pl020-5.i386.rpm'/> |
| 270 | <Package file='FreeWnn-devel-1.10pl020-5.i386.rpm'/> |
| 271 | <Package file='FreeWnn-libs-1.10pl020-5.i386.rpm'/> |
| 272 | ... |
| 273 | </Group> |
| 274 | </PackageList> |
| 275 | }}} |
| 276 | |
| 277 | Here you can see that the data is encapsulated in a PackageList which |
| 278 | describes the URI of the files described, the type of package, and a |
| 279 | priority of the files. The priority is used to decide which specific |
| 280 | file to use when there are multiple files that could be used for a |
| 281 | particular host. The highest priority file is the one that is used. |
| 282 | Using this system, you can have a file that contains all the Packages |
| 283 | from the original installation, linux-rhel-server-as-x86.xml in our |
| 284 | case, and then create a new file that contains updates that are made |
| 285 | available afterwards, linux-rhel-server-as-x86-updates.xml and linux- |
| 286 | rhel-server-as-noarch-updates.xml in our case. You simply make the |
| 287 | priority of the update Packages higher and they will be used instead |
| 288 | of the original installation Packages. |
| 289 | The names of the XML files have no special meaning to Bcfg2; they are |
| 290 | simply named so it's easy for the admin to know what the contents |
| 291 | hold. All Packages could be kept in a single file if you so desired. |
| 292 | Bcfg2 simply uses the Groups in the files and priorities to determine |
| 293 | how to assign Packages to a host. You may notice the file ci- |
| 294 | backup.uchicago.edu.xml. Its Packages have a higher priority than the |
| 295 | update Packages. This is because that particular host requires |
| 296 | special Packages that are older than the ones available in the updates. |
| 297 | |
| 298 | ==== Svcmgr/ Directory ===== |
| 299 | |
| 300 | The Svcmgr directory is responsible for defining the state of |
| 301 | Services. Like the Pkgmgr directory, the Svcmgr directory can contain |
| 302 | multiple files to allow the administrator to divide the definitions |
| 303 | of services up. Here's a simple example: |
| 304 | |
| 305 | {{{ |
| 306 | <Services priority='0'> |
| 307 | <Service name="kudzu" status="off"/> |
| 308 | <Group name="mail-server"> |
| 309 | <Service name="postfix" status="on"/> |
| 310 | </Group> |
| 311 | ... |
| 312 | </Services> |
| 313 | }}} |
| 314 | |
| 315 | ==== Base/ Directory ==== |
| 316 | |
| 317 | The Base directory is responsible for defining the base config for |
| 318 | all hosts of a given Group. The majority of the elements are |
| 319 | Packages, but you can have Services, ConfigFiles, Directories, and |
| 320 | SymLinks as well. Here's an example: |
| 321 | |
| 322 | {{{ |
| 323 | <Base > |
| 324 | <Group name='linux-rhel-server-as-4-x86'> |
| 325 | <ConfigFile name='/etc/group'/> |
| 326 | <ConfigFile name='/etc/inittab'/> |
| 327 | <ConfigFile name='/etc/passwd'/> |
| 328 | <ConfigFile name='/etc/securetty'/> |
| 329 | <ConfigFile name='/etc/shadow'/> |
| 330 | <ConfigFile name='/etc/updatedb.conf'/> |
| 331 | <ConfigFile name='/usr/bin/bu'/> |
| 332 | <Package name='4Suite'/> |
| 333 | ... |
| 334 | </Group> |
| 335 | </Base> |
| 336 | }}} |
| 337 | |
| 338 | Like the Pkgmgr directory and the Svcmgr directory, the Base |
| 339 | directory can contain multiple files and the appropriate file is |
| 340 | chosen based on the Group membership: |
| 341 | |
| 342 | {{{ |
| 343 | $ ls Base/ |
| 344 | linux-fedora-core-4-x86.xml |
| 345 | linux-rhel-client-ws-4-x86_64.xml |
| 346 | linux-rhel-client-ws-4-x86.xml |
| 347 | linux-rhel-server-as-4-x86.xml |
| 348 | linux-rhel-server-es-4-x86.xml |
| 349 | }}} |
| 350 | |
| 351 | ==== Cfg/ Directory ==== |
| 352 | |
| 353 | The Cfg is where all the actual ConfigFiles are kept. If you have a |
| 354 | ConfigFile element listed in a Bundle you need to provide Bcfg with |
| 355 | the actual configuration file to give to the host. The directory |
| 356 | structure under the Cfg/ directory defines where the configuration |
| 357 | file 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 |
| 360 | in that directory. |
| 361 | |
| 362 | ===== Specialized Configuration Files ===== |
| 363 | |
| 364 | Some hosts or Groups might need a different version of /etc/motd or |
| 365 | might just need to add or remove lines from it. You can create |
| 366 | specialized versions for a particular host by appending .H_ to the |
| 367 | configuration file where <hostname is the fully qualified hostname. |
| 368 | So if foo.example.com needed a special version your motd directory |
| 369 | might look like: |
| 370 | |
| 371 | {{{ |
| 372 | $ ls Cfg/etc/motd |
| 373 | motd |
| 374 | motd.H_foo.example.com |
| 375 | }}} |
| 376 | |
| 377 | Now when you run Bcfg2 on foo.example.com it will get the specialized |
| 378 | version and all other hosts will get the generic version. |
| 379 | If you want specialized versions for a Group you would append .G##_ |
| 380 | to the file where ## is a two digit number specifying priority and is |
| 381 | the name of the Group. Continuing our example if we wanted to have a |
| 382 | special motd for the mail-server Group we would have the following: |
| 383 | |
| 384 | {{{ |
| 385 | $ ls Cfg/etc/motd |
| 386 | motd |
| 387 | motd.G01_mail-server |
| 388 | motd.H_foo.example.com |
| 389 | }}} |
| 390 | |
| 391 | Now if a host is a member of the mail-server Group it will get the |
| 392 | specialized Group version of motd. Now what happens if |
| 393 | foo.example.com is also a membere of the mail-server Group? Bcfg2 |
| 394 | will use the highest priority, most specific file. So foo.example.com |
| 395 | will always get motd.H_foo.example.com. If you have specialized |
| 396 | versions for multiple groups, the priorities you assign come in to |
| 397 | play. Let's say we have the following: |
| 398 | |
| 399 | {{{ |
| 400 | $ ls Cfg/etc/motd |
| 401 | motd |
| 402 | motd.G01_mail-server |
| 403 | motd.G02_web-server |
| 404 | motd.H_foo.example.com |
| 405 | }}} |
| 406 | |
| 407 | If you have a host, not foo.example.com, that is a member of both the |
| 408 | mail-server and the web-server Groups, it will get the web-server |
| 409 | version because it has a higher priority, 02 instead of 01. |
| 410 | |
| 411 | === Deltas === |
| 412 | |
| 413 | Bcfg2 has finer grained control over how to deliver configuration |
| 414 | files 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 |
| 416 | they need one line added. We could copy motd to motd.G01_file-server, |
| 417 | add the one line to the Group specific version and be done with it, |
| 418 | but we're duplicating data in both files. What happens if we need to |
| 419 | update the motd? We'll need to remember to update both files then. |
| 420 | Here's where deltas come in. A delta is a small change to the base |
| 421 | file. There are two types of deltas: cats and diffs. The cat delta |
| 422 | simply adds or removes lines from the base file. The diff delta is |
| 423 | more powerful since it can take a unified diff and apply it to the |
| 424 | base configuration file to create the specialized file. Diff deltas |
| 425 | should be used very sparingly. |
| 426 | |
| 427 | ==== Cat Files ==== |
| 428 | |
| 429 | Continuing our example for cat files, we would first create a file |
| 430 | named motd.G01_file-server.cat. The .cat suffix designates that the |
| 431 | file is a diff. We would then edit that file and add the following |
| 432 | line: |
| 433 | |
| 434 | {{{ |
| 435 | +This is a file server |
| 436 | }}} |
| 437 | |
| 438 | The + at the beggining of the file tells Bcfg2 that the line should |
| 439 | be appended to end of the file. You can also start a line with - to |
| 440 | tell Bcfg2 to remove that exact line wherever it might be in the file. |
| 441 | How do we know what base file Bcfg2 will choose to use to apply a |
| 442 | delta? The same rules apply as before: Bcfg2 will choose the highest |
| 443 | priority, most specific file as the base and then apply deltas in the |
| 444 | order of most specific and then increasing in priority. What does |
| 445 | this mean in real life. Let's say our machine is a web server, mail |
| 446 | server, and file server and we have the following configuration files: |
| 447 | |
| 448 | {{{ |
| 449 | motd |
| 450 | motd.G01_web-server |
| 451 | motd.G01_mail-server.cat |
| 452 | motd.G02_file-server.cat |
| 453 | motd.H_foo.example.cat |
| 454 | }}} |
| 455 | |
| 456 | If our machine isn't foo.example.com then here's what would happen: |
| 457 | |
| 458 | Bcfg2 would choose motd.G01_web-server as the base file. It is the |
| 459 | most 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 |
| 463 | result of the delta before it. |
| 464 | If our machine is foo.example.com then here's what would happen: |
| 465 | |
| 466 | Bcfg2 would choose motd.G01_web-server as the base file. It is the |
| 467 | most 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. |
| 470 | The reason the other deltas aren't applied to foo.example.com is |
| 471 | because a .H_ delta is more specific than a .G##_ delta. Bcfg2 |
| 472 | applies all the deltas at the most specific level. |
| 473 | |
| 474 | == Bcfg2 Reports == |
| 475 | |
| 476 | Bcfg2 has the ability to generate reports to make it easier to see at |
| 477 | a glance the state of your environment. It can report via three |
| 478 | methods: HTML web page, RSS feed, email. |
| 479 | |
| 480 | === Report Configuration === |
| 481 | |
| 482 | Report generation requires the etc/report-configuration.xml and looks |
| 483 | something like: |
| 484 | |
| 485 | {{{ |
| 486 | <Reports> |
| 487 | <Report name='Computation Institute' good='Y' modified='Y'> |
| 488 | <Delivery mechanism='www' type='nodes-digest'> |
| 489 | <Destination address='/var/db/bcfg/www/stats.html'/> |
| 490 | </Delivery> |
| 491 | <Delivery mechanism='rss' type='nodes-individual'> |
| 492 | <Destination address='/var/db/bcfg/www/stats.rss'/> |
| 493 | </Delivery> |
| 494 | <Delivery mechanism='mail' type='nodes-digest'> |
| 495 | <Destination address='[email protected]'/> |
| 496 | </Delivery> |
| 497 | |
| 498 | <Machine name='.*'/> |
| 499 | </Report> |
| 500 | </Reports> |
| 501 | }}} |
| 502 | |
| 503 | This is a good example showcasing several of the report generation |
| 504 | features. In this example we define a report names Computation |
| 505 | Institute which includes good as well as bad nodes and those nodes |
| 506 | that were modified in the last run. For this report there are three |
| 507 | delivery mechanisms: www, rss, mail. Thee www mechanism is the HTML |
| 508 | generation. The other two are pretty self explanatory. The last |
| 509 | parameter is which machines to include in this report. This report |
| 510 | includes all the machines that Bcfg2 knows about. here you can give a |
| 511 | regular expression to narrow down which machines are reported for. |
| 512 | Refer to the Bcfg2 documentation for more detail on the configuring |
| 513 | reports. |
| 514 | |
| 515 | === Report Scripts === |
| 516 | |
| 517 | Reports are generated by the /usr/sbin/StatReports script. |
| 518 | !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 |
| 522 | automatically run !GenerateHostInfo if it has not run within 24 hours. |
| 523 | !StatReports is usually run nightly from cron. |
| 524 | |
| 525 | === Report Interface === |
| 526 | |
| 527 | For 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: |
| 531 | |
| 532 | {{{ |
| 533 | <IfModule mod_alias.c> |
| 534 | Alias /bcfg2 /var/db/bcfg/www |
| 535 | </IfModule> |
| 536 | |
| 537 | <Directory "/var/db/bcfg/www"> |
| 538 | Options Indexes FollowSymLinks |
| 539 | AllowOverride None |
| 540 | Order deny,allow |
| 541 | Allow from all |
| 542 | </Directory> |
| 543 | }}} |