Linux and UNIX Man Pages

Test Your Knowledge in Computers #996
Difficulty: Medium
Major Unix vendors, including Sun Microsystems, HP, IBM, and SGI, have been selling virtualized hardware since before 1990.
True or False?
Linux & Unix Commands - Search Man Pages

fossil(1) [debian man page]

FOSSIL(1)							   User Commands							 FOSSIL(1)

NAME
fossil - Distributed Version Control System SYNOPSIS
fossil help fossil help COMMAND fossil COMMAND [OPTIONS] DESCRIPTION
Fossil is a distributed version control system (DVCS) with built-in wiki, ticket tracker, CGI/http interface, and http server. Available COMMANDs: add co info rename ticket addremove commit init revert timeline all configuration leaves rm ui annotate deconstruct ls scrub undo artifact delete merge search unset bisect descendants mv server update branch diff new settings user cgi export open sha1sum version changes extras pull sqlite3 wiki checkout finfo push stash winsrv ci gdiff rebuild status zip clean help reconstruct sync clone http redo tag close import remote-url tarball FEATURES
Features as described on the fossil home page. 1. Bug Tracking And Wiki - In addition to doing distributed version control like Git and Mercurial, Fossil also supports distributed bug tracking, distributed wiki, and a distributed blog mechanism all in a single integrated package. 2. Web Interface - Fossil has a built-in and easy-to-use web interface that simplifies project tracking and promotes situational aware- ness. Simply type "fossil ui" from within any check-out and Fossil automatically opens your web browser in a page that gives detailed graphical history and status information on that project. 3. Autosync - Fossil supports "autosync" mode which helps to keep projects moving forward by reducing the amount of needless forking and merging often associated with distributed projects. 4. Self-Contained - Fossil is a single stand-alone executable that contains everything needed to do configuration management. Installation is trivial: simply download a precompiled binary for Linux, Mac, or Windows and put it on your $PATH. Easy-to-compile source code is available for users on other platforms. Fossil sources are also mostly self-contained, requiring only the "zlib" library and the standard C library to build. 5. Simple Networking - Fossil uses plain old HTTP (with proxy support) for all network communications, meaning that it works fine from behind restrictive firewalls. The protocol is bandwidth efficient to the point that Fossil can be used comfortably over a dial-up internet connection. 6. CGI Enabled - No server is required to use fossil. But a server does make collaboration easier. Fossil supports three different yet simple server configurations. The most popular is a 2-line CGI script. This is the approach used by the self-hosting fossil reposi- tories. 7. Robust & Reliable - Fossil stores content using an enduring file format in an SQLite database so that transactions are atomic even if interrupted by a power loss or system crash. Furthermore, automatic self-checks verify that all aspects of the repository are con- sistent prior to each commit. In over three years of operation, no work has ever been lost after having been committed to a Fossil repository. DOCUMENTATION
http://www.fossil-scm.org/ fossil ui http://fossil-scm.org January 2011 FOSSIL(1)

Check Out this Related Man Page

bcfg2.conf(5)							File Formats Manual						     bcfg2.conf(5)

NAME
bcfg2.conf - 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. Values of 'gamin', 'fam', or 'pseudo' are valid. 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: o Account The account plugin manages authentication data, including: * /etc/passwd * /etc/group * /etc/security/limits.conf * /etc/sudoers * /root/.ssh/authorized_keys o Actions Action entries are commands that are executed either before bundle installation, after bundle installation or both. If exit status is observed, a failing pre-action will cause no modification of the enclosing bundle to be performed; all entries included in that bundle will not be modified. Failing actions are reported through Bcfg2's reporting system, so they can be centrally observed. o BB The BB plugin maps users to machines and metadata to machines. (experimental) o Base 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. o Bundler Bundler is used to describe groups of inter-dependent configuration entries, such as the combination of packages, configu- ration 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. o Bzr 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. o Cfg The Cfg plugin provides a repository to describe configuration file contents for clients. In its simplest form, the Cfg repos- itory is just a directory tree modeled off of the directory tree on your client machines. o Cvs 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. (experimental) o Darcs 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. (experimental) o DBStats Direct to database statistics plugin. (0.9.6 and later) o Decisions 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. (0.9.6 and later) o Deps The Deps plugin allows you to make a series of assertions like "Package X requires Package Y (and optionally also Package Z etc.) o Editor The Editor plugin allows you to partially manage configuration for a file. Its use is not recommended and not well docu- mented. o Fossil The Fossil plugin allows you to track changes to your Bcfg2 repository using a Fossil SCM version control backend. Cur- rently, it enables you to get revision information out of your repository for reporting purposes. o Git 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. o GroupPatterns The GroupPatterns plugin is a connector that can assign clients group membership based on patterns in client host- names. o Hg 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. (experimental) o Hostbase The Hostbase plugin is an IP management system built on top of Bcfg2. o Metadata The Metadata plugin is the primary method of specifying Bcfg2 server metadata. o NagiosGen NagiosGen is a Bcfg2 plugin that dynamically generates Nagios configuration files based on Bcfg2 data. o Ohai The Ohai plugin is used to detect information about the client operating system. The data is reported back to the server using JSON. (experimental) o POSIXCompat The POSIXCompat plugin provides a compatibility layer which turns new-style (1.0) POSIX entries into old-style entries which are compatible with previous releases. o Packages The Packages plugin is an alternative to Pkgmgr for specifying package entries for clients. Where Pkgmgr explicitly spec- ifies package entry information, Packages delegates control of package version information to the underlying package manager, installing the latest version available from through those channels. o Pkgmgr 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. o Probes 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. o Properties The Properties plugin is a connector plugin that adds information from properties files into client metadata instances. (1.0 and later) o Rules The Rules plugin resolves Abstract Configuration Entities to literal configuration entries suitable for the client drivers to consume. o SGenshi (Deprecated) See Bundler. o Snapshots The Snapshots plugin stores various aspects of a client's state when the client checks in to the server. o SSHbase 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. o Svn 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. o TCheetah 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. o TGenshi 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. o Trigger Trigger is a plugin that calls external scripts when clients are configured. prefix Specifies a prefix if the Bcfg2 installation isn't placed in the default location (eg. /usr/local). MDATA OPTIONS
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) perms Global permissions for Paths (defaults to 644) paranoid Global paranoid settings for Paths (defaults to false) sensitive Global sensitive settings for Paths (defaults to false) CLIENT OPTIONS
These options only affect client functionality, specified in the [client] section. decision Specify the server decision list mode (whitelist or blacklist). (This setting 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. STATISTICS OPTIONS
Server-only, specified in the [statistics] section. These options control the statistics collection functionality of the server. database_engine The database engine used by the statistics module. One of either 'postgresql', 'mysql', 'sqlite3', or 'ado_mssql'. database_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 database_user User for database connections. Not used for sqlite3. database_password Password for database connections. Not used for sqlite3. database_host Host for database connections. Not used for sqlite3. database_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). 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 cac- ert 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. serverCommonNames A client-only option. A colon-separated list of Common Names the client will accept in the SSL certificate presented by the server. user A client-only option. The UUID of the client. 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. 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. eg: bcfg2 = https://10.3.1.6:6789 encoding Text encoding of configuration files. Defaults to UTF-8. LOGGING OPTIONS
Specified in the [logging] section. These options control the server logging functionality. path Server log file path. 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 SEE ALSO
bcfg2(1), bcfg2-server(8) bcfg2.conf(5)