Config-Model-Systemd

 view release on metacpan or  search on metacpan

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

',
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'RootMStack',
      {
        'description' => 'Takes a path to a
L<systemd.mstack(7)>
directory encapsulating a mount stack consisting of layers and bind mounts. Similar to
C<RootDirectory> and C<RootImage> this runs the service off a
distinct root file system, in this case set up via C<overlayfs>.

Since C<.mstack/> directories may reference disk images (DDIs) similar device
policy extensions and dependencies are in effect when C<RootMStack> is used as are
if C<RootImage> is used.',
        'type' => 'leaf',
        'value_type' => 'uniline'
      },
      'MountAPIVFS',
      {
        'description' => 'Takes a boolean argument. If on, a private mount namespace for the unit\'s processes is created

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

        'type' => 'list'
      },
      'ExtensionImages',
      {
        'cargo' => {
          'type' => 'leaf',
          'value_type' => 'uniline'
        },
        'description' => 'This setting is similar to C<MountImages> in that it mounts a file
system hierarchy from a block device node or loopback file, but instead of providing a destination
path, an overlay will be set up. This option expects a whitespace separated list of mount
definitions. Each definition consists of a source path, optionally followed by a colon and a list of
mount options.

A read-only OverlayFS will be set up on top of C</usr/> and
C</opt/> hierarchies for sysext images and C</etc/>
hierarchy for confext images. The order in which the images are listed will determine the
order in which the overlay is laid down: images specified first to last will result in overlayfs
layers bottom to top.

Mount options may be defined as a single comma-separated list of options, in which case they
will be implicitly applied to the root partition on the image, or a series of colon-separated tuples
of partition name and mount options. Valid partition names and mount options are the same as for
C<RootImageOptions> setting described above.

Each mount definition may be prefixed with C<->, in which case it will be
ignored when its source path does not exist. The source argument is a path to a block device node or
regular file. If the source path contains a C<:>, it needs to be escaped as

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

C<DevicePolicy>.',
        'type' => 'list'
      },
      'ExtensionDirectories',
      {
        'cargo' => {
          'type' => 'leaf',
          'value_type' => 'uniline'
        },
        'description' => 'This setting is similar to C<BindReadOnlyPaths> in that it mounts a file
system hierarchy from a directory, but instead of providing a destination path, an overlay will be set
up. This option expects a whitespace separated list of source directories.

A read-only OverlayFS will be set up on top of C</usr/> and
C</opt/> hierarchies for sysext images and C</etc/>
hierarchy for confext images. The order in which the directories are listed will determine
the order in which the overlay is laid down: directories specified first to last will result in overlayfs
layers bottom to top.

Each directory listed in C<ExtensionDirectories> may be prefixed with C<->,
in which case it will be ignored when its source path does not exist. Any mounts created with this option are
specific to the unit, and are not visible in the host\'s mount table.

These settings may be used more than once, each usage appends to the unit\'s list of directories
paths. If the empty string is assigned, the entire list of mount paths defined prior to this is
reset.

lib/Config/Model/models/Systemd/Common/Exec.pl  view on Meta::CPAN

If a service employs this option with
L<systemd.v(7)>,
and has C<RefreshOnReload=extensions> enabled (the default), the confexts will
be refreshed to pick up any changes on service reload. This only applies to confext extensions.
Note that in case a service has this configuration enabled at first, and then it is subsequently
removed in an update followed by a daemon-reload operation, reloading the confexts will be a no-op,
and a full service restart is required instead. See
L<systemd.service(5)>
also for details.

Note that usage from user units requires overlayfs support in unprivileged user namespaces,
which was first introduced in kernel v5.11.',
        'type' => 'list'
      },
      'User',
      {
        'description' => "Set the UNIX user or group that the processes are executed as, respectively. Takes a single
user or group name, or a numeric ID as argument. For system services (services run by the system service
manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of
systemd --user), the default is C<root>, but C<User> may be
used to specify a different user. For user services of any other user, switching user identity is not

lib/Config/Model/models/Systemd/Section/Service.pod  view on Meta::CPAN

    root=verity+signed+encrypted+unprotected+absent: \
    usr=verity+signed+encrypted+unprotected+absent
. I< Optional. Type uniline.  > 

=head2 RootMStack

Takes a path to a
L<systemd.mstack(7)>
directory encapsulating a mount stack consisting of layers and bind mounts. Similar to
C<RootDirectory> and C<RootImage> this runs the service off a
distinct root file system, in this case set up via C<overlayfs>.

Since C<.mstack/> directories may reference disk images (DDIs) similar device
policy extensions and dependencies are in effect when C<RootMStack> is used as are
if C<RootImage> is used. I< Optional. Type uniline.  > 

=head2 MountAPIVFS

Takes a boolean argument. If on, a private mount namespace for the unit's processes is created
and the API file systems C</proc/>, C</sys/>, C</dev/> and
C</run/> (as an empty C<tmpfs>) are mounted inside of it, unless they are

lib/Config/Model/models/Systemd/Section/Service.pod  view on Meta::CPAN

to C<DeviceAllow>. See
L<systemd.resource-control(5)>
for the details about C<DevicePolicy> or C<DeviceAllow>. Also, see
C<PrivateDevices> below, as it may change the setting of
C<DevicePolicy>. I< Optional. Type list of uniline.  > 

=head2 ExtensionImages

This setting is similar to C<MountImages> in that it mounts a file
system hierarchy from a block device node or loopback file, but instead of providing a destination
path, an overlay will be set up. This option expects a whitespace separated list of mount
definitions. Each definition consists of a source path, optionally followed by a colon and a list of
mount options.

A read-only OverlayFS will be set up on top of C</usr/> and
C</opt/> hierarchies for sysext images and C</etc/>
hierarchy for confext images. The order in which the images are listed will determine the
order in which the overlay is laid down: images specified first to last will result in overlayfs
layers bottom to top.

Mount options may be defined as a single comma-separated list of options, in which case they
will be implicitly applied to the root partition on the image, or a series of colon-separated tuples
of partition name and mount options. Valid partition names and mount options are the same as for
C<RootImageOptions> setting described above.

Each mount definition may be prefixed with C<->, in which case it will be
ignored when its source path does not exist. The source argument is a path to a block device node or
regular file. If the source path contains a C<:>, it needs to be escaped as

lib/Config/Model/models/Systemd/Section/Service.pod  view on Meta::CPAN

C<block-loop> and C<block-blkext> with C<rwm> mode
to C<DeviceAllow>. See
L<systemd.resource-control(5)>
for the details about C<DevicePolicy> or C<DeviceAllow>. Also, see
C<PrivateDevices> below, as it may change the setting of
C<DevicePolicy>. I< Optional. Type list of uniline.  > 

=head2 ExtensionDirectories

This setting is similar to C<BindReadOnlyPaths> in that it mounts a file
system hierarchy from a directory, but instead of providing a destination path, an overlay will be set
up. This option expects a whitespace separated list of source directories.

A read-only OverlayFS will be set up on top of C</usr/> and
C</opt/> hierarchies for sysext images and C</etc/>
hierarchy for confext images. The order in which the directories are listed will determine
the order in which the overlay is laid down: directories specified first to last will result in overlayfs
layers bottom to top.

Each directory listed in C<ExtensionDirectories> may be prefixed with C<->,
in which case it will be ignored when its source path does not exist. Any mounts created with this option are
specific to the unit, and are not visible in the host's mount table.

These settings may be used more than once, each usage appends to the unit's list of directories
paths. If the empty string is assigned, the entire list of mount paths defined prior to this is
reset.

lib/Config/Model/models/Systemd/Section/Service.pod  view on Meta::CPAN

If a service employs this option with
L<systemd.v(7)>,
and has C<RefreshOnReload=extensions> enabled (the default), the confexts will
be refreshed to pick up any changes on service reload. This only applies to confext extensions.
Note that in case a service has this configuration enabled at first, and then it is subsequently
removed in an update followed by a daemon-reload operation, reloading the confexts will be a no-op,
and a full service restart is required instead. See
L<systemd.service(5)>
also for details.

Note that usage from user units requires overlayfs support in unprivileged user namespaces,
which was first introduced in kernel v5.11. I< Optional. Type list of uniline.  > 

=head2 User

Set the UNIX user or group that the processes are executed as, respectively. Takes a single
user or group name, or a numeric ID as argument. For system services (services run by the system service
manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of
systemd --user), the default is C<root>, but C<User> may be
used to specify a different user. For user services of any other user, switching user identity is not
permitted, hence the only valid setting is the same user the user's service manager is running as. If no group