From 4160043a0fac8b812905b7502ce34adf3af538f1 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Tue, 6 Sep 2016 02:27:18 -0400 Subject: move man pages to appropriate directories --- src/systemd-nspawn/systemd-nspawn.xml | 1066 +++++++++++++++++++++++++++++++++ 1 file changed, 1066 insertions(+) create mode 100644 src/systemd-nspawn/systemd-nspawn.xml (limited to 'src/systemd-nspawn') diff --git a/src/systemd-nspawn/systemd-nspawn.xml b/src/systemd-nspawn/systemd-nspawn.xml new file mode 100644 index 0000000000..476cc2932f --- /dev/null +++ b/src/systemd-nspawn/systemd-nspawn.xml @@ -0,0 +1,1066 @@ + + + + + + + + + systemd-nspawn + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + systemd-nspawn + 1 + + + + systemd-nspawn + Spawn a namespace container for debugging, testing and building + + + + + systemd-nspawn + OPTIONS + COMMAND + ARGS + + + + systemd-nspawn + --boot + OPTIONS + ARGS + + + + + Description + + systemd-nspawn may be used to run a + command or OS in a light-weight namespace container. In many ways + it is similar to + chroot1, + but more powerful since it fully virtualizes the file system + hierarchy, as well as the process tree, the various IPC subsystems + and the host and domain name. + + systemd-nspawn limits access to various + kernel interfaces in the container to read-only, such as + /sys, /proc/sys or + /sys/fs/selinux. Network interfaces and the + system clock may not be changed from within the container. Device + nodes may not be created. The host system cannot be rebooted and + kernel modules may not be loaded from within the container. + + Note that even though these security precautions are taken + systemd-nspawn is not suitable for fully secure + container setups. Many of the security features may be + circumvented and are hence primarily useful to avoid accidental + changes to the host system from the container. + + In contrast to + chroot1 systemd-nspawn + may be used to boot full Linux-based operating systems in a + container. + + Use a tool like + dnf8, + debootstrap8, + or + pacman8 + to set up an OS directory tree suitable as file system hierarchy + for systemd-nspawn containers. + + Note that systemd-nspawn will mount file + systems private to the container to /dev, + /run and similar. These will not be visible + outside of the container, and their contents will be lost when the + container exits. + + Note that running two systemd-nspawn + containers from the same directory tree will not make processes in + them see each other. The PID namespace separation of the two + containers is complete and the containers will share very few + runtime objects except for the underlying file system. Use + machinectl1's + login command to request an additional login + prompt in a running container. + + systemd-nspawn implements the + Container + Interface specification. + + As a safety check systemd-nspawn will + verify the existence of /usr/lib/os-release + or /etc/os-release in the container tree + before starting the container (see + os-release5). + It might be necessary to add this file to the container tree + manually if the OS of the container is too old to contain this + file out-of-the-box. + + + + Options + + If option is specified, the arguments + are used as arguments for the init binary. Otherwise, + COMMAND specifies the program to launch + in the container, and the remaining arguments are used as + arguments for this program. If is not used and + no arguments are specified, a shell is launched in the + container. + + The following options are understood: + + + + + + + Directory to use as file system root for the + container. + + If neither , nor + is specified the directory is + determined by searching for a directory named the same as the + machine name specified with . See + machinectl1 + section "Files and Directories" for the precise search path. + + If neither , + , nor + are specified, the current directory will + be used. May not be specified together with + . + + + + + + Directory or btrfs + subvolume to use as template for the container's root + directory. If this is specified and the container's root + directory (as configured by ) + does not yet exist it is created as btrfs + subvolume and populated from this template tree. Ideally, the + specified template path refers to the root of a + btrfs subvolume, in which case a simple + copy-on-write snapshot is taken, and populating the root + directory is instant. If the specified template path does not + refer to the root of a btrfs subvolume (or + not even to a btrfs file system at all), + the tree is copied, which can be substantially more + time-consuming. Note that if this option is used the + container's root directory (in contrast to the template + directory!) must be located on a btrfs file + system, so that the btrfs subvolume may be + created. May not be specified together with + or + . + + Note that this switch leaves host name, machine ID and + all other settings that could identify the instance + unmodified. + + + + + + + If specified, the container is run with a + temporary btrfs snapshot of its root + directory (as configured with ), + that is removed immediately when the container terminates. + This option is only supported if the root file system is + btrfs. May not be specified together with + or + . + Note that this switch leaves host name, machine ID and + all other settings that could identify the instance + unmodified. + + + + + + + Disk image to mount the root directory for the + container from. Takes a path to a regular file or to a block + device node. The file or block device must contain + either: + + + An MBR partition table with a single + partition of type 0x83 that is marked + bootable. + + A GUID partition table (GPT) with a single + partition of type + 0fc63daf-8483-4772-8e79-3d69d8477de4. + + A GUID partition table (GPT) with a marked + root partition which is mounted as the root directory of the + container. Optionally, GPT images may contain a home and/or + a server data partition which are mounted to the appropriate + places in the container. All these partitions must be + identified by the partition types defined by the Discoverable + Partitions Specification. + + + Any other partitions, such as foreign partitions, swap + partitions or EFI system partitions are not mounted. May not + be specified together with , + or + . + + + + + + + Invoke the shell or specified program as process ID (PID) 2 instead of PID 1 (init). By + default, if neither this option nor is used, the selected binary is run as process with + PID 1, a mode only suitable for programs that are aware of the special semantics that the process with PID 1 + has on UNIX. For example, it needs to reap all processes reparented to it, and should implement + sysvinit compatible signal handling (specifically: it needs to reboot on SIGINT, reexecute + on SIGTERM, reload configuration on SIGHUP, and so on). With a minimal stub init + process is run as PID 1 and the selected binary is executed as PID 2 (and hence does not need to implement any + special semantics). The stub init process will reap processes as necessary and react appropriately to + signals. It is recommended to use this mode to invoke arbitrary commands in containers, unless they have been + modified to run correctly as PID 1. Or in other words: this switch should be used for pretty much all commands, + except when the command refers to an init or shell implementation, as these are generally capable of running + correctly as PID 1. This option may not be combined with or + . + + + + + + + + Automatically search for an init binary and invoke it as PID 1, instead of a shell or a user + supplied program. If this option is used, arguments specified on the command line are used as arguments for the + init binary. This option may not be combined with or + . + + The following table explains the different modes of invocation and relationship to + (see above): + + + Invocation Mode + + + + + + Switch + Explanation + + + + + Neither nor specified + The passed parameters are interpreted as the command line, which is executed as PID 1 in the container. + + + + specified + The passed parameters are interpreted as the command line, which is executed as PID 2 in the container. A stub init process is run as PID 1. + + + + specified + An init binary as automatically searched and run as PID 1 in the container. The passed parameters are used as invocation parameters for this process. + + + + +
+ + + + + + + Change to the specified working directory before invoking the process in the container. Expects + an absolute path in the container's file system namespace. + + + + + + + After transitioning into the container, change + to the specified user-defined in the container's user + database. Like all other systemd-nspawn features, this is not + a security feature and provides protection against accidental + destructive operations only. + + + + + + + Sets the machine name for this container. This + name may be used to identify this container during its runtime + (for example in tools like + machinectl1 + and similar), and is used to initialize the container's + hostname (which the container can choose to override, + however). If not specified, the last component of the root + directory path of the container is used, possibly suffixed + with a random identifier in case + mode is selected. If the root directory selected is the host's + root directory the host's hostname is used as default + instead. + + + + + + Set the specified UUID for the container. The + init system will initialize + /etc/machine-id from this if this file is + not set yet. Note that this option takes effect only if + /etc/machine-id in the container is + unpopulated. + + + + + + Make the container part of the specified + slice, instead of the default + machine.slice. This is only applies if + the machine is run in its own scope unit, i.e. if + is not used. + + + + + + + Set a unit property on the scope unit to + register for the machine. This only applies if the machine is + run in its own scope unit, i.e. if + is not used. Takes unit property + assignments in the same format as systemctl + set-property. This is useful to set memory limits + and similar for machines. + + + + + + + Controls user namespacing. If enabled, the container will run with its own private set of UNIX + user and group ids (UIDs and GIDs). This involves mapping the private UIDs/GIDs used in the container (starting + with the container's root user 0 and up) to a range of UIDs/GIDs on the host that are not used for other + purposes (usually in the range beyond the host's UID/GID 65536). The parameter may be specified as follows: + + + The value no turns off user namespacing. This is the default. + + The value yes (or the omission of a parameter) turns on user + namespacing. The UID/GID range to use is determined automatically from the file ownership of the root + directory of the container's directory tree. To use this option, make sure to prepare the directory tree in + advance, and ensure that all files and directories in it are owned by UIDs/GIDs in the range you'd like to + use. Also, make sure that used file ACLs exclusively reference UIDs/GIDs in the appropriate range. If this + mode is used the number of UIDs/GIDs assigned to the container for use is 65536, and the UID/GID of the + root directory must be a multiple of 65536. + + The value "pick" turns on user namespacing. In this case the UID/GID range is automatically + chosen. As first step, the file owner of the root directory of the container's directory tree is read, and it + is checked that it is currently not used by the system otherwise (in particular, that no other container is + using it). If this check is successful, the UID/GID range determined this way is used, similar to the + behaviour if "yes" is specified. If the check is not successful (and thus the UID/GID range indicated in the + root directory's file owner is already used elsewhere) a new – currently unused – UID/GID range of 65536 + UIDs/GIDs is randomly chosen between the host UID/GIDs of 524288 and 1878982656, always starting at a + multiple of 65536. This setting implies (see below), which has the + effect that the files and directories in the container's directory tree will be owned by the appropriate + users of the range picked. Using this option makes user namespace behaviour fully automatic. Note that the + first invocation of a previously unused container image might result in picking a new UID/GID range for it, + and thus in the (possibly expensive) file ownership adjustment operation. However, subsequent invocations of + the container will be cheap (unless of course the picked UID/GID range is assigned to a different use by + then). + + Finally if one or two colon-separated numeric parameters are specified, user namespacing is + turned on, too. The first parameter specifies the first host UID/GID to assign to the container, the second + parameter specifies the number of host UIDs/GIDs to assign to the container. If the second parameter is + omitted, 65536 UIDs/GIDs are assigned. + + + It is recommended to assign at least 65536 UIDs/GIDs to each container, so that the usable UID/GID range in the + container covers 16 bit. For best security, do not assign overlapping UID/GID ranges to multiple containers. It is + hence a good idea to use the upper 16 bit of the host 32-bit UIDs/GIDs as container identifier, while the lower 16 + bit encode the container UID/GID used. This is in fact the behaviour enforced by the + option. + + When user namespaces are used, the GID range assigned to each container is always chosen identical to the + UID range. + + In most cases, using is the recommended option as it enhances + container security massively and operates fully automatically in most cases. + + Note that the picked UID/GID range is not written to /etc/passwd or + /etc/group. In fact, the allocation of the range is not stored persistently anywhere, + except in the file ownership of the files and directories of the container. + + + + + + If the kernel supports the user namespaces feature, equivalent to + , otherwise equivalent to + . + + + + + + If specified, all files and directories in the container's directory tree will adjusted so that + they are owned to the appropriate UIDs/GIDs selected for the container (see above). This operation is + potentially expensive, as it involves descending and iterating through the full directory tree of the + container. Besides actual file ownership, file ACLs are adjusted as well. + + This option is implied if is used. This option has no effect if + user namespacing is not used. + + + + + + Disconnect networking of the container from + the host. This makes all network interfaces unavailable in the + container, with the exception of the loopback device and those + specified with and + configured with . If this + option is specified, the CAP_NET_ADMIN capability will be + added to the set of capabilities the container retains. The + latter may be disabled by using + . + + + + + + Assign the specified network interface to the + container. This will remove the specified interface from the + calling namespace and place it in the container. When the + container terminates, it is moved back to the host namespace. + Note that implies + . This option may be used + more than once to add multiple network interfaces to the + container. + + + + + + Create a macvlan interface + of the specified Ethernet network interface and add it to the + container. A macvlan interface is a virtual + interface that adds a second MAC address to an existing + physical Ethernet link. The interface in the container will be + named after the interface on the host, prefixed with + mv-. Note that + implies + . This option may be used + more than once to add multiple network interfaces to the + container. + + + + + + Create an ipvlan interface + of the specified Ethernet network interface and add it to the + container. An ipvlan interface is a virtual + interface, similar to a macvlan interface, + which uses the same MAC address as the underlying interface. + The interface in the container will be named after the + interface on the host, prefixed with iv-. + Note that implies + . This option may be used + more than once to add multiple network interfaces to the + container. + + + + + + + Create a virtual Ethernet link (veth) between host and container. The host + side of the Ethernet link will be available as a network interface named after the container's name (as + specified with ), prefixed with ve-. The container side of the + Ethernet link will be named host0. The option implies + . + + Note that + systemd-networkd.service8 + includes by default a network file /usr/lib/systemd/network/80-container-ve.network + matching the host-side interfaces created this way, which contains settings to enable automatic address + provisioning on the created virtual link via DHCP, as well as automatic IP routing onto the host's external + network interfaces. It also contains /usr/lib/systemd/network/80-container-host0.network + matching the container-side interface created this way, containing settings to enable client side address + assignment via DHCP. In case systemd-networkd is running on both the host and inside the + container, automatic IP communication from the container to the host is thus available, with further + connectivity to the external network. + + + + + + + Adds an additional virtual Ethernet link + between host and container. Takes a colon-separated pair of + host interface name and container interface name. The latter + may be omitted in which case the container and host sides will + be assigned the same name. This switch is independent of + , and — in contrast — may be + used multiple times, and allows configuration of the network + interface names. Note that + has no effect on interfaces created with + . + + + + + + Adds the host side of the Ethernet link created with to the + specified Ethernet bridge interface. Expects a valid network interface name of a bridge device as + argument. Note that implies . If this option + is used, the host side of the Ethernet link will use the vb- prefix instead of + ve-. + + + + + + Creates a virtual Ethernet link (veth) to the container and adds it to an + automatically managed Ethernet bridge interface. The bridge interface is named after the passed argument, + prefixed with vz-. The bridge interface is automatically created when the first container + configured for its name is started, and is automatically removed when the last container configured for its + name exits. Hence, each bridge interface configured this way exists only as long as there's at least one + container referencing it running. This option is very similar to , besides + this automatic creation/removal of the bridge device. + + This setting makes it easy to place multiple related containers on a common, virtual Ethernet-based + broadcast domain, here called a "zone". Each container may only be part of one zone, but each zone may contain + any number of containers. Each zone is referenced by its name. Names may be chosen freely (as long as they form + valid network interface names when prefixed with vz-), and it is sufficient to pass the same + name to the switch of the various concurrently running containers to join + them in one zone. + + Note that + systemd-networkd.service8 + includes by default a network file /usr/lib/systemd/network/80-container-vz.network + matching the bridge interfaces created this way, which contains settings to enable automatic address + provisioning on the created virtual network via DHCP, as well as automatic IP routing onto the host's external + network interfaces. Using is hence in most cases fully automatic and + sufficient to connect multiple local containers in a joined broadcast domain to the host, with further + connectivity to the external network. + + + + + + + + If private networking is enabled, maps an IP + port on the host onto an IP port on the container. Takes a + protocol specifier (either tcp or + udp), separated by a colon from a host port + number in the range 1 to 65535, separated by a colon from a + container port number in the range from 1 to 65535. The + protocol specifier and its separating colon may be omitted, in + which case tcp is assumed. The container + port number and its colon may be omitted, in which case the + same port as the host port is implied. This option is only + supported if private networking is used, such as with + , + . + + + + + + + Sets the SELinux security context to be used + to label processes in the container. + + + + + + + + Sets the SELinux security context to be used + to label files in the virtual API file systems in the + container. + + + + + + + List one or more additional capabilities to + grant the container. Takes a comma-separated list of + capability names, see + capabilities7 + for more information. Note that the following capabilities + will be granted in any way: CAP_CHOWN, CAP_DAC_OVERRIDE, + CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_IPC_OWNER, + CAP_KILL, CAP_LEASE, CAP_LINUX_IMMUTABLE, + CAP_NET_BIND_SERVICE, CAP_NET_BROADCAST, CAP_NET_RAW, + CAP_SETGID, CAP_SETFCAP, CAP_SETPCAP, CAP_SETUID, + CAP_SYS_ADMIN, CAP_SYS_CHROOT, CAP_SYS_NICE, CAP_SYS_PTRACE, + CAP_SYS_TTY_CONFIG, CAP_SYS_RESOURCE, CAP_SYS_BOOT, + CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL. Also CAP_NET_ADMIN is + retained if is specified. + If the special value all is passed, all + capabilities are retained. + + + + + + Specify one or more additional capabilities to + drop for the container. This allows running the container with + fewer capabilities than the default (see + above). + + + + + + Specify the process signal to send to the + container's PID 1 when nspawn itself receives SIGTERM, in + order to trigger an orderly shutdown of the + container. Defaults to SIGRTMIN+3 if + is used (on systemd-compatible init systems SIGRTMIN+3 + triggers an orderly shutdown). For a list of valid signals, see + signal7. + + + + + + Control whether the container's journal shall + be made visible to the host system. If enabled, allows viewing + the container's journal files from the host (but not vice + versa). Takes one of no, + host, try-host, + guest, try-guest, + auto. If no, the journal + is not linked. If host, the journal files + are stored on the host file system (beneath + /var/log/journal/machine-id) + and the subdirectory is bind-mounted into the container at the + same location. If guest, the journal files + are stored on the guest file system (beneath + /var/log/journal/machine-id) + and the subdirectory is symlinked into the host at the same + location. try-host and + try-guest do the same but do not fail if + the host does not have persistent journalling enabled. If + auto (the default), and the right + subdirectory of /var/log/journal exists, + it will be bind mounted into the container. If the + subdirectory does not exist, no linking is performed. + Effectively, booting a container once with + guest or host will link + the journal persistently if further on the default of + auto is used. + + + + + + Equivalent to + . + + + + + + Mount the root file system read-only for the + container. + + + + + + + Bind mount a file or directory from the host + into the container. Takes one of: a path argument — in which + case the specified path will be mounted from the host to the + same path in the container —, or a colon-separated pair of + paths — in which case the first specified path is the source + in the host, and the second path is the destination in the + container —, or a colon-separated triple of source path, + destination path and mount options. Mount options are + comma-separated and currently, only "rbind" and "norbind" + are allowed. Defaults to "rbind". Backslash escapes are interpreted, so + \: may be used to embed colons in either path. + This option may be specified multiple times for + creating multiple independent bind mount points. The + option creates read-only bind + mounts. + + + + + + Mount a tmpfs file system into the container. + Takes a single absolute path argument that specifies where to + mount the tmpfs instance to (in which case the directory + access mode will be chosen as 0755, owned by root/root), or + optionally a colon-separated pair of path and mount option + string that is used for mounting (in which case the kernel + default for access mode and owner will be chosen, unless + otherwise specified). This option is particularly useful for + mounting directories such as /var as + tmpfs, to allow state-less systems, in particular when + combined with . + Backslash escapes are interpreted in the path, so + \: may be used to embed colons in the path. + + + + + + + + Combine multiple directory trees into one + overlay file system and mount it into the container. Takes a + list of colon-separated paths to the directory trees to + combine and the destination mount point. + + Backslash escapes are interpreted in the paths, so + \: may be used to embed colons in the paths. + + + If three or more paths are specified, then the last + specified path is the destination mount point in the + container, all paths specified before refer to directory trees + on the host and are combined in the specified order into one + overlay file system. The left-most path is hence the lowest + directory tree, the second-to-last path the highest directory + tree in the stacking order. If + is used instead of , a read-only + overlay file system is created. If a writable overlay file + system is created, all changes made to it are written to the + highest directory tree in the stacking order, i.e. the + second-to-last specified. + + If only two paths are specified, then the second + specified path is used both as the top-level directory tree in + the stacking order as seen from the host, as well as the mount + point for the overlay file system in the container. At least + two paths have to be specified. + + For details about overlay file systems, see overlayfs.txt. Note + that the semantics of overlay file systems are substantially + different from normal file systems, in particular regarding + reported device and inode information. Device and inode + information may change for a file while it is being written + to, and processes might see out-of-date versions of files at + times. Note that this switch automatically derives the + workdir= mount option for the overlay file + system from the top-level directory tree, making it a sibling + of it. It is hence essential that the top-level directory tree + is not a mount point itself (since the working directory must + be on the same file system as the top-most directory + tree). Also note that the lowerdir= mount + option receives the paths to stack in the opposite order of + this switch. + + + + + + + Specifies an environment variable assignment + to pass to the init process in the container, in the format + NAME=VALUE. This may be used to override + the default variables or to set additional variables. This + parameter may be used more than once. + + + + + + Allows the container to share certain system + facilities with the host. More specifically, this turns off + PID namespacing, UTS namespacing and IPC namespacing, and thus + allows the guest to see and interact more easily with + processes outside of the container. Note that using this + option makes it impossible to start up a full Operating System + in the container, as an init system cannot operate in this + mode. It is only useful to run specific programs or + applications this way, without involving an init system in the + container. This option implies . + This option may not be combined with + . + + + + + + Controls whether the container is registered + with + systemd-machined8. + Takes a boolean argument, which defaults to yes. + This option should be enabled when the container runs a full + Operating System (more specifically: an init system), and is + useful to ensure that the container is accessible via + machinectl1 + and shown by tools such as + ps1. + If the container does not run an init system, it is + recommended to set this option to no. Note + that implies + . + + + + + + Instead of creating a transient scope unit to + run the container in, simply register the service or scope + unit systemd-nspawn has been invoked in + with + systemd-machined8. + This has no effect if is used. + This switch should be used if + systemd-nspawn is invoked from within a + service unit, and the service unit's sole purpose is to run a + single systemd-nspawn container. This + option is not available if run from a user + session. + + + + + + Control the architecture ("personality") + reported by + uname2 + in the container. Currently, only x86 and + x86-64 are supported. This is useful when + running a 32-bit container on a 64-bit host. If this setting + is not used, the personality reported in the container is the + same as the one reported on the host. + + + + + + + Turns off any status output by the tool + itself. When this switch is used, the only output from nspawn + will be the console output of the container OS + itself. + + + + + MODE + + Boots the container in volatile mode. When no + mode parameter is passed or when mode is specified as + , full volatile mode is enabled. This + means the root directory is mounted as a mostly unpopulated + tmpfs instance, and + /usr from the OS tree is mounted into it + in read-only mode (the system thus starts up with read-only OS + resources, but pristine state and configuration, any changes + to the either are lost on shutdown). When the mode parameter + is specified as , the OS tree is + mounted read-only, but /var is mounted as + a tmpfs instance into it (the system thus + starts up with read-only OS resources and configuration, but + pristine state, and any changes to the latter are lost on + shutdown). When the mode parameter is specified as + (the default), the whole OS tree is made + available writable. + + Note that setting this to or + will only work correctly with + operating systems in the container that can boot up with only + /usr mounted, and are able to populate + /var automatically, as + needed. + + + + MODE + + Controls whether + systemd-nspawn shall search for and use + additional per-container settings from + .nspawn files. Takes a boolean or the + special values or + . + + If enabled (the default), a settings file named after the + machine (as specified with the + setting, or derived from the directory or image file name) + with the suffix .nspawn is searched in + /etc/systemd/nspawn/ and + /run/systemd/nspawn/. If it is found + there, its settings are read and used. If it is not found + there, it is subsequently searched in the same directory as the + image file or in the immediate parent of the root directory of + the container. In this case, if the file is found, its settings + will be also read and used, but potentially unsafe settings + are ignored. Note that in both these cases, settings on the + command line take precedence over the corresponding settings + from loaded .nspawn files, if both are + specified. Unsafe settings are considered all settings that + elevate the container's privileges or grant access to + additional resources such as files or directories of the + host. For details about the format and contents of + .nspawn files, consult + systemd.nspawn5. + + If this option is set to , the + file is searched, read and used the same way, however, the order of + precedence is reversed: settings read from the + .nspawn file will take precedence over + the corresponding command line options, if both are + specified. + + If this option is set to , the + file is searched, read and used the same way, but regardless + of being found in /etc/systemd/nspawn/, + /run/systemd/nspawn/ or next to the image + file or container root directory, all settings will take + effect, however, command line arguments still take precedence + over corresponding settings. + + If disabled, no .nspawn file is read + and no settings except the ones on the command line are in + effect. + + + + + + + + + + Examples + + + Build and boot a minimal BLAG distribution in a container + + # dnf -y --releasever=210k --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=blag --enablerepo=updates install systemd passwd dnf blag-release vim-minimal +# systemd-nspawn -bD /srv/mycontainer + + This installs a minimal BLAG distribution into the + directory /srv/mycontainer/ + and then boots an OS in a namespace container in it. + + + + Spawn a shell in a container of a minimal gNewSense unstable distribution + + # debootstrap --arch=amd64 unstable ~/gnewsense-tree/ +# systemd-nspawn -D ~/gnewsense-tree/ + + This installs a minimal gNewSense unstable distribution into + the directory ~/gnewsense-tree/ and then + spawns a shell in a namespace container in it. + + + + Boot a minimal Parabola GNU/Linux-libre distribution in a container + + # pacstrap -c -d ~/parabola-tree/ base +# systemd-nspawn -bD ~/parabola-tree/ + + This installs a minimal Parabola GNU/Linux-libre distribution into the + directory ~/parabola-tree/ and then boots an OS + in a namespace container in it. + + + + Boot into an ephemeral <literal>btrfs</literal> snapshot of the host system + + # systemd-nspawn -D / -xb + + This runs a copy of the host system in a + btrfs snapshot which is removed immediately + when the container exits. All file system changes made during + runtime will be lost on shutdown, hence. + + + + Run a container with SELinux sandbox security contexts + + # chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container +# systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh + + + + + Exit status + + The exit code of the program executed in the container is + returned. + + + + See Also + + systemd1, + systemd.nspawn5, + chroot1, + dnf8, + debootstrap8, + pacman8, + systemd.slice5, + machinectl1, + btrfs8 + + + + -- cgit v1.2.3-54-g00ecf