sysusers.d

package: systemd

title: sysusers.d(5)

text:
# sysusers.d(5)

## NAME
sysusers.d - Declarative allocation of system users and groups

## SYNOPSIS
/etc/sysusers.d/*.conf

/run/sysusers.d/*.conf

/usr/local/lib/sysusers.d/*.conf

/usr/lib/sysusers.d/*.conf

```
#Type Name       ID                  GECOS              Home directory Shell
u     user_name  uid                 "User Description" /home/dir      /path/to/shell
u     user_name  uid:gid             "User Description" /home/dir      /path/to/shell
u     user_name  /file/owned/by/user "User Description" /home/dir      /path/to/shell
g     group_name gid
g     group_name /file/owned/by/group
m     user_name  group_name
r     -          lowest-highest
```

## DESCRIPTION
systemd-sysusers uses the files from sysusers.d directory to create system users and groups and to add users to groups, at package installation or boot time. This tool may be used to allocate system users and groups only, it is not useful for creating non-system (i.e. regular, "human") users and groups, as it accesses /etc/passwd and /etc/group directly, bypassing any more complex user databases, for example any database involving NIS or LDAP.

## CONFIGURATION DIRECTORIES AND PRECEDENCE
Each configuration file shall be named in the style of package.conf or package-part.conf. The second variant should be used when it is desirable to make it easy to override just this part of configuration.

Files in /etc/sysusers.d override files with the same name in /usr/lib/sysusers.d and /run/sysusers.d. Files in /run/sysusers.d override files with the same name in /usr/lib/sysusers.d. Packages should install their configuration files in /usr/lib/sysusers.d. Files in /etc/sysusers.d are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same path, the entry in the file with the lexicographically earliest name will be applied. All later entries for the same user and group names will be logged as warnings.

If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/sysusers.d/ bearing the same filename.

## CONFIGURATION FILE FORMAT
The file format is one line per user or group containing name, ID, GECOS field description, home directory, and login shell:

```
#Type Name     ID             GECOS                 Home directory Shell
u!    httpd    404            "HTTP User"
u!    _authd   /usr/bin/authd "Authorization user"
u!    postgres -              "Postgresql Database" /var/lib/pgsql /usr/libexec/postgresdb
g     input    -              -
m     _authd   input
u     root     0              "Superuser"           /root          /bin/zsh
r     -        500-900
```

Empty lines and lines beginning with the "#" character are ignored, and may be used for commenting.

### Type
The type consists of a single letter. The following line types are understood:

u

Create a system user and group of the specified name should they not exist yet. The user's primary group will be set to the group bearing the same name unless the ID field specifies it. The account will be created disabled, so that logins are not allowed. Added in version 215.

Type u may be suffixed with an exclamation mark ("u!") to create a fully locked account. This is recommended, since logins should typically not be allowed for system users. With or without the exclamation mark an invalid password is set. For "u!", the account is also locked, which makes a difference for non-password forms of authentication, such as SSH or similar.

Added in version 257.

g

Create a system group of the specified name should it not exist yet. Note that u implicitly creates a matching group. The group will be created with no password set. Added in version 215.

m

Add a user to a group. If the user or group do not exist yet, they will be implicitly created. Added in version 215.

r

Add a range of numeric UIDs/GIDs to the pool to allocate new UIDs and GIDs from. If no line of this type is specified, the range of UIDs/GIDs is set to some compiled-in default. Note that both UIDs and GIDs are allocated from the same pool, in order to ensure that users and groups of the same name are likely to carry the same numeric UID and GID. Added in version 216.

### Name
The name field specifies the user or group name. The specified name must consist only of the characters a-z, A-Z, 0-9, "_" and "-", except for the first character which must be one of a-z, A-Z or "_" (i.e. numbers and "-" are not permitted as first character). The user/group name must have at least one character, and at most 31.

For further details about the syntax of user/group names, see User/Group Name Syntax[1].

It is strongly recommended to pick user and group names that are unlikely to clash with normal users created by the administrator. A good scheme to guarantee this is by prefixing all system and group names with the underscore, and avoiding too generic names.

For m lines, this field should contain the user name to add to a group.

For lines of type r, this field should be set to "-".

### ID
For u and g, the numeric 32-bit UID or GID of the user/group. Do not use IDs 65535 or 4294967295, as they have special placeholder meanings. Specify "-" for automatic UID/GID allocation for the user or group (this is strongly recommended unless it is strictly necessary to use a specific UID or GID). Alternatively, specify an absolute path in the file system. In this case, the UID/GID is read from the path's owner/group. This is useful to create users whose UID/GID match the owners of pre-existing files (such as SUID or SGID binaries). The syntaxes "uid:gid" and "uid:groupname" are supported to allow creating users with specific primary groups. The given group must be created explicitly, or it must already exist. Specifying "-" for the UID in these syntaxes is also supported.

For m lines, this field should contain the group name to add to a user to.

For lines of type r, this field should be set to a UID/GID range in the format "FROM-TO", where both values are formatted as decimal ASCII numbers. Alternatively, a single UID/GID may be specified formatted as decimal ASCII numbers.

### GECOS
A short, descriptive string for users to be created, enclosed in quotation marks. Note that this field may not contain colons.

Only applies to lines of type u and should otherwise be left unset (or "-").

### Home Directory
The home directory for a new system user. If omitted, defaults to the root directory.

Only applies to lines of type u and should otherwise be left unset (or "-"). It is recommended to omit this, unless software strictly requires a home directory to be set.

systemd-sysusers only sets the home directory record in the user database. To actually create the directory, consider adding a corresponding tmpfiles.d(5) fragment.

### Shell
The login shell of the user. If not specified, this will be set to /usr/sbin/nologin, except if the UID of the user is 0, in which case /bin/sh will be used.

Only applies to lines of type u and should otherwise be left unset (or "-"). It is recommended to omit this, unless a shell different /usr/sbin/nologin must be used.

## SPECIFIERS
Specifiers can be used in the "Name", "ID", "GECOS", "Home directory", and "Shell" fields. An unknown or unresolvable specifier is treated as invalid configuration. The following expansions are understood:

Table 1. Specifiers available

Specifier

Meaning

Details

"%a"

Architecture

A short string identifying the architecture of the local system. A string such as x86, x86-64 or arm64. See the architectures defined for ConditionArchitecture= in systemd.unit(5) for a full list.

"%A"

Operating system image version

The operating system image version identifier of the running system, as read from the IMAGE_VERSION= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%b"

Boot ID

The boot ID of the running system, formatted as string. See random(4) for more information.

"%B"

Operating system build ID

The operating system build identifier of the running system, as read from the BUILD_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%H"

Host name

The hostname of the running system.

"%l"

Short host name

The hostname of the running system, truncated at the first dot to remove any domain component.

"%m"

Machine ID

The machine ID of the running system, formatted as string. See machine-id(5) for more information.

"%M"

Operating system image identifier

The operating system image identifier of the running system, as read from the IMAGE_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%o"

Operating system ID

The operating system identifier of the running system, as read from the ID= field of /etc/os-release. See os-release(5) for more information.

"%q"

Pretty host name

The pretty hostname of the running system, as read from the PRETTY_HOSTNAME= field of /etc/machine-info. If not set, resolves to the short hostname. See machine-info(5) for more information.

"%T"

Directory for temporary files

This is either /tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)

"%v"

Kernel release

Identical to uname -r output.

"%V"

Directory for larger and persistent temporary files

This is either /var/tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)

"%w"

Operating system version ID

The operating system version identifier of the running system, as read from the VERSION_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%W"

Operating system variant ID

The operating system variant identifier of the running system, as read from the VARIANT_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%%"

Single percent sign

Use "%%" in place of "%" to specify a single percent sign.

## IDEMPOTENCE
Note that

systemd-sysusers will do nothing if the specified users or groups already exist or the users are members of specified groups, so normally there is no reason to override sysusers.d vendor configuration, except to block certain users or groups from being created.

## SEE ALSO
systemd(1), systemd-sysusers(8)

## NOTES
1.

User/Group Name Syntax

https://systemd.io/USER_NAMES

branch: sisyphus


tmpfiles.d

title: tmpfiles.d(5)

text:
# tmpfiles.d(5)

## NAME
tmpfiles.d - Configuration for creation, deletion, and cleaning of files and directories

## SYNOPSIS
/etc/tmpfiles.d/*.conf

/run/tmpfiles.d/*.conf

/usr/local/lib/tmpfiles.d/*.conf

/usr/lib/tmpfiles.d/*.conf

~/.config/user-tmpfiles.d/*.conf

$XDG_RUNTIME_DIR/user-tmpfiles.d/*.conf

~/.local/share/user-tmpfiles.d/*.conf

...

/usr/local/share/user-tmpfiles.d/*.conf

/usr/share/user-tmpfiles.d/*.conf

```
#Type Path                                     Mode User Group Age         Argument
f     /file/to/create                          mode user group -           content
f+    /file/to/create-or-truncate              mode user group -           content
w     /file/to/write-to                        -    -    -     -           content
w+    /file/to/append-to                       -    -    -     -           content
d     /directory/to/create-and-clean-up        mode user group cleanup-age -
D     /directory/to/create-and-remove          mode user group cleanup-age -
e     /directory/to/clean-up                   mode user group cleanup-age -
v     /subvolume-or-directory/to/create        mode user group cleanup-age -
q     /subvolume-or-directory/to/create        mode user group cleanup-age -
Q     /subvolume-or-directory/to/create        mode user group cleanup-age -
p     /fifo/to/create                          mode user group -           -
p+    /fifo/to/[re]create                      mode user group -           -
L     /symlink/to/create                       -    -    -     -           symlink/target/path
L+    /symlink/to/[re]create                   -    -    -     -           symlink/target/path
c     /dev/char-device-to-create               mode user group -           major:minor
c+    /dev/char-device-to-[re]create           mode user group -           major:minor
b     /dev/block-device-to-create              mode user group -           major:minor
b+    /dev/block-device-to-[re]create          mode user group -           major:minor
C     /target/to/create                        -    -    -     cleanup-age /source/to/copy
C+    /target/to/create                        -    -    -     cleanup-age /source/to/copy
x     /path-or-glob/to/ignore/recursively      -    -    -     cleanup-age -
X     /path-or-glob/to/ignore                  -    -    -     cleanup-age -
r     /path-or-glob/to/remove                  -    -    -     -           -
R     /path-or-glob/to/remove/recursively      -    -    -     -           -
z     /path-or-glob/to/adjust/mode             mode user group -           -
Z     /path-or-glob/to/adjust/mode/recursively mode user group -           -
t     /path-or-glob/to/set/xattrs              -    -    -     -           xattrs
T     /path-or-glob/to/set/xattrs/recursively  -    -    -     -           xattrs
h     /path-or-glob/to/set/attrs               -    -    -     -           file attrs
H     /path-or-glob/to/set/attrs/recursively   -    -    -     -           file attrs
a     /path-or-glob/to/set/acls                -    -    -     -           POSIX ACLs
a+    /path-or-glob/to/append/acls             -    -    -     -           POSIX ACLs
A     /path-or-glob/to/set/acls/recursively    -    -    -     -           POSIX ACLs
A+    /path-or-glob/to/append/acls/recursively -    -    -     -           POSIX ACLs
```

## DESCRIPTION
tmpfiles.d configuration files provide a generic mechanism to define the creation of regular files, directories, pipes, and device nodes, adjustments to their access mode, ownership, attributes, quota assignments, and contents, and finally their time-based removal. It is mostly commonly used for volatile and temporary files and directories (such as those located under /run/, /tmp/, /var/tmp/, the API file systems such as /sys/ or /proc/, as well as some other directories below /var/).

systemd-tmpfiles(8) uses this configuration to create volatile files and directories during boot and to do periodic cleanup afterwards. See systemd-tmpfiles(8) for the description of systemd-tmpfiles-setup.service, systemd-tmpfiles-clean.service, and associated units.

System daemons frequently require private runtime directories below /run/ to store communication sockets and similar. For these, it is better to use RuntimeDirectory= in their unit files (see systemd.exec(5) for details), if the flexibility provided by tmpfiles.d is not required. The advantages are that the configuration required by the unit is centralized in one place, and that the lifetime of the directory is tied to the lifetime of the service itself. Similarly, StateDirectory=, CacheDirectory=, LogsDirectory=, and ConfigurationDirectory= should be used to create directories under /var/lib/, /var/cache/, /var/log/, and /etc/. tmpfiles.d should be used for files whose lifetime is independent of any service or requires more complicated configuration.

## CONFIGURATION DIRECTORIES AND PRECEDENCE
Each configuration file shall be named in the style of package.conf or package-part.conf. The second variant should be used when it is desirable to make it easy to override just this part of configuration.

Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d. Files in /run/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d. Packages should install their configuration files in /usr/lib/tmpfiles.d. Files in /etc/tmpfiles.d are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same path, the entry in the file with the lexicographically earliest name will be applied (note that lines suppressed due to the "!" are filtered before application, meaning that if an early line carries the exclamation mark and is suppressed because of that, a later line matching in path will be applied). All other conflicting entries will be logged as errors. When two lines are prefix path and suffix path of each other, then the prefix line is always created first, the suffix later (and if removal applies to the line, the order is reversed: the suffix is removed first, the prefix later). Lines that take globs are applied after those accepting no globs. If multiple operations shall be applied on the same file (such as ACL, xattr, file attribute adjustments), these are always done in the same fixed order. Except for those cases, the files/directories are processed in the order they are listed.

If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/tmpfiles.d/ bearing the same filename.

## CONFIGURATION FILE FORMAT
The configuration format is one line per path, containing type, path, mode, ownership, age, and argument fields. The lines are separated by newlines, the fields by whitespace:

```
#Type Path        Mode User Group Age Argument...
d     /run/user   0755 root root  10d -
L     /tmp/foobar -    -    -     -   /dev/null
```

Fields may contain C-style escapes. With the exception of the seventh field (the "argument") all fields may be enclosed in quotes. Note that any whitespace found in the line after the beginning of the argument field will be considered part of the argument field. To begin the argument field with a whitespace character, use C-style escapes (e.g. "\x20").

### Type
The type consists of a single letter and optionally one or more modifier characters: a plus sign ("+"), exclamation mark ("!"), minus sign ("-"), equals sign ("="), tilde character ("~") and/or caret ("^").

The following line types are understood:

f, f+

f will create a file if it does not exist yet. If the argument parameter is given and the file did not exist yet, it will be written to the file. f+ will create or truncate the file. If the argument parameter is given, it will be written to the file. Does not follow symlinks.

w, w+

Write the argument parameter to a file, if the file exists. If suffixed with +, the line will be appended to the file. If your configuration writes multiple lines to the same file, use w+. Lines of this type accept shell-style globs in place of normal path names. The argument parameter will be written without a trailing newline. C-style backslash escapes are interpreted. Follows symlinks.

d

Create a directory. The mode and ownership will be adjusted if specified. Contents of this directory are subject to time-based cleanup if the age argument is specified.

D

Similar to d, but in addition the contents of the directory will be removed when --remove is used.

e

Adjust the mode and ownership of existing directories and remove their contents based on age. Lines of this type accept shell-style globs in place of normal path names. Contents of the directories are subject to time-based cleanup if the age argument is specified. If the age argument is "0", contents will be unconditionally deleted every time systemd-tmpfiles(8) --clean is run. For this entry to be useful, at least one of the mode, user, group, or age arguments must be specified, since otherwise this entry has no effect. As an exception, an entry with no effect may be useful when combined with !, see the examples.

Added in version 230.

v

Create a subvolume if the path does not exist yet, the file system supports subvolumes (btrfs), and the system itself is installed into a subvolume (specifically: the root directory / is itself a subvolume). Otherwise, create a normal directory, in the same way as d. A subvolume created with this line type is not assigned to any higher-level quota group. For that, use q or Q, which allow creating simple quota group hierarchies, see below.

Added in version 219.

q

Create a subvolume or directory the same as v, but assign the subvolume to the same higher-level quota groups as the parent. This ensures that higher-level limits and accounting applied to the parent subvolume also include the specified subvolume. On non-btrfs file systems, this line type is identical to d. If the subvolume already exists, no change to the quota hierarchy is made, regardless of whether the subvolume is already attached to a quota group or not. Also see Q below. See btrfs-qgroup(8) for details about the btrfs quota group concept.

Added in version 228.

Q

Create the subvolume or directory the same as v, but assign the new subvolume to a new leaf quota group. Instead of copying the higher-level quota group assignments from the parent as is done with q, the lowest quota group of the parent subvolume is determined that is not the leaf quota group. Then, an "intermediary" quota group is inserted that is one level below this level, and shares the same ID part as the specified subvolume. If no higher-level quota group exists for the parent subvolume, a new quota group at level 255 sharing the same ID as the specified subvolume is inserted instead. This new intermediary quota group is then assigned to the parent subvolume's higher-level quota groups, and the specified subvolume's leaf quota group is assigned to it. Effectively, this has a similar effect as q, however introduces a new higher-level quota group for the specified subvolume that may be used to enforce limits and accounting to the specified subvolume and children subvolume created within it. Thus, by creating subvolumes only via q and Q, a concept of "subtree quotas" is implemented. Each subvolume for which Q is set will get a "subtree" quota group created, and all child subvolumes created within it will be assigned to it. Each subvolume for which q is set will not get such a "subtree" quota group, but it is ensured that they are added to the same "subtree" quota group as their immediate parents.

It is recommended to use Q for subvolumes that typically contain further subvolumes, and where it is desirable to have accounting and quota limits on all child subvolumes together. Examples for Q are typically /home/ or /var/lib/machines/. In contrast, q should be used for subvolumes that either usually do not include further subvolumes or where no accounting and quota limits are needed that apply to all child subvolumes together. Examples for q are typically /var/ or /var/tmp/.

As with q, Q has no effect on the quota group hierarchy if the subvolume already exists, regardless of whether the subvolume already belong to a quota group or not.

Added in version 228.

p, p+

Create a named pipe (FIFO) if it does not exist yet. If suffixed with + and a file already exists where the pipe is to be created, it will be removed and be replaced by the pipe.

L, L+, L?

Create a symlink if it does not exist yet. If suffixed with + and a file or directory already exists where the symlink is to be created, it will be removed and be replaced by the symlink. If suffixed with ? and the source path does not exist, the symlink is not created. If the argument is omitted, symlinks to files with the same name residing in the directory /usr/share/factory/ are created. Note that permissions on symlinks are ignored.

c, c+

Create a character device node if it does not exist yet. If suffixed with + and a file already exists where the device node is to be created, it will be removed and be replaced by the device node. It is recommended to suffix this entry with an exclamation mark to only create static device nodes at boot, as udev will not manage static device nodes that are created at runtime.

b, b+

Create a block device node if it does not exist yet. If suffixed with + and a file already exists where the device node is to be created, it will be removed and be replaced by the device node. It is recommended to suffix this entry with an exclamation mark to only create static device nodes at boot, as udev will not manage static device nodes that are created at runtime.

C, C+

Recursively copy a file or directory, if the destination files or directories do not exist yet or the destination directory is empty. Note that this command will not descend into subdirectories if the destination directory already exists and is not empty, unless the action is suffixed with +. Instead, the entire copy operation is skipped. If the argument is omitted, files from the source directory /usr/share/factory/ with the same name are copied. Does not follow symlinks. Contents of the directories are subject to time-based cleanup if the age argument is specified. Added in version 214.

x

Ignore a path during cleaning. Use this type to exclude paths from clean-up as controlled with the Age parameter. Lines of this type accept shell-style globs in place of normal path names.

X

Ignore a path during cleaning. Use this type to exclude paths from clean-up as controlled with the Age parameter. Unlike x, this parameter will not exclude the content if path is a directory, but only directory itself. Lines of this type accept shell-style globs in place of normal path names. Added in version 198.

r

Remove a file or directory if it exists. This may not be used to remove non-empty directories, use R for that. Lines of this type accept shell-style globs in place of normal path names. Does not follow symlinks.

R

Recursively remove a path and all its subdirectories (if it is a directory). Lines of this type accept shell-style globs in place of normal path names. Does not follow symlinks.

z

Adjust the access mode, user and group ownership, and restore the SELinux security context of a file or directory, if it exists. Lines of this type accept shell-style globs in place of normal path names. Does not follow symlinks.

Z

Recursively set the access mode, user and group ownership, and restore the SELinux security context of a file or directory if it exists, as well as of its subdirectories and the files contained therein (if applicable). Lines of this type accept shell-style globs in place of normal path names. Does not follow symlinks.

t

Set extended attributes, see attr(5) for details. The argument field should take one or more assignment expressions in the form namespace.attribute=value, for examples see below. Lines of this type accept shell-style globs in place of normal path names. This can be useful for setting SMACK labels. Does not follow symlinks. Please note that extended attributes settable with this line type are a different concept from the Linux file attributes settable with h/H, see below.

Added in version 218.

T

Same as t, but operates recursively. Added in version 219.

h

Set Linux file/directory attributes. Lines of this type accept shell-style globs in place of normal path names. The format of the argument field is [+-=][aAcCdDeijPsStTu]. The prefix + (the default one) causes the attributes to be added; - causes the attributes to be removed; = causes the attributes to be set exactly as the following letters. The letters "aAcCdDeijPsStTu" select the new attributes for the files, see chattr(1) for further information.

Passing only = as argument resets all the file attributes listed above. It has to be pointed out that the = prefix limits itself to the attributes corresponding to the letters listed here. All other attributes will be left untouched. Does not follow symlinks.

Please note that the Linux file attributes settable with this line type are a different concept from the extended attributes settable with t/T, see above.

H

Sames as h, but operates recursively. Added in version 220.

a, a+

Set POSIX ACLs (access control lists), see acl(5). Additionally, if 'X' is used, the execute bit is set only if the file is a directory or already has execute permission for some user, as mentioned in setfacl(1). If suffixed with +, the specified entries will be added to the existing set. systemd-tmpfiles(8) will automatically add the required base entries for user and group based on the access mode of the file, unless base entries already exist or are explicitly specified. The mask will be added if not specified explicitly or already present. Lines of this type accept shell-style globs in place of normal path names. This can be useful for allowing additional access to certain files. Does not follow symlinks. Added in version 219.

A, A+

Same as a and a+, but recursive. Does not follow symlinks. Added in version 219.

### Type Modifiers
If the exclamation mark ("!") is used, this line is only safe to execute during boot, and can break a running system. Lines without the exclamation mark are presumed to be safe to execute at any time, e.g. on package upgrades. systemd-tmpfiles(8) will take lines with an exclamation mark only into consideration, if the --boot option is given.

For example:

```
# Make sure these are created by default so that nobody else can
d /tmp/.X11-unix 1777 root root 10d
# Unlink the X11 lock files
r! /tmp/.X[0-9]*-lock
```

The second line in contrast to the first one would break a running system, and will only be executed with --boot.

If the minus sign ("-") is used, this line failing to run successfully during create (and only create) will not cause the execution of systemd-tmpfiles(8) to return an error.

For example:

```
# Modify sysfs but do not fail if we are in a container with a read-only /proc
w- /proc/sys/vm/swappiness - - - - 10
```

If the equals sign ("=") is used, the file types of existing objects in the specified path are checked, and removed if they do not match. This includes any implicitly created parent directories (which can be either directories or directory symlinks). For example, if there is a FIFO in place of one of the parent path components it will be replaced with a directory.

If the tilde character ("~") is used, the argument (i.e. 6th) column is Base64 decoded[1] before use. This modifier is only supported on line types that can write file contents, i.e. f, f+, w, +. This is useful for writing arbitrary binary data (including newlines and NUL bytes) to files. Note that if this switch is used, the argument is not subject to specifier expansion, neither before nor after Base64 decoding.

If the caret character ("^") is used, the argument (i.e. 6th) column takes a service credential name to read the argument data from. See System and Service Credentials[2] for details about the credentials concept. This modifier is only supported on line types that can write file contents, i.e. f, f+, w, w+. This is useful for writing arbitrary files with contents sourced from elsewhere, including from VM or container managers further up. If the specified credential is not set for the systemd-tmpfiles service, the line is silently skipped. If "^" and "~" are combined Base64 decoding is applied to the credential contents.

If the dollar sign ("$") is used, the file becomes subject to removal when systemd-tmpfiles is invoked with the --purge switch. Lines without this character are unaffected by that switch.

Note that for all line types that result in creation of any kind of file node (i.e. f, d/D/v/q/Q, p, L, c/b and C) leading directories are implicitly created if needed, owned by root with an access mode of 0755. In order to create them with different modes or ownership make sure to add appropriate d lines.

### Path
The file system path specification supports simple specifier expansion, see below. The path (after expansion) must be absolute.

### Mode
The file access mode to use when creating this file or directory. If omitted or when set to "-", the default is used: 0755 for directories, 0644 for all other file objects. For z, Z lines, if omitted or when set to "-", the file access mode will not be modified. This parameter is ignored for x, r, R, L, t, and a lines.

Optionally, if prefixed with "~", the access mode is masked based on the already set access bits for existing file or directories: if the existing file has all executable bits unset, all executable bits are removed from the new access mode, too. Similarly, if all read bits are removed from the old access mode, they will be removed from the new access mode too, and if all write bits are removed, they will be removed from the new access mode too. In addition, the sticky/SUID/SGID bit is removed unless applied to a directory. This functionality is particularly useful in conjunction with Z.

By default, the access mode of listed inodes is set to the specified mode regardless of whether it is created anew, or already existed. Optionally, if prefixed with ":", the configured access mode is only applied when creating new inodes, and if the inode the line refers to already exists, its access mode is left in place unmodified.

### User, Group
The user and group to use for this file or directory. This may either be a numeric ID or a user/group name. If omitted or when set to "-", the user and group of the user who invokes systemd-tmpfiles(8) is used. For z and Z lines, when omitted or when set to "-", the file ownership will not be modified. These parameters are ignored for x, r, R, t, and a lines.

This field should generally only reference system users/groups, i.e. users/groups that are guaranteed to be resolvable during early boot. If this field references users/groups that only become resolvable during later boot (i.e. after NIS, LDAP or a similar networked directory service become available), execution of the operations declared by the line will likely fail. Also see Notes on Resolvability of User and Group Names[3] for more information on requirements on system user/group definitions.

By default, the ownership of listed inodes is set to the specified user/group regardless of whether it is created anew, or already existed. Optionally, if prefixed with ":", the configured user/group information is only applied when creating new inodes, and if the inode the line refers to already exists, its user/group is left in place unmodified.

### Age
The date field, when set, is used to decide what files to delete when cleaning. If a file or directory is older than the current time minus the age field, it is deleted. The field format is a series of integers each followed by one of the following suffixes for the respective time units: s, m or min, h, d, w, ms, and us, meaning seconds, minutes, hours, days, weeks, milliseconds, and microseconds, respectively. Full names of the time units can be used too.

If multiple integers and units are specified, the time values are summed. If an integer is given without a unit, s is assumed.

When the age is set to zero, the files are cleaned unconditionally.

The age field only applies to lines starting with d, D, e, v, q, Q, C, x and X. If omitted or set to "-", no automatic clean-up is done.

If the age field starts with a tilde character "~", clean-up is only applied to files and directories one level inside the directory specified, but not the files and directories immediately inside it.

The age of a file system entry is determined from its last modification timestamp (mtime), its last access timestamp (atime), and (except for directories) its last status change timestamp (ctime). By default, any of these three (or two) values will prevent cleanup if it is more recent than the current time minus the age field. To restrict the deletion based on particular type of file timestamps, the age-by argument can be used.

The age-by argument overrides the timestamp types to be used for the age check. It can be specified by prefixing the age argument with a sequence of characters to specify the timestamp types and a colon (":"): "age-by...:cleanup-age". The argument can consist of a (A for directories), b (B for directories), c (C for directories), or m (M for directories). Those respectively indicate access, creation, last status change, and last modification time of a file system entry. The lower-case letter signifies that the given timestamp type should be considered for files, while the upper-case letter signifies that the given timestamp type should be considered for directories. See statx(2) file timestamp fields for more details about timestamp types.

If not specified, the age-by field defaults to abcmABM, i.e. by default all file timestamps are taken into consideration, with the exception of the last status change timestamp (ctime) for directories. This is because the aging logic itself will alter the ctime whenever it deletes a file inside it. To ensure that running the aging logic does not feed back into the next iteration of itself, ctime for directories is ignored by default.

For example:

```
# Files created and modified, and directories accessed more than
# an hour ago in "/tmp/foo/bar", are subject to time-based cleanup.
d /tmp/foo/bar - - - bmA:1h -
```

Note that while the aging algorithm is run an exclusive BSD file lock (see flock(2)) is taken on each directory/file the algorithm decides to remove. If the aging algorithm finds a lock (shared or exclusive) is already taken on some directory/file, it (and everything below it) is skipped. Applications may use this to temporarily exclude certain directory subtrees from the aging algorithm: the applications can take a BSD file lock themselves, and as long as they keep it aging of the directory/file and everything below it is disabled.

This behavior can be used to ensure guaranteed cleanup of files or directories whose lifetime should be aligned with the process that created them by having that process create them in a location monitored by systemd-tmpfiles with an age of "0", and having the process immediately lock the directory or file before using it. Because the BSD lock is process specific, the file is guaranteed to be unlocked as soon as the process exits, meaning that even if the process crashes, those files and directories will be unlocked and cleaned up by systemd-tmpfiles.

### Argument
For L lines determines the destination path of the symlink. For c and b, determines the major/minor of the device node, with major and minor formatted as integers, separated by ":", e.g. "1:3". For f and w, the argument may be used to specify a short string that is written to the file, suffixed by a newline. For C, specifies the source file or directory. For t and T, determines extended attributes to be set. For a and A, determines ACL attributes to be set. For h and H, determines the file attributes to set. Ignored for all other lines.

This field can contain specifiers, see below.

## SPECIFIERS
Specifiers can be used in the "path" and "argument" fields. An unknown or unresolvable specifier is treated as invalid configuration. The following expansions are understood:

Table 1. Specifiers available

Specifier

Meaning

Details

"%a"

Architecture

A short string identifying the architecture of the local system. A string such as x86, x86-64 or arm64. See the architectures defined for ConditionArchitecture= in systemd.unit(5) for a full list.

"%A"

Operating system image version

The operating system image version identifier of the running system, as read from the IMAGE_VERSION= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%b"

Boot ID

The boot ID of the running system, formatted as string. See random(4) for more information.

"%B"

Operating system build ID

The operating system build identifier of the running system, as read from the BUILD_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%C"

System or user cache directory

In --user mode, this is the same as $XDG_CACHE_HOME, and /var/cache otherwise.

"%g"

User group

This is the name of the group running the command. In case of the system instance this resolves to "root".

"%G"

User GID

This is the numeric GID of the group running the command. In case of the system instance this resolves to 0.

"%h"

User home directory

This is the home directory of the user running the command. In case of the system instance this resolves to "/root".

"%H"

Host name

The hostname of the running system.

"%l"

Short host name

The hostname of the running system, truncated at the first dot to remove any domain component.

"%L"

System or user log directory

In --user mode, this is the same as $XDG_STATE_HOME with /log appended, and /var/log otherwise.

"%m"

Machine ID

The machine ID of the running system, formatted as string. See machine-id(5) for more information.

"%M"

Operating system image identifier

The operating system image identifier of the running system, as read from the IMAGE_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%o"

Operating system ID

The operating system identifier of the running system, as read from the ID= field of /etc/os-release. See os-release(5) for more information.

"%q"

Pretty host name

The pretty hostname of the running system, as read from the PRETTY_HOSTNAME= field of /etc/machine-info. If not set, resolves to the short hostname. See machine-info(5) for more information.

"%S"

System or user state directory

In --user mode, this is the same as $XDG_STATE_HOME, and /var/lib otherwise.

"%t"

System or user runtime directory

In --user mode, this is the same as $XDG_RUNTIME_DIR, and /run/ otherwise.

"%T"

Directory for temporary files

This is either /tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)

"%u"

User name

This is the name of the user running the command. In case of the system instance this resolves to "root".

"%U"

User UID

This is the numeric UID of the user running the command. In case of the system instance this resolves to 0.

"%v"

Kernel release

Identical to uname -r output.

"%V"

Directory for larger and persistent temporary files

This is either /var/tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)

"%w"

Operating system version ID

The operating system version identifier of the running system, as read from the VERSION_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%W"

Operating system variant ID

The operating system variant identifier of the running system, as read from the VARIANT_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%%"

Single percent sign

Use "%%" in place of "%" to specify a single percent sign.

## EXAMPLES
Example 1. Create directories with specific mode and ownership

screen(1), needs two directories created at boot with specific modes and ownership:

```
# /usr/lib/tmpfiles.d/screen.conf
d /run/screens  1777 root screen 10d
d /run/uscreens 0755 root screen 10d12h
```

Contents of /run/screens and /run/uscreens will be cleaned up after 10 and 10½ days, respectively.

Example 2. Create a directory with a SMACK attribute

```
D /run/cups - - - -
t /run/cups - - - - security.SMACK64=printing user.attr-with-spaces="foo bar"
```

The directory will be owned by root and have default mode. Its contents are not subject to time-based cleanup, but will be obliterated when systemd-tmpfiles --remove runs.

Example 3. Create a directory and prevent its contents from cleanup

abrt(1), needs a directory created at boot with specific mode and ownership and its content should be preserved from the automatic cleanup applied to the contents of /var/tmp:

```
# /usr/lib/tmpfiles.d/tmp.conf
d /var/tmp 1777 root root 30d
```

```
# /usr/lib/tmpfiles.d/abrt.conf
d /var/tmp/abrt 0755 abrt abrt -
```

Example 4. Apply clean up during boot and based on time

```
# /usr/lib/tmpfiles.d/dnf.conf
r! /var/cache/dnf/*/*/download_lock.pid
r! /var/cache/dnf/*/*/metadata_lock.pid
r! /var/lib/dnf/rpmdb_lock.pid
e  /var/cache/dnf/ - - - 30d
```

The lock files will be removed during boot. Any files and directories in /var/cache/dnf/ will be removed after they have not been accessed in 30 days.

Example 5. Empty the contents of a cache directory on boot

```
# /usr/lib/tmpfiles.d/krb5rcache.conf
e! /var/cache/krb5rcache - - - 0
```

Any files and subdirectories in /var/cache/krb5rcache/ will be removed on boot. The directory will not be created.

Example 6. Provision SSH public key access for root user via Credentials in QEMU

```
-smbios type=11,value=io.systemd.credential.binary:tmpfiles.extra=$(echo -e "d /root/.ssh 0750 root root -\nf~ /root/.ssh/authorized_keys 0600 root root - $(ssh-add -L | base64 -w 0)" | base64 -w 0)
```

By passing this line to QEMU, the public key of the current user will be encoded in base64, added to a tmpfiles.d line that tells systemd-tmpfiles(8) to decode it into /root/.ssh/authorized_keys, encode that line itself in base64 and pass it as a Credential that will be picked up by systemd from SMBIOS on boot.

## /RUN/ AND /VAR/RUN/
/var/run/ is a deprecated symlink to /run/, and applications should use the latter. systemd-tmpfiles will warn if /var/run/ is used.

## SEE ALSO
systemd(1), systemd-tmpfiles(8), systemd-delta(1), systemd.exec(5), attr(5), getfattr(1), setfattr(1), setfacl(1), getfacl(1), chattr(1), btrfs-subvolume(8), btrfs-qgroup(8)

## NOTES
1.

Base64 decoded

https://www.rfc-editor.org/rfc/rfc4648.html

2.

System and Service Credentials

https://systemd.io/CREDENTIALS

3.

Notes on Resolvability of User and Group Names

https://systemd.io/UIDS-GIDS/#notes-on-resolvability-of-user-and-group-names


user@.service

title: user@.service(5)

summary: System units to start the user manager

text:
# user@.service(5)

## NAME
user@.service, user-runtime-dir@.service, systemd-user-runtime-dir - System units to start the user manager

## SYNOPSIS
user@UID.service

user-runtime-dir@UID.service

/usr/lib/systemd/systemd-user-runtime-dir

user-UID.slice

## DESCRIPTION
The systemd(1) system manager (PID 1) starts user manager instances as user@UID.service, with the user's numerical UID used as the instance identifier. These instances use the same executable as the system manager, but running in a mode where it starts a different set of units. Each systemd --user instance manages a hierarchy of units specific to that user. See systemd(1) for a discussion of units and systemd.special(7) for a list of units that form the basis of the unit hierarchies of system and user units.

user@UID.service is accompanied by the system unit user-runtime-dir@UID.service, which creates the user's runtime directory /run/user/UID when started, and removes it when it is stopped. It also might apply runtime quota settings on /tmp/ and/or /dev/shm/ for the user. user-runtime-dir@UID.service executes the systemd-user-runtime-dir binary to do the actual work.

User processes may be started by the user@.service instance, in which case they will be part of that unit in the system hierarchy. They may also be started elsewhere, for example by sshd(8) or a display manager like gdm, in which case they form a .scope unit (see systemd.scope(5)). Both user@UID.service and the scope units are collected under the user-UID.slice.

Individual user-UID.slice slices are collected under user.slice, see systemd.special(7).

## CONTROLLING RESOURCES FOR LOGGED-IN USERS
Options that control resources available to logged-in users can be configured at a few different levels. As described in the previous section, user.slice contains processes of all users, so any resource limits on that slice apply to all users together. The usual way to configure them would be through drop-ins, e.g. /etc/systemd/system/user.slice.d/resources.conf.

The processes of a single user are collected under user-UID.slice. Resource limits for that user can be configured through drop-ins for that unit, e.g. /etc/systemd/system/user-1000.slice.d/resources.conf. If the limits should apply to all users instead, they may be configured through drop-ins for the truncated unit name, user-.slice. For example, configuration in /etc/systemd/system/user-.slice.d/resources.conf is included in all user-UID.slice units, see systemd.unit(5) for a discussion of the drop-in mechanism.

When a user logs in and a .scope unit is created for the session (see previous section), the creation of the scope may be managed through pam_systemd(8). This PAM module communicates with systemd-logind(8) to create the session scope and provide access to hardware resources. Resource limits for the scope may be configured through the PAM module configuration, see pam_systemd(8). Configuring them through the normal unit configuration is also possible, but since the name of the slice unit is generally unpredictable, this is less useful.

In general any resources that apply to units may be set for user@UID.service and the slice units discussed above, see systemd.resource-control(5) for an overview.

## EXAMPLES
Example 1. Hierarchy of control groups with two logged in users

```
$ systemd-cgls
Control group /:
-.slice
├─user.slice
│ ├─user-1000.slice
│ │ ├─user@1000.service
│ │ │ ├─pulseaudio.service
│ │ │ │ └─2386 /usr/bin/pulseaudio --daemonize=no
│ │ │ └─gnome-terminal-server.service
│ │ │   └─init.scope
│ │ │     ├─ 4127 /usr/libexec/gnome-terminal-server
│ │ │     └─ 4198 zsh
│ │ ...
│ │ └─session-4.scope
│ │   ├─ 1264 gdm-session-worker [pam/gdm-password]
│ │   ├─ 2339 /usr/bin/gnome-shell
│ │   ...
│ │ ├─session-19.scope
│ │   ├─6497 sshd: zbyszek [priv]
│ │   ├─6502 sshd: zbyszek@pts/6
│ │   ├─6509 -zsh
│ │   └─6602 systemd-cgls --no-pager
│ ...
│ └─user-1001.slice
│   ├─session-20.scope
│   │ ├─6675 sshd: guest [priv]
│   │ ├─6708 sshd: guest@pts/6
│   │ └─6717 -bash
│   └─user@1001.service
│     ├─init.scope
│     │ ├─6680 /usr/lib/systemd/systemd --user
│     │ └─6688 (sd-pam)
│     └─sleep.service
│       └─6706 /usr/bin/sleep 30
...
```

User with UID 1000 is logged in using gdm (session-4.scope) and ssh(1) (session-19.scope), and also has a user manager instance running (user@1000.service). User with UID 1001 is logged in using ssh (session-20.scope) and also has a user manager instance running (user@1001.service). Those are all (leaf) system units, and form part of the slice hierarchy, with user-1000.slice and user-1001.slice below user.slice. User units are visible below the user@.service instances (pulseaudio.service, gnome-terminal-server.service, init.scope, sleep.service).

Example 2. Default user resource limits

```
$ systemctl cat user-1000.slice
# /usr/lib/systemd/system/user-.slice.d/10-defaults.conf
# ...
[Unit]
Description=User Slice of UID %j
After=systemd-user-sessions.service
[Slice]
TasksMax=33%
```

The user-UID.slice units by default do not have a unit file. The resource limits are set through a drop-in, which can be easily replaced or extended following standard drop-in mechanisms discussed in the first section.

## SEE ALSO
systemd(1), systemd.service(5), systemd.slice(5), systemd.resource-control(5), systemd.exec(5), systemd.special(7), capsule@.service(5), pam(8)


vconsole.conf

title: vconsole.conf(5)

text:
# vconsole.conf(5)

## NAME
vconsole.conf - Configuration file for the virtual console

## SYNOPSIS
/etc/vconsole.conf

## DESCRIPTION
The /etc/vconsole.conf file configures the virtual console, i.e. keyboard mapping and console font. It is applied at boot by udev using 90-vconsole.rules file. You can safely mask this file if you want to avoid this kind of initialization.

The format of vconsole.conf is a newline-separated list of environment-like shell-compatible variable assignments, ignoring comments and empty lines. It is possible to source the configuration from shell scripts, however, beyond mere variable assignments no shell features are supported, allowing applications to read the file without implementing a shell compatible execution engine. See os-release(5) for a detailed description of the format.

Note that the kernel command line options vconsole.keymap=, vconsole.keymap_toggle=, vconsole.font=, vconsole.font_map=, vconsole.font_unimap= may be used to override the console settings at boot.

Depending on the operating system other configuration files might be checked for configuration of the virtual console as well, however only as fallback.

/etc/vconsole.conf is usually created and updated using systemd-localed.service(8). localectl(1) may be used to instruct systemd-localed.service to query or update configuration.

## OPTIONS
The following options are understood:

KEYMAP=, KEYMAP_TOGGLE=

Configures the key mapping table for the keyboard. KEYMAP= defaults to "us" if not set. Specially, if "@kernel" is specified, no keymap will be loaded, i.e. the kernel's default keymap is used. The KEYMAP_TOGGLE= can be used to configure a second toggle keymap and is by default unset.

FONT=, FONT_MAP=, FONT_UNIMAP=

Configures the console font, the console map and the unicode font map.

## KERNEL COMMAND LINE
A few configuration parameters from vconsole.conf may be overridden on the kernel command line:

vconsole.keymap=, vconsole.keymap_toggle=

Overrides KEYMAP= and KEYMAP_TOGGLE=. Added in version 232.

vconsole.font=, vconsole.font_map=, vconsole.font_unimap=

Overrides FONT=, FONT_MAP=, and FONT_UNIMAP=. Added in version 232.

## EXAMPLE
Example 1. German keyboard and console

/etc/vconsole.conf:

```
KEYMAP=de-latin1
FONT=eurlatgr
```

## SEE ALSO
systemd(1), systemd-vconsole-setup.service(8), loadkeys(1), setfont(8), locale.conf(5), systemd-localed.service(8)


veritytab

title: veritytab(5)

summary: Configuration for verity block devices

text:
# veritytab(5)

## NAME
veritytab - Configuration for verity block devices

## SYNOPSIS
/etc/veritytab

## DESCRIPTION
The /etc/veritytab file describes verity protected block devices that are set up during system boot.

Empty lines and lines starting with the "#" character are ignored. Each of the remaining lines describes one verity protected block device. Fields are delimited by white space.

Each line is in the form

```
volume-name data-device hash-device roothash [options]
```

The first four fields are mandatory, the remaining one is optional.

The first field contains the name of the resulting verity volume; its block device is set up below /dev/mapper/.

The second field contains a path to the underlying block data device, or a specification of a block device via UUID= followed by the UUID.

The third field contains a path to the underlying block hash device, or a specification of a block device via UUID= followed by the UUID.

The fourth field is the roothash in hexadecimal. If this field is specified as dash, it is attempted to read the root hash from the udev property "ID_DISSECT_PART_ROOTHASH=" (encoded in hexadecimal) of the data device.

The fifth field, if present, is a comma-delimited list of options. The following options are recognized:

superblock=BOOL

Use dm-verity with or without permanent on-disk superblock. Added in version 254.

format=NUMBER

Specifies the hash version type. Format type "0" is original Chrome OS version. Format type "1" is modern version. Added in version 254.

data-block-size=BYTES

Used block size for the data device. (Note kernel supports only page-size as maximum here; Multiples of 512 bytes.) Added in version 254.

hash-block-size=BYTES

Used block size for the hash device. (Note kernel supports only page-size as maximum here; Multiples of 512 bytes.) Added in version 254.

data-blocks=BLOCKS

Number of blocks of data device used in verification. If not specified, the whole device is used. Added in version 254.

hash-offset=BYTES

Offset of hash area/superblock on "hash-device". (Multiples of 512 bytes.) Added in version 254.

salt=HEX

Salt used for format or verification. Format is a hexadecimal string; 256 bytes long maximum; "-" is the special value for empty. Added in version 254.

uuid=UUID

Use the provided UUID instead of generating new one. The UUID must be provided in standard UUID format, e.g. "12345678-1234-1234-1234-123456789abc". Added in version 254.

ignore-corruption, restart-on-corruption, panic-on-corruption

Defines what to do if a data verity problem is detected (data corruption). Without these options kernel fails the IO operation with I/O error. With --ignore-corruption option the corruption is only logged. With --restart-on-corruption or --panic-on-corruption the kernel is restarted (panicked) immediately. (You have to provide way how to avoid restart loops.) Added in version 248.

ignore-zero-blocks

Instruct kernel to not verify blocks that are expected to contain zeroes and always directly return zeroes instead.

Warning

Use this option only in very specific cases. This option is available since Linux kernel version 4.5.

Added in version 248.

check-at-most-once

Instruct kernel to verify blocks only the first time they are read from the data device, rather than every time.

Warning

It provides a reduced level of security because only offline tampering of the data device's content will be detected, not online tampering. This option is available since Linux kernel version 4.17.

Added in version 248.

hash=HASH

Hash algorithm for dm-verity. This should be the name of the algorithm, like "sha1". For default see veritysetup --help. Added in version 254.

fec-device=PATH

Use forward error correction (FEC) to recover from corruption if hash verification fails. Use encoding data from the specified device. The fec device argument can be block device or file image. If fec device path does not exist, it will be created as file. Note: block sizes for data and hash devices must match. Also, if the verity data_device is encrypted the fec_device should be too. Added in version 254.

fec-offset=BYTES

This is the offset, in bytes, from the start of the FEC device to the beginning of the encoding data. (Aligned on 512 bytes.) Added in version 254.

fec-roots=NUM

Number of generator roots. This equals to the number of parity bytes in the encoding data. In RS(M, N) encoding, the number of roots is M-N. M is 255 and M-N is between 2 and 24 (including). Added in version 254.

root-hash-signature=PATH|base64:BASE64|auto

A Base64 string encoding the root hash signature prefixed by "base64:", or an absolute path to a root hash signature file used to verify the root hash (in kernel). If the special string "auto" is specified, the root hash signature is attempted to be read from the udev property "ID_DISSECT_PART_ROOTHASH_SIG=" (in Base64 format) of the data device. This feature requires Linux kernel version 5.4 or more recent. Added in version 248.

_netdev

Marks this veritysetup device as requiring network. It will be started after the network is available, similarly to systemd.mount(5) units marked with _netdev. The service unit to set up this device will be ordered between remote-fs-pre.target and remote-veritysetup.target, instead of veritysetup-pre.target and veritysetup.target. Hint: if this device is used for a mount point that is specified in fstab(5), the _netdev option should also be used for the mount point. Otherwise, a dependency loop might be created where the mount point will be pulled in by local-fs.target, while the service to configure the network is usually only started after the local file system has been mounted.

Added in version 248.

noauto

This device will not be added to veritysetup.target. This means that it will not be automatically enabled on boot, unless something else pulls it in. In particular, if the device is used for a mount point, it'll be enabled automatically during boot, unless the mount point itself is also disabled with noauto. Added in version 248.

nofail

This device will not be a hard dependency of veritysetup.target. It'll still be pulled in and started, but the system will not wait for the device to show up and be enabled, and boot will not fail if this is unsuccessful. Note that other units that depend on the enabled device may still fail. In particular, if the device is used for a mount point, the mount point itself also needs to have the nofail option, or the boot will fail if the device is not enabled successfully. Added in version 248.

x-initrd.attach

Setup this verity protected block device in the initrd, similarly to systemd.mount(5) units marked with x-initrd.mount. Although it is not necessary to mark the mount entry for the root file system with x-initrd.mount, x-initrd.attach is still recommended with the verity protected block device containing the root file system as otherwise systemd will attempt to detach the device during the regular system shutdown while it is still in use. With this option the device will still be detached but later after the root file system is unmounted.

All other verity protected block devices that contain file systems mounted in the initrd should use this option.

Added in version 248.

At early boot and when the system manager configuration is reloaded, this file is translated into native systemd units by systemd-veritysetup-generator(8).

## EXAMPLES
Example 1. /etc/veritytab example

Set up two verity protected block devices. One using device blocks, another using files.

```
usr  PARTUUID=783e45ae-7aa3-484a-beef-a80ff9c19cbb PARTUUID=21dc1dfe-4c33-8b48-98a9-918a22eb3e37 36e3f740ad502e2c25e2a23d9c7c17bf0fdad2300b7580842d4b7ec1fb0fa263 auto
data /etc/data /etc/hash a5ee4b42f70ae1f46a08a7c92c2e0a20672ad2f514792730f5d49d7606ab8fdf auto
```

## SEE ALSO
systemd(1), systemd-veritysetup@.service(8), systemd-veritysetup-generator(8), fstab(5), veritysetup(8)


loader.conf

package: systemd-boot-efi

title: loader.conf(5)

summary: Configuration file for systemd\-boot

text:
# loader.conf(5)

## NAME
loader.conf - Configuration file for systemd-boot

## SYNOPSIS
ESP/loader/loader.conf

## DESCRIPTION
systemd-boot(7) reads ESP/loader/loader.conf. This file configures whether the menu is shown and for how long, the font, audible beep, types of menu entries to show, the default choice, and some aspects of Secure Boot enrollment and firmware handling. See the list of available options below.

The file uses UTF-8 encoding and consists of series of lines separated by "line feed" (i.e. ASCII code 10). Lines that are empty or start with the comment sign ("#") are ignored. Other lines consist of an option name, followed by whitespace, and the option value.

Boolean arguments may be written as "yes"/"y"/"true"/"t"/"on"/"1" or "no"/"n"/"false"/"f"/"off"/"0".

Note: systemd-boot will also read boot loader entry files, type #1 (ESP/loader/entries/*.conf and XBOOTLDR/loader/entries/*.conf) and type #2 (ESP/EFI/Linux/*.uki and XBOOTLDR/EFI/Linux/*.uki). Those files are described by the Boot Loader Specification[1].

Note: the behaviour of systemd-boot is also influenced by EFI variables. Some of the settings specified in this file can be overridden by those, for example the default boot menu entry or the menu timeouts. See systemd-boot(7) for details.

## OPTIONS
The following configuration are supported in loader.conf:

default

A glob pattern to select the default entry by id, which is the file name including literal suffix ".conf". The default entry may be changed in the boot menu itself, in which case the name of the selected entry will be stored as an EFI variable, overriding this option. If set to "@saved" the chosen entry will be saved as an EFI variable on every boot and automatically selected the next time the boot loader starts.

Table 1. Automatically detected entries will use the following names:

Name

Description

auto-efi-default

EFI Default Loader

auto-efi-shell

EFI Shell

auto-osx

macOS

auto-poweroff

Power Off The System

auto-reboot

Reboot The System

auto-reboot-to-firmware-setup

Reboot Into Firmware Interface

auto-windows

Windows Boot Manager

Supported glob wildcard patterns are

"?", "*", and "[...]" (including ranges). Note that these patterns use the same syntax as glob(7), but do not support all features. In particular, set negation and named character classes are not supported. The matching is done case-insensitively on the entry ID (as shown by bootctl list).

Added in version 239.

timeout

How long the boot menu should be shown before the default entry is booted, in seconds. This may be changed in the boot menu itself and will be stored as an EFI variable in that case, overriding this option. If set to "menu-disabled" or "menu-hidden" or "0" (the default), no menu is shown and the default entry will be booted immediately. Unless "menu-disabled" is used, the menu can be shown by pressing and holding a key before systemd-boot is launched. Setting this to "menu-force" disables the timeout while always showing the menu.

Added in version 239.

console-mode

This option configures the resolution of the console. This may be changed in the boot menu itself and will be stored as an EFI variable in that case, overriding this option. Takes a number or one of the special values listed below. The following values may be used:

0

Standard UEFI 80x25 mode Added in version 239.

1

80x50 mode, not supported by all devices Added in version 239.

2

the first non-standard mode provided by the device firmware, if any Added in version 239.

auto

Pick a suitable mode automatically using heuristics Added in version 239.

max

Pick the highest-numbered available mode Added in version 239.

keep

Keep the mode selected by firmware (the default) Added in version 239.

Added in version 239.

editor

Takes a boolean argument. Enable (the default) or disable the editor. The editor should be disabled if the machine can be accessed by unauthorized persons. Added in version 239.

auto-entries

Takes a boolean argument. Enable (the default) or disable entries for other boot entries found on the boot partition. In particular, this may be useful when loader entries are created to show replacement descriptions for those entries. Added in version 239.

auto-firmware

A boolean controlling the presence of the "Reboot Into Firmware Interface" entry (enabled by default). If this is disabled, the firmware interface may still be reached by using the f key. Added in version 239.

auto-reboot

A boolean controlling the presence of the "Reboot The System" entry (disabled by default). Even if this is disabled, the system may still be rebooted by pressing Shift+b. Added in version 255.

auto-poweroff

A boolean controlling the presence of the "Power Off The System" entry (disabled by default). Even if this is disabled, the system may still be powered off by pressing Shift+o. Added in version 255.

beep

Takes a boolean argument. If timeout enabled beep every second, otherwise beep n times when n-th entry in boot menu is selected (default disabled). Currently, only x86 is supported, where it uses the PC speaker. Added in version 251.

secure-boot-enroll

Danger: this feature might soft-brick your device if used improperly. Controls enrollment of secure boot keys found on the ESP if the system is in setup mode:

if-safe

This is the default. Same behavior as manual, but will try to automatically enroll the key named "auto" if it is considered to be safe. Currently, this is only the case if the system is running inside a virtual machine. Added in version 253.

manual

Boot entries for found secure boot keys are created that allow manual enrollment. Added in version 253.

off

No action is taken. Added in version 253.

force

Always enroll the "auto" key if found. Note that a warning message with a timeout will still be shown if this operation is unknown to be safe. Added in version 253.

The different sets of variables can be set up under /loader/keys/NAME where NAME is the name that is going to be used as the name of the entry. This allows one to ship multiple sets of Secure Boot variables and choose which one to enroll at runtime.

Supported Secure Boot variables are one database for authorized images, one for the key exchange key (KEK) and one for the platform key (PK). For more information, refer to the UEFI specification[2], under Secure Boot and Driver Signing. Another resource that describe the interplay of the different variables is the EDK2 documentation[3].

A complete set of UEFI variable includes db.auth, KEK.auth and PK.auth. Note that these files need to be authenticated UEFI variables. See below for an example of how to generate them from regular X.509 keys.

```
uuid=$(systemd-id128 new --uuid)
for key in PK KEK db; do

  openssl req -new -x509 -subj "/CN=${key}/" -keyout "${key}.key" -out "${key}.pem"

  openssl x509 -outform DER -in "${key}.pem" -out "${key}.der"

  sbsiglist --owner "${uuid}" --type x509 --output "${key}.esl" "${key}.der"
