neulab/tldr huggingface dataset:
The conversion to UTF8 format used with the name options assumes that T61Strings use the ISO8859-1 character set. This is wrong but Netscape and MSIE do this as do many certificates. So although this is incorrect it is more likely to display the majority of certificates correctly.
The -email option searches the subject name and the subject alternative name extension. Only unique email addresses will be printed out: it will not print the same address more than once.
The -purpose option checks the certificate extensions and determines what the certificate can be used for. The actual checks done are rather complex and include various hacks and workarounds to handle broken certificates and software.
The same code is used when verifying untrusted certificates in chains so this section is useful if a chain is rejected by the verify code.
The basicConstraints extension CA flag is used to determine whether the certificate can be used as a CA. If the CA flag is true then it is a CA, if the CA flag is false then it is not a CA. All CAs should have the CA flag set to true.
If the basicConstraints extension is absent then the certificate is considered to be a "possible CA" other extensions are checked according to the intended use of the certificate. A warning is given in this case because the certificate should really not be regarded as a CA: however it is allowed to be a CA to work around some broken software.
If the certificate is a V1 certificate (and thus has no extensions) and it is self signed it is also assumed to be a CA but a warning is again given: this is to work around the problem of Verisign roots which are V1 self signed certificates.
If the keyUsage extension is present then additional restraints are made on the uses of the certificate. A CA certificate must have the keyCertSign bit set if the keyUsage extension is present.
The extended key usage extension places additional restrictions on the certificate uses. If this extension is present (whether critical or not) the key can only be used for the purposes specified.
A complete description of each test is given below. The comments about basicConstraints and keyUsage and V1 certificates above apply to all CA certificates.
SSL Client The extended key usage extension must be absent or include the "web client authentication" OID.  keyUsage must be absent or it must have the digitalSignature bit set. Netscape certificate type must be absent or it must have the SSL client bit set.
SSL Client CA The extended key usage extension must be absent or include the "web client authentication" OID. Netscape certificate type must be absent or it must have the SSL CA bit set: this is used as a work around if the basicConstraints extension is absent.
SSL Server The extended key usage extension must be absent or include the "web server authentication" and/or one of the SGC OIDs.  keyUsage must be absent or it must have the digitalSignature, the keyEncipherment set or both bits set.  Netscape certificate type must be absent or have the SSL server bit set.
SSL Server CA The extended key usage extension must be absent or include the "web server authentication" and/or one of the SGC OIDs.  Netscape certificate type must be absent or the SSL CA bit must be set: this is used as a work around if the basicConstraints extension is absent.
Netscape SSL Server For Netscape SSL clients to connect to an SSL server it must have the keyEncipherment bit set if the keyUsage extension is present. This isn't always valid because some cipher suites use the key for digital signing.  Otherwise it is the same as a normal SSL server.
Common S/MIME Client Tests The extended key usage extension must be absent or include the "email protection" OID. Netscape certificate type must be absent or should have the S/MIME bit set. If the S/MIME bit is not set in Netscape certificate type then the SSL client bit is tolerated as an alternative but a warning is shown: this is because some Verisign certificates don't set the S/MIME bit.
S/MIME Signing In addition to the common S/MIME client tests the digitalSignature bit or the nonRepudiation bit must be set if the keyUsage extension is present.
S/MIME Encryption In addition to the common S/MIME tests the keyEncipherment bit must be set if the keyUsage extension is present.
S/MIME CA The extended key usage extension must be absent or include the "email protection" OID. Netscape certificate type must be absent or must have the S/MIME CA bit set: this is used as a work around if the basicConstraints extension is absent.
CRL Signing The keyUsage extension must be absent or it must have the CRL signing bit set.
CRL Signing CA The normal CA tests apply. Except in this case the basicConstraints extension must be present.
Extensions in certificates are not transferred to certificate requests and vice versa.
It is possible to produce invalid certificates or requests by specifying the wrong private key or using inconsistent options in some cases: these should be checked.
There should be options to explicitly set such things as start and end dates rather than an offset from the current time.
req(1), ca(1), genrsa(1), gendsa(1), verify(1), x509v3_config(5)
The hash algorithm used in the -subject_hash and -issuer_hash options before OpenSSL 1.0.0 was based on the deprecated MD5 algorithm and the encoding of the distinguished name. In OpenSSL 1.0.0 and later it is based on a canonical version of the DN using SHA1. This means that any directories using the old form must have their links rebuilt using c_rehash or similar.
Licensed under the OpenSSL license (the "License").  You may not use this file except in compliance with the License.  You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.
SERVICE(8)                   System Manager's Manual                  SERVICE(8)
service - run a System V init script
service SCRIPT COMMAND [OPTIONS]
service --status-all
service --help | -h | --version
service runs a System V init script or systemd unit in as predictable an environment as possible, removing most environment variables and with the current working directory set to /.
The SCRIPT parameter specifies a System V init script, located in /etc/init.d/SCRIPT, or the name of a systemd unit. The existence of a systemd unit of the same name as a script in /etc/init.d will cause the unit to take precedence over the init.d script.  The supported values of COMMAND depend on the invoked script. service passes COMMAND  and OPTIONS to the init script unmodified. For systemd units, start, stop, status, and reload are passed through to their systemctl/initctl equivalents.
All scripts should support at least the start and stop commands.  As a special case, if COMMAND is --full-restart, the script is run twice, first with the stop command, then with the start command.
service --status-all runs all init scripts, in alphabetical order, with the status command. The status is [ + ] for running services, [ - ] for stopped services and [ ? ] for services without a status command.  This option only calls status for sysvinit jobs.
service calls the init script and returns the status returned by it.
/etc/init.d The directory containing System V init scripts.
/{lib,run,etc}/systemd/system The directories containing systemd units.
LANG, LANGUAGE, LC_CTYPE, LC_NUMERIC, LC_TIME, LC_COLLATE, LC_MONETARY, LC_MESSAGES, LC_PAPER, LC_NAME, LC_ADDRESS, LC_TELEPHONE, LC_MEASUREMENT, LC_IDENTIFICATION, LC_ALL, TERM, PATH The only environment variables passed to the init scripts.
/etc/init.d/skeleton update-rc.d(8) init(8) invoke-rc.d(8) systemctl(1)
Miloslav Trmac <mitr@redhat.com>, Petter Reinholdtsen <pere@hungry.com>
Licence: GNU Public Licence v2 (GPLv2)
2006 Red Hat, Inc.,  Petter Reinholdtsen <pere@hungry.com>
INITDB(1)                 PostgreSQL 13.4 Documentation                INITDB(1)
initdb - create a new PostgreSQL database cluster
initdb [option...] [--pgdata | -D] directory
initdb creates a new PostgreSQL database cluster. A database cluster is a collection of databases that are managed by a single server instance.
Creating a database cluster consists of creating the directories in which the database data will live, generating the shared catalog tables (tables that belong to the whole cluster rather than to any particular database), and creating the template1 and postgres databases. When you later create a new database, everything in the template1 database is copied. (Therefore, anything installed in template1 is automatically copied into each database created later.) The postgres database is a default database meant for use by users, utilities and third party applications.
Although initdb will attempt to create the specified data directory, it might not have permission if the parent directory of the desired data directory is root-owned. To initialize in such a setup, create an empty data directory as root, then use chown to assign ownership of that directory to the database user account, then su to become the database user to run initdb.
initdb must be run as the user that will own the server process, because the server needs to have access to the files and directories that initdb creates. Since the server cannot be run as root, you must not run initdb as root either. (It will in fact refuse to do so.)
For security reasons the new cluster created by initdb will only be accessible by the cluster owner by default. The --allow-group-access option allows any user in the same group as the cluster owner to read files in the cluster. This is useful for performing backups as a non-privileged user.
initdb initializes the database cluster's default locale and character set encoding. The character set encoding, collation order (LC_COLLATE) and character set classes (LC_CTYPE, e.g., upper, lower, digit) can be set separately for a database when it is created.  initdb determines those settings for the template1 database, which will serve as the default for all other databases.
To alter the default collation order or character set classes, use the --lc-collate and --lc-ctype options. Collation orders other than C or POSIX also have a performance penalty. For these reasons it is important to choose the right locale when running initdb.
The remaining locale categories can be changed later when the server is started. You can also use --locale to set the default for all locale categories, including collation order and character set classes. All server locale values (lc_*) can be displayed via SHOW ALL. More details can be found in Section 23.1.
To alter the default encoding, use the --encoding. More details can be found in Section 23.3.
-A authmethod --auth=authmethod This option specifies the default authentication method for local users used in pg_hba.conf (host and local lines).  initdb will prepopulate pg_hba.conf entries using the specified authentication method for non-replication as well as replication connections.
Do not use trust unless you trust all local users on your system. trust is the default for ease of installation.
--auth-host=authmethod This option specifies the authentication method for local users via TCP/IP connections used in pg_hba.conf (host lines).
--auth-local=authmethod This option specifies the authentication method for local users via Unix-domain socket connections used in pg_hba.conf (local lines).
-D directory --pgdata=directory This option specifies the directory where the database cluster should be stored. This is the only information required by initdb, but you can avoid writing it by setting the PGDATA environment variable, which can be convenient since the database server (postgres) can find the database directory later by the same variable.
-E encoding --encoding=encoding Selects the encoding of the template database. This will also be the default encoding of any database you create later, unless you override it there. The default is derived from the locale, or SQL_ASCII if that does not work. The character sets supported by the PostgreSQL server are described in Section 23.3.1.
-g --allow-group-access Allows users in the same group as the cluster owner to read all cluster files created by initdb. This option is ignored on Windows as it does not support POSIX-style group permissions.
-k --data-checksums Use checksums on data pages to help detect corruption by the I/O system that would otherwise be silent. Enabling checksums may incur a noticeable performance penalty. If set, checksums are calculated for all objects, in all databases. All checksum failures will be reported in the pg_stat_database view.
--locale=locale Sets the default locale for the database cluster. If this option is not specified, the locale is inherited from the environment that initdb runs in. Locale support is described in Section 23.1.
--lc-collate=locale --lc-ctype=locale --lc-messages=locale --lc-monetary=locale --lc-numeric=locale --lc-time=locale Like --locale, but only sets the locale in the specified category.
--no-locale Equivalent to --locale=C.
-N --no-sync By default, initdb will wait for all files to be written safely to disk. This option causes initdb to return without waiting, which is faster, but means that a subsequent operating system crash can leave the data directory corrupt. Generally, this option is useful for testing, but should not be used when creating a production installation.
--pwfile=filename Makes initdb read the database superuser's password from a file. The first line of the file is taken as the password.
-S --sync-only Safely write all database files to disk and exit. This does not perform any of the normal initdb operations.
-T config --text-search-config=config Sets the default text search configuration. See default_text_search_config for further information.
-U username --username=username Selects the user name of the database superuser. This defaults to the name of the effective user running initdb. It is really not important what the superuser's name is, but one might choose to keep the customary name postgres, even if the operating system user's name is different.
-W --pwprompt Makes initdb prompt for a password to give the database superuser. If you don't plan on using password authentication, this is not important. Otherwise you won't be able to use password authentication until you have a password set up.
-X directory --waldir=directory This option specifies the directory where the write-ahead log should be stored.
--wal-segsize=size Set the WAL segment size, in megabytes. This is the size of each individual file in the WAL log. The default size is 16 megabytes. The value must be a power of 2 between 1 and 1024 (megabytes). This option can only be set during initialization, and cannot be changed later.
It may be useful to adjust this size to control the granularity of WAL log shipping or archiving. Also, in databases with a high volume of WAL, the sheer number of WAL files per directory can become a performance and management problem. Increasing the WAL file size will reduce the number of WAL files.
Other, less commonly used, options are also available:
-d --debug Print debugging output from the bootstrap backend and a few other messages of lesser interest for the general public. The bootstrap backend is the program initdb uses to create the catalog tables. This option generates a tremendous amount of extremely boring output.
-L directory Specifies where initdb should find its input files to initialize the database cluster. This is normally not necessary. You will be told if you need to specify their location explicitly.
-n --no-clean By default, when initdb determines that an error prevented it from completely creating the database cluster, it removes any files it might have created before discovering that it cannot finish the job. This option inhibits tidying-up and is thus useful for debugging.
Other options:
-V --version Print the initdb version and exit.
-? --help Show help about initdb command line arguments, and exit.
PGDATA Specifies the directory where the database cluster is to be stored; can be overridden using the -D option.
PG_COLOR Specifies whether to use color in diagnostic messages. Possible values are always, auto and never.
TZ Specifies the default time zone of the created database cluster. The value should be a full time zone name (see Section 8.5.3).
This utility, like most other PostgreSQL utilities, also uses the environment variables supported by libpq (see Section 33.14).
initdb can also be invoked via pg_ctl initdb.
pg_ctl(1), postgres(1)
FLATPAK-BUILDER(1)               flatpak builder              FLATPAK-BUILDER(1)
flatpak-builder - Help build application dependencies
flatpak-builder [OPTION...] DIRECTORY MANIFEST
flatpak-builder --run [OPTION...] DIRECTORY MANIFEST COMMAND
flatpak-builder --show-deps [OPTION...] MANIFEST
flatpak-builder --show-manifest [OPTION...] MANIFEST
flatpak-builder is a wrapper around the flatpak build command that automates the building of applications and their dependencies. It is one option you can use to build applications.
The goal of flatpak-builder is to push as much knowledge about how to build modules to the individual upstream projects. It does this by assuming that the modules adhere to the Build API specified at https://github.com/cgwalters/build-api. This essentially means that it follows the ./configure && make && make install scheme with an optional autogen script. If the upstream does not adhere to the API you can make it do so by adding patches and extra files.
An invocation of flatpak-builder proceeds in these stages, each being specified in detail in json format in MANIFEST:
•   Download all sources
•   Initialize the application directory with flatpak build-init
•   Build and install each module with flatpak build
•   Clean up the final build tree by removing unwanted files and e.g. stripping binaries
•   Finish the application directory with flatpak build-finish
After this you will end up with a build of the application in DIRECTORY, which you can export to a repository with the flatpak build-export command. If you use the --repo option, flatpak-builder will do the export for you at the end of the build process. When flatpak-builder does the export, it also stores the manifest that was used for the build in /app/manifest.json. The manifest is 'resolved', i.e. git branch names are replaced by the actual commit IDs that were used in the build.
At each of the above steps flatpak caches the result, and if you build the same file again, it will start at the first step where something changes. For instance the first version controlled source that had new commits added, or the first module where some changes to the MANIFEST file caused the build environment to change. This makes flatpak-builder very efficient for incremental builds.
When building a flatpak to be published to the internet, --collection-id=COLLECTION-ID should be specified as a globally unique reverse DNS value to identify the collection of flatpaks this will be added to. Setting a globally unique collection ID allows the apps in the repository to be shared over peer to peer systems without needing further configuration.
The manifest file is a json or yaml file whose format is described in detail in its own manual page.
-h, --help Show help options and exit.
-v, --verbose Print debug information during command processing.
--version Print version information and exit.
--arch=ARCH Specify the machine architecture to build for. If no architecture is specified, the host architecture will be automatically detected. Only host compatible architectures can be specified.
--default-branch=BRANCH Set the default branch to BRANCH. This is used if the manifest does not specify a branch. The default is master.
--disable-cache Don't look at the existing cache for a previous build, instead always rebuild modules.
--disable-rofiles-fuse Disable the use of rofiles-fuse to optimize the cache use via hardlink checkouts.
--disable-download Don't download any sources. This only works if some version of all sources are downloaded already. This is useful if you want to guarantee that no network i/o is done. However, the build will fail if some source is not locally available.
--disable-updates Download missing sources, but don't update local mirrors of version control repos. This is useful to rebuild things but without updating git, bzr or svn repositories from the remote repository.
--disable-tests Don't run any of the tests.
--run Run a command in a sandbox based on the build dir. This starts flatpak build, with some extra arguments to give the same environment as the build, and the same permissions the final app will have (except filesystem permissions). The command to run must be the last argument passed to flatpak-builder, after the directory and the manifest.
Only the --arch=ARCH, --ccache and --verbose options can be combined with this option.
--build-shell=MODULENAME Extract and prepare the sources for the named module, and then start a shell in a sandbox identical to the one flatpak-builder would use for building the module. This is useful to debug a module.
--show-deps List all the (local) files that the manifest depends on.
Only the --verbose option can be combined with this option.
--show-manifest Loads the manifest, including any included files and prints it in a canonical json format. This is useful for tools that want to handle manifest files to avoid having to support both yaml and json, as well as some non-standard json handling that is supported (for example comments and multiline strings).
--download-only Exit successfully after downloading the required sources.
--bundle-sources Create an additional runtime with the source code for this module. It will be named app-id.Sources, for example org.gnome.Maps.Sources.
--build-only Don't do the cleanup and finish stages, which is useful if you want to build more things into the app.
--finish-only Only do the cleanup, finish and export stages, picking up where a --build-only command left off.
--export-only Only do the export stages, picking up the build result from a previous build. This can be used to split the build and export/signature into two calls by leaving out --repo in the first call.
--require-changes Do nothing, leaving a non-existent DIRECTORY if nothing changes since last cached build. If this is not specified, the latest version from the cache will be put into DIRECTORY.
--state-dir=PATH Use this directory for storing state (downloads, build dirs, build cache, etc) rather than .flatpak-builder. This can be an absolute or relative path, but must be on the same filesystem as the specified target DIRECTORY.
--keep-build-dirs Don't remove the sources and build after having built and installed each module. This also creates a symlink to the build directory with a stable name ("build-modulename").
--delete-build-dirs Always remove the sources and build after having built each module, even if the build failed. The default is to keep failed build directories but remove successful ones. This is useful in e.g. automatic build systems.
--ccache Enable use of ccache in the build (needs ccache in the sdk). The default ccache folder can be overridden by setting the environment variable CCACHE_DIR.
--stop-at=MODULENAME Stop at the specified module, ignoring it and all the following ones in both the "download" and "build" phases. This is useful for debugging and development. For instance, you can build all the dependencies, but stop at the main application so that you can then do a build from a pre-existing checkout. Implies --build-only.
--repo=DIR After the build finishes, run flatpak build-export to export the result to the repository DIR. If DIR exists, it must be an OSTree repository; otherwise a new one will be created.
-s, --subject=SUBJECT One line subject for the commit message. Used when exporting the build results.
-b, --body=BODY Full description for the commit message. Used when exporting the build results.
--collection-id=COLLECTION-ID Set as the collection ID of the repository. Setting a globally unique collection ID allows the apps in the repository to be shared over peer to peer systems without needing further configuration. If building in an existing repository, the collection ID must match the existing configured collection ID for that repository.
--token-type=VAL Set type of token needed to install this commit. Setting this to a value greater than 0 implies that authentication will be needed to install the flatpak. A token-type property set in the manifest takes precedence over this option. Used when exporting the build results.
--gpg-sign=KEYID Sign the commit with this GPG key. Used when exporting the build results. This option can be used multiple times.
--gpg-homedir=PATH GPG Homedir to use when looking for keyrings. Used when exporting the build results.
--jobs=JOBS Limit the number of parallel jobs during the build. The default is the number of CPUs on the machine.
--force-clean Erase the previous contents of DIRECTORY if it is not empty.
--sandbox Disable the possibility to specify build-args that are passed to flatpak build. This means the build process can't break out of its sandbox, and is useful when building less trusted software.
--allow-missing-runtimes Do not immediately fail if the sdk or platform runtimes are not installed on this system. Attempting to build any manifest modules will still fail if the sdk is missing, but may be useful for apps that install files without a sandbox build.
--rebuild-on-sdk-change Record the exact version of the sdk in the cache, and rebuild everything if it changes. This is useful if you're building against an API-unstable runtime, like a nightly build.
--skip-if-unchanged If the json is unchanged since the last build of this filename, then do nothing, and return exit code 42.
--mirror-screenshots-url=URL Mirror any screenshots in the appstream and rewrite the appstream xml as if they were on the specified URL. The resulting files will be stored in the "screenshots" subdirectory in the app directory and needs to be copied to the specified URL for the appdata to work.
--extra-sources=SOURCE-DIR When downloading sources (archives, files, git, bzr, svn), look in this directory for pre-existing copies and use them instead of downloading.
--extra-sources-url=URL When downloading sources (archives, files, git, bzr, svn), look at this url for mirrored downloads before downloading from the original url.
--from-git=GIT Look for the manifest in the given git repository. If this option is given, MANIFEST is interpreted as a relative path inside the repository.
--from-git-branch=BRANCH The branch to use with --from-git.
--no-shallow-clone Don't use shallow clones when mirroring git repos.
--add-tag=TAG Add this tag to the tags list of the manifest before building.
--remove-tag=TAG Remove this tag to the tags list of the manifest before building. The remove happen before processing the --add-tag option, so if both are specified, then --app-tag wins.
--install-deps-from=REMOTE Install/update build required dependencies from the specified remote.
--install-deps-only Stop after downloading dependencies.
--install When the build is finished, install the result locally.
--user Install the dependencies in a per-user installation.
--system Install the dependencies in the default system-wide installation.
--installation=NAME Install the dependencies in a system-wide installation specified by NAME among those defined in /etc/flatpak/installations.d/. Using --installation=default is equivalent to using --system.
flatpak-builder caches sources and partial build results in the state directory (defaulting to the .flatpak-builder subdirectory of the current directory). If you use --keep-build-dirs, build directories for each module are also stored here.
It is safe to remove the state directory. This will force a full build the next time you build.
$ flatpak-builder my-app-dir manifest.json
Example manifest file:
{ "id": "org.test.TestApp", "runtime": "org.freedesktop.Platform", "runtime-version": "1.2", "sdk": "org.freedesktop.Sdk", "command": "test", "cleanup": [ "/include", "*.la" ], "build-options" : { "cflags": "-O2 -g", "cxxflags": "-O2 -g", "env": { "V": "1" }, "arch": { "x86_64": { "cflags": "-O3 -g", } } }, "modules": [ { "name": "pygobject", "config-opts": [ "--disable-introspection" ], "sources": [ { "type": "archive", "url": "http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.28/pygobject-2.28.6.tar.xz", "sha256": "fb8a1d4f665130a125011659bd347c7339c944232163dbb9a34fd0686577adb8" }, { "type": "patch", "path": "required-pygobject-fix.patch" }, { "type": "file", "path": "pygobject-extra-file", "dest-filename": "extra-file" } ] }, { "name": "babl", "build-options" : { "cxxflags": "-O2 -g -std=c++11" }, "cleanup": [ "/bin" ], "sources": [ { "type": "git", "url": "https://gitlab.gnome.org/GNOME/babl.git" } ] }, { "name": "testapp", "sources": [ { "type": "bzr", "url": "lp:testapp" } ] } ] }
flatpak(1), flatpak-manifest(5), flatpak-build-init(1), flatpak-build(1), flatpak-build-finish(1), flatpak-build-export(1)
RVM(1)                       General Commands Manual                      RVM(1)
rvm - rsync vault manager
rvm [ action ] [ --timestamp timestamp ] [ --no-default-config ] [ [ --config config-file ] ... ] [ [ --job job-file ] ... ]
Rvm is an archive manager that uses rsync to create and maintain a list of archives that span one or more archive vaults.  A vault is defined as a directory on a logical partition that holds one or more archives.  An archive is defined as a subdirectory on a vault, with a time stamp for a name, that holds the files and directories backed up from one or more archive jobs.  Files in newer archives that are identical to files in older archives may be optionally replaced with hard links to save space.
Rvm will expect one action command line option to be given.  Actions are mutually exclusive.  If multiple action options appear on the command line, only the last option encountered will be taken.
--archive
Create a new archive or update the files in an existing archive. Whether an existing archive is updated or a new archive is created depends on the timestamp-resolution configuration command, and the timestamp of the last archive created.  If an archive is found with the same timestamp as the one generated at execution time, then that archive is used regardless of the vault on which it appears.
If the link-catalog-dir configuration command is used, then the link catalog is updated after all archive jobs have been processed.
--relink
Update the link catalog.  Do not create a new archive or refresh any existing archive.  This option requires that the configuration command link-catalog-dir appear somewhere in the configuration file(s).  This command is not required and has no default value.  If no value is specified in a configuration file then rvm will take no action.
--check-config
Load the configuration file(s) and perform all configuration checks, but do nothing more.  Rvm will print an error on standard error and exit with an error code if any problems were found with the configuration settings.  Rvm will print nothing and exit with a successful exit code if there are no problems.
Print the version number and a synopsis of command line options, then exit.
Print the version number then exit.
The following command line options are used in conjunction with one of the action options to direct rvm's behavior.
--timestamp timestamp
Override the default timestamp generated at execution time and force rvm to use the given timestamp instead.  This option may only be used on the command line once.  If it appears multiple times then only the last timestamp given will be used.
Timestamps must be specified in the form of:
[ YYYY [ - MM [ - DD [ .  HH [ MM [ SS ]]]]]]
YYYY A four-digit year.
MM A two-digit month.
DD A two-digit day of the month.
HH A two-digit hour of the day, in 24-hour format (00-23).
MM A two-digit minute.
SS A two-digit second.
No spaces are allowed.  The number of segments specified in the timestamp will override any timestamp-resolution setting that may appear in the configuration files.  Caution should be used by the archive manager when specifying custom timestamps on the command line, as specifying a timestamp of lesser resolution than the timestamp resolution normally used from the configuration file(s), could result in the archive generated from the custom timestamp being the first archive deleted by rvm later when the vault exceeds it's overflow threshold.
--no-default-config
Do not attempt to read configuration information from the default configuration file /usr/local/etc/rvm.conf.  This command line option must be used in conjunction with the --config command line option to tell rvm to read another configuration file instead of the default configuration file.  Rvm will exit with an error if no configuration files are read.
--config config-file
Read configuration information from config-file.  If used without the --no-default-config option, rvm will read the configuration file config-file after attempting to read the default configuration file /usr/local/etc/rvm.conf.  If used with --no-default-config, rvm will read only config-file, and will not read /usr/local/etc/rvm.conf. Multiple uses of this command line option will result in rvm reading each file passed on the command line in the order given.
If config-file is a relative pathname, then it is assumed to be relative to the location from which rvm is executed.  If config-file contains wildcard characters, then all files that match will be read in alphabetical order.  Note that wildcard characters must either be quoted or escaped or the shell may expand it's value before passing the command line to rvm, which may result in undesired behavior.
This command line option may be used multiple times to have rvm read several configuration files.
--job job-file
Read the contents of job-file as the contents of an archive job block. This command line option is synonymous with the read-job configuration command.  Contents of the file job-file should not be enclosed in a <job>...</job> block, as a job context is already implied.  If a beginning or ending job block command is found in the job-file file, then rvm will exit with an error.
If job-file is a relative pathname, then it is assumed to be relative to the location from which rvm is executed.  If job-file contains wildcard characters, then all files that match will be read in alphabetical order, each as a separate job.  Note that wildcard characters given on the command line must either be quoted or escaped or the shell may expand it's value before passing the command line to rvm, which may result in undesired behavior.
This command line option may be used multiple times to have rvm read several job files.
Archive Administrator
The user in charge of setup and maintenance of rvm and all associated files and directories.
A file used to change rvm's behavior.  Multiple configuration files may be used, and each file may include the contents of other files.  By default rvm will look for the file /usr/local/etc/rvm.conf, unless told to do otherwise by the --no-default-config command line option.  Rvm may also be told to read extra configuration files with the --config and --job command line options.
A repository for archives.  A vault is merely a directory under which archives are created and maintained.  One or more vaults may be used. When using multiple vaults it is recommended that each vault be located either on separate physical devices, or at least separate logical partitions, for increased reliability in the event of disk corruption or failure.
An archive is a subdirectory within a vault, with a time-sensitive directory name, that houses the files and directories from one or more archive jobs.  The name of the archive subdirectory is generated from the timestamp created at the time that rvm is executed.  An archive may optionally contain hardlinks from files within to files in an older archive if the file has not changed.
Archive Job
An archive job consists of files and directories that are to be backed up from some source.  A job may consist of local files and directories, or files and directories mounted over NFS or Samba, or files and directory located on a remote host accessible by rsync via RSH or SSH, or files and directories located on an rsync server.  The files and directories backed up from the specified source may be stored in a user-configurable subdirectory tree under the archive directory.
When rvm is executed it will first set default values for all configuration settings.  Next rvm will parse command line options.
If rvm was executed with the --help or --version command line options, then rvm will print out it's version number, and optionally a usage summary, then exit.
If any other action options were selected, then rvm will next try to read configuration files.  If the --no-default-config command line option was used then rvm will not try to read the default configuration file, /usr/local/etc/rvm.conf.  Otherwise, rvm will attempt to locate and read this file first.  If this file cannot be found, rvm will exit with an error.  Next, if any --config or --job command line options were used then rvm will attempt to find and read those configuration files.  If any errors were detected in any of the configuration files found then rvm will exit with an error.
If rvm was executed with the --check-config option, then rvm will exit after successfully reading all configuration files.
If the --relink action was selected, and a valid directory was given for link-catalog-dir in the configuration file(s), then rvm will rebuild the link catalog directory and exit.
If the --archive action was selected, then rvm will begin the archiving process.  Rvm will next select a vault and prepare that vault for a new archive.  Vault selection may be modified with the vault-selection- behavior configuration command.  Vaults may be selected round-robin style, where each vault listed in rvm's configuration files will be used in turn, or vaults may be selected on the grounds of which vault has the most free space available.
Vault preparation involves checking the vault for available space, as specified with the vault-overflow-blocks and vault-overflow-inodes configuration commands.  If the filesystem on which the selected vault resides has fewer than the specified percentage of free blocks or inodes, then the vault is considered to have exceeded it's overflow threshold. If this condition occurs, then rvm will take the action specified by the vault-overflow-behavior configuration command.  Depending on this configuration setting, rvm may take one of three actions.  By default, rvm will simply exit with an error.  Rvm may also be instructed to delete the oldest archive found on the selected vault and re-check the filesystem's available space.  If, after deleting the oldest archive found, the filesystem's used space has fallen below the overflow threshold, then rvm will continue with execution; otherwise rvm will exit with an error.  Lastly, and most dangerously, rvm may be instructed to continue deleting old archives until either sufficient space is found or the vault runs out of old archives.
After vault selection and preparation, rvm will create a new archive subdirectory on the vault using either the timestamp given by the --timestamp command line option, or a generated timestamp constructed according to the timestamp-resolution configuration command.  For the duration of the archival process the archive subdirectory name will be appended with the extension ".incomplete".
Next rvm will spawn children to process archiving jobs.  Each child will handle a single job and archive all the paths associated with that job, and then send a report back to the parent rvm process.  By default, rvm will only spawn one child process at a time unless specified otherwise with the rsync-parallel configuration command.  If the rsync-hardlink command appears in the job configuration for this job, or in a previous default job configuration, then the child rvm process will select an older archive on the same vault to use as a hardlink source for rsync. This can save space within the vault by hardlinking files that have not changed from one invocation of rvm to the next.
Each child will interpret rsync's output and exit codes, and if unsuccessful, the child may retry the command a certain number of times before giving up, as specified by the rsync-retry-count and rsync- behavior configuration commands.
After all jobs have completed rvm will rename the archive directory, removing the ".incomplete" extension.  Then, rvm may optionally create or update the link catalog directory, if link-catalog-dir configuration command was found in the configuration file(s).
Finally, rvm will generate a report that it will print to standard output and save to a file in the log directory.
Exit codes returned by rvm are:
0 Successful completion of all archive jobs.
1 A configuration error occurred.
2 The selected vault is full.
3 One or more archive jobs failed.
4 An internal or fatal error occurred.
Rvm is configured through the use of one or more configuration files.  By default rvm will search for the file /usr/local/etc/rvm.conf, unless this behavior is overridden by the use of the --no-default-config command line option.  If /usr/local/etc/rvm.conf does not exist then rvm will search for files passed to it using the --config and --job command line options. If no configuration files can be found then rvm will exit with an error.
Blank lines and lines that begin with a '#' are ignored.
A configuration file may include the contents of another file, or a configuration file may include the contents of all files that match a wildcard filename.  Included files may in turn include more files.  (Note that reading the contents of included files is done recursively, meaning that it is possible for rvm to exceed it's stack size, resulting in an error.)
All configurable settings are listed on a single line in the form of keyword-value pairs unless specified otherwise.  Each line begins with a case-insensitive keyword followed by a value and a newline character '\n'.  White space is ignored except for certain values that may be specified using double quotes.  Some configuration commands are required to appear in a configuration file, others have default values that are assumed.  Some configuration commands may be used multiple times, for others, multiple use will override that command's previous settings.
Configuration commands are context-sensitive.  A configuration file consists of three sections: a global section, one or more default sections, and one or more job sections.  Some configuration commands are allowed in any context, while others may only be used in a default or job context.
These are commands that may appear anywhere in a configuration file in any context.
Stop reading the current configuration file and read the contents of the file path.  When finished, continue reading the current file.
If path is a relative pathname, then it is assumed to be relative to the directory of the configuration file in which this command is found.  This is in contrast to the --config and --job command line options, where a relative pathname is assumed to be relative to the directory from which rvm is executed.
If path contains wildcard characters, then each matching file found will be read in alphabetical order.  If no files are found, then rvm will exit with an error.  Included files may in turn contain commands to include other files.  Multiple uses of this command are allowed. This command is not required, and has no default value.
When including the contents of another file, rvm behaves as though the file included were literally pasted into the current file at the current location.  If an included file changes the configuration context then the new context remains in effect when rvm finishes reading the included file and continues with the current file.  This must be taken into account when authoring configuration files or at best, an error will occur, and at worst, confusing and undesired effects may occur.
When rvm begins reading the first configuration file it assumes a global context until a default or job context is specified.  Global commands affect the overall behavior of rvm, such as the method used to select vaults, the location of the local rsync binary, or the number of jobs to process in parallel.  This is in contrast to default or job contexts, where commands affect the behavior of rvm's children as they process a particular job.
<default>...</default>
Configuration settings in a default context are specified by placing those settings inside a default block.  A default block begins with the text "<default>" on a line by itself, and ends with the text "</default>" on another line by itself.  Lines in between are applied to the default settings.  These default settings will be assumed by all jobs that follow until another default block is encountered. Commands given in a default block may be overridden by commands found within a job block, but this override will not affect other jobs that follow.
The settings used in a default block are only changed by the appearance of another default block.  When another default block is encountered, all default settings not specified in the new default block are reset, settings from previous default blocks do not carry over into the new default block.
This command is not required, and if not used the following values are assumed:
<default> archive-path hostname/path rsync-behavior * = retry rsync-behavior 0 = ok rsync-behavior 1 = fail rsync-behavior 2 = fail rsync-behavior 4 = fail rsync-behavior 23 = retry-without-hardlinks rsync-behavior 124 = fail rsync-behavior 125 = fail rsync-behavior 126 = fail rsync-behavior 127 = fail rsync-connection-type remote rsync-hardlink yes rsync-retry-count 3 # # 14400 = 60 sec/min * 60 min/hr * 4 = 4 hours # rsync-timeout 14400 </default>
Default values may themselves be reset to rvm's built-in default values by specifying an empty default block, like so:
<default> </default>
include-job path
Stop reading the current configuration file, assume a job context, and read the contents of the file path.  When finished, switch back to a global context and continue reading the current configuration file.
This command may be thought of as a one line short cut for the following:
<job> include path </job>
If path is a relative pathname, then it is assumed to be relative to the directory of the configuration file in which this command appears.  This is in contrast to the --job command line option, where job-file is assumed to be relative to the location from which rvm is executed.
If path contains wildcard characters, then each matching file found will be included in alphabetical order as a separate job.  If no matching files are found then rvm will exit with an error.
Multiple uses of this command will append new jobs to the job list.
<job>...</job>
Configuration settings in a job context are specified by placing those settings inside a job block.  A job block begins with the text "<job>" on a line by itself, and ends with the text "</job>" on another line by itself.  When rvm encounters a job block in a configuration file a new job is created and appended to the job list. The newly created job will assume default values either from rvm or from the last default block encountered.  After default values have been assigned then the commands inside the job block are read and their settings applied.
link-catalog-dir path
If this command is found, then rvm will create a catalog of all archives from all vaults in the directory path using relative symbolic links.  If path does not exist, then rvm will exit with an error.  If path is a relative pathname, then it is assumed to be relative to the location from which rvm is executed.
This command is not required and has no default value.  Multiple uses of this command will overwrite any previous value.
NOTICE: If the archive administrator chooses to export the path directory to other hosts, then all vault directories must also be exported.  Also, these directories must be mounted on remote machines in such a way that will preserve the validity of the relative symbolic links in path.
log-dir path
Create log files under the directory path.  Rvm will use /var/log/rvm if no other setting is found.  Multiple uses of this command will overwrite any previous value.  If path is a relative pathname, then it is assumed to be relative to the location from which rvm is executed.