From db60e20ca7a328509da99862a1634639dd45cf5d Mon Sep 17 00:00:00 2001 From: Sol Jerome Date: Wed, 7 Nov 2012 13:05:47 -0600 Subject: man: Migrate generate-manpages.bash to sphinx Signed-off-by: Sol Jerome --- tools/manpagegen/bcfg2.conf.5.ronn | 596 ------------------------------------- 1 file changed, 596 deletions(-) delete mode 100644 tools/manpagegen/bcfg2.conf.5.ronn (limited to 'tools/manpagegen/bcfg2.conf.5.ronn') diff --git a/tools/manpagegen/bcfg2.conf.5.ronn b/tools/manpagegen/bcfg2.conf.5.ronn deleted file mode 100644 index f0359d0d3..000000000 --- a/tools/manpagegen/bcfg2.conf.5.ronn +++ /dev/null @@ -1,596 +0,0 @@ -bcfg2.conf(5) -- configuration parameters for Bcfg2 -=================================================== - -## DESCRIPTION - -`bcfg2.conf` includes configuration parameters for the Bcfg2 server and -client. - -## FILE FORMAT - -The file is INI-style and consists of sections and options. A section -begins with the name of the sections in square brackets and continues -until the next section begins. - -Options are specified in the form "name=value". - -The file is line-based each newline-terminated line represents either a -comment, a section name or an option. - -Any line beginning with a hash (#) is ignored, as are lines containing -only whitespace. - -## SERVER OPTIONS - -These options are only necessary on the Bcfg2 server. They are -specified in the `[server]` section of the configuration file. - - * `repository`: - Specifies the path to the Bcfg2 repository containing all of the - configuration specifications. The repository should be created - using the `bcfg2-admin init` command. - - * `filemonitor`: - The file monitor used to watch for changes in the repository. The - default is the best available monitor. The following values are - valid: - - `inotify`, - `gamin`, - `fam`, - `pseudo` - - * `ignore_files`: - A comma-separated list of globs that should be ignored by the file - monitor. Default values are: - - `*~`, - `*#`, - `.#*`, - `*.swp`, - `.*.swx`, - `SCCS`, - `.svn`, - `4913`, - `.gitignore` - - * `listen_all`: - This setting tells the server to listen on all available - interfaces. The default is to only listen on those interfaces - specified by the bcfg2 setting in the components section of - `bcfg2.conf`. - - * `plugins`: - A comma-delimited list of enabled server plugins. Currently - available plugins are: - - `Account`, - `Actions`, - `Base`, - `Bundler`, - `Bzr`, - `Cfg`, - `Cvs`, - `Darcs`, - `DBStats`, - `Decisions`, - `Deps`, - `Editor`, - `Fossil`, - `Git`, - `GroupPatterns`, - `Hg`, - `Hostbase`, - `Metadata`, - `NagiosGen`, - `Ohai`, - `Packages`, - `Pkgmgr`, - `Probes`, - `Properties`, - `Rules`, - `Snapshots`, - `SSHbase`, - `Svn`, - `Svn2`, - `TCheetah`, - `TGenshi`, - `Trigger` - - Descriptions of each plugin can be found in their respective - sections below. - - * `prefix`: - Specifies a prefix if the Bcfg2 installation isn’t placed in the - default location (e.g. /usr/local). - - * `backend`: - Specifies which server core backend to use. Current available - options are: - - `cherrypy`, - `builtin`, - `best` - - The default is `best`, which is currently an alias for `builtin`. - More details on the backends can be found in the official - documentation. - - * `user`: - The username or UID to run the daemon as. Default is `0` - - * `group`: - The group name or GID to run the daemon as. Default is `0` - - * `vcs_root`: - Specifies the path to the root of the VCS working copy that holds - your Bcfg2 specification, if it is different from `repository`. - E.g., if the VCS repository does not hold the bcfg2 data at the - top level, you may need to set this option. - -### Account Plugin - -The account plugin manages authentication data, including the following. - - * `/etc/passwd` - * `/etc/group` - * `/etc/security/limits.conf` - * `/etc/sudoers` - * `/root/.ssh/authorized_keys` - -### Base Plugin - -A structure plugin that provides the ability to add lists of unrelated -entries into client configuration entry inventories. Base works much -like Bundler in its file format. This structure plugin is good for the -pile of independent configs needed for most actual systems. - -### Bundler Plugin - -Bundler is used to describe groups of inter-dependent configuration -entries, such as the combination of packages, configuration files, -and service activations that comprise typical Unix daemons. Bundles are -used to add groups of configuration entries to the inventory of client -configurations, as opposed to describing particular versions of those -entries. - -### Bzr Plugin - -The Bzr plugin allows you to track changes to your Bcfg2 repository -using a GNU Bazaar version control backend. Currently, it enables you to -get revision information out of your repository for reporting purposes. - -### Cfg Plugin - -The Cfg plugin provides a repository to describe configuration file -contents for clients. In its simplest form, the Cfg repository is just a -directory tree modeled off of the directory tree on your client -machines. - -### Cvs Plugin (experimental) - -The Cvs plugin allows you to track changes to your Bcfg2 repository -using a Concurrent version control backend. Currently, it enables you to -get revision information out of your repository for reporting purposes. - -### Darcs Plugin (experimental) - -The Darcs plugin allows you to track changes to your Bcfg2 repository -using a Darcs version control backend. Currently, it enables you to get -revision information out of your repository for reporting purposes. - -### DBStats Plugin - -Direct to database statistics plugin. - -### Decisions Plugin - -The Decisions plugin has support for a centralized set of per-entry -installation decisions. This approach is needed when particular changes -are deemed "*high risk*"; this gives the ability to centrally specify -these changes, but only install them on clients when administrator -supervision is available. - -### Deps Plugin - -The Deps plugin allows you to make a series of assertions like "Package -X requires Package Y (and optionally also Package Z etc.)" - -### Editor Plugin - -The Editor plugin attempts to allow you to partially manage -configuration for a file. Its use is not recommended and not well -documented. - -### Fossil Plugin - -The Fossil plugin allows you to track changes to your Bcfg2 repository -using a Fossil SCM version control backend. Currently, it enables you to -get revision information out of your repository for reporting purposes. - -### Git Plugin - -The Git plugin allows you to track changes to your Bcfg2 repository -using a Git version control backend. Currently, it enables you to get -revision information out of your repository for reporting purposes. - -### GroupPatterns Plugin - -The GroupPatterns plugin is a connector that can assign clients group -membership based on patterns in client hostnames. - -### Hg Plugin (experimental) - -The Hg plugin allows you to track changes to your Bcfg2 repository using -a Mercurial version control backend. Currently, it enables you to get -revision information out of your repository for reporting purposes. - -### Hostbase Plugin - -The Hostbase plugin is an IP management system built on top of Bcfg2. - -### Metadata Plugin - -The Metadata plugin is the primary method of specifying Bcfg2 server -metadata. - -### NagiosGen Plugin - -NagiosGen is a Bcfg2 plugin that dynamically generates Nagios -configuration files based on Bcfg2 data. - -### Ohai Plugin (experimental) - -The Ohai plugin is used to detect information about the client operating -system. The data is reported back to the server using JSON. - -### Packages Plugin - -The Packages plugin is an alternative to Pkgmgr for specifying package -entries for clients. Where Pkgmgr explicitly specifies package entry -information, Packages delegates control of package version information -to the underlying package manager, installing the latest version -available from through those channels. - -### Pkgmgr Plugin - -The Pkgmgr plugin resolves the Abstract Configuration Entity "Package" -to a package specification that the client can use to detect, verify and -install the specified package. - -### Probes Plugin - -The Probes plugin gives you the ability to gather information from a -client machine before you generate its configuration. This information -can be used with the various templating systems to generate -configuration based on the results. - -### Properties Plugin - -The Properties plugin is a connector plugin that adds information from -properties files into client metadata instances. - -### Rules Plugin - -The Rules plugin provides literal configuration entries that resolve the -abstract configuration entries normally found in the Bundler and Base -plugins. The literal entries in Rules are suitable for consumption by -the appropriate client drivers. - -### Snapshots Plugin - -The Snapshots plugin stores various aspects of a client’s state when the -client checks in to the server. - -### SSHbase Plugin - -The SSHbase generator plugin manages ssh host keys (both v1 and v2) for -hosts. It also manages the ssh_known_hosts file. It can integrate host -keys from other management domains and similarly export its keys. - -### Svn Plugin - -The Svn plugin allows you to track changes to your Bcfg2 repository -using a Subversion backend. Currently, it enables you to get revision -information out of your repository for reporting purposes. - -### Svn2 Plugin - -The Svn2 plugin extends on the capabilities in the Svn plugin. It -provides Update and Commit methods which provide hooks for modifying -subversion-backed Bcfg2 repositories. - -### TCheetah Plugin - -The TCheetah plugin allows you to use the cheetah templating system to -create files. It also allows you to include the results of probes -executed on the client in the created files. - -### TGenshi Plugin - -The TGenshi plugin allows you to use the Genshi templating system to -create files. It also allows you to include the results of probes -executed on the client in the created files. - -### Trigger Plugin - -The Trigger plugin provides a method for calling external scripts when -clients are configured. - -## CLIENT OPTIONS - -These options only affect client functionality, specified in the -`[client]` section. - - * `decision`: - Specify the server decision list mode (whitelist or blacklist). - (This settiing will be ignored if the client is called with the -f - option.) - - * `drivers`: - Specify tool driver set to use. This option can be used to - explicitly specify the client tool drivers you want to use when the - client is run. - - * `paranoid`: - Run the client in paranoid mode. - - * `profile`: - Assert the given profile for the host. - -## COMMUNICATION OPTIONS - -Specified in the `[communication]` section. These options define -settings used for client-server communication. - - * `ca`: - The path to a file containing the CA certificate. This file is - required on the server, and optional on clients. However, if the - cacert is not present on clients, the server cannot be verified. - - * `certificate`: - The path to a file containing a PEM formatted certificate which - signs the key with the ca certificate. This setting is required on - the server in all cases, and required on clients if using client - certificates. - - * `key`: - Specifies the path to a file containing the SSL Key. This is - required on the server in all cases, and required on clients if - using client certificates. - - * `password`: - Required on both the server and clients. On the server, sets the - password clients need to use to communicate. On a client, sets the - password to use to connect to the server. - - * `protocol`: - Communication protocol to use. Defaults to xmlrpc/ssl. - - * `retries`: - A client-only option. Number of times to retry network - communication. Default is 3 retries. - - * `retry_delay`: - A client-only option. Number of seconds to wait in between - retrying network communication. Default is 1 second. - - * `serverCommonNames`: - A client-only option. A colon-separated list of Common Names the - client will accept in the SSL certificate presented by the server. - - * `timeout`: - A client-only option. The network communication timeout. - - * `user`: - A client-only option. The UUID of the client. - -## COMPONENT OPTIONS - -Specified in the `[components]` section. - - * `bcfg2`: - URL of the server. On the server this specifies which interface and - port the server listens on. On the client, this specifies where the - client will attempt to contact the server. - - e.g. `bcfg2 = https://10.3.1.6:6789` - - * `encoding`: - Text encoding of configuration files. Defaults to UTF-8. - - * `lockfile`: - The path to the client lock file, which is used to ensure that - only one Bcfg2 client runs at a time on a single client. - -## LOGGING OPTIONS - -Specified in the `[logging]` section. These options control the server -logging functionality. - - * `debug`: - Whether or not to enable debug-level log output. Default is - false. - - * `path`: - Server log file path. - - * `syslog`: - Whether or not to send logging data to syslog. Default is true. - - * `verbose`: - Whether or not to enable verbose log output. Default is false. - -## MDATA OPTIONS - -Specified in the `[mdata]` section. These options affect the default -metadata settings for Paths with type=’file’. - - * `owner`: - Global owner for Paths (defaults to root) - - * `group`: - Global group for Paths (defaults to root) - - * `mode`: - Global permissions for Paths (defaults to 644) - - * `secontext`: - Global SELinux context for Path entries (defaults to - `__default__`, which restores the expected context) - - * `paranoid`: - Global paranoid settings for Paths (defaults to false) - - * `sensitive`: - Global sensitive settings for Paths (defaults to false) - - * `important`: - Global important settings for Paths. Defaults to false, and - anything else is probably not a good idea. - - -## PACKAGES OPTIONS - -The following options are specified in the `[packages]` section of the -configuration file. - - * `resolver`: - Enable dependency resolution. Default is 1 (true). - - * `metadata`: - Enable metadata processing. Default is 1 (true). If metadata is - disabled, it’s implied that resolver is also disabled. - - * `yum_config`: - The path at which to generate Yum configs. No default. - - * `apt_config`: - The path at which to generate APT configs. No default. - - * `gpg_keypath`: - The path on the client where RPM GPG keys will be copied before they - are imported on the client. Default is `/etc/pki/rpm-gpg`. - - * `version`: - Set the version attribute used when binding Packages. Default is - auto. - -The following options are specified in the `[packages:yum]` section of -the configuration file. - - * `use_yum_libraries`: - By default, Bcfg2 uses an internal implementation of Yum’s - dependency resolution and other routines so that the Bcfg2 server - can be run on a host that does not support Yum itself. If you run - the Bcfg2 server on a machine that does have Yum libraries, however, - you can enable use of those native libraries in Bcfg2 by setting - this to 1. - - * `helper`: - Path to bcfg2-yum-helper. By default, Bcfg2 looks first in $PATH and - then in `/usr/sbin/bcfg2-yum-helper` for the helper. - - All other options in the `[packages:yum]` section will be passed along - verbatim to the Yum configuration if you are using the native Yum - library support. - -The following options are specified in the `[packages:pulp]` section of -the configuration file. - - * `username`: - The username of a Pulp user that will be used to register new - clients and bind them to repositories. - - * `password`: - The password of a Pulp user that will be used to register new - clients and bind them to repositories. - -## PARANOID OPTIONS - -These options allow for finer-grained control of the paranoid mode on -the Bcfg2 client. They are specified in the `[paranoid]` section of the -configuration file. - - * `path`: - Custom path for backups created in paranoid mode. The default is in - `/var/cache/bcfg2`. - - * `max_copies`: - Specify a maximum number of copies for the server to keep when - running in paranoid mode. Only the most recent versions of these - copies will be kept. - -## SNAPSHOTS OPTIONS - -Specified in the `[snapshots]` section. These options control the server -snapshots functionality. - - * `driver`: - sqlite - - * `database`: - The name of the database to use for statistics data. - - eg: `$REPOSITORY_DIR/etc/bcfg2.sqlite` - -## SSLCA OPTIONS - -These options are necessary to configure the SSLCA plugin and can be -found in the `[sslca_default]` section of the configuration file. - - * `config`: - Specifies the location of the openssl configuration file for your - CA. - - * `passphrase`: - Specifies the passphrase for the CA’s private key (if necessary). - If no passphrase exists, it is assumed that the private key is - stored unencrypted. - - * `chaincert`: - Specifies the location of your ssl chaining certificate. This is - used when pre-existing certifcate hostfiles are found, so that they - can be validated and only regenerated if they no longer meet the - specification. If you’re using a self signing CA this would be the - CA cert that you generated. - -## DATABASE OPTIONS - -Server-only, specified in the `[database]` section. These options -control the database connection of the server. - - * `engine`: - The database engine used by the statistics module. One of the - following: - - `postgresql`, - `mysql`, - `sqlite3`, - `ado_mssql` - - * `name`: - The name of the database to use for statistics data. If - ‘database_engine’ is set to ‘sqlite3’ this is a file path to sqlite - file and defaults to `$REPOSITORY_DIR/etc/brpt.sqlite`. - - * `user`: - User for database connections. Not used for sqlite3. - - * `password`: - Password for database connections. Not used for sqlite3. - - * `host`: - Host for database connections. Not used for sqlite3. - - * `port`: - Port for database connections. Not used for sqlite3. - - * `time_zone`: - Specify a time zone other than that used on the system. (Note that - this will cause the Bcfg2 server to log messages in this time zone - as well). - -## SEE ALSO - -bcfg2(1), bcfg2-server(8) -- cgit v1.2.3-1-g7c22