done
# See also: Windows Secure Boot Key Creation and Management Guidance[4]
curl --location \

     "https://go.microsoft.com/fwlink/p/?linkid=321192" -o ms-db-2011.der \

     "https://go.microsoft.com/fwlink/p/?linkid=321185" -o ms-kek-2011.der \

     "https://go.microsoft.com/fwlink/p/?linkid=321194" -o ms-uefi-db-2011.der \

     "https://go.microsoft.com/fwlink/p/?linkid=2239776" -o ms-db-2023.der \

     "https://go.microsoft.com/fwlink/p/?linkid=2239775" -o ms-kek-2023.der \

     "https://go.microsoft.com/fwlink/p/?linkid=2239872" -o ms-uefi-db-2023.der
sha1sum -c <<END
580a6f4cc4e4b669b9ebdc1b2b3e087b80d0678d  ms-db-2011.der
31590bfd89c9d74ed087dfac66334b3931254b30  ms-kek-2011.der
46def63b5ce61cf8ba0de2e6639c1019d0ed14f3  ms-uefi-db-2011.der
45a0fa32604773c82433c3b7d59e7466b3ac0c67  ms-db-2023.der
459ab6fb5e284d272d5e3e6abc8ed663829d632b  ms-kek-2023.der
b5eeb4a6706048073f0ed296e7f580a790b59eaa  ms-uefi-db-2023.der
END
for key in ms-*.der; do

  sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output "${key%der}esl" "${key}"
