caddy-file-server

title: caddy-file-server(8)

text:
# caddy-file-server(8)

## NAME
caddy-file-server - Spins up a production-ready file server

## SYNOPSIS
caddy file-server [--domain ] [--root ] [--listen ] [--browse] [--reveal-symlinks] [--access-log] [--precompressed] [flags]

## DESCRIPTION
A simple but production-ready file server. Useful for quick deployments, demos, and development.

The listener's socket address can be customized with the --listen flag.

If a domain name is specified with --domain, the default listener address will be changed to the HTTPS port and the server will use HTTPS. If using a public domain, ensure A/AAAA records are properly configured before using this option.

By default, Zstandard and Gzip compression are enabled. Use --no-compress to disable compression.

If --browse is enabled, requests for folders without an index file will respond with a file listing.

## OPTIONS
-a, --access-log[=false] Enable the access log

-b, --browse[=false] Enable directory browsing

-v, --debug[=false] Enable verbose debug logs

-d, --domain="" Domain name at which to serve the files

-f, --file-limit=10000 Max directories to read

-h, --help[=false] help for file-server

-l, --listen="" The address to which to bind the listener

--no-compress[=false] Disable Zstandard and Gzip compression

-p, --precompressed=[] Specify precompression file extensions. Compression preference implied from flag order.

--reveal-symlinks[=false] Show symlink paths when browse is enabled.

-r, --root="" The path to the root of the site

-t, --templates[=false] Enable template rendering

