From c6980afcb230c86c64532e69c02a09a3fc329a5f Mon Sep 17 00:00:00 2001 From: Peter Boy Date: Dec 18 2022 17:08:42 +0000 Subject: Adjust all articles to the new design (with authors / revision line beyond title) --- diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc index 672b3c3..332dad8 100644 --- a/docs/modules/ROOT/nav.adoc +++ b/docs/modules/ROOT/nav.adoc @@ -15,11 +15,11 @@ ** xref:virtualization/vm-install-cloudimg-centos9.adoc[Creating a virtual machine using a distribution's Cloud base image] ** xref:virtualization/vm-management-cockpit.adoc[Managing virtual machines with Cockpit] -* xref:container-an-introduction.adoc[Containerization] -** xref:container-nspawn-install.adoc[Container systemd-nspawn – Installation] +* xref:containerization/index.adoc[Containerization] +** xref:containerization/systemd-nspawn-setup.adoc[Setting up Systemd Nspawn Container] * Providing services -** xref:services/postgresql-installation.adoc[PostgreSQL – Installation] +** xref:services/setup-postgresql.adoc[Setting up PostgreSQL Database Server] * Example Use Cases ** xref:usecase-gui-addon.adoc[Adding a graphical user interface] diff --git a/docs/modules/ROOT/pages/administration/dnsmasq.adoc b/docs/modules/ROOT/pages/administration/dnsmasq.adoc index 4dde80e..0d58055 100644 --- a/docs/modules/ROOT/pages/administration/dnsmasq.adoc +++ b/docs/modules/ROOT/pages/administration/dnsmasq.adoc @@ -1,12 +1,11 @@ = Setting up dnsmasq - a lightweight DHCP and DNS server Peter Boy; Emmmanuel Seyman :page-authors: {author}, {author_2} -:page-aliases: pages/sysadmin-dnsmasq.adoc +:revnumber: F35-F36 +:revdate: 2022-09-23 +// :revremark: a new beginning +:page-aliases: sysadmin-dnsmasq.adoc -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2022-05-14 | Last update: 2022-09-23 | Related Fedora Version(s): 35,36 -**** [abstract] ____ diff --git a/docs/modules/ROOT/pages/administration/index.adoc b/docs/modules/ROOT/pages/administration/index.adoc index f9e7878..010f0af 100644 --- a/docs/modules/ROOT/pages/administration/index.adoc +++ b/docs/modules/ROOT/pages/administration/index.adoc @@ -1,14 +1,12 @@ = Fedora Server Edition Basic Administration Guide Peter Boy; Jan Kuparinen; Emmanuel Seyman :page-authors: {author}, {author_2}, {author_3} -:page-aliases: pages/sysadmin-an-introduction.adoc +:revnumber: F35-F37 +:revdate: 2022-11-15 +// :revremark: a new beginning +:page-aliases: sysadmin-an-introduction.adoc -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2021-03-10 | Last update: 2022-11-15 | Related Fedora Version(s): 35,36,37 -**** - == What You Find Here Generic basic system administration is covered by Fedora's overall diff --git a/docs/modules/ROOT/pages/container-an-introduction.adoc b/docs/modules/ROOT/pages/container-an-introduction.adoc deleted file mode 100644 index a16be4c..0000000 --- a/docs/modules/ROOT/pages/container-an-introduction.adoc +++ /dev/null @@ -1,98 +0,0 @@ -= Containerization -Peter Boy; Jan Kuparinen -:page-authors: {author}, {author_2} - -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2022-02-09 | Last update: 2022-02-09 | Related Fedora Version(s): 34,35 -**** - -Since some years "Container" are on everyone's lips. It's a prominent subject of public dicsussion. Complete operating systems are rebuilt to serve primarily as runtime environments for containers. And in public discussion "container" are mostly equated with "Docker". It is hard to find software that is not at least also offered as a Docker image. And it didn't take long for the disadvantages of such a monopolization to become apparent, e.g. in the form of serious security risks. - -As we learn time and time again, one size does not fit all. A number of the advantages of containerization are widely agreed upon. But the needs and requirements in IT are so diverse that not all of them can be optimally realized by one implementation. Therefore, there are alternative container implementations with different application profiles. And containerization is not always helpful either. - -*Fedora Server supports and allows several alternatives that can be used depending on the local context and/or user's requirement profile.* - -== Containerization options in Fedora Server - -A common feature of all container systems is the sharing of the host kernel and the use of kernel capabilities (e.g. cnames) to achieve a certain mutual isolation and autonomy. - -They differ in implementation, architecture principles, toolset, runtime environment and community. A rough classification is the distinction between "system container" and "application container", roughly determined by the existence and scope of an init system. - -=== Podman - -Its characteristics are - -* Application container -* Security enhancement: no root privileges and no central controlling daemon required -* Optimized for the interaction of multiple, coordinated containers (a "pod"), each dedicated to a specific task and cooperating with others to accomplish a complex overall task (e.g. customer management with connection to a specific database system). Reinforces the architecture principle: one and only one application per container. -* Binary compatible container image as Docker, mutually usable -* Free open source software - -Podman is *natively supported by Fedora Server* and the recommended solution for application containers. - -=== Docker - -Its characteristics are - -* Application container -* Dependent on a daemon with ROOT privileges -* Huge trove of pre-built containers for all sorts of software -* Mixture of a free community edition and a commercial product - -Docker releases it own Community Edition for various distributions. Therefore there is *no native support* for Fedora Server, but a *vendor repository* maintained for Fedora. - -=== LXC (libvirt) - -Its characteristics are - -* System container, kind of "lightweight virtual machine" -* Administration of container runtimes supported by Libvirt management routines for virtual machines as well as by Cockpit libvirt module -* Container runtime solely dependent on kernel capabilities, no own toolset -* Creation of a container disk image is not considered a task of libvirt, but a matter for the administrator. It includes composing a xml-based descriptor file. Therefore, the toolset is rated as somewhat "rough". -* Free open source software - -Libvirt LXC is *natively supported by Fedora Server* (via libvirt as default virtualization tool) - -=== LXC (linux containers) - -Its characteristics are - -* System container -* One of the first implementations of containers and the "progenitor" of (meanwhile emancipated) Docker and Podman -* Complete toolset, container images, community. Its designated successor is LXD (see next). -* Free open source software - -Linux Container's LXC is *natively supported by Fedora Server* (in its LTS versions) - -=== LXD (linux containers) - -Its characteristics are - -* System container, kind of "lightweight virtual machine" -* LXC with advanced toolset -* Complete versatile toolset, including container images and active supportive community. -* Free open source software - -LXD is *not natively supported* by Fedora Server, but there is a *COPR project* available, Additionally there is *vendor support* for Fedora by a third party package manager. - -=== systemd-nspawn container - -Its characteristics are - -* System container as a "lightweight virtual machine" and also configurable as a kind of application container (with a stub init system) -* Toolset highly integrated into systemd system management and thus a strong simplification of administration and maintenance. -* Both technically stringent and systematic documentation as well as stringent naming and structuring of the toolset, which facilitates administration. -* Rather new development and currently still somewhat rough SELinux support (so far its weakest point). -* Free open source software - -The systemd-nspawn container is *natively supported by Fedora Server*. - -=== Linux Vserver - -It requires a modified kernel and is *not supported by Fedora Server* - -=== OpenVZ - -It uses a self customized version of RHEL / CentOS and is *not supported by Fedora Server* - diff --git a/docs/modules/ROOT/pages/container-nspawn-install.adoc b/docs/modules/ROOT/pages/container-nspawn-install.adoc deleted file mode 100644 index a9a0e09..0000000 --- a/docs/modules/ROOT/pages/container-nspawn-install.adoc +++ /dev/null @@ -1,643 +0,0 @@ -= Container systemd-nspawn – Installation -Peter Boy; Jan Kuparinen -:page-authors: {author}, {author_2} - -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date:2022-02-09 | Last update: 2022-07-05 | Related Fedora Release(s): 34-36 -**** - -The systemd-nspawn container runtime is part of the systemd system software. It has been offloaded into its own package, systemd-container, a while ago. - -The prerequisite is a fully installed basic system. A standard interface of the host to the public network is assumed, via which the container receives independent access (own IP). In addition an interface for an internal, protected net between containers and host is assumed, usually a bridge. It may be a virtual network within the host, e.g. libvirts virbr0, or a physical interface connecting multiple hosts. - -But of course a container can also be operated with other variations of a network connection or even without a network connection at all. - -== 1. Setting up the nspawn container infrastructure - -1. *Create a container storage area* -+ -The systemd-nspawn tools like machinctl look for containers in `/var/lib/machines` first. This directory is also created during the installation of the programs if it does not exist. -+ -Following the Fedora server storage scheme, create a logical volume, create a file system and mount it to `/var/lib/machines`. The tools can use BTRFS properties, so this can be used as a filesystem in this case. -If you don't want to follow the Fedora Server rationale, skip this step. -+ -[source,] ----- - […]# dnf install btrfs-progs - […]# lvcreate -L 20G -n machines {VGNAME} - […]# mkfs.btrfs -L machines /dev/mapper/{VGNAME}-machines - […]# mkdir /var/lib/machines - […]# vim /etc/fstab - (insert) - /dev/mapper/{VGNAME}-machines /var/lib/machines auto 0 0 - - […]# mount -a ----- -2. *Check and, if necessary, correct the SELinux labels* -+ -Ensure that the directory belongs to root and can only be accessed by root (should be done by the installer). -+ -[source,] ----- -[…]# restorecon -vFr /var/lib/machines -[…]# chown root:root /var/lib/machines -[…]# chmod 700 /var/lib/machines ----- -3. *Adding configuration for nspawn to the `etc/systemd` directory* -+ -[source,] ----- - […]# mkdir /etc/systemd/nspawn ----- - -== 2. Creating a nspawn container - -=== 2.1 Creating a container directory tree - -The creation of a container filesystem or the provision of a corresponding image is treated as "out of scope" by systemd-nspawn. There are a number of alternative options. By far the easiest and most efficient way is simply to use the distribution specific bootstrap tool, DNF in case of fedora, in the container’s directory. This is the recommended procedure. - -1. Creating a BTRFS subvolume with the name of the container -+ -[source,] ----- - […]# cd /var/lib/machines - […]# btrfs subvolume create {ctname} ----- -2. Creating a minimal container directory tree -+ -**__Fedora 34 / 35__** -+ -[source,] ----- - […]# dnf --releasever=35 --best --setopt=install_weak_deps=False --installroot=/var/lib/machines/{CTNAME}/ \ -install dhcp-client dnf fedora-release glibc glibc-langpack-en glibc-langpack-de iputils less ncurses passwd systemd systemd-networkd systemd-resolved vim-default-editor ----- -+ -F34 installs 165 packages (247M) and allocates 557M in the file system. -F35 installs 174 packages (270M) and allocates 527M in the file system. -+ -**__Fedora 36__** -+ -[source,] ----- - […]# dnf --releasever=36 --best --setopt=install_weak_deps=False --installroot=/var/lib/machines/{CTNAME}/ \ -install dhcp-client dnf fedora-release glibc glibc-langpack-en glibc-langpack-de iputils less ncurses passwd systemd systemd-networkd systemd-resolved util-linux vim-default-editor ----- -+ -F36 installs 171 packages (247M) and allocates 550M in the file system. -+ -**__CentOS 8-stream__** -+ -First create a separate CentOS repository file (e.g. /root/centos.repo) and import CentOS keys.On this basis, perform a standard installation using DNF. -+ -[source,] ----- - […]# vim /root/centos8.repo - - [centos8-chroot-base] - name=CentOS-8-Base - baseurl=http://mirror.centos.org/centos/8/BaseOS/x86_64/os/ - gpgcheck=1 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial - # - [centos8-chroot-appstream] - name=CentOS-8-stream-AppStream - #baseurl=http://mirror.centos.org/$contentdir/$stream/AppStream/$basearch/os/ - baseurl=http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/ - gpgcheck=1 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial - # - [epel8-chroot] - name=Epel-8 - baseurl=https://ftp.halifax.rwth-aachen.de/fedora-epel/8/Everything/x86_64/ - gpgcheck=1 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8 - - […]# dnf install http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/centos-gpg-keys-8-2.el8.noarch.rpm - - […]# rpm -Uvh --nodeps https:/dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - - […]# dnf -c /root/centos8.repo --releasever=8-stream --best --disablerepo=* --setopt=install_weak_deps=False --enablerepo=centos8-chroot-base --enablerepo=centos8-chroot-appstream --enablerepo=epel8-chroot --installroot=/var/lib/machines/{CTNAME} install centos-release dhcp-client dnf glibc-langpack-en glibc-langpack-de iproute iputils less passwd systemd systemd-networkd vim-enhanced - ----- -+ -This installs 165 packages that occupy 435 M in the file system. -The message: `install-info: File or directory not found for /dev/null` appears several times. The cause is that the `/dev/` file system is not yet initialized at this point. You may savely ignore the message. - -=== 2.2 Configuration and commissioning of a system container - -1. Setting the password for root -+ -This requires temporarily setting SELinux to permissive, otherwise passwd will not make any changes. -+ -[source,] ----- - […]# setenforce 0 - […]# systemd-nspawn -D /var/lib/machines/{ctname} passwd - […]# setenforce 1 ----- -2. Provision of network interfaces for the container within the host -+ -If only a connection to an internal, protected network is needed (replace the host bridge interface name accordingly): -+ -[source,] ----- - […]# vim /etc/systemd/nspawn/{ctname}.nspawn - (insert) - [Network] - Bridge=vbr6s0 ----- -+ -If a connection to the external, public network is also required, two corresponding interfaces must be provided, whereby a mac-vlan is used on the interface of the host for the external connection (again, replace the host interface names accordingly). -+ -[source,] ----- - […]# vim /etc/systemd/nspawn/{ctname}.nspawn - (insert) - [Network] - MACVLAN=enp4s0 - Bridge=vbr6s0 ----- - -3. Configuration of the connection to the internal network within the container -+ -[source,] ----- -[…]# vim /var/lib/machines/{ctname}/etc/systemd/network/20-host0.network - (insert) - # {ctname}.localnet - # internal network interface via bridge - # static configuration, no dhcp defined - [Match] - Name=host0* - - [Network] - DHCP=no - Address=10.10.10.yy/24 - #Gateway=10.10.10.10 - - LinkLocalAddressing=no - IPv6AcceptRA=no ----- -+ -If the internal network is also to be used for external access via NAT, the gateway entry must be commented in. Otherwise do not! - -4. Optionally, configure an additional connection to the public network via Mac Vlan -+ -In this case, the gateway entry _must_ be commented _out_ in the configuration of the internal network, as mentioned in item 3. -+ -[source,] ----- - […]# vim /var/lib/machinec/{ctname}/etc/systemd/network/10-mv.network - (insert) - # {ctname}.sowi.uni-bremen.de - # public interface via mac-vlan - # static configuration, no dhcp available - [Match] - Name=mv-enp* - - [Link] - ARP=True - - [Network] - DHCP=no - - # IPv4 static configuration, no DHCP configured! - Address=134.102.3.zz/27 - Gateway=134.102.3.30 - # without Destination specification - # treated as default! - #Destination= - - # IPv6 static configuration - Address=2001:638:708:f010::zzz/64 - IPv6AcceptRA=True - Gateway=2001:638:708:f010::1 - # in case of issues possible workaround - # cf https://github.com/systemd/systemd/issues/1850 - #GatewayOnlink=yes - - [IPv6AcceptRA] - UseOnLinkPrefix=False - UseAutonomousPrefix=False ----- -+ -Don't forget to adjust interface names and IP addresses accordingly! - -5. Boot the container and log in -+ -Check if container boots without error messages -+ -[source,] ----- - […]# systemd-nspawn -D /var/lib/machines/{ctname} -b - OK Spawning container {ctname} on /var/l…01. - OK … - {ctname} login: ----- -6. Checking the status of systemd-networkd -+ -If inactive, activate and start the service. -+ -[source,] ----- - […]# systemctl status systemd-networkd - … - […]# systemctl enable systemd-networkd - […]# systemctl start systemd-networkd - […]# systemctl status systemd-networkd ----- -7. Check if all network interfaces are available -+ -[source,] ----- - […]# ip a ----- -8. Check for correct routing -+ -[source,] ----- - […]# ip route show ----- -9. Configure default DNS search path -+ -Specify a search domain to appended to a unary hostname without domain part, usually the internal network domain name, e.g. example.lan. Adjust the config file according to the pattern below: -+ -[source,] ----- - […]# vim /etc/systemd/resolved.conf - - [Resolve] - ... - #dns.quad9.net - #DNS= - #FallbackDNS= - #Domains= - Domains=example.lan - #DNSSEC=no - ... ----- -10. Check if name resolution is configured correctly -+ -[source,] ----- - […]# ls -al /etc/resolv.conf - lrwxrwxrwx. 1 root root 39 29. Dez 12:15 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf ----- -+ -If the file is missing or is a text file, correct it. -+ -[source,] ----- - […]# cd /etc - […]# rm -f resolv.conf - […]# ln -s ../run/systemd/resolve/stub-resolv.conf resolv.conf - […]# ls -al /etc/resolv.conf - […]# cd ----- -+ -Ensure that systemd-resolved service is enabled. -+ -[source,] ----- - […]# systemctl status systemd-resolved ----- -+ -Activate the service if necessary. -+ -[source,] ----- - […]# systemctl enable systemd-resolved ----- - -11. Set the intended hostname -+ -[source,] ----- - […]# hostnamectl - […]# hostnamectl set-hostname ----- -12. Terminate the container -+ -[source,] ----- - […]# +]]] - Container terminated by signal KILL. ----- - -=== 2.2 Configuration and commissioning of an application container - -1. Setting the password for root -+ -This requires temporarily setting SELinux to permissive, otherwise passwd will not make any changes. -+ -[source,] ----- - […]# setenforce 0 - […]# systemd-nspawn -D /var/lib/machines/{ctname} passwd - […]# setenforce 1 ----- -2. Configuration of container properties -+ -Specifying private user configuration and shared network access. -+ -[source,] ----- - […]# vim /etc/systemd/nspawn/{ctname}.nspawn - (insert) - [Exec] - PrivateUsers=false - [Network] - Private=off - VirtualEthernet=false ----- -3. Boot the container and log in -+ -Check if container boots without error messages -+ -[source,] ----- - […]# systemd-nspawn -b -D /var/lib/machines/{ctname} - OK Spawning container {ctname} on /var/l…01. - OK … - {ctname} login: ----- -4. Checking the status of systemd-networkd -+ -If active, deactivate the service. -+ -[source,] ----- - […]# systemctl status systemd-networkd - … - […]# systemctl disable systemd-networkd - […]# systemctl stop systemd-networkd - […]# systemctl status systemd-networkd - […]# systemctl status systemd-resolved - … - […]# systemctl disable systemd-resolved - […]# systemctl stop systemd-resolved - […]# systemctl status systemd-resolved ----- -+ -If file /etc/resolv.conf is a link, remove it. -+ -[source,] ----- - […]# rm /etc/resolv.conf ----- -+ -Create (or edit an existing) file /etc/resolv.conf -+ -[source,] ----- - […]# vim /etc/resolv.conf - -nameserver 127.0.0.53 -options edns0 trust-ad -search ----- -5. Check if all network interfaces are available -+ -[source,] ----- - […]# ip a ----- -+ -You should see the same interfaces and IP addresses as on the host system. -6. Check if name resolution is working correctly -+ -[source,] ----- - […]# ping spiegel.de - PING spiegel.de (128.65.210.8) 56(84) bytes of data. - 64 bytes from 128.65.210.8 (128.65.210.8): icmp_seq=1 ttl=59 time=19.8 ms - ... ----- -7. Set the intended hostname -+ -[source,] ----- - […]# hostnamectl - […]# hostnamectl set-hostname ----- -8. Terminate the container -+ -[source,] ----- - […]# +]]] - Container terminated by signal KILL. ----- - -== 3. Starting the container as a system service for productive operation - -1. Booting the container using systemctl -+ -In this step, a separate UID/GID range is automatically created for the container. -+ -[source,] ----- - […]# systemctl enable systemd-nspawn@{ctname} - […]# systemctl start systemd-nspawn@{ctname} - […]# systemctl status systemd-nspawn@{ctname} ----- -+ -On first boot after installing systemd-container, a SELinux bug currently (Fedora 34/35) blocks execution. The solution is to fix the SELinux label(s). -+ -* Select the SELinux tab in Cockpit, preferably before booting the container for the first time. -* There, the AVCs are listed and solutions are offered, such as: -+ -`type=AVC msg=audit(1602592088.91:50075): avc: denied { search } for pid=35673 comm="systemd-machine" name="48865" dev="proc" ino=1070782 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=dir permissive=0` -+ -The proposed solution is roughly as follows: -+ -[source,] ----- -[…]# ausearch -c 'systemd-machine' --raw | audit2allow -M my-systemdmachine -[…]# semodule -i my-systemdmachine.pp ----- -* The operation must be repeated until no SELinux error is reported and the container starts as a service. -+ -Alternatively, the SELinux CLI tool can be used, which also suggests these solutions. - -2. Enable automatic start of the container at system startup -+ -[source,] ----- - […]# systemctl enable systemd-nspawn@{ctname} - […]# systemctl status systemd-nspawn@{ctname} ----- - -3. Log in to the container -+ -[source,] ----- - […]# setenforce 0 - […]# machinectl login {ctname} ----- -+ -When machinectl is called with parameters for the first time, an SELinux bug (Fedora 34/35) also blocks execution. The correction is done in the same way as for the container start. - -4. Completing and finalizing the container configuration -+ -Within the container, perform other designated software installations and customizations. -+ -In case of a CentOS 8-stream container, the epel repository should be installed (dnf install epel-release-latest-8) so that systemd-networkd is provided with updates. - -5. Logging off from the container -+ -After finishing all further work inside the container press ]]] ( Mac: 666) to exit the container and reactivate SELinux. -+ -[source,] ----- - […]# setenforce 1 ----- - -=== 3.1 Autostart of the container on reboot of the host - -An autostart of the container in the "enabled" state fails on Fedora 35 and older. The cause can be seen in a status query after rebooting the host, which issues an error message according to the following example: - -[source,] ----- - […]# systemctl status systemd-nspawn@CT_NAME - systemd-nspawn[802]: Failed to add interface vb-{CT_NAME} to bridge vbr6s0: No such device ----- - -This means that systemd starts the container before all required network interfaces are available. - -==== Resolution for (physical) interfaces managed by NetworkManager - -1. The service file requires an amendment (Bug #2001631). In section [Unit], for the `Wants=` and `After=` configurations, add a target `network-online.target` at the end of each line. The file must then look like this (ignore the commented out marker rows): -+ -[source,] ----- - […]# systemctl edit systemd-nspawn@ --full - ... - [Unit] - Description=Container %i - Documentation=man:systemd-nspawn(1) - Wants=modprobe@tun.service modprobe@loop.service modprobe@dm-mod.service network-online.target - ### ^^^^^^^^^^^^^^^^^^^^^ - PartOf=machines.target - Before=machines.target - After=network.target systemd-resolved.service modprobe@tun.service modprobe@loop.service modprobe@dm-mod.service network-online.target - ### ^^^^^^^^^^^^^^^^^^^^^ - RequiresMountsFor=/var/lib/machines/%i - ... ----- -+ -Important is the character "@" after `nspawn`! In the opening editor make the insertions and save them. - -2. Then execute -+ -[source,] ----- - […]# systemctl daemon-reload ----- - -At the next reboot the containers will be started automatically. - -==== Resolution for virtual interfaces managed by libvirt - -For such interfaces (usually the bridge virbr0) the addition mentioned above does not help. The container must be started by script in an extra step after Libvirt initialization is complete. For this you can use a hook that Libvirt provides. - -[source,] ----- -[…]# mkdir -p /etc/libvirt/hooks/network.d/ -[…]# vim /etc/libvirt/hooks/network.d/50-start-nspawn-container.sh -(INSERT) -#!/bin/bash -# Check defined nspawn container in /var/lib/machines and -# start every container that is enabled. -# The network-online.target in systemd-nspawn@ service file -# does not (yet) wait for libvirt managed interfaces. -# We need to start it decidely when the libvirt bridge is ready. - -# $1 : network name, eg. Default -# $2 : one of "start" | "started" | "port-created" -# $3 : always "begin" -# see https://libvirt.org/hooks.html - -set -o nounset - -network="$1" -operation="$2" -suboperation="$3" - -ctdir="/var/lib/machines/" -ctstartlog="/var/log/nspawn-ct-startup.log" - -echo " P1: $1 - P2: $2 - P3: $3 @ $(date) " -echo " " > $ctstartlog -echo "=======================================" >> $ctstartlog -echo " Begin $(date) " >> $ctstartlog -echo " P1: $1 - P2: $2 - P3: $3 " >> $ctstartlog - -if [ "$network" == "default" ]; then - if [ "$operation" == "started" ] && [ "$suboperation" == "begin" ]; then - for file in $ctdir/* ; do - echo "Checking: $file " >> $ctstartlog - echo " Filename: $(basename $file) " >> $ctstartlog - echo " Status: $(systemctl is-enabled systemd-nspawn@$(basename $file) ) " >> $ctstartlog - - if [ "$(systemctl is-enabled systemd-nspawn@$(basename $file) )" == "enabled" ]; then - echo " Starting Container $(basename $file) ... " >> $ctstartlog - systemctl start systemd-nspawn@$(basename $file) - echo "Container $(basename $file) started" >> $ctstartlog - fi - done - fi -fi - -[…]# chmod +x /etc/libvirt/hooks/network.d/50-start-nspawn-container.sh ----- -You may also use the link:{attachmentsdir}/nspawn-autostart-libvirt-hook.tgz[attached script] instead of typing. - -== 4. Troubleshooting - -=== 4.1 RPM DB problem in a CentOS 8-stream container on Fedora host - -For dnf / rpm queries the error message is displayed: -`warning: Found SQLITE rpmdb.sqlite database while attempting bdb backend: using sqlite backend` - -The cause is that Fedora's dfn, which is used for the installation, uses sqlite while CentOS/RHEL use the Berkeley (bdb) format. - -Check configuration within the running container: -[source,] ----- - […]# rpm -E "%{_db_backend}" ----- -The output must be `bdb`. Then fix it executing -[source,] ----- - […]# rpmdb --rebuilddb ----- - -=== 4.2 Error message dev-hugepages - -You will find message such as -[source,] ----- -dev-hugepages.mount: Mount process exited, code=exited, status=32/n/a -dev-hugepages.mount: Failed with result 'exit-code'. -[FAILED] Failed to mount Huge Pages File System. -See 'systemctl status dev-hugepages.mount' for details. ----- -DFN installs this by default, but it is not applicable inside a container. It is a general kernel configuration that cannot be changed by a container (at least as long as it is not configurable within namespaces). - -The messages can be safely ignored. - -=== 4.3 Package update may fail - -Some packages, e.g. the `filesystem` package, may not get updated in a container (error message "Error: Transaction failed"), see also https://bugzilla.redhat.com/show_bug.cgi?id=1548403 and https://bugzilla.redhat.com/show_bug.cgi?id=1912155. - -Workaround: Run before update: -[source,] ----- - […]# echo '%_netsharedpath /sys:/proc' > /etc/rpm/macros.netshared ----- -When an update has already been performed, execute this command and update the package again. - -As of Fedora 35, the bug should be fixed. - diff --git a/docs/modules/ROOT/pages/containerization/index.adoc b/docs/modules/ROOT/pages/containerization/index.adoc new file mode 100644 index 0000000..168459a --- /dev/null +++ b/docs/modules/ROOT/pages/containerization/index.adoc @@ -0,0 +1,97 @@ += Containerization +Peter Boy +:page-authors: {author} +:revnumber: F34-F37 +:revdate: 2022-11-05 +// :revremark: a new beginning +:page-aliases: container-an-introduction.adoc + +Since some years "Container" are on everyone's lips. It's a prominent subject of public dicsussion. Complete operating systems are rebuilt to serve primarily as runtime environments for containers. And in public discussion "container" are mostly equated with "Docker". It is hard to find software that is not at least also offered as a Docker image. And it didn't take long for the disadvantages of such a monopolization to become apparent, e.g. in the form of serious security risks. + +As we learn time and time again, one size does not fit all. A number of the advantages of containerization are widely agreed upon. But the needs and requirements in IT are so diverse that not all of them can be optimally realized by one implementation. Therefore, there are alternative container implementations with different application profiles. And containerization is not always helpful either. + +*Fedora Server supports and allows several alternatives that can be used depending on the local context and/or user's requirement profile.* + +== Containerization options in Fedora Server + +A common feature of all container systems is the sharing of the host kernel and the use of kernel capabilities (e.g. cnames) to achieve a certain mutual isolation and autonomy. + +They differ in implementation, architecture principles, toolset, runtime environment and community. A rough classification is the distinction between "system container" and "application container", roughly determined by the existence and scope of an init system. + +=== Podman + +Its characteristics are + +* Application container +* Security enhancement: no root privileges and no central controlling daemon required +* Optimized for the interaction of multiple, coordinated containers (a "pod"), each dedicated to a specific task and cooperating with others to accomplish a complex overall task (e.g. customer management with connection to a specific database system). Reinforces the architecture principle: one and only one application per container. +* Binary compatible container image as Docker, mutually usable +* Free open source software + +Podman is *natively supported by Fedora Server* and the recommended solution for application containers. + +=== Docker + +Its characteristics are + +* Application container +* Dependent on a daemon with ROOT privileges +* Huge trove of pre-built containers for all sorts of software +* Mixture of a free community edition and a commercial product + +Docker releases it own Community Edition for various distributions. Therefore there is *no native support* for Fedora Server, but a *vendor repository* maintained for Fedora. + +=== LXC (libvirt) + +Its characteristics are + +* System container, kind of "lightweight virtual machine" +* Administration of container runtimes supported by Libvirt management routines for virtual machines as well as by Cockpit libvirt module +* Container runtime solely dependent on kernel capabilities, no own toolset +* Creation of a container disk image is not considered a task of libvirt, but a matter for the administrator. It includes composing a xml-based descriptor file. Therefore, the toolset is rated as somewhat "rough". +* Free open source software + +Libvirt LXC is *natively supported by Fedora Server* (via libvirt as default virtualization tool) + +=== LXC (linux containers) + +Its characteristics are + +* System container +* One of the first implementations of containers and the "progenitor" of (meanwhile emancipated) Docker and Podman +* Complete toolset, container images, community. Its designated successor is LXD (see next). +* Free open source software + +Linux Container's LXC is *natively supported by Fedora Server* (in its LTS versions) + +=== LXD (linux containers) + +Its characteristics are + +* System container, kind of "lightweight virtual machine" +* LXC with advanced toolset +* Complete versatile toolset, including container images and active supportive community. +* Free open source software + +LXD is *not natively supported* by Fedora Server, but there is a *COPR project* available, Additionally there is *vendor support* for Fedora by a third party package manager. + +=== systemd-nspawn container + +Its characteristics are + +* System container as a "lightweight virtual machine" and also configurable as a kind of application container (with a stub init system) +* Toolset highly integrated into systemd system management and thus a strong simplification of administration and maintenance. +* Both technically stringent and systematic documentation as well as stringent naming and structuring of the toolset, which facilitates administration. +* Rather new development and currently still somewhat rough SELinux support (so far its weakest point). +* Free open source software + +The systemd-nspawn container is *natively supported by Fedora Server*. + +=== Linux Vserver + +It requires a modified kernel and is *not supported by Fedora Server* + +=== OpenVZ + +It uses a self customized version of RHEL / CentOS and is *not supported by Fedora Server* + diff --git a/docs/modules/ROOT/pages/containerization/systemd-nspawn-setup.adoc b/docs/modules/ROOT/pages/containerization/systemd-nspawn-setup.adoc new file mode 100644 index 0000000..d8e6086 --- /dev/null +++ b/docs/modules/ROOT/pages/containerization/systemd-nspawn-setup.adoc @@ -0,0 +1,642 @@ += Setting up Systemd Nspawn Container +Peter Boy; Jan Kuparinen +:page-authors: {author}, {author_2} +:revnumber: F34-F36 +:revdate: 2022-07-05 +// :revremark: a new beginning +:page-aliases: container-nspawn-install.adoc + +The systemd-nspawn container runtime is part of the systemd system software. It has been offloaded into its own package, systemd-container, a while ago. + +The prerequisite is a fully installed basic system. A standard interface of the host to the public network is assumed, via which the container receives independent access (own IP). In addition an interface for an internal, protected net between containers and host is assumed, usually a bridge. It may be a virtual network within the host, e.g. libvirts virbr0, or a physical interface connecting multiple hosts. + +But of course a container can also be operated with other variations of a network connection or even without a network connection at all. + +== 1. Setting up the nspawn container infrastructure + +1. *Create a container storage area* ++ +The systemd-nspawn tools like machinctl look for containers in `/var/lib/machines` first. This directory is also created during the installation of the programs if it does not exist. ++ +Following the Fedora server storage scheme, create a logical volume, create a file system and mount it to `/var/lib/machines`. The tools can use BTRFS properties, so this can be used as a filesystem in this case. +If you don't want to follow the Fedora Server rationale, skip this step. ++ +[source,] +---- + […]# dnf install btrfs-progs + […]# lvcreate -L 20G -n machines {VGNAME} + […]# mkfs.btrfs -L machines /dev/mapper/{VGNAME}-machines + […]# mkdir /var/lib/machines + […]# vim /etc/fstab + (insert) + /dev/mapper/{VGNAME}-machines /var/lib/machines auto 0 0 + + […]# mount -a +---- +2. *Check and, if necessary, correct the SELinux labels* ++ +Ensure that the directory belongs to root and can only be accessed by root (should be done by the installer). ++ +[source,] +---- +[…]# restorecon -vFr /var/lib/machines +[…]# chown root:root /var/lib/machines +[…]# chmod 700 /var/lib/machines +---- +3. *Adding configuration for nspawn to the `etc/systemd` directory* ++ +[source,] +---- + […]# mkdir /etc/systemd/nspawn +---- + +== 2. Creating a nspawn container + +=== 2.1 Creating a container directory tree + +The creation of a container filesystem or the provision of a corresponding image is treated as "out of scope" by systemd-nspawn. There are a number of alternative options. By far the easiest and most efficient way is simply to use the distribution specific bootstrap tool, DNF in case of fedora, in the container’s directory. This is the recommended procedure. + +1. Creating a BTRFS subvolume with the name of the container ++ +[source,] +---- + […]# cd /var/lib/machines + […]# btrfs subvolume create {ctname} +---- +2. Creating a minimal container directory tree ++ +**__Fedora 34 / 35__** ++ +[source,] +---- + […]# dnf --releasever=35 --best --setopt=install_weak_deps=False --installroot=/var/lib/machines/{CTNAME}/ \ +install dhcp-client dnf fedora-release glibc glibc-langpack-en glibc-langpack-de iputils less ncurses passwd systemd systemd-networkd systemd-resolved vim-default-editor +---- ++ +F34 installs 165 packages (247M) and allocates 557M in the file system. +F35 installs 174 packages (270M) and allocates 527M in the file system. ++ +**__Fedora 36__** ++ +[source,] +---- + […]# dnf --releasever=36 --best --setopt=install_weak_deps=False --installroot=/var/lib/machines/{CTNAME}/ \ +install dhcp-client dnf fedora-release glibc glibc-langpack-en glibc-langpack-de iputils less ncurses passwd systemd systemd-networkd systemd-resolved util-linux vim-default-editor +---- ++ +F36 installs 171 packages (247M) and allocates 550M in the file system. ++ +**__CentOS 8-stream__** ++ +First create a separate CentOS repository file (e.g. /root/centos.repo) and import CentOS keys.On this basis, perform a standard installation using DNF. ++ +[source,] +---- + […]# vim /root/centos8.repo + + [centos8-chroot-base] + name=CentOS-8-Base + baseurl=http://mirror.centos.org/centos/8/BaseOS/x86_64/os/ + gpgcheck=1 + gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial + # + [centos8-chroot-appstream] + name=CentOS-8-stream-AppStream + #baseurl=http://mirror.centos.org/$contentdir/$stream/AppStream/$basearch/os/ + baseurl=http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/ + gpgcheck=1 + gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial + # + [epel8-chroot] + name=Epel-8 + baseurl=https://ftp.halifax.rwth-aachen.de/fedora-epel/8/Everything/x86_64/ + gpgcheck=1 + gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8 + + […]# dnf install http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/centos-gpg-keys-8-2.el8.noarch.rpm + + […]# rpm -Uvh --nodeps https:/dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm + + […]# dnf -c /root/centos8.repo --releasever=8-stream --best --disablerepo=* --setopt=install_weak_deps=False --enablerepo=centos8-chroot-base --enablerepo=centos8-chroot-appstream --enablerepo=epel8-chroot --installroot=/var/lib/machines/{CTNAME} install centos-release dhcp-client dnf glibc-langpack-en glibc-langpack-de iproute iputils less passwd systemd systemd-networkd vim-enhanced + +---- ++ +This installs 165 packages that occupy 435 M in the file system. +The message: `install-info: File or directory not found for /dev/null` appears several times. The cause is that the `/dev/` file system is not yet initialized at this point. You may savely ignore the message. + +=== 2.2 Configuration and commissioning of a system container + +1. Setting the password for root ++ +This requires temporarily setting SELinux to permissive, otherwise passwd will not make any changes. ++ +[source,] +---- + […]# setenforce 0 + […]# systemd-nspawn -D /var/lib/machines/{ctname} passwd + […]# setenforce 1 +---- +2. Provision of network interfaces for the container within the host ++ +If only a connection to an internal, protected network is needed (replace the host bridge interface name accordingly): ++ +[source,] +---- + […]# vim /etc/systemd/nspawn/{ctname}.nspawn + (insert) + [Network] + Bridge=vbr6s0 +---- ++ +If a connection to the external, public network is also required, two corresponding interfaces must be provided, whereby a mac-vlan is used on the interface of the host for the external connection (again, replace the host interface names accordingly). ++ +[source,] +---- + […]# vim /etc/systemd/nspawn/{ctname}.nspawn + (insert) + [Network] + MACVLAN=enp4s0 + Bridge=vbr6s0 +---- + +3. Configuration of the connection to the internal network within the container ++ +[source,] +---- +[…]# vim /var/lib/machines/{ctname}/etc/systemd/network/20-host0.network + (insert) + # {ctname}.localnet + # internal network interface via bridge + # static configuration, no dhcp defined + [Match] + Name=host0* + + [Network] + DHCP=no + Address=10.10.10.yy/24 + #Gateway=10.10.10.10 + + LinkLocalAddressing=no + IPv6AcceptRA=no +---- ++ +If the internal network is also to be used for external access via NAT, the gateway entry must be commented in. Otherwise do not! + +4. Optionally, configure an additional connection to the public network via Mac Vlan ++ +In this case, the gateway entry _must_ be commented _out_ in the configuration of the internal network, as mentioned in item 3. ++ +[source,] +---- + […]# vim /var/lib/machinec/{ctname}/etc/systemd/network/10-mv.network + (insert) + # {ctname}.sowi.uni-bremen.de + # public interface via mac-vlan + # static configuration, no dhcp available + [Match] + Name=mv-enp* + + [Link] + ARP=True + + [Network] + DHCP=no + + # IPv4 static configuration, no DHCP configured! + Address=134.102.3.zz/27 + Gateway=134.102.3.30 + # without Destination specification + # treated as default! + #Destination= + + # IPv6 static configuration + Address=2001:638:708:f010::zzz/64 + IPv6AcceptRA=True + Gateway=2001:638:708:f010::1 + # in case of issues possible workaround + # cf https://github.com/systemd/systemd/issues/1850 + #GatewayOnlink=yes + + [IPv6AcceptRA] + UseOnLinkPrefix=False + UseAutonomousPrefix=False +---- ++ +Don't forget to adjust interface names and IP addresses accordingly! + +5. Boot the container and log in ++ +Check if container boots without error messages ++ +[source,] +---- + […]# systemd-nspawn -D /var/lib/machines/{ctname} -b + OK Spawning container {ctname} on /var/l…01. + OK … + {ctname} login: +---- +6. Checking the status of systemd-networkd ++ +If inactive, activate and start the service. ++ +[source,] +---- + […]# systemctl status systemd-networkd + … + […]# systemctl enable systemd-networkd + […]# systemctl start systemd-networkd + […]# systemctl status systemd-networkd +---- +7. Check if all network interfaces are available ++ +[source,] +---- + […]# ip a +---- +8. Check for correct routing ++ +[source,] +---- + […]# ip route show +---- +9. Configure default DNS search path ++ +Specify a search domain to appended to a unary hostname without domain part, usually the internal network domain name, e.g. example.lan. Adjust the config file according to the pattern below: ++ +[source,] +---- + […]# vim /etc/systemd/resolved.conf + + [Resolve] + ... + #dns.quad9.net + #DNS= + #FallbackDNS= + #Domains= + Domains=example.lan + #DNSSEC=no + ... +---- +10. Check if name resolution is configured correctly ++ +[source,] +---- + […]# ls -al /etc/resolv.conf + lrwxrwxrwx. 1 root root 39 29. Dez 12:15 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf +---- ++ +If the file is missing or is a text file, correct it. ++ +[source,] +---- + […]# cd /etc + […]# rm -f resolv.conf + […]# ln -s ../run/systemd/resolve/stub-resolv.conf resolv.conf + […]# ls -al /etc/resolv.conf + […]# cd +---- ++ +Ensure that systemd-resolved service is enabled. ++ +[source,] +---- + […]# systemctl status systemd-resolved +---- ++ +Activate the service if necessary. ++ +[source,] +---- + […]# systemctl enable systemd-resolved +---- + +11. Set the intended hostname ++ +[source,] +---- + […]# hostnamectl + […]# hostnamectl set-hostname +---- +12. Terminate the container ++ +[source,] +---- + […]# +]]] + Container terminated by signal KILL. +---- + +=== 2.2 Configuration and commissioning of an application container + +1. Setting the password for root ++ +This requires temporarily setting SELinux to permissive, otherwise passwd will not make any changes. ++ +[source,] +---- + […]# setenforce 0 + […]# systemd-nspawn -D /var/lib/machines/{ctname} passwd + […]# setenforce 1 +---- +2. Configuration of container properties ++ +Specifying private user configuration and shared network access. ++ +[source,] +---- + […]# vim /etc/systemd/nspawn/{ctname}.nspawn + (insert) + [Exec] + PrivateUsers=false + [Network] + Private=off + VirtualEthernet=false +---- +3. Boot the container and log in ++ +Check if container boots without error messages ++ +[source,] +---- + […]# systemd-nspawn -b -D /var/lib/machines/{ctname} + OK Spawning container {ctname} on /var/l…01. + OK … + {ctname} login: +---- +4. Checking the status of systemd-networkd ++ +If active, deactivate the service. ++ +[source,] +---- + […]# systemctl status systemd-networkd + … + […]# systemctl disable systemd-networkd + […]# systemctl stop systemd-networkd + […]# systemctl status systemd-networkd + […]# systemctl status systemd-resolved + … + […]# systemctl disable systemd-resolved + […]# systemctl stop systemd-resolved + […]# systemctl status systemd-resolved +---- ++ +If file /etc/resolv.conf is a link, remove it. ++ +[source,] +---- + […]# rm /etc/resolv.conf +---- ++ +Create (or edit an existing) file /etc/resolv.conf ++ +[source,] +---- + […]# vim /etc/resolv.conf + +nameserver 127.0.0.53 +options edns0 trust-ad +search +---- +5. Check if all network interfaces are available ++ +[source,] +---- + […]# ip a +---- ++ +You should see the same interfaces and IP addresses as on the host system. +6. Check if name resolution is working correctly ++ +[source,] +---- + […]# ping spiegel.de + PING spiegel.de (128.65.210.8) 56(84) bytes of data. + 64 bytes from 128.65.210.8 (128.65.210.8): icmp_seq=1 ttl=59 time=19.8 ms + ... +---- +7. Set the intended hostname ++ +[source,] +---- + […]# hostnamectl + […]# hostnamectl set-hostname +---- +8. Terminate the container ++ +[source,] +---- + […]# +]]] + Container terminated by signal KILL. +---- + +== 3. Starting the container as a system service for productive operation + +1. Booting the container using systemctl ++ +In this step, a separate UID/GID range is automatically created for the container. ++ +[source,] +---- + […]# systemctl enable systemd-nspawn@{ctname} + […]# systemctl start systemd-nspawn@{ctname} + […]# systemctl status systemd-nspawn@{ctname} +---- ++ +On first boot after installing systemd-container, a SELinux bug currently (Fedora 34/35) blocks execution. The solution is to fix the SELinux label(s). ++ +* Select the SELinux tab in Cockpit, preferably before booting the container for the first time. +* There, the AVCs are listed and solutions are offered, such as: ++ +`type=AVC msg=audit(1602592088.91:50075): avc: denied { search } for pid=35673 comm="systemd-machine" name="48865" dev="proc" ino=1070782 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=dir permissive=0` ++ +The proposed solution is roughly as follows: ++ +[source,] +---- +[…]# ausearch -c 'systemd-machine' --raw | audit2allow -M my-systemdmachine +[…]# semodule -i my-systemdmachine.pp +---- +* The operation must be repeated until no SELinux error is reported and the container starts as a service. ++ +Alternatively, the SELinux CLI tool can be used, which also suggests these solutions. + +2. Enable automatic start of the container at system startup ++ +[source,] +---- + […]# systemctl enable systemd-nspawn@{ctname} + […]# systemctl status systemd-nspawn@{ctname} +---- + +3. Log in to the container ++ +[source,] +---- + […]# setenforce 0 + […]# machinectl login {ctname} +---- ++ +When machinectl is called with parameters for the first time, an SELinux bug (Fedora 34/35) also blocks execution. The correction is done in the same way as for the container start. + +4. Completing and finalizing the container configuration ++ +Within the container, perform other designated software installations and customizations. ++ +In case of a CentOS 8-stream container, the epel repository should be installed (dnf install epel-release-latest-8) so that systemd-networkd is provided with updates. + +5. Logging off from the container ++ +After finishing all further work inside the container press ]]] ( Mac: 666) to exit the container and reactivate SELinux. ++ +[source,] +---- + […]# setenforce 1 +---- + +=== 3.1 Autostart of the container on reboot of the host + +An autostart of the container in the "enabled" state fails on Fedora 35 and older. The cause can be seen in a status query after rebooting the host, which issues an error message according to the following example: + +[source,] +---- + […]# systemctl status systemd-nspawn@CT_NAME + systemd-nspawn[802]: Failed to add interface vb-{CT_NAME} to bridge vbr6s0: No such device +---- + +This means that systemd starts the container before all required network interfaces are available. + +==== Resolution for (physical) interfaces managed by NetworkManager + +1. The service file requires an amendment (Bug #2001631). In section [Unit], for the `Wants=` and `After=` configurations, add a target `network-online.target` at the end of each line. The file must then look like this (ignore the commented out marker rows): ++ +[source,] +---- + […]# systemctl edit systemd-nspawn@ --full + ... + [Unit] + Description=Container %i + Documentation=man:systemd-nspawn(1) + Wants=modprobe@tun.service modprobe@loop.service modprobe@dm-mod.service network-online.target + ### ^^^^^^^^^^^^^^^^^^^^^ + PartOf=machines.target + Before=machines.target + After=network.target systemd-resolved.service modprobe@tun.service modprobe@loop.service modprobe@dm-mod.service network-online.target + ### ^^^^^^^^^^^^^^^^^^^^^ + RequiresMountsFor=/var/lib/machines/%i + ... +---- ++ +Important is the character "@" after `nspawn`! In the opening editor make the insertions and save them. + +2. Then execute ++ +[source,] +---- + […]# systemctl daemon-reload +---- + +At the next reboot the containers will be started automatically. + +==== Resolution for virtual interfaces managed by libvirt + +For such interfaces (usually the bridge virbr0) the addition mentioned above does not help. The container must be started by script in an extra step after Libvirt initialization is complete. For this you can use a hook that Libvirt provides. + +[source,] +---- +[…]# mkdir -p /etc/libvirt/hooks/network.d/ +[…]# vim /etc/libvirt/hooks/network.d/50-start-nspawn-container.sh +(INSERT) +#!/bin/bash +# Check defined nspawn container in /var/lib/machines and +# start every container that is enabled. +# The network-online.target in systemd-nspawn@ service file +# does not (yet) wait for libvirt managed interfaces. +# We need to start it decidely when the libvirt bridge is ready. + +# $1 : network name, eg. Default +# $2 : one of "start" | "started" | "port-created" +# $3 : always "begin" +# see https://libvirt.org/hooks.html + +set -o nounset + +network="$1" +operation="$2" +suboperation="$3" + +ctdir="/var/lib/machines/" +ctstartlog="/var/log/nspawn-ct-startup.log" + +echo " P1: $1 - P2: $2 - P3: $3 @ $(date) " +echo " " > $ctstartlog +echo "=======================================" >> $ctstartlog +echo " Begin $(date) " >> $ctstartlog +echo " P1: $1 - P2: $2 - P3: $3 " >> $ctstartlog + +if [ "$network" == "default" ]; then + if [ "$operation" == "started" ] && [ "$suboperation" == "begin" ]; then + for file in $ctdir/* ; do + echo "Checking: $file " >> $ctstartlog + echo " Filename: $(basename $file) " >> $ctstartlog + echo " Status: $(systemctl is-enabled systemd-nspawn@$(basename $file) ) " >> $ctstartlog + + if [ "$(systemctl is-enabled systemd-nspawn@$(basename $file) )" == "enabled" ]; then + echo " Starting Container $(basename $file) ... " >> $ctstartlog + systemctl start systemd-nspawn@$(basename $file) + echo "Container $(basename $file) started" >> $ctstartlog + fi + done + fi +fi + +[…]# chmod +x /etc/libvirt/hooks/network.d/50-start-nspawn-container.sh +---- +You may also use the link:{attachmentsdir}/nspawn-autostart-libvirt-hook.tgz[attached script] instead of typing. + +== 4. Troubleshooting + +=== 4.1 RPM DB problem in a CentOS 8-stream container on Fedora host + +For dnf / rpm queries the error message is displayed: +`warning: Found SQLITE rpmdb.sqlite database while attempting bdb backend: using sqlite backend` + +The cause is that Fedora's dfn, which is used for the installation, uses sqlite while CentOS/RHEL use the Berkeley (bdb) format. + +Check configuration within the running container: +[source,] +---- + […]# rpm -E "%{_db_backend}" +---- +The output must be `bdb`. Then fix it executing +[source,] +---- + […]# rpmdb --rebuilddb +---- + +=== 4.2 Error message dev-hugepages + +You will find message such as +[source,] +---- +dev-hugepages.mount: Mount process exited, code=exited, status=32/n/a +dev-hugepages.mount: Failed with result 'exit-code'. +[FAILED] Failed to mount Huge Pages File System. +See 'systemctl status dev-hugepages.mount' for details. +---- +DFN installs this by default, but it is not applicable inside a container. It is a general kernel configuration that cannot be changed by a container (at least as long as it is not configurable within namespaces). + +The messages can be safely ignored. + +=== 4.3 Package update may fail + +Some packages, e.g. the `filesystem` package, may not get updated in a container (error message "Error: Transaction failed"), see also https://bugzilla.redhat.com/show_bug.cgi?id=1548403 and https://bugzilla.redhat.com/show_bug.cgi?id=1912155. + +Workaround: Run before update: +[source,] +---- + […]# echo '%_netsharedpath /sys:/proc' > /etc/rpm/macros.netshared +---- +When an update has already been performed, execute this command and update the package again. + +As of Fedora 35, the bug should be fixed. + diff --git a/docs/modules/ROOT/pages/installation/index.adoc b/docs/modules/ROOT/pages/installation/index.adoc index 0ecba36..acbf19f 100644 --- a/docs/modules/ROOT/pages/installation/index.adoc +++ b/docs/modules/ROOT/pages/installation/index.adoc @@ -6,10 +6,6 @@ Peter Boy; Kevin Fenzi; Jan Kuparinen // :revremark: a new beginning :page-aliases: installation-an-introduction.adoc -// [sidebar] -// **** -// Author: Peter Boy (pboy) | Creation Date: 2022-11-15 | Last update: n/a | Related Fedora Version(s): // 35-37 -// **** [abstract] ____ diff --git a/docs/modules/ROOT/pages/server-communicating.adoc b/docs/modules/ROOT/pages/server-communicating.adoc index 9d24532..72e9f77 100644 --- a/docs/modules/ROOT/pages/server-communicating.adoc +++ b/docs/modules/ROOT/pages/server-communicating.adoc @@ -1,11 +1,10 @@ = Communicating and Getting Help Peter Boy; Jan Kuparinen :page-authors: {author}, {author_2} +:revnumber: All +:revdate: 2021-06-09 +// :revremark: a new beginning -[sidebar] -**** -Author: Jan Kuparinen (copperi) | Creation Date: 2021-03-09 | Last update: 2021-06-09 | Related Fedora Version(s): All -**** For general troubleshooting help related to Fedora, please refer to link:https://ask.fedoraproject.org[Ask Fedora Forum]. diff --git a/docs/modules/ROOT/pages/server-faq.adoc b/docs/modules/ROOT/pages/server-faq.adoc index 9f4bc10..fd91813 100644 --- a/docs/modules/ROOT/pages/server-faq.adoc +++ b/docs/modules/ROOT/pages/server-faq.adoc @@ -1,11 +1,10 @@ = Frequently Asked Questions (FAQ) Peter Boy; Jan Kuparinen :page-authors: {author}, {author_2} +:revnumber: All +:revdate: 2021-03-09 +// :revremark: a new beginning -[sidebar] -**** -Author: Jan Kuparinen (copperi) | Creation Date: 2021-03-09 | Last update: N/A | Related Fedora Version(s): All -**** [qanda] Can I see a built preview of this template to get a better idea about the result?:: diff --git a/docs/modules/ROOT/pages/server-on-sbc/index.adoc b/docs/modules/ROOT/pages/server-on-sbc/index.adoc index cd1ffb8..df44561 100644 --- a/docs/modules/ROOT/pages/server-on-sbc/index.adoc +++ b/docs/modules/ROOT/pages/server-on-sbc/index.adoc @@ -1,11 +1,10 @@ = Fedora Server on Single Board Computers - Raspberry Pi & Co. Fredrik Arneving; Peter Boy; Jan Kuparinen :page-authors: {author}, {author_2}, {author_3} +:revnumber: F36,F37 +:revdate: 2022-11-15 +// :revremark: a new beginning -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2022-11-XX | Last update: n/a | Related Fedora Version(s): 36,37 -**** [abstrqact] ____ diff --git a/docs/modules/ROOT/pages/services/postgresql-installation.adoc b/docs/modules/ROOT/pages/services/postgresql-installation.adoc deleted file mode 100644 index fdaca21..0000000 --- a/docs/modules/ROOT/pages/services/postgresql-installation.adoc +++ /dev/null @@ -1,188 +0,0 @@ -= System Administration – PostgreSQL Installation -Peter Boy; Jan Kuparinen -:page-authors: {author}, {author_2} -:page-aliases: pages/service-postgresql-installation.adoc - - -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2022-02-09 | Last update: 2022-11-15 | Related Fedora Version(s): 35-37 -**** - -Postgresql is the recommended database management system of Fedora. It is a key functionality that is part of the Reease criteria. - -Fedora 36 includes PostgreSQL 13, Fedora 37 PostgreSQL 14. - -== 1. Storage preparation - -In Fedora, PostgreSQL stores the databases and other runtime files in the `/var/lib/pgsql` directory. - -Following the Fedora storage concept, a dedicated file system on a logical volume, mounted at the appropriate position in the directory tree, takes over this function. - -A convenient descriptive name for both the logical volume and the file system is `pgsql`. The volume group that contains the logical volume is called `fedora_fedora` in a default installation. A suitable initial size is likely to be 50 GiB in many cases. - -In any case, the system administrator must adapt the following command sequence according to the local requirements! With a Linux LVM and Software raid, XFS can autonomously determine its optimal configuration values. With some hardware raids, intervention by the administrator can also be useful for this. -[source,] ----- - […]# vgs - […]# lvcreate -L 50G -n pgsql fedora_fedora - […]# mkfs.xfs -L pgsql /dev/mapper/fedora_fedora-pgsql - […]# mkdir /var/lib/pgsql - […]# vim /etc/fstab - (insert) - /dev/mapper/fedora_fedora-pgsql /var/lib/pgsql auto defaults 0 0 - (save & quit) - […]# mount -a - […]# df -h ----- - -== 2. Basic installation - -Just one package - postgresql-server - already provides a complete and comprehensive server at your disposal. All the many other Postgresql related packages provide additional options that are only useful or needed for specific special needs. - -The package provides the pure server functionality. Fedora additionally loads the packages _postgresql_, a CLI client program granting interactive access to the server, and __postgresql-private-libs__, containing shared libraries used by each ot those packages, as dependencies. -[source,] ----- - […]# dnf install postgresql-server - ... - ============================================================================================== - Package Architectur Version Repository Size - ============================================================================================== - Installing: - postgresql-server x86_64 14.3-2.fc37 updates 5.9 M - Installing dependencies - postgresql x86_64 14.3-2.fc37 updates 1.6 M - postgresql-private-libs x86_64 14.3-2.fc37 updates 138 k - - Transaction Summary - ============================================================================================== - Install 3 packages ----- - -The installer should have adjusted all SELinux labels in the pgsql directory already created. Check: -[source,] ----- - […]# ls -alZ /var/lib/pgsql/ - drwx------. 4 postgres postgres system_u:object_r:postgresql_db_t:s0 54 ... . - drwxr-xr-x. 45 root root system_u:object_r:var_lib_t:s0 4096 ... .. - drwx------. 2 postgres postgres system_u:object_r:postgresql_db_t:s0 ... backups - -rw-r--r--. 1 postgres postgres system_u:object_r:postgresql_db_t:s0 ... .bash_profile - drwx------. 2 postgres postgres system_u:object_r:postgresql_db_t:s0 ... data ----- - - If the installation program missed something, fix it executing -[source,] ----- - […]# restorecon -vFr /var/lib/pgsql - […]# ls -alZ /var/lib/pgsql/ ----- - - It is also a prerequisite that exclusively the user postgres has access to the directory pgsql and its subdirectories. Usually the installer takes care of it. Fix it if necessary. -[source,] ----- - […]# chown -R postgres:postgres /var/lib/pgsql - […]# chmod -R 700 /var/lib/pgsql ----- - -When all the requirements are met, perform the initialization of the database cluster. This is a prerequisite for all further activities. -[source,] ----- - […]# postgresql-setup --initdb ----- - -== 3. Configuration and initialization - -Fedora preconfigures Postgresql in a way that in any case ensures reliable and maintainable operation on the one hand and secure operation as far as possible on the other. - -=== Authentification options - -==== Administrative access - -For admin access Fedora postgresql is configured to obtain the host's operating system user name from the kernel and using it as the allowed database user name. Therefore, as soon as someone can authentiate on the host as user __postgres__, that person has administrative privileges on the postgresql server without any additional password prompt. The only one who can do that by default, is root. Root can configure additional users to be able to su to postgres. In any case, in a whatever emergency, if any then the system administrator is able to quickly access postgresql server unhindered and salvage what can still get salvaged. - -If local regulations make it necessary to replace these procedures with a dedicated authentication by postgresql itself, one of the other procedures can be configured later. In general, however, it is not advisable to make any changes. Once root is compromised, there are a lot of completely different problems to get tackled. - -==== Client user access - -In the initial configuration postgresql restricts any authentication to peer as above described or ident (i.e. asking a ident server). In most cases you need an authentication based on a kind of password, mostly still md5 despite its security issues. The details depend on the prospective clients. As a typical use case we will accept connections from the internal network to VMs, by default 192.169.122.0/24. - -The configuration is done in the file `pg_hba.conf` in the `data` subdirectory. Edit the file to match the pattern below. -[source,] ----- - […]# vim /var/lib/pgsql/data/pg_hba.conf - # TYPE DATABASE USER ADDRESS METHOD - # "local" is for Unix domain socket connections only - local all all peer - # IPv4 local connections: - host all all 127.0.0.1/32 ident - # IPv4 internal network connections: # <- modification! - host all all 192.168.122.1/24 md5 # <- modification! - # IPv6 local connections: - host all all ::1/128 ident - # Allow replication connections from localhost, by a user with the ----- -Add further entries according to the need, as far as they are already known. Additions are possible at any time later, but require a reload of the server, i.e. at least a short service interruption. - -For further details see the PostgreSQL documentation, chapter https://www.postgresql.org/docs/13/auth-methods.html[20.3. Authentication Methods] - -=== Connection options - -Now you are allowed to authenticate from machines on the internal network, but you still can't connect from the internal network to the PostgreSQL server. The default configuration restricts connection initially to the local host to avoid any security vulnerabilities in the first place. - -Connections granted are configured in ~/data/postgresql.conf. To grant access to VMs on the internal network as well as from local host, edit the file near the beginning to match the pattern below. -[source,] ----- - […]# vim /var/lib/pgsql/data/postgresql.conf - ... - #------------------------------------------------------------------------------ - # CONNECTIONS AND AUTHENTICATION - #------------------------------------------------------------------------------ - - # - Connection Settings - - - listen_addresses = 'localhost, 192.168.122.1/24' - #listen_addresses = 'localhost' # what IP address(es) to listen on; - # comma-separated list of addresses; - # defaults to 'localhost'; use '*' for all - # (change requires restart) - #port = 5432 # (change requires restart) - max_connections = 100 # (change requires restart) - ... ----- - -An entry of `listen_addresses = '*'` enables connections from any address. It is probably rather a bad idea and relies solely on authentication restrictions and, if present, a supporting firewall configuration. - -== 4. Using PostgreSQL as permanent service - -You are now ready to start the PostgreSQL server. -[source,] ----- - […]# systemctl start postgresql - […]# systemctl status postgresql ----- - -If no errors are reported, try to connect as user postgres using the psql cli client. Once connected, start commands with backslash, e.g. \? to get help or \q to quit. -[source,] ----- - […]# su - postgres - […]$ psql - psql (13.4) - Enter »help« ... - - postgres=# \dg - List of roles - Role name | attributes | member of - -----------+-------------------------------------------------------------+-------------- - postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {} - - postgres-# \q - […]$ ----- - -If everything works as expected, enable autostart of postgresql, -[source,] ----- - […]# systemctl enable postgresql ----- - -Enjoy a powerful DBMS. diff --git a/docs/modules/ROOT/pages/services/setup-postgresql.adoc b/docs/modules/ROOT/pages/services/setup-postgresql.adoc new file mode 100644 index 0000000..932355c --- /dev/null +++ b/docs/modules/ROOT/pages/services/setup-postgresql.adoc @@ -0,0 +1,189 @@ += Setting up PostgreSQL Database Server +Peter Boy +:page-authors: {author} +:revnumber: F35-F37 +:revdate: 2022-11-15 +// :revremark: a new beginning +:page-aliases: service-postgresql-installation.adoc +:page-aliases: services/postgresql-installation.adoc + +[abstract] +____ +Postgresql is the recommended database management system of Fedora. It is a key functionality that is part of the Release criteria. +____ + +Fedora 36 includes PostgreSQL 13, Fedora 37 PostgreSQL 14. + +== 1. Storage preparation + +In Fedora, PostgreSQL stores the databases and other runtime files in the `/var/lib/pgsql` directory. + +Following the Fedora storage concept, a dedicated file system on a logical volume, mounted at the appropriate position in the directory tree, takes over this function. + +A convenient descriptive name for both the logical volume and the file system is `pgsql`. The volume group that contains the logical volume is called `fedora_fedora` in a default installation. A suitable initial size is likely to be 50 GiB in many cases. + +In any case, the system administrator must adapt the following command sequence according to the local requirements! With a Linux LVM and Software raid, XFS can autonomously determine its optimal configuration values. With some hardware raids, intervention by the administrator can also be useful for this. +[source,] +---- + […]# vgs + […]# lvcreate -L 50G -n pgsql fedora_fedora + […]# mkfs.xfs -L pgsql /dev/mapper/fedora_fedora-pgsql + […]# mkdir /var/lib/pgsql + […]# vim /etc/fstab + (insert) + /dev/mapper/fedora_fedora-pgsql /var/lib/pgsql auto defaults 0 0 + (save & quit) + […]# mount -a + […]# df -h +---- + +== 2. Basic installation + +Just one package - postgresql-server - already provides a complete and comprehensive server at your disposal. All the many other Postgresql related packages provide additional options that are only useful or needed for specific special needs. + +The package provides the pure server functionality. Fedora additionally loads the packages _postgresql_, a CLI client program granting interactive access to the server, and __postgresql-private-libs__, containing shared libraries used by each ot those packages, as dependencies. +[source,] +---- + […]# dnf install postgresql-server + ... + ============================================================================================== + Package Architectur Version Repository Size + ============================================================================================== + Installing: + postgresql-server x86_64 14.3-2.fc37 updates 5.9 M + Installing dependencies + postgresql x86_64 14.3-2.fc37 updates 1.6 M + postgresql-private-libs x86_64 14.3-2.fc37 updates 138 k + + Transaction Summary + ============================================================================================== + Install 3 packages +---- + +The installer should have adjusted all SELinux labels in the pgsql directory already created. Check: +[source,] +---- + […]# ls -alZ /var/lib/pgsql/ + drwx------. 4 postgres postgres system_u:object_r:postgresql_db_t:s0 54 ... . + drwxr-xr-x. 45 root root system_u:object_r:var_lib_t:s0 4096 ... .. + drwx------. 2 postgres postgres system_u:object_r:postgresql_db_t:s0 ... backups + -rw-r--r--. 1 postgres postgres system_u:object_r:postgresql_db_t:s0 ... .bash_profile + drwx------. 2 postgres postgres system_u:object_r:postgresql_db_t:s0 ... data +---- + + If the installation program missed something, fix it executing +[source,] +---- + […]# restorecon -vFr /var/lib/pgsql + […]# ls -alZ /var/lib/pgsql/ +---- + + It is also a prerequisite that exclusively the user postgres has access to the directory pgsql and its subdirectories. Usually the installer takes care of it. Fix it if necessary. +[source,] +---- + […]# chown -R postgres:postgres /var/lib/pgsql + […]# chmod -R 700 /var/lib/pgsql +---- + +When all the requirements are met, perform the initialization of the database cluster. This is a prerequisite for all further activities. +[source,] +---- + […]# postgresql-setup --initdb +---- + +== 3. Configuration and initialization + +Fedora preconfigures Postgresql in a way that in any case ensures reliable and maintainable operation on the one hand and secure operation as far as possible on the other. + +=== Authentification options + +==== Administrative access + +For admin access Fedora postgresql is configured to obtain the host's operating system user name from the kernel and using it as the allowed database user name. Therefore, as soon as someone can authentiate on the host as user __postgres__, that person has administrative privileges on the postgresql server without any additional password prompt. The only one who can do that by default, is root. Root can configure additional users to be able to su to postgres. In any case, in a whatever emergency, if any then the system administrator is able to quickly access postgresql server unhindered and salvage what can still get salvaged. + +If local regulations make it necessary to replace these procedures with a dedicated authentication by postgresql itself, one of the other procedures can be configured later. In general, however, it is not advisable to make any changes. Once root is compromised, there are a lot of completely different problems to get tackled. + +==== Client user access + +In the initial configuration postgresql restricts any authentication to peer as above described or ident (i.e. asking a ident server). In most cases you need an authentication based on a kind of password, mostly still md5 despite its security issues. The details depend on the prospective clients. As a typical use case we will accept connections from the internal network to VMs, by default 192.169.122.0/24. + +The configuration is done in the file `pg_hba.conf` in the `data` subdirectory. Edit the file to match the pattern below. +[source,] +---- + […]# vim /var/lib/pgsql/data/pg_hba.conf + # TYPE DATABASE USER ADDRESS METHOD + # "local" is for Unix domain socket connections only + local all all peer + # IPv4 local connections: + host all all 127.0.0.1/32 ident + # IPv4 internal network connections: # <- modification! + host all all 192.168.122.1/24 md5 # <- modification! + # IPv6 local connections: + host all all ::1/128 ident + # Allow replication connections from localhost, by a user with the +---- +Add further entries according to the need, as far as they are already known. Additions are possible at any time later, but require a reload of the server, i.e. at least a short service interruption. + +For further details see the PostgreSQL documentation, chapter https://www.postgresql.org/docs/13/auth-methods.html[20.3. Authentication Methods] + +=== Connection options + +Now you are allowed to authenticate from machines on the internal network, but you still can't connect from the internal network to the PostgreSQL server. The default configuration restricts connection initially to the local host to avoid any security vulnerabilities in the first place. + +Connections granted are configured in ~/data/postgresql.conf. To grant access to VMs on the internal network as well as from local host, edit the file near the beginning to match the pattern below. +[source,] +---- + […]# vim /var/lib/pgsql/data/postgresql.conf + ... + #------------------------------------------------------------------------------ + # CONNECTIONS AND AUTHENTICATION + #------------------------------------------------------------------------------ + + # - Connection Settings - + + listen_addresses = 'localhost, 192.168.122.1/24' + #listen_addresses = 'localhost' # what IP address(es) to listen on; + # comma-separated list of addresses; + # defaults to 'localhost'; use '*' for all + # (change requires restart) + #port = 5432 # (change requires restart) + max_connections = 100 # (change requires restart) + ... +---- + +An entry of `listen_addresses = '*'` enables connections from any address. It is probably rather a bad idea and relies solely on authentication restrictions and, if present, a supporting firewall configuration. + +== 4. Using PostgreSQL as permanent service + +You are now ready to start the PostgreSQL server. +[source,] +---- + […]# systemctl start postgresql + […]# systemctl status postgresql +---- + +If no errors are reported, try to connect as user postgres using the psql cli client. Once connected, start commands with backslash, e.g. \? to get help or \q to quit. +[source,] +---- + […]# su - postgres + […]$ psql + psql (13.4) + Enter »help« ... + + postgres=# \dg + List of roles + Role name | attributes | member of + -----------+-------------------------------------------------------------+-------------- + postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {} + + postgres-# \q + […]$ +---- + +If everything works as expected, enable autostart of postgresql, +[source,] +---- + […]# systemctl enable postgresql +---- + +Enjoy a powerful DBMS. diff --git a/docs/modules/ROOT/pages/usecase-gui-addon.adoc b/docs/modules/ROOT/pages/usecase-gui-addon.adoc index 8023178..e26a239 100644 --- a/docs/modules/ROOT/pages/usecase-gui-addon.adoc +++ b/docs/modules/ROOT/pages/usecase-gui-addon.adoc @@ -1,11 +1,10 @@ = Adding a graphical interface Peter Boy; Jan Kuparinen :page-authors: {author}, {author_2} +:revnumber: F35-F36 +:revdate: 2022-03-98 +// :revremark: a new beginning -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date:2022-05-10 | Last update: 2022-03-08 | Related Fedora Release(s): 35,36 -**** Some users install Fedora Server Edition and then manually add a graphical user interface. Sometimes it is a matter of more convenient administration of a locally accessible server, sometimes it is a kind of off-label use, and desire for a server hardened runtime environment as a workstation with special requirements. diff --git a/docs/modules/ROOT/pages/virtualization/index.adoc b/docs/modules/ROOT/pages/virtualization/index.adoc index 1833f76..b871d60 100644 --- a/docs/modules/ROOT/pages/virtualization/index.adoc +++ b/docs/modules/ROOT/pages/virtualization/index.adoc @@ -1,15 +1,15 @@ = Virtualization Fredrik Arneving; Peter Boy; Jan Kuparinen :page-authors: {author}, {author_2}, {author_3} -:page-aliases: pages/virtualization-an-introduction.adoc +:revnumber: F35-F36 +:revdate: 2022-05-10 +// :revremark: a new beginning +:page-aliases: virtualization-an-introduction.adoc -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2021-03-31 | Last update: 2022-05-10 | Related Fedora Version(s): 35,36 -**** +[abstract] ____ -For more than a decade now, server hardware has been powerful enough to run not only one operating system, but many of them simultaneously. This inspired software developers to create virtualisation solutions for affordable (Intel) server architecture, as was already common on mainframes at the time. +For more than a decade now, server hardware has been powerful enough to run not only one operating system, but many of them simultaneously. This inspired software developers to create virtualisation solutions for affordable (Intel) server architecture, as was already common on mainframes at the time. ____ Virtualization means that several complete and probably different operating systems – the virtual guest machines (guest VM) – run on one and the same hardware, even if intended for a different hardware architecture (full virtualization). In any case, each guest VM uses its own kernel und operates as far as possible independently and isolated from each other and the host system. The basis is a 'hypervisor' that manages hardware resources and assigns them to the individual operating systems rsp. virtual guest machines. diff --git a/docs/modules/ROOT/pages/virtualization/installation.adoc b/docs/modules/ROOT/pages/virtualization/installation.adoc index 6b67f78..52c8f85 100644 --- a/docs/modules/ROOT/pages/virtualization/installation.adoc +++ b/docs/modules/ROOT/pages/virtualization/installation.adoc @@ -1,14 +1,12 @@ = Adding Virtualization Support Fredrik Arneving; Peter Boy; Jan Kuparinen :page-authors: {author}, {author_2}, {author_3} -:page-aliases: pages/virtualization-install.adoc +:revnumber: F34-F37 +:revdate: 2022-11-15 +// :revremark: a new beginning +:page-aliases: virtualization-install.adoc -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2021-03-31 | Last update: 2022-11-15 | Fedora Version(s) 34-37 -**** - [abstract] ____ Qemu-kvm in combination with Libvirt management toolkit is the standard virtualization methodology in Fedora. This optionally includes a local virtual network that you may use for protected communication between the virtual guest systems with each other and with the host. Its default configuration enables also natted access to the public network, specifically usful for virtual machines or containers without its own direct access to the public interface. diff --git a/docs/modules/ROOT/pages/virtualization/vm-install-cloudimg-centos9.adoc b/docs/modules/ROOT/pages/virtualization/vm-install-cloudimg-centos9.adoc index 313d25e..f9bf6d6 100644 --- a/docs/modules/ROOT/pages/virtualization/vm-install-cloudimg-centos9.adoc +++ b/docs/modules/ROOT/pages/virtualization/vm-install-cloudimg-centos9.adoc @@ -1,14 +1,13 @@ = Creating a virtual machine using a distribution’s Cloud base image – the example of CentOS Peter Boy; Jan Kuparinen; :page-authors: {author}, {author_2} -:page-aliases: pages/virtualization-vm-install-cloudimg-centoos9.adoc +:revnumber: F34-F36 +:revdate: 2022-05-10 +// :revremark: a new beginning +:page-aliases: virtualization-vm-install-cloudimg-centoos9.adoc +:page-aliases: virtualization-vm-install-cloudimg-centos9.adoc -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2022-05-10 | Last update: N/A | Related Fedora Version(s): 34-36 -**** - [abstract] ____ The objective here is to create a virtual machine based on any distribution. But instead of going through the distribution-specific installer, a cloud image is to be used. This reduces the installation process to copying a disk image with subsequent initial adaptation to the concrete runtime environment. The workload shrinks to a few minutes. diff --git a/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-fedoraserver.adoc b/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-fedoraserver.adoc index 5c2cc2c..e7a166f 100644 --- a/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-fedoraserver.adoc +++ b/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-fedoraserver.adoc @@ -1,14 +1,13 @@ = Creating a virtual machine using Fedora Server Edition disk image Peter Boy :page-authors: {author} +:revnumber: F37 +:revdate: 2022-11-15 +// :revremark: a new beginning :page-aliases: pages/virtualization-vm-install-diskimg-fedoraserver.adoc -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2022-11-15 | Last update: N/A | Related Fedora Version(s): 37 -**** - +[abstract] ____ Installation of Fedora Server Edition in a virtual machine is a supported way for a long time by using the standard installation program in a Virtual Machine. Another option is to download a prebuild Fedora Server Edition virtual disk image and mount that in a virtual machine. The former can be quite flexibly adapted to a specific, individual requirement. The latter entails a default installation, but requires much less time and effort. It is the scope of this guidance. ____ diff --git a/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-virtbuilder.adoc b/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-virtbuilder.adoc index ebb4e62..a608267 100644 --- a/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-virtbuilder.adoc +++ b/docs/modules/ROOT/pages/virtualization/vm-install-diskimg-virtbuilder.adoc @@ -1,14 +1,13 @@ = Creating a virtual machine using a generic disk image – the example of virt-builder Peter Boy :page-authors: {author} -:page-aliases: pages/virtualization-vm-install-diskimg-virtbuilder.adoc +:revnumber: F35-F36 +:revdate: 2022-05-10 +// :revremark: a new beginning +:page-aliases: virtualization-vm-install-diskimg-virtbuilder.adoc -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2022-04-14 | Last update: 2022-05-10 | Related Fedora Version(s): 35,36 -**** - +[abstract] ____ Many people and professional journals describe virt-builder as a way to "__quickly build virtual machine images__". __This is simply wrong__. Instead, the program picks up an already _existing machine image_, referred to as a "template", and _customizes_ it according to the parameters that the system administrator has specified. The virt-builder program does literally build nothing at all. The differentiation may be subtle. But those phrases distract from the fact that the entire process depends entirely on a large binary blob. And for a system built and trusted on free software, the question of how that blob is created deserves attention. diff --git a/docs/modules/ROOT/pages/virtualization/vm-install-fedoraserver-cockpit.adoc b/docs/modules/ROOT/pages/virtualization/vm-install-fedoraserver-cockpit.adoc index 9ca03de..8d98fbf 100644 --- a/docs/modules/ROOT/pages/virtualization/vm-install-fedoraserver-cockpit.adoc +++ b/docs/modules/ROOT/pages/virtualization/vm-install-fedoraserver-cockpit.adoc @@ -1,19 +1,18 @@ = Installing the Fedora Server Edition as a virtual machine using Cockpit Peter Boy; Jan Kuparinen :page-authors: {author}, {author_2} -:page-aliases: pages/virtualization-vm-install-fedoraserver-cockpit.adoc +:revnumber: F34-F36 +:revdate: 2022-05-10 +// :revremark: a new beginning +:page-aliases: virtualization-vm-install-fedoraserver-cockpit.adoc -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2022-03-18 | Last update: 2022-05-10 | Related Fedora Version(s): 34-36 -**** - +[abstract] ____ The objective here is to install a Fedora Server in a virtual machine using the deployed generic installation media. An underlying assumption is that the processor architecture is the same as that of the host. The other case is also possible, but requires additional configuration. +____ The descriptions can also be used as a blueprint for installing other distributions with the respective distribution’s own installation media. -____ == Why Cockpit diff --git a/docs/modules/ROOT/pages/virtualization/vm-management-cockpit.adoc b/docs/modules/ROOT/pages/virtualization/vm-management-cockpit.adoc index 57721c1..42e7530 100644 --- a/docs/modules/ROOT/pages/virtualization/vm-management-cockpit.adoc +++ b/docs/modules/ROOT/pages/virtualization/vm-management-cockpit.adoc @@ -1,14 +1,12 @@ = Managing virtual machines with Cockpit -Peter Boy; Jan Kuparinen; -:page-authors: {author}, {author_2} -:page-aliases: pages/virtualization-vm-management-cockpit.adoc +Peter Boy +:page-authors: {author} +:revnumber: F35-F36 +:revdate: 2022-05-10 +// :revremark: a new beginning +:page-aliases: virtualization-vm-management-cockpit.adoc -[sidebar] -**** -Author: Peter Boy (pboy) | Creation Date: 2022-04-17 | Last update: 2022-05-10 | Related Fedora Version(s): 35.36 -**** - [abstract] ____ A virtual machine is created under certain assumptions about required memory, data storage, processing capacity, and so on. All too often, these assumptions need to be adjusted based on actual use practices, and require additional configuration work by a system administrator. Cockpit greatly simplifies and facilitates this work, especially for the Fedora Server Edition, that do not include a graphical interface.