done
# Optionally add Microsoft Windows certificates (needed to boot into Windows).
cat ms-db-*.esl >>db.esl
# Optionally add Microsoft UEFI certificates for firmware drivers / option ROMs and third-party
# boot loaders (including shim). This is highly recommended on real hardware as not including this
# may soft-brick your device (see next paragraph).
cat ms-uefi-*.esl >>db.esl
# Optionally add Microsoft KEK certificates. Recommended if either of the Microsoft keys is used as
# the official UEFI revocation database is signed with this key. The revocation database can be
# updated with fwupdmgr(1).
cat ms-kek-*.esl >>KEK.esl
attr=NON_VOLATILE,RUNTIME_ACCESS,BOOTSERVICE_ACCESS,TIME_BASED_AUTHENTICATED_WRITE_ACCESS
sbvarsign --attr "${attr}" --key PK.key --cert PK.pem --output PK.auth PK PK.esl
sbvarsign --attr "${attr}" --key PK.key --cert PK.pem --output KEK.auth KEK KEK.esl
sbvarsign --attr "${attr}" --key KEK.key --cert KEK.pem --output db.auth db db.esl
```

This feature is considered dangerous because even if all the required files are signed with the keys being loaded, some files necessary for the system to function properly still won't be. This is especially the case with Option ROMs (e.g. for storage controllers or graphics cards). See Secure Boot and Option ROMs[5] for more details.

Added in version 252.

secure-boot-enroll-action

Specifies the action to take after the automatic enrollment of secure boot keys is completed. reboot

Reboot the system after enrollment. This is the default.

shutdown

Shut down the system after enrollment.

This option is only relevant if "secure-boot-enroll" is enabled.

Added in version 258.

reboot-for-bitlocker

Caveat: This feature is experimental, and is likely to be changed (or removed in its current form) in a future version of systemd. Work around BitLocker requiring a recovery key when the boot loader was updated (disabled by default).

Try to detect BitLocker encrypted drives along with an active TPM. If both are found and Windows Boot Manager is selected in the boot menu, set the "BootNext" EFI variable and restart the system. The firmware will then start Windows Boot Manager directly, leaving the TPM PCRs in expected states so that Windows can unseal the encryption key. This allows systemd-boot(7) to be updated without having to provide the recovery key for BitLocker drive unlocking.

Note that the PCRs that Windows uses can be configured with the "Configure TPM platform validation profile for native UEFI firmware configurations" group policy under "Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption". When Secure Boot is enabled, changing this to PCRs "0,2,7,11" should be safe. The TPM key protector needs to be removed and then added back for the PCRs on an already encrypted drive to change. If PCR 4 is not measured, this setting can be disabled to speed up booting into Windows.

Added in version 251.

reboot-on-error

Controls auto reboot in case the selected entry fails to start. yes

Reboot the system if the selected boot entry failed to start.

no

Don't reboot - pass control back to EFI firmware.

auto

Perform the reboot if and only if boot counting is enabled for this entry and the tries left counter wasn't already at 0. This is the default, as it is typically a safe option, that ensures a clean measurement log on each boot attempt, but also does not risk an unbounded reboot loop.

Added in version 258.

## EXAMPLE

```
# /boot/efi/loader/loader.conf
timeout 0
default 01234567890abcdef1234567890abdf0-*
editor no
```

The menu will not be shown by default (the menu can still be shown by pressing and holding a key during boot). One of the entries with files with a name starting with "01234567890abcdef1234567890abdf0-" will be selected by default. If more than one entry matches, the one with the highest priority will be selected (generally the one with the highest version number). The editor will be disabled, so it is not possible to alter the kernel command line.

## SEE ALSO
systemd-boot(7), bootctl(1)

## NOTES
1.

Boot Loader Specification

https://uapi-group.org/specifications/specs/boot_loader_specification

2.

UEFI specification

https://uefi.org/specifications

3.

EDK2 documentation

https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/secure_boot_chain_in_uefi/uefi_secure_boot

4.

Windows Secure Boot Key Creation and Management Guidance

https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance

5.

Secure Boot and Option ROMs

https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom


bootchart.conf

package: systemd-bootchart

title: bootchart.conf(5)

text:
# bootchart.conf(5)

## NAME
bootchart.conf, bootchart.conf.d - Boot performance analysis graphing tool configuration files

## SYNOPSIS
/etc/systemd/bootchart.conf

/etc/systemd/bootchart.conf.d/*.conf

/run/systemd/bootchart.conf.d/*.conf

/lib/systemd/bootchart.conf.d/*.conf

## DESCRIPTION
When starting, systemd-bootchart will read the configuration file /etc/systemd/bootchart.conf, followed by the files in the bootchart.conf.d directories. These configuration files determine logging parameters and graph output.

## CONFIGURATION DIRECTORIES AND PRECEDENCE
The default configuration is defined during compilation, so a configuration file is only needed when it is necessary to deviate from those defaults. By default, the configuration file in /etc/systemd/ contains commented out entries showing the defaults as a guide to the administrator. This file can be edited to create local overrides.

When packages need to customize the configuration, they can install configuration snippets in /lib/systemd/*.conf.d/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. The main configuration file is read before any of the configuration directories, and has the lowest precedence; entries in a file in any configuration directory override entries in the single configuration file. Files in the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order, regardless of which of the subdirectories they reside in. If multiple files specify the same option, the entry in the file with the lexicographically latest name takes precedence. It is recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering of the files.

To disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file.

## OPTIONS
Samples=500

Configure the amount of samples to record in total before bootchart exits. Each sample will record at intervals defined by Frequency=.

Frequency=25

Configure the sample log frequency. This can be a fractional number, but must be larger than 0.0. Most systems can cope with values under 25-50 without impacting boot time severely.

Relative=no

Configures whether the left axis of the output graph equals time=0.0 (CLOCK_MONOTONIC start). This is useful for using bootchart at post-boot time to profile an already booted system, otherwise the graph would become extremely large. If set to yes, the horizontal axis starts at the first recorded sample instead of time=0.0.

Filter=no

Configures whether the resulting graph should omit tasks that did not contribute significantly to the boot. Processes that are too short-lived (only seen in one sample) or that do not consume any significant CPU time (less than 0.001sec) will not be displayed in the output graph.

Output=[path]

Configures the output directory for writing the graphs. By default, bootchart writes the graphs to /run/log.

Init=[path]

Configures bootchart to run a non-standard binary instead of /lib/systemd/systemd. This option is only relevant if bootchart was invoked from the kernel command line with init=/lib/systemd/systemd-bootchart.

PlotMemoryUsage=no

If set to yes, enables logging and graphing of processes' PSS memory consumption.

PlotEntropyGraph=no

If set to yes, enables logging and graphing of the kernel random entropy pool size.

ScaleX=100

Horizontal scaling factor for all variable graph components.

ScaleY=20

Vertical scaling factor for all variable graph components.

ControlGroup=no

Display process control group.

Cmdline=no

Display the full command line of each process.

## SEE ALSO
systemd-bootchart(1), systemd.directives(7)


machine-id

package: systemd-container

title: machine-id(5)

summary: Local machine ID configuration file

text:
# machine-id(5)

## NAME
machine-id - Local machine ID configuration file

## SYNOPSIS
/etc/machine-id

## DESCRIPTION
The /etc/machine-id file contains the unique machine ID of the local system that is set during installation or boot. The machine ID is a single newline-terminated, hexadecimal, 32-character, lowercase ID. When decoded from hexadecimal, this corresponds to a 16-byte/128-bit value. This ID may not be all zeros.

The machine ID is usually generated from a random source during system installation or first boot and stays constant for all subsequent boots. Optionally, for stateless systems, it is generated during runtime during early boot if necessary.

The machine ID may be set, for example when network booting, with the systemd.machine_id= kernel command line parameter or by passing the option --machine-id= to systemd. An ID specified in this manner has higher priority and will be used instead of the ID stored in /etc/machine-id.

The machine ID does not change based on local or network configuration or when hardware is replaced. Due to this and its greater length, it is a more useful replacement for the gethostid(3) call that POSIX specifies.

This machine ID adheres to the same format and logic as the D-Bus machine ID.

This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one. The sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm.

## INITIALIZATION
Each machine should have a non-empty ID in normal operation. The ID of each machine should be unique. To achieve those objectives, /etc/machine-id can be initialized in a few different ways.

For normal operating system installations, where a custom image is created for a specific machine, /etc/machine-id should be populated during installation.

systemd-machine-id-setup(1) may be used by installer tools to initialize the machine ID at install time, but /etc/machine-id may also be written using any other means.

For operating system images which are created once and used on multiple machines, for example for containers or in the cloud, /etc/machine-id should be either missing or an empty file in the generic file system image (the difference between the two options is described under "First Boot Semantics" below). An ID will be generated during boot and saved to this file if possible. Having an empty file in place is recommended because it allows a temporary file to be bind-mounted over the real file, in case the image is used read-only and when /etc is mounted read-only in the early boot. Also see Safely Building Images[1].

systemd-firstboot(1) may be used to initialize /etc/machine-id on mounted (but not booted) system images.

When a machine is booted with systemd(1) the ID of the machine will be established. If systemd.machine_id= or --machine-id= options (see first section) are specified, this value will be used. Otherwise, the value in /etc/machine-id will be used. If this file is empty or missing, systemd will attempt to use the D-Bus machine ID from /var/lib/dbus/machine-id, the value of the kernel command line option container_uuid, the KVM DMI product_uuid or the devicetree vm,uuid (on KVM systems), the Xen hypervisor uuid, and finally a randomly generated UUID. systemd.machine_id=firmware can be set to generate the machine ID from the firmware.

After the machine ID is established, systemd(1) will attempt to save it to /etc/machine-id. If this fails, it will attempt to bind-mount a temporary file over /etc/machine-id. It is an error if the file system is read-only and does not contain a (possibly empty) /etc/machine-id file.

systemd-machine-id-commit.service(8) will attempt to write the machine ID to the file system if /etc/machine-id or /etc/ are read-only during early boot but become writable later on.

## FIRST BOOT SEMANTICS
/etc/machine-id is used to decide whether a boot is the first one. The rules are as follows:

1.The kernel command argument systemd.condition_first_boot= may be used to override the autodetection logic, see kernel-command-line(7).

2.Otherwise, if /etc/machine-id does not exist, this is a first boot. During early boot, systemd will write "uninitialized\n" to this file and overmount a temporary file which contains the actual machine ID. Later (after first-boot-complete.target has been reached), the real machine ID will be written to disk.

3.If /etc/machine-id contains the string "uninitialized", a boot is also considered the first boot. The same mechanism as above applies.

4.If /etc/machine-id exists and is empty, a boot is not considered the first boot. systemd will still bind-mount a file containing the actual machine-id over it and later try to commit it to disk (if /etc/ is writable).

5.If /etc/machine-id already contains a valid machine-id, this is not a first boot.

If according to the above rules a first boot is detected, units with ConditionFirstBoot=yes will be run and systemd will perform additional initialization steps, in particular presetting units.

## RELATION TO OSF UUIDS
Note that the machine ID historically is not an OSF UUID as defined by RFC 4122[2], nor a Microsoft GUID; however, starting with systemd v30, newly generated machine IDs do qualify as Variant 1 Version 4 UUIDs, as per RFC 4122.

In order to maintain compatibility with existing installations, an application requiring a strictly RFC 4122 compliant UUID should decode the machine ID, and then (non-reversibly) apply the following operations to turn it into a valid RFC 4122 Variant 1 Version 4 UUID. With "id" being an unsigned character array:

```
/* Set UUID version to 4 --- truly random generation */
id[6] = (id[6] & 0x0F) | 0x40;
/* Set the UUID variant to DCE */
id[8] = (id[8] & 0x3F) | 0x80;
```

(This code is inspired by "generate_random_uuid()" of drivers/char/random.c from the Linux kernel sources.)

## HISTORY
The simple configuration file format of /etc/machine-id originates in the /var/lib/dbus/machine-id file introduced by D-Bus. In fact, this latter file might be a symlink to /etc/machine-id.

## SEE ALSO
systemd(1), systemd-machine-id-setup(1), gethostid(3), hostname(5), machine-info(5), os-release(5), sd-id128(3), sd_id128_get_machine(3), systemd-firstboot(1)

## NOTES
1.

Safely Building Images

https://systemd.io/BUILDING_IMAGES

2.

RFC 4122

https://tools.ietf.org/html/rfc4122


machine-info

title: machine-info(5)

summary: Local machine information file

text:
# machine-info(5)

## NAME
machine-info - Local machine information file

## SYNOPSIS
/etc/machine-info

## DESCRIPTION
The /etc/machine-info file contains machine metadata.

The format of machine-info is a newline-separated list of environment-like shell-compatible variable assignments, ignoring comments and empty lines. It is possible to source the configuration from shell scripts, however, beyond mere variable assignments no shell features are supported, allowing applications to read the file without implementing a shell compatible execution engine. See os-release(5) for a detailed description of the format.

/etc/machine-info contains metadata about the machine that is set by the user or administrator. The settings configured here have the highest precedence. When not set, appropriate values may be determined automatically, based on the information about the hardware or other configuration files. It is thus completely fine for this file to not be present.

You may use hostnamectl(1) to change the settings of this file from the command line.

## OPTIONS
The following machine metadata parameters may be set using /etc/machine-info:

### Machine Information
PRETTY_HOSTNAME=

A pretty human-readable UTF-8 machine identifier string. This should contain a name like "Lennart's Laptop" which is useful to present to the user and does not suffer by the syntax limitations of internet domain names. If possible, the internet hostname as configured in /etc/hostname should be kept similar to this one. Example: if this value is "Lennart's Computer" an Internet hostname of "lennarts-computer" might be a good choice. If this parameter is not set, an application should fall back to the Internet hostname for presentation purposes.

ICON_NAME=

An icon identifying this machine according to the XDG Icon Naming Specification[1]. If this parameter is not set, an application should fall back to "computer" or a similar icon name.

CHASSIS=

The chassis type. Currently, the following chassis types are defined: "desktop", "laptop", "convertible", "server", "tablet", "handset", "watch", and "embedded", as well as the special chassis types "vm" and "container" for virtualized systems that lack an immediate physical chassis. Note that most systems allow detection of the chassis type automatically (based on firmware information or suchlike). This setting should only be used to override a misdetection or to manually configure the chassis type where automatic detection is not available.

Added in version 197.

DEPLOYMENT=

Describes the system deployment environment. One of the following is suggested: "development", "integration", "staging", "testing", "production". Added in version 216.

LOCATION=

Describes the system location if applicable and known. Takes a human-friendly, free-form string. This may be as generic as "Berlin, Germany" or as specific as "Left Rack, 2nd Shelf". Added in version 216.

HARDWARE_VENDOR=

Specifies the hardware vendor. If unspecified, the hardware vendor set in DMI or hwdb(7) will be used. Added in version 251.

HARDWARE_MODEL=

Specifies the hardware model. If unspecified, the hardware model set in DMI or hwdb(7) will be used. Added in version 251.

HARDWARE_SKU=

Specifies the hardware SKU (Stock-Keeping Unit). If unspecified, the hardware SKU set in DMI will be used. Added in version 258.

HARDWARE_VERSION=

Specifies the hardware version. If unspecified, the hardware version set in DMI will be used. Added in version 258.

### Custom Fields
Operating system vendors and systemd administrators may extend the file format and introduce new fields. It is highly recommended to prefix new fields with an OS-specific name in order to avoid name clashes. Applications reading this file must ignore unknown fields.

Example: "_LOCAL_EMERGENCY_CONTACT="user@example.org"".

## EXAMPLE

```
PRETTY_HOSTNAME="Lennart's Tablet"
ICON_NAME=computer-tablet
CHASSIS=tablet
DEPLOYMENT=production
```

## SEE ALSO
systemd(1), os-release(5), hostname(5), machine-id(5), hostnamectl(1), systemd-hostnamed.service(8)

## NOTES
1.

XDG Icon Naming Specification

https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html