## SEE ALSO
caddy(8), caddy-file-server-export-template(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-file-server-export-template

package: caddy

title: caddy-file-server-export-template(8)

text:
# caddy-file-server-export-template(8)

## NAME
caddy-file-server-export-template - Exports the default file browser template

## SYNOPSIS
caddy file-server export-template [flags]

## DESCRIPTION
Exports the default file browser template

## OPTIONS
-h, --help[=false] help for export-template

## EXAMPLE

```
caddy file-server export-template > browse.html
```

## SEE ALSO
caddy-file-server(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra

branch: sisyphus


caddy-fmt

title: caddy-fmt(8)

text:
# caddy-fmt(8)

## NAME
caddy-fmt - Formats a Caddyfile

## SYNOPSIS
caddy fmt [--overwrite] [--diff] [] [flags]

## DESCRIPTION
Formats the Caddyfile by adding proper indentation and spaces to improve human readability. It prints the result to stdout.

If --overwrite is specified, the output will be written to the config file directly instead of printing it.

If --diff is specified, the output will be compared against the input, and lines will be prefixed with '-' and '+' where they differ. Note that unchanged lines are prefixed with two spaces for alignment, and that this is not a valid patch format.

If you wish to use stdin instead of a regular file, use - as the path. When reading from stdin, the --overwrite flag has no effect: the result is always printed to stdout.

## OPTIONS
-c, --config="" Configuration file

-d, --diff[=false] Print the differences between the input file and the formatted output

-h, --help[=false] help for fmt

-w, --overwrite[=false] Overwrite the input file with the results

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-hash-password

title: caddy-hash-password(8)

text:
# caddy-hash-password(8)

## NAME
caddy-hash-password - Hashes a password and writes base64

## SYNOPSIS
caddy hash-password [--plaintext ] [--algorithm ] [--bcrypt-cost ] [--argon2id-time ] [--argon2id-memory ] [--argon2id-threads ] [--argon2id-keylen ] [flags]

## DESCRIPTION
Convenient way to hash a plaintext password. The resulting hash is written to stdout as a base64 string.

--plaintext

The password to hash. If omitted, it will be read from stdin.

If Caddy is attached to a controlling TTY, the input will not be echoed.

--algorithm

Selects the hashing algorithm. Valid options are:

* 'argon2id' (recommended for modern security)

* 'bcrypt' (legacy, slower, configurable cost)

bcrypt-specific parameters:

--bcrypt-cost

Sets the bcrypt hashing difficulty. Higher values increase security by

making the hash computation slower and more CPU-intensive.

Must be within the valid range [bcrypt.MinCost, bcrypt.MaxCost].

If omitted or invalid, the default cost is used.

Argon2id-specific parameters:

--argon2id-time

Number of iterations to perform. Increasing this makes

hashing slower and more resistant to brute-force attacks.

--argon2id-memory

Amount of memory to use during hashing.

Larger values increase resistance to GPU/ASIC attacks.

--argon2id-threads

Number of CPU threads to use. Increase for faster hashing

on multi-core systems.

--argon2id-keylen

Length of the resulting hash in bytes. Longer keys increase

security but slightly increase storage size.

## OPTIONS
-a, --algorithm="bcrypt" Name of the hash algorithm

--argon2id-keylen=32 Length of the resulting Argon2id hash in bytes. Longer hashes increase security but slightly increase storage size.

--argon2id-memory=47104 Memory to use in KiB for Argon2id hashing. Larger values increase resistance to GPU/ASIC attacks.

--argon2id-threads=1 Number of CPU threads to use for Argon2id hashing. Increase for faster hashing on multi-core systems.

--argon2id-time=1 Number of iterations for Argon2id hashing. Increasing this makes the hash slower and more resistant to brute-force attacks.

--bcrypt-cost=14 Bcrypt hashing cost (only used with 'bcrypt' algorithm)

-h, --help[=false] help for hash-password

-p, --plaintext="" The plaintext password

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-list-modules

title: caddy-list-modules(8)

text:
# caddy-list-modules(8)

## NAME
caddy-list-modules - Lists the installed Caddy modules

## SYNOPSIS
caddy list-modules [--packages] [--versions] [--skip-standard] [--json] [flags]

## DESCRIPTION
Lists the installed Caddy modules

## OPTIONS
-h, --help[=false] help for list-modules

--json[=false] Print modules in JSON format

--packages[=false] Print package paths

-s, --skip-standard[=false] Skip printing standard modules

--versions[=false] Print version information

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-manpage

title: caddy-manpage(8)

text:
# caddy-manpage(8)

## NAME
caddy-manpage - Generates the manual pages for Caddy commands

## SYNOPSIS
caddy manpage --directory [flags]

## DESCRIPTION
Generates the manual pages for Caddy commands into the designated directory tagged into section 8 (System Administration).

The manual page files are generated into the directory specified by the argument of --directory. If the directory does not exist, it will be created.

## OPTIONS
-o, --directory="" The output directory where the manpages are generated

-h, --help[=false] help for manpage

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-reload

title: caddy-reload(8)

text:
# caddy-reload(8)

## NAME
caddy-reload - Changes the config of the running Caddy instance

## SYNOPSIS
caddy reload --config [--adapter ] [--address ] [flags]

## DESCRIPTION
Gives the running Caddy instance a new configuration. This has the same effect as POSTing a document to the /load API endpoint, but is convenient for simple workflows revolving around config files.

Since the admin endpoint is configurable, the endpoint configuration is loaded from the --address flag if specified; otherwise it is loaded from the given config file; otherwise the default is assumed.

## OPTIONS
-a, --adapter="" Name of config adapter to apply

--address="" Address of the administration listener, if different from config

-c, --config="" Configuration file (required)

-f, --force[=false] Force config reload, even if it is the same

-h, --help[=false] help for reload

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-remove-package

title: caddy-remove-package(8)

text:
# caddy-remove-package(8)

## NAME
caddy-remove-package - Removes Caddy packages (EXPERIMENTAL)

## SYNOPSIS
caddy remove-package [flags]

## DESCRIPTION
Downloads an updated Caddy binaries without the specified packages (module/plugin). Returns an error if any of the packages are not included. EXPERIMENTAL: May be changed or removed.

## OPTIONS
-h, --help[=false] help for remove-package

-k, --keep-backup[=false] Keep the backed up binary, instead of deleting it

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-respond

title: caddy-respond(8)

text:
# caddy-respond(8)

## NAME
caddy-respond - Simple, hard-coded HTTP responses for development and testing

## SYNOPSIS
caddy respond [--status ] [--body ] [--listen ] [--access-log] [--debug] [--header "Field: value"] [flags]

## DESCRIPTION
Spins up a quick-and-clean HTTP server for development and testing purposes.

With no options specified, this command listens on a random available port and answers HTTP requests with an empty 200 response. The listen address can be customized with the --listen flag and will always be printed to stdout. If the listen address includes a port range, multiple servers will be started.

If a final, unnamed argument is given, it will be treated as a status code (same as the --status flag) if it is a 3-digit number. Otherwise, it is used as the response body (same as the --body flag). The --status and --body flags will always override this argument (for example, to write a body that literally says "404" but with a status code of 200, do '--status 200 404').

A body may be given in 3 ways: a flag, a final (and unnamed) argument to the command, or piped to stdin (if flag and argument are unset). Limited template evaluation is supported on the body, with the following variables:

```
{{.N}}        The server number (useful if using a port range)
{{.Port}}     The listener port
{{.Address}}  The listener address
```

(See the docs for the text/template package in the Go standard library for information about using templates: https://pkg.go.dev/text/template)

Access/request logging and more verbose debug logging can also be enabled.

Response headers may be added using the --header flag for each header field.

## OPTIONS
--access-log[=false] Enable the access log

-b, --body="" The body of the HTTP response

-v, --debug[=false] Enable more verbose debug-level logging

-H, --header=[] Set a header on the response (format: "Field: value")

-h, --help[=false] help for respond

-l, --listen=":0" The address to which to bind the listener

-s, --status=200 The response status code

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-reverse-proxy

title: caddy-reverse-proxy(8)

text:
# caddy-reverse-proxy(8)

## NAME
caddy-reverse-proxy - A quick and production-ready reverse proxy

## SYNOPSIS
caddy reverse-proxy [--from ] [--to ] [--change-host-header] [--insecure] [--internal-certs] [--disable-redirects] [--header-up "Field: value"] [--header-down "Field: value"] [--access-log] [--debug] [flags]

## DESCRIPTION
A simple but production-ready reverse proxy. Useful for quick deployments, demos, and development.

Simply shuttles HTTP(S) traffic from the --from address to the --to address. Multiple --to addresses may be specified by repeating the flag.

Unless otherwise specified in the addresses, the --from address will be assumed to be HTTPS if a hostname is given, and the --to address will be assumed to be HTTP.

If the --from address has a host or IP, Caddy will attempt to serve the proxy over HTTPS with a certificate (unless overridden by the HTTP scheme or port).

If serving HTTPS:

--disable-redirects can be used to avoid binding to the HTTP port.

--internal-certs can be used to force issuance certs using the internal

CA instead of attempting to issue a public certificate.

For proxying:

--header-up can be used to set a request header to send to the upstream.

--header-down can be used to set a response header to send back to the client.

--change-host-header sets the Host header on the request to the address

of the upstream, instead of defaulting to the incoming Host header. This is a shortcut for --header-up "Host: {http.reverse_proxy.upstream.hostport}".

--insecure disables TLS verification with the upstream. WARNING: THIS

DISABLES SECURITY BY NOT VERIFYING THE UPSTREAM'S CERTIFICATE.

## OPTIONS
--access-log[=false] Enable the access log

-c, --change-host-header[=false] Set upstream Host header to address of upstream

-v, --debug[=false] Enable verbose debug logs

-r, --disable-redirects[=false] Disable HTTP->HTTPS redirects

-f, --from="localhost" Address on which to receive traffic

-d, --header-down=[] Set a response header to send back to the client (format: "Field: value")

-H, --header-up=[] Set a request header to send to the upstream (format: "Field: value")

-h, --help[=false] help for reverse-proxy

--insecure[=false] Disable TLS verification (WARNING: DISABLES SECURITY BY NOT VERIFYING TLS CERTIFICATES!)

-i, --internal-certs[=false] Use internal CA for issuing certs

-t, --to=[] Upstream address(es) to which traffic should be sent

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-run

title: caddy-run(8)

text:
# caddy-run(8)

## NAME
caddy-run - Starts the Caddy process and blocks indefinitely

## SYNOPSIS
caddy run [--config [--adapter ]] [--envfile ] [--environ] [--resume] [--watch] [--pidfile ] [flags]

## DESCRIPTION
Starts the Caddy process, optionally bootstrapped with an initial config file, and blocks indefinitely until the server is stopped; i.e. runs Caddy in "daemon" mode (foreground).

If a config file is specified, it will be applied immediately after the process is running. If the config file is not in Caddy's native JSON format, you can specify an adapter with --adapter to adapt the given config file to Caddy's native format. The config adapter must be a registered module. Any warnings will be printed to the log, but beware that any adaptation without errors will immediately be used. If you want to review the results of the adaptation first, use the 'adapt' subcommand.

As a special case, if the current working directory has a file called "Caddyfile" and the caddyfile config adapter is plugged in (default), then that file will be loaded and used to configure Caddy, even without any command line flags.

If --envfile is specified, an environment file with environment variables in the KEY=VALUE format will be loaded into the Caddy process.

If --environ is specified, the environment as seen by the Caddy process will be printed before starting. This is the same as the environ command but does not quit after printing, and can be useful for troubleshooting.

The --resume flag will override the --config flag if there is a config auto- save file. It is not an error if --resume is used and no autosave file exists.

If --watch is specified, the config file will be loaded automatically after changes. ⚠ This can make unintentional config changes easier; only use this option in a local development environment.

## OPTIONS
-a, --adapter="" Name of config adapter to apply

-c, --config="" Configuration file

--envfile=[] Environment file(s) to load

-e, --environ[=false] Print environment

-h, --help[=false] help for run

--pidfile="" Path of file to which to write process ID

--pingback="" Echo confirmation bytes to this address on success

-r, --resume[=false] Use saved config, if any (and prefer over --config file)

-w, --watch[=false] Watch config file for changes and reload it automatically

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-start

title: caddy-start(8)

text:
# caddy-start(8)

## NAME
caddy-start - Starts the Caddy process in the background and then returns

## SYNOPSIS
caddy start [--config [--adapter ]] [--envfile ] [--watch] [--pidfile ] [flags]

## DESCRIPTION
Starts the Caddy process, optionally bootstrapped with an initial config file. This command unblocks after the server starts running or fails to run.

If --envfile is specified, an environment file with environment variables in the KEY=VALUE format will be loaded into the Caddy process.

On Windows, the spawned child process will remain attached to the terminal, so closing the window will forcefully stop Caddy; to avoid forgetting this, try using 'caddy run' instead to keep it in the foreground.

## OPTIONS
-a, --adapter="" Name of config adapter to apply

-c, --config="" Configuration file

--envfile=[] Environment file(s) to load

-h, --help[=false] help for start

--pidfile="" Path of file to which to write process ID

-w, --watch[=false] Reload changed config file automatically

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-stop

title: caddy-stop(8)

text:
# caddy-stop(8)

## NAME
caddy-stop - Gracefully stops a started Caddy process

## SYNOPSIS
caddy stop [--config [--adapter ]] [--address ] [flags]

## DESCRIPTION
Stops the background Caddy process as gracefully as possible.

It requires that the admin API is enabled and accessible, since it will use the API's /stop endpoint. The address of this request can be customized using the --address flag, or from the given --config, if not the default.

## OPTIONS
-a, --adapter="" Name of config adapter to apply (when --config is used)

--address="" The address to use to reach the admin API endpoint, if not the default

-c, --config="" Configuration file to use to parse the admin address, if --address is not used

-h, --help[=false] help for stop

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-storage

title: caddy-storage(8)

text:
# caddy-storage(8)

## NAME
caddy-storage - Commands for working with Caddy's storage (EXPERIMENTAL)

## SYNOPSIS
caddy storage [flags]

## DESCRIPTION
Allows exporting and importing Caddy's storage contents. The two commands can be combined in a pipeline to transfer directly from one storage to another:

$ caddy storage export --config Caddyfile.old --output - | > caddy storage import --config Caddyfile.new --input -

The - argument refers to stdout and stdin, respectively.

NOTE: When importing to or exporting from file_system storage (the default), the command should be run as the user that owns the associated root path.

EXPERIMENTAL: May be changed or removed.

## OPTIONS
-h, --help[=false] help for storage

## SEE ALSO
caddy(8), caddy-storage-export(8), caddy-storage-import(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-storage-export

title: caddy-storage-export(8)

text:
# caddy-storage-export(8)

## NAME
caddy-storage-export - Exports storage assets as a tarball

## SYNOPSIS
caddy storage export --config --output [flags]

## DESCRIPTION
The contents of the configured storage module (TLS certificates, etc) are exported via a tarball.

--output is required, - can be given for stdout.

## OPTIONS
-c, --config="" Input configuration file (required)

-h, --help[=false] help for export

-o, --output="" Output path

## SEE ALSO
caddy-storage(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-storage-import

title: caddy-storage-import(8)

text:
# caddy-storage-import(8)

## NAME
caddy-storage-import - Imports storage assets from a tarball.

## SYNOPSIS
caddy storage import --config --input [flags]

## DESCRIPTION
Imports storage assets to the configured storage module. The import file must be a tar archive.

--input is required, - can be given for stdin.

## OPTIONS
-c, --config="" Configuration file to load (required)

-h, --help[=false] help for import

-i, --input="" Tar of assets to load (required)

## SEE ALSO
caddy-storage(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-trust

title: caddy-trust(8)

text:
# caddy-trust(8)

## NAME
caddy-trust - Installs a CA certificate into local trust stores

## SYNOPSIS
caddy trust [--ca ] [--address ] [--config [--adapter ]] [flags]

## DESCRIPTION
Adds a root certificate into the local trust stores.

Caddy will attempt to install its root certificates into the local trust stores automatically when they are first generated, but it might fail if Caddy doesn't have the appropriate permissions to write to the trust store. This command is necessary to pre-install the certificates before using them, if the server process runs as an unprivileged user (such as via systemd).

By default, this command installs the root certificate for Caddy's default CA (i.e. 'local'). You may specify the ID of another CA with the --ca flag.

This command will attempt to connect to Caddy's admin API running at 'localhost:2019' to fetch the root certificate. You may explicitly specify the --address, or use the --config flag to load the admin address from your config, if not using the default.

## OPTIONS
-a, --adapter="" Name of config adapter to apply (if --config is used)

--address="" Address of the administration API listener (if --config is not used)

--ca="" The ID of the CA to trust (defaults to 'local')

-c, --config="" Configuration file (if --address is not used)

-h, --help[=false] help for trust

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-untrust

title: caddy-untrust(8)

text:
# caddy-untrust(8)

## NAME
caddy-untrust - Untrusts a locally-trusted CA certificate

## SYNOPSIS
caddy untrust [--cert ] | [[--ca ] [--address ] [--config [--adapter ]]] [flags]

## DESCRIPTION
Untrusts a root certificate from the local trust store(s).

This command uninstalls trust; it does not necessarily delete the root certificate from trust stores entirely. Thus, repeatedly trusting and untrusting new certificates can fill up trust databases.

This command does not delete or modify certificate files from Caddy's configured storage.

This command can be used in one of two ways. Either by specifying which certificate to untrust by a direct path to the certificate file with the --cert flag, or by fetching the root certificate for the CA from the admin API (default behaviour).

If the admin API is used, then the CA defaults to 'local'. You may specify the ID of another CA with the --ca flag. By default, this will attempt to connect to the Caddy's admin API running at 'localhost:2019' to fetch the root certificate. You may explicitly specify the --address, or use the --config flag to load the admin address from your config, if not using the default.

## OPTIONS
-a, --adapter="" Name of config adapter to apply (if --config is used)

--address="" Address of the administration API listener (if --config is not used)

--ca="" The ID of the CA to untrust (defaults to 'local')

-p, --cert="" The path to the CA certificate to untrust

-c, --config="" Configuration file (if --address is not used)

-h, --help[=false] help for untrust

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-upgrade

title: caddy-upgrade(8)

text:
# caddy-upgrade(8)

## NAME
caddy-upgrade - Upgrade Caddy (EXPERIMENTAL)

## SYNOPSIS
caddy upgrade [flags]

## DESCRIPTION
Downloads an updated Caddy binary with the same modules/plugins at the latest versions. EXPERIMENTAL: May be changed or removed.

## OPTIONS
-h, --help[=false] help for upgrade

-k, --keep-backup[=false] Keep the backed up binary, instead of deleting it

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-validate

title: caddy-validate(8)

text:
# caddy-validate(8)

## NAME
caddy-validate - Tests whether a configuration file is valid

## SYNOPSIS
caddy validate --config [--adapter ] [--envfile ] [flags]

## DESCRIPTION
Loads and provisions the provided config, but does not start running it. This reveals any errors with the configuration through the loading and provisioning stages.

If --envfile is specified, an environment file with environment variables in the KEY=VALUE format will be loaded into the Caddy process.

## OPTIONS
-a, --adapter="" Name of config adapter

-c, --config="" Input configuration file

--envfile=[] Environment file(s) to load

-h, --help[=false] help for validate

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


caddy-version

title: caddy-version(8)

text:
# caddy-version(8)

## NAME
caddy-version - Prints the version

## SYNOPSIS
caddy version [flags]

## DESCRIPTION
Prints the version of this Caddy binary.

Version information must be embedded into the binary at compile-time in order for Caddy to display anything useful with this command. If Caddy is built from within a version control repository, the Go command will embed the revision hash if available. However, if Caddy is built in the way specified by our online documentation (or by using xcaddy), more detailed version information is printed as given by Go modules.

For more details about the full version string, see the Go module documentation: https://go.dev/doc/modules/version-numbers

## OPTIONS
-h, --help[=false] help for version

## SEE ALSO
caddy(8)

## HISTORY
2-Jul-2026 Auto generated by spf13/cobra


calamares

package: calamares

title: calamares(8)

text:
# calamares(8)

## NAME
calamares - distribution-independent system installer

## SYNOPSIS
calamares [options]

## DESCRIPTION
calamares is a distribution-independent system installer, with an advanced partitioning feature for both manual and automated partitioning operations. It is the first installer with an automated “Replace Partition” option, which makes it easy to reuse a partition over and over for distribution testing. Calamares is designed to be customizable by distribution maintainers without need for cumbersome patching, thanks to third party branding and external modules support.

## OPTIONS
-h, --help

Displays this help.

-v, --version

Displays version information.

-d, --debug

Debugging mode for testing purposes. Implies -D8 and -c..

-D <level>

Sets logging-level. Higher numbers are more verbose.

-c, --config <config>

Configuration directory to use, for testing purposes.

-X, --xdg-config

Use XDG environment variables for file lookup.

-T, --debug-translation

Use translations from current directory.

## FILES
calamares reads its configuration from many files. The first configuration file is settings.conf which is located in one of the configuration locations. When started with -d calamares looks in the current directory for a settings file. When started with -X calamares looks in the directories specified by XDG_CONFIG_DIRS for a settings file. If no settings file is found elsewhere, calamares looks in pre-configured directories like /etc .

The contents of the settings.conf file dictate where other configuration files are located, and which configuration files are used.

calamares prints debug-information to standard output and also saves the debug-information in ~/.cache/calamares/session.log . After installation the debug-information may be saved in the target system.

## SEE ALSO
The calamares website: https://calamares.io .

The command-line arguments for calamares are primarily for developers convenience and should not be needed in nearly any situation in which calamares is deployed. Most live CD environments and OEM installations should have installed configuration files in their correct system-wide locations.

## BUGS
Please report any bugs to https://codeberg.org/Calamares/calamares/issues

## AUTHORS
calamares is written by Teo Mrnjavac <teo@kde.org>, Adriaan de Groot <groot@kde.org> and an international group of contributors.

This man page is written by Jonathan Carter <jcarter@linux.com>


title: cciss_vol_status(8)

text:
# cciss_vol_status(8)

## NAME
cciss_vol_status - show status of logical drives attached to HP Smartarray controllers

## SYNOPSIS
cciss_vol_status [OPTION] [DEVICE]...

## DESCRIPTION
Shows the status of logical drives configured on HP Smartarray controllers.

## OPTIONS
-p, --persnickety

Without this option, device nodes which can't be opened, or which are not found to be of the correct device type are silently ignored. This lets you use wildcards, e.g.: cciss_vol_status /dev/sg* /dev/cciss/c*d0, and the program will not complain as long as all devices which are found to be of the correct type are found to be ok. However, you may wish to explicitly list the devices you expect to be there, and be notified if they are not there (e.g. perhaps a PCI slot has died, and the system has rebooted, so that what was once /dev/cciss/c1d0 is no longer there at all). This option will cause the program to complain about any device node listed which does not appear to be the right device type, or is not openable.

-C, --copyright

If stderr is a terminal, Print out a copyright message, and exit.

-q, --quiet

This option doesn't do anything. Previously, without this option and if stderr is a terminal, a copyright message precedes the normal program output. Now, the copyright message is only printed via the -C option.

-s

Query each physical drive for S.M.A.R.T data and report any drives in "predictive failure" state.

-u, --try-unknown-devices

If a device has an unrecognized board ID, normally the program will not attempt to communicate with it. In case you have some Smart Array controller which is newer than this program, the program may not recognize it. This option permits the program to attempt to interrogate the board even if it is unrecognized on the assumption that it is in fact a Smart Array of some kind.

-v, --version

Print the version number and exit.

-x, --exhaustive

Deprecated. Previously, it "exhaustively" searched for logical drives, as, under some circumstances some logical drives might otherwise be missed. This option no longer does anything, as the algorithm for finding logical drives was changed to obviate the need for it.

## DEVICE
The DEVICE argument indicates which RAID controller is to be queried. Note, that it indicates which RAID controller, not which logical drive.

For the cciss driver, the "d0" nodes matching "/dev/cciss/c*d0" are the nodes which correspond to the RAID controllers. (See note 1, below.) It is not necessary to invoke cciss_vol_status on each logical drive individually, though if you do this, each time it will report the status of ALL logical drives on the controller.

For the hpsa driver, or for fibre attached MSA1000 family devices, or for the hpahcisr sotware RAID driver which emulates Smart Arrays, the RAID controller is accessed via the scsi generic driver, and the device nodes will match "/dev/sg*" Some variants of the "lsscsi" tool will easily identify which device node corresponds to the RAID controller. Some variants may only report the SCSI nexus (controller/bus/target/lun tuple.) Some distros may not have the lsscsi tool.

Executing the following query to the /sys filesystem and correlating this with the contents of /proc/scsi/scsi or output of lsscsi can help in finding the right /dev/sg node to use with cciss_vol_status:

```
wumpus:/home/scameron # ls -l /sys/class/scsi_generic/*
lrwxrwxrwx 1 root root 0 2009-11-18 12:31 /sys/class/scsi_generic/sg0 -> ../../devices/pci0000:00/0000:00:02.0/0000:02:00.0/0000:03:03.0/host0/target0:0:0/0:0:0:0/scsi_generic/sg0
lrwxrwxrwx 1 root root 0 2009-11-18 12:31 /sys/class/scsi_generic/sg1 -> ../../devices/pci0000:00/0000:00:1f.1/host2/target2:0:0/2:0:0:0/scsi_generic/sg1
lrwxrwxrwx 1 root root 0 2009-11-19 07:47 /sys/class/scsi_generic/sg2 -> ../../devices/pci0000:00/0000:00:05.0/0000:0e:00.0/host4/target4:3:0/4:3:0:0/scsi_generic/sg2
wumpus:/home/scameron # cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00

  Vendor: COMPAQ   Model: BD03685A24       Rev: HPB6

  Type:   Direct-Access                    ANSI  SCSI revision: 03
Host: scsi2 Channel: 00 Id: 00 Lun: 00

  Vendor: SAMSUNG  Model: CD-ROM SC-148A   Rev: B408

  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi4 Channel: 03 Id: 00 Lun: 00

  Vendor: HP       Model: P800             Rev: 6.82

  Type:   RAID                             ANSI  SCSI revision: 00
wumpus:/home/scameron # lsscsi
[0:0:0:0]    disk    COMPAQ   BD03685A24       HPB6  /dev/sda
[2:0:0:0]    cd/dvd  SAMSUNG  CD-ROM SC-148A   B408  /dev/sr0
[4:3:0:0]    storage HP       P800             6.82  -
```

From the above you can see that /dev/sg2 corresponds to SCSI nexus 4:3:0:0, which corresponds to the HP P800 RAID controller listed in /proc/scsi/scsi.

## EXAMPLE

```
	[root@somehost]# cciss_vol_status -q /dev/cciss/c*d0
	/dev/cciss/c0d0: (Smart Array P800) RAID 0 Volume 0 status: OK.
	/dev/cciss/c0d0: (Smart Array P800) RAID 0 Volume 1 status: OK.
	/dev/cciss/c0d0: (Smart Array P800) RAID 1 Volume 2 status: OK.
	/dev/cciss/c0d0: (Smart Array P800) RAID 5 Volume 4 status: OK.
	/dev/cciss/c0d0: (Smart Array P800) RAID 5 Volume 5 status: OK.
	/dev/cciss/c0d0: (Smart Array P800) Enclosure MSA60 (S/N: USP6340B3F) on Bus 2, Physical Port 1E status: Power Supply Unit failed
	/dev/cciss/c1d0: (Smart Array P800) RAID 5 Volume 0 status: OK.
	/dev/cciss/c1d0: (Smart Array P800) RAID 5 Volume 1 status: OK.
	/dev/cciss/c1d0: (Smart Array P800) RAID 5 Volume 2 status: OK.
	/dev/cciss/c1d0: (Smart Array P800) RAID 5 Volume 3 status: OK.
	/dev/cciss/c1d0: (Smart Array P800) RAID 5 Volume 4 status: OK.
	/dev/cciss/c1d0: (Smart Array P800) RAID 5 Volume 5 status: OK.
	/dev/cciss/c1d0: (Smart Array P800) RAID 5 Volume 6 status: OK.
	/dev/cciss/c1d0: (Smart Array P800) RAID 5 Volume 7 status: OK.
	[root@someotherhost]# cciss_vol_status -q /dev/sg0 /dev/cciss/c*d0
	/dev/sg0: (MSA1000) RAID 1 Volume 0 status: OK.   At least one spare drive.
	/dev/sg0: (MSA1000) RAID 5 Volume 1 status: OK.
	/dev/cciss/c0d0: (Smart Array P800) RAID 0 Volume 0 status: OK.
	[root@localhost]# ./cciss_vol_status -s /dev/sg1
	/dev/sda: (Smart Array P410i) RAID 0 Volume 0 status: OK.
		 connector 1I box 1 bay 1                 HP      DG072A9BB7                               B365P6803PCP0633     HPD0 S.M.A.R.T. predictive failure.
	[root@localhost]# echo $?
	1
	[root@localhost]# ./cciss_vol_status -s /dev/cciss/c0d0
	/dev/cciss/c0d0: (Smart Array P800) RAID 0 Volume 0 status: OK.
		 connector 2E box 1 bay 8                 HP      DF300BB6C3                           3LM08AP700009713RXUT     HPD3 S.M.A.R.T. predictive failure.
	/dev/cciss/c0d0: (Smart Array P800) Enclosure MSA60 (S/N: USP6340B3F) on Bus 2, Physical Port 2E status: OK.
```

## DIAGNOSTICS
Normally, a logical drive in good working order should report a status of "OK." Possible status values are:

"OK." (0) - The logical drive is in good working order.

"FAILED." (1) - The logical drive has failed, and no i/o to it is poosible.

Additionally, failed drives will be identified by connector, box and bay, as well as vendor, model, serial number, and firmware revision.

"Using interim recovery mode." (3) - One or more drives has failed,

but not so many that the logical drive can no longer operate. The failed drives should be replaced as soon as possible.

"Ready for recovery operation." (4) - Failed drive(s) have been

replaced, and the controller is about to begin rebuilding redundant parity data.

"Currently recovering." (5) - Failed drive(s) have been replaced,

and the controller is currently rebuilding redundant parity information.

"Wrong physical drive was replaced." (6) - A drive has failed, and

another (working) drive was replaced.

"A physical drive is not properly connected." (7) - There is some

cabling or backplane problem in the drive enclosure.

(From fwspecwww.doc, see cpqarray project on sourceforge.net):

Note: If the unit_status value is 6 (Wrong physical drive was replaced) or 7 (A physical drive is not properly connected), the unit_status of all other configured logical drives will be marked as 1 (Logical drive failed). This is to force the user to correct the problem and to insure that once the problem is corrected, the data will not have been corrupted by any user action.

"Hardware is overheating." (8) - Hardware is too hot.

"Hardware was overheated." (9) - At some point in the past,

the hardware got too hot.

"Currently expannding." (10) - The controller is currently in the

process of expanding a logical drive.

"Not yet available." (11) - The logical drive is not yet finished

being configured.

"Queued for expansion." (12) - The logical drive will be expended

when the controller is able to begin working on it.

Additionally, the following messages may appear regarding spare drive status:

```
	"At least one spare drive designated"
	"At least one spare drive activated and currently rebuilding"
	"At least one activated on-line spare drive is completely rebuilt on this logical drive"
	"At least one spare drive has failed"
	"At least one spare drive activated"
	"At least one spare drive remains available"
Active spares will be identified by connector, box and bay, as well
as by vendor, model, serial number, and firmware revision.
```

For each logical drive, the total number of failed physical drives, if more than zero, will be reported as:

"Total of n failed physical drives detected on this logical drive."

```

```

with "n" replaced by the actual number, of course.

"Replacement" drives -- newly inserted drives that replace a previously failed drive but are not yet finished rebuilding -- are also identified by connector, box and bay, as well as by vendor, model, serial number, and firmware revision.

If the -s option is specified, each physical drive will be queried for S.M.A.R.T data, any any drives in predictive failure state will be reported, identified by connector, box and bay, as well as vendor, model, serial number, and firmware revision.

Additionally failure conditions of disk enclosure fans, power supplies, and temperature are reported as follows:

```
	"Fan failed"
	"Temperature problem"
	"Door alert"
	"Power Supply Unit failed"
```

## FILES
/dev/cciss/c*d0 (Smart Array PCI controllers using the cciss driver)

/dev/sg* (Fibre attached MSA1000 controllers and Smart Array controllers using the hpsa driver or hpahcisr software RAID driver.)

## EXIT CODES
0 - All configured logical drives queried have status of "OK."

1 - One or more configured logical drives queried have status other than "OK."

## AUTHOR
Written by Stephen M. Cameron

## REPORTING BUGS
MSA500 G1 logical drive numbers may not be reported correctly.

I've seen enclosure serial numbers contain garbage.

Report bugs to <steve.cameron@hp.com>

## COPYRIGHT
Copyright © 2007 Hewlett-Packard Development Company, L.P.

This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

## SEE ALSO
http://cciss.sourceforge.net

## note 1
The /dev/cciss/c*d0 device nodes of the cciss driver do double duty. They serve as an access point to both the RAID controllers, and to the first logical drive of each RAID controller. Notice that a /dev/cciss/c*d0 node will be present for each controller even if no logical drives are configured on that controller. It might be cleaner if the driver had a special device node just for the controller, instead of making these device nodes do double duty. It has been like that since the 2.2 linux kernel timeframe. At that time, device major and minor nodes were statically allocated at compile time, and were in short supply. Changing this behavior at this point would break lots of userland programs.


cdemu-daemon

package: cdemu-daemon

title: cdemu-daemon(8)

summary: The CDEmu daemon

text:
# cdemu-daemon(8)

## NAME
cdemud - The CDEmu daemon

## SYNOPSIS
cdemu-daemon [options]

## DESCRIPTION
This is CDEmu daemon, the userspace part of the cdemu suite, a free, GPL CD/DVD-ROM device emulator for linux.

It receives SCSI commands from kernel module and processes them, passing the requested data back to the kernel. Daemon implements the actual virtual device; one instance per each device registered by kernel module. It uses libMirage, an image access library that is part of the cdemu suite, for the image access (e.g. sector reading).

The daemon registers itself on D-BUS' system or session bus (depending on the options passed to it) where it exposes an interface that can be used by clients to control it.

## OPTIONS
--config-file=filename

Configuration file to load. See Configuration file section for details.

-n --num-devices=N

Number of devices. Specifies the number of virtual devices the daemon instance should register with kernel module and control. By default, 1 virtual device is created.

-c --ctl-device=path

Control device. Specifies the control device path. Control device is a character device provided by kernel module; it is used for communication between kernel and userspace part of CDEmu suite. By default, /dev/vhba_ctl is used.

-a --audio-driver=driver

Audio driver. Specifies audio driver to be used by virtual devices' audio play. Since libao is used for audio playback, any valid libao driver can be specified. If default is used as a driver, then libao's default driver is used. Few examples of valid libao drivers are alsa, oss, pulse or null. For all drivers, default device is used. By default, if audio driver is not explicitly specified via this option, null is used.

-b --bus=bus_type

Bus type. Valid options are system or session. By default, session bus is used. (Please note that the running of CDEmu daemon on system bus is considered deprecated and is discouraged for security reasons).

-l --logfile=logfile

Log file to write logging output into. By default, use of log file is disabled and messages are written to stdout.

--default-cdemu-debug-mask=mask

Default debug mask for CDEmu devices (at CDEmu daemon implementation level). Default value is 0.

--default-mirage-debug-mask=mask

Default debug mask for CDEmu devices (at libMirage implementation level). Default value is 0.

--system-sleep-handler=0|1

Enable or disable systemd-logind system sleep handler. When enabled, the daemon attempts to obtain delaying sleep inhibitor lock from the org.freedesktop.login1.Manager systemd-logind interface at /org/freedesktop/login1 on the system bus, and registers handler for the prepare-for-sleep signal. When system is about to enter suspend/hibernation (as indicated by received signal), the virtual devices are stopped, and inhibitor lock is released. After system resumes (as indicated by received signal), the inhibitor lock is re-acquired, and virtual devices are restarted. This mechanism attempts to mitigate issues with active virtual devices preventing the system from properly suspending/hibernating. Default value is 1 (the handler is enabled). If sleep handler functionality is disabled at build time, this option has no effect.

-? --help

Display the help message.

## EXAMPLES
Running daemon on default bus with PulseAudio audio driver and 4 virtual devices:

cdemu-daemon --num-devices=4 --audio-driver=pulse

Running daemon on system bus with 2 virtual devices and logging redirected to a file:

cdemu-daemon --num-devices=2 --bus=system --logfile=/tmp/cdemu-daemon.log

## CONFIGURATION FILE
The daemon's settings can be collected in a configuration file, which is passed to the daemon via --config-file option. Configuration file contains key=value pairs that are contained in a single [settings] section. The keys in configuration file correspond to the long names of command-line switches.

If an option is specified in both configuration file and on command-line, the latter takes precedence.

If the specified configuration file does not exist, it is silently ignored. If the specified configuration file is invalid (e.g., has invalid syntax, or does not contain a section), an error is raised.

Example

Saving the following configuration to a file and passing it to the daemon via --config-file is equivalent to passing --num-devices=2 --audio-driver=pulse directly to the daemon:

[settings]

num-devices=2

audio-driver=pulse

## AUTHORS
Rok Mandeljc <rok.mandeljc@gmail.com>

CDEmu project's web page: http://cdemu.sourceforge.net

CDEmu project's mailing list: cdemu-devel@lists.sourceforge.net


ceph-create-keys

package: ceph-base

title: ceph-create-keys(8)

summary: ceph keyring generate tool

text:
# ceph-create-keys(8)

## NAME
ceph-create-keys - ceph keyring generate tool

## SYNOPSIS

```
ceph-create-keys [-h] [-v] [-t seconds] [--cluster name] --id id
```

## DESCRIPTION
ceph-create-keys is a utility to generate bootstrap keyrings using the given monitor when it is ready.

It creates following auth entities (or users)

client.admin

and its key for your client host.

client.bootstrap-{osd, rgw, mds}

and their keys for bootstrapping corresponding services

To list all users in the cluster:

```
ceph auth ls
```

## OPTIONS
--cluster

name of the cluster (default 'ceph').

-t

time out after seconds (default: 600) waiting for a response from the monitor

-i, --id

id of a ceph-mon that is coming up. ceph-create-keys will wait until it joins quorum.

-v, --verbose

be more verbose.

## AVAILABILITY
ceph-create-keys is part of Ceph, a massively scalable, open-source, distributed storage system. Please refer to the Ceph documentation at <https://docs.ceph.com> for more information.

## SEE ALSO
ceph <>(8)

## Copyright
2010-2014, Inktank Storage, Inc. and contributors. Licensed under Creative Commons Attribution Share Alike 3.0 (CC-BY-SA-3.0)


ceph-kvstore-tool

title: ceph-kvstore-tool(8)

summary: ceph kvstore manipulation tool

text:
# ceph-kvstore-tool(8)

## NAME
ceph-kvstore-tool - ceph kvstore manipulation tool

## SYNOPSIS

```
ceph-kvstore-tool <rocksdb|bluestore-kv> <store path> command [args...]
```

## DESCRIPTION
ceph-kvstore-tool is a kvstore manipulation tool. It allows users to manipulate RocksDB's data (like OSD's omap) offline.

## COMMANDS
ceph-kvstore-tool utility uses many commands for debugging purpose which are as follows:

list [prefix]

Print key of all KV pairs stored with the URL encoded prefix.

list-crc [prefix]

Print CRC of all KV pairs stored with the URL encoded prefix.

dump [prefix]

Print key and value of all KV pairs stored with the URL encoded prefix.

exists <prefix> [key]

Check if there is any KV pair stored with the URL encoded prefix. If key is also specified, check for the key with the prefix instead.

get <prefix> <key> [out <file>]

Get the value of the KV pair stored with the URL encoded prefix and key. If file is also specified, write the value to the file.

crc <prefix> <key>

Get the CRC of the KV pair stored with the URL encoded prefix and key.

get-size [<prefix> <key>]

Get estimated store size or size of value specified by prefix and key.

set <prefix> <key> [ver <N>|in <file>]

Set the value of the KV pair stored with the URL encoded prefix and key. The value could be version_t or text.

rm <prefix> <key>

Remove the KV pair stored with the URL encoded prefix and key.

rm-prefix <prefix>

Remove all KV pairs stored with the URL encoded prefix.

store-copy <path> [num-keys-per-tx]

Copy all KV pairs to another directory specified by path. [num-keys-per-tx] is the number of KV pairs copied for a transaction.

store-crc <path>

Store CRC of all KV pairs to a file specified by path.

compact

Subcommand compact is used to compact all data of kvstore. It will open the database, and trigger a database's compaction. After compaction, some disk space may be released.

compact-prefix <prefix>

Compact all entries specified by the URL encoded prefix.

compact-range <prefix> <start> <end>

Compact some entries specified by the URL encoded prefix and range.

destructive-repair

Make a (potentially destructive) effort to recover a corrupted database. Note that in the case of rocksdb this may corrupt an otherwise uncorrupted database--use this only as a last resort!

stats

Prints statistics from underlying key-value database. This is only for informative purposes. Format and information content may vary between releases. For RocksDB information includes compactions stats, performance counters, memory usage and internal RocksDB stats.

histogram

Presents key-value sizes distribution statistics from the underlying KV database.

## AVAILABILITY
ceph-kvstore-tool is part of Ceph, a massively scalable, open-source, distributed storage system. Please refer to the Ceph documentation at <https://docs.ceph.com> for more information.

## SEE ALSO
ceph <>(8)

## Copyright
2010-2014, Inktank Storage, Inc. and contributors. Licensed under Creative Commons Attribution Share Alike 3.0 (CC-BY-SA-3.0)


ceph-run

title: ceph-run(8)

summary: restart daemon on core dump

text:
# ceph-run(8)

## NAME
ceph-run - restart daemon on core dump

## SYNOPSIS

```
ceph-run command ...
```

## DESCRIPTION
ceph-run is a simple wrapper that will restart a daemon if it exits with a signal indicating it crashed and possibly core dumped (that is, signals 3, 4, 5, 6, 8, or 11).

The command should run the daemon in the foreground. For Ceph daemons, that means the -f option.

## OPTIONS
None

## AVAILABILITY
ceph-run is part of Ceph, a massively scalable, open-source, distributed storage system. Please refer to the Ceph documentation at <https://docs.ceph.com> for more information.

## SEE ALSO
ceph <>(8), ceph-mon <>(8), ceph-mds <>(8), ceph-osd <>(8)

## Copyright
2010-2014, Inktank Storage, Inc. and contributors. Licensed under Creative Commons Attribution Share Alike 3.0 (CC-BY-SA-3.0)


crushtool

title: crushtool(8)

summary: CRUSH map manipulation tool

text:
# crushtool(8)

## NAME
crushtool - CRUSH map manipulation tool

## SYNOPSIS

```
crushtool ( -d map | -c map.txt | --build --num_osds numosds
layer1 ... | --test ) [ -o outfile ]
```

## DESCRIPTION
crushtool is a utility that lets you create, compile, decompile and test CRUSH map files.

CRUSH is a pseudo-random data distribution algorithm that efficiently maps input values (which, in the context of Ceph, correspond to Placement Groups) across a heterogeneous, hierarchically structured device map. The algorithm was originally described in detail in the following paper (although it has evolved some since then):

```
http://www.ssrc.ucsc.edu/Papers/weil-sc06.pdf
```

The tool has four modes of operation.

--compile|-c map.txt

will compile a plaintext map.txt into a binary map file.

--decompile|-d map

will take the compiled map and decompile it into a plaintext source file, suitable for editing.

--build --num_osds {num-osds} layer1 ...

will create map with the given layer structure. See below for a detailed explanation.

--test

will perform a dry run of a CRUSH mapping for a range of input values [--min-x,--max-x] (default [0,1023]) which can be thought of as simulated Placement Groups. See below for a more detailed explanation.

Unlike other Ceph tools, crushtool does not accept generic options such as --debug-crush from the command line. They can, however, be provided via the CEPH_ARGS environment variable. For instance, to silence all output from the CRUSH subsystem:

```
CEPH_ARGS="--debug-crush 0" crushtool ...
```

## RUNNING TESTS WITH --TEST
The test mode will use the input crush map ( as specified with -i map ) and perform a dry run of CRUSH mapping or random placement (if --simulate is set ). On completion, two kinds of reports can be created. 1) The --show-... option outputs human readable information on stderr. 2) The --output-csv option creates CSV files that are documented by the --help-output option.

Note: Each Placement Group (PG) has an integer ID which can be obtained from ceph pg dump (for example PG 2.2f means pool id 2, PG id 32). The pool and PG IDs are combined by a function to get a value which is given to CRUSH to map it to OSDs. crushtool does not know about PGs or pools; it only runs simulations by mapping values in the range [--min-x,--max-x].

--show-statistics

Displays a summary of the distribution. For instance:

```
rule 1 (metadata) num_rep 5 result size == 5:    1024/1024
```

shows that rule 1 which is named metadata successfully mapped 1024 values to result size == 5 devices when trying to map them to num_rep 5 replicas. When it fails to provide the required mapping, presumably because the number of tries must be increased, a breakdown of the failures is displayed. For instance:

```
rule 1 (metadata) num_rep 10 result size == 8:   4/1024
rule 1 (metadata) num_rep 10 result size == 9:   93/1024
rule 1 (metadata) num_rep 10 result size == 10:  927/1024
```

shows that although num_rep 10 replicas were required, 4 out of 1024 values ( 4/1024 ) were mapped to result size == 8 devices only.

--show-mappings

Displays the mapping of each value in the range [--min-x,--max-x]. For instance:

```
CRUSH rule 1 x 24 [11,6]
```

shows that value 24 is mapped to devices [11,6] by rule 1.

One of the following is required when using the --show-mappings option:

a.

--num-rep

b.

both --min-rep and --max-rep

--num-rep stands for "number of replicas, indicates the number of replicas in a pool, and is used to specify an exact number of replicas (for example --num-rep 5). --min-rep and --max-rep are used together to specify a range of replicas (for example, --min-rep 1 --max-rep 10).

--show-bad-mappings

Displays which value failed to be mapped to the required number of devices. For instance:

```
bad mapping rule 1 x 781 num_rep 7 result [8,10,2,11,6,9]
```

shows that when rule 1 was required to map 7 devices, it could map only six : [8,10,2,11,6,9].

--show-utilization

Displays the expected and actual utilization for each device, for each number of replicas. For instance:

```
device 0: stored : 951      expected : 853.333
device 1: stored : 963      expected : 853.333
...
```

shows that device 0 stored 951 values and was expected to store 853. Implies --show-statistics.

--show-utilization-all

Displays the same as --show-utilization but does not suppress output when the weight of a device is zero. Implies --show-statistics.

--show-choose-tries

Displays how many attempts were needed to find a device mapping. For instance:

```
0:     95224
1:      3745
2:      2225
..
```

shows that 95224 mappings succeeded without retries, 3745 mappings succeeded with one attempts, etc. There are as many rows as the value of the --set-choose-total-tries option.

--output-csv

Creates CSV files (in the current directory) containing information documented by --help-output. The files are named after the rule used when collecting the statistics. For instance, if the rule : 'metadata' is used, the CSV files will be:

```
metadata-absolute_weights.csv
metadata-device_utilization.csv
...
```

The first line of the file shortly explains the column layout. For instance:

```
metadata-absolute_weights.csv
Device ID, Absolute Weight
0,1
...
```

--output-name NAME

Prepend NAME to the file names generated when --output-csv is specified. For instance --output-name FOO will create files:

```
FOO-metadata-absolute_weights.csv
FOO-metadata-device_utilization.csv
...
```

The --set-... options can be used to modify the tunables of the input crush map. The input crush map is modified in memory. For example:

```
$ crushtool -i mymap --test --show-bad-mappings
bad mapping rule 1 x 781 num_rep 7 result [8,10,2,11,6,9]
```

could be fixed by increasing the choose-total-tries as follows:

$ crushtool -i mymap --test

--show-bad-mappings --set-choose-total-tries 500

## BUILDING A MAP WITH --BUILD
The build mode will generate hierarchical maps. The first argument specifies the number of devices (leaves) in the CRUSH hierarchy. Each layer describes how the layer (or devices) preceding it should be grouped.

Each layer consists of:

```
bucket ( uniform | list | tree | straw | straw2 ) size
```

The bucket is the type of the buckets in the layer (e.g. "rack"). Each bucket name will be built by appending a unique number to the bucket string (e.g. "rack0", "rack1"...).

The second component is the type of bucket: straw should be used most of the time.

The third component is the maximum size of the bucket. A size of zero means a bucket of infinite capacity.

## EXAMPLE
Suppose we have two rows with two racks each and 20 nodes per rack. Suppose each node contains 4 storage devices for Ceph OSD Daemons. This configuration allows us to deploy 320 Ceph OSD Daemons. Lets assume a 42U rack with 2U nodes, leaving an extra 2U for a rack switch.

To reflect our hierarchy of devices, nodes, racks and rows, we would execute the following:

```
$ crushtool -o crushmap --build --num_osds 320 \

       node straw 4 \

       rack straw 20 \

       row straw 2 \

       root straw 0
# id        weight  type name       reweight
-87 320     root root
-85 160             row row0
-81 80                      rack rack0
-1  4                               node node0
0   1                                       osd.0   1
1   1                                       osd.1   1
2   1                                       osd.2   1
3   1                                       osd.3   1
-2  4                               node node1
4   1                                       osd.4   1
5   1                                       osd.5   1
...
```

CRUSH rules are created so the generated crushmap can be tested. They are the same rules as the ones created by default when creating a new Ceph cluster. They can be further edited with:

```
# decompile
crushtool -d crushmap -o map.txt
# edit
emacs map.txt
# recompile
crushtool -c map.txt -o crushmap
```

## RECLASSIFY
The reclassify function allows users to transition from older maps that maintain parallel hierarchies for OSDs of different types to a modern CRUSH map that makes use of the device class feature. For more information, see <https://docs.ceph.com/en/latest/rados/operations/crush-map-edits/#migrating-from-a-legacy-ssd-rule-to-device-classes>.

## EXAMPLE OUTPUT FROM --TEST
See <https://github.com/ceph/ceph/blob/master/src/test/cli/crushtool/set-choose.t> for sample crushtool --test commands and output produced thereby.

## AVAILABILITY
crushtool is part of Ceph, a massively scalable, open-source, distributed storage system. Please refer to the Ceph documentation at <https://docs.ceph.com> for more information.

## SEE ALSO
ceph <>(8), osdmaptool <>(8),

## AUTHORS
John Wilkins, Sage Weil, Loic Dachary

## Copyright
2010-2014, Inktank Storage, Inc. and contributors. Licensed under Creative Commons Attribution Share Alike 3.0 (CC-BY-SA-3.0)


monmaptool

title: monmaptool(8)

text:
# monmaptool(8)

## NAME
monmaptool - ceph monitor cluster map manipulation tool

## SYNOPSIS

```
monmaptool <action> [options] mapfilename
```

## DESCRIPTION
monmaptool is a utility to create, view, and modify a monitor cluster map for the Ceph distributed storage system. The monitor map specifies the only fixed addresses in the Ceph distributed system. All other daemons bind to arbitrary addresses and register themselves with the monitors.

When creating a map with --create, a new monitor map with a new, random UUID will be created. It should be followed by one or more monitor addresses.

The default Ceph monitor port for messenger protocol v1 is 6789, and 3300 for protocol v2.

Multiple actions can be performed per invocation.

## OPTIONS
--print

print a plaintext dump of the map, after any modifications are made.

--feature-list [plain|parseable]

list the enabled features as well as the available ones. By default, a human readable output is produced.

--create

create a new monitor map with a new UUID (and with it, a new, empty Ceph cluster).

--clobber

allow monmaptool to create a new mapfilename in place of an existing map. Only useful when --create is used.

--generate

generate a new monmap based on the values on the command line or specified in the ceph configuration. This is, in order of preference,

1.

--monmap filename to specify a monmap to load

2.

--mon-host 'host1,ip2' to specify a list of hosts or ip addresses

3.

[mon.foo] sections containing mon addr settings in the config. Note that this method is not recommended and support will be removed in a future release.

--filter-initial-members

filter the initial monmap by applying the mon initial members setting. Monitors not present in that list will be removed, and initial members not present in the map will be added with dummy addresses.

--add name ip[:port]

add a monitor with the specified ip:port to the map. If the nautilus feature is set, and the port is not, the monitor will be added for both messenger protocols.

--addv name [protocol:ip:port[,...]]

add a monitor with the specified version:ip:port to the map.

--rm name

remove the monitor with the specified name from the map.

--fsid uuid

set the fsid to the given uuid. If not specified with --create, a random fsid will be generated.

--feature-set value [--optional|--persistent]

enable a feature.

--feature-unset value [--optional|--persistent]

disable a feature.

--enable-all-features

enable all supported features.

--set-min-mon-release release

set the min_mon_release.

## EXAMPLE
To create a new map with three monitors (for a fresh Ceph cluster):

```
monmaptool --create --add nodeA 192.168.0.10 --add nodeB 192.168.0.11 \

  --add nodeC 192.168.0.12 --enable-all-features --clobber monmap
```

To display the contents of the map:

```
monmaptool --print monmap
```

To replace one monitor:

```
monmaptool --rm nodeA monmap
monmaptool --add nodeA 192.168.0.9 monmap
```

## AVAILABILITY
monmaptool is part of Ceph, a massively scalable, open-source, distributed storage system. Please refer to the Ceph documentation at <https://docs.ceph.com> for more information.

## SEE ALSO
ceph <>(8), crushtool <>(8),

## Copyright
2010-2014, Inktank Storage, Inc. and contributors. Licensed under Creative Commons Attribution Share Alike 3.0 (CC-BY-SA-3.0)


osdmaptool

title: osdmaptool(8)

summary: ceph osd cluster map manipulation tool

text:
# osdmaptool(8)

## NAME
osdmaptool - ceph osd cluster map manipulation tool

## SYNOPSIS

```
osdmaptool mapfilename [--print] [--createsimple numosd
[--pgbits bitsperosd ] ] [--clobber]
osdmaptool mapfilename [--import-crush crushmap]
osdmaptool mapfilename [--export-crush crushmap]
osdmaptool mapfilename [--upmap file] [--upmap-max max-optimizations]
[--upmap-deviation max-deviation] [--upmap-pool poolname]
[--save] [--upmap-active]
osdmaptool mapfilename [--upmap-cleanup] [--upmap file]
```

## DESCRIPTION
osdmaptool is a utility that lets you create, view, and manipulate OSD cluster maps from the Ceph distributed storage system. Notably, it lets you extract the embedded CRUSH map or import a new CRUSH map. It can also simulate the upmap balancer mode so you can get a sense of what is needed to balance your PGs.

## OPTIONS
--print

will simply make the tool print a plaintext dump of the map, after any modifications are made.

--dump <format>

displays the map in plain text when <format> is 'plain', 'json' if specified format is not supported. This is an alternative to the print option.

--clobber

will allow osdmaptool to overwrite mapfilename if changes are made.

--import-crush mapfile

will load the CRUSH map from mapfile and embed it in the OSD map.

--export-crush mapfile

will extract the CRUSH map from the OSD map and write it to mapfile.

--createsimple numosd [--pg-bits bitsperosd] [--pgp-bits bits]

will create a relatively generic OSD map with the numosd devices. If --pg-bits is specified, the initial placement group counts will be set with bitsperosd bits per OSD. That is, the pg_num map attribute will be set to numosd shifted by bitsperosd. If --pgp-bits is specified, then the pgp_num map attribute will be set to numosd shifted by bits.

--create-from-conf

creates an osd map with default configurations.

--test-map-pgs [--pool poolid] [--range-first <first> --range-last <last>]

will print out the mappings from placement groups to OSDs. If range is specified, then it iterates from first to last in the directory specified by argument to osdmaptool. Eg: osdmaptool --test-map-pgs --range-first 0 --range-last 2 osdmap_dir. This will iterate through the files named 0,1,2 in osdmap_dir.

--test-map-pgs-dump [--pool poolid] [--range-first <first> --range-last <last>]

will print out the summary of all placement groups and the mappings from them to the mapped OSDs. If range is specified, then it iterates from first to last in the directory specified by argument to osdmaptool. Eg: osdmaptool --test-map-pgs-dump --range-first 0 --range-last 2 osdmap_dir. This will iterate through the files named 0,1,2 in osdmap_dir.

--test-map-pgs-dump-all [--pool poolid] [--range-first <first> --range-last <last>]

will print out the summary of all placement groups and the mappings from them to all the OSDs. If range is specified, then it iterates from first to last in the directory specified by argument to osdmaptool. Eg: osdmaptool --test-map-pgs-dump-all --range-first 0 --range-last 2 osdmap_dir. This will iterate through the files named 0,1,2 in osdmap_dir.

--test-random

does a random mapping of placement groups to the OSDs.

--test-map-pg <pgid>

map a particular placement group(specified by pgid) to the OSDs.

--test-map-object <objectname> [--pool <poolid>]

map a particular placement group(specified by objectname) to the OSDs.

--test-crush [--range-first <first> --range-last <last>]

map placement groups to acting OSDs. If range is specified, then it iterates from first to last in the directory specified by argument to osdmaptool. Eg: osdmaptool --test-crush --range-first 0 --range-last 2 osdmap_dir. This will iterate through the files named 0,1,2 in osdmap_dir.

--mark-up-in

mark osds up and in (but do not persist).

--mark-out

mark an osd as out (but do not persist)

--mark-up <osdid>

mark an osd as up (but do not persist)

--mark-in <osdid>

mark an osd as in (but do not persist)

--tree

Displays a hierarchical tree of the map.

--clear-temp

clears pg_temp and primary_temp variables.

--clean-temps

clean pg_temps.

--health

dump health checks

--with-default-pool

include default pool when creating map

--upmap-cleanup <file>

clean up pg_upmap[_items] entries, writing commands to <file> [default: - for stdout]

--upmap <file>

calculate pg upmap entries to balance pg layout writing commands to <file> [default: - for stdout]

--upmap-max <max-optimizations>

set max upmap entries to calculate [default: 10]

--upmap-deviation <max-deviation>

max deviation from target [default: 5]

--upmap-pool <poolname>

restrict upmap balancing to 1 pool or the option can be repeated for multiple pools

--upmap-active

Act like an active balancer, keep applying changes until balanced

--adjust-crush-weight <osdid:weight>[,<osdid:weight>,<...>]

Change CRUSH weight of <osdid>

--save

write modified osdmap with upmap or crush-adjust changes

--read <file>

calculate pg upmap entries to balance pg primaries

--read-pool <poolname>

specify which pool the read balancer should adjust

--vstart

prefix upmap and read output with './bin/'

## EXAMPLE
To create a simple map with 16 devices:

```
osdmaptool --createsimple 16 osdmap --clobber
```

To view the result:

```
osdmaptool --print osdmap
```

To view the mappings of placement groups for pool 1:

```
osdmaptool osdmap --test-map-pgs-dump --pool 1
pool 1 pg_num 8
1.0     [0,2,1] 0
1.1     [2,0,1] 2
1.2     [0,1,2] 0
1.3     [2,0,1] 2
1.4     [0,2,1] 0
1.5     [0,2,1] 0
1.6     [0,1,2] 0
1.7     [1,0,2] 1
#osd    count   first   primary c wt    wt
osd.0   8       5       5       1       1
osd.1   8       1       1       1       1
osd.2   8       2       2       1       1

 in 3

 avg 8 stddev 0 (0x) (expected 2.3094 0.288675x))

 min osd.0 8

 max osd.0 8
size 0  0
size 1  0
size 2  0
size 3  8
```

In which,

1.

pool 1 has 8 placement groups. And two tables follow:

2.

A table for placement groups. Each row presents a placement group. With columns of:

- placement group id,

- acting set, and

- primary OSD.

3.

A table for all OSDs. Each row presents an OSD. With columns of:

- count of placement groups being mapped to this OSD,

- count of placement groups where this OSD is the first one in their acting sets,

- count of placement groups where this OSD is the primary of them,

- the CRUSH weight of this OSD, and

- the weight of this OSD.

4.

Looking at the number of placement groups held by 3 OSDs. We have

- average, stddev, stddev/average, expected stddev, expected stddev / average

- min and max

5.

The number of placement groups mapping to n OSDs. In this case, all 8 placement groups are mapping to 3 different OSDs.

In a less-balanced cluster, we could have following output for the statistics of placement group distribution, whose standard deviation is 1.41421:

```
#osd    count   first   primary c wt    wt
osd.0   8       5       5       1       1
osd.1   8       1       1       1       1
osd.2   8       2       2       1       1
#osd    count   first    primary c wt    wt
osd.0   33      9        9       0.0145874     1
osd.1   34      14       14      0.0145874     1
osd.2   31      7        7       0.0145874     1
osd.3   31      13       13      0.0145874     1
osd.4   30      14       14      0.0145874     1
osd.5   33      7        7       0.0145874     1

 in 6

 avg 32 stddev 1.41421 (0.0441942x) (expected 5.16398 0.161374x))

 min osd.4 30

 max osd.1 34
size 00
size 10
size 20
size 364
```

To simulate the active balancer in upmap mode:

```
     osdmaptool --upmap upmaps.out --upmap-active --upmap-deviation 6 --upmap-max 11 osdmap
osdmaptool: osdmap file 'osdmap'
writing upmap command output to: upmaps.out
checking for upmap cleanups
upmap, max-count 11, max deviation 6
pools movies photos metadata data
prepared 11/11 changes
Time elapsed 0.00310404 secs
pools movies photos metadata data
prepared 11/11 changes
Time elapsed 0.00283402 secs
pools data metadata movies photos
prepared 11/11 changes
Time elapsed 0.003122 secs
pools photos metadata data movies
prepared 11/11 changes
Time elapsed 0.00324372 secs
pools movies metadata data photos
prepared 1/11 changes
Time elapsed 0.00222609 secs
pools data movies photos metadata
prepared 0/11 changes
Time elapsed 0.00209916 secs
Unable to find further optimization, or distribution is already perfect
osd.0 pgs 41
osd.1 pgs 42
osd.2 pgs 42
osd.3 pgs 41
osd.4 pgs 46
osd.5 pgs 39
osd.6 pgs 39
osd.7 pgs 43
osd.8 pgs 41
osd.9 pgs 46
osd.10 pgs 46
osd.11 pgs 46
osd.12 pgs 46
osd.13 pgs 41
osd.14 pgs 40
osd.15 pgs 40
osd.16 pgs 39
osd.17 pgs 46
osd.18 pgs 46
osd.19 pgs 39
osd.20 pgs 42
Total time elapsed 0.0167765 secs, 5 rounds
```

To simulate the active balancer in read mode, first make sure capacity is balanced by running the balancer in upmap mode. Then, balance the reads on a replicated pool with:

```
     osdmaptool osdmap --read read.out --read-pool <pool name>
./bin/osdmaptool: osdmap file 'om'
writing upmap command output to: read.out
---------- BEFORE ------------
osd.0 | primary affinity: 1 | number of prims: 3
osd.1 | primary affinity: 1 | number of prims: 10
osd.2 | primary affinity: 1 | number of prims: 3
read_balance_score of 'cephfs.a.meta': 1.88
---------- AFTER ------------
osd.0 | primary affinity: 1 | number of prims: 5
osd.1 | primary affinity: 1 | number of prims: 5
osd.2 | primary affinity: 1 | number of prims: 6
read_balance_score of 'cephfs.a.meta': 1.13
num changes: 5
```

## AVAILABILITY
osdmaptool is part of Ceph, a massively scalable, open-source, distributed storage system. Please refer to the Ceph documentation at <https://docs.ceph.com> for more information.

## SEE ALSO
ceph <>(8), crushtool <>(8),

## Copyright
2010-2014, Inktank Storage, Inc. and contributors. Licensed under Creative Commons Attribution Share Alike 3.0 (CC-BY-SA-3.0)