diff options
Diffstat (limited to 'doc/appendix/guides')
| -rw-r--r-- | doc/appendix/guides/fedora.txt | 19 | ||||
| -rw-r--r-- | doc/appendix/guides/using-bcfg2-info.txt | 132 |
2 files changed, 15 insertions, 136 deletions
diff --git a/doc/appendix/guides/fedora.txt b/doc/appendix/guides/fedora.txt index d8d3b1b34..91d36cd25 100644 --- a/doc/appendix/guides/fedora.txt +++ b/doc/appendix/guides/fedora.txt @@ -15,12 +15,22 @@ This is a complete getting started guide for Fedora. With this document you should be able to install a Bcfg2 server, a Bcfg2 client, and change the ``/etc/motd`` file on the client. +Prerequisites +============= + +To setup a configuration management system based on Bcfg2 only a few +prerequisites need to be fullfilled. + +* A server machine that can host the Bcfg2 +* Internet access for the installation process +* A working network with DNS + + Install Bcfg2 From RPM ====================== The fastest way to get Bcfg2 onto your system is to use ``yum`` -or PackageKit. `` -um`` will pull all dependencies of Bcfg2 +or PackageKit. ``yum`` will pull all dependencies of Bcfg2 automatically in. :: $ su -c 'yum install bcfg2-server bcfg2' @@ -28,6 +38,7 @@ automatically in. :: Your system should now have the necessary software to use Bcfg2. The next step is to set up your Bcfg2 :term:`repository`. + Initialize your repository ========================== @@ -45,7 +56,7 @@ is a tool which allows you to automate this: What is the server's hostname: [config01.local.net] Input the server location [https://config01.local.net:6789]: Input base Operating System for clients: - 1: Redhat/Fedora/RHEL/RHAS/Centos + 1: Red Hat/Fedora/RHEL/RHAS/Centos 2: SUSE/SLES 3: Mandrake 4: Debian @@ -68,7 +79,7 @@ Change responses as necessary. Start the server ================ -You are now ready to start your bcfg2 server for the first time:: +You are now ready to start your Bcfg2 server for the first time:: $ su -c '/etc/init.d/bcfg2-server start' Starting Configuration Management Server: bcfg2-server [ OK ] diff --git a/doc/appendix/guides/using-bcfg2-info.txt b/doc/appendix/guides/using-bcfg2-info.txt deleted file mode 100644 index b2354652f..000000000 --- a/doc/appendix/guides/using-bcfg2-info.txt +++ /dev/null @@ -1,132 +0,0 @@ -.. -*- mode: rst -*- - -.. _appendix-guides-using_bcfg2_info: - -================ -Using bcfg2-info -================ - -``bcfg2-info`` is a tool for introspecting server functions. It is -useful for understanding how the server is interpreting your -repository. It consists of the same logic executed by the server to -process the repository and produce configuration specifications, just -without all of the network communication code. Think of ``bcfg2-info`` -as ``bcfg2-server`` on a stick. It is a useful location to do testing -and staging of new configuration rules, prior to deployment. This is -particularly useful when developing templates, or developing Bcfg2 -plugins. - -Getting Started -=============== - -First, fire up the bcfg2-info interpreter. - -.. code-block:: none - - [0:464] bcfg2-info - Loading experimental plugin(s): Packages - NOTE: Interfaces subject to change - Handled 8 events in 0.006s - Handled 4 events in 0.035s - Welcome to bcfg2-info - Type "help" for more information - > - -At this point, the server core has been loaded up, all plugins have -been loaded, and the ``bcfg2-info`` has both read the initial state of -the Bcfg2 repository, as well as begun monitoring it for changes. Like -*bcfg2-server*, ``bcfg2-info`` monitors the repository for changes, -however, unlike *bcfg2-server*, it does not process change events -automatically. File modification events can be processed by explicitly -calling the **update** command. This will process the events, -displaying the number of events processed and the amount of time taken -by this processing. If no events are available, no message will be -displayed. For example, after a change to a file in the repository: - -.. code-block:: none - - >update - Handled 1 events in 0.001s - > update - > - -This explicit update process allows you to control the update process, -as well as see the precise changes caused by repository -modifications. - -``bcfg2-info`` has several builtin commands that display the state of -various internal server core state. These are most useful for -examining the state of client metadata, either for a single client, or -for clients overall. - -**clients** - displays a list of clients, along with their profile groups -**groups** - displays a list of groups, the inheritance hierarchy, profile - status, and category name, if there is one. -**showclient** - displays full metadata information for a client, including - profile group, group memberships, bundle list, and any connector - data, like Probe values or Property info. - -Debugging Configuration Rules -============================= - -In addition to the commands listed above for viewing client metadata, -there are also commands which can shed light on the configuration -generation process. Recall that configuration generation occurs in -three major steps: - -1) Resolve client metadata -2) Build list of entries for the configuration -3) Bind host-specific version of each entry - -Step *1* can be viewed with the commands presented in the previous -section. The latter two steps can be examined using the following -commands. - -**showentries** - displays a list of entries (optionally filtered by type) that - appear in a client's configuration specification - -**buildfile** - Perform the entry binding process on a single entry, displaying - its results. This command is very useful when developing - configuration file templates. - -**build** - Build the full configuration specification and write it to a - file. - -**mappings** - displays the entries handled by the plugins loaded by the server - core. This command is useful when the server reports a bind - failure for an entry. - -Debugging and Developing Bcfg2 -============================== - -``bcfg2-info`` loads a full Bcfg2 server core, so it provides the ideal -environment for developing and debugging Bcfg2. Because it is hard to -automate this sort of process, we have only implemented two commands -in ``bcfg2-info`` to aid in the process. - -**profile** - The profile command produces python profiling information for - other ``bcfg2-info`` commands. This can be used to track - performance problems in configuration generation. - -**debug** - The debug command exits the ``bcfg2-info`` interpreter loop and drops - to a python interpreter prompt. The Bcfg2 server core is available - in this namespace as "self". Full documentation for the server core - is out of scope for this document. This capability is most useful - to call into plugin methods, often with setup calls or the enabling - of diagnostics. - - It is possible to return to the ``bcfg2-info`` command loop by - exiting the python interpreter with ^D. - - There is built-in support for IPython in ``bcfg2-info``. If IPython - is installed, dropping into debug mode in ``bcfg2-info`` will use - the IPython interpreter by default. |