Fixed typos and various refs.

Reviewed-on: server/user-documentation#223

.forgejo/workflows/antora.yml

@@ -0,0 +1,14 @@
+on: [push]
+
+jobs:
+  antora:
+    runs-on:
+      - podman
+    container:
+      image: docker.io/antora/antora
+    steps:
+      - run: apk add --no-cache git
+
+      - uses: actions/checkout@v6
+
+      - run: antora --html-url-extension-style=indexify site.yml

.forgejo/workflows/vale.yml

@@ -0,0 +1,12 @@
+on: [push]
+
+jobs:
+  vale:
+    runs-on:
+      - podman
+    container:
+      image: docker.io/jdkato/vale
+    steps:
+      - uses: actions/checkout@v7
+      - run: vale sync
+      - run: vale README.md modules/ROOT/pages/ modules/ROOT/partials/

.gitignore

@@ -2,3 +2,10 @@ build
 cache
 public
 preview.pid
+.DS_Store
+*.bak
+*~
+*swp
+
+# vale
+.vale/styles/RedHat/

.vale.ini

@@ -0,0 +1,45 @@
+StylesPath = .vale/styles
+MinAlertLevel = suggestion
+Packages = RedHat
+Vocab = FedoraServer
+
+[*]
+# BasedOnStyles = RedHat
+FedoraServer.Headings = YES
+RedHat.Abbreviations = YES
+# RedHat.CaseSensitiveTerms = YES
+# RedHat.Conjunctions = YES
+# RedHat.ConsciousLanguage = YES
+RedHat.Contractions = YES
+# RedHat.Definitions = YES
+# RedHat.DoNotUseTerms = YES
+# RedHat.Ellipses = YES
+# RedHat.EmDash = YES
+# RedHat.GitLinks = YES
+# RedHat.HeadingPunctuation = YES
+# RedHat.Headings = YES
+# RedHat.Hyphens = YES
+RedHat.MergeConflictMarkers = YES
+# RedHat.NoGerundsInTitles = YES
+# RedHat.ObviousTerms = YES
+RedHat.OxfordComma = YES
+# RedHat.PascalCamelCase = YES
+# RedHat.PassiveVoice = YES
+# RedHat.ProductCentricWriting = YES
+# RedHat.ReadabilityGrade = YES
+# RedHat.ReleaseNotes = YES
+RedHat.RepeatedWords = YES
+# RedHat.SelfReferentialText = YES
+# RedHat.SentenceLength = YES
+RedHat.SessionId = YES
+# RedHat.SimpleWords = YES
+# RedHat.Slash = YES
+RedHat.SmartQuotes = YES
+RedHat.Spacing = YES
+RedHat.Spelling = YES
+# RedHat.Symbols = YES
+# RedHat.TermsErrors = YES
+# RedHat.TermsSuggestions = YES
+# RedHat.TermsWarnings = YES
+# RedHat.UserReplacedValues = YES
+# RedHat.Using = YES

.vale/styles/FedoraServer/Headings.yml

@@ -0,0 +1,99 @@
+# Based on RedHat.Headings
+extends: capitalization
+level: error
+link: https://redhat-documentation.github.io/vale-at-red-hat/reference-guide.html#headings
+match: $sentence
+message: "Use sentence-style capitalization in '%s'."
+scope: heading
+indicators:
+  - ":"
+exceptions:
+  - ARP
+  - Avahi
+  - BIOS
+  - CA
+  - CMS
+  - Cockpit
+  - CPU
+  - CVE
+  - DHCP
+  - DNF
+  - DNS
+  - dnsmasq
+  - ECDSA
+  - Ed25519
+  - EFI
+  - /etc/ssh
+  - /etc/systemd/nspawn
+  - FAQ
+  - Fedora
+  - Fedora Cloud Edition
+  - Fedora Server
+  - Fedora Server Documentation
+  - Fedora Server Edition
+  - Fedora Server Edition User Documentation
+  - FQDN
+  - FTP
+  - GNU
+  - GPT
+  - GSSAPI
+  - ImageFactory
+  - Kea
+  - Kickstart
+  - L
+  - Legacy BIOS
+  - Linux
+  - Linux-Vserver
+  - LVM
+  - LXC
+  - LXD
+  - MAC
+  - machinectl
+  - MacOS
+  - MBR
+  - mDNS
+  - NAT
+  - NFS
+  - NFSv3
+  - NFSv4
+  - NTP
+  - OpenSSH
+  - OpenVZ
+  - OS
+  - PKCS#11
+  - Podman
+  - POP
+  - Proxmox
+  - Proxmov Virtual Environment
+  - PV
+  - PXE
+  - RAID
+  - Raspberry Pi
+  - rcp
+  - rlogin
+  - rsh
+  - rsync
+  - scp
+  - Secure Boot
+  - sftp
+  - Solaris
+  - SSH
+  - ssh-agent
+  - ssh-copy-id
+  - sshd
+  - ssh-keygen
+  - systemd-nspawn
+  - Telnet
+  - UEFI
+  - UEFI HTTP
+  - URL
+  - UUID
+  - /var/lib/machines
+  - /var/lib/tftpboot
+  - VG
+  - VM
+  - VMs
+  - WordPress
+  - X
+  - X11
+  - Xen

.vale/styles/config/vocabularies/FedoraServer/accept.txt

@@ -0,0 +1,65 @@
+
+arabic
+bantime
+biosboot
+bootloader
+bootloaders
+chmod
+chown
+cockpit-machines
+Deepin
+diskimg
+EFF
+efi
+example.lan
+fedoraserver
+finalbootform
+homelab
+homelabs
+hostmin
+hostnamectl
+installationdestination
+Jamstack
+libnfsidmap
+libvirt
+libvirtform
+libvirtlist
+Logwatch
+LXC
+LXD
+Mindshare
+mkdir
+mv
+nat
+Netinstall
+NoCloud
+Proxmox
+QEMU
+rlogin
+rootfsform
+rootfslist
+sda
+sdb
+srvform
+srvlist
+SSHFS
+subprojects
+Sun Microsystems
+sysefi
+sysgvlist
+syspv
+syspvlist
+sysvg
+sysvgform
+uefilist
+usrhomeform
+usrhomelist
+usrpv
+usrvg
+usrvglist
+varlogform
+varloglist
+vda
+WordPress
+Xen
+Xfce

README.md

@@ -8,12 +8,14 @@ Steps to do to contribute to the documentation:
 
 Fork this repository, so you are not pushing updates directly into the main branch.
 
-Start adding the actual ASCIIDoc content. While writing, make sure your new source files are included in the nav.adoc configuration file of the module you are using (./modules/ROOT/ ). 
+Start adding the actual AsciiDoc content. While writing, make sure your new source files are included in the nav.adoc configuration file of the module you are using (./modules/ROOT/ ). 
 Also make sure to use local preview often to check your markup.
 
+Please see our [Style Guidelines](STYLE.md) to help guide your content.
+
 Once you finish, commit your changes and push them to your fork.
 
-Use forge to make a pull request from your fork to the repository’s main branch.
+Use forge to make a pull request from your fork to the repository's main branch.
 
 Someone will see your pull request and either merge it, or provide feedback if there is something you should change. Work with the people commenting to make sure your contributions are up to standards.
 
@@ -58,22 +60,22 @@ Someone will see your pull request and either merge it, or provide feedback if t
 ```
 1. Metadata definition.
 2. A script that does a local build. It shows a preview of the site in a web browser on localhost:8080 by running a local web server. Uses podman/docker.
-3. Licence information for the documentation.
+3. License information for the documentation.
 4. Configuration for the local web server mentioned above.
 5. A definition file for the build script.
 6. A "root module of this documentation component". Please read below for an explanation.
 7. Directory containing **attachments** to be used on any page.
-8. Directory containing **Iiages** to be used on any page.
+8. Directory containing **images** to be used on any page.
 9. **Menu definition.** Also defines the hierarchy of all the pages.
-10. **Pages with the actual content.** They are organised into subdirectories for specific area of information.
-11. Snippets of adoc files reusable in various documentations, organised into subdirectories for specific area of information.
+10. **Pages with the actual content.** They are organized into subdirectories for specific area of information.
+11. Snippets of adoc files reusable in various documentations, organized into subdirectories for specific area of information.
 
-## Components and Modules
+## Components and modules
 
 Antora introduces two new terms:
 
-* **Component** — Simply put, a component is a part of the documentation website with its own menu. Components can also be versioned. In the Fedora Docs, we use separate components for user documentation, the Fedora Project, Fedora council, Mindshare, FESCO, but also for subprojects such as CommOps or Modulartity.
-* **Module** — A component can be broken down into multiple modules. Modules still share a single menu on the site, but their sources can be stored in different git repositories, even owned by different groups. The default module is called "ROOT" (that's what is in this example). If you don't want to use multiple modules, only use "ROOT". But to define more modules, simply duplicate the "ROOT" directory and name it anything you want. You can store modules in one or more git repositories.
+* **Component**  - Simply put, a component is a part of the documentation website with its own menu. Components can also be versioned. In the Fedora Docs, we use separate components for user documentation, the Fedora Project, Fedora council, Mindshare, FESCO, but also for subprojects such as CommOps or Modularity.
+* **Module**  - A component can be broken down into multiple modules. Modules still share a single menu on the site, but their sources can be stored in different git repositories, even owned by different groups. The default module is called "ROOT" (that is what is in this example). If you do not want to use multiple modules, only use "ROOT". But to define more modules, simply duplicate the "ROOT" directory and name it anything you want. You can store modules in one or more git repositories.
 
 ## Local preview
 
@@ -93,7 +95,7 @@ The result will be available at http://localhost:8080
 
 ### Installing Podman on Fedora
 
-Newer Fedora Workstations comes with Podman preinstalled by default — if you do not have it, you need to install it using the following command:
+Newer Fedora Workstations come with Podman preinstalled by default  - if you do not have it, you need to install it using the following command:
 
 ```
 $ sudo dnf install podman
@@ -134,9 +136,9 @@ And replaced it with a pointer to my fork:
 ...
 ```
 
-I could also point to a local repository, using `HEAD` as a branch to preview the what's changed without the need of making a commit.
+I could also point to a local repository, using `HEAD` as a branch to preview what is changed without the need of making a commit.
 
-**Note:** I would need to move the repository under the `docs-fp-o` directory, because the builder won't see anything above.
+**Note:** I would need to move the repository under the `docs-fp-o` directory, because the builder will not see anything above.
 So I would need to create a `repositories` directory in `docs-fp-o` and copy my repository into it.
 
 ```

STYLE.md

@@ -0,0 +1,81 @@
+# Documentation style guidelines
+
+Fedora Server documentation follows the style guidelines defined at https://docs.fedoraproject.org/en-US/fedora-docs/contributing-docs/style-guide/
+
+Additionally the following general style decisions have been agreed for Fedora Server documentation:
+
+## File edit instructions
+
+In general, avoid mentioning the editor or including the editor in a codeblock. Describe the filepath in the text preceding the file content and then
+include the file content in a codeblock. For example:
+
+``` 
+ Create or edit the file at /path/to/file using your preferred editor running under sudo to obtain elevated privileges. The file content should match:
+ [source,ini]
+ ----
+ [main]
+ key=<value>
+ ----
+```
+
+Use of HEREDOC is permitted, but is only preferred for very small file creation actions. We want to encourage users to actually review the content that they enter into an editor when creating and editing files. An example of a small HEREDOC file creation might be:
+
+```
+[source,console]
+----
+$ sudo tee /etc/sysctl.d/50-enable-forwarding.conf << 'EOF'
+net.ipv4.ip_forward=1
+net.ipv6.conf.all.forwarding=1
+EOF
+----
+```
+
+TIP: By quoting the 'EOF' in the command, you can avoid bash variable expansion if the file contains variable strings. Read more on HEREDOC at [The Linux Documentation Project](https://tldp.org/LDP/abs/html/here-docs.html).
+
+## Codeblocks and command syntax
+
+When commands, filepaths or functions are referenced in inline text, enclose them within backticks (`). For example:
+
+```
+ Run the `echo` command and pipe to `tee` using `sudo` to output to `/etc/config.ini`.
+```  
+
+Codeblock class directives for shell interactions should use the `[source,console]` classes. This helps to handle the exclusion of the shell prompt in a copy action, and provides some shell syntax highlighting. 
+
+Although Asciidoc supports a variety of codeblock delimiters, we always use `----` to indicate the start and the end of a block.
+
+For variable substitution use `<variable_name>` in the codeblock and then preferably call out the variable in surrounding text to explain what it should be substituted with.
+
+In addition to the standard style instruction to use a shell prompt ($ or #) to indicate privilege level and set the input apart from output. We prefer that commands are generally run with user privileges and
+ sudo to obtain root privileges where required. The majority of your shell commands should be preceded with a $, unless there is a significant reason that something explicitly runs as root. For example:
+
+
+``` 
+ [source,console]
+ ----
+ $ sudo some_command --opt <my_var>  
+ Output from some_command run with root privileges, if valuable to show.
+ $ some_command
+ Output from some_command run as a standard user, if valuable to show.
+ # some_command 
+ Output from some_command run as root - avoid doing this, if possible.
+ ----
+```
+
+It is worth noting that simply putting sudo in front of a command that was previously run as root might not give the behavior you expected, particularly if the command included pipes or redirects. For example:
+
+```
+# echo 1 > /proc/sys/net/ipv4/ip_forward
+```
+ 
+is *not* the same as:
+
+```
+$ sudo echo 1 > /proc/sys/net/ipv4/ip_forward
+```
+
+The redirect will run as the standard user and only the echo will run under sudo. Instead, run the echo as the standard user and pipe the output to tee running under sudo:
+
+```
+$ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
+```

makefile

@@ -0,0 +1,8 @@
+VALE ?= ./scripts/vale.sh
+
+.PHONY: all vale
+
+all:
+
+vale:
+	$(VALE) modules/ROOT/pages modules/ROOT/partials README.md

modules/ROOT/assets/attachments/tutorials/imagefactory/fedora-server-kvm-dev.ks

@@ -1,201 +0,0 @@
-# fedora-server-vm-full.ks (rel. 1.02)
-# Kickstart file to build a Fedora Server Edition VM disk image.
-# The image aims to resemble as close as technically possible the
-# full features of a Fedora Server Edition in a virtual machine.
-#
-# The image uses GPT partition type as of default in Fedora 39.
-#
-# At first boot it opens a text mode basic configuration screen.
-#
-# This kickstart file is designed to be used with ImageFactory (in Koji).
-#
-# To build the image locally, you need to install ImageFactory and
-# various additional helpers and configuration files.
-# See Fedora Server Edition user documentation tutorial.
-
-# Use text mode install
-text
-
-# Keyboard layouts
-keyboard 'us'
-
-# System language
-lang en_US.UTF-8
-
-# System timezone
-# set time zone to GMT (Etcetera/UTC)
-timezone Etc/UTC --utc
-
-
-# Root password
-rootpw --iscrypted --lock locked
-
-# SELinux configuration
-selinux --enforcing
-
-
-# System bootloader configuration
-bootloader --location=mbr --timeout=1 --append="console=tty1 console=ttyS0,115200n8"
-
-# Network information
-network  --bootproto=dhcp --device=link --activate --onboot=on
-
-# Firewall configuration
-firewall --enabled --service=mdns
-
-
-# System services
-services --enabled="sshd,NetworkManager,chronyd,initial-setup"
-
-# Run the Setup Agent on first boot
-firstboot --reconfig
-
-# Partition Information. Use GPT by default (since Fedora 37)
-# Resemble the Partitioning used for Fedora Server Install media
-clearpart --all --initlabel --disklabel=gpt
-reqpart --add-boot
-part pv.007     --size=4000  --grow
-volgroup  sysvg  pv.007
-logvol / --vgname=sysvg --size=4000 --grow --maxsize=16000 --fstype=xfs --name=root --label=sysroot
-
-
-# Include URLs for network installation dynamically, dependent on Fedora release
-# and imagefactory runtime environment
-%include fedora-repo.ks
-
-# Shutdown after installation
-shutdown
-
-
-
-##### begin package list #############################################
-%packages --inst-langs=en
-
-@server-product
-@core
-@headless-management
-@standard
-@networkmanager-submodules
-# container management is an optional install item on disk media.
-# Install options not available with VMs. So we don't include it
-# despite trying to resemble a DVD installation as close as possible.
-##@container-management
-@domain-client
-@guest-agents
-
-# All arm-tools packages install on aarch64/armhfp only
-# TODO: on a x86_64 devel environment are @arm-tools not available
-# and cause a build error.
-# @arm-tools
-
-# Standard Fedora Package Groups
-## dracut-config-generic  ## included in =core=
-glibc-all-langpacks
-initial-setup
-kernel-core
--dracut-config-rescue
--generic-release*
--initial-setup-gui
--kernel
--linux-firmware
--plymouth
-# pulled in by @standard
--smartmontools
--smartmontools-selinux
-
-%end
-##### end package list ###############################################
-
-
-##### begin kickstart post script ####################################
-%post --erroronfail  --log=/root/anaconda-post-1.log
-
-# Find the architecture we are on
-arch=$(uname -m)
-
-# Import RPM GPG key, during installation saved in /etc/pki
-echo "Import RPM GPG key"
-releasever=$(rpm --eval '%{fedora}')
-basearch=$(uname -i)
-rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
-
-# See the systemd-random-seed.service man page that says:
-#   " It is recommended to remove the random seed from OS images intended
-#     for replication on multiple systems"
-# The newly installed instance should make it's own
-echo "Removing random-seed so it's not the same in every image."
-rm -f /var/lib/systemd/random-seed
-
-# When we build the image a networking config file gets left behind.
-# Let's clean it up.
-echo "Cleanup leftover networking configuration"
-rm -f /etc/NetworkManager/system-connections/*.nmconnection
-
-# Truncate the /etc/resolv.conf left over from NetworkManager during the
-# kickstart because the DNS server is environment specific.
-truncate -s 0 /etc/resolv.conf
-
-echo "Cleaning repodata to save space."
-dnf clean all
-
-# linux-firmware is installed by default and is quite large. As of mid 2020:
-#   Total download size: 97 M
-#   Installed size: 268 M
-# Not needed in virtual environment.
-echo "Removing linux-firmware package."
-rpm -e linux-firmware
-
-# Will ever anybody see this?
-echo "Packages within this disk image"
-rpm -qa --qf '%{size}\t%{name}-%{version}-%{release}.%{arch}\n' |sort -rn
-
-# Note that running rpm recreates the rpm db files which aren't needed or wanted
-rm -f /var/lib/rpm/__db*
-
-
-# Do we need a serial terminal with a VM?
-if [[ $arch == "aarch64" ]] || [[ $arch == "armv7l" ]]; then
- # Anaconda adds console=tty0 to the grub boot line on all images. this is problematic
- # when you are using fedora via serial console as you do not get any output post grub
- # linux does a good job of knowing what consoles need to be enabled.
- # https://bugzilla.redhat.com/show_bug.cgi?id=2022757
- sed -i -e 's|console=tty0||g' /boot/loader/entries/*conf
-fi
-
-
-# Remove machine-id on pre generated images
-rm -f /etc/machine-id
-touch /etc/machine-id
-
-%end
-##### end kickstart post script #####################################
-
-
-##### begin custom post script (after base) #########################
-%post
-
-# When we build the image /var/log gets populated.
-# Let's clean it up.
-echo "Cleanup leftover in /var/log"
-cd /var/log  && find . -name \* -type f -delete 
-
-echo "Zeroing out empty space."
-# Create zeros file with nodatacow and no compression
-touch /var/tmp/zeros
-chattr +C /var/tmp/zeros
-# This forces the filesystem to reclaim space from deleted files
-dd bs=1M if=/dev/zero of=/var/tmp/zeros || :
-echo "(Don't worry -- that out-of-space error was expected.)"
-# Force sync to disk
-sync /
-rm -f /var/tmp/zeros
-sync /
-
-# setup systemd to boot to the right runlevel
-echo -n "Setting default runlevel to multiuser text mode"
-rm -f /etc/systemd/system/default.target
-ln -s /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
-echo .
-
-%end
-##### end custom post script ########################################

modules/ROOT/assets/attachments/tutorials/imagefactory/fedora-server-kvm-dev.tdl

@@ -1,16 +0,0 @@
-<template>
-    <name>fedora-server-kvm-dev</name>
-    <os>
-        <name>Fedora</name>
-        <version>22</version>
-        <arch>x86_64</arch>
-        <install type='url'>
-          <url>https://kojipkgs.fedoraproject.org/compose/branched/Fedora-39-20231001.n.0/compose/Everything/x86_64/os</url>
-        </install>
-    </os>
-    <description>Fedora-server-kvm-dev</description>
-    <disk>
-      <size>7G</size>
-    </disk>
-</template>
-

modules/ROOT/nav.adoc

@@ -2,12 +2,19 @@
 ** xref:installation/interactive-local.adoc[Interactive local installation]
 ** xref:installation/interactive-remote.adoc[Interactive remote installation]
 ** xref:installation/sw-raid-upon-installation.adoc[Exkurs: Configuring a software RAID upon interactive installation]
-** xref:installation/postinstallation-tasks.adoc[Post Installation Tasks]
+
+* xref:postinstallation/index.adoc[Postinstallation Customizations]
 
 * xref:administration/index.adoc[Basic Administration] 
 ** xref:administration/dnsmasq.adoc[Setting up dnsmasq – a lightweight DHCP and DNS server]
+** xref:administration/virtual-bridge.adoc[Setting Up a Virtual Bridge]
 ** xref:administration/virtual-routing-bridge.adoc[Setting Up a Virtual Routing Bridge (brouter)]
 ** xref:administration/point-to-point-connection.adoc[Setting Up a Point-to-Point Network] 
+** Remote Access Using OpenSSH
+*** xref:administration/ssh-about.adoc[About SSH and OpenSSH]
+*** xref:administration/ssh-server.adoc[OpenSSH Server Configuration]
+*** xref:administration/ssh-client.adoc[OpenSSH Client Configuration]
+*** xref:administration/ssh-advanced-usage.adoc[Advanced SSH Usage]
 
 * xref:virtualization/index.adoc[Virtualization]
 ** xref:virtualization/installation.adoc[Adding Virtualization Support]
@@ -22,17 +29,16 @@
 * xref:containerization/index.adoc[Containerization]
 ** xref:containerization/systemd-nspawn-setup.adoc[Setting up Systemd Nspawn Container]
 
-* Providing services
+* Services
 ** xref:services/postgresql-setup.adoc[Setting up PostgreSQL Database Server]
+** xref:services/fedsysadmins-cheatsheet-postgresql.adoc[Fedora Server System Administrator's Cheat Sheet: PostgreSQL]
 ** xref:services/httpd-basic-setup.adoc[Setting up a basic web server]
 ** xref:services/filesharing-nfs-installation.adoc[File sharing with NFS – Installation]
+** xref:services/mdns.adoc[Local domains with mDNS]
 
-* Example Use Cases
-** xref:usecase-gui-addon.adoc[Adding a graphical user interface]
-
-* Tutorials
-** xref:tutorials/imagefactory.adoc[ImageFactory - How to create a virtual machine disk image]
-** xref:tutorials/wordpress-installation.adoc[Installing Wordpress CMS]
+* Use Cases
+** xref:usecases/wordpress-installation.adoc[Installing Wordpress CMS]
+** xref:usecases/gui-addon.adoc[Adding a graphical user interface]
 
 * xref:server-on-sbc/index.adoc[Special: Fedora Server on ARM Single Board Computers - the Raspberry Pi & Co]
 ** xref:server-on-sbc/uboot-installation.adoc[Installation based on u-boot]

modules/ROOT/pages/administration/dnsmasq.adoc

@@ -1,240 +1,323 @@
-= Setting up dnsmasq - a lightweight DHCP and DNS server
-Peter Boy; Emmmanuel Seyman
-:page-authors: {author}, {author_2}
-:revnumber: F35-F36
-:revdate: 2022-09-23
-// :revremark: a new beginning
+= Setting up dnsmasq - a lightweight DHCP
+Peter Boy; Emmanuel Seyman; Jan Kuparinen; Rowan Puttergill
+:revnumber: F35-F44
+:page-authors: {author}, {author_2}, {author_3}, {author_4}
+:revdate: 2026-07-01
 :page-aliases: sysadmin-dnsmasq.adoc
 
 
 [abstract]
-____
-Fedora Server Edition recommends the lightweight dnsmasq program to provide DHCP, DDNS and DNS caching service for a server and a small to medium-sized local network. It works as a NetworkManager plugin to ensure a seamless interlocking of the components. It is the preconfigured default configuration and specifically supported.
-____
+Fedora Server recommends using the lightweight dnsmasq program to provide a server and a small to medium-sized local network with DHCP, DDNS and DNS caching services. Fedora Server has already preconfigured it as a NetworkManager plugin to ensure seamless integration of the components. 
+//[NOTE]
+//====
+//**Status:** checked and ready for final review (2026-05-11)
+//====
 
 == Introduction
-A typical usage of dnsmasq is to provide a DHCP service for a private network.  It is optionally supplemented by dynamic DNS, whereby a DHCP assigned IP address gets a temporary DNS entry with the hostname of the device. Additionally, it supports static hostnames, too. Another typical use case is to provide DHCP for a public subdomain, while an official public DNS server still provides the subdomain's name resolution. Of course, devices with such an address cannot be found via DNS. They are primarily used for the initial system installation, for network-supported booting (PXE), or dynamically assigning machines, identified by their MAC address, a specific IP address. And sometimes dnsmasq is used as a caching DNS proxy without any DHCP or DDNS functionality. But since release 33, Fedora uses systemd-resolved as DNS client which includes a versatile caching. Thus, dnsmasq is no longer needed for this use case.
+By default, Fedora Server uses dnsmasq to provide local DNS and DHCP services for private or public subnets. It is preconfigured as a NetworkManager plug-in to ensure seamless integration of the components.
 
-The dnsmasq DHCP and DNS is the default and recommend way to provide these services in Fedora Server Edition. Each of the components is optional. A system can use only the DHCP part without DNS, or only DNS without DHCP, or only DHCP caching, or any combination. Each component is configured separately. It is preconfigured as a NetworkManager plugin to ensure a seamless interlocking of the components.
+The DHCP component provides dynamic DNS for a DHCP-assigned IP address, offering a temporary DNS entry for the device's hostname. It also supports static hostnames. Another common use case is to provide DHCP for a public subdomain, while an official public DNS server provides name resolution for the subdomain. Devices with such an address cannot, of course, be found via DNS. These addresses are primarily used for initial system installation, network-supported booting (PXE), and for dynamically assigning a specific IP address to machines identified by their MAC address. Another capability is providing a DNS caching service. However, since release 33, Fedora has used systemd-resolved as the DNS client, which includes versatile caching. Therefore, dnsmasq is no longer required for this purpose.
 
-The target is a small to middle-sized subnet. Usually, a server performs this task as a “side job” so to speak, and the main tasks involve other services.
+Dnsmasq can also provide a TFTP service that can be used to support PXE boot environments, most often used for remote system installation across a network.
 
-A general determination of the upper limit is practically impossible.  But as a rule of thumb, dnsmasq can easily handle 100 or more machines. Significantly larger networks primarily require better management and structuring capabilities. The __ISC DHCP Server__ would then be a more suitable choice.
+Each dnsmasq component is optional. A system can use the DHCP component alone, the DNS component alone, the DHCP caching component alone, or any combination of these. Each component is configured separately.
+
+The target is a small to medium-sized subnet. Typically, a server performs this task as an additional responsibility, alongside its main duties. It is practically impossible to determine the upper limit with any degree of accuracy. However, as a rule of thumb, dnsmasq can handle over 100 machines with ease. Significantly larger networks require better management and structuring capabilities. In this case, Kea, the ISC DHCP Server would be a more suitable choice.
+
+For additional information, see the _Fedora Magazine_ article  https://fedoramagazine.org/using-the-networkmanagers-dnsmasq-plugin/[Using the NetworkManager's DNSMasq plugin] (2019).
+
+
+== Prerequisites
+
+All the necessary interfaces have been installed and fully configured. This includes assigning the correct firewall zones.
+
+* **Check firewall zones**
++
+You should get something like
++
+[source,console]
+----
+$ firewall-cmd --get-active-zones
+FedoraServer (default)
+  interfaces: <IF01> ...
+<MY_ZONE>
+  interfaces: <IF02> ...
+----
++
+Fix the zone assignments if necessary
++
+[source,console]
+----
+$ sudo firewall-cmd --permanent --zone=<zone_name> --change-interface=<interface_name>
+$ sudo firewall-cmd --reload
+----
+
+* **Check auto forwarding**
++
+The system should automatically forward between the interfaces. Check the forwarding status and adjust it if necessary.
++
+[source,console]
+----
+$ cat /proc/sys/net/ipv4/ip_forward
+$ cat /proc/sys/net/ipv6/conf/default/forwarding
+----
++
+In both cases a value of 1 indicates an active forwarding.
++
+Otherwise, enable it immediately and configure it permanently.
++
+[source,console]
+----
+$ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
+$ echo 1 | sudo tee /proc/sys/net/ipv6/conf/all/forwarding
+
+$ sudo tee /etc/sysctl.d/50-enable-forwarding.conf << 'EOF'
+# local customizations
+#
+# enable forwarding for dual stack
+net.ipv4.ip_forward=1
+net.ipv6.conf.all.forwarding=1
+EOF
+----
 
-For additional information, see the _Fedora Magazine_ article  https://fedoramagazine.org/using-the-networkmanagers-dnsmasq-plugin/[Using the NetworkManager’s DNSMasq plugin] (2019).
 
 == Installation
-The NetworkManager dnsmasq plugin included  by default provides a basic configuration skeleton, but does not install the dnsmasq package. Thus, it avoids to uselessly occupy space and to introduce a superfluous and unused binary in case dnsmasq is not going to be in use on the particular server. 
+The NetworkManager dnsmasq plugin, included by default, provides a basic configuration skeleton, but does not install the dnsmasq package. Thus, it avoids unnecessarily occupying space and introducing a superfluous, unused binary when dnsmasq is not needed on the server. 
 
 In case dnsmasq is not already installed
-[source,]
+[source,console]
 ----
- […]# dnf install  dnsmasq
+$ sudo dnf install dnsmasq
 ----
 
 [IMPORTANT]
 ====
-Do *not* use systemctl directly on dnsmasq! It is used as a NetworkManager plugin, therefore NetworkManager starts and manages dnsmasq and adjusts `resolv.conf` accordingly. It uses its own set of parameters and ignores the packages' configuration file /etc/dnsmasq.conf. 
+Do *not* use `systemctl` directly on dnsmasq! It is used as a NetworkManager plugin, therefore NetworkManager starts and manages dnsmasq and adjusts `resolv.conf` accordingly. It uses its own set of parameters and ignores the package's configuration file /etc/dnsmasq.conf.
 
-Calling systemctl directly would be ineffective and would rather start yet another dnsmasq instance, which leads to conflicts.
+Calling `systemctl` directly would be ineffective and would rather start yet another dnsmasq instance, which leads to conflicts.
 ==== 
 
 
 == Basic configuration
 
-NetworkManager takes care of the dnsmasq plugin operation. Configuration files in the `/etc/NetworkManager/dnsmasq.d` directory specify the custom configuration requirements, preferably one configuration file per task. The only exception in this example is the file containing the  IP - hostname mapping of for static DNS names, `/etc/dnsmasq.hosts`. 
+NetworkManager takes care of the dnsmasq plugin operation. Configuration files in the `/etc/NetworkManager/dnsmasq.d` directory specify the custom configuration requirements, preferably one configuration file per task. The only exception in this example is the file containing the  IP - hostname mapping of static DNS names, `/etc/dnsmasq.hosts`. 
 
 [TIP]
 ====
-NetworkManager reads all files in that directory, independantly of the file extension. So you can't temporarily deactivate a configuration by renaming it.
+NetworkManager reads all files in that directory, independently of the file extension. So you cannot temporarily deactivate a configuration by renaming it.
 ==== 
 
-The example here uses 2 interfaces, an external public interface enp1s0 (example.com) and an internal private interface enp2s0 (example.lan). You may add any number of additional interfaces by adding corresponding config files as in the examples here.
+The example here uses 2 interfaces, an external public interface enp1s0 (public.tld) and an internal private interface enp2s0 (internal.lan). You may add any number of additional interfaces by adding corresponding config files as in the examples here.
 
 
-1. Activate the dnsmasq NetworkManager plugin
+1. **Activate the dnsmasq NetworkManager plugin**
 +
-[source,]
+Create and edit the file at `/etc/NetworkManager/conf.d/00-use-dnsmasq.conf` using your preferred editor running under `sudo` with root privileges. The content should be as follows:
++
+[source, ini]
 ----
- […]# vim /etc/NetworkManager/conf.d/00-use-dnsmasq.conf
- <i>
- # /etc/NetworkManager/conf.d/00-use-dnsmasq.conf #
- # This enabled the dnsmasq plugin.
- [main]
- dns=dnsmasq
- <esc><:wq>
+# /etc/NetworkManager/conf.d/00-use-dnsmasq.conf
+# This enables the dnsmasq plugin.
+[main]
+dns=dnsmasq
 ----
 
-2. Configuration of the name resolution (DNS) for the private network (example.lan)
+2. **Configuration of the name resolution (DNS) for the internal private network (internal.lan)**
 +
-[source,]
+Create and edit the file at `/etc/NetworkManager/dnsmasq.d/01-DNS-<INTERNAL>.conf` using your preferred editor running under `sudo` with root privileges. The content should be as follows:
++
+[source,ini]
 ----
- […]# vim /etc/NetworkManager/dnsmasq.d/01-DNS-example-lan.conf
- <i>
- # /etc/NetworkManager/dnsmasq.d/01-DNS-example-lan.conf
- # This file sets up DNS for the private local net domain example.lan
- local=/example.lan/
- # file where to find the list of IP - hostname mapping
- addn-hosts=/etc/dnsmasq.hosts
- 
- domain-needed 
- bogus-priv
- 
- # Automatically add <domain> to simple names in a hosts-file. 
- expand-hosts
- 
- # interfaces to listen on
- interface=lo
- interface=enp2s0
- # in case of a bridge don't use the attached server virtual ethernet interface
- 
- # The below defines a Wildcard DNS Entry. 
- #address=/.localnet/10.10.10.zzz
- 
- # Upstream public net DNS server (max.three)
- no-poll
- server=134.102.xx.yy 
- server=134.102.uu.vv 
- server=2001:638:xxx:yyy::zz
- <esc><:wq>
+# /etc/NetworkManager/dnsmasq.d/01-DNS-<INTERNAL>.conf
+# This file sets up DNS for the private local net domain '<INTERNAL>.lan'
+local=/<INTERNAL>.lan/
+# file where to find the list of IP - hostname mapping
+addn-hosts=/etc/dnsmasq-<INTERNAL>.hosts
+
+domain-needed
+bogus-priv
+
+# Automatically add <domain> to simple names in a hosts-file.
+expand-hosts
+
+# interfaces to listen on
+interface=lo
+interface=<ENPxyz>
+# in case of a bridge don't use the attached server virtual ethernet interface here!
+
+# Upstream public net DNS server (max.three)
+no-poll
+server=<uuu.vv.xx.yy>
+server=<www.vv.xx.zz>
+server=<2001:www:xxx:yyy::zz>
+----
++
+Substitute values for <INTERNAL>, <ENPxyz> with a name for your internal private network, and the network interface connected to your internal private network. 
++
+Substitute the values for <uuu.vv.xx.yy>, <www.vv.xx.zz>, and <2001:www:xxx:yyy::zz> with the IP addresses of any upstream DNS servers.
++
+Provide an empty host file
++
+[source,console]
+----
+$ sudo touch /etc/dnsmasq-<INTERNAL>.hosts
 ----
 
-3. Configuration of the DHCP service for the private network (example.lan)
+3. **Configuration of the DHCP service for the internal private network (<INTERNAL>.lan)**
 +
-[source,]
+Create and edit the file at `/etc/NetworkManager/dnsmasq.d/02-DHCP-<INTERNAL>.conf` using your preferred editor running under `sudo` with root privileges. The content should be as follows:
++
+[source,ini]
 ----
- […]# vim /etc/NetworkManager/dnsmasq.d/02-DHCP-example-lan.conf
- # etc/NetworkManager/dnsmasq.d/02-DHCP-example-lan.conf
- # This file sets up DHCP for the private local net domain example.lan
- 
- # The domain the DHCP part of dnsmasq is responsible for: 
- domain=example.lan,10.10.10.0/24,local
- 
- # interfaces to listen on 
- interface=enp2s0
- 
- # general DHCP stuff (options, see RFC 2132) 
- # 1: subnet masq
- # 3: default router
- # 6: DNS server
- # 12: hostname
- # 15: DNS domain (unneeded with option 'domain') 
- # 28: broadcast address
- 
- dhcp-authoritative 
- dhcp-option=1,255.255.255.0 
- dhcp-option=3,10.10.10.10 
- dhcp-option=6,10.10.10.1
- 
- # Assign fixed IP addresses based on MAC address
- # dhcp-host=00:1a:64:ce:89:4a,NAME01,10.10.10.50,infinite 
- # dhcp-host=52:54:00:42:6a:43,NAME02,10.10.10.51,infinite
- 
- # Assign dynamically IP addresses to interface to listen on
- # Range for distributed addresses, tagged <int> for further references dhcp-range=tag:enp2s0,10.10.10.150,10.10.10.200,24h
+# etc/NetworkManager/dnsmasq.d/02-DHCP-<INTERNAL>.conf
+# This file sets up DHCP for the private local net domain '<INTERNAL>.lan'
+
+# The domain the DHCP part of dnsmasq is responsible for:
+domain=<INTERNAL>.lan,<uuu.vv.xx.y/24>,local
+
+# interfaces to listen on (redundant, same as for DNS)
+interface=<ENPxyz>
+
+# general DHCP stuff (options, see RFC 2132)
+# 1: subnet masq
+# 3: default router
+# 6: DNS server
+# 12: hostname
+# 15: DNS domain (unneeded with option 'domain')
+# 28: broadcast address
+
+dhcp-authoritative
+dhcp-option=1,<255.255.255.0>
+dhcp-option=3,<www.xxx.yy.zz>
+dhcp-option=6,<www.xx.yy.z>
+
+# Assign fixed IP addresses based on MAC address
+# dhcp-host=00:1a:64:ce:89:4a,NAME01,www.xx.yy.zz,infinite
+# dhcp-host=52:54:00:42:6a:43,NAME02,www.xx.yy.zz,infinite
+
+# Assign dynamically IP addresses to interface to listen on
+# Range for distributed addresses, tagged <int> for further references
+dhcp-range=tag:<ENPxyz>,<vvv.ww.xx.y,vvv.ww.xx.z>,24h
+----
++
+Substitute values for <INTERNAL>, <ENPxyz> with a name for your internal private network, and the network interface connected to your internal private network. 
++
+Substitute the value of <uuu.vv.xx.y/24> with the network address and mask for your internal private network.
++ 
+The example shows the binding of the network interface and then sets the different DHCP responses for various client request options.
++ 
+The subnet mask (dhcp-option=1) is set to <255.255.255.0>, the default router or gateway (dhcp-option=3) is set to <www.xxx.yy.zz>, and the DNS server (dhcp-option=6) is set to <www.xx.yy.z>. Substitute values appropriate to your network.
++ 
+In this example, no permanent or fixed IP addresses are assigned, but examples are provided as commented lines, so that you can see how to add an entry to assign a particular IP address to a host based on its MAC address.
++ 
+The example enables a DHCP range within the network and assigns hosts IP addresses from <vvv.ww.xx.y> to <vvv.ww.xx.z> with leases lasting for 24 hours. Substitute values as appropriate for your network.
+
+4. **Configuration of the DHCP service for the public network (`<PUBLIC.TLD>`)**
++
+Create and edit the file at `/etc/NetworkManager/dnsmasq.d/03-DHCP-<PUBLIC.TLD>.conf` using your preferred editor running under `sudo` with root privileges. The content should be as follows:
++
+[source,ini]
+----
+# etc/NetworkManager/dnsmasq.d/03-DHCP-<PUBLIC.TLD>.conf
+# This file sets up DHCP for the public '<PUBLIC.TLD>' domain interface
+
+# The domain the DHCP part of dnsmasq is responsible for:
+domain=<PUBLIC.TLD>,<uuu.vv.ww.xx/24>
+
+# the public interfaces to listen on
+interface=<ENPuvw>
+
+# general DHCP stuff (options, see RFC 2132)
+# 1: subnet masq
+# 3: default router
+# 6: DNS server
+# 12: hostname
+# 15: DNS domain (unneeded with option 'domain')
+# 28: broadcast address
+
+##dhcp-authoritative
+## we just send the bare minimum, e.g. no DNS server
+##dhcp-option=1,<255.255.255.0>
+dhcp-option=tag:<ENPuvw>,option=router,<uuu.vv.ww.zz>
+
+# Assign fixed IP addresses based on MAC address
+# dhcp-host=00:1a:64:ce:89:4a,thootes,10.10.10.50,infinite
+# dhcp-host=52:54:00:42:6a:43,apollon,10.10.10.51,infinite
+# Assign dynamically IP addresses to interface to listen on
+# Range for distributed addresses, tagged <int> for further references dhcp-range=tag:<ENPuvw>,<uuu.vvv.w.x,uuu.vvv.w.y6,1h
+----
++
+Substitute values for `<PUBLIC.TLD>`, `<ENPuvw>` with the domain name for your public facing network, and the network interface connected to your public facing network.
++
+Substitute the value of `<uuu.vv.ww.xx/24>` with the network address and mask for your public facing network.
++
+Substitute the value `<uuu.vv.ww.zz>` with the IP address of the network router or default gateway.
++
+There is no DNS configuration for the external interface following, assuming that a official public DNS server is used to resolve all public facing interfaces of the domain public.tld.
+
+5. **Test the dnsmasq configuration**
++
+[source,console]
+----
+$ dnsmasq --test
 ----
 
-
-4. Configuration of the DHCP service for the public network (example.com)
+6. **Adjusting the firewall**
 +
-[source,]
+Allow ports for DHCP (UDP port 67) and DNS (TCP port 53) service on the public interface. If the system is running firewalld, you can configure these services as follows:
++
+[source,console]
 ----
-[…]# vim /etc/NetworkManager/dnsmasq.d/03-DHCP-example-com.conf
- # etc/NetworkManager/dnsmasq.d/03-DHCP-example-com.conf
- # This file sets up DNCP for the public example.com domain interface
-
- # The domain the DHCP part of dnsmasq is responsible for: 
- domain=example.com,134.102.xx.yy/27
- 
- # interfaces to listen on 
- interface=enp1s0
- 
- # general DHCP stuff (options, see RFC 2132) 
- # 1: subnet masq
- # 3: default router
- # 6: DNS server
- # 12: hostname
- # 15: DNS domain (unneeded with option 'domain') 
- # 28: broadcast address
-
- ##dhcp-authoritative
- ## we just send the bare minimum, e.g. no DNS server 
- ##dhcp-option=1,255.255.255.224 
- dhcp-option=tag:enp1s0,option=router,134.102.3.30
- 
- # Assign fixed IP addresses based on MAC address
- # dhcp-host=00:1a:64:ce:89:4a,thootes,10.10.10.50,infinite 
- # dhcp-host=52:54:00:42:6a:43,apollon,10.10.10.51,infinite
- # Assign dynamically IP addresses to interface to listen on
- # Range for distributed addresses, tagged <int> for further references dhcp-range=tag:enp1s0,134.102.3.19,134.102.3.26,1h
-----
-+
-There is no DNS configuration for the external interface following, assuming that a official public DNS server is used to resolve all public facing interfaces of the domain example.com.
-
-5. Adjusting the firewall
-+
-Allow ports for DHCP and DNS (53) service on the public interface.
-+
-[source,]
-----
- […]# firewall-cmd --get-services
- […]# firewall-cmd --zone=FedoraServer --permanent --add-service=dhcp
- […]# firewall-cmd --zone=FedoraServer --permanent --add-service=dns
- […]# firewall-cmd --reload 
- […]# firewall-cmd --list-all
+$ firewall-cmd --get-services
+$ sudo firewall-cmd --zone=<YOUR_ZONE> --permanent --add-service=dhcp
+$ sudo firewall-cmd --zone=<YOUR_ZONE> --permanent --add-service=dns
+$ sudo firewall-cmd --reload
+$ firewall-cmd --list-all --zone=<YOUR_ZONE>
 ----
 
-6. Disabling the systemd-resolved stub resolver
+7. **Restart NetworkManager to start dnsmasq**
 +
-Inhibit the stub resolver and remove the symlink /etc/resolv.conf so that Network Manager will generate a new resolv.conf directing queries to dnsmasq. For more info, see the man page for "systemd-resolved" under the heading "/ETC/RESOLV.CONF".
-+
-[source,]
+[source,console]
 ----
- […]# find /etc/resolv.conf -printf '%p -> %l\n'
- /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
- […]# rm -f /etc/resolv.conf
- […]# mkdir -p /etc/systemd/resolved.conf.d
- […]# echo -e "[Resolve]\nDNSStubListener=no" > /etc/systemd/resolved.conf.d/no-stub-listener.conf
+$ sudo systemctl restart NetworkManager
+$ ps -ef | grep dnsmasq
+dnsmasq     2114    2072  0 08:33 ?        00:00:00 /usr/sbin/dnsmasq --no-resolv ...
+----
++
+NetworkManager should have started `dnsmasq` shown by the `ps` command above.
+command above.
+
+8. **Restart systemd-resolved**
++
+[source,console]
+----
+$ sudo systemctl restart systemd-resolved
+$ resolvectl status
+----
++
+The systemd-resolved should recognize the dnsmasq nameserver attached to interfaces as configured.
+
+9. **Test the installation**
+
+a. Test DHCP in the public using a machine without IP address
++
+[source,console]
+----
+$ ip a   # no IPv4 address associated with interface
+$ sudo dhclient -4 -1 -v eth0
+$ ip a  # expect new IPv4 address associated with interface
+$ sudo dhclient -4 -1 -r -v eth0  # expected: no IPv4 again
+$ ip a  # expect no IPv4 address associated with interface again
+----
+b. Validate that a DNS lookup for the system works correctly on another server, by running any of the following:
++
+[source,console]
+----
+$ dig app1 @10.10.10.1
+$ nslookup app1 10.10.10.1
+$ dhclient -v -d -s 10.10.10.1 enp6s0
 ----
 
-7. Restart systemd-resolved and restart NetworkManager to start dnsmasq
-+
-The first time we restart systemd-resolved, it will no longer be running the stub resolver. The second time, we are reloading the configuration to prompt systemd-resolved to re-assess the /etc/resolv.conf generated by NetworkManager, but systemd-resolved does not support the "reload" unit command.
-+
-[source,]
-----
- […]# systemctl restart systemd-resolved
- […]# systemctl restart NetworkManager
- […]# systemctl restart systemd-resolved
-----
-+
-NetworkManager adjusts now the nameserver entries in /etc/resolv. They are replaced by 127.0.0.1 and processed via dnsmasq.
-
-8. Test the installation
-a. The dnsmasq internal self test
-+
-[source,]
-----
- […]# dnsmasq --test
-----
-b. Test DHCP in the public using a machine without IP address
-+
-[source,]
-----
- […]# ip a   # no IPv4 address associated with interface
- […]# dhclient -4 -1 -v eth0
- […]# ip a  # expect new IPv4 address associated with interface
- […]# dhclient -4 -1 -r -v eth0  # expected: no IPv4 again
- […]# ip a  # expect no IPv4 address associated with interface again
-----
-c. Try on an other server
-+
-[source,]
-----
- […]# dig app1 @10.10.10.1  
- […]# nslookup app1 10.10.10.1
- […]# dhclient -v -d -s 10.10.10.1 enp6s0
-----
 
 == Masquerading / NAT
 
@@ -242,17 +325,17 @@ If machines in the private network need access to the public network, add masque
 
 1. Enabling masquerading for the public zone and for the internal (trusted) trusted zone
 +
-[source,]
+[source,console]
 ----
-[…]# firewall-cmd --zone=FedoraServer --add-masquerade --permanent
+$ sudo firewall-cmd --zone=FedoraServer --add-masquerade --permanent
 success
-[…]# firewall-cmd --zone=trusted --add-masquerade --permanent
+$ sudo firewall-cmd --zone=trusted --add-masquerade --permanent
 success
-[…]# firewall-cmd --reload
-   
-[…]# firewall-cmd --zone=FedoraServer --query-masquerade
+$ sudo firewall-cmd --reload
+
+$ sudo firewall-cmd --zone=FedoraServer --query-masquerade
 yes
-[…]# firewall-cmd --zone=trusted --query-masquerade
+$ sudo firewall-cmd --zone=trusted --query-masquerade
 yes
 ----
 
@@ -261,39 +344,39 @@ further to the public network.
 +
 a. A commonly used way to accomplish this is to set 'rules' in the firewall configuration. Corresponding tutorials are very widespread. And those who are familiar with it may want to continue using it.
 +
-[source,]
+[source,console]
 ----
-[…]# firewall-cmd --get-active-zones
+$ firewall-cmd --get-active-zones
 FedoraServer
     interfaces: enp1s0
 trusted
     interfaces: vbr2s0 enp2s0
-[…]# firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 0 -o enp1s0 -j MASQUERADE
+$ sudo firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 0 -o enp1s0 -j MASQUERADE
 success
-[…]# firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i vbr2s0 -o enp2s0 -j ACCEPT
+$ sudo firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i vbr2s0 -o enp2s0 -j ACCEPT
 success
-[…]# firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i enp1s0 -o vbr2s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
+$ sudo firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i enp1s0 -o vbr2s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
 success
 ----
 
 b. Fedora's firewall daemon, however, offers with release 35 and beyond a more elegant option, so-called 'policies'. These abstract typical targets previously configured by rules. 
 +
-[source,]
+[source,console]
 ----
-[…]# firewall-cmd --get-active-zones
+$ firewall-cmd --get-active-zones
 FedoraServer
     interfaces: enp1s0
 trusted
     interfaces: vbr2s0 enp2s0
-[…]# firewall-cmd --permanent --new-policy trustedToExt
+$ sudo firewall-cmd --permanent --new-policy trustedToExt
   success
-[…]# firewall-cmd --permanent --policy trustedToExt --add-ingress-zone trusted
+$ sudo firewall-cmd --permanent --policy trustedToExt --add-ingress-zone trusted
   success
-[…]# firewall-cmd --permanent --policy trustedToExt --add-egress-zone FedoraServer
+$ sudo firewall-cmd --permanent --policy trustedToExt --add-egress-zone FedoraServer
   success
-[…]# firewall-cmd --permanent --policy trustedToExt --set-target ACCEPT
+$ sudo firewall-cmd --permanent --policy trustedToExt --set-target ACCEPT
   success
-[…]# firewall-cmd --reload
+$ sudo firewall-cmd --reload
   success
 ----
 +
@@ -301,48 +384,360 @@ This method is much clearer, improves maintainability and reduces sources of pot
 
 
 == Integrate libvirt's virtual interface
-In case libvirt and virualization including a virtual network for the virtual machines, libvirt installs and configures its own dnsmasq instance. In most cases it is just convenient, instead of replacing the libvirt _default_ network to integrate it in NetworkManagers dnsmasq plugin. Thus, two instances of dnsmasq operate along each other.
+In case libvirt and virtualization including a virtual network for the virtual machines, libvirt installs and configures its own dnsmasq instance. In most cases it is just convenient, instead of replacing the libvirt _default_ network to integrate it in NetworkManager's dnsmasq plugin. Thus, two instances of dnsmasq operate along each other.
 
-To make it work, just add onother configuration file. The example uses libvirt.lan as the libvirt virtual network domain name. Adjust as appropriate.
+To make it work, just add another configuration file, for example `/etc/NetworkManager/dnsmasq.d/30-DNS-libvirt.conf`. 
+
+The example uses libvirt.lan as the libvirt virtual network domain name. Adjust as appropriate.
 
 We just add the name resolution (DNS) for the libvirt virtual network (libvirt.lan), leaving the DHCP functionality untouched.
 
-[source,]
+[source,ini]
 ----
- […]# vim /etc/NetworkManager/dnsmasq.d/20-DNS-libvirt-lan.conf
- <i>
- # /etc/NetworkManager/dnsmasq.d/20-DNS-libvirt-lan.conf
+# /etc/NetworkManager/dnsmasq.d/30-DNS-libvirt.conf
 
- # This file directs dnsmasq to forward any request to resolve
- # names under the .libvirt.lan domain to 192.168.122.1, the 
- # local libvirt DNS server default address. 
- server=/libvirt.lan/192.168.122.1
- <esc><:><w><q>
+# This file directs dnsmasq to forward any request to resolve
+# names under the .libvirt.lan domain to 192.168.122.1, the
+# local libvirt DNS server default address.
+server=/libvirt.lan/192.168.122.1
 ----
 
-== Managing static DNS Entries
+== Managing static DNS entries
 
-1. Edit the dnsmasq host file
+1. **Edit the dnsmasq host file that you created at `/etc/dnsmasq-<INTERNAL>.hosts` to define internal DNS mappings for hosts on the local network.** 
 +
-The format is the same as /etc/hosts .
-+
-[source,]
-----
-[…]# vim /etc/dnsmasq.hosts
-----
+The format is the same as `/etc/hosts`. See the hosts(5) man page for more information.
 
-2. Restart NetworkManager to read the modified file. 
+2. **Restart NetworkManager to read the modified file.** 
 +
-[source,]
+[source,console]
 ----
-[…]# systemctl restart NetworkManager
+$ sudo systemctl restart NetworkManager
 ----
 
 3. Test the modification
 +
-[source,]
+[source,console]
 ----
-[…]# nslookup {NAME}
-[…]# nslookup {NAME}.example.lan
+$ sudo nslookup {NAME}
+$ sudo nslookup {NAME}.example.lan
 ----
 
+
+== Configuring dnsmasq as a PXE service
+
+Dnsmasq can be configured to act as a PXE service, by enabling the TFTP server and setting some dhcp-boot directives. In this example, the configuration is extended to provide a PXE service to enable network boot and to configure a Fedora installation over the network.
+
+Systems that use legacy BIOS to perform a network boot behave differently to systems that use UEFI firmware to do the same. Since most modern systems use UEFI and systems booting using legacy BIOS can complicate setup, the configuration described in this example focuses only on UEFI support.
+
+. **Install packages required to support PXE boot clients**:
++
+[source,console]
+----
+$ sudo dnf install grub2-tools grub2-efi-x64-modules
+----
+
+. **Create the TFTP server directories and provide the network boot loader files**:
++
+[source,console]
+----
+$ sudo mkdir /var/lib/tftpboot/
+----
++
+Use the `grub2-mknetdir` command to generate EFI binaries that are used for network boot.
++
+[source,console]
+----
+$ sudo grub2-mknetdir --net-directory=/var/lib/tftpboot --subdir=EFI
+Netboot directory for i386-pc created. Configure your DHCP server to point to /var/lib/tftpboot/EFI/i386-pc/core.0
+Netboot directory for i386-efi created. Configure your DHCP server to point to /var/lib/tftpboot/EFI/i386-efi/core.efi
+Netboot directory for x86_64-efi created. Configure your DHCP server to point to /var/lib/tftpboot/EFI/x86_64-efi/core.efi
+----
++
+[NOTE]
+====
+UEFI systems that have Secure Boot enabled might reject a PXE boot if the EFI binaries are not signed. The most simple solution to this issue is to disable Secure Boot in the UEFI firmware when you need to perform network-based installation.
+====
+
+
+. **Download or copy the installation kernel and ram-disk image files to the TFTP server directory hierarchy**:
++
+You can either copy these files directly off an installation ISO, or you can download them directly from Fedora. In this example, we create a directory to host these files and then download each of the files from the https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Everything/x86_64/os/images/pxeboot/[Fedora `pxeboot` download URL]:
++
+[source,console]
+----
+$ sudo mkdir /var/lib/tftpboot/fedora44
+$ curl -L -o /tmp/initrd.img https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Everything/x86_64/os/images/pxeboot/initrd.img
+$ curl -L -o /tmp/vmlinuz https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Everything/x86_64/os/images/pxeboot/vmlinuz
+$ sudo mv /tmp/{vmlinuz, initrd.img} /var/lib/tftpboot/fedora44
+----
+
+. **Create the PXE Boot configuration files**:
++
+PXE Boot configuration files define the boot menu that loads once the system is connected to the TFTP server.
++
+The `inst.repo` URL in the file tells the Anaconda installer where to fetch packages from. The URL provided in the example is the official Fedora mirror, but if the system does not have external network access, you can equally create a mirror or host the install tree from an ISO locally, and point to that instead. Also, downloading from the Fedora mirror could take a long time and slow down network based install. Consider creating a mirror and then pointing to a URL on your local network as an alternative.
++
+Note that menu entry for the Fedora 44 Network Install points to the `fedora44/initrd.img` and `fedora44/vmlinuz` files that we downloaded in the previous step. If you wanted to host multiple install options you can download the kernel and ram-disk images for each distribution or release and create a menu entry for each release.
++
+A menu entry is included to exit out of this menu and to use the next configured boot option, which usually includes the hard disk for the system. Providing this option in the menu, gives you a way to boot to disk easily. You can change the `set default=0` line to `set default=1` to make the second menu entry the default value, if you prefer.
++
+Create and edit the file at `/var/lib/tftpboot/EFI/x86_64-efi/grub.cfg` using your preferred editor running under `sudo` for root privileges:
++
+[source,]
+----
+set timeout=10
+set default=0
+
+menuentry "Fedora 44 Network Install" {
+     linuxefi fedora44/vmlinuz \
+        inst.repo=https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Everything/x86_64/os/ \
+        ip=dhcp \
+        inst.lang=en_US.UTF-8 \
+        inst.keymap=us \
+        quiet
+     initrdefi fedora44/initrd.img
+}
+
+menuentry 'Exit to next boot device' {
+      exit
+}
+----
+
+. **Add a dnsmasq configuration entry to enable the TFTP service**:
+Create and edit the file at `/etc/NetworkManager/dnsmasq.d/10-TFTP.conf` using your preferred editor running under `sudo` to acquire root privileges:
++
+[source,]
+----
+# Enable TFTP server
+#enable-tftp[=<interface>[,<interface>]]
+enable-tftp
+# dnsmasq serves files from this directory
+tftp-root=/var/lib/tftpboot
+
+# Tell DHCP clients where to find the TFTP server and which file to load
+# Note that this configuration assumes that all clients are using UEFI firmware.
+# If you need to distinguish between client types, use the dhcp match directive to identify the client-arch in the DHCP request. See RFC 4578 2.1.
+# BIOS clients have a client-arch=0.
+# UEFI x86_64 clients have a client-arch=7|9.
+
+dhcp-match=set:efi-x86_64,option:client-arch,7
+dhcp-match=set:efi-x86_64,option:client-arch,9
+# dhcp-boot=<tag>,<filename>[,<server-name>,<server-ip>]
+dhcp-boot=tag:efi-x86_64,EFI/x86_64-efi/core.efi
+
+----
++
+In the configuration, DHCP matching is used to tag the request for the appropriate client architecture (UEFI). The DHCP boot instructions describe the filename to serve for the given tag. If you were handling BIOS clients and you had configured the syslinux binaries appropriately, you could create dhcp-match and dhcp-boot directives appropriate to that client architecture.
++
+You can optionally edit the dhcp-boot directive to specify a server hostname or server IP where the TFTP service is located if not on the current dnsmasq host.
+Note that if you only want the TFTP service to be available on a particular network interface you can change the `enable-tftp` option to `enable-tftp=<IFNAME>`.
+
+. **Enable access to the TFTP service (UDP port 69) in your firewall**:
++
+If you're running firewalld, you can do this by running the following commands:
++
+[source,console]
+----
+$ sudo firewall-cmd --zone=FedoraServer --permanent --add-service=tftp
+$ sudo firewall-cmd --reload
+----
+
+. **Test the dnsmasq configuration to make sure that it is still valid**:
++
+[source,console]
+----
+$ dnsmasq --test
+dnsmasq: syntax check OK.
+----
+. **Restart NetworkManager to restart the dnsmasq plugin and enable the TFTP configuration**:
++
+[source,console]
+----
+$ sudo systemctl restart NetworkManager
+----
+
+. **If the system is running SELinux, set the file context on the `tftpboot` directory**:
++
+[source,console]
+----
+$ sudo semanage fcontext -a -t tftpdir_t "/var/lib/tftpboot(/.*)?"
+$ sudo restorecon -R -v /var/lib/tftpboot
+----
++
+[TIP]
+====
+If semanage is not available, install the `policycoreutils` package.
+====
+
+. **Network boot a client system to check that it is assigned an IP address and that the network based installation starts**:
++
+While the client system is booting, you can monitor the NetworkManager logs to check that DHCP requests are received and that the service responds correctly:
++
+[source,console]
+----
+$ journalctl -u NetworkManager -f | grep -E "dnsmasq|DHCP"
+----
++
+The client system should present the Network Boot menu and if the timeout is reached, should begin loading the Anaconda installer automatically.
+
+
+For network-based install to be properly effective, you should create a complete kickstart configuration file that can guide Anaconda through an unattended installation.
+//Add a link to documentation on creating kickstart files
+The Kickstart configuration file can be hosted on a local HTTP or NFS service and you can make it available to the installer by editing the PXE configuration file at `/var/lib/tftpboot/EFI/x86_64-efi/grub.cfg` and adding an entry for `inst.ks=` beneath the inst.repo line. For example, to point to a kickstart file hosted on an HTTP server with the IP address `10.0.100.1`, run something like:
+
+[source,console]
+----
+sudo sed -i '/inst.repo/a inst.ks=http://10.0.100.1/kickstart/my-server.ks.cfg \' /var/lib/tftpboot/EFI/x86_64-efi/grub.cfg
+----
+
+If you make any changes to `/etc/dnsmasq.conf`, restart the dnsmasq service. You do not need to restart the service if you change the content of boot loader configuration files.
+
+== Configuring dnsmasq for UEFI HTTP boot
+
+Unlike PXE boot, which uses DHCP to obtain TFTP server information and boot files, UEFI HTTP Boot allows a client to directly request boot files from a web server using HTTP or HTTPS.
+UEFI HTTP Boot provides a high-performance an more reliable alternative to PXE for remote boot configuration that is simpler to configure.
+Most significantly, you can configure HTTP Boot to point directly to a URL hosting an installation ISO file to trigger a remote installation, simplifying remote install setups.
+
+This approach offers several advantages:
+
+* Simpler network configuration
+* Better security with HTTPS support
+* ISO-based installation over the network
+* More reliable boot process
+* Easier troubleshooting
+
+=== Prerequisites
+
+Before configuring dnsmasq for UEFI HTTP Boot, ensure that:
+
+* UEFI firmware supports HTTP Boot
+* An HTTP server is set up and configured on the network that client systems are connected to
+* Your network infrastructure allows HTTP traffic on port 80 (or 443 for HTTPS)
+
+=== Configuring UEFI HTTP boot to install from ISO
+
+To enable HTTP Boot with dnsmasq, create and edit `/etc/NetworkManager/dnsmasq.d/11-HTTP.conf` in your preferred editor running under `sudo` for root privileges. The file content should look similar to the following:
+
+[source,ini]
+----
+## Service for UEFI HTTP Boot Clients
+
+# Set up dnsmasq to respond to clients that have the vendor class HTTPClient
+dhcp-pxe-vendor=HTTPClient
+# Match DHCP clients that use the X86_64 UEFI HTTP Boot architecture (16) and tag (efi_x64_http)
+dhcp-match=set:efi_x64_http,option:client-arch,16
+# Confirm the vendor class identifier (60) for HTTPClient support
+dhcp-option=tag:efi_x64_http,60,HTTPClient
+# Provide URL/bootfile-name (67) to the ISO or EFI file to load 
+dhcp-option=tag:efi_x64_http,67,http://10.0.100.1/fedora44-netinst.iso
+----
+
+In this example, we host a complete installation ISO on a web server located on the same network. You should replace the URL with one pointing to an accessible location. We recommend hosting ISO files within your local network, rather than pointing to locations on the Internet, to improve performance and to assist with network debugging. You should ideally validate any files you download from the Internet before hosting them. For example, in this configuration, on the web server we ran:
+
+[source,console]
+----
+$ curl https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/iso/Fedora-Server-netinst-x86_64-44-1.7.iso --output /tmp/fedora44-netinst.iso
+$ sudo mv /tmp/fedora44-netinst.iso /var/www/
+----
+
+Then restart NetworkManager to apply the changes:
+
+[source,console]
+----
+$ sudo systemctl restart NetworkManager
+----
+
+=== Configuring UEFI HTTP boot for advanced GRUB configuration
+
+While serving ISO files is useful, you require direct access to the console of each system to be able to control installation.
+It is often preferable to serve an EFI file that can load the GRUB bootloader with a configuration of your own design. This approach can help to automate installation.
+
+For example, just as we did for our PXEBoot configuration, at the root of your web server, you can do the following:
+
+1. Use the `grub2-mknetdir` command to generate EFI binaries that are used for network boot.
++
+[source,console]
+----
+$ sudo grub2-mknetdir --net-directory=/var/www --subdir=EFI
+Netboot directory for i386-pc created. Configure your DHCP server to point to /var/www/EFI/i386-pc/core.0
+Netboot directory for i386-efi created. Configure your DHCP server to point to /var/www/EFI/i386-efi/core.efi
+Netboot directory for x86_64-efi created. Configure your DHCP server to point to /var/www/EFI/x86_64-efi/core.efi
+----
+
+2. Either copy or download the kernel and initrd files for the distribution that you want to boot. For example:
++
+[source,console]
+----
+$ sudo mkdir /var/www/fedora44
+$ curl -L -o /tmp/initrd.img https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Everything/x86_64/os/images/pxeboot/initrd.img
+$ curl -L -o /tmp/vmlinuz https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Everything/x86_64/os/images/pxeboot/vmlinuz
+$ sudo mv /tmp/{vmlinuz, initrd.img} /var/www/fedora44/
+----
+
+3. Create a GRUB configuration file at `/var/www/EFI/x86_64-efi/grub.cfg` using your preferred editor running under `sudo` for root privileges:
++
+[source,]
+----
+set timeout=10
+set default=0
+
+menuentry "Fedora 44 Network Install" {
+     linuxefi /fedora44/vmlinuz \
+        inst.repo=https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Everything/x86_64/os/ \
+        ip=dhcp \
+        inst.lang=en_US.UTF-8 \
+        inst.keymap=us \
+        quiet
+     initrdefi /fedora44/initrd.img
+}
+
+menuentry 'Exit to next boot device' {
+      exit
+}
+----
+
+4. Edit `/etc/NetworkManager/dnsmasq.d/11-HTTP.conf` in your preferred editor running under `sudo` for root privileges. The file content should look similar to the following:
++
+[source,ini]
+----
+## Service for UEFI HTTP Boot Clients
+
+# Set up dnsmasq to respond to clients that have the vendor class HTTPClient
+dhcp-pxe-vendor=HTTPClient
+# Match DHCP clients that use the X86_64 UEFI HTTP Boot architecture (16) and tag (efi_x64_http)
+dhcp-match=set:efi_x64_http,option:client-arch,16
+# Confirm the vendor class identifier (60) for HTTPClient support
+dhcp-option=tag:efi_x64_http,60,HTTPClient
+# Provide URL/bootfile-name (67) to the ISO or EFI file to load
+dhcp-option=tag:efi_x64_http,67,http://10.0.100.1/EFI/x86_64-efi/core.efi
+----
++
+Substitute the IP address of your web server.
+
+5. Restart NetworkManager, to pick up the changes to the dnsmasq configuration:
++
+[source,console]
+----
+$ sudo systemctl restart NetworkManager
+----
+
+Your server is now ready to service UEFI HTTP Boot clients. You can edit the GRUB configuration file to include `inst.rdp` or `inst.ks` options on the kernel command line, to either provide remote RDP access to the installer, or to automate installation using a Kickstart configuration.
+
+
+=== Troubleshooting UEFI HTTP boot
+
+If you encounter issues with HTTP Boot:
+
+* Confirm that the UEFI client firmware supports HTTP Boot
+* Verify that the HTTP server is accessible from client machines
+* Check that firewall rules allow HTTP traffic
+* Ensure that the boot files exist in the correct locations
+* Monitor HTTP server logs to check that the clients are making HTTP requests
+
+For debugging, monitor NetworkManager logs to check that the clients are making the appropriate requests and the server is responding correctly:
+
+[source,console]
+----
+$ journalctl -u NetworkManager -f | grep -E "dnsmasq"
+----

modules/ROOT/pages/administration/index.adoc

@@ -1,12 +1,12 @@
-= Fedora Server Edition Basic Administration Guide
+= Fedora Server Edition basic administration guide
 Peter Boy; Jan Kuparinen; Emmanuel Seyman
-:page-authors: {author}, {author_2}, {author_3}
 :revnumber: F37-F38
+:page-authors: {author}, {author_2}, {author_3}
 :revdate: 2023-04-21
 
 :page-aliases: pages/sysadmin-an-introduction.adoc
 
-== What You Find Here
+== What you find here
 
 General basic system administration is covered in Fedora's overall  
 //xref:fedora::system-administrators-guide.adoc[System Administrator's Guide]. 
@@ -17,26 +17,26 @@ This section covers topics like name resolution tools, DHCP support, special net
 
 _Currently, the compilation and description of administrative tasks is still under construction. It will be continuously expanded._
 
-== Administrative Tools
+== Administrative tools
 
-Fedora Server Edition is designed as a headless device, i.e. without a graphical user interface. Corresponding packages are not even installed. Accordingly, only a simple text-based terminal is available on the box by default, which is somewhat euphemistically called a __Command Line Interface__ (CLI). 
+Fedora Server is designed as a headless device, i.e. without a graphical user interface. Corresponding packages are not even installed. Accordingly, only a simple text-based terminal is available on the box by default, which is somewhat euphemistically called a __Command Line Interface__ (CLI). 
 
 Very many servers do not even have a monitor and keyboard permanently connected. The administrator works over the network from his desktop. In this case, a graphical tool is also available, __Cockpit__, a lightweight web-based graphical user interface. It is very powerful and greatly simplifies administration even for experienced and CLI-savvy ("hard core") administrators. 
 
-//=== Comand line interface (CLI)
+//=== Command line interface (CLI)
 
 //Typically, however, administration is done remotely via a secure SSH connection.
 
 //=== Cockpit
 
-//In addition, a lightweight web-based graphical user interface, Cockpit, is available by default and is intended to simplify many typical and repetitive maintenance tasks. For example, the creation, formatting and mounting of a logical file area can be done with a short input form consisting of 3-4 topics and one click. This saves even the experienced system administrator a lot of time and the (error-free) typing of several command lines. 
+//In addition, a lightweight web-based graphical user interface, Cockpit, is available by default and is intended to simplify many typical and repetitive maintenance tasks. For example, the creation, formatting and mounting of a logical file area can be done with a short input form consisting of three to four topics and a single click. This saves even the experienced system administrator a lot of time and the (error-free) typing of several command lines. 
 
 
-== System security 
+== System security
 
-Fedora is very concerned about security. Accordingly, as part of the installation, the system is already fitted with many security-relevant configurations. Thus, by default, a firewall is installed and also activated, which only allows an ssh as well as a cockpit connection. SSH uses the latest encryption algorithms and blocks outdated, insecure methods. 
+Fedora is very concerned about security. Accordingly, as part of the installation, the system is already fitted with many security-relevant configurations. Thus, by default, a firewall is installed and also activated, which only allows SSH and a Cockpit connection. SSH uses the latest encryption algorithms and blocks outdated, insecure methods. 
 
 There is not much left for the system administrator to do. Measures that may be required are described together with the corresponding service.
 //xref:services/index.adoc[services]. 
 
-However, the installation process cannot perform all security-related configurations automatically.The system manager must weigh the pros and cons and make a decision. Admins should process these items immediately after the installation. For detailed information see xref:installation/postinstallation-tasks.adoc[Post Installation Tasks]. 
+However, the installation process cannot perform all security-related configurations automatically. The system manager must weigh the pros and cons and make a decision. Admins should process these items immediately after the installation. For detailed information see xref:postinstallation/index.adoc[Postinstallation Customizations]. 

modules/ROOT/pages/administration/point-to-point-connection.adoc

@@ -1,7 +1,7 @@
-= Setting Up a Point-to-Point Network Connection
+= Setting up a point-to-point network connection
 Peter Boy
-:page-authors: {author}
 :revnumber: all up to F38
+:page-authors: {author}
 :revdate: 2023-04-18
 
 //[NOTE]
@@ -20,25 +20,25 @@ Typically, a server (or desktop) is directly connected to a local network and al
 
 The limiting is handled exclusively in the network connection device mimicking an ordinary switch, bridge or router, completely uninfluenced by and independent of the individual servers or desktops. On the surface, they use a completely normal IP network structure.
 
-In a IPv4 network, a server unaware of the underlying limitation tries to establish connections as usual and fails at destinations within the same subnet. Instead, the IPv4 address of the server must be configured as a /32 address, i.e. a network with only one node. However, the gateway is then located outside of the own network and must be configured explicitly in order to be reachable. If the other nodes of the own subnet do not need to be reachable, a usual network configuration can be used.
+In an IPv4 network, a server unaware of the underlying limitation tries to establish connections as usual and fails at destinations within the same subnet. Instead, the IPv4 address of the server must be configured as a /32 address, i.e. a network with only one node. However, the gateway is then located outside of the own network and must be configured explicitly in order to be reachable. If the other nodes of the own subnet do not need to be reachable, a usual network configuration can be used.
 
 For an IPv6 configuration, it is sufficient to specify the link address of the gateway.
 
 
 == Configuration of current Fedora releases
 
-Given an interface enp1s0 with IPv4 address of 192.168.133.100 and the gateway 192.168.133.1 you may configure the interface
-[source,]
+Given an interface enp1s0 with IPv4 address of `192.168.133.100` and the gateway `192.168.133.1`, you may configure the interface
+[source,console]
 ----
-[…]# nmcli con mod enp1s0 ipv4.method manual ipv4.addresses '192.168.133.100/32' \
+# nmcli con mod enp1s0 ipv4.method manual ipv4.addresses '192.168.133.100/32' \
      ipv4.gateway '192.168.133.1' ipv4.dns '192.172.1.1'
 ----
 
 
 This will result in a configuration file like
-[source,]
+[source,console]
 ----
-[…]# less /etc/NetworkManager/system-connections/enp1s0.nmconnection 
+# less /etc/NetworkManager/system-connections/enp1s0.nmconnection 
 [connection]
 id=enp1s0
 uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
@@ -63,7 +63,7 @@ method=manual
 ----
 
 An alternative notation for the IPv4 part is
-[source,]
+[source,console]
 ----
 [ipv4]
 address1=192.168.133.100/32
@@ -72,21 +72,21 @@ route1=0.0.0.0/0,192.168.133.1
 ----
 
 In any case you get a 
-[source,]
+[source,console]
 ----
-[…]# ip r
+# ip r
 default via 192.168.133.1 dev enp1s0 proto static metric 100
 192.168.133.1 dev enp1s0 proto static scope link metric 100 
 ----
 
-== Pre Fedora 35 configuration
+== Pre-Fedora 35 configuration
 
 These Fedora releases used _ifcfg-IF_NAME_ files in /etc/sysconfig/network-scripts/. This method dates back to the time before NetworkManager was introduced and network connections were managed with a collection of shell scripts. The shell scripts disappeared with the introduction of NetworkManager, but the configuration files if cfg-NAME was retained as the default configuration method in Release 36 for backward compatibility. 
 
-Usually, you configure the interface using a text editor, eg given the above example
-[source,]
+Usually, you configure the interface using a text editor, e.g. given the above example
+[source,console]
 ----
-[…]# vim /etc/sysconfig/network-scripts/ifcfg-enp1s0
+# vim /etc/sysconfig/network-scripts/ifcfg-enp1s0
 DEVICE=enp1s0
 ONBOOT=yes
 BOOTPROTO=none
@@ -103,18 +103,18 @@ IPV6_DEFAULTDEV=enp1s0
 ----
 
 Additionally you need a routing table.
-[source,]
+[source,console]
 ----
-[…]# vim /etc/sysconfig/network-scripts/route-enp1s0
+# vim /etc/sysconfig/network-scripts/route-enp1s0
 ADDRESS0=0.0.0.0
 NETMASK0=0.0.0.0
 GATEWAY0=192.168.133.1
 ----
 
 Both variants result again in a
-[source,]
+[source,console]
 ----
-[…]# ip r
+# ip r
 default via 192.168.133.1 dev enp1s0 proto static metric 100
 192.168.133.1 dev enp1s0 proto static scope link metric 100 
 ----
@@ -122,9 +122,9 @@ default via 192.168.133.1 dev enp1s0 proto static metric 100
 == Using systemd-networkd
 
 Some server administrators might prefer systemd-network over NetworkManager. Many of the NetworkManager features are very useful for desktops and laptops, but rather superfluous for servers. The configuration tool is a plain text editor.
-[source,]
+[source,console]
 ----
-[…]# vim /etc/systemd/network/10-public.network
+# vim /etc/systemd/network/10-public.network
 [Match]
 MACAddress=12:34:56:78:9a:bc # or another identifier
 
@@ -136,4 +136,4 @@ Address=192.168.133.100/32  #  /32 suffix is optional here
 Peer=192.168.133.1/32       # Gateway, /32 suffix mandatory here
 ----
 
-Configuration of IPv6 is done as usual by specifying the address and the gateway.
+Configuration of IPv6 is done as usual by specifying the address and the gateway.

modules/ROOT/pages/administration/ssh-about.adoc

@@ -0,0 +1,142 @@
+= About SSH and OpenSSH
+Rowan Puttergill
+:revdate: 2026-06-12
+:page-authors: {author}
+:tags: SSH, Security, Access
+
+[abstract]
+SSH (Secure Shell) is a protocol which facilitates secure communications between two systems using a client-server architecture and allows users to log into server host systems remotely. Unlike other remote communication protocols, such as FTP, Telnet, or rlogin, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords.
+
+[NOTE]
+====
+**Status:** work in progress. Content in this section is in review and being updated. Feedback welcome!
+====
+
+The [application]*ssh* program is designed to replace older, less secure terminal applications used to log into remote hosts, such as [command]#telnet# or [command]#rsh#. A related program called `scp` replaces older programs designed to copy files between hosts, such as `rcp`. Because these older applications do not encrypt passwords transmitted between the client and the server, avoid them whenever possible. Using secure methods to log into remote systems decreases the risks for both the client system and the remote host.
+
+Fedora includes the general OpenSSH package, `openssh`, as well as the OpenSSH server, [package]*openssh-server*, and client, [package]*openssh-clients*, packages. Note, the OpenSSH packages require the OpenSSL package [package]*openssl-libs*, which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.
+
+[[s2-ssh-why]]
+== Why use SSH?
+indexterm:[SSH protocol,security risks]
+Potential intruders have a variety of tools at their disposal enabling them to disrupt, intercept, and re-route network traffic in an effort to gain access to a system. In general terms, these threats can be categorized as follows:
+
+Interception of communication between two systems::  The attacker can be somewhere on the network between the communicating parties, copying any information passed between them. He may intercept and keep the information, or alter the information and send it on to the intended recipient.
++
+This attack is usually performed using a _packet sniffer_, a rather common network utility that captures each packet flowing through the network, and analyzes its content.
+
+Impersonation of a particular host::  Attacker's system is configured to pose as the intended recipient of a transmission. If this strategy works, the user's system remains unaware that it is communicating with the wrong host.
++
+This attack can be performed using a technique known as _DNS poisoning_, or via so-called _IP spoofing_. In the first case, the intruder uses a cracked DNS server to point client systems to a maliciously duplicated host. In the second case, the intruder sends falsified network packets that appear to be from a trusted host.
+
+Both techniques intercept potentially sensitive information and, if the interception is made for hostile reasons, the results can be disastrous. If SSH is used for remote shell login and file copying, these security threats can be greatly diminished. This is because the SSH client and server use digital signatures to verify their identity. Additionally, all communication between the client and server systems is encrypted. Attempts to spoof the identity of either side of a communication does not work, since each packet is encrypted using a key known only by the local and remote systems.
+
+[[s2-ssh-features]]
+== Main features
+indexterm:[SSH protocol,features]indexterm:[OpenSSH,SSH]
+The SSH protocol provides the following safeguards:
+
+No one can pose as the intended server::  After an initial connection, the client can verify that it is connecting to the same server it had connected to previously.
+
+No one can capture the authentication information::  The client transmits its authentication information to the server using strong encryption.
+
+No one can intercept the communication::  All data sent and received during a session is transferred using strong encryption, making intercepted transmissions extremely difficult to decrypt and read.
+
+Additionally, it also offers the following options:
+
+It provides secure means to use graphical applications over a network::  Using a technique called _X11 forwarding_, the client can forward _X11_ (_X Window System_) applications from the server. Note that if you set the [option]`ForwardX11Trusted` option to `yes` or you use SSH with the [option]`-Y` option, you bypass the X11 SECURITY extension controls, which can result in a security threat.
+
+It provides a way to secure otherwise insecure protocols::  The SSH protocol encrypts everything it sends and receives. Using a technique called _port forwarding_, an SSH server can become a conduit to securing otherwise insecure protocols, like *POP*, and increasing overall system and data security.
+
+It can be used to create a secure channel::  The OpenSSH server and client can be configured to create a tunnel similar to a virtual private network for traffic between server and client machines.
+
+It supports Kerberos authentication::  OpenSSH servers and clients can be configured to authenticate using the *GSSAPI* (Generic Security Services Application Program Interface) implementation of the Kerberos network authentication protocol.
+
+[[s2-ssh-versions]]
+== Protocol versions
+indexterm:[SSH protocol,version 1]indexterm:[SSH protocol,version 2]
+Two varieties of SSH currently exist: version 1 and version 2. The OpenSSH suite under Fedora uses SSH version 2, which has an enhanced key exchange algorithm not vulnerable to the known exploit in version 1. Protocol version 1 was removed from OpenSSH suite and is no longer supported.
+
+[[s2-ssh-conn]]
+== Event sequence of an SSH connection
+indexterm:[SSH protocol,connection sequence]
+The following series of events help protect the integrity of SSH communication between two hosts.
+
+. A cryptographic handshake is made so that the client can verify that it is communicating with the correct server.
+
+. The transport layer of the connection between the client and remote host is encrypted using a symmetric cipher.
+
+. The client authenticates itself to the server.
+
+. The client interacts with the remote host over the encrypted connection.
+
+[[s2-ssh-protocol-conn-transport]]
+=== Transport layer
+indexterm:[SSH protocol,layers,transport layer]
+The primary role of the transport layer is to facilitate safe and secure communication between the two hosts at the time of authentication and during subsequent communication. The transport layer accomplishes this by handling the encryption and decryption of data, and by providing integrity protection of data packets as they are sent and received. The transport layer also provides compression, speeding the transfer of information.
+
+Once an SSH client contacts a server, key information is exchanged so that the two systems can correctly construct the transport layer. The following steps occur during this exchange:
+
+* The key exchange algorithm is determined
+
+* The public key signature algorithm is determined
+
+* The symmetric encryption algorithm is determined
+
+* The message authentication algorithm is determined
+
+* Keys are exchanged
+
+During the key exchange, the server identifies itself to the client with a unique _host key_. If the client has never communicated with this particular server before, the server's host key is unknown to the client and it does not connect. OpenSSH notifies the user that the authenticity of the host cannot be established and prompts the user to accept or reject it. The user is expected to independently verify the new host key before accepting it. In subsequent connections, the server's host key is checked against the saved version on the client, providing confidence that the client is indeed communicating with the intended server. If, in the future, the host key no longer matches, the user must remove the client's saved version before a connection can occur.
+
+.Always verify the integrity of a new SSH server
+[WARNING]
+====
+
+It is possible for an attacker to masquerade as an SSH server during the initial contact since the local system does not know the difference between the intended server and a false one set up by an attacker. To help prevent this, verify the integrity of a new SSH server by contacting the server administrator before connecting for the first time or in the event of a host key mismatch.
+
+====
+
+SSH is designed to work with almost any kind of public key algorithm or encoding format. After an initial key exchange creates a hash value used for exchanges and a shared secret value, the two systems immediately begin calculating new keys and algorithms to protect authentication and future data sent over the connection.
+
+After a certain amount of data has been transmitted using a given key and algorithm (the exact amount depends on the SSH implementation, encryption algorithm and configuration), another key exchange occurs, generating another set of hash values and a new shared secret value. Even if an attacker is able to determine the hash and shared secret value, this information is only useful for a limited period of time.
+
+[[s2-ssh-protocol-authentication]]
+=== Authentication
+indexterm:[SSH protocol,authentication]
+Once the transport layer has constructed a secure tunnel to pass information between the two systems, the server tells the client the different authentication methods supported, such as using a private key-encoded signature or typing a password. The client then tries to authenticate itself to the server using one of these supported methods.
+
+SSH servers and clients can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it supports based on its security model, and the client can choose the order of authentication methods to attempt from the available options.
+
+[[s2-ssh-protocol-connection]]
+=== Channels
+indexterm:[SSH protocol,layers,channels]
+After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called _multiplexing_pass:attributes[{blank}]footnote:[A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.]. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
+
+Both clients and servers can create a new channel. Each channel is then assigned a different number on each end of the connection. When the client attempts to open a new channel, the clients sends the channel number along with the request. This information is stored by the server and is used to direct communication to that channel. This is done so that different types of sessions do not affect one another and so that when a given session ends, its channel can be closed without disrupting the primary SSH connection.
+
+Channels also support _flow-control_, which allows them to send and receive data in an orderly fashion. In this way, data is not sent over the channel until the client receives a message that the channel is open.
+
+The client and server negotiate the characteristics of each channel automatically, depending on the type of service the client requests and the way the user is connected to the network. This allows great flexibility in handling different types of remote connections without having to change the basic infrastructure of the protocol.
+
+////
+[[s2-ssh-key-types]]
+== SSH host and user key types
+
+NOTE: This section is a placeholder. It should give a conceptual overview of
+the key algorithms referenced throughout these SSH topics (RSA, ECDSA, and
+Ed25519) -- what they are, and current recommendations (Ed25519 is now
+generally preferred over RSA and ECDSA for new keys). Practical steps for
+generating user key pairs are covered in xref:ssh-client.adoc[OpenSSH Client
+Configuration], and the host key files generated by the server are listed in
+xref:ssh-server.adoc[OpenSSH Server Configuration].
+////
+
+[[s1-openssh-additional-resources]]
+== Additional resources
+indexterm:[OpenSSH,additional resources]indexterm:[OpenSSL,additional resources]
+For more information about the SSH protocol, see the resources listed below.
+
+* link:++https://www.openssh.com/++[OpenSSH Home Page] — The OpenSSH home page containing further documentation, frequently asked questions, links to the mailing lists, bug reports, and other useful resources.
+
+* link:++https://www.openssl.org/++[OpenSSL Home Page] — The OpenSSL home page containing further documentation, frequently asked questions, links to the mailing lists, and other useful resources.

modules/ROOT/pages/administration/ssh-advanced-usage.adoc

@@ -0,0 +1,745 @@
+= Advanced SSH usage
+Rowan Puttergill
+:revdate: 2026-06-12
+:page-authors: {author}
+:tags: SSH, Security, Access
+
+
+[abstract]
+This topic walks through common SSH use cases that combine server-side configuration with client-side commands: certificate-based authentication, X11 forwarding, and port forwarding. It focuses on example configuration and commands for typical scenarios -- for complete directive and option references, see xref:administration/ssh-server.adoc[OpenSSH Server Configuration] and xref:administration/ssh-client.adoc[OpenSSH Client Configuration]. For background on the SSH protocol, see xref:administration/ssh-about.adoc[About SSH and OpenSSH].
+
+[NOTE]
+====
+**Status:** work in progress. Content in this section is in review and being updated. Feedback welcome!
+====
+
+[[sec-Using_OpenSSH_Certificate_Authentication]]
+== Use case: SSH certificate authentication
+
+[[sec-Introduction_to_SSH_Certificates]]
+=== Introduction to SSH certificates
+
+Using public key cryptography for authentication requires copying the public key from every client to every server that the client intends to log into. This system does not scale well and can be an administrative burden. Using a public key from a _certificate authority_ (*CA*) to authenticate client certificates removes the need to copy keys between multiple systems. While the X.509 Public Key Infrastructure Certificate system provides a solution to this issue, there is a submission and validation process, with associated fees, to go through in order to get a certificate signed. As an alternative, OpenSSH supports the creation of simple certificates and associated CA infrastructure.
+
+OpenSSH certificates contain a public key, identity information, and validity constraints. They are signed with a standard SSH public key using the [command]#ssh-keygen# utility. The format of the certificate is described in `/usr/share/doc/openssh-_version_pass:attributes[{blank}]/PROTOCOL.certkeys`.
+
+The [command]#ssh-keygen# utility supports two types of certificates: user and host. User certificates authenticate users to servers, whereas host certificates authenticate server hosts to users. For certificates to be used for user or host authentication, `sshd` must be configured to trust the CA public key.
+
+[[sec-Creating_SSH_CA_Certificate_Signing-Keys]]
+=== Creating SSH CA certificate signing keys
+
+Two types of certificates are required, host certificates and user certificates. It is considered better to have two separate keys for signing the two certificates, for example `ca_user_key` and `ca_host_key`, however it is possible to use just one CA key to sign both certificates. It is also easier to follow the procedures if separate keys are used, so the examples that follow will use separate keys.
+
+The basic format of the command to sign user's public key to create a user certificate is as follows:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -s ca_user_key -I pass:quotes[_certificate_ID_] id_rsa.pub
+----
+
+Where [option]`-s` indicates the private key used to sign the certificate, [option]`-I` indicates an identity string, the _certificate_ID_, which can be any alpha numeric value. It is stored as a zero terminated string in the certificate. The _certificate_ID_ is logged whenever the certificate is used for identification and it is also used when revoking a certificate. Having a long value would make logs hard to read, therefore using the host name for host certificates and the user name for user certificates is a safe choice.
+
+To sign a host's public key to create a host certificate, add the [option]`-h` option:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -s ca_host_key -I pass:quotes[_certificate_ID_] -h ssh_host_rsa_key.pub
+----
+
+Host keys are generated on the system by default, to list the keys, enter a command as follows:
+
+[subs="macros", source, bash]
+----
+$ ls -l /etc/ssh/ssh_host*
+-rw-------. 1 root root  480 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key
+-rw-r--r--. 1 root root  162 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key.pub
+-rw-------. 1 root root  387 May 13 16:11 /etc/ssh/ssh_host_ed25519_key
+-rw-r--r--. 1 root root   82 May 13 16:11 /etc/ssh/ssh_host_ed25519_key.pub
+-rw-------. 1 root root 2578 May 13 16:11 /etc/ssh/ssh_host_rsa_key
+-rw-r--r--. 1 root root  554 May 13 16:11 /etc/ssh/ssh_host_rsa_key.pub
+
+----
+
+[IMPORTANT]
+====
+
+It is recommended to create and store CA keys in a safe place just as with any other private key. In these examples the `root` user will be used. In a real production environment using an offline computer with an administrative user account is recommended. For guidance on key lengths see [citetitle]_link:++https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf++[NIST Special Publication 800-131A Revision 1]_.
+
+====
+
+[[proc-Generating_SSH_CA_Certificate_Signing-Keys]]
+.Generating SSH CA Certificate Signing Keys
+. On the server designated to be the CA, generate two keys for use in signing certificates. These are the keys that all other hosts need to trust. Choose suitable names, for example `ca_user_key` and `ca_host_key`. To generate the user certificate signing key, enter the following command:
++
+[subs="macros", source, bash]
+----
+sudo ssh-keygen -t rsa -f /root/.ssh/ca_user_key
+Generating public/private rsa key pair.
+Created directory '/root/.ssh'.
+Enter passphrase (empty for no passphrase):
+Enter same passphrase again:
+Your identification has been saved in /root/.ssh/ca_user_key
+Your public key has been saved in /root/.ssh/ca_user_key.pub
+The key fingerprint is:
+SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 root@host_name.example.com
+The key's randomart image is:
++---[RSA 3072]----+
+|       .+.      o|
+|       . o     +.|
+|      o + .   . o|
+|       o + . . ..|
+|        S . ... *|
+|        . . . .*.|
+|         = E  .. |
+|        . o .    |
+|           .     |
++----[SHA256]-----+
+----
++
+Generate a host certificate signing key, `ca_host_key`, as follows:
++
+[subs="macros", source, bash]
+----
+sudo ssh-keygen -t rsa -f /root/.ssh/ca_host_key
+Generating public/private rsa key pair.
+Enter passphrase (empty for no passphrase):
+Enter same passphrase again:
+Your identification has been saved in /root/.ssh/ca_host_key
+Your public key has been saved in /root/.ssh/ca_host_key.pub
+The key fingerprint is:
+SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 root@host_name.example.com
+The key's randomart image is:
++---[RSA 3072]----+
+|            ..   |
+|           . ....|
+|        . . o +oo|
+|       o .   o *o|
+|        S     = .|
+|             o. .|
+|            *.E. |
+|           +o=   |
+|          .oo.   |
++----[SHA256]-----+
+----
++
+If required, confirm the permissions are correct:
++
+[subs="macros", source, bash]
+----
+sudo ls -la /root/.ssh
+total 40
+drwxrwxrwx. 2 root root 4096 May 22 13:18 .
+dr-xr-x---. 3 root root 4096 May  8 08:34 ..
+-rw-------. 1 root root 1743 May 22 13:15 ca_host_key
+-rw-r--r--. 1 root root  420 May 22 13:15 ca_host_key.pub
+-rw-------. 1 root root 1743 May 22 13:14 ca_user_key
+-rw-r--r--. 1 root root  420 May 22 13:14 ca_user_key.pub
+-rw-r--r--. 1 root root  854 May  8 05:55 known_hosts
+-r--------. 1 root root 1671 May  6 17:13 ssh_host_rsa
+-rw-r--r--. 1 root root 1370 May  7 14:30 ssh_host_rsa-cert.pub
+-rw-------. 1 root root  420 May  6 17:13 ssh_host_rsa.pub
+----
+
+. Create the CA server's own host certificate by signing the server's host public key together with an identification string such as the host name, the CA server's _fully qualified domain name_ (*FQDN*) but without the trailing `.`, and a validity period. The command takes the following form:
++
+[subs="macros", source, bash]
+----
+# ssh-keygen -s ~/.ssh/ca_host_key -I pass:quotes[_certificate_ID_] -h -n pass:quotes[_host_name.example.com_] -V pass:quotes[_-start:+end_] /etc/ssh/ssh_host_rsa.pub
+----
++
+The [option]`-n` option restricts this certificate to a specific host within the domain. The [option]`-V` option is for adding a validity period; this is highly recommend. Where the validity period is intended to be one year, fifty two weeks, consider the need for time to change the certificates and any holiday periods around the time of certificate expiry.
++
+For example:
++
+[subs="macros", source, bash]
+----
+$ sudo ssh-keygen -s /root/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1w:+54w5d /etc/ssh/ssh_host_rsa.pub
+Enter passphrase:
+Signed host key /root/.ssh/ssh_host_rsa-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2020-05-15T13:52:29 to 2021-06-08T13:52:29
+----
+
+[[sec-Distributing_and_Trusting_SSH_CA_Public_Keys]]
+=== Distributing and trusting SSH CA public keys
+
+Hosts that are to allow certificate authenticated log in from users must be configured to trust the CA's public key that was used to sign the user certificates, in order to authenticate user's certificates. In this example that is the `ca_user_key.pub`.
+
+Publish the `ca_user_key.pub` key and download it to all hosts that are required to allow remote users to log in. Alternately, copy the CA user public key to all the hosts. In a production environment, consider copying the public key to an administrator account first. The secure copy command can be used to copy the public key to remote hosts. The command has the following format:
+
+[subs="macros", source, bash]
+----
+# scp  ~/.ssh/ca_user_key.pub root@pass:quotes[_host_name_].example.com:/etc/ssh/
+----
+
+Where _host_name_ is the host name of a server the is required to authenticate user's certificates presented during the login process. Ensure you copy the public key not the private key. For example:
+
+[subs="macros", source, bash]
+----
+$ sudo scp /root/.ssh/ca_user_key.pub root@host_name.example.com:/etc/ssh/
+The authenticity of host 'host_name.example.com (192.0.2.1)' can't be established.
+ED25519 key fingerprint is SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c.
+This key is not known by any other names.
+Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
+Warning: Permanently added 'host_name.example.com' (ED25519) to the list of known hosts.
+root@host_name.example.com's password:
+ca_user_key.pub                                       100%  420     0.4KB/s   00:00
+----
+
+For remote user authentication, CA keys can be marked as trusted per-user in the `~/.ssh/authorized_keys` file using the [command]#cert-authority# directive or for global use by means of the [command]#TrustedUserCAKeys# directive in the `/etc/ssh/sshd_config` file. For remote host authentication, CA keys can be marked as trusted globally in the `/etc/ssh/known_hosts` file or per-user in the `~/.ssh/ssh_known_hosts` file.
+
+[[proc-Trusting_the_User_Signing_Key]]
+.Trusting the User Signing Key
+. For user certificates which have one or more principles listed, and where the setting is to have global effect, edit the `/etc/ssh/sshd_config` file as follows:
++
+[subs="macros", source]
+----
+TrustedUserCAKeys /etc/ssh/ca_user_key.pub
+----
++
+Restart `sshd` to make the changes take effect:
++
+[subs="macros", source, bash]
+----
+$ sudo systemctl restart sshd.service
+----
+
+To avoid being presented with the warning about an unknown host, a user's system must trust the CA's public key that was used to sign the host certificates. In this example that is `ca_host_key.pub`.
+
+[[proc-Trusting_the_Host_Signing_Key]]
+.Trusting the Host Signing Key
+. Extract the contents of the public key used to sign the host certificate. For example, on the CA:
++
+[subs="macros", source, bash]
+----
+sudo cat /root/.ssh/ca_host_key.pub
+sudo ssh-rsa  pass:quotes[_AAAAB5Wm._]== root@ca-server.example.com
+----
+
+. To configure client systems to trust servers' signed host certificates, add the contents of the `ca_host_key.pub` into the global `known_hosts` file. This will automatically check a server's host advertised certificate against the CA public key for all users every time a new machine is connected to in the domain `*.example.com`. Configure the `/etc/ssh/ssh_known_hosts` file, as follows:
++
+[subs="macros", source, bash]
+----
+$ sudo vi /etc/ssh/ssh_known_hosts
+# A CA key, accepted for any host in *.example.com
+@cert-authority *.example.com ssh-rsa pass:quotes[_AAAAB5Wm._]
+----
++
+Where `ssh-rsa _AAAAB5Wm._pass:attributes[{blank}]` is the contents of `ca_host_key.pub`. The above configures the system to trust the CA servers host public key. This enables global authentication of the certificates presented by hosts to remote users.
+
+[[sec-Signing_SSH_Certificates]]
+=== Creating SSH certificates
+
+A certificate is a signed public key. The user's and host's public keys must be copied to the CA server for signing by the CA server's private key.
+
+[IMPORTANT]
+====
+
+Copying many keys to the CA to be signed can create confusion if they are not uniquely named. If the default name is always used then the latest key to be copied will overwrite the previously copied key, which may be an acceptable method for one administrator. In the example below the default name is used. In a production environment, consider using easily recognizable names. It is recommend to have a designated directory on the CA server owned by an administrative user for the keys to be copied into. Copying these keys to the `root` user's `/etc/ssh/` directory is not recommend. In the examples below an account named `admin` with a directory named `keys/` will be used.
+
+====
+
+Create an administrator account, in this example `admin`, and a directory to receive the user's keys. For example:
+
+[subs="quotes, macros", source, bash]
+----
+$ [command]#mkdir keys#
+----
+
+Set the permissions to allow keys to be copied in:
+
+[source, bash]
+----
+$ chmod o+w keys
+$ ls -la keys
+total 8
+drwxrwxrwx. 2 admin admin 4096 May 22 16:17 .
+drwx------. 3 admin admin 4096 May 22 16:17 ..
+----
+
+[[sec-Creating_SSH_Certificates_to_Authenticate_Hosts]]
+==== Creating SSH certificates to authenticate hosts
+
+The command to sign a host certificate has the following format:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -s ca_host_key -I pass:quotes[_host_name_] -h ssh_host_rsa_key.pub
+----
+
+The host certificate will named `ssh_host_rsa_key-cert.pub`.
+
+[[proc-Generating_a_Host_Certificate]]
+.Generating a Host Certificate
+To authenticate a host to a user, a public key must be generated on the host, passed to the CA server, signed by the CA, and then passed back to be stored on the host to present to a user attempting to log into the host.
+
+. Host keys are generated automatically on the system. To list them enter the following command:
++
+[subs="macros", source, bash]
+----
+$ sudo ls -l /etc/ssh/ssh_host*
+-rw-------. 1 root root  480 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key
+-rw-r--r--. 1 root root  162 May 13 16:11 /etc/ssh/ssh_host_ecdsa_key.pub
+-rw-------. 1 root root  387 May 13 16:11 /etc/ssh/ssh_host_ed25519_key
+-rw-r--r--. 1 root root   82 May 13 16:11 /etc/ssh/ssh_host_ed25519_key.pub
+-rw-------. 1 root root 2578 May 13 16:11 /etc/ssh/ssh_host_rsa_key
+-rw-r--r--. 1 root root  554 May 13 16:11 /etc/ssh/ssh_host_rsa_key.pub
+----
+
+. Copy the chosen public key to the server designated as the CA. For example, from the host:
++
+[subs="macros", source, bash]
+----
+$ sudo scp /etc/ssh/ssh_host_rsa_key.pub admin@ca-server.example.com:~/keys/ssh_host_rsa_key.pub
+The authenticity of host 'ca-server.example.com (192.0.2.2)' can't be established.
+ED25519 key fingerprint is SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c.
+This key is not known by any other names.
+Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
+Warning: Permanently added 'ca-server.example.com' (ED25519) to the list of known hosts.
+admin@ca-server.example.com's password:
+ssh_host_rsa_key.pub                           100%  382     0.4KB/s   00:00
+----
++
+Alternately, from the CA:
++
+[subs="macros", source, bash]
+----
+$ sudo scp  root@host_name.example.com:/etc/ssh/ssh_host_rsa_key.pub ~/keys/ssh_host_rsa_key.pub
+----
+
+. On the CA server, sign the host's public key. For example:
++
+[subs="macros", source, bash]
+----
+$ sudo ssh-keygen -s ~/.ssh/ca_host_key -I host_name -h -n host_name.example.com -V -1d:+54w /home/admin/keys/ssh_host_rsa_key.pub
+Enter passphrase:
+Signed host key /home/admin/keys/ssh_host_rsa_key-cert.pub: id "host_name" serial 0 for host_name.example.com valid from 2020-05-26T12:21:54 to 2021-06-08T12:21:54
+----
++
+Where _host_name_ is the host name of the system requiring the certificate.
+
+. Copy the certificate to the host. For example, from the CA:
++
+[subs="macros", source, bash]
+----
+$ sudo scp /home/admin/keys/ssh_host_rsa_key-cert.pub root@host_name.example.com:/etc/ssh/
+root@host_name.example.com's password:
+ssh_host_rsa_key-cert.pub                      100% 1384     1.5KB/s   00:00
+----
+
+. Configure the host to present the certificate to a user's system when a user initiates the login process. As `root`, edit the `/etc/ssh/sshd_config` file as follows:
++
+----
+HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
+----
+
+. Restart `sshd` to make the changes take effect:
++
+[subs="macros", source, bash]
+----
+$ sudo systemctl restart sshd.service
+----
+
+. On user's systems, remove keys belonging to hosts from the `~/.ssh/known_hosts` file if the user has previously logged into the host configured above. When a user logs into the host they should no longer be presented with the warning about the hosts authenticity.
+
+To test the host certificate, on a client system, ensure the client has set up the global `/etc/ssh/known_hosts` file, as described in xref:proc-Trusting_the_Host_Signing_Key[Trusting the Host Signing Key], and that the server's public key is not in the `~/.ssh/known_hosts` file. Then attempt to log into the server over SSH as a remote user. You should not see a warning about the authenticity of the host. If required, add the [option]`-v` option to the SSH command to see logging information.
+
+[[sec-Creating_SSH_Certificates_for_Authenticating_Users]]
+==== Creating SSH certificates for authenticating users
+
+To sign a user's certificate, use a command in the following format:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -s ca_user_key -I pass:quotes[_user_name_] -n pass:quotes[_user_name_] -V pass:quotes[_-start:+end_] id_rsa.pub
+----
+
+The resulting certificate will be named `id_rsa-cert.pub`.
+
+The default behavior of OpenSSH is that a user is allowed to log in as a remote user if one of the principals specified in the certificate matches the remote user's name. This can be adjusted in the following ways:
+
+* Add more user's names to the certificate during the signing process using the [option]`-n` option:
++
+[subs="quotes"]
+----
+-n "name1[,name2,...]"
+----
+
+* On the user's system, add the public key of the CA in the `~/.ssh/authorized_keys` file using the [command]#cert-authority# directive and list the principals names as follows:
++
+[subs="macros", source, bash]
+----
+$ vi ~/.ssh/authorized_keys
+# A CA key, accepted for any host in *.example.com
+@cert-authority principals="name1,name2" *.example.com ssh-rsa pass:quotes[_AAAAB5Wm._]
+----
+
+* On the server, create an `AuthorizedPrincipalsFile` file, either per user or globally, and add the principles' names to the file for those users allowed to log in. Then in the `/etc/ssh/sshd_config` file, specify the file using the [command]#AuthorizedPrincipalsFile# directive.
+
+[[proc-Generating_a_User_Certificate]]
+.Generating a User Certificate
+To authenticate a user to a remote host, a public key must be generated by the user, passed to the CA server, signed by the CA, and then passed back to be stored by the user for use when logging in to a host.
+
+. On client systems, login as the user who requires the certificate. Check for available keys as follows:
++
+[subs="quotes, macros", source, bash]
+----
+$ [command]#ls -l ~/.ssh/#
+----
++
+If no suitable public key exists, generate one and set the directory permissions if the directory is not the default directory. For example, enter the following command:
++
+[subs="quotes, macros", source, bash]
+----
+$ ssh-keygen -t rsa
+Generating public/private rsa key pair.
+Enter file in which to save the key (/home/user1/.ssh/id_rsa):
+Created directory '/home/user1/.ssh'.
+Enter passphrase (empty for no passphrase):
+Enter same passphrase again:
+Your identification has been saved in /home/user1/.ssh/id_rsa
+Your public key has been saved in /home/user1/.ssh/id_rsa.pub
+The key fingerprint is:
+SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 user1@host1.example.com
+The key's randomart image is:
++---[RSA 3072]----+
+|    oo++.        |
+|   o.o.o.        |
+|   .o o .        |
+|    oo . o       |
+|   . oo.S        |
+|     o=..        |
+|     .Eo+        |
+|      .=         |
+|     ..          |
++----[SHA256]-----+
+----
++
+By default the directory permissions for a user's keys are `drwx------.`, or octal 0700. If required, confirm the permissions are correct:
++
+[subs="quotes, macros", source, bash]
+----
+$ ls -la ~/.ssh
+total 16
+drwx------. 2 user1 user1 4096 May  7 12:37 .
+drwx------. 3 user1 user1 4096 May  7 12:37 ..
+-rw-------. 1 user1 user1 1679 May  7 12:37 id_rsa
+-rw-r--r--. 1 user1 user1  421 May  7 12:37 id_rsa.pub
+----
++
+See xref:administration/ssh-client.adoc#s3-ssh-configuration-keypairs-generating[Generating Key Pairs] in xref:administration/ssh-client.adoc[OpenSSH Client Configuration] for more examples of key generation and for instructions on setting the correct directory permissions.
+
+. The chosen public key must be copied to the server designated as the CA, in order to be signed. The secure copy command can be used to do this, the command has the following format:
++
+[subs="macros", source, bash]
+----
+$ scp  ~/.ssh/id_pass:quotes[_protocol_].pub pass:quotes[_admin_]@ca_server.example.com:~/keys/
+----
++
+Where _protocol_ is the part of the file name indicating the protocol used to generate the key, for example `rsa`, _admin_ is an account on the CA server, and _/keys/_ is a directory setup to receive the keys to be signed.
++
+Copy the chosen public key to the server designated as the CA. For example:
++
+[source, bash]
+----
+$ scp ~/.ssh/id_rsa.pub admin@ca-server.example.com:~/keys/
+admin@ca-server.example.com's password:
+id_rsa.pub                                  100%  421     0.4KB/s   00:00
+----
++
+If you have configured the client system to trust the host signing key as described in xref:proc-Trusting_the_Host_Signing_Key[Trusting the Host Signing Key] then you should not see a warning about the authenticity of the remote host.
+
+. On the CA server, sign the user's public key. For example, as `root`:
++
+[source, bash]
+----
+$ sudo ssh-keygen -s /root/.ssh/ca_user_key -I user1 -n user1 -V -1d:+54w /home/admin/keys/id_rsa.pub
+Enter passphrase:
+Signed user key /home/admin/keys/id_rsa-cert.pub: id "user1" serial 0 for host_name.example.com valid from 2020-05-21T16:43:17 to 2021-06-03T16:43:17
+----
+
+. Copy the resulting certificate to the user's `~/.ssh/` directory on their system. For example:
++
+[source, bash]
+----
+sudo scp /home/admin/keys/id_rsa-cert.pub user1@host_name.example.com:~/.ssh/
+user1@host_name.example.com's password:
+id_rsa-cert.pub                             100%  1498    1.5KB/s   00:00
+----
+
+. If using the standard file names and location then no further configuration is required as the SSH daemon will search for user certificates ending in `-cert.pub` and use them automatically if it finds them. Note that the default location and file names for SSH version 2 keys are: `~/.ssh/id_ecdsa`, `~/.ssh/id_ed25519` and `~/.ssh/id_rsa` as explained in the `ssh_config(5)` manual page. If you use these locations and naming conventions then there is no need for editing the configuration files to enable `sshd` to present the certificate. They will be used automatically when logging in to a remote system. In this is the case then skip to step 6.
++
+If required to use a non-default directory or file naming convention, then as `root`, add the following line to the `/etc/ssh/ssh_config` or `~/.ssh/config` files:
++
+[subs="macros"]
+----
+IdentityFile pass:quotes[_~/path/key_file_]
+----
++
+Note that this must be the private key name, do not had `.pub` or `-cert.pub`.
+Ensure the file permission are correct. For example:
++
+[subs="quotes, macros, attributes", source, bash]
+----
+$ [command]#ls -la ~/.ssh/config#
+-rw-rw-r--. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
+$ [command]#chmod 700 ~/.ssh/config#
+$ [command]#ls -la ~/.ssh/config#
+-rwx------. 1 user1 user1 36 May 27 21:49 /home/user1/.ssh/config
+----
++
+This will enable the user of this system to be authenticated by a user certificate when logging into a remote system configured to trust the CA user certificate signing key.
+
+. To test the user certificate, attempt to log into a server over SSH from the user's account. You should do this as the user listed as a principle in the certificate, if any are specified. You should not be prompted for a password. If required, add the [option]`-v` option to the SSH command to see logging information.
+
+[[sec-SSH_Certificate_PKCS_11_Token]]
+=== Signing an SSH certificate using a PKCS#11 token
+
+It is possible to sign a host key using a CA key stored in a PKCS#11 token by providing the token library using the [option]`-D` and identifying the CA key by providing its public half as an argument to the [option]`-s` option:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I pass:quotes[_certificate_ID_] host_key.pub
+----
+
+In all cases, _certificate_ID_ is a "`key identifier`" that is logged by the server when the certificate is used for authentication.
+
+Certificates may be configured to be valid only for a set of users or host names, the principals. By default, generated certificates are valid for all users or hosts. To generate a certificate for a specified set of principals, use a comma separated list with the [option]`-n` option as follows:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -s ca_user_key.pub -D libpkcs11.so -I pass:quotes[_certificate_ID_] -n pass:quotes[_user1,user2_] id_rsa.pub
+----
+
+and for hosts:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I pass:quotes[_certificate_ID_] -h -n host.domain ssh_host_rsa_key.pub
+----
+
+Additional limitations on the validity and use of user certificates may be specified through certificate options.
+A certificate option may disable features of the SSH session, may be valid only when presented from particular
+source addresses or may force the use of a specific command. For a list of valid certificate options, see the
+`ssh-keygen(1)` manual page for the [option]`-O` option.
+
+Certificates may be defined to be valid for a specific lifetime. The [option]`-V` option allows specifying a certificates
+start and end times. For example:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -s ca_user_key -I pass:quotes[_certificate_ID_] -V "-1w:+54w5d" id_rsa.pub
+----
+
+A certificate that is presented at a time outside this range will not be considered valid.
+By default, certificates are valid indefinitely starting from UNIX Epoch.
+
+[[sec-Viewing_an_SSH_CA_Certificate]]
+=== Viewing an SSH CA certificate
+
+To view a certificate, use the [option]`-L` to list the contents. For example, for a user's certificate:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -L -f ~/.ssh/id_rsa-cert.pub
+/home/user1/.ssh/id_rsa-cert.pub:
+        Type: ssh-rsa-cert-v01@openssh.com user certificate
+        Public key: RSA-CERT SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
+        Signing CA: RSA SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
+        Key ID: "user1"
+        Serial: 0
+        Valid: from 2020-05-27T00:09:16 to 2021-06-09T00:09:16
+        Principals:
+                user1
+        Critical Options: (none)
+        Extensions:
+                permit-X11-forwarding
+                permit-agent-forwarding
+                permit-port-forwarding
+                permit-pty
+                permit-user-rc
+----
+
+To view a host certificate:
+
+[subs="macros", source, bash]
+----
+$ sudo ssh-keygen -L -f /etc/ssh/ssh_host_rsa_key-cert.pub
+/etc/ssh/ssh_host_rsa_key-cert.pub:
+        Type: ssh-rsa-cert-v01@openssh.com host certificate
+        Public key: RSA-CERT SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
+        Signing CA: RSA SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0
+        Key ID: "host_name"
+        Serial: 0
+        Valid: from 2020-05-26T17:19:01 to 2021-06-08T17:19:01
+        Principals:
+                host_name.example.com
+        Critical Options: (none)
+        Extensions: (none)
+----
+
+[[sec-Revoking_an_SSH_CA_Certificate]]
+=== Revoking an SSH CA certificate
+
+If a certificate is stolen, it should be revoked. Although OpenSSH does not provide a mechanism to distribute the revocation list it is still easier to create the revocation list and distribute it by other means then to change the CA keys and all host and user certificates previously created and distributed.
+
+Keys can be revoked by adding them to the `revoked_keys` file and specifying the file name in the `sshd_config` file as follows:
+
+----
+RevokedKeys /etc/ssh/revoked_keys
+----
+
+Note that if this file is not readable, then public key authentication will be refused for all users.
+
+A new key revocation list can be generated as follows:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -kf  /etc/ssh/revoked_keys -z 1 ~/.ssh/id_rsa.pub
+----
+
+To add lines to the list, use the [option]`-u` option to update the list:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -ukf /etc/ssh/revoked_keys -z pass:quotes[_integer_] ~/.ssh/id_rsa.pub
+----
+
+where _integer_ is the line number.
+
+To test if a key has been revoked, query the revocation list for the presence of the key. Use a command as follows:
+
+[subs="macros", source, bash]
+----
+$ ssh-keygen -Qf  /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub
+----
+
+A user can revoke a CA certificate by changing the [command]#cert-authority# directive to [command]#revoke# in the `known_hosts` file.
+
+== Use case: X11 and port forwarding
+
+A secure command line interface is just the beginning of the many ways SSH can be used. Given the proper amount of bandwidth, X11 sessions can be directed over an SSH channel. Or, by using TCP/IP forwarding, previously insecure port connections between systems can be mapped to specific SSH channels.
+
+[[s2-ssh-beyondshell-x11]]
+=== X11 forwarding
+indexterm:[SSH protocol,X11 forwarding]
+To open an X11 session over an SSH connection, use a command in the following form:
+
+[subs="quotes, macros", source, bash]
+----
+$ [command]#ssh -Y _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_pass:attributes[{blank}]#
+----
+
+For example, to log in to a remote machine named `penguin.example.com` with `USER` as a user name, type:
+
+[subs="quotes, macros, attributes", source, bash]
+----
+$ [command]#ssh -Y USER@penguin.example.com#
+USER@penguin.example.com's password:
+----
+
+When an X program is run from the secure shell prompt, the SSH client and server create a new secure channel, and the X program data is sent over that channel to the client machine transparently.
+
+NOTE: For X11 forwarding to work, the SSH server must allow it. Ensure `X11Forwarding yes` is set in `/etc/ssh/sshd_config` (see xref:administration/ssh-server.adoc[OpenSSH Server Configuration])
+
+The remote system must also be able to run X11 applications and authenticate X11 sessions. The [package]#xorg-x11-xauth# package is required for this purpose.
+
+[subs="macros", source, bash]
+----
+$ sudo dnf install xorg-x11-xauth
+----
+
+X11 forwarding can be useful for accessing graphical applications on a remote system without running a full remote desktop sharing environment.
+For example, to open and interact with the firefox browser on a remote system, you can run:
+
+[subs="quotes, macros, attributes", source, bash]
+----
+$ ssh -Y user@penguin.example.com firefox
+----
+
+The [application]*Firefox* application opens, allowing you to browse using the firefox application as if you were on the remote system. When you close the browser,
+the SSH connection drops. You could equally SSH into the remote system and then run any graphical application from the command line and use the & option to background
+the process. If you do this, the SSH connection stays open after you close the graphical application, and you are able to run multiple graphical applications in the
+same session.
+
+Note that although Wayland replaces the legacy X11 server as the display server on Fedora, X11 forwarding of applications over SSH is still functional.
+
+[[s2-ssh-beyondshell-tcpip]]
+=== Local port forwarding (-L)
+indexterm:[SSH protocol,port forwarding]
+SSH can secure otherwise insecure `TCP/IP` protocols via port forwarding. When using this technique, the SSH server becomes an encrypted conduit to the SSH client.
+
+Port forwarding works by mapping a local port on the client to a remote port on the server. SSH can map any port from the server to any port on the client. Port numbers do not need to match for this technique to work.
+
+.Using reserved port numbers
+[NOTE]
+====
+
+Setting up port forwarding to listen on ports below 1024 requires `root` level access.
+
+====
+
+To create a TCP/IP port forwarding channel which listens for connections on the `localhost`, use a command in the following form:
+
+[subs="quotes, macros", source, bash]
+----
+$ [command]#ssh -L _local-port_:pass:attributes[{blank}]_remote-hostname_:pass:attributes[{blank}]_remote-port_ _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_pass:attributes[{blank}]#
+----
+
+For example, to check email on a server called `mail.example.com` using `POP3` through an encrypted connection, use the following command:
+
+[subs="quotes, macros, attributes", source, bash]
+----
+$ [command]#ssh -L 1100:mail.example.com:110 mail.example.com#
+----
+
+Once the port forwarding channel is in place between the client machine and the mail server, direct a POP3 mail client to use port `1100` on the `localhost` to check for new email. Any requests sent to port `1100` on the client system will be directed securely to the `mail.example.com` server.
+
+If `mail.example.com` is not running an SSH server, but another machine on the same network is, SSH can still be used to secure part of the connection. However, a slightly different command is necessary:
+
+[subs="quotes, macros, attributes", source, bash]
+----
+$ [command]#ssh -L 1100:mail.example.com:110 other.example.com#
+----
+
+In this example, POP3 requests from port `1100` on the client machine are forwarded through the SSH connection on port `22` to the SSH server, `other.example.com`. Then, `other.example.com` connects to port `110` on `mail.example.com` to check for new email. Note that when using this technique, only the connection between the client system and `other.example.com` SSH server is secure.
+
+Port forwarding can also be used to get information securely through network firewalls. If the firewall is configured to allow SSH traffic via its standard port (that is, port 22) but blocks access to other ports, a connection between two hosts using the blocked ports is still possible by redirecting their communication over an established SSH connection.
+
+.A connection is only as secure as a client system
+[IMPORTANT]
+====
+
+Using port forwarding to forward connections in this manner allows any user on the client system to connect to that service. If the client system becomes compromised, the attacker also has access to forwarded services.
+
+System administrators concerned about port forwarding can disable this functionality on the server by specifying a [option]`No` parameter for the [option]`AllowTcpForwarding` line in `/etc/ssh/sshd_config` and restarting the [command]#sshd# service.
+
+====
+
+////
+=== Remote port forwarding (-R)
+
+NOTE: This section is a placeholder. It should cover `ssh -R _remote-port_:_local-host_:_local-port_ _user_@_hostname_` to expose a local (or LAN-accessible) service to the remote host, and the server-side `GatewayPorts` directive needed if the forwarded port should be reachable from other hosts on the server's network.
+////
+
+////
+=== Dynamic port forwarding / SOCKS proxy (-D)
+
+NOTE: This section is a placeholder. It should cover `ssh -D _local-port_ _user_@_hostname_` to turn the SSH client into a SOCKS proxy, and how to point a browser or other application at it.
+////
+
+////
+== Use case: Passwordless login setup
+
+NOTE: This section is a placeholder. It should walk through the end-to-end flow of generating a key pair and copying it to a server with `ssh-copy-id` (see xref:administration/ssh-client.adoc#s2-ssh-client-keypairs[Generating and Managing SSH Keys] in xref:administration/ssh-client.adoc[OpenSSH Client Configuration]), then disabling password authentication on the server (see xref:administration/ssh-server.adoc#s2-ssh-configuration-keypairs[Enforcing Key-based Authentication] in xref:administration/ssh-server.adoc[OpenSSH Server Configuration]).
+////
+
+////
+== Use case: jump hosts (ProxyJump)
+
+NOTE: This section is a placeholder. It should cover using `ssh -J _jumphost_ _destination_` (or the `ProxyJump` directive) to reach a host via an intermediate bastion/jump host, and reference the `~/.ssh/config` gap section in xref:administration/ssh-client.adoc[OpenSSH Client Configuration].
+////
+
+== See also
+
+* xref:administration/ssh-about.adoc[About SSH and OpenSSH] -- conceptual background on the SSH protocol.
+* xref:administration/ssh-server.adoc[OpenSSH Server Configuration] -- full reference for `sshd` and server-side configuration.
+* xref:administration/ssh-client.adoc[OpenSSH Client Configuration] -- full reference for `ssh`, `scp`, `sftp`, and client-side configuration.

modules/ROOT/pages/administration/ssh-client.adoc

@@ -0,0 +1,454 @@
+= OpenSSH client configuration
+Rowan Puttergill
+:revdate: 2026-06-12
+:page-authors: {author}
+:tags: SSH, Security, Access
+
+
+[abstract]
+This topic covers connecting to OpenSSH servers using `ssh`, `scp`, and `sftp`, plus client-side configuration files and SSH key management. For server-side configuration, see xref:administration/ssh-server.adoc[OpenSSH Server Configuration]. For background on the SSH protocol, see xref:administration/ssh-about.adoc[About SSH and OpenSSH].
+
+[NOTE]
+====
+**Status:** work in progress. Content in this section is in review and being updated. Feedback welcome!
+====
+
+.Make sure you have relevant packages installed
+[NOTE]
+====
+
+To connect to an OpenSSH server from a client machine, you must have the [package]*openssh-clients* package installed. If it is not already installed, run:
+
+[source,bash]
+---
+$ sudo dnf install openssh-clients
+---
+
+====
+
+[[s2-ssh-configuration-configs-user]]
+== Configuration files
+indexterm:[SSH protocol,configuration files,user-specific configuration files]
+User-specific SSH configuration information is stored in `~/.ssh/` within the user's home directory, as described in xref:table-ssh-configuration-configs-user[User-specific configuration files] below. For the system-wide client configuration file, `/etc/ssh/ssh_config`, and the server's configuration files, see xref:administration/ssh-server.adoc#table-ssh-configuration-configs-system[System-wide configuration files] in xref:administration/ssh-server.adoc[OpenSSH Server Configuration].
+
+[[table-ssh-configuration-configs-user]]
+.User-specific configuration files
+
+[options="header"]
+|===
+|File|Description
+|`~/.ssh/authorized_keys`|Holds a list of authorized public keys for servers. When the client connects to a server, the server authenticates the client by checking its signed public key stored within this file.
+|`~/.ssh/id_ecdsa`|Contains the ECDSA private key of the user.
+|`~/.ssh/id_ecdsa.pub`|The ECDSA public key of the user.
+|`~/.ssh/id_rsa`|The RSA private key used by [command]#ssh#.
+|`~/.ssh/id_rsa.pub`|The RSA public key used by [command]#ssh#.
+|`~/.ssh/id_ed25519`|The EdDSA private key used by [command]#ssh#.
+|`~/.ssh/id_ed25519.pub`|The EdDSA public key used by [command]#ssh#.
+|`~/.ssh/known_hosts`|Contains host keys of SSH servers accessed by the user. This file is very important for ensuring that the SSH client is connecting to the correct SSH server.
+|===
+
+For information concerning various directives that can be used in the SSH configuration files, see the `ssh_config`(5) and `sshd_config`(5) manual pages.
+
+[[s2-ssh-clients-ssh]]
+== Using the `ssh` utility
+indexterm:[ssh,OpenSSH]indexterm:[OpenSSH,client,ssh]
+The [command]#ssh# utility allows you to log in to a remote machine and execute commands there. It is a secure replacement for the `rlogin`, [command]#rsh#, and [command]#telnet# programs.
+
+Similarly to the [command]#telnet# command, log in to a remote machine by using the following command:
+
+[subs="quotes, macros", source, bash]
+----
+$ ssh _hostname_
+----
+
+For example, to log in to a remote machine named `penguin.example.com`, type the following at a shell prompt:
+
+[subs="quotes, macros, attributes", source, bash]
+----
+$ ssh penguin.example.com
+----
+
+This will log you in with the same user name you are using on the local machine. If you want to specify a different user name, use a command in the following form:
+
+[subs="quotes, macros", source, bash]
+----
+$ ssh _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_
+----
+
+For example, to log in to `penguin.example.com` as `USER`, type:
+
+[subs="quotes, macros, attributes", source, bash]
+----
+$ ssh USER@penguin.example.com
+----
+
+The first time you initiate a connection, you will be presented with a message similar to this:
+
+[subs="quotes"]
+----
+The authenticity of host 'penguin.example.com (192.0.2.1)' can't be established.
+ED25519 key fingerprint is SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c.
+This key is not known by any other names.
+Are you sure you want to continue connecting (yes/no/[fingerprint])?
+----
+
+Users should always check if the fingerprint is correct before answering the question in this dialog. The user can ask the administrator of the server to confirm the key is correct. This should be done in a secure and previously agreed way. If the user has access to the server's host keys, the fingerprint can be checked by using the [command]#ssh-keygen# command as follows:
+
+[subs="attributes", source, bash]
+----
+$ ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
+256 SHA256:ZYEUaevOAEASvYjm58PiPdMebxhhlaTZBjTMr/N2I3c root@penguin.example.com (ED25519)
+----
+
+Type `yes` to accept the key and confirm the connection. You will see a notice that the server has been added to the list of known hosts, and a prompt asking for your password:
+
+[subs="quotes"]
+----
+Warning: Permanently added 'penguin.example.com' (ED25519) to the list of known hosts.
+USER@penguin.example.com's password:
+----
+
+.Updating the host key of an SSH server
+[IMPORTANT]
+====
+
+If the SSH server's host key changes, the client notifies the user that the connection cannot proceed until the server's host key is deleted from the `~/.ssh/known_hosts` file. Before doing this, however, contact the system administrator of the SSH server to verify the server is not compromised.
+
+To remove a key from the `~/.ssh/known_hosts` file, issue a command as follows:
+
+[subs="macros, attributes", source, bash]
+----
+$ ssh-keygen -R pass:quotes[_penguin.example.com_]
+# Host penguin.example.com found: line 15
+/home/USER/.ssh/known_hosts updated.
+Original contents retained as /home/USER/.ssh/known_hosts.old
+----
+
+====
+
+After entering the password, you will be provided with a shell prompt for the remote machine.
+
+Alternatively, the [command]#ssh# program can be used to execute a command on the remote machine without logging in to a shell prompt:
+
+[subs="quotes, macros", source, bash]
+----
+$ ssh _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_ _command_
+----
+
+For example, the `/etc/redhat-release` file provides information about the Fedora version. To view the contents of this file on `penguin.example.com`, type:
+
+[subs="quotes, macros, attributes", source, bash]
+----
+$ ssh USER@penguin.example.com cat /etc/redhat-release
+USER@penguin.example.com's password:
+Fedora release 44 (Forty Four)
+----
+
+After you enter the correct password, the user name will be displayed, and you will return to your local shell prompt.
+
+[[s2-ssh-client-keypairs]]
+== Generating and managing SSH keys
+indexterm:[OpenSSH,using key-based authentication]
+To be able to use [command]#ssh#, `scp`, or [command]#sftp# to connect to a server, generate an authorization key pair by following the steps below. Note that keys must be generated for each user separately.
+
+Fedora uses SSH Protocol 2 by default (see xref:administration/ssh-about.adoc#s2-ssh-versions[Protocol Versions] for more information). When generating new keys, Ed25519 is the recommended key type; RSA and ECDSA are also supported for compatibility with older systems.
+
+.Do not generate key pairs as root
+[IMPORTANT]
+====
+
+If you complete the steps as `root`, only `root` will be able to use the keys.
+
+====
+
+.Backup your ~/.ssh/ directory
+[NOTE]
+====
+
+If you reinstall your system and want to keep previously generated key pairs, backup the `~/.ssh/` directory. After reinstalling, copy it back to your home directory. This process can be done for all users on your system, including `root`.
+
+====
+
+[[s3-ssh-configuration-keypairs-generating]]
+=== Generating an RSA key pair
+indexterm:[RSA keys,generating]indexterm:[OpenSSH,RSA keys,generating]
+To generate an RSA key pair for version 2 of the SSH protocol, follow these steps:
+indexterm:[OpenSSH,ssh-keygen,RSA]
+
+. Generate an RSA key pair by typing the following at a shell prompt:
++
+[subs="attributes", source, bash]
+----
+$ ssh-keygen -t rsa
+Generating public/private rsa key pair.
+Enter file in which to save the key (/home/USER/.ssh/id_rsa):
+----
+
+. Press kbd:[Enter] to confirm the default location, `~/.ssh/id_rsa`, for the newly created key.
+
+. Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account.
++
+After this, you will be presented with a message similar to this:
++
+----
+Your identification has been saved in /home/USER/.ssh/id_rsa
+Your public key has been saved in /home/USER/.ssh/id_rsa.pub
+The key fingerprint is:
+SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 USER@penguin.example.com
+The key's randomart image is:
++---[RSA 3072]----+
+|             E.  |
+|            . .  |
+|             o . |
+|              . .|
+|        S .    . |
+|         + o o ..|
+|          * * +oo|
+|           O +..=|
+|           o*  o.|
++----[SHA256]-----+
+----
+
+. By default, the permissions of the `~/.ssh/` directory are set to `rwx------` or `700` expressed in octal notation. This is to ensure that only the _USER_ can view the contents. If required, this can be confirmed with the following command:
++
+[subs="quotes, macros, attributes", source, bash]
+----
+$ [command]#ls -ld ~/.ssh#
+drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
+----
+
+. To copy the public key to a remote machine, issue a command in the following format:
++
+[subs="quotes, macros", source, bash]
+----
+$ [command]#ssh-copy-id _user@hostname_pass:attributes[{blank}]#
+----
++
+This will copy the most recently modified `~/.ssh/id*.pub` public key if it is not yet installed. Alternatively, specify the public key's file name as follows:
++
+[source, bash]
+----
+$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname
+----
++
+This will copy the content of `~/.ssh/id_rsa.pub` into the `~/.ssh/authorized_keys` file on the machine to which you want to connect. If the file already exists, the keys are appended to its end.
+
+=== Generating an ECDSA key pair
+indexterm:[ECDSA keys,generating]indexterm:[OpenSSH,ECDSA keys,generating]
+To generate an ECDSA key pair for version 2 of the SSH protocol, follow these steps:
+indexterm:[OpenSSH,ssh-keygen,ECDSA]
+
+. Generate an ECDSA key pair by typing the following at a shell prompt:
++
+[subs="attributes", source, bash]
+----
+$ ssh-keygen -t ecdsa
+Generating public/private ecdsa key pair.
+Enter file in which to save the key (/home/USER/.ssh/id_ecdsa):
+----
+
+. Press kbd:[Enter] to confirm the default location, `~/.ssh/id_ecdsa`, for the newly created key.
+
+. Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account.
++
+After this, you will be presented with a message similar to this:
++
+----
+Your identification has been saved in /home/USER/.ssh/id_ecdsa
+Your public key has been saved in /home/USER/.ssh/id_ecdsa.pub
+The key fingerprint is:
+SHA256:y6f0DGlHe28YWotEypnhfk3WLYQ5TgaQwoSlOFwmmm0 USER@penguin.example.com
+The key's randomart image is:
++---[ECDSA 256]---+
+|       .+ +o     |
+|       . =.o     |
+|        o o +  ..|
+|         + + o  +|
+|        S o o oE.|
+|           + oo+.|
+|            + o  |
+|                 |
+|                 |
++----[SHA256]-----+
+----
+
+. By default, the permissions of the `~/.ssh/` directory are set to `rwx------` or `700` expressed in octal notation. This is to ensure that only the _USER_ can view the contents. If required, this can be confirmed with the following command:
++
+[subs="quotes, macros, attributes", source, bash]
+----
+$ [command]#ls -ld ~/.ssh#
+drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
+----
+
+. To copy the public key to a remote machine, issue a command in the following format:
++
+[subs="quotes, macros", source, bash]
+----
+$ [command]#ssh-copy-id _USER@hostname_pass:attributes[{blank}]#
+----
++
+This will copy the most recently modified `~/.ssh/id*.pub` public key if it is not yet installed. Alternatively, specify the public key's file name as follows:
++
+[source, bash]
+----
+$ ssh-copy-id -i ~/.ssh/id_ecdsa.pub USER@hostname
+----
++
+This will copy the content of `~/.ssh/id_ecdsa.pub` into the `~/.ssh/authorized_keys` on the machine to which you want to connect. If the file already exists, the keys are appended to its end.
+
+=== Generating an Ed25519 key pair
+
+NOTE: This section is a placeholder. Ed25519 is the current recommended default for new keys -- it produces smaller keys than RSA or ECDSA while remaining very secure and fast. This section should mirror the RSA/ECDSA steps above using `ssh-keygen -t ed25519`, including the default key location (`~/.ssh/id_ed25519`) and `ssh-copy-id` usage.
+
+See xref:s3-ssh-configuration-keypairs-agent[Configuring ssh-agent] below for information on how to set up your system to remember the passphrase.
+
+.Never share your private key
+[IMPORTANT]
+====
+
+The private key is for your personal use only, and it is important that you never give it to anyone.
+
+====
+
+[[s3-ssh-configuration-keypairs-agent]]
+=== Configuring ssh-agent
+indexterm:[OpenSSH,ssh-agent]indexterm:[ssh-agent]
+To store your passphrase so that you do not have to enter it each time you initiate a connection with a remote machine, you can use the [command]#ssh-agent# authentication agent.
+
+To save your passphrase for a certain shell prompt, use the following command:
+
+[subs="attributes", source, bash]
+----
+$ ssh-add
+Enter passphrase for /home/USER/.ssh/id_rsa:
+----
+
+Note that when you log out, your passphrase will be forgotten. You must execute the command each time you log in to a virtual console or a terminal window.
+
+[[s2-ssh-client-config-file]]
+== The SSH client configuration file (~/.ssh/config)
+
+NOTE: This section is a placeholder and is not covered in the original topic. It should cover the per-user `~/.ssh/config` file (and the system-wide `/etc/ssh/ssh_config`), including `Host` blocks/aliases, common per-host options such as `HostName`, `User`, `Port`, and `IdentityFile`, the `ProxyJump` directive for jump hosts, and global defaults such as `ServerAliveInterval`.
+
+[[s2-ssh-clients-scp]]
+== Using the `scp` utility
+indexterm:[scp,OpenSSH]indexterm:[OpenSSH,client,scp]indexterm:[`rcp`]
+`scp` can be used to transfer files between machines over a secure, encrypted connection. In its design, it is very similar to `rcp`.
+
+To transfer a local file to a remote system, use a command in the following form:
+
+[subs="quotes, macros", source, bash]
+----
+$ [command]#scp _localfile_ _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_:pass:attributes[{blank}]_remotefile_pass:attributes[{blank}]#
+----
+
+For example, if you want to transfer `taglist.vim` to a remote machine named `penguin.example.com`, type the following at a shell prompt:
+
+[subs="quotes, macros, attributes", source, bash]
+----
+$ [command]#scp taglist.vim USER@penguin.example.com:.vim/plugin/taglist.vim#
+USER@penguin.example.com's password:
+taglist.vim                                   100%  144KB 144.5KB/s   00:00
+----
+
+Multiple files can be specified at once. To transfer the contents of `.vim/plugin/` to the same directory on the remote machine `penguin.example.com`, type the following command:
+
+[subs="attributes", source, bash]
+----
+$ scp .vim/plugin/* USER@penguin.example.com:.vim/plugin/
+USER@penguin.example.com's password:
+closetag.vim                                  100%   13KB  12.6KB/s   00:00
+snippetsEmu.vim                               100%   33KB  33.1KB/s   00:00
+taglist.vim                                   100%  144KB 144.5KB/s   00:00
+----
+
+To transfer a remote file to the local system, use the following syntax:
+
+[subs="quotes, macros", source, bash]
+----
+$ [command]#scp _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_:pass:attributes[{blank}]_remotefile_ _localfile_pass:attributes[{blank}]#
+----
+
+For instance, to download the `.vimrc` configuration file from the remote machine, type:
+
+[subs="quotes, macros, attributes", source, bash]
+----
+$ [command]#scp USER@penguin.example.com:.vimrc .vimrc#
+USER@penguin.example.com's password:
+.vimrc                                        100% 2233     2.2KB/s   00:00
+----
+
+[IMPORTANT]
+====
+
+The SCP protocol is not well designed and can cause unexpected results. In the past it was source of several CVEs where malicious server could override files in local filesystem when downloading files. It is recommended to use SFTP when possible. See the next section for more information.
+
+====
+
+[[s2-ssh-clients-sftp]]
+== Using the [command]#sftp# utility
+indexterm:[sftp,OpenSSH]indexterm:[OpenSSH,client,sftp]
+The [command]#sftp# utility can be used to open a secure, interactive SFTP session. In its design, it is similar to [command]#ftp# except that it uses a secure, encrypted connection.
+
+To connect to a remote system, use a command in the following form:
+
+[subs="quotes, macros", source, bash]
+----
+$ [command]#sftp _username_pass:attributes[{blank}]@pass:attributes[{blank}]_hostname_pass:attributes[{blank}]#
+----
+
+For example, to log in to a remote machine named `penguin.example.com` with `USER` as a user name, type:
+
+[subs="quotes, macros, attributes", source, bash]
+----
+$ [command]#sftp USER@penguin.example.com#
+USER@penguin.example.com's password:
+Connected to penguin.example.com.
+sftp>
+----
+
+After you enter the correct password, you will be presented with a prompt. The [command]#sftp# utility accepts a set of commands similar to those used by [command]#ftp# (see xref:table-ssh-clients-sftp[A selection of available sftp commands]).
+
+[[table-ssh-clients-sftp]]
+.A selection of available sftp commands
+
+[options="header"]
+|===
+|Command|Description
+|[command]#ls# [pass:attributes[{blank}]_directory_pass:attributes[{blank}]]|List the content of a remote _directory_. If none is supplied, a current working directory is used by default.
+|[command]#cd# _directory_|Change the remote working directory to _directory_.
+|`mkdir` _directory_|Create a remote _directory_.
+|`rmdir` _directory_|Remove a remote _directory_.
+|`put` `localfile` [pass:attributes[{blank}]`remotefile`_pass:attributes[{blank}]]|Transfer `localfile` to a remote machine.
+|`get` `remotefile` [pass:attributes[{blank}]`localfile`_pass:attributes[{blank}]]|Transfer `remotefile` from a remote machine.
+|===
+
+For a complete list of available commands, see the `sftp`(1) manual page.
+
+== SSH certificates
+
+NOTE: Generating user certificates and configuring `IdentityFile` to present them is covered as part of the SSH Certificate Authentication use case in xref:administration/ssh-advanced-usage.adoc[Advanced SSH Usage].
+
+////
+== Agent forwarding
+
+NOTE: This section is a placeholder. It should cover SSH agent forwarding (`ssh -A`, the `ForwardAgent` option), typical use cases such as jumping through a bastion host without copying private keys, and the associated security caveat of trusting the remote host with access to your agent.
+
+////
+
+[[s1-openssh-client-additional-resources]]
+== Additional resources
+indexterm:[OpenSSH,additional resources]
+For more information on how to connect to an OpenSSH server from Fedora, see the resources listed below.
+
+* `ssh`(1) — The manual page for the [command]#ssh# client application provides a complete list of available command line options and supported configuration files and directories.
+
+* `scp`(1) — The manual page for the `scp` utility provides a more detailed description of this utility and its usage.
+
+* `sftp`(1) — The manual page for the [command]#sftp# utility.
+
+* `ssh-keygen`(1) — The manual page for the [command]#ssh-keygen# utility documents in detail how to use it to generate, manage, and convert authentication keys used by [command]#ssh#.
+
+* `ssh_config`(5) — The manual page named `ssh_config` documents available SSH client configuration options.
+
+For server-side resources and information about the SSH protocol, see xref:administration/ssh-server.adoc[OpenSSH Server Configuration] and xref:administration/ssh-about.adoc[About SSH and OpenSSH].

modules/ROOT/pages/administration/ssh-server.adoc

@@ -0,0 +1,181 @@
+= OpenSSH server configuration
+Rowan Puttergill
+:revdate: 2026-06-12
+:page-authors: {author}
+:tags: SSH, Security, Access
+
+
+[abstract]
+This topic covers installing, starting, and configuring the OpenSSH server (`sshd`) on Fedora, including system-wide configuration files, enforcing key-based authentication, and other server-side security settings. For client-side configuration and key management, see xref:administration/ssh-client.adoc[OpenSSH Client Configuration]. For background on the SSH protocol, see xref:administration/ssh-about.adoc[About SSH and OpenSSH].
+
+[NOTE]
+====
+**Status:** work in progress. Content in this section is in review and being updated. Feedback welcome!
+====
+
+[[s2-ssh-configuration-configs]]
+== Configuration files
+indexterm:[SSH protocol,configuration files]
+There are two different sets of configuration files: those for client programs (that is, [command]#ssh#, `scp`, and [command]#sftp#), and those for the server (the [command]#sshd# daemon).
+indexterm:[SSH protocol,configuration files,system-wide configuration files]
+System-wide SSH configuration information is stored in the `/etc/ssh/` directory as described in xref:table-ssh-configuration-configs-system[System-wide configuration files] below. For the user-specific configuration files stored in `~/.ssh/`, see xref:administration/ssh-client.adoc#table-ssh-configuration-configs-user[User-specific configuration files] in xref:administration/ssh-client.adoc[OpenSSH Client Configuration].
+
+[[table-ssh-configuration-configs-system]]
+.System-wide configuration files
+
+[options="header"]
+|===
+|File|Description
+|`/etc/ssh/moduli`|Contains Diffie-Hellman groups used for the "`Diffie-Hellman group exchange`" key exchange method, which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. If the file is not available, fixed groups will be used. Other key exchange methods do not need this file.
+|`/etc/ssh/ssh_config`|The default SSH client configuration file. Note that it is overridden by `~/.ssh/config` if it exists.
+|`/etc/ssh/sshd_config`|The configuration file for the [command]#sshd# daemon.
+|`/etc/ssh/ssh_host_ecdsa_key`|The ECDSA private key used by the [command]#sshd# daemon.
+|`/etc/ssh/ssh_host_ecdsa_key.pub`|The ECDSA public key used by the [command]#sshd# daemon.
+|`/etc/ssh/ssh_host_rsa_key`|The RSA private key used by the [command]#sshd# daemon.
+|`/etc/ssh/ssh_host_rsa_key.pub`|The RSA public key used by the [command]#sshd# daemon.
+|`/etc/ssh/ssh_host_ed25519_key`|The EdDSA private key used by the [command]#sshd# daemon.
+|`/etc/ssh/ssh_host_ed25519_key.pub`|The EdDSA public key used by the [command]#sshd# daemon.
+|`/etc/pam.d/sshd`|The PAM configuration file for the [command]#sshd# daemon.
+|`/etc/sysconfig/sshd`|Configuration file for the `sshd` service.
+|===
+
+For information concerning various directives that can be used in the SSH configuration files, see the `ssh_config`(5) and `sshd_config`(5) manual pages.
+
+[[s2-ssh-configuration-sshd]]
+== Starting an OpenSSH server
+indexterm:[OpenSSH,server]
+
+.Make sure you have relevant packages installed
+[NOTE]
+====
+
+To run an OpenSSH server, you must have the [package]*openssh-server* package installed. If not already installed, run:
+
+[subs="attributes", source, bash]
+----
+$ sudo dnf install openssh-server
+----
+
+====
+indexterm:[OpenSSH,server,starting]
+To start the [command]#sshd# daemon in the current session, type the following at a shell prompt:
+
+[subs="attributes", source, bash]
+----
+$ sudo systemctl start sshd.service
+----
+indexterm:[OpenSSH,server,stopping]
+To stop the running [command]#sshd# daemon in the current session, use the following command:
+
+[subs="attributes", source, bash]
+----
+$ sudo systemctl stop sshd.service
+----
+
+If you want the daemon to start automatically at the boot time, use the following command:
+
+[subs="attributes", source, bash]
+----
+$ sudo systemctl enable sshd.service
+Created symlink '/etc/systemd/system/multi-user.target.wants/sshd.service' → '/usr/lib/systemd/system/sshd.service'.
+----
+
+See xref:infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons] for more information on how to configure services in Fedora.
+
+Note that if you reinstall the system, a new set of identification keys will be created. As a result, clients who had connected to the system with any of the OpenSSH tools before the reinstall will see the following message:
+
+[subs="quotes"]
+----
+@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
+@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
+Someone could be eavesdropping on you right now (man-in-the-middle attack)!
+It is also possible that the RSA host key has just been changed.
+----
+
+To prevent this, you can backup the relevant files from the `/etc/ssh/` directory (see xref:table-ssh-configuration-configs-system[System-wide configuration files] for a complete list), and restore them whenever you reinstall the system.
+
+[[s2-ssh-configuration-requiring]]
+== Requiring SSH for remote connections
+indexterm:[SSH protocol,insecure protocols]indexterm:[SSH protocol,requiring for remote login]
+For SSH to be truly effective, using insecure connection protocols should be prohibited. Otherwise, a user's password may be protected using SSH for one session, only to be captured later while logging in using Telnet. Some services to disable include [command]#telnet#, [command]#rsh#, `rlogin`, and [command]#vsftpd#.
+
+These services are not installed by default in Fedora. If required, to make sure these services are not running, type the following commands at a shell prompt:
+
+[subs="quotes, macros", source, bash]
+----
+$ sudo systemctl stop telnet.service
+$ sudo systemctl stop rsh.service
+$ sudo systemctl stop rlogin.service
+$ sudo systemctl stop vsftpd.service
+----
+
+To disable running these services at startup, type:
+
+[subs="quotes, macros", source, bash]
+----
+$ sudo systemctl disable telnet.service
+$ sudo systemctl disable rsh.service
+$ sudo systemctl disable rlogin.service
+$ sudo systemctl disable vsftpd.service
+----
+
+See xref:infrastructure-services/Services_and_Daemons.adoc#ch-Services_and_Daemons[Services and Daemons] for more information on how to configure services in Fedora.
+
+[[s2-ssh-configuration-keypairs]]
+== Enforcing key-based authentication
+indexterm:[OpenSSH,using key-based authentication]
+To improve the system security even further, generate SSH key pairs and then enforce key-based authentication by disabling password authentication. To do so, create a drop-in configuration file, for example `/etc/ssh/sshd_config.d/01-local.conf`. Make sure it is lexicographically before the `50-redhat.conf` file, providing Fedora defaults. In a text editor such as [application]*vi* or [application]*nano* insert the [option]`PasswordAuthentication` option as follows:
+
+[subs="quotes", source]
+----
+PasswordAuthentication no
+----
+
+If you are working on a system other than a new default installation, check that [command]#PubkeyAuthentication no# has *not* been set in neither `/etc/ssh/sshd_config` nor any included file from drop-in directory. If connected remotely, not using console or out-of-band access, testing the key-based log in process before disabling password authentication is advised.
+
+To generate SSH key pairs and copy them to this server so that key-based authentication works once password authentication is disabled, see xref:administration/ssh-client.adoc#s3-ssh-configuration-keypairs-generating[Generating Key Pairs] in xref:administration/ssh-client.adoc[OpenSSH Client Configuration].
+
+== SSH certificates
+
+NOTE: Configuring `HostCertificate`, `TrustedUserCAKeys`, `RevokedKeys`, and `AuthorizedPrincipalsFile` for certificate-based authentication is covered as part of the SSH Certificate Authentication use case in xref:administration/ssh-advanced-usage.adoc[Advanced SSH Usage].
+
+////
+== Restricting user and group access
+
+NOTE: This section is a placeholder. It should cover restricting which users and groups may log in over SSH using the `AllowUsers`, `DenyUsers`, `AllowGroups`, and `DenyGroups` directives in `sshd_config`, as well as using `Match` blocks to apply different rules to specific users, groups, or networks.
+
+////
+
+////
+== Changing the default SSH port
+
+NOTE: This section is a placeholder. It should cover changing the `Port` directive in `sshd_config`, the corresponding SELinux change needed (`semanage port -a -t ssh_port_t -p tcp _port_`), and the impact on firewall rules.
+
+////
+
+
+////
+== Firewall considerations
+
+NOTE: This section is a placeholder. It should cover opening the `ssh` service (or a custom port) in `firewalld`. See xref:firewalld.adoc[Control of System Accessibility by firewalld] for general firewall configuration.
+
+////
+
+////
+== Logging and monitoring login attempts
+
+NOTE: This section is a placeholder. It should cover reviewing SSH login activity with `journalctl -u sshd`, and give an overview of brute-force mitigation tools such as `fail2ban`.
+////
+
+[[s1-openssh-server-additional-resources]]
+== Additional resources
+indexterm:[OpenSSH,additional resources]
+For more information on how to configure an OpenSSH server on Fedora, see the resources listed below.
+
+* `sshd`(8) — The manual page for the `sshd` daemon documents available command line options and provides a complete list of supported configuration files and directories.
+
+* `sshd_config`(5) — The manual page named `sshd_config` provides a full description of available SSH daemon configuration options.
+
+For client-side resources and information about the SSH protocol, see xref:administration/ssh-client.adoc[OpenSSH Client Configuration] and xref:administration/ssh-about.adoc[About SSH and OpenSSH].

modules/ROOT/pages/administration/virtual-bridge.adoc

@@ -0,0 +1,228 @@
+= Set up a virtual bridge 
+Peter Boy; Kevin Fenzi
+:page-authors: {author}, {author_2}
+:revnumber: F44
+:revdate: 2026-04-28
+
+[abstract]
+--
+A bridge establishes a specific communication network between the network interfaces of multiple devices.
+It sorts traffic based on the hardware-related MAC addresses of the interface rather than the environment- and customisation-related IP addresses.
+A virtual bridge implements this functionality as a software application on a server rather than in dedicated hardware.
+In most cases, the devices connected are virtual machines or containers running on the host providing the virtual bridge.
+However, physical interfaces can also be attached.
+--
+
+[NOTE]
+====
+*Status*: Awaiting final review. For now, just take it all with a grain of salt.
+====
+
+
+Basically there are two types of usage.
+
+* The bridge _adds a new interface_ and its own IP address. This option is typically used to create one or more __internal__, secure network(s).
+
+* The bridge __shares an existing interface__ and takes over a physical interface and its IP address from the host. This option is typically used to connect the server along with hosted VMs and maybe other physical connected devices to an _external_ network.
+
+More complex configurations are also possible, such as setting up an internal local network of several servers that use one or more additional physical interfaces. But the basic structure of a virtual bridge remains the same.
+
+
+== Prerequisites
+
+. Fully updated Fedora Server, any version of F33 or newer. F44 is preferred.
+. All physical interfaces are fully configured and operational
+
+
+== Steps to configure a virtual bridge
+
+The bridge needs a unique name to be able to make a connection. It is helpful to use a descriptive name about its function, for example `vbrint` or `vbr1s0` for an internal network or a replacement of enp1s0. 
+
+//If the bridge is intended to replace the internal libvirt network for virtual machines, it might be sensible to keep the default name, `virbr0`.
+
+=== Use case: Adding a new interface and network
+
+We use the name `vbrint` here. In the same step we add an appropriate IP address and network specification.
+
+1. Create a bridge  
++
+[source,console]
+----
+$ sudo nmcli con add con-name vbrint ifname vbrint type bridge stp off
+----
+
+2. Modify network specifications as appropriate.
++
+Specifically, adjust the zone to your requirements. If you specify no zone, the bridge is assigned to the default zone, `FedoraServer`. This is probably not a good idea in the case of an internal, secure network.
++
+[source,console]
+----
+$ sudo nmcli con mod vbrint connection.zone internal \
+ipv4.method manual \
+ipv4.addresses '192.158.xxx.yy/24'  \
+ipv4.gateway '192.158.yyy.zz' \
+ipv4.dns '192.158.yyy.zz' \
+ipv6.method disabled 
+----
++
+If there is no gateway or no DNS configured yet, exclude that part of the configuration.
++
+If you use an IPv6 network you must specify the correct network configuration information, instead of disabling it.
+
+3. Bring the bridge up
++
+[source,console]
+----
+$ sudo nmcli con up vbrint
+----
+
+=== Use case: Replacing an existing interface and network
+
+We use the name vbr1s0 to denote the replacement of the physical interface known as 'enp1s0'. 
+
+1. Create the bridge
++
+[source,console]
+----
+$ sudo nmcli con add type bridge con-name vbr1s0 ifname vbr1s0 stp off
+----
+
+2. Modify network specifications as appropriate.
++
+In this scenario the bridge takes over the __connection__ from the interface `enp1s0`. You will therefore need to import the IP configuration into the bridge. (The connection configuration `enp1s0` will be deleted later; only the device will remain, integrated into the bridge.)
++
+Retrieve the current connection specifications.
++
+[source,console]
+----
+$ sudo nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway,ipv4.dns,ipv6.method,ipv6.addresses,ipv6.gateway,ipv6.dns con show enp1s0 
+ipv4.method:                            auto
+ipv4.addresses:                         --
+ipv4.gateway:                           --
+ipv4.dns:                               --
+ipv6.method:                            auto
+ipv6.addresses:                         --
+ipv6.gateway:                           --
+ipv6.dns:                               --
+----
++
+Set these details in the Bridge (`vir1s0`)
++
+[source,console]
+----
+$ sudo nmcli con mod vbr1s0 
+ipv4.method manual  
+ipv4.addresses '192.158.xxx.yy/24'  \
+ipv4.gateway '192.158.yyy.zz' \
+ipv4.dns '192.158.yyy.zz' \
+ipv6.method manual \
+ipv6.addresses 'uu:vv:ww:xx::yy.zz/64'  \
+ipv6.gateway 'uu:vv:ww:xx::yy.zz' \
+ipv6.dns 'uu:vv:ww:xx::yy.zz' \
+ipv6.addr-gen-mode eui64 \
+connection.zone FedoraServer
+----
++
+Adjust the zone to your requirements. If no zone is specified, the bridge is assigned to the default zone (`FedoraServer`), which is probably OK for an external interface.
+
+3. Add the existing interface as a secondary (`bridge-slave`) to the bridge configuration
++
+[source,console]
+----
+$ sudo nmcli con add type bridge-slave ifname enp1s0 master vbr1s0 con-name vbr1s0-sl
+----
+
+4. Transfer connection 
++
+Disconnect from the current connection named `enp1s0` and enable the bridge. 
+Use command concatenation (`&&`) to avoid losing the connection.
++
+[source,console]
+----
+$ sudo nmcli con down enp1s0 && nmcli con up vbr1s0
+----
++
+NetworkManager replaces the connection `enp1s0`, _not_ the device.
++
+[source,console]
+----
+$ nmcli con
+NAME       UUID                                  TYPE      DEVICE 
+vbr1s0     a4fef065-...-75786a74d495  bridge    vbr1s0 
+vbr1s0-sl  b626163c-...-4c9f6477dd16  ethernet  enp1s0 
+lo         9aef9261-...-7f88d3ad3ecb  loopback  lo  
+
+$ nmcli dev
+DEVICE   TYPE       STATE                   CONNECTION 
+vbr1s0   bridge     connected               vbr1s0     
+enp1s0   ethernet   connected               vbr1s0-sl  
+lo       loopback   connected (externally)  lo         
+----
+
+5. Optionally: Delete the earlier `enp1s0` connection configuration
++
+You can delete the connection to avoid any further confusion.
++
+[source,console]
+----
+$ sudo nmcli con del enp1s0 
+----
+
+=== Add interfaces to the bridge
+
+The virtual machine and containerization tools provide means to select an network interface of the host to connect them to. As an example, when you  xref:virtualization/vm-install-diskimg-fedoraserver.adoc[instantiate a virtual machine image] by using virt-install, you include a line similar to the following in the command:
+[source,]
+----
+ --network bridge=vbrint,model=virtio
+----
+
+Cockpit provides you with a list of available interfaces on the host to connect the virtual machine to.
+
+Physical interfaces must be active. They are added as a `port` to the bridge.
+[source,console]
+----
+$ sudo nmcli con mod enp2s0 master vbr1s0
+----
+
+
+== Follow-up tasks
+
+=== Manage forwarding
+
+If the host has more than one network interface, you will probably want traffic to be automatically forwarded between the interfaces. Check the forwarding status: 
+[source,console]
+----
+$ cat /proc/sys/net/ipv4/ip_forward
+$ cat /proc/sys/net/ipv6/conf/default/forwarding
+----
+In both cases, a value of 1 indicates that automatic forwarding is enabled. Otherwise, it is disabled. This is the default. If necessary, you can enable forwarding immediately and temporarily.
+
+[source,console]
+----
+$ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward 
+$ echo 1 | sudo tee /proc/sys/net/ipv6/conf/all/forwarding
+----
+
+To make these changes permanent, create or edit the file at `/etc/sysctl.d/50-enable-forwarding.conf` by using your preferred editor running under `sudo`:
+
+[source,ini]
+----
+# local customizations
+#
+# enable forwarding for dual stack
+net.ipv4.ip_forward=1
+net.ipv6.conf.all.forwarding=1
+----
+
+=== Install DHCP and DNS
+
+It is often desirable to provide DHCP and, where necessary, DNS within a bridge's subnet. For Fedora servers, xref:administration/dnsmasq.adoc[dnsmasq] is the recommended solution for this.
+
+== Further reading
+
+* https://networkmanager.dev/docs/admins/[Upstream documentation for administrators] (very technical) 
+
+* https://networkmanager.dev/docs/api/latest/nmcli.html[nmcli - command-line tool for controlling NetworkManager] - Overview of `nmcli` options and parameters from the upstream project
+
+* xref:virtualization/installation.adoc[Adding Virtualization Support in Fedora Server] 
+

modules/ROOT/pages/administration/virtual-routing-bridge.adoc

@@ -1,59 +1,67 @@
-= Setting Up a Virtual Routing Bridge (brouter)
-Peter Boy; Kevin Fenzi
-:page-authors: {author}, {author_2}
-:revnumber: F37,F38
-:revdate: 2023-04-18
+= Set up a virtual routing bridge (`brouter`)
+Peter Boy; Kevin Fenzi; Brett Weir
+:page-authors: {author}, {author_2}, {author_3}
+:revnumber: F37-F44
+:revdate: 2026-05-13
 
 [abstract]
 --
-A virtual bridge is a convenient means of providing the virtual machines hosted on a server with access to the public network by sharing its physical interface. More complex configurations are also possible, such as setting up an internal local network of several servers via one or more additional physical interfaces. But the basic structure of a virtual bridge remains the same. 
+A virtual bridge is a software application that implements a communication network between multiple devices on a server, rather than using dedicated hardware.
+A 'routing' bridge is a special type of bridge that forwards traffic based on the IP addresses of the devices.
+This is a bit of a misnomer, as bridges by definition operate based on MAC addresses.
+This type of bridge is used in specific environments where multiple IP addresses share the same MAC address and the receiving device must handle traffic distribution.
+Otherwise, the functionality is the same.
 --
 
-//[NOTE]
-//====
-//**Status:** work in progress
-//====
-
-Basically there a two ways to set up a virtual bridge.
+Basically there are two ways to set up a virtual bridge.
 
 The virtual (plain) bridge::
-Typically, the bridge "captures" the physical interface of the server and assigns the server as a slave device. To attach Virtual Machines, virtual interfaces are added as needed. The bridge operates at layer 2 of the OSI model and uses unique MAC addresses to determine the recipient of a data packet. 
+Typically, the bridge "captures" the physical interface of the server and assigns the server as a secondary device.
+To attach Virtual Machines, virtual interfaces are added as needed.
+The bridge operates at layer 2 of the OSI model and uses unique MAC addresses to determine the recipient of a data packet.
 
 The virtual routing bridge::
-This bridge leaves the host's interface untouched and instead creates an independent bridge to which VMs are attached. It uses the forwarding capability to forward incoming packets that are not destined for the host to the bridge. The destination of data packets is determined locally to the bridge based on IP addresses and routing tables.
+This bridge leaves the host's interface untouched and instead creates an independent bridge to which VMs are attached.
+It uses the forwarding capability to forward incoming packets that are not destined for the host to the bridge.
+The destination of data packets is determined locally to the bridge based on IP addresses and routing tables.
+
+This article deals with the latter variant. 
 
-This article deals with the latter variant.  
 
 == Prerequisites
 
-. Fully updated Fedora Server, any version of F33 or newer, preferrable F38.
-. Installed virtualization support according to the xref:virtualization/installation.adoc[Adding Virtualization Support] guide.
-. Completed preparations for installing VMs according to the xref:virtualization/vm-install-diskimg-fedoraserver.adoc#_provisioning_the_server_vm_image[Provisioning the Server VM image] guide.
+.
+Fully updated Fedora Server, any version of F37 or newer.
+F44 is preferred.
+.
+Installed virtualization support according to the xref:virtualization/installation.adoc[Adding Virtualization Support] guide.
+.
+Completed preparations for installing VMs according to the xref:virtualization/vm-install-diskimg-fedoraserver.adoc#_provisioning_the_server_vm_image[Provisioning the Server VM image] guide.
 . Set up DNS entries for the projected VMs
 
 == Steps to configure a basic routing bridge
 
 1. Check the forwarding configuration
 +
-[source,]
+[source,console]
 ----
- […]# cat /proc/sys/net/ipv4/ip_forward
- […]# cat /proc/sys/net/ipv6/conf/default/forwarding
+$ cat /proc/sys/net/ipv4/ip_forward
+$ cat /proc/sys/net/ipv6/conf/default/forwarding
 ----
 +
-In both cases a value of 1 must be returned. Libvirt will activate IPv4 forwarding, but probably not IPv6. If necessary, activate forwarding temporarily
+In both cases, check that the command returns a value of 1.
+Libvirt activates IPv4 forwarding, but does not always activate IPv6 forwarding.
 +
-[source,]
+[source,console]
 ----
-[…]# echo 1 > /proc/sys/net/ipv4/ip_forward 
-[…]# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
+$ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward 
+$ echo 1 | sudo tee /proc/sys/net/ipv6/conf/all/forwarding
 ----
 +
-The following file must be set up for permanent setup.
+To make these changes permanent, create or edit the file at `/etc/sysctl.d/50-enable-forwarding.conf` by using your preferred editor running under `sudo`:
 +
-[source,]
+[source,ini]
 ----
-[…]# vim /etc/sysctl.d/50-enable-forwarding.conf
 # local customizations
 #
 # enable forwarding for dual stack
@@ -61,124 +69,132 @@ net.ipv4.ip_forward=1
 net.ipv6.conf.all.forwarding=1
 ----
 
-2. Checking the existing interfaces
+2. Check the existing interfaces
 +
-[source,]
+[source,console]
 ----
-[…]# ip a 
+$ ip a 
 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
- … 
-2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> …  state UP group default qlen 1000
-     inet 148.251.152.29/32 scope global noprefixroute enp2s0   
-      … 
-     inet6 2a01:xxx:yyy:zzz::2/64 scope global noprefixroute 
-      … 
-3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> …  state UP group default qlen 1000
-      … 
+ ... 
+2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...  state UP group default qlen 1000
+    inet 148.251.152.29/32 scope global noprefixroute enp2s0   
+      ... 
+    inet6 2a01:4f8:210:512d::2/64 scope global noprefixroute 
+      ... 
+3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...  state UP group default qlen 1000
+      ... 
 ----
 
-3. Adjusting the IPv6 subnet
+3. Adjust the IPv6 subnet
 +
-As the listing indicates, the external IPv6 subnet is a common full /64 network. This must be changed to trigger IPv6 forwarding.
+As the IP address listing indicates, the external IPv6 subnet is the common full /64 network.
+Change the subnet in the IP configuration to trigger IPv6 forwarding.
+Use the original IP address from the IP address listing, but change the /64 to /128 when you modify the connection, as follows.
 +
-[source,]
+[source,console]
 ----
-[…]# nmcli con mod enp2s0 ipv6.addresses '2a01:4f8:210:512d::2/128' 
-[…]# nmcli con up  enp2s0
+$ sudo nmcli con mod enp2s0 ipv6.addresses '2a01:4f8:210:512d::2/128'
+$ sudo nmcli con up enp2s0
 ----
++
+[TIP]
+====
+In the example, the connection name matches the device name. You might need to check the network connection name that the device is attached to, when you run the `nmcli con` commands. For example, run: `nmcli con|grep nmcli enp2s0` to get the names of the network connections that the enp2s0 device is connected to.
+====
 
-4. Creating a routing bridge 
+4. Create a routing bridge 
 +
-The (public) bridge is named vbr1s0, based on the name of the accompanying (public) interface.The IP addresses are the same, but with a different subnet range to trigger forwarding. 
+The (public) bridge is named vbr1s0, based on the name of the accompanying (public) interface. The IP addresses are the same, but with a different subnet range to trigger forwarding. 
 +
-In the listing of interfaces, the IPv4 address is a point-to-point connection. Therefore, the bridge uses a subnet, if any, the range that is also assigned in DNS. If the IPv4 interface is also created as a subnet, the bridge would be created as a p2p connection instead. 
+In the listing of interfaces, the IPv4 address is a point-to-point connection. Therefore, the bridge uses a subnet, if any, the range that is also assigned in DNS. If the IPv4 interface is also created as a subnet, the bridge is created as a p2p connection instead. 
 +
-[source,]
+[source,console]
 ----
-[…]# nmcli con add  con-name vbr1s0  ifname vbr1s0  type bridge  stp off \
+$ sudo nmcli con add  con-name vbr1s0  ifname vbr1s0  type bridge  stp off \
      ipv4.method manual  ipv4.addresses '148.251.152.29/27'  \
      ipv6.method manual ipv6.addresses '2a01:4f8:210:512d::2/64' ipv6.addr-gen-mode eui64
 ----
 +
-No zone is specified! Thus the bridge is assigned to the default zone (FedoraServer), to which the Ethernet interface also belongs by default. This is very important for the firewall permissions!
+Do not specify a zone for the connection so that the bridge is assigned to the default zone, `FedoraServer`, to which the Ethernet interface also belongs by default. 
+Ensuring that the connection belongs to the default zone is very important for the firewall permissions.
 +
-Finally, for IPv4, the routes must be created and the public addresses of all VMs must be listed
+Finally, for IPv4, create the routes and the public addresses of all VMs
 +
-[source,]
+[source,console]
 ----
-[…]# nmcli con mod vbr2s0 +ipv4.routes "148.251.152.49/32"
-[…]# nmcli con mod vbr2s0 +ipv4.routes "148.251.152.52/32"
-[…]# nmcli con mod vbr2s0 +ipv4.routes "148.251.152.56/32"
+$ sudo nmcli con mod vbr2s0 +ipv4.routes "148.251.152.49/32"
+$ sudo nmcli con mod vbr2s0 +ipv4.routes "148.251.152.52/32"
+$ sudo nmcli con mod vbr2s0 +ipv4.routes "148.251.152.56/32"
 ----
 
 5. Double check your entries, especially the IP addresses, to avoid incorrect configuration and time-consuming troubleshooting.
 
 6. Activate the routing bridge
 +
-[source,]
+[source,console]
 ----
-[…]# nmcli con up vbr1s0
+$ sudo nmcli con up vbr1s0
 ----
 
-7. Installing a VM
+7. Install a VM
 +
 Use Cockpit or the command line
 +
-[source,]
+[source,console]
 ----
-[…]# cp /var/lib/libvirt/boot/Fedora-Server-KVM-37-custom.qcow2 /var/lib/libvirt/images/vm-01.qcow2
-[…]# virt-install --name vm-01 --memory 4096 --cpu host --vcpus 4 --graphics none \
+$ sudo cp /var/lib/libvirt/boot/Fedora-Server-KVM-37-custom.qcow2 /var/lib/libvirt/images/vm-01.qcow2
+$ sudo virt-install --name vm-01 --memory 4096 --cpu host --vcpus 4 --graphics none \
 --os-variant fedora37 --import  --disk /var/lib/libvirt/images/vm-01.qcow2,format=qcow2,bus=virtio \
 --network bridge=vbr1s0,model=virtio --network bridge=virbr0,model=virtio 
 ----
 +
-Complete the First Boot Sceen. Leave the network configuration as it is. It is easier to configure it after the first login.
+Complete the First Boot Screen. Leave the network configuration as it is. It is easier to configure it after the first login.
 
 8. Login to the VM and configure the public interface
 +
-[source,]
+[source,console]
 ----
-[…]# nmcli con mod 'Wired connection 1' ipv4.method manual ipv4.addresses '148.251.152.49/32' \
+$ sudo nmcli con mod 'Wired connection 1' ipv4.method manual ipv4.addresses '148.251.152.49/32' \
      ipv4.gateway '148.251.152.29'  ipv4.dns '213.133.98.98' ipv6.method 'manual' \
      ipv6.addresses '2a01:4f8:210:512d::10/64' ipv6.gateway '2a01:4f8:210:512d::2'  connection.id enp1s0
-[…]# nmcli con up  enp1s0
+$ sudo nmcli con up  enp1s0
 ----
 
-9. If exist adjust the internal interface.
+9. If it exists, adjust the internal interface.
 +
 [source,bash]
 ----
-[…]# nmcli con mod 'Wired connection 2'  ipv4.method auto ipv6.method disabled connection.zone 'internal' connection.id enp2s0
-[…]# nmcli con up  enp2s0
+$ sudo nmcli con mod 'Wired connection 2'  ipv4.method auto ipv6.method disabled connection.zone 'internal' connection.id enp2s0
+$ sudo nmcli con up  enp2s0
 ----
 
 10. Optionally reboot to reinitialize everything
 +
 [source,bash]
 ----
-[…]# reboot
+$ sudo reboot
 ----
 
-=== Testing the configuration
+=== Test the configuration
 
 1. Check the forwarding configuration
 +
-[source,]
+[source,console]
 ----
- […]# cat /proc/sys/net/ipv4/ip_forward
- […]# cat /proc/sys/net/ipv6/conf/default/forwarding
+$ cat /proc/sys/net/ipv4/ip_forward
+$ cat /proc/sys/net/ipv6/conf/default/forwarding
 ----
 +
-In both cases a value of 1 must be returned.
+In both cases, check that the command returns a value of 1.
 
 2. Check the host configuration
-SELinux should be in enforcing mode and firewalld active with zone FedoraServer with both the external interface and the virtual bridge attached.
+Ensure that SELinux is in enforcing mode and firewalld active with zone `FedoraServer` with both the external interface and the virtual bridge attached.
 +
 [source,bash]
 ----
- […]# getenforce
- […]# firewall-cmd  --list-all
- […]# firewall-cmd  --get-active-zones
+$ getenforce
+$ sudo firewall-cmd  --list-all
+$ sudo firewall-cmd  --get-active-zones
 ----
 
 3. Check IPv6

modules/ROOT/pages/containerization/index.adoc

@@ -1,20 +1,19 @@
 = Containerization
 Peter Boy
+:revnumber: F34-F44
 :page-authors: {author}
-:revnumber: F34-F37
-:revdate: 2022-11-05
-// :revremark: a new beginning
+:revdate: 2026-05-17
 :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.   
+For several years, "Container" has been on everyone's lips. It is a prominent subject of public discussion. 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. It did not 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.
+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.
+A common feature of all container systems is the sharing of the host kernel and the use of kernel capabilities (e.g. cgroups) 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.
 
@@ -35,11 +34,11 @@ Podman is *natively supported by Fedora Server* and the recommended solution for
 Its characteristics are
 
 * Application container
-* Dependent on a daemon with ROOT privileges
+* Dependent on a daemon, historically with ROOT privileges. Later a rootless mode was added.
 * 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. 
+Docker releases its own Community Edition for various distributions. Therefore, there is *no native support* for Fedora Server, but a *vendor repository* is maintained for Fedora. 
 
 === LXC (libvirt)
 
@@ -53,7 +52,7 @@ Its characteristics are
 
 Libvirt LXC is *natively supported by Fedora Server* (via libvirt as default virtualization tool)
 
-=== LXC (linux containers)
+=== LXC (Linux containers)
 
 Its characteristics are
 
@@ -62,9 +61,9 @@ Its characteristics are
 * 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)
+Linux Container's LXC is *natively supported by Fedora Server* 
 
-=== LXD (linux containers)
+=== LXD (Linux containers)
 
 Its characteristics are
 
@@ -73,21 +72,20 @@ Its characteristics are
 * 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.
+LXD is *not natively supported* by Fedora Server, but there is a *COPR project* available, and 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)
+* System container as a "lightweight virtual machine"  and also configurable as an 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
+=== Linux-Vserver
 
 It requires a modified kernel and is *not supported by Fedora Server*
 

modules/ROOT/pages/containerization/systemd-nspawn-setup.adoc

@@ -1,169 +1,138 @@
-= Setting up Systemd Nspawn Container
+= Setting up a `systemd-nspawn` Fedora container
 Peter Boy; Jan Kuparinen
+:revnumber: F43-F44
 :page-authors: {author}, {author_2}
-:revnumber: F34-F36
-:revdate: 2022-07-05
-// :revremark: a new beginning
+:revdate: 2026-07-29
 :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.
+[abstract]
+The `systemd-nspawn` container runtime is part of the systemd system software. It is exceptionally lightweight, flexible, and integrates deeply with systemd for seamless service management. This article covers how to set up a Fedora container.
 
-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. 
+[NOTE]
+====
+*Status*: Awaiting final review. For now, just take it all with a grain of salt.
+====
 
-But of course a container can also be operated with other variations of a network connection or even without a network connection at all. 
+The only prerequisite is a fully installed basic Fedora Server system. 
 
-== 1. Setting up the nspawn container infrastructure
+== 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.
+The `systemd-nspawn` tools like `machinectl` look for system-wide usable containers in `/var/lib/machines`. This directory is also created during the installation of the program 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.
+Following the Fedora server storage scheme, create an appropriate storage where to store all of the system-wide `nspawn` containers. Depending on your choice of storage concept, either create a resource at `/var/lib/machines` or let the installation program create the default subdirectory.
++
+If you created this directory yourself, make sure that the correct SELinux labels are in place, that ownership is set to root, and that accessibility is restricted to root only.
++
+[source,console]
+----
+# restorecon  -vFr /var/lib/machines
+# chown root:root /var/lib/machines
+# chmod 700 /var/lib/machines 
+----
+2. *Install the software*
 +
 [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 
+# dnf install systemd-container 
+# machinectl
+No machines.
 ----
-2. *Check and, if necessary, correct the SELinux labels*
+3. *Add the host configuration directory for `nspawn`*
 +
-Ensure that the directory belongs to root and can only be accessed by root (should be done by the installer).
-+
-[source,]
+[source,console]
 ----
-[…]# 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 
+# mkdir /etc/systemd/nspawn 
 ----
 
-== 2. Creating a nspawn container
+== 2. Create an `nspawn` system container
 
-=== 2.1 Creating a container directory tree
+In this context, the term "system container" specifically refers to a container that has a complete init system and, in particular, its own network connection. It therefore operates in a similar way to a VM, albeit without its own kernel (lightweight VM), and is otherwise largely independent of the host machine.
 
-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.
+=== 2.1 Setting up a system containers infrastructure
 
-1. Creating a BTRFS subvolume with the name of the container
+. Creating a container subdirectory
 +
-[source,]
-----
- […]# cd /var/lib/machines 
- […]# btrfs subvolume create {ctname}
-----
-2. Creating a minimal container directory tree
+The `systemd-nspawn` tooling expects a subdirectory, using its name as both the container name and the default hostname.
 +
-**__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
-   <insert>
-   [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.
+Create a subdirectory according your storage concept.
 
-=== 2.2 Configuration and commissioning of a system container
+. Create a minimal 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.
++
+[source,console]
+----
+# dnf install dbus dhcp-client dnf fedora-release glibc glibc-langpack-en iputils \
+less ncurses passwd systemd systemd-networkd systemd-resolved util-linux \
+vim-default-editor --releasever=44  --setopt=install_weak_deps=False \
+--best --use-host-config --installroot=/var/lib/machines/{CTNAME}
+----
++
+Fedora 44 installs 174 packages (270M) and allocates 527M in the file system.
++
+Optionally, you may add your local language package
++
+[source,console]
+----
+# dnf --releasever=44 --best --setopt=install_weak_deps=False  --use-host-config --installroot=/var/lib/machines/{CTNAME} install glibc-langpack-{YOUR_LOCALE}
+----
++
+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 safely ignore the message.
 
-1. Setting the password for root
+
+=== 2.2 System container configuration and commissioning
+
+1. *Setting the password for root*
 +
 This requires temporarily setting SELinux to permissive, otherwise passwd will not make any changes.
 +
-[source,]
+[source,console]
 ----
-  […]# setenforce 0 
-  […]# systemd-nspawn -D /var/lib/machines/{ctname}   passwd
-  […]# setenforce 1  
+# 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):
+In the same way you can create any other account. If you want to disallow root create a administrative account instead.
 +
-[source,]
+[source,console]
 ----
-  […]# vim /etc/systemd/nspawn/{ctname}.nspawn
-  (insert)
+# setenforce 0 
+# systemd-nspawn -D /var/lib/machines/{ctname}   adduser -g wheel <USERNAME>
+# setenforce 1  
+----
+2. *Configuring host to provision network interfaces*
++
+If you need a connection to an internal, protected network is needed (e.g. provided by libvirt) replace the host's interface by a xref:administration/virtual-bridge.adoc#_use_case_replacing_an_existing_interface_and_network[virtual bridge] if not already done, and assign its interface name to the container resources in the host:
++
+[source,console]
+----
+# vim /etc/systemd/nspawn/{ctname}.nspawn
+
   [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).
+If a connection to an external public network is required as well, two corresponding interfaces must be provided. For simplicity's sake, use a Mac VLAN on the host interface instead of a virtual bridge. (replace the host interface names accordingly).
 +
-[source,]
+[source,console]
 ----
-  […]# vim /etc/systemd/nspawn/{ctname}.nspawn
+# 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,]
+If the container is not intended for use with an internal interface, leave it off.
+
+3. *Optional: Configure the connection to the internal network within the container*
++
+[source,console]
 ----
-[…]# vim /var/lib/machines/{ctname}/etc/systemd/network/20-host0.network
+# vim /var/lib/machines/{ctname}/etc/systemd/network/20-host0.network
  (insert)
  # {ctname}.localnet
  # internal network interface via bridge
@@ -182,15 +151,15 @@ If a connection to the external, public network is also required, two correspond
 +
 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
+4. *Optional: Configure a 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.
+In this case, the gateway entry must be commented out in the configuration of the internal network, as mentioned in item 3.
 +
-[source,]
+[source,console]
 ----
- […]# vim /var/lib/machinec/{ctname}/etc/systemd/network/10-mv.network
+# vim /var/lib/machinec/{ctname}/etc/systemd/network/10-mv.network
   (insert)
-  # {ctname}.sowi.uni-bremen.de
+  # {ctname}.example.org
   # public interface via mac-vlan
   # static configuration, no dhcp available
   [Match]
@@ -203,8 +172,8 @@ In this case, the gateway entry _must_ be commented _out_ in the configuration o
   DHCP=no
 
   # IPv4 static configuration, no DHCP configured!
-  Address=134.102.3.zz/27
-  Gateway=134.102.3.30
+  Address=www.xxx.yyy.zz/rr
+  Gateway=www.xxx.yyy.vv
   # without Destination specification 
   # treated as default!
   #Destination=
@@ -222,50 +191,50 @@ In this case, the gateway entry _must_ be commented _out_ in the configuration o
   UseAutonomousPrefix=False 
 ----
 +
-Don't forget to adjust interface names and IP addresses accordingly!
+Do not forget to adjust interface names and IP addresses accordingly!
 
-5. Boot the container and log in
+5. *Boot the container and log in*
 +
 Check if container boots without error messages
 +
-[source,]
+[source,console]
 ----
- […]# systemd-nspawn -D /var/lib/machines/{ctname}  -b
+# 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
+6. *Checking the status of systemd-networkd*
 +
 If inactive, activate and start the service.
 +
-[source,]
+[source,console]
 ----
- […]# systemctl  status  systemd-networkd
+# systemctl  status  systemd-networkd
  … 
- […]# systemctl  enable  systemd-networkd
- […]# systemctl  start   systemd-networkd 
- […]# systemctl  status  systemd-networkd 
+# systemctl  enable  systemd-networkd
+# systemctl  start   systemd-networkd 
+# systemctl  status  systemd-networkd 
 ----
-7. Check if all network interfaces are available
+7. *Check if all network interfaces are available*
 +
-[source,]
+[source,console]
 ----
- […]# ip a
+# ip a
 ----
-8. Check for correct routing
+8. *Check for correct routing*
 +
-[source,]
+[source,console]
 ----
- […]# ip route show 
+# ip route show 
 ----
-9. Configure default DNS search path
+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:
+Specify a search domain (typically your internal domain, like `example.lan`). When you look up a short hostname (e.g., server1), the system appends this domain automatically, forming server1.example.lan for DNS resolution. Update the config file accordingly.
 +
-[source,]
+[source,console]
 ----
- […]# vim /etc/systemd/resolved.conf 
+# vim /etc/systemd/resolved.conf 
  
  [Resolve]
  ...
@@ -277,73 +246,110 @@ Specify a search domain to appended to a unary hostname without domain part, usu
  #DNSSEC=no
  ... 
 ----
-10. Check if name resolution is configured correctly
+10. *Check if name resolution is configured correctly*
 +
-[source,]
+[source,console]
 ----
- […]# ls  -al  /etc/resolv.conf
+# 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,]
+[source,console]
 ----
- […]# cd  /etc
- […]# rm  -f  resolv.conf
- […]# ln  -s  ../run/systemd/resolve/stub-resolv.conf  resolv.conf
- […]# ls  -al  /etc/resolv.conf
- […]# cd
+# 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,]
+[source,console]
 ----
-  […]# systemctl status systemd-resolved 
+# systemctl status systemd-resolved 
 ----
 +
 Activate the service if necessary.
 +
-[source,]
+[source,console]
 ----
-  […]# systemctl enable systemd-resolved
+# systemctl enable systemd-resolved
 ----
 
-11. Set the intended hostname
+11. *Set the intended hostname*
 +
-[source,]
+[source,console]
 ----
- […]# hostnamectl
- […]# hostnamectl set-hostname <FQDN>
+# hostnamectl
+# hostnamectl set-hostname <FQDN>
 ----
-12. Terminate the container
+12. *Terminate the container*
 +
-[source,]
+[source,console]
 ----
- […]# <CTRL>+]]]
+# <CTRL>+]]]
  Container <CTNAME> terminated by signal KILL.
 ----
 
-=== 2.2 Configuration and commissioning of an application container
+== 3. Create an `nspawn` application container
 
-1. Setting the password for root
+In this context, the term "application container" specifically refers to the way in which the container shares the host's network interfaces and possibly other resources, and may have either a reduced  or a complete init system. It thus behaves like a standard application in a sandbox on the host.
+
+=== 3.1 Setting up an application containers infrastructure
+
+. *Creating a container subdirectory*
++
+The `systemd-nspawn` tooling expects a subdirectory, using its name as both the container name and the default hostname.
++
+Create a subdirectory according your storage concept.
+
+. *Create a minimal 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.
++
+[source,console]
+----
+# dnf install dbus dhcp-client dnf fedora-release glibc glibc-langpack-en iputils \
+less ncurses passwd util-linux \
+vim-default-editor --releasever=44  --setopt=install_weak_deps=False \
+--best --use-host-config --installroot=/var/lib/machines/{CTNAME}
+----
++
+Fedora 44 installs 147 packages (221M) and allocates 5xxM in the file system.
++
+Optionally, you may add your local language package
++
+[source,console]
+----
+# dnf --releasever=44 --best --setopt=install_weak_deps=False  --use-host-config --installroot=/var/lib/machines/{CTNAME} install glibc-langpack-{YOUR_LOCALE}
+----
++
+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 safely ignore the message.
+
+
+=== 3.2 Application container configuration and commissioning
+
+1. *Setting the password for root*
 +
 This requires temporarily setting SELinux to permissive, otherwise passwd will not make any changes.
 +
-[source,]
+[source,console]
 ----
-  […]# setenforce 0 
-  […]# systemd-nspawn -D /var/lib/machines/{ctname}   passwd
-  […]# setenforce 1  
+# setenforce 0 
+# systemd-nspawn -D /var/lib/machines/{ctname}   passwd
+# setenforce 1  
 ----
-2. Configuration of container properties
+
+2. *Adjust container Host's runtime*
 +
 Specifying private user configuration and shared network access.
 +
-[source,]
+[source,console]
 ----
-  […]# vim /etc/systemd/nspawn/{ctname}.nspawn
+# vim /etc/systemd/nspawn/{ctname}.nspawn
   (insert)
   [Exec]
   PrivateUsers=false
@@ -351,99 +357,210 @@ Specifying private user configuration and shared network access.
   Private=off
   VirtualEthernet=false
 ----
-3. Boot the container and log in
+
+
+3. *Boot the container and log in*
 +
 Check if container boots without error messages
 +
-[source,]
+[source,console]
 ----
- […]# systemd-nspawn -b -D /var/lib/machines/{ctname}
+# 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
+
+4. *Check if all network interfaces are available*
 +
-If active, deactivate the service.
-+
-[source,]
+[source,console]
 ----
- […]# 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 
+# ip a
 ----
 +
-If file /etc/resolv.conf is a link, remove it.
+You should see the same interfaces and IP addresses as on the host system.
+
+5. *Set the intended hostname*
 +
-[source,]
+[source,console]
 ----
- […]# rm /etc/resolv.conf
+# hostnamectl
+# hostnamectl set-hostname <FQDN>
 ----
+
+6. *Optional: modify the terminal prompt* 
 +
-Create (or edit an existing) file /etc/resolv.conf
+Include the name of the host to get an indicator for the container
 +
-[source,]
+[source,console]
 ----
- […]# vim /etc/resolv.conf
+[…]# vim /etc/profile.d/custom.sh 
+#Adjust shell prompt to include container name
+[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\h-mail \W]\\$ "
+----
+
+7. *Check name resolution*
++
+[source,console]
+----
+# ping fedoraproject.org 
+# ping {MY_HOST_NAME}
+----
+
+8. *Check file /etc/resolv.conf*
++
+[source,console]
+----
+# vim /etc/resolv.conf
  
 nameserver 127.0.0.53
 options edns0 trust-ad
 search <YOUR_DOMAIN>
 ----
-5. Check if all network interfaces are available
+
+9. *Terminate the container*
 +
-[source,]
+[source,console]
 ----
- […]# 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 <FQDN>
-----
-8. Terminate the container
-+
-[source,]
-----
- […]# <CTRL>+]]]
+# <CTRL>+]]]
  Container <CTNAME> terminated by signal KILL.
 ----
 
-== 3. Starting the container as a system service for productive operation
+== 4. Starting a container as a system service for productive operation
 
-1. Booting the container using systemctl
+1. *Booting the container using systemctl*
 +
 In this step, a separate UID/GID range is automatically created for the container.
 +
-[source,]
+[source,console]
 ----
- […]# systemctl  enable systemd-nspawn@{ctname}
- […]# systemctl  start  systemd-nspawn@{ctname}
- […]# systemctl  status systemd-nspawn@{ctname} 
+# systemctl  enable systemd-nspawn@{ctname}
+# systemctl  start  systemd-nspawn@{ctname}
+# systemctl  status systemd-nspawn@{ctname} 
+----
+
+2. *Log in to the container*
++
+[source,console]
+----
+# machinectl  login  {ctname} 
 ----
 +
+Alternatively
++
+[source,console]
+----
+# machinectl  shell  {ctname} 
+----
++
+The latter provides you with a root shell.
+
+3. *Completing and finalizing the container configuration*
++
+Within the container, perform other designated software installations and customizations.
+
+4. *Logging off from the container*
++
+After finishing all further work inside the container press <ctrl>]]] ( Mac: <ctrl><alt>666) to exit the container.
+
+5. *Optionally: Autostart of the container at hosts boot up*
++
+The well-known 'systemctl enable ...' does not work here due to coordination issues of NetworkManager and systemd and network interception of libvirt. There are 2 ways to autostart a container:
+
+a. __(Re-)Activate rc.local__
++
+* Create a rc.local file
++
+[source,console]
+----
+# vim /etc/rc.d/rc.local
+  #!/usr/bin/bash
+
+  systemctl  start  systemd-nspawn@<CONTAINER01>
+  systemctl  start  systemd-nspawn@<CONTAINER01>
+  systemctl  start  systemd-nspawn@<CONTAINERnn>
+  
+# chmod ug+x /etc/rc.d/rc.local 
+----
+* Create systemd Services for rc.local
++
+[source,console]
+----
+# mkdir  /etc/systemd/system/rc-local.service.d/
+# vim    /etc/systemd/system/rc-local.service.d/network.conf
+  # /etc/systemd/system/rc-local.service.d/network.conf
+  [Unit]
+  Wants=network-online.target
+  After=network-online.target 
+----
+* Activate systemd rc-local service
++
+[source,console]
+----
+# /usr/lib/systemd/system-generators/systemd-rc-local-generator    /run/systemd/generator 
+----
++
+After every change to the rc.local file, you must run systemd-rc-local-generator again (specifying the full path and the argument!).
+
+b. __Using a systemd timer__
++
+* Create a bash script to start each container
++
+[source,console]
+----
+# vim /var/lib/machines/autostart.sh
+  #!/usr/bin/bash
+
+  systemctl  start  systemd-nspawn@<CONTAINER01>
+  systemctl  start  systemd-nspawn@<CONTAINER01>
+  systemctl  start  systemd-nspawn@<CONTAINERnn>
+  
+# chmod ug+x /var/lib/machines/autostart.sh 
+----
+* Create a systemd service to execute the script
++
+[source,console]
+----
+# vim /etc/systemd/system/autostart-nspawn.service
+  [Unit]
+  Description=Autostart nspawn containers at boot
+  After=network.target
+
+  [Service]
+  Type=oneshot
+  User=root
+  ExecStart/var/lib/machines/autostart.sh
+----
+* Create a systemd timer
++
+[source,console]
+----
+# vim /etc/systemd/system/autostart-nspawn.timer
+  [Unit]
+  Description=Timer for autostart nspawn containers at boot
+
+  [timer]
+  # Starts 5 minutes after booten
+  OnBootSec=5min
+  Unit=autostart-nspawn.service
+ 
+  [Install]
+  WantedBy=timer.target
+----
+* Activate the timer
++
+[source,console]
+----
+# systemctl daemon-reload
+# systemctl enable --now autostart-nspawn.timer
+----
+
+== 5. Troubleshooting
+
+=== 5.1 SELinux
+
 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:
 +
@@ -451,174 +568,21 @@ On first boot after installing systemd-container, a SELinux bug currently (Fedor
 +
 The proposed solution is roughly as follows:
 +
-[source,]
+[source,console]
 ----
-[…]# ausearch -c 'systemd-machine' --raw | audit2allow -M my-systemdmachine
-[…]# semodule -i my-systemdmachine.pp
+# 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 <ctrl>]]] ( Mac: <ctrl><alt>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
+=== 5.2 Error message dev-hugepages
 
 You will find message such as
-[source,]
+[source,console]
 ----
-dev-hugepages.mount: Mount process exited, code=exited, status=32/n/a
+dev-hugepages.mount: Mount process exited, code=exited, statupdateus=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. 
@@ -627,16 +591,4 @@ DFN installs this by default, but it is not applicable inside a container. It is
 
 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.
 

modules/ROOT/pages/index.adoc

@@ -1,13 +1,12 @@
 = Fedora Server Documentation
-Peter Boy; Jan Kuparinen; Peter W. Smith
-:page-authors: {author}, {author_2}, {author_3}
-:revnumber: F38-F43
-:revdate: 2025-10-28
-// :revremark: 
+Peter Boy; Jan Kuparinen
+:revnumber: F38-F44
+:page-authors: {author}, {author_2}
+:revdate: 2026-04-28
 
-image::Logo_server2.png[Server] 
+image::logo_server2.png[Server] 
 
-== Our Mission
+== Our mission
 
 *As a user, you gain the opportunity to use the server of the future right now.*
 
@@ -19,79 +18,7 @@ It is based on the latest technology and as such, brings the most modern environ
 Fedora Server is a platform for developers and system integrators, providing an implementation of the latest server technology for further evaluation and practical use.
 
 
-== What You Will Find Here
-
-- Server installation and administration guides
-+
-You find information about installation and basic system administration supplementing the general Fedora Installation Guide and System Administration Guide. Several other sections cover specific Fedora Server Edition related options and solutions. This includes virtualisation and containerization in particular.
-
-- Example Use Cases
-+
-Users describe how they use Fedora Server for a wide variety of tasks as well as solutions for special tasks. Hopefully, this will provide inspiration for your own assignments.
-
-- Tutorials
-+
-Detailed step-by-step instructions are given for various typical areas of application. The tutorials are intended to enable not only experienced system administrators but also inexperienced users to safely install and configure the system.
-
-
-- People, policies, and working methods
-
-
-=== Updating to Fedora 43
-
-The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine. 
-
-Before you start the process you should use `df -h` to check the root file system. You need about 2-3 gb free space depending on your installation to store the rpm packages of the F43 release. 
-
-If you use postgresql, please note that the major version has increased from 16.9 to 18.0. This means that the database tables need to be adapted.
-
-[CAUTION]
-==== 
-The update will break Postgresql runtime and requires extra effort! 
-====
-
-Fedora 43 updates Postgresql from version 16 directly to version 18, skipping one major version. However, the update utility cannot process data from version 16. Therefore, perform the following steps:
-
-1. Verify that Postgresql failed to start and perform a backup.
-+
-[source]
-----
-[…]$ systemctl status postgresql
-[…]$ sudo tar -cvJf /var/lib/pgsql/backups/postgres16-bak.tzx  /var/lib/pgsql/data/ 
-----
-2. Replace installed version 18 by version 17 und use it to update your database
-+
-[source]
-----
-[…]$ sudo dnf install postgresql17-server postgresql17-upgrade --allowerasing 
-[…]$ sudo -u postgres postgresql-upgrade /var/lib/pgsql/data
-----
-3. Stop postgres and activate checksums which is a new default in version 18
-+
-[source]
-----
-[…]$ systemctl stop postgresql
-[…]$ sudo -u postgres pg_checksums -D /var/lib/pgsql/data -e -P 
-----
-4. Reinstall version 18 and update the data again
-+
-[source]
-----
-[…]$ mv /var/lib/pgsql/data_old  /var/lib/pgsql/data_old_16
-[…]$ sudo dnf install postgresql-server postgresql-upgrade --allowerasing
-[…]$ sudo -u postgres postgresql-upgrade /var/lib/pgsql/data
-----
-5. Start postgresql und check if everything works again
-+
-[source]
-----
-[…]$ sudo systemctl start postgresql
-[…]$ sudo systemctl status postgresql
-----
-6. Execute the maintenance steps as recommended by the update program and fix collation issues if exist.
-7. Done
-
-== Why Use Fedora Server
+== Why use Fedora Server
 
 Fedora Server Edition offers users and system administrators several attractive features:
 
@@ -112,17 +39,40 @@ Fedora Server Edition offers users and system administrators several attractive
 * *Developers will feel right at home*: Fedora Server is an excellent development environment for the next generation server as well as application software with the latest software versions available.
 
 
-== What's in the Pipeline?
+== What you will find here
+
+- Server installation and administration guides
++
+You find information about installation and basic system administration supplementing the general Fedora Installation Guide and System Administration Guide. Several other sections cover specific Fedora Server Edition related options and solutions. This includes virtualisation and containerization in particular.
+
+- Example Use Cases
++
+Users describe how they use Fedora Server for a wide variety of tasks as well as solutions for special tasks. Hopefully, this will provide inspiration for your own assignments.
+
+- Tutorials
++
+Detailed step-by-step instructions are given for various typical areas of application. The tutorials are intended to enable not only experienced system administrators but also inexperienced users to safely install and configure the system.
+
+
+- People, policies, and working methods
+
+
+[updating-f43]
+== Updating to Fedora 44
+
+We are not aware of any issue when upgrading from Fedora 43. 
+
+== What is in the pipeline?
 
 Currently, several projects are in development:
 
-- Further Improvements to the documentation 
+- We started a "home server spin-off" to better support the many domestic usages we got aware of. 
 - Facilitation of the deployment of key services by combining rpm and Ansible
 
 
-== You Are Welcome to Contribute
+== You are welcome to contribute
 
-You don't have to be a programmer, a developer or a technical nerd to contribute to the development of Fedora Server. We are especially interested in feedback from our users and potential new users.
+You do not have to be a programmer, a developer or a technical nerd to contribute to the development of Fedora Server. We are especially interested in feedback from our users and potential new users.
 
 - Please, tell us about your usage of Fedora Server
 - Tell us about problems you found and how you resolved it
@@ -139,19 +89,73 @@ For additional information refer to https://docs.fedoraproject.org/en-US/fedora-
 
 == About previous versions of Fedora Server
 
+[updating-f43]
+=== Updating to Fedora 43
+
+The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine. 
+
+Before you start the process you should use `df -h` to check the root file system. You need about 2-3 GB free space depending on your installation to store the rpm packages of the F43 release. 
+
+If you use postgresql, please note that the major version has increased from 16.9 to 18.0. This means that the database tables need to be adapted.
+
+[CAUTION]
+==== 
+The update will break Postgresql runtime and requires extra effort! 
+====
+
+Fedora 43 updates Postgresql from version 16 directly to version 18, skipping one major version. However, the update utility cannot process data from version 16. Therefore, perform the following steps:
+
+1. Verify that Postgresql failed to start and perform a backup.
++
+[source]
+----
+$ systemctl status postgresql
+$ sudo tar -cvJf /var/lib/pgsql/backups/postgres16-bak.tzx  /var/lib/pgsql/data/ 
+----
+2. Replace installed version 18 by version 17 and use it to update your database
++
+[source]
+----
+$ sudo dnf install postgresql17-server postgresql17-upgrade --allowerasing 
+$ sudo -u postgres postgresql-upgrade /var/lib/pgsql/data
+----
+3. Stop postgres and activate checksums which is a new default in version 18
++
+[source]
+----
+$ systemctl stop postgresql
+$ sudo -u postgres pg_checksums -D /var/lib/pgsql/data -e -P 
+----
+4. Reinstall version 18 and update the data again
++
+[source]
+----
+$ mv /var/lib/pgsql/data_old  /var/lib/pgsql/data_old_16
+$ sudo dnf install postgresql-server postgresql-upgrade --allowerasing
+$ sudo -u postgres postgresql-upgrade /var/lib/pgsql/data
+----
+5. Start postgresql and check if everything is working again
++
+[source]
+----
+$ sudo systemctl start postgresql
+$ sudo systemctl status postgresql
+----
+6. Execute the maintenance steps as recommended by the update program and fix collation issues if exist.
+7. Done
 === Updating to Fedora 41
 
 The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine. 
 
-Before you start the process you should use `df -h` to check the root file system. You need about 2-3 gb free space depending on your installation to store the rpm packages of the F41 release. 
+Before you start the process you should use `df -h` to check the root file system. You need about 2-3 GB free space depending on your installation to store the rpm packages of the F41 release. 
 
-Please note that for an interactive remote installation, you must also add the parameter nomodeset to the kernel command line. For more information, see the corresponding installation instructions.
+Please note that for an interactive remote installation, you must also add the parameter `nomodeset` to the kernel command line. For more information, see the corresponding installation instructions.
 
 === Updating to Fedora 40
 
 The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine. 
 
-Before you start the process you should use `df -h` to check the root file system. You need about 2-3 gb free space depending on your installation to store the rpm packages of the F40 release. 
+Before you start the process you should use `df -h` to check the root file system. You need about 2-3 GB free space depending on your installation to store the rpm packages of the F40 release. 
 
 Note that the configuration of LVM has changed. The CLI commands now only take into account partitions that are listed in `lvmdevices`. 
 
@@ -159,26 +163,26 @@ If you use postgresql, please note that the major version has increased from 15.
 
 === Installing Fedora 39
 
-There is an issue with the aarch64 SBC installation image. You can't use a Fedora Server Edition host to transfer the distribution image onto a SD card. Use Fedora Workstation or any other non-LVM system.
+There is an issue with the aarch64 SBC installation image. You cannot use a Fedora Server Edition host to transfer the distribution image onto a SD card. Use Fedora Workstation or any other non-LVM system.
 
 === Updating to Fedora 39
 
 The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine. 
 
-Before you start the process you should use `df -h` to check the root file system. You need about 2-3 gb free space depending on your installation to store the rpm packages of the F39 release. 
+Before you start the process you should use `df -h` to check the root file system. You need about 2-3 GB free space depending on your installation to store the rpm packages of the F39 release. 
 
 
 === Updating to Fedora 38
 
 The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine. 
 
-Before you start the process you should use `df -h` to check the root file system. You need about 2-3 gb free space depending on your installation to store the rpm packages of the F38 release. 
+Before you start the process you should use `df -h` to check the root file system. You need about 2-3 GB free space depending on your installation to store the rpm packages of the F38 release. 
 
 === Updating to Fedora 37
 
 Upgrading using the dnf upgrade process is fully tested and supported. No issues were found during the release tests.
 
-With release 37 we additionally deliver a Fedora Server KVM virtual disk image. Now it's much easier to provision a Fedora server with virtual machines.
+With release 37 we additionally deliver a Fedora Server KVM virtual disk image. Now it is much easier to provision a Fedora server with virtual machines.
 
 The Fedora KVM image resembles a standard Fedora Server installation as close as possible. An administrator should not detect any differences in the work routines - except for hardware specific actions, of course. For details see the supplemented user documentation xref:virtualization/vm-install-diskimg-fedoraserver.adoc[Creating a virtual machine using Fedora Server Edition disk image].
 

modules/ROOT/pages/installation/index.adoc

@@ -1,8 +1,8 @@
-= Fedora Server Installation Guide
+= Fedora Server installation guide
 Peter Boy; Kevin Fenzi; Jan Kuparinen
-:revnumber: F37-F41
-:revdate: 2024-10-28
+:revnumber: F37-F44
 :page-authors: {author}, {author_2}, {author_3}
+:revdate: 2026-04-28
 :page-aliases: installation-an-introduction.adoc
 
 //[NOTE]
@@ -11,11 +11,11 @@ Peter Boy; Kevin Fenzi; Jan Kuparinen
 // ====
 
 [abstract]
-A good and sustaining server installation benefits from some plannings ahead. As the saying goes, planning ahead will substitute for many a mishap. This chapter and its subchapters cover general planning principles and focus on a _bare metal_ installation. The implementation of the principles for a virtual machine covers the chapter __Virtualization__.
+A good and sustainable server installation benefits from some planning ahead. As the saying goes, planning ahead averts many mishaps. This chapter and its subchapters cover general planning principles and focus on a _bare metal_ installation. The implementation of the principles for a virtual machine covers the chapter __Virtualization__.
 
 Fedora Server Edition uses the Fedora installation program, Anaconda, as several other editions and spins.
 
-While Fedora Server Edition uses the same rpm package repository as all Fedora editions, the composition of the packages and especially the defaults of the runtime environment are different and more tailored to a server requirements. The following paragraphs describe some of the most important ones. Of course, the administrator can override any of them.
+While Fedora Server Edition uses the same RPM package repository as all other Fedora editions, its package composition and the defaults of the runtime environment are tailored to server requirements. The following paragraphs describe some of the most important ones. Of course, the administrator can override any of them.
 
 The installation planning depends on the details of the target environment. Anaconda can install on 'bare metal' directly on server hardware as well as in a virtual environment on a virtual machine (VM). While both targets are similar in many ways, they also differ in key technical details. As an example, on both targets, the storage organization is a very important planning item, but on a virtual machine the system administrator does not need to worry about a RAID system.
 
@@ -26,13 +26,13 @@ Having done various decisions and some preparations, the installation itself is
 == Planning ahead
 
 
-=== Minimum requirements 
+=== Minimum requirements
 
-The question of the minimum requirements is always raised, even though it is obvious to anybody that it depends entirely on the deployment plan.
+The minimum requirements are often questioned, though they depend on the deployment plan.
 
-Nevertheless, technically, you can run a default Fedora Server on a storage space of about 5 GiB. The installed system occupies about 2.5 GiB. Of course,  such a server would hardly be useful for anything. The smallest disc currently available for purchase is 64 GiB. With that, you could satisfactorily run a small to medium server for web and mail services. For virtual machines, we currently use 40 GiB as default. 
+Nevertheless, technically, you can run a default Fedora Server on a storage space of about 5 GiB. The installed system occupies about 2.5 GiB. Of course, such a server would have limited usefulness. The smallest disk currently available for purchase is 64 GiB. With that, you could satisfactorily run a small to medium server for web and mail services. For virtual machines, we currently use 40 GiB as default. 
 
-Again, from a purely technical point of view, a standard Fedora server would get by with about 1 GiB of memory. Again, without being able to do anything useful. The smallest memory chip currently available is 4GiB. In at least a dual channel server system you need 2, so you have at least 8 GiB of RAM. For a small to medium sized server for web and mail services, this is perfectly adequate. 
+Again, from a purely technical point of view, a standard Fedora server would get by with about 1 GiB of memory. Again, without being able to do anything useful. The smallest memory chip currently available is 4GiB. In a dual-channel server system, you need two modules, providing at least 8 GiB of RAM. For a small to medium sized server for web and mail services, this is perfectly adequate. 
 
 So, with today's smallest possible purchasable hardware, a Fedora server can be run perfectly for a small to medium deployment.
 
@@ -49,11 +49,11 @@ The Fedora Server Edition working group has also discussed this topic and agreed
 
 A new Fedora installation creates a (modern) GPT partition table by default.
 
-On a _BIOSboot_ machine, Anaconda creates at first a small (1 MiB) ```BIOS boot``` system partition on the first drive. It stores the second stage bootloader which is required by GNU/Grub. Subsequently, it creates a ``/boot``` partition of 1 GiB. It contains all the files necessary for booting Linux, especially the kernel. The remaining area is completely filled with a third partition containing one large volume group (LVM VG) named `fedora` by default. You end up with 3 primary partitions on the hard disk that use all the available space. 
+On a _BIOSboot_ machine, Anaconda creates at first a small (1 MiB) `BIOS boot` system partition on the first drive. It stores the second stage bootloader which is required by GNU/Grub. Subsequently, it creates a `/boot` partition of 1 GiB. It contains all the files necessary for booting Linux, especially the kernel. The remaining area is completely filled with a third partition containing one large volume group (LVM VG) named `fedora` by default. You end up with 3 primary partitions on the hard disk that use all the available space. 
 
-Fedora can still use the (legacy) MBR partition scheme, provided that the disc is not larger than 2 TB. It then omits the ```BIOSboot``` partition and uses only the other two partitions.
+Fedora can still use the (legacy) MBR partition scheme, provided that the disk is not larger than 2 TB. It then omits the `BIOSboot` partition and uses only the other two partitions.
 
-In the case of a _UEFI_ boot system, Anaconda creates first the required 'EFI System' partition and then adds the aforementioned ```/boot``` partition and one large LVM partition and Volume Group (VG) as described above. You will end up with 3 partitions on the hard disk that completely occupy the available space.
+In the case of a _UEFI_ boot system, Anaconda creates first the required 'EFI System' partition and then adds the aforementioned `/boot` partition and one large LVM partition and Volume Group (VG) as described above. You will end up with 3 partitions on the hard disk that completely occupy the available space.
 
 In _each_ of these alternatives, Anaconda creates one logical volume of approximately 15 GiB (the exact value depends on the disk capacity of your system) named `root` for the operating system and its software. The remaining available space is at the disposal of the system administrator for free use to store user data.
 
@@ -69,12 +69,12 @@ In this way, any error that may occur in the file system should have as little i
 
 If you are a more experienced administrator, you may wish to further the rationale above with increased separation.
 
-You will select `Custom` and create the `BIOSboot`, `efi` and `/boot` partitions as required and a small partition and VG dedicated to the operating system.  A good size for this VG (eg. ```sysvg```) is, approximately, 30 GiB. Occupying the remaining space, you will create a dedicated partition and Volume group  (eg. ```usrvg```) for user data. You will end up with 4 partitions on the hard disk (boot, sysvg, usrvg with Bios boot machines and hard disks up to 2 TB) rsp. 4 partitions (BIOSboot/efi, boot, sysvg, usrvg for all other machines) that use all the available space.
+You will select `Custom` and create the `BIOSboot`, `efi` and `/boot` partitions as required and a small partition and VG dedicated to the operating system.  A good size for this VG (e.g. `sysvg`) is approximately 30 GiB. Occupying the remaining space, you will create a dedicated partition and volume group (e.g. `usrvg`) for user data. You will end up with 4 partitions on the hard disk: `boot`, `sysvg`, and `usrvg` for BIOS systems or those with disks up to 2 TB; or `BIOSboot`/`efi`, `boot`, `sysvg`, and `usrvg` for all other machines. All configurations use the entire available space.
 
-Create a LV (e.g. ```sys_root```) of about  15 GiB for the operating system and maybe additional LVs for the runtime environment, e.g. a LV ```sys_log``` of about 5 GB. Mount it at ```/var/log``` to prevent log files from flooding and blocking the system and, vice versa, prevent that any other space issue on the root partition block your logs and complicate error analysis. The remaining free space is left for distribution as needed over time. Similar to the default partitioning, all user data is created as LVs in ```usrvg``` and mounted in the corresponding directories of the system. This is the maximum possible separation of system and user data with only one hard disk available. And with today's typical hard drive size of 2 TB and more, those dedicated 30 GBs don't interfere with the effective use of disk space anymore.
+Create a LV (e.g. `sys_root`) of about  15 GiB for the operating system and maybe additional LVs for the runtime environment, e.g. a LV `sys_log` of about 5 GB. Mount it at `/var/log` to prevent log files from flooding and blocking the system and, vice versa, prevent that any other space issue on the root partition block your logs and complicate error analysis. The remaining free space is left for distribution as needed over time. Similar to the default partitioning, all user data is created as LVs in `usrvg` and mounted in the corresponding directories of the system. This is the maximum possible separation of system and user data with only one hard disk available. And with today's typical hard drive size of 2 TB and more, those dedicated 30 GBs do not interfere with the effective use of disk space anymore.
 
 
-==== Raid system
+==== RAID system
 
 If there is more than one disk available, the default partitioning creates, on each of the other disks, one big partition with a Physical Volume (PV) and adds it to the VG.
 
@@ -91,57 +91,57 @@ Some system administrators prefer a static configuration even if there is DHCP a
 
 === Choosing the right installation medium
 
-Fedora Server comes with its own special installation ISO image, either as a full local installation or as a network installation. If at all possible, use one of the two https://getfedora.org/en/server/download/[Fedora Server Edition] alternatives ("Standard" or "Netinstall") and avoid booting from another image.  Anaconda, the installation program and the GUI look alike for any edition or spin, but are tailored differently under the hood, e.g. with different configuration defaults. 
+Fedora Server comes with its own special installation ISO image, either as a full local installation or as a network installation. If at all possible, use one of the two https://fedoraproject.org/server/download[Fedora Server Edition] alternatives ("Standard" or "Netinstall") and avoid booting from another image. Anaconda, the installation program and the GUI look alike for any edition or spin, but are tailored differently under the hood, e.g. with different configuration defaults. 
 
-That's why you don't get a "Fedora Server Edition" as a result with the "__Everything__" installation medium, even if you select "Fedora Server" as a software package. This can lead to various problems during operation and is __not supported__.
+That is why you do not get a "Fedora Server Edition" as a result with the "__Everything__" installation medium, even if you select "Fedora Server" as a software package. This can lead to various problems during operation and is __not supported__.
 
 === Download the proper installation media
 
-Wether on hardware or on a virtual machine, an installation requires the download and the verification of an appropriate installation medium. On your Workstation, you can either use the web browser to download the image file or open a terminal window and perform the download via CLI commands.
+Whether on hardware or on a virtual machine, an installation requires the download and verification of an appropriate installation medium. On your Workstation, you can either use the web browser to download the image file or open a terminal window and perform the download via CLI commands.
 
-In the former case, navigate your browser to  _https://fedoraproject.org/server/download_, select your hardware architecture, and follow the instructions to download and verify the image.
+In the former case, navigate your browser to https://fedoraproject.org/server/download, select your hardware architecture, and follow the instructions to download and verify the image.
 
 In the latter, navigate to the directory where you want to keep the files. We will assume your home directory here. For x86_64 systems, type the following commands line by line.
 
 ----
-[…]$ mkdir -p ~/tmp  && cd ~/tmp  
-[…]$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/41/Server/x86_64/iso/Fedora-Server-dvd-x86_64-41-1.4.iso  
-[…]$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/41/Server/x86_64/iso/Fedora-Server-41-1.4-x86_64-CHECKSUM  
-[…]$ wget https://fedoraproject.org/fedora.gpg  
-[…]$ gpgv --keyring ./fedora.gpg Fedora-Server-41-1.4-x86_64-CHECKSUM  
-[…]# sha256sum  --ignore-missing -c Fedora-Server-41-1.4-x86_64-CHECKSUM  
+$ mkdir -p ~/tmp  && cd ~/tmp  
+$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/41/Server/x86_64/iso/Fedora-Server-dvd-x86_64-41-1.4.iso  
+$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/41/Server/x86_64/iso/Fedora-Server-41-1.4-x86_64-CHECKSUM  
+$ wget https://fedoraproject.org/fedora.gpg  
+$ gpgv --keyring ./fedora.gpg Fedora-Server-41-1.4-x86_64-CHECKSUM  
+# sha256sum  --ignore-missing -c Fedora-Server-41-1.4-x86_64-CHECKSUM  
 Fedora-Server-dvd-x86_64-41-1.4.iso: OK
 sha256sum: WARNING: 17 lines are improperly formatted
 ----
 
 You can safely ignore the last command's warning about incorrectly formatted lines.
 
-=== Create a bootable installation medium 
+=== Create a bootable installation medium
 
-A installation on bare metal requires to transfer the installation file to a bootable media, mostly an USB memory stick. There are several option:
+An installation on bare metal requires transferring the installation file to bootable media, typically a USB memory stick. There are several options.
 
-. As a (typically hands-off) server sysadmin, you can use the "Media Writer" graphical utility provided by the Fedora Project to accomplish this task.  See https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/#using-fedora-media-writer[Creating and using a live installation image - Using Fedora Media Writer] for guidance on using this program.
+. As a (typically hands-off) server sysadmin, you can use the "Media Writer" graphical utility provided by the Fedora Project to accomplish this task. See https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/#using-fedora-media-writer[Creating and using a live installation image - Using Fedora Media Writer] for guidance on using this program.
 
-. As a (hard core) server sysadmin to be, you might prefer a fast and efficiont CLI tool, the `dd` command. If you are already in a terminal window, connect the USB stick and enter the following command to get a list of connected devices.
+. As a (hard core) server sysadmin to be, you might prefer a fast and efficient CLI tool, the `dd` command. If you are already in a terminal window, connect the USB stick and enter the following command to get a list of connected devices.
 +
-[source,]
+[source,console]
 ----
-[…]# lsblk
+# lsblk
 ----
 +
 Determine the USB device, e.g. `/dev/sdc`
 +
 Just in case, umount the device and transfer the downloaded installation file to the device in one go. On the above example use
 +
-[source,]
+[source,console]
 ----
-[…]$ sudo umount /dev/sdc*
-[…]$ dd if=Fedora-Server-dvd-x86_64-41-1.3.iso of=/dev/sdc bs=8M status=progress 
+$ sudo umount /dev/sdc*
+$ dd if=Fedora-Server-dvd-x86_64-41-1.3.iso of=/dev/sdc bs=8M status=progress 
 ----
 +
 Of course, adjust file and device accordingly! You may receive an error message about parameter `status=progress` not supported. Then you still have an older dd version and have to leave that option off.
 
-. And as a (typically busy) server sysadmin to be, you might appreciate a tool provided by the Open Source https://www.ventoy.net/[ventoy] project. A small utility on a USB stick of any size takes over the presentation of the device to the hardware as bootable, and reads itself the ISO file, which is stored on a data partition of the stick. Depending on it's size, it can accomodate multiple ISO files. The server sysadmin can choose between them at boot time in a selection menu. With a new version simply copy the ISO file as it is on the stick and ready to go. No more dd and no Media Writer. 
+. As a system administrator, you might appreciate a tool provided by the https://www.ventoy.net/[`ventoy` project]. A small utility on a USB stick of any size takes over the presentation of the device to the hardware as bootable, and reads itself the ISO file, which is stored on a data partition of the stick. Depending on its size, it can accommodate multiple ISO files. The server sysadmin can choose between them at boot time in a selection menu. With a new version simply copy the ISO file as it is on the stick and ready to go. No more dd and no Media Writer. 
 
 With everything done proceed with one of the available installation procedures.
 

modules/ROOT/pages/installation/interactive-local.adoc

@@ -1,31 +1,33 @@
 = Fedora Server interactive local installation
-Peter Boy; Stephen Daley; Kevin Fenzi
+Peter Boy; Kevin Fenzi; Emmanuel Seyman
+:revnumber: F33-F44
 :page-authors: {author}, {author_2}, {author_3}
-:revnumber: F37-F41
-:revdate: 2024-10-15
+:revdate: 2026-04-28
 
 :page-aliases: pages/installation-interactive-local.adoc
 
 [abstract]
-This is the default method for manually installing Fedora if console access is available. The graphical interface is designed with the goal of making the installation as simple and speedy as possible. It is intended to facilitate the work of the system administrator by preassigning as many installation options as possible after analyzing the hardware.
+This is the default method for manually installing Fedora if console access is available. The graphical interface is designed with the goal of making the installation as simple and speedy as possible. It is intended to facilitate the work of the system administrator by automatically specifying as many installation options as possible after analyzing the hardware.
 
 
-// Before publishing on main site, comment out
-// the warning. Comment in again when start to update.
+// Before publishing, comment out the warning.
+// Comment in again when start to update.
 //[WARNING]
 //====
-//**You are in the Fedora Server documentation staging area!**
 //
-//These documents are not approved yet and may be incomplete and/or incorrect. You would probably prefer to study the https://docs.stg.fedoraproject.org/en-US/fedora-server/[published documentation].
+// This document is not approved yet and may be incomplete and/or incorrect.
 
-// *Status of this document*: Updated to f41.
+// *Status of this document*: Updated to f44.
+// ToDo:
+// * Update images from F41 to F44
+// * Update complete text
 //====
 
 
 With all xref:index.adoc[preparations and installation plans] complete, insert the prepared installation medium and boot the server. After some time you get the boot menu screen.
 
 .The Fedora boot screen
-image::installation/interactive-local-010.png[The boot screen]
+image::installation/interactive-local-010.png[]
 
 The second option, _Test this media & install Fedora Server_, is selected as default. Before the first usage, testing the installation media is strongly recommended. Subsequent installations can dispense with this and select the first option.
 
@@ -35,7 +37,8 @@ First, the program asks for the language to be used during the installation phas
 
 Anaconda will display the following installation overview, with all available configuration options.  
 
-image::installation/interactive-local-020.png[Anaconda Installation Summary]
+.The Anaconda Installation Summary
+image::installation/interactive-local-020.png[]
 
 
 == Server installation steps
@@ -50,7 +53,7 @@ Anaconda does not allow the installation to begin until all marked items have be
 
 The default values assigned are usually acceptable. However, two items deserve the administrator's attention:
 
-* __Keyboard__ in case on a non-US runtime environment
+* __Keyboard__ in case of a non-US runtime environment
 * __Network & Host Name__ 
 
 [TIP]
@@ -73,9 +76,9 @@ __Non-US users__ should specifically check the keyboard layout. Selecting this i
 
 
 
-=== Installation Source
+=== Installation source
 
-In a standard  installation (using the "Standard ISO image"), Anaconda uses "Local media" which will pull packages from the ISO image on your install media.
+In a standard installation (using the "Standard ISO image"), Anaconda uses "Local media" which will pull packages from the ISO image on your install media.
 
 In a network installation select the item and edit the form appropriately. 
 
@@ -90,9 +93,10 @@ Alternatively, you may manually select a server repository directly.
 
 
 
-=== Installation Destination
+=== Installation destination
 
-image::installation/interactive-local-050.png[Anaconda Installation Destination]
+.The Anaconda Installation Destination Screen
+image::installation/interactive-local-050.png[]
 
 Select one or more disks on which to install Fedora Server. You have several options.
 
@@ -104,7 +108,7 @@ Anaconda defaults to Automatic, which follows the recommended default storage or
 +
 If there is more than one disk available, the default partitioning creates, on each of the other disks, one big partition with a Physical Volume (PV) and adds it to the Volume Group (VG). On a server, this is usually not optimal. Rather, you would use the opportunity to store data redundantly and open up the opportunity to maintain operation in the event of a disk failure. 
 +
-If your machine doesn't include a hardware raid capability, you may configure a software RAID system. Switch to xref:installation/sw-raid-upon-installation.adoc[Exkurs: Configuring a software RAID during installation] and then continue here with the Network section.   
+If your machine does not include a hardware raid capability, you may configure a software RAID system. Switch to xref:installation/sw-raid-upon-installation.adoc[`Exkurs`: Configuring a software RAID during installation] and then continue here with the Network section.   
 
 * *Custom configuration*
 +
@@ -117,14 +121,14 @@ The Advanced Custom option also opens up this option, but you have to perform al
 The _Add a disk_ enables you to include external storages, e.g. a SAN (Storage Attached Network) or other network attached drives as part of your Fedora Server install in this same configuration screen. However, this configuration is not covered here in this installation guide. 
 
 ==== Automatic default configuration
-If you are satisfied with the Fedora Server default hard disk partitioning as described in the xref:installation/index.adoc#_what_default_partitioning_does[Server installation] introduction, you can leave _Automatic_ checked under __Storage Configuration__. 
+If you are satisfied with the Fedora Server default hard disk partitioning as described in the xref:installation/index.adoc#_what_default_partitioning_does[Server installation] introduction, you can leave __Automatic__ checked under __Storage Configuration__. 
 
 [TIP]
 ====
 Fedora Server uses LVM by default and creates a Volume Group to enclose the root filesystem. The default name is `fedora`. When you first edit the network configuration and specify a custom hostname, it is appended, i.e. the VG name  becomes `fedora_<hostname>`. This is often useful if managing multiple Fedora servers in a federation, as it avoids duplicate VG names. In any case, you can edit the Volume Group name later in _Installation Destination_.
 ====
 
-No further steps are required besides the disks already contain partitions and file systems. In this case you may want to select the option "Free up space by removing or shrinking existing partitions". Then select _Done_ in the upper bar and you are 'done'.
+No further steps are required beyond the disks that already contain partitions and file systems. In this case you may want to select the option "Free up space by removing or shrinking existing partitions". Then select _Done_ in the upper bar and you are 'done'.
 
 ====
 If you selected the option to free up space, a window will open after you click _Done_ giving you the opportunity to confirm to delete partitions and file systems to make space for your Fedora Server installation or to retain one or more partition. 
@@ -135,18 +139,18 @@ If you selected the option to free up space, a window will open after you click
 
 Select _Custom_ Storage Configuration instead of _Automatic_ and select _Done_ in the upper bar. Anaconda will take you to the _Manual Partitioning_ form.
 
-.Anaconda Manual Partitioning form
-image::installation/interactive-local-070.png[Anaconda Manual Partitioning form]
+.The Anaconda Manual Partitioning form
+image::installation/interactive-local-070.png[]
 
 By clicking onto the + sign you can add partitions according to your storage concept.
 
-Fedora uses a GPT partitioning scheme. Thus, on a BIOSboot system you must add a BIOSboot partion, preferrably as the first one. On a UEFIboot system you have to add a EFI system partition, preferrably as the first one. If you forget it, Anaconda will remind you.
+Fedora uses a GPT partitioning scheme. Thus, on a BIOSboot system you must add a BIOSboot partition, preferably as the first one. On a UEFIboot system you have to add an EFI system partition, preferably as the first one. If you forget it, Anaconda will remind you.
 
-===== How to find out if firmware is efi-boot or bios-boot
+===== How to find out if firmware is UEFI-boot or BIOS-boot
 
-Open a temporay shell by using `<alt>+<ctrl>+<F2>` and type into the terminal window:
+Open a temporary shell by using `<alt>+<ctrl>+<F2>` and type into the terminal window:
 
-[source,]
+[source,console]
 ----
 # [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
 ----
@@ -168,9 +172,6 @@ By default the installation program creates a DHCP configuration for each networ
 
 In case of servers it is often preferable to configure a static IP address. This ensures a valid network connection at system start even if the DHCP server is defective. Select the network interface, activate the IPv4 or IPv6 tab. Switch from "Automatic (DHCP)" to "Manual" and add an IP specification.
 
-NOTE: Post Fedora 36, NetworkManager stores the configuration  exclusively in __/etc/NetworkManager/connected_systems/*.network__. The former /etc/sysconfig/network-scripts directory is no longer supported at all.
-
-
 
 
 === Creating users
@@ -187,8 +188,8 @@ You may want to check Time & Date on the Installation Summary page to ensure tha
 
 On the "Installation Summary" page select "Time & Date" and check time, time zone and activation of time synchronization.
 
-== Start Installation
+== Start installation
 
 Finally, check the default assignments of all options that have not been edited. 
 
-Then, when all settings and configurations fit, select _Begin Installation_ and lean back (or get a coffee!). When finished, confirm the option to restart the computer. Log in and follow the xref:installation/postinstallation-tasks.adoc[post installation suggestions].
+Then, when all settings and configurations fit, select _Begin Installation_ and lean back (or get a coffee!). When finished, confirm the option to restart the computer. Log in and follow the xref:postinstallation/index.adoc[Postinstallation Customizations].

modules/ROOT/pages/installation/interactive-remote.adoc

@@ -1,21 +1,22 @@
 = Fedora Server remote interactive installation guide
 Peter Boy; Kevin Fenzi; Jan Kuparinen; Jiri Konecny
+:revnumber: F44
 :page-authors: {author}, {author_2}, {author_3}, {author_4}
-:revnumber: F42
-:revdate: 2024-12-16
+:revdate: 2026-04-28
 
 :numbered:
 
-:page-aliases: pages/installation-interactive-remote.adoc
-
-// [NOTE]
-// ====
-// **Status:** In sync with released version.
-// ====
+:page-aliases: pages/installation-interactive-remote.ado
 
 
 [abstract]
-With this method, the server is usually residing in a remote location, such as a data center. It boots from a prepared installation media into the Anaconda installation program configured to start and use a "remote desktop protocol" (RDP) server instead of a local physical console. The system administrator connects using a RDP client on a local desktop to the server and runs through the Anaconda graphical installer. This method is best suited for servers without any or just cumbersome available direct console access.
+This method is best suited to servers with limited or no direct console access, but which still have the option of connecting and booting from a USB flash drive. It boots from the prepared installation media into Anaconda and starts a Remote Desktop Protocol (RDP) server instead of a local physical console. The system administrator then connects using an RDP client and runs the Anaconda graphical installer. 
+
+
+
+[NOTE]
+Updated, not yet fully reviewed
+
 
 
 == Prerequisites
@@ -26,20 +27,22 @@ You need one of the installation media variants ready to use as described in   x
 RDP client::
 Performing an RDP installation requires an RDP client running on your workstation or another terminal computer. RDP clients are available in the repositories of most Linux distributions; free RDP clients are also available for other operating systems, such as Windows. On Linux systems, use your package manager to search for a RDP for your distribution.
 +
-The following RDP clients are available in Fedora:
+The following RDP clients are available in __Fedora__:
 +
-* GNOME Connections - Connections is a remote desktop client for the GNOME desktop environment.
-* freerdp - Free implementation of the Remote Desktop Protocol (RDP)
+--
+* __GNOME Connections__ - a remote desktop client for the GNOME desktop environment.
+* __freerdp__ - Free implementation of the Remote Desktop Protocol (RDP)
+--
 +
-To install any of the clients listed above, execute the following command as root:
+Use your desktop software installation program to install any of the clients listed above.
 +
-[source,]
-----
-[...]# dnf install PACKAGE_NAME
-----
+For MacOS you may use one of the following options:
 +
-Replace package with the package name of the client you want to use (for example, freerdp).
-
+--
+* __Windows App__ - provided by Microsoft for free via App Store 
+* __Jump Desktop__ - commercial application via App Store 
+* __FreeRDP__ - Free implementation of the Remote Desktop Protocol installable via Homebrew or MacPorts
+--
 
 == Booting the server
 There are several options to boot the server, depending on the ethernet connection method and availability of at least some, maybe cumbersome and short living local console access.
@@ -91,11 +94,67 @@ The system will initialize the installation program and start the necessary serv
 ----
 Continue with __3.2. Connecting to the server__.
 
+=== No console access available - provide a kickstart medium
+
+You will need two usable USB ports or DVD drives on the server, one for the installation medium, one for a kickstart flash drive.
+
+. On your desktop, connect an USB stick and format as FAT and with label OEMDRV. In Fedora use the graphical tool of the desktop UI or a terminal window.            
++            
+List the connected devices and identify the USB stick 
++            
+[source,bash]            
+----            
+$ lsblk            
+NAME            MAJ:MIN RM    SIZE RO TYPE MOUNTPOINTS            
+sda             8:0    0  596.2G  0 disk   
+ ├─sda1         8:1    0    600M  0 part /boot/efi
+ ├─sda2         8:2    0      1G  0 part /boot   
+ ├─sda3         8:3    0     80G  0 part 
+ │ ├─fedora_fedora-root    253:0    0     15G  0 lvm  /            
+ │ └─fedora_fedora-var_log 253:2    0      5G  0 lvm  /var/log            
+ └─sda4         8:4    0  514.6G  0 part             ├─fedora_user-libvirt   253:3    0    120G  0 lvm  /var/lib/libvirt            
+    └─fedora_user-machines  253:4    0     80G  0 lvm  /var/lib/machines            
+sdb             8:16   1 1001.5M  0 disk 
+ └─sdb1         8:17   1 1001.5M  0 part   
+zram0           252:0    0      8G  0 disk [SWAP] 
+----            
++            
+In the example above, the USB stick is `sdb`. If already mounted, unmount, format, and mount at e.g. `/mnt`.            
++            
+[source,bash]            
+----            
+$ sudo umount /dev/sdb1            
+$ sudo mkfs.vfat  -n 'OEMDRV' /dev/sdb1          
+$ sudo mount /dev/sdb1  /mnt            
+----
+
+            
+. Create and edit a kickstart file _ks.cfg_ in the root directory of the USB flash drive.            
++            
+If possible, you should provide a static network configuration, so you'll know the IP address. If that is not possible and DHCP is available, you can omit the "network" line. Anaconda will then use DHCP and display the address it receives.  
++            
+[source,bash]            
+----            
+$ sudo vim /mnt/ks.cfg            
+<INSERT>            
+network --bootproto=static --ip=ww.xx.yy.zz --netmask=255.255.255.0 --gateway=ww.xx.yy.gg  --ipv6='aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh/nnn' --hostname='myhost.mydomain.tld'  --nameserver=10.0.2.1 
+rdp --user='SOME_NAME' --password=PASSWORD            
+<SAVE&QUIT>            
+----            
++            
+If the network configuration does not allow or enable static interface configuration, omit the 'network …' line either completely or just add the --hostname parameter. It uses DHCP by default. And if your DHCP server provides dynamic DNS as well, you can easy access your server to be installed.            
+
+. On your server, connect the installation medium as well as the OEMDRV medium and boot. The server will use the OEMDRV stick, configure the interface and start VNC. Just in case you have at least a monitor without keyboard and mouse, you will see the corresponding message. Otherwise, trust your configuration. 
+
+With _Fedora 44_ you get some Python error messages you can ignore. It works anyway.
+
+Continue with __3.2. Connecting to the server__. 
+
+=== No console access available - patch installation medium
 
-==== No console access available – patch installation medium
 If none of the above options work with your server and network configuration, you could patch the installation media as a last resort. As an example, you can change the grub boot lines in /isolinux/grub.conf. You would need to add the RDP parameter and remove the integrity test, as this is the default line but would fail after patching.
 
-We won't go into this matter any further here. This is really the very last resort and is not recommended.
+We will not go into this matter any further here. This is really the very last resort and is not recommended.
 
 == Connecting to the server
 . In case of a server without a console attached determine the IP address.
@@ -104,8 +163,8 @@ b. Scan the network subnet the server is connected to for open port 3389. Adjust
 +
 [source,bash]
 ----
-[…]# dnf install nmap
-[…]# nmap -Pn -p3389 192.168.158.0/24
+# dnf install nmap
+# nmap -Pn -p3389 192.168.158.0/24
 Starting Nmap 7.80 ( https://nmap.org ) at 2021-05-23 08:18 CEST
 Nmap scan report for example.com (192.168.158.1)
 Host is up (0.00052s latency).
@@ -129,9 +188,9 @@ Host is up (0.00068s latency).
 Nmap done: 256 IP addresses (12 hosts up) scanned in 2.38 seconds
 ----
 +
-Look for an entry with open state of port 3389 and no hostname or unknown hostname. Among them you will probably find the device you are looking for. In the example above it is 192.168.158.200.
+Look for an entry with open state of port 3389 and no hostname or unknown hostname. Among them you will probably find the device you are looking for. In the example above it is `192.168.158.200`.
 
-. On the desktop start the GNOME connections, add new connection with a plus symbol, enter the IP address obtained in the previous step. You will be asked to confirm certificates. These are generated by Anaconda and they are different for each installation.
+. On the desktop start the RDP client, add new connection with a plus symbol, enter the IP address obtained in the previous step. You will be asked to confirm certificates. These are generated by Anaconda and they are different for each installation.
 +
 Alternatively, use freerdp client with
 +
@@ -149,7 +208,7 @@ This window will provide full remote access to the installer until the installat
 +
 [TIP]
 ====
-If the screen freezes after some mouse or keyboard actions, add the kernel option __nomodeset__ before the term _inst.rdp_ to the kernel commad line in step  __3.1.1__.
+If the screen freezes after some mouse or keyboard actions, add the kernel option `nomodeset` before the term _inst.rdp_ to the kernel command line in step __3.1.1__.
 ====
 
 You can then proceed with xref::installation/interactive-local.adoc[Fedora Server interactive local installation].

modules/ROOT/pages/installation/sw-raid-upon-installation.adoc

@@ -1,26 +1,26 @@
 = Excursus: Configuring a software RAID upon interactive installation
 Peter Boy; Stephen Daley; Kevin Fenzi
+:revnumber: F37-F44
 :page-authors: {author}, {author_2}, {author_3}
-:revnumber: F37-F42
-:revdate: 2025-08-20
+:revdate: 2026-04-28
 
 [abstract]
-This Exkurs describes the configuration of a _software RAID_ as part of an interactive Fedora Server Edition installation. In this case, the RAID capability is provided by operating system drivers and processed bei the computer CPU. It does not cover firmware raid (also called Windows RAID), which provide this capability via the computer internal firmware, nor hardware raid, where dedicated integrated hardware modules or adapters completely relieve the computer CPU of the raid processing.   
+This `Exkurs` describes the configuration of a _software RAID_ as part of an interactive Fedora Server Edition installation. In this case, the RAID capability is provided by operating system drivers and processed by the computer CPU. It does not cover firmware raid (also called Windows RAID), which provide this capability via the computer internal firmware, nor hardware raid, where dedicated integrated hardware modules or adapters completely relieve the computer CPU of the raid processing.   
 
 
-The RAID configuraton starts at the "Installation Destination" window.
+The RAID configuration starts at the "Installation Destination" window.
 
 .The Installation Destination window
 image:installation/sw-raid/001-installationdestination.png[]
 
-The _Local Standard Disk_ list must include at least two hard disks. And please, ignore the USB drive that provides the installation system, in case Anaconda doesn't hide the installation media anyway.
+The _Local Standard Disk_ list must include at least two hard disks. And please, ignore the USB drive that provides the installation system, in case Anaconda does not hide the installation media anyway.
 
 Before you start with partitioning, you have to determine the boot type of your system, UEFI boot or BIOS (or legacy) boot system. Fedora defaults to the GPT partitioning scheme which was created with UEFI boot systems in mind. On a BIOS boot system, it requires a special partition. 
 
 NOTE:  Just in case you need a DOS/MBR partitioning scheme for some good reason, you can override the GPT default by adding "inst.mbr" to the kernel boot parameter at the initial boot screen.
 
-If you don't know the type of your system for sure, you can check the system now. Open a temporay shell by using `<alt>+<ctrl>+<F2>` and type into the terminal window:
-[source,]
+If you do not know the type of your system for sure, you can check the system now. Open a temporary shell by using `<alt>+<ctrl>+<F2>` and type into the terminal window:
+[source,console]
 ----
 # [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
 ----
@@ -31,7 +31,7 @@ There are then two installation options:
 
 * The "**Custom**" option
 +
-This way you just specify the mountpoints and Anaconda performs all the necessary steps for you. If needed you can adjust some properties afterwards. That's the comfortable way. 
+This way you just specify the mountpoints and Anaconda performs all the necessary steps for you. If needed you can adjust some properties afterwards. That is the comfortable way. 
 +
 Unfortunately, Anaconda does not necessarily keep the arrangement of the partitions that you have chosen, but sorts the partitions as it sees fit. This causes no problems at all in everyday operation. But if, for example, you have placed a partition at the end to preserve the possibility of making adjustments later, that could go wrong.
 
@@ -41,7 +41,7 @@ This way, you can and must perform each individual step of partitioning, configu
 +
 The advantage is that you can define every detail and you will get a partitioning exactly according to your plan. And the GUI supports the work very effectively.
 
-Select all drives you want to include in the prospective RAID drive, click on the partitioning option you want to use and then on Done in the uper left corner. 
+Select all drives you want to include in the prospective RAID drive, click on the partitioning option you want to use and then on Done in the upper left corner. 
 
 == Custom partitioning
 
@@ -56,13 +56,13 @@ If the area beyond __Unknown__ contains one or more partition, check whether you
 +
 To delete a partition, click on it and then on the '-' sign at the bottom. At the end, all disks must either be empty or identically partitioned.
 
-. *On a BIOS boot system only, create a biosboot partition on each disk*
+. *On a BIOS boot system only, create a `biosboot` partition on each disk*
 +
 On a BIOS boot system, a GPT partition table as used by Fedora requires a small BIOSBoot partition for the Grub boot loader. Create it at the beginning of each disk to keep the system operational when one disk fails. Skip this step, if your host uses UEFI!
 +
-Use the "+" sign to add a partition. In the Mount Point field select 'biosboot' and set a size of 1 MiB.
+Use the "+" sign to add a partition. In the Mount Point field select `biosboot` and set a size of 1 MiB.
 +
-A biosboot entry appears in the left __New Fedora 41 Installation__ section on one of he disks.
+A `biosboot` entry appears in the left __New Fedora 41 Installation__ section on one of he disks.
 +
 Repeat it and you see a second entry, usually on the same disk.
 +
@@ -71,12 +71,12 @@ image:installation/sw-raid/105-custom-biosboot-1.png[]
 +
 Select the new entry and click on __Modify__ at __Device(s)__. In the device list select one of the other disks. Then select __Update Settings__. 
 +
-Anaconda updates the list of partitions in the _New Fedora 41 installation_ section so that the biosboot partition is now the first partition on different disks. 
+Anaconda updates the list of partitions in the _New Fedora 41 installation_ section so that the `biosboot` partition is now the first partition on different disks.
 +
 .The adjusted BiosBoot installation
 image:installation/sw-raid/110-custom-biosboot-2.png[]
 +
-Repeat the step until all disks have a biosboot partition. This is necessary so that the system can boot from any of the other disks if the first disk fails. 
+Repeat the step until all disks have a `biosboot` partition. This is necessary so that the system can boot from any of the other disks if the first disk fails.
 
 . *On a UEFI boot system only, create an EFI partition*
 +
@@ -93,7 +93,7 @@ image:installation/sw-raid/120-custom-efi-1.png[]
 +
 Anaconda sets up an EFI partition on the first disk. But a RAID system must be able to boot from any of the available disks, not just the first one. Otherwise, the system would be paralyzed if that failed. One solution is to set up the EFI partition as a RAID as well. 
 +
-Find the property Device Type and use the drop down list to change Standard partition to RAID. In the right side shows up a new selection box RAID level showing initially RAID1 (mirroring) in this example, because we have just 2 disks. Leave the file system as “EFI System Partition”. Choose an optional label, e.g. sysefi, and And trigger “Update Settings” further below.
+Find the property Device Type and use the drop down list to change Standard partition to RAID. In the right side shows up a new selection box RAID level showing initially RAID1 (mirroring) in this example, because we have just 2 disks. Leave the file system as "EFI System Partition". Choose an optional label, e.g. `sysefi`, and trigger "Update Settings" further below.
 +
 .Final EFI system partition properties
 image:installation/sw-raid/125-custom-efi-2.png[]
@@ -108,25 +108,25 @@ Tick the "+" sign and a form "Add a new Mount Point" opens again.
 +
 A new mount point is created on sda1. On the right side there is a form to show and modify some properties. Find the property _Device Type_ and use the drop down list to change Standard partition to __RAID__. In the right side shows up a new selection box _RAID level_ showing initially RAID1 (mirroring) in this example, because we have just 2 disks. Choose the RAID level you wish and then click on _Update Settings_ further down. 
 +
-Anaconda updates the form and the list beyond __New Fedora 41 Installation__. The sdx partition is gone and replaced by a (device) name, the same one you find in the property form on the right side. In the form you can add a label, e.g. sysboot, if you like, and _Update Settings_ again.
+Anaconda updates the form and the list beyond __New Fedora 41 Installation__. The `sdx` partition is gone and replaced by a (device) name, the same one you find in the property form on the right side. In the form you can add a label, e.g. `sysboot`, if you like, and _Update Settings_ again.
 +
 .Final properties of the boot device (raid partition)
 image:installation/sw-raid/130-custom-finalbootform.png[]
 
 . *Add a _root_ mount point*
 +
-Use the "+" sign to add another Moint Point
+Use the "+" sign to add another Mount Point
 +
  *  select / as the mount point
  * enter 15 Gib as size
  * Tick "Add Mount Point"
 +
-Anaconda creates a new mount point. From the context Anaconda guesses to assign the device type LVM, to create a Volume Group using the default name _fedora_ appending the systems hostname, if you already configured the network, and to assign the device name root. The size of 15 GiB is the same as a default configuration would do. That's a lot of work that Anaconda saves you.
+Anaconda creates a new mount point. From the context Anaconda guesses to assign the device type LVM, to create a Volume Group using the default name _fedora_ appending the systems hostname, if you already configured the network, and to assign the device name root. The size of 15 GiB is the same as a default configuration would do. That is a lot of work that Anaconda saves you.
 +
 .Anaconda generated LVM root volume and filesystem
 image:installation/sw-raid/140-custom-generated-root.png[]
 +
-Now you have the opportunity the adjust Anacondas guessings.
+Now you have the opportunity to adjust Anaconda's guesses.
 +
 The most important one is to adjust the RAID level. Anaconda configures a LVM without RAID by default. Tick the modify button of the LVM property.
 +
@@ -135,25 +135,25 @@ image:installation/sw-raid/145-custom-lvm-properties.png[]
 +
 Select a proper RAID level and check the size policy.
 
-* _Automatic_ means that the size of the partition and the Volume Group is just as large as the Logical Volumes you create with Anaconda here. That provides you a maximum of flexibilty to later adjust the storage organisation but also involves some additional steps to handle the Volume Group and its partition when you want do add a Logical Volume and file system. 
+* _Automatic_ means that the size of the partition and the Volume Group is just as large as the Logical Volumes you create with Anaconda here. That provides you a maximum of flexibility to later adjust the storage organization but also involves some additional steps to handle the Volume Group and its partition when you want do add a Logical Volume and file system. 
 * _Maximum size_ expands the Volume Group to fill up the complete hard disk, so you can add Logical Volumes with a minimum of effort. That is the recommended way for medium size disks. 
 * _Fixed size_ lets you specify a size that fulfills your foreseeable requirements and leaving some space for later adjustments that come up as a surprise.
 +
-This option also allows for an __even stronger separation of system and user data__. Specify a fixed size of 20-30 GiB for a system volume group (named e.g. fedora_sysvg). This contains the root file system and, if applicable, further system-related logical volumes. In the remaining space you will later set up  a user volume group (correspondingly named fedora_usrvg) and logical volumes for user data. This gives you the greatest possible flexibility to adapt the system area to changes in demand or technical developments without touching the precious user data at all. This is recommended for large hard disks, servers with a planned longtime lifespan, or remotely located servers.    
+This option also allows for an __even stronger separation of system and user data__. Specify a fixed size of 20-30 GiB for a system volume group (named e.g. `fedora_sysvg`). This contains the root file system and, if applicable, further system-related logical volumes. In the remaining space you will later set up  a user volume group (correspondingly named `fedora_usrvg`) and logical volumes for user data. This gives you the greatest possible flexibility to adapt the system area to changes in demand or technical developments without touching the precious user data at all. This is recommended for large hard disks, servers with a planned longtime lifespan, or remotely located servers.    
 
-. *Customize the storage organisation to your requirements*
+. *Customize the storage organization to your requirements*
 +
 Finally, you can further customize the storage organization to your requirements. 
 +
-Some adminmistrators like to confine the /var/log subdirectory in its own Logical Volume. This prevents excessive logging from filling up the root file system. But also vice versa, that excessive outputs of a program fill up the root file system to such an extent that no more log outputs can be saved and troubleshooting is made more difficult. 
+Some administrators like to confine the /var/log subdirectory in its own Logical Volume. This prevents excessive logging from filling up the root file system. But also vice versa, that excessive outputs of a program fill up the root file system to such an extent that no more log outputs can be saved and troubleshooting is made more difficult. 
 
-Finally, click on Done, in the upcomming list accept the Changes and return now to the original guide, probably xref::installation/interactive-local.adoc#_networking[Fedora Server interactive local installation] guide.
+Finally, click on Done, in the upcoming list accept the Changes and return now to the original guide, probably xref::installation/interactive-local.adoc#_networking[Fedora Server interactive local installation] guide.
 
-== Advanced Custom partitioning
+== Advanced custom partitioning
 
 Anaconda opens a new window:
 
-.The advancced custom partitioning start up screen
+.The advanced custom partitioning start up screen
 image:installation/sw-raid/201-adv-custom-start.png[]
 
 . *Check all disks for existing partitions*
@@ -162,7 +162,7 @@ If there are partitions on any of the hard disks, delete the partitions if they
 +
 To delete a partition, click on it and then on the circled "x" sign below. In the end, all hard disks must either be empty or identically partitioned. In the following, we assume that the hard disks are empty.
 
-. *On a BIOS boot system only, create a biosboot partition on each disk*
+. *On a BIOS boot system only, create a `biosboot` partition on each disk*
 +
 On a BIOS boot system, a GPT partition table as used by Fedora requires a small BIOSBoot partition for the Grub boot loader. Create it at the beginning of each disk to keep the system  operational when one disk fails. Skip this step, if your host uses UEFI!
 +
@@ -172,7 +172,7 @@ a partition.
 .Create a BIOS Boot partition 
 image:installation/sw-raid/205-adv-custom-biosboot.png[]
 +
-First select "Bios Boot" in the „Filesystem“ selection field and then enter 1 MiB as the size. An OK creates the partition and updates the free space area. 1 MiB is quite sufficient, but sometimes the dialogue insists on 2 MiB and corrects the entry accordingly. That's fine, too.
+First select "Bios Boot" in the „Filesystem“ selection field and then enter 1 MiB as the size. An OK creates the partition and updates the free space area. 1 MiB is quite sufficient, but sometimes the dialogue insists on 2 MiB and corrects the entry accordingly. That is fine, too.
 +
 Next, click on sdb and thus activate it for editing. Repeat the process to create a BIOSBoot partition as before. 
 +
@@ -191,7 +191,7 @@ Anaconda sets up an EFI partition on the first disk. But a RAID system must be a
  * select RAID level raid1
  * enter 0.6 GiB size
  * select Filesystem "EFI System Partition"
- * enter Label "sysefi"
+ * enter Label "`sysefi`"
  * enter Name "boot_efi"
  * Enter Mountpoint /boot/efi 
  * Tick "OK"
@@ -211,14 +211,14 @@ image:installation/sw-raid/215-adv-custom-boot.png[]
 In the “Device type” selection box, select “Software RAID” . The form changes. 
 Then fill out the rest of the form as indicated.
 +
- * select sda and sdb as RAID members
+ * select `sda` and `sdb` as RAID members
  * select RAID level raid1
  * enter 1.0 GiB size
- * keep Filesystem "xfs"
- * enter Label "sysboot"
- * enter Name "boot"
- * Enter Mountpoint /boot 
- * Tick "OK"
+ * keep Filesystem: `xfs`
+ * enter Label: `sysboot`
+ * enter Name: `boot`
+ * Enter Mountpoint: `/boot`
+ * Tick **OK**
 +
 The installation window refreshes and now shows another new RAID entry in the left column and a boot partition in the sda disk.
 +
@@ -230,7 +230,7 @@ image:installation/sw-raid/217-adv-custom-bootlist.png[]
 +
 Click into the free space on sda to activate it and tick the "+" sign again to open a new device form.
 +
-.Creating a system Volme Group partition
+.Creating a system Volume Group partition
 image:installation/sw-raid/220-adv-custom-syspv.png[]
 +
 Again, in the “Device type” selection box, select “Software RAID” and then fill out the rest of the form as indicated.
@@ -239,7 +239,7 @@ Again, in the “Device type” selection box, select “Software RAID” and th
  * select RAID level raid1
  * Specify the size of the partition. There are basically three options.
  ** __Leave the size as suggested by the form__, which fills the rest of the hard disk. Both system and user data are stored in a common volume group. This is appropriate for hosts with a planned lifespan of a few years or less and/or a disk capacity of less than 0.5 - 1 TB. 
- ** __Set aside a 20–30/50 GiB partition for the system area__ and, in the next step, another partition exclusively for user data. This is particulary recommended for systems with a planned longtime lifespan, a hard disk capacity of more than 1–2 TiB, and especially for systems in remote data centers where there is never any possibility of accessing the system console. In the latter case, it is especially important to keep system and user areas strictly separated as far as possible on the same hard disk, in order to be able to carry out any system work without ever having to touch the precious user data.
+ ** __Set aside a 20-30/50 GiB partition for the system area__ and, in the next step, another partition exclusively for user data. This is particularly recommended for systems with a planned longtime lifespan, a hard disk capacity of more than 1-2 TiB, and especially for systems in remote data centers where there is never any possibility of accessing the system console. In the latter case, it is especially important to keep system and user areas strictly separated as far as possible on the same hard disk, in order to be able to carry out any system work without ever having to touch the precious user data.
  ** In either case, __leave some free space at the end__ to allow for possible future adjustments to changing and  unpredictable needs. 
 +
 In this example, we use a 30 GiB system area and the entire rest for a dedicated user area. 
@@ -248,28 +248,28 @@ In this example, we use a 30 GiB system area and the entire rest for a dedicated
  * enter Name "syspv"
  * Tick "OK"
 +
-The list view refreshes and shows the harddisks with the 3 partitions and on the left column an additional RAID device.
+The list view refreshes and shows the hard disks with the 3 partitions and on the left column an additional RAID device.
 +
 .Partitions list including EFI, boot and physical volume partitions
 image:installation/sw-raid/222-adv-custom-syspvlist.png[]
  +
 In contrast to other GUIs, a volume group (VG) is not created immediately, but a "physical volume" is created first. Many other GUIs perform this step implicitly and automatically.
 +
-Double-click onto the syspv icon in the left bar to activate it and then on the Plus sign to open a device creation form.
+Double-click onto the `syspv` icon in the left bar to activate it and then on the Plus sign to open a device creation form.
 +
 .Partitions list including EFI, boot and physical volume partitions
 image:installation/sw-raid/224-adv-custom-sysvgform.png[]
 +
-Leave the Device type and Size field as is und enter "sysvg" into the Name field. Tick OK to submit the form.
+Leave the Device type and Size field as is and enter "`sysvg`" into the Name field. Tick OK to submit the form.
 +
-The overview list screen now shows a new Volume Group device "sysvg" beyond a new category "LVM".
+The overview list screen now shows a new Volume Group device `sysvg` beyond a new category "LVM".
 +
 .Devices list showing partitions, volume groups and RAID devices
 image:installation/sw-raid/226-adv-custom-sysgvlist.png[]
 
 . *Optional: Creating a user Volume Group*
 +
-If you have opted for a separate user area as recommended, you should now create a corresponding volume group.  Repeat the steps from the previous section accordingly. 
+If you have opted for a separate user area as recommended, you should now create a corresponding volume group. Repeat the steps from the previous section accordingly. 
 
 * Double-click on sda and into the free space to activate it and tick the "+" sign again to create an additional RAID partition and physical volume.
 +
@@ -283,21 +283,21 @@ Either leave the suggested size value as it is to set up the entire free area fo
 .Partitions list including EFI, boot and physical volume partitions
 image:installation/sw-raid/234-adv-custom-usrvg.png[]
 +
-Leave the Device type and Size field as is und enter "usrvg" into the Name field. Tick OK to submit the form.
+Leave the Device type and Size field as is and enter "`usrvg`" into the Name field. Tick OK to submit the form.
 +
-The overview list screen now shows a new Volume Group device "sysvg" beyond a new category "LVM".
+The overview list screen now shows a new Volume Group device `usrvg` beyond a new category "LVM".
 +
 .Devices list showing partitions, two volume groups and RAID devices
 image:installation/sw-raid/236-adv-custom-usrvglist.png[]
 
 . *Creating the ROOT file system*
 +
-As in the previous steps, clicking on symbol sysvg activates the unit for editing and clicking on the free area releases the plus sign. A click on the plus sign opens the dialogue for setting up a file system.
+As in the previous steps, clicking on symbol `sysvg` activates the unit for editing and clicking on the free area releases the plus sign. A click on the plus sign opens the dialogue for setting up a file system.
 +
 .Creating the ROOT file system
 image:installation/sw-raid/240-adv-custom-rootfsform.png[]
 +
-Leave the Device type and Avalable devices as is.
+Leave the Device type and Available devices as is.
 
 * Specify the size of the root file system. A value of 12 GiB for the mere system files is large enough for the usual use cases and still has a lot of leeway for unusual situations.  
 * Complete the other fields as indicated and tick OK.
@@ -312,14 +312,14 @@ Finally, you can further customize the storage organization to your requirements
 
 * __Optional: Create a separate log file system__
 +
-Some adminmistrators like to confine the /var/log subdirectory in its own Logical Volume. This prevents excessive logging from filling up the root file system. But also vice versa, that excessive outputs of a program fill up the root file system to such an extent that no more log outputs can be saved and troubleshooting is made more difficult.
+Some administrators like to confine the `/var/log` subdirectory in its own Logical Volume. This prevents excessive logging from filling up the root file system. But also vice versa, that excessive outputs of a program fill up the root file system to such an extent that no more log outputs can be saved and troubleshooting is made more difficult.
 +
-As in the previous steps, clicking on symbol sysvg activates the unit for editing and clicking on the free area releases the plus sign. A click on the plus sign opens the dialogue for setting up a file system.
+As in the previous steps, clicking on symbol `sysvg` activates the unit for editing and clicking on the free area releases the plus sign. A click on the plus sign opens the dialogue for setting up a file system.
 +
 .Creating log file system
 image:installation/sw-raid/250-adv-custom-varlogform.png[]
 +
-Leave the Device type and Avalable devices as is
+Leave the Device type and Available devices as is
 +
  ** Specify the size of the file system. A value of 3 or 5 GiB is usually large enough.  
  ** Complete the form as indicated
@@ -336,48 +336,48 @@ But sometimes they need to upload some data for further processing on the server
 +
 For a large number of users, use the user area, if available
 +
-** Select a siutable Volume Group, double-click on the device in the left column (sysvg or usrvg), and then into the free space to release the "plus" button.
+** Select a suitable Volume Group, double-click on the device in the left column (`sysvg` or `usrvg`), and then into the free space to release the "plus" button.
 +
 .Creating a home file system
 image:installation/sw-raid/260-adv-custom-usrhomeform.png[]
 
-** Leave the Device type and Avalable devices as is
-** Specify a reasonable size of the home file system. For a system with only administravie users, a value of 3 or 5 GiB is usually large enough.  
+** Leave the Device type and Available devices as is
+** Specify a reasonable size of the home file system. For a system with only administrative users, a value of 3 or 5 GiB is usually large enough.  
 ** Complete the form as indicated
 +
 .Storage overview including a home file system
 image:installation/sw-raid/264-adv-custom-usrhomelist.png[]
 
-* __Optional: Setting up a server (/srv) storage space__
+* __Optional: Setting up a server (`/srv`) storage space__
 +
 According to the Filesystem Hierarchy Standard (FHS), a system should store site-specific data served by the server, such as data and scripts for web servers, data offered by FTP servers, etc. in /srv. These belong into a separate file system.
 
-** Select a suitable Volume Group, in this example usrvg if available. Double-click on the device in the left column and then into the free space to release the "plus" button.
+** Select a suitable Volume Group, in this example `usrvg` if available. Double-click on the device in the left column and then into the free space to release the "plus" button.
 +
-.Creating a srv file system
+.Creating a `/srv` file system
 image:installation/sw-raid/270-adv-custom-srvform.png[]
 
-** Leave the Device type and Avalable devices as is.
-** Specify a reasonable size depending on your system plannings.
+** Leave the Device type and Available devices as is.
+** Specify a reasonable size depending on your system planning.
 ** Complete the form as indicated.
 +
-.Devices list showing the srv file system
+.Devices list showing the `/srv` file system
 image:installation/sw-raid/274-adv-custom-srvlist.png[]
 
 * __If applicable: Setting up a virtual machine's storage space__
 +
 
-** Select a suitable Volume Group, in this example usrvg if available. Double-click on the device in the left column and then into the free space to release the "plus" button.
+** Select a suitable Volume Group, in this example `usrvg` if available. Double-click on the device in the left column and then into the free space to release the "plus" button.
 +
 .Creating a libvirt file system
 image:installation/sw-raid/280-adv-libvirtform.png[]
 
-** Leave the Device type and Avalable devices as is.
-** Specify a reasonable size depending on your system plannings.
+** Leave the Device type and Available devices as is.
+** Specify a reasonable size depending on your system planning.
 ** Complete the form as indicated.
 +
 .Devices list showing libvirt file system
 image:installation/sw-raid/284-adv-custom-libvirtlist.png[]
 
 
-Finally, click on Done, in the upcomming list accept the Changes and return now to the original guide, probably xref::installation/interactive-local.adoc#_networking[Fedora Server interactive local installation] guide.
+Finally, click on Done, in the upcoming list accept the Changes and return now to the original guide, probably xref::installation/interactive-local.adoc#_networking[Fedora Server interactive local installation] guide.

modules/ROOT/pages/postinstallation/index.adoc

@@ -1,10 +1,10 @@
-= Post Installation Tasks
+= Postinstallation Customizations
 Peter Boy; Stephen Daley; Kevin Fenzi
+:revnumber: F36-F45
 :page-authors: {author}, {author_2}, {author_3}
-:revnumber: F36-F41
-:revdate: 2024-10-15
+:revdate: 2026-09-13
 
-:page-aliases: pages/sysadmin-postinstall.adoc
+:page-aliases: pages/sysadmin-postinstall.adoc pages/installation/postinstallation-tasks.adoc
 
 :numbered:
 
@@ -12,19 +12,33 @@ Peter Boy; Stephen Daley; Kevin Fenzi
 This guide offers a recommended checklist of tasks to ensure the safe and reliable operation of Fedora Server. System administrators may choose whether these tasks apply to their specific use case.
 
 
-// Before publishing on main site, comment out
-// the warning. Comment in again when start to update.
+[NOTE]
+====
+We are currently in the process of splitting this guide into a series of shorter, more detailed articles, mostly in a how-to style.
+====
+
+
+// Before publishing, comment out the warning.
+// Comment in again when start to update.
 //[WARNING]
 //====
-//**You are in the Fedora Server documentation staging area!**
-//
-//These documents are not approved yet and may be incomplete and/or incorrect. You would probably prefer to study the https://docs.stg.fedoraproject.org/en-US/fedora-server/[published documentation].
+//This document is not approved yet and may be incomplete and/or incorrect. 
 
-To perform the administrative tasks described here, you need either any Linux or any macOS desktop or laptop. On Windows computers, you need at least Windows 10 1809 or additional programs such as Putty.
+//*Status of this document*: Updated to f44.
+
+//ToDo:
+
+//* Update images from F43 toF44
+//* Update complete text
+//====
+
+The following descriptions assume that the administrator is working at their workstation and accessing the server via SSH. However, most of the configuration instructions described can also be executed on the server console.
+
+SSH is included by default on Linux and macOS. Windows 10 requires at least version 1809, or the additional program PuTTY.
 
 == Simplified access for the administrative account
 
-In a default installation, the root account is locked and administrative work is delegated to a user account that is entitled to root privileges (sudo). It is convenient to make the login process as comfortabe as possible.
+In a default installation, the root account is locked and administrative work is delegated to a user account that is entitled to root privileges (sudo). It is convenient to make the login process as comfortable as possible.
 
 include::partial$installation/post-install/convenient-user-login.adoc[]
 
@@ -36,7 +50,7 @@ include::partial$installation/post-install/cockpit-check-accessibility.adoc[]
 
 
 
-== Disable SSH Login with passwords for system users
+== Disable SSH login with passwords for system users
 
 System users are a systematic weak point in defending a server against compromise attacks. This is certainly unintentional on the part of the users. It is due to lack of understanding, insecure passwords, falling for phishing attacks, and alike. On the other hand, it is precisely the users that a server is operated for.
 
@@ -61,22 +75,22 @@ include::partial$installation/post-install/cockpit-secure-access.adoc[]
 
 == Optionally: Set up root login via key file
 
-Even if you activated root access during installation, you have hopefully kept the default option to restrict root to key file authentification. So you have to set up a key file prior to any ssh login. But be aware! You can still log in to Cockpit's web interface. Therefore, in this case, be sure to implement the additional security measures described in the previous chapter!
+Even if you activated root access during installation, you have hopefully kept the default option to restrict root to key file authentication. So you have to set up a key file prior to any ssh login. But be aware! You can still log in to Cockpit's web interface. Therefore, in this case, be sure to implement the additional security measures described in the previous chapter!
 
-=== Prepare a pair of private / public keys
+=== Prepare a pair of private/public keys
 
-This step is to be performed only if a pair of keys does not already exist. It is best to create the key in the _.ssh_ directory of the desktop user. It should not be secured by password to enable automatic processing. The naming with leading 'id_' und trailing types abbreviation, e.g. '_rsa' is just a common convention, yet helpful.
+This step is to be performed only if a pair of keys does not already exist. It is best to create the key in the _.ssh_ directory of the desktop user. It should not be secured by password to enable automatic processing. The naming with leading `id_` and trailing types abbreviation, e.g. `_rsa`, is just a common convention, yet helpful.
 
 a. Execute on the local desktop 
 +
 [source]
 ----
-[…]$ mkdir ~/.ssh 
-[…]$ cd ~/.ssh 
-[…]$ ssh-keygen -t rsa -b 4096  -C "root@example.com" -f <outputkeyfile>
+$ mkdir ~/.ssh 
+$ cd ~/.ssh 
+$ ssh-keygen -t rsa -b 4096  -C "root@example.com" -f <outputkeyfile>
 ----
 
-Although the type rsa is widely used, you may adjust your key type accordingly.
+Although RSA is widely used, you may adjust your key type accordingly.
 
 === Transfer and install the public key onto the server
 
@@ -84,50 +98,50 @@ You normally use _ssh-copy-id_ to install the public key on the server. However,
 
 a. Log in to your server via sftp using the unprivileged administration account and transfer the public key file
 +
-[source,]
+[source,console]
 ----
-[…]$ sftp hostmin@example.com
+$ sftp hostmin@example.com
 sftp> put ~/.ssh/<outputkeyfile>.pub
 sftp> quit
 ----
 
 b. Log in to your server via ssh using the unprivileged administration account again 
 +
-[source,]
+[source,console]
 ----
-[…]$ ssh  hostmin@example.com
+$ ssh  hostmin@example.com
 ----
 
 c. On the server acquire root permissions, move the key file and adjust permissions
 +
-[source,]
+[source,console]
 ----
-[…]$ sudo su -
-[…]# mkdir /root/.ssh 
-[…]# cd  /root/.ssh
-[…]# mv /home/hostmin/<outputkeyfile>.pub /root/.ssh/authorized_keys
-[…]# chown  -R  root:root  /root/.ssh
-[…]# chmod 700 /root/.ssh
-[…]# chmod 600 ~/.ssh/*
-[…]# restorecon  -R  -vF  /root/.ssh
+$ sudo su -
+# mkdir /root/.ssh 
+# cd  /root/.ssh
+# mv /home/hostmin/<outputkeyfile>.pub /root/.ssh/authorized_keys
+# chown  -R  root:root  /root/.ssh
+# chmod 700 /root/.ssh
+# chmod 600 ~/.ssh/*
+# restorecon  -R  -vF  /root/.ssh
 ----
 
-=== Test and Simplify Access
+=== Test and simplify access
 
 a. On your local workstation test key file based access:
 +
-[source,]
+[source,console]
 ----
-[…]# ssh -i ~/.ssh/<outputkeyfile>  root@example.com
+# ssh -i ~/.ssh/<outputkeyfile>  root@example.com
 ----
 +
 adjust file, file type, and domain name as appropriate.
 
 b. To simplify access create a configuration file on your desktop and define a short name for the connection:
 +
-[source,]
+[source,console]
 ----
-[…]# vi ~/.ssh/config
+# vi ~/.ssh/config
 #  ###########################################################
 #  my remote server, root account
 #  ###########################################################
@@ -146,9 +160,9 @@ again, replace names accordingly.
 
 c. Check if everything works:
 +
-[source,]
+[source,console]
 ----
-[…]# ssh myhost
+# ssh myhost
 ----
 
 == Double check hostname and time synchronisation
@@ -157,40 +171,40 @@ Both are important for trouble-free server operation. Just in case you missed it
 
 a. Check for correct hostname
 +
-[source,]
+[source,console]
 ----
-[…]# hostnamectl
+# hostnamectl
 ----
 * Set hostname if required:
 +
-[source,]
+[source,console]
 ----
-[…]# hostnamectl  set-hostname  <YourFQDN>
+# hostnamectl  set-hostname  <YourFQDN>
 ----
 
 b. Control of time zone, time synchronisation, time 
 +
-[source,]
+[source,console]
 ----
-[…]# timedatectl
+# timedatectl
 ----
 * Correct time zone if necessary:
 +
-[source,]
+[source,console]
 ----
-[…]# timedatectl set-timezone  <ZONE>
+# timedatectl set-timezone  <ZONE>
 ----
 * If necessary, activate time synchronisation:
 +
-[source,]
+[source,console]
 ----
 timedatectl set-ntp true
 ----
 * Correct time if necessary:
 +
-[source,]
+[source,console]
 ----
-[…]# timedatectl set-time  <TIME>
+# timedatectl set-time  <TIME>
 ----
 
 == Consolidate network configuration
@@ -201,22 +215,22 @@ It sounds trivial, but before any change of the network configuration make sure
 
 a. Check IP addresses, interface and which protocol stack is used 
 +
-[source,]
+[source,console]
 ----
-[…]# ip a
+# ip a
 1:  lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc n
          ...
 2:  enp3s0: <BROADCAST,MULTICAST,UP,LOWER
          ...
 
-[…]# nmcli con
+# nmcli con
 NAME    UUID                                  TYPE      DEVICE 
 enp3s0  dabaa33b-25b0-3bfd-8a74-b6b40847a7a4  ethernet  enp3s0 
 
-[…]# who am i 
+# who am i 
 root     pts/5        2021-04-09 21:07 (2003:ca:7f05:xx00:yyyy:zzzz:479a:b36e)
 
-[…]# nmcli -p -f ipv4.method,ipv6.method con show 'enp3s0'
+# nmcli -p -f ipv4.method,ipv6.method con show 'enp3s0'
 =====================================================================
                     Connection details (enp3s0)
 =====================================================================
@@ -230,50 +244,50 @@ ipv6.method:              manual
 
 b. Just in case IPv6 is configured as local only (fe80::....) or not static, you may set up a fixed IPv6
 +
-[source,]
+[source,console]
 ----
-[…]# nmcli con mod 'enp3s0' ipv6.method manual \
+# nmcli con mod 'enp3s0' ipv6.method manual \
   ipv6.addresses <YOUR_IPv6_PREFIX>::2/64 \
   ipv6.gateway fe80::1 \
   ipv6.dns "2a01:4f8:xx:yy::zzz:8888 2a01:4f8:xx:yy::zzz:9999"
-[…]# nmcli con up 'enp3s0'
-[…]# nmcli con reload
+# nmcli con up 'enp3s0'
+# nmcli con reload
 ----
 +
-Again, don't forget to adjust names, prefix, and DNS IP addresses. Pay special attention to the gateway. Using a local address of 1 (fe80::1) is a widely used convention.Another is the IPV6 prefix with the address 1. But each provider may have an even different approach.
+Again, do not forget to adjust names, prefix, and DNS IP addresses. Pay special attention to the gateway. Using a local address of 1 (`fe80::1`) is a widely used convention. Another is the IPV6 prefix with the address 1. But each provider may have an even different approach.
 +
 Check connectivity from your local workstation. If that fails, the gateway configuration is the first suspected culprit.
 +
-[source,]
+[source,console]
 ----
-[…]# ping6 <YOUR_IPv6_PREFIX>::2 
-[…]# # e.g. ping6  2a01:xxx:yyy:zzz::2
+# ping6 <YOUR_IPv6_PREFIX>::2 
+# # e.g. ping6  2a01:xxx:yyy:zzz::2
 ----
 
-c. Optionally reconfigure IPv4 as static. But make sure the IPv6 address works and don't change both protocol stacks at the same time (and in the worst case drop connectivity at all):
+c. Optionally reconfigure IPv4 as static. But make sure the IPv6 address works and do not change both protocol stacks at the same time (and in the worst case drop connectivity at all):
 +
-[source,]
+[source,console]
 ----
-[…]# nmcli con mod 'enp3s0' ipv4.method manual \
+# nmcli con mod 'enp3s0' ipv4.method manual \
   ipv4.addresses <YOUR_IPv4>/27 \
   ipv4.gateway <GATEWAY> \
   ipv4.dns "<DNS1_IPv4> <DNS2_IPv4>"
-[…]# nmcli con up'enp3s0'
-[…]# nmcli con reload
+# nmcli con up'enp3s0'
+# nmcli con reload
 ----
 +
-Again, don't forget to adjust names, prefix, and DNS IP addresses and check connectivity from your local workstation:
+Again, do not forget to adjust names, prefix, and DNS IP addresses and check connectivity from your local workstation:
 +
-[source,]
+[source,console]
 ----
-[…]# ping <YOUR_IPv4> 
+# ping <YOUR_IPv4> 
 ----
 
 d. Optionally you may have a look at the NetworkManager configuration file
 +
-[source,]
+[source,console]
 ----
-[…]# less /etc/NetworkManager/system-connections/enp3s0.nmconnection
+# less /etc/NetworkManager/system-connections/enp3s0.nmconnection
 ----
 
 Finally reboot now to check everything from ground up
@@ -287,26 +301,26 @@ With Fedora 39 the default LVM configuration has changed. The various LVM manage
 Listing the registered devices:: 
 Check the list to see whether all expected devices are included, but also whether each device should actually be part of the current system.
 +
-[source,]
+[source,console]
 ----
-[…]$ sudo lvmdevices 
+$ sudo lvmdevices 
   Device /dev/sda3 IDTYPE=sys_wwid IDNAME=naa.5000000000000000 DEVNAME=/dev/sda3 PVID=IoUGXYfv74B3YrmCoPfh9ZsWZsDrVKAN PART=3
 ----
 
 Adding a device (permanently)::
 This modifies the devices file in /etc/lvm/devices
 +
-[source,]
+[source,console]
 ----
-[…]$ sudo lvmdevices --adddev /dev/<PART>
+$ sudo lvmdevices --adddev /dev/<PART>
 ----
 
 Removing a device (permanently)::
 This modifies the devices file in /etc/lvm/devices
 +
-[source,]
+[source,console]
 ----
-[…]$ sudo lvmdevices --deldev /dev/<PART>
+$ sudo lvmdevices --deldev /dev/<PART>
 ----
 
 
@@ -316,18 +330,20 @@ Depending on how you decided on data storage during installation, different supp
 
 a. If you have chosen the _Default_ partitioning and are content with the basic principle of creating logical volumes for user and any other payload data, there is nothing to do at the moment. The creation of these logical volumes happens in the context of the installation of the corresponding application software. 
 +
-You may ensure that the volume group – default name `fedora` – fills the complete disk. Using Cockpit, in the section `Devices` choose the volume group. At the top of the new window it shows its total capacity.
+You may ensure that the volume group (default name: fedora) fills the complete disk. Using Cockpit, in the section `Storage` you see the available devices and their partitioning as well as Volume Group and Logical Volumes.
 
-b. If you have chosen the _Default_ partitioning but are _not content_ with the basic principle of creating Logical volumes for user and any other payload data you have now to extend the existing root logical volume to accomodate your data. Cockpit provides an easy way for this. Choose _Grow_. Determine the new size as needed.
+b. If you have chosen the _Default_ partitioning but are _not content_ with the basic principle of creating Logical volumes for user and any other payload data but prefer to store everything in one big filesystem,  you have now to extend the existing root logical volume to accommodate your data. 
 +
 [CAUTION]
 ====
-This is not a recommended procedure! Don't complain in case of issues.
+This is not a recommended procedure! Do not complain in case of issues.
 ====
-
-c. If you have decided for a stricter _separation of system and payload data_ and created a small Volume Group for system data, you may have already created an additional partition and Volume Group in Anaconda. Otherwise you have to create it here.
 +
-Select `Storage` in Cockpit's main menu and then your drive  in the right column. Select `Create new partition` and fill in the upcomming form accordingly. In the box "Devices" select from the Menu "Create LVM2 volume group" and fill in the upcomming form accordingly.
+Cockpit provides an easy way for this. On the right side of the 'root' filesystem line select the 3 dot button. Choose _Grow_ for the logical volume. Determine the new size as needed.
+
+c. If you have decided for a stricter _separation of system and payload data_ by using a separate volume group for each, you may have already created an additional partition and Volume Group in Anaconda. Otherwise you have to create it now.
++
+Select `Storage` in Cockpit's main menu and then your drive  in the right column. Select `Create new partition` and fill in the upcoming form accordingly. In the box "Devices" select from the Menu "Create LVM2 volume group" and fill in the upcoming form accordingly.
 
 
 
@@ -343,33 +359,33 @@ include::partial$installation/post-install/install-fail2ban.adoc[]
 
 == Install and configure Logwatch
 
-The software checks log files for anomalies and compiles a daily report that can optionally be sent to system administrators via email. It is something like a minimal defensive effort.  More powerful, but much more involved would be the installation of a monitor software.
+The software checks log files for anomalies and compiles a daily report that can optionally be sent to system administrators via email. It is something like a minimal defensive effort. More powerful, but much more involved would be the installation of a monitor software.
 
 a. Install software
 +
-[source,]
+[source,console]
 ----
-[…]# dnf install  logwatch
+# dnf install  logwatch
 ----
 
 b. The only configuration required is to enter a real email address for root, the recipient of the report. It is added at the end of the file.
 +
-[source,]
+[source,console]
 ----
-[…]# vi /etc/aliases 
+# vi /etc/aliases 
 ...
 # Person who should get root's mail
 #root:          marc
 root:		   real@address.for.root
 
-[…]# newaliases
+# newaliases
 ----
 
 == Disable systemd-resolved LLMNR and/or mDNS
 
 You may want to disable LLMNR and/or mDNS depending on your environment. Both protocols are subject to trivial DNS poisoning attacks by a rogue responder.
 
-[source,]
+[source,console]
 -----
 sudo mkdir -p /etc/systemd/resolved.conf.d
 sudo touch /etc/systemd/resolved.conf.d/20-disable-llmnr-mdns.conf
@@ -387,7 +403,7 @@ You can view the status of LLMNR and mDNS with the following command: `sudo syst
 
 == Manage system updates
 
-It is common sense among system administrators,that regular installation of bug fixes and closing of security vulnerabilities is essential, i.e. applying updates in a systremtatic way. An important step is to automate the process as much as it is reasonable.
+It is common sense among system administrators that regular installation of bug fixes and closing of security vulnerabilities is essential; applying updates in a systematic way. An important step is to automate the process as much as it is reasonable.
 
 // ===============================================================
 include::partial$installation/post-install/manage-dnf-updates.adoc[]
@@ -397,11 +413,11 @@ include::partial$installation/post-install/manage-dnf-updates.adoc[]
 
 == Finally update system and install additional software
 
-Now that secure administrative access is in place, it's time to update the system and install some useful software. Of course, 'useful software' varies depending on the use case or applications that will be run on Fedora Server. Anyway, a good choice might be vim. With vimdiff e.g. a comparison of updates of configuration files (*.rpmnew) is very comfortable and straightforward.
-[source,]
+Now that secure administrative access is in place, it is time to update the system and install some useful software. Of course, 'useful software' varies depending on the use case or applications that will be run on Fedora Server. Anyway, a good choice might be `vim`. With `vimdiff` e.g. a comparison of updates of configuration files (*.rpmnew) is very comfortable and straightforward.
+[source,console]
 ----
-[…]# dnf install vim-default-editor  --allowerasing
-[…]# dnf update
+# dnf install vim-default-editor  --allowerasing
+# dnf update
 ----
 Add to the software list as needed.
 

modules/ROOT/pages/server-communicating.adoc

@@ -1,21 +1,20 @@
-= Communicating and Getting Help
+= Communicating and getting help
 Peter Boy; Jan Kuparinen
-:page-authors: {author}, {author_2}
 :revnumber: All
+:page-authors: {author}, {author_2}
 :revdate: 2021-06-09
-// :revremark: a new beginning
 
 
 For general troubleshooting help related to Fedora, please refer to link:https://ask.fedoraproject.org[Ask Fedora Forum].
-	
+
 If you found a bug, report it!
 
 * link:https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/[How to file a bug].
-	
-* Issues about a server can be filed at link:https://pagure.io/fedora-server/issues[the ticketing repository on Pagure].
-	
-* You can chat with us at link:https://web.libera.chat/?channels=#fedora-server[#fedora-server on libera.chat].
+
+* Issues about a server can be filed at link:https://forge.fedoraproject.org/fedora-server/issues[the ticketing repository on Fedora Forge].
+
+* You can chat with us at link:https://matrix.to/#/#server:fedoraproject.org[#fedora-server on Matrix].
 
 * You can discuss server issues at link:https://discussion.fedoraproject.org/c/server[Server Discussion Forum].
-	
-* You can e-mail us on the Server mailing list at link:https://lists.fedoraproject.org/admin/lists/server@lists.fedoraproject.org/[server@lists.fedoraproject.org].
+
+* You can e-mail us on the Server mailing list at link:https://lists.fedoraproject.org/admin/lists/server@lists.fedoraproject.org/[server@lists.fedoraproject.org].

modules/ROOT/pages/server-faq.adoc

@@ -1,15 +1,14 @@
-= Frequently Asked Questions (FAQ)
+= Frequently asked questions (FAQ)
 Peter Boy; Jan Kuparinen
-:page-authors: {author}, {author_2}
 :revnumber: All
+:page-authors: {author}, {author_2}
 :revdate: 2021-03-09
-// :revremark: a new beginning
 
 
 [qanda]
 Can I see a built preview of this template to get a better idea about the result?::
-    Of course you can! Just look at the README of the repository — it should tell you everything.
+    Of course you can! Just look at the README of the repository. It should tell you everything.
 Is writing documentation hard and dreadful?::
-    Absolutely not (OK, just joking). Writing documentation in asciidoc is very simple and straightforward. And in fact, writing documentation makes you very happy. Just try and see for yourself!
+    Absolutely not (OK, just joking). Writing documentation in AsciiDoc is very simple and straightforward. In fact, writing documentation makes you happy. Just try it yourself!
 How do I manage SELinux issues?::
-    First of all: Don’t deactivate but resolve issues - (Link to Server Sysadmin Cockpit page and Quick Docs) 
+    First of all: Do not deactivate but resolve issues - (Link to Server Sysadmin Cockpit page and Quick Docs)

modules/ROOT/pages/server-on-sbc/index.adoc

@@ -1,27 +1,26 @@
-= Fedora Server on ARM Single Board Computers - the Raspberry Pi & Co.
-Fredrik Arneving; Peter Boy; Jan Kuparinen
-:page-authors: {author}, {author_2}, {author_3}
+= Fedora Server on ARM single-board computers (Raspberry Pi & co.)
+Peter Boy; Jan Kuparinen
 :revnumber: F36,F37
+:page-authors: {author}, {author_2}
 :revdate: 2022-11-15
-// :revremark: a new beginning
 
 
 [abstract]
 Fedora has already supported the ARM architecture, and specifically ARM Single Board Computers (SBCs), for quite some time. Especially for these there is also a Fedora Server Edition installation medium available. But there are a number of pitfalls to be aware of.
 
 
-Once started as an  experimentation and education tool, the technology evolved into an affordable but sufficiently powerful tool for many tasks of everyday life. Even though these devices are very miniature and limited in power, they offer enough strength, to install a dedicated modern, solid Linux system. This is especially true for the newer alternatives to the well known Raspberry Pi.
+Originally introduced as an experimental and educational tool, the technology has evolved into an affordable yet sufficiently powerful solution for many everyday tasks. Although these devices are miniature and limited in power, they provide enough capability to install a dedicated modern, solid Linux system. This is especially true for newer alternatives to the well‑known Raspberry Pi.
 
 SBC Fedora Server Edition takes advantage of the power available on SBC today to install a dedicated modern, solid server system. In the end Fedora Server works on application level exactly as otherwise familiar.
 
 But not all SBC models are equally or similarly capable for a Fedora Server deployment. 
 
 
-== Required Device capabilities
+== Required device capabilities
 
 * The Fedora Server Edition is only available for ARMv8/aarch64.
 
-* A fast wired network adapter is needed.  Some SBCs do not have a dedicated Ethernet interface, but you need a USB adapter. Often only USB 2.0 is available for this or the Ethernet interface is connected internally via a USB 2.0 hub. 
+* A fast wired network adapter is needed. Some SBCs do not have a dedicated Ethernet interface, but you need a USB adapter. Often only USB 2.0 is available for this or the Ethernet interface is connected internally via a USB 2.0 hub. 
 
 * A fast, internal mass storage is required. The always available mSD card is sufficient for installation, but not for operation. An NVMe board connected via PCIe is optimal.
 
@@ -34,7 +33,7 @@ These are just a few criteria that certainly need to be expanded.
 
 Almost all board makers are very enthusiastic about using the open source Linux system to make their hardware usable at all and attractive to a wider audience, saving them the development of their own operating system or the licensing costs for a commercial system. They focus on the development of device drivers for their hardware, instead. In fact, to even boot, many of them require device specific software. 
 
-Unfortunately, manufacturers are sometimes much less enthusiastic to make these drivers freely available under an open source license and to integrate them into the mainline kernel. Their models are  working with Linux, but only in a proprietary tainted version, propriarily customized by the manufacturer.
+Unfortunately, manufacturers are sometimes much less enthusiastic to make these drivers freely available under an open source license and to integrate them into the mainline kernel. Their models work with Linux, but only in a proprietary, tainted version provided by the manufacturer.
 
 Fedora is dedicated and uncompromisingly Free Software, for good reason. All software involved must be open source and freely available. Fedora uncompromisingly insists on the reproducibility of all software components on their own hardware and under their complete control - especially for security and anti-fraud reasons.
 
@@ -52,9 +51,9 @@ Supported by Fedora is not a true/false alternative but a matter of degree and i
 Thus, the question of appropriateness depends much on several criteria and intentions of use.
 
 
-== How Fedora supports the diversity of Single Board Computers
+== How Fedora supports the diversity of single board computers
 
-Fedora distributes a generic Fedora Server Edition image, preconfigured for Raspberry Pi. Additionally, it provides a utility to transfer the image to the prospective boot medium, usually an SD card. To support multiplemodels, the transfer program is able to (re-)configure the disk image for an alternative SBC model. Optionally, it can also make some adjustments to the initial configuration.
+Fedora distributes a generic Fedora Server Edition image, preconfigured for Raspberry Pi. Additionally, it provides a utility to transfer the image to the prospective boot medium, usually an SD card. To support multiple models, the transfer program is able to (re-)configure the disk image for an alternative SBC model. Optionally, it can also make some adjustments to the initial configuration.
 
 == Conclusion
 
@@ -62,6 +61,6 @@ The choice of an SBC model therefore requires careful consideration if you do no
 
 [WARNING]
 ====
-When choosing a device for Fedora Server, check carefully if the available hardware capabilities are compatible with the intended use and are actually supported by Fedora. Take everything with a grain of salt. Don't expect everything to work just smoothly with SBCs. It is best to ask in advance on the arm mailing list.
+When choosing a device for Fedora Server, check carefully if the available hardware capabilities are compatible with the intended use and are actually supported by Fedora. Take everything with a grain of salt. Do not expect everything to work just smoothly with SBCs. It is best to ask in advance on the arm mailing list.
 ====
 

modules/ROOT/pages/server-on-sbc/uboot-installation.adoc

@@ -1,7 +1,7 @@
-= Installation based on __u-boot__ 
-Fredrik Arneving; Peter Boy; Emmanuel Seyman
-:page-authors: {author}, {author_2}, {author_3}
+= Installation based on __u-boot__
+Peter Boy; Emmanuel Seyman
 :revnumber: F37-F43
+:page-authors: {author}, {author_2}
 :revdate: 2025-10-28
 
 :page-aliases: pages/installation-on-sbc.adoc
@@ -9,7 +9,7 @@ Fredrik Arneving; Peter Boy; Emmanuel Seyman
 :page-aliases: pages/installation/on-sbc.adoc
 
 [abstract]
-ARM Single Board Computers originally had only __one data storage medium__, an SD card. And they use to have no BIOS or equivalent firmware to initialize the hardware at boot time and make it accessible. The operating system has to provide this function, too. The u-boot bootloader is one of several options for providing this function.  Therefore, the installation method for SBC devices works quite differently from what is otherwise known from Fedora. 
+ARM single-board computers typically have only __one data storage medium__, an SD card, with no BIOS or equivalent firmware to initialize the hardware at boot time and make it accessible. The operating system has to provide this function, too. The u-boot bootloader is one of several options for providing this function. Therefore, the installation method for SBC devices works quite differently compared to other platforms.
 
 
 // Please, comment in the Warning below when you start
@@ -26,7 +26,7 @@ ARM Single Board Computers originally had only __one data storage medium__, an S
 
 == How it works
 
-Even though many SBC devices now also feature eMMC modules or m.2 NVMe interfaces, the boot process remains very simple. The minimal firmware continues to boot from the SD card, and possibly supplementally from eMMC or an SPI flash module. The device expects a ready-to-use operating system, configured precisely for the respective hardware, including low-level hardware initialization.
+Even though many SBC devices now also feature eMMC modules or m.2 NVMe interfaces, the boot process remains very simple. The minimal firmware continues to boot from the SD card, and may also use eMMC or an SPI flash module. The device expects a ready-to-use operating system, configured precisely for the respective hardware, including low-level hardware initialization.
 
 A widely used software that provides this functionality is the bootloader __u-boot__. It is basically a collection of low-level, model-specific device drivers. 
 
@@ -37,35 +37,35 @@ Even though the installation works quite differently, Fedora Server ultimately f
 
 == Prerequisites
 
-* Of course, you need a *suitable single board computer* model, _supported by Fedora_ and with a network connection, keyboard and display. A simple text console is perfectly sufficient. 
+* Of course, you need a *suitable single board computer* model, _supported by Fedora_ and with a network connection, keyboard, and display. A simple text console is perfectly sufficient. 
 +
 [WARNING]
 ====
-The critical passage is "supported by Fedora". When choosing a device for Fedora Server, check carefully if it is really actually supported. Unlike the x86 universe, don't expect everything to work just as smoothly in ARM rsp. aarch64. Take everything with a grain of salt. It is best to ask in advance on the arm mailing list or Matrix room.
+The critical passage is "supported by Fedora". When choosing a device for Fedora Server, check carefully if it is really actually supported. Unlike the x86 universe, do not expect everything to work just as smoothly in ARM, e.g. aarch64. Take everything with a grain of salt. It is best to ask in advance on the arm mailing list or Matrix room.
 ====
 
 * A *Fedora system*, which provides the Fedora utility program, __arm-image-installer__. 
 +
 The utility should basically be usable with any Linux desktop, but not with Windows or MacOS. You have to install VirtualBox or any other virtualization software that is able to provide direct access to the physical USB port or SD card slot, and install Fedora as a guest system.
 //+
-//If your device is a Raspberry Pi model 3 or 4 you don't need to make any adjustments and can install Balena Etcher instead to transfer the image to the SD card.
+//If your device is a Raspberry Pi model 3 or 4 you do not need to make any adjustments and can install Balena Etcher instead to transfer the image to the SD card.
 
 * A *pluggable disk* of suitable size, practically, this is either an SD card or eMMC storage on a removable daughter board. The absolute minimum capacity is 8 GB, but a capacity of 32 GB should be fine and affordable nowadays.
 
 
 == Special considerations: Organization of the storage area
 
-Basically, Fedora Server on SBC follows the same storage configuration principles as on 'full-blown' Server Hardware. Please, read the section "Storage organization" in the xref:installation/index.adoc#_storage_organization[installation overview] and the supplementary information in the xref:installation/postinstallation-tasks.adoc#_consolidate_storage_configuration[Post installation tasks] section. Fedora Server Edition implements this principle, which originated in professional IT, __on SBCs__ as well. 
+Basically, Fedora Server on SBC follows the same storage configuration principles as on 'full-blown' Server Hardware. Please, read the section "Storage organization" in the xref:installation/index.adoc#_storage_organization[installation overview] and the supplementary information in the xref:postinstallation/index.adoc#_consolidate_storage_configuration[Postinstallation Customizations] section. Fedora Server Edition implements this principle, which originated in professional IT, __on SBCs__ as well. 
 
-Fedora uses UEFI as the boot system, but on SBCs it still uses a DOS/MBR partition table. Therefore, it first creates a FAT partition for EFI and a small /boot partition, used by grub2 bootloader. Thereafter, it creates another partition including one LVM volume group (VG) as described in the forementioned guide.
+Fedora uses UEFI as the boot system, but on SBCs it still uses a DOS/MBR partition table. Therefore, it first creates a FAT partition for EFI and a small /boot partition, used by grub2 bootloader. Thereafter, it creates another partition including one LVM volume group (VG) as described in the aforementioned guide.
 
 For practical reasons, the downloaded deliverable is limited to just under 8 GB in total. During or after installation, the size is adjusted to the existing hardware.
 
-== Handling different boot media 
+== Handling different boot media
 
 Many SBC models today offer additionally alternative storage media, especially eMMC memory, either pluggable or soldered. Nevertheless, the installation procedure remains basically the same. 
 
-These SBCs can alternatively boot and operate directly from this remarkable faster memory. A pluggable memory can be connected to the desktop with an adapter. It is then the target for the image transfer, instead of the SD card.  instead of the SD card. In case of soldered memory, you must first go through the installation process with the SD card, and then use that system to copy an installation image to the internal eMMC memory in a second step. 
+If using a pluggable memory, connect it to the desktop with an adapter; it becomes the target for the image transfer instead of the SD card. For soldered memory, first use the SD card for installation, then copy the image to the internal eMMC memory in a second step. 
 
 Some models provide a special flash module (SPI) to store a custom bootloader. For these cases, the u-boot bootloader offers a special format that is flashed onto the SPI module. This requires a board-specific tool independent from Fedora. The Fedora Server unified basic image file is transferred to the installation medium unchanged. 
 
@@ -74,7 +74,7 @@ These bootloaders quite often support extended options to boot from, e.g. NVMe b
 Here we describe the basic steps for creating a customized boot medium (SD card or eMMC module). 
 
 
-== Steps to install Fedora Server Edition on a Single Board Computer
+== Steps to install Fedora Server Edition on a single-board computer
 
 === Preparations
 
@@ -82,54 +82,54 @@ Here we describe the basic steps for creating a customized boot medium (SD card
 +
 [source,bash]
 ----
-[…]$ sudo dnf -y install  arm-image-installer uboot-images-armv8.noarch
+$ sudo dnf -y install  arm-image-installer uboot-images-armv8.noarch
 ----
 
 2. Set the download directory as default, fetch a Fedora Server aarch64 system disk raw image, here F43, and check the integrity of the download.
 +
 [source,bash]
 ----
-[…]$ cd ~/Downloads
-[…]$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/43/Server/aarch64/images/Fedora-Server-Host-Generic-43-1.6.aarch64.raw.xz
-[…]$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/43/Server/aarch64/images/Fedora-Server-43-1.6-aarch64-CHECKSUM
-[…]$ sha256sum -c *-CHECKSUM  --ignore-missing
+$ cd ~/Downloads
+$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/43/Server/aarch64/images/Fedora-Server-Host-Generic-43-1.6.aarch64.raw.xz
+$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/43/Server/aarch64/images/Fedora-Server-43-1.6-aarch64-CHECKSUM
+$ sha256sum -c *-CHECKSUM  --ignore-missing
 Fedora-Server-Host-Generic-43-1.6.aarch64.raw.xz: OK
 sha256sum: WARNING: 17 lines are improperly formatted
 ----
 +
-The result message includes a complain about some not correct formated lines. It can savely be ignored.
+The result message includes a complaint about some incorrectly formatted lines. It can safely be ignored.
 
 3. Connect your Micro SD card to your desktop. Identify the device name.
 +
 [source,text]
 ----
-[…]$ lsblk
+$ lsblk
 NAME              MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
-sda                 8:0    0 596,2G  0 disk
+sda                 8:0    0 596.2G  0 disk
 ├─sda1              8:1    0   600M  0 part /boot/efi
 ├─sda2              8:2    0     1G  0 part /boot
 ├─sda3              8:3    0    30G  0 part
 │ └─sysvg-root    253:0    0    15G  0 lvm  /
-└─sda4              8:4    0 564,6G  0 part
+└─sda4              8:4    0 564.6G  0 part
   ├─usrvg-var_log 253:1    0     5G  0 lvm  /var/log
   └─usrvg-libvirt 253:2    0   200G  0 lvm  /var/lib/libvirt
-mmcblk0           179:0    0  29,5G  0 disk
-└─mmcblk0p1       179:1    0  29,5G  0 part
-zram0             252:0    0   7,5G  0 disk [SWAP]
+mmcblk0           179:0    0  29.5G  0 disk
+└─mmcblk0p1       179:1    0  29.5G  0 part
+zram0             252:0    0   7.5G  0 disk [SWAP]
 ----
 
 4. In the above example the device is obviously _/dev/mmcblk0_ and its partition (mmcblk0p1) is not mounted anywhere. If it were, you would have to unmount the device.
 +
 [source,bash]
 ----
-[…]$ sudo umount /dev/mmcblk0p1
+$ sudo umount /dev/mmcblk0p1
 ----
 
 5. Identify the name of the support files for your board
 +
 [source,bash]
 ----
-[…]$ sudo arm-image-installer --supported
+$ sudo arm-image-installer --supported
 AllWinner Devices:
 A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM A20-OLinuXino-Lime A20-OLinuXino-Lime2
 A20-OLinuXino-Lime2-eMMC A20-OLinuXino_MICRO A20-Olimex-SOM-EVB Ampe_A76 Auxtek-T003 Auxtek-T004 Bananapi
@@ -148,11 +148,11 @@ Other Devices:
 arndale chiliboard cl-som-am57x rpi2 rpi3 rpi4 olpc_xo175
 ----
 +
-If you don't find your board, check the _boards.d_ directory directly just in case the list is not up to date.
+If you do not find your board, check the _boards.d_ directory directly just in case the list is not up to date.
 +
 [source,bash]
 ----
-[…]$ ls -al /usr/share/arm-image-installer/boards.d  |  less
+$ ls -al /usr/share/arm-image-installer/boards.d  |  less
 ----
 +
 As an example., you will find the PINE64 "ROCKPro64" model as "rockpro64-rk3399"
@@ -161,14 +161,14 @@ As an example., you will find the PINE64 "ROCKPro64" model as "rockpro64-rk3399"
 +
 [source,bash]
 ----
-[…]$ sudo arm-image-installer --image=Fedora-Server-Host-Generic-43-1.6.aarch64.raw.xz --target=rockpro64-rk3399  --media=/dev/mmcblk0
+$ sudo arm-image-installer --image=Fedora-Server-Host-Generic-43-1.6.aarch64.raw.xz --target=rockpro64-rk3399  --media=/dev/mmcblk0
 ----
 +
 Just in case you already decided to fill the complete space on disk with the root file system and to dispense with segmentation, you may add the resizefs parameter which would result in an _alternative command line_:
 +
 [source,bash]
 ----
-[…]$ arm-image-installer --image=Fedora-Server-Host-Generic-43-1.6.aarch64.raw.xz --target=rockpro64-rk3399 --resizefs --media=/dev/mmcblk0
+$ arm-image-installer --image=Fedora-Server-Host-Generic-43-1.6.aarch64.raw.xz --target=rockpro64-rk3399 --resizefs --media=/dev/mmcblk0
 ----
 +
 Remember, this is definitely _not a recommended option_ for serious production server operation!
@@ -180,13 +180,13 @@ Consult the https://fedoraproject.org/wiki/Architectures/ARM/Installation#Arm_Im
 
 === Basic installation and configuration
 
-At the SBC terminal, we perform only the minimum, absolutely necessary configuration, namely the creation of a user including password and administrative privileges. Just in case your network doesn't provide DHCP, you have to configure the IP address as well. Everything else can be more conveniently accomplished via ssh or Cockpit from the desktop.
+At the SBC terminal, we perform only the minimum, absolutely necessary configuration, namely the creation of a user including password and administrative privileges. Just in case your network does not provide DHCP, you have to configure the IP address as well. Everything else can be more conveniently accomplished via ssh or Cockpit from the desktop.
 
 1. make sure that the SBC is disconnected from power.
 2. Connect monitor, keyboard and network cable, insert the micro SD card.
-3. Connect the SBC to power and wait. After some time a lot of messages scroll across the screen. If the network interface doesn't provide DHCP, in includes a NetworkManager error message. You can safely ignore it for now. It finally ends with a simple, text-based input mask for the first boot configuration.
+3. Connect the SBC to power and wait. After some time a lot of messages scroll across the screen. If the network interface does not provide DHCP, in includes a NetworkManager error message. You can safely ignore it for now. It finally ends with a simple, text-based input mask for the first boot configuration.
 +
-[source,]
+[source,console]
 ----
 SoC Rockchip rk3399
 Reset cause: POR
@@ -214,7 +214,7 @@ The menu is quite simple and a bit old-fashioned, but effective and straightforw
 
 4. The most important item is the configuration of an admin user and their password. Type 5 to enter the submenu. 
 +
-[source,]
+[source,console]
 ----
 ================================================================================
 ================================================================================
@@ -256,9 +256,9 @@ If you enter a "c", the user configuration will be closed and you will return to
 +
 Usually, leave the ntp server as is.
 +
-If you are uncomfortable with the entry here, you can also enter this and all the following information later comforatbly with the Web interface. 
+If you are uncomfortable with the entry here, you can also enter this and all the following information later comfortably with the Web interface. 
 
-6. If you don't have a DHCP server on your LAN you may configure network connection in this menu or use the command line in the next stage. Specifically it you use a non-US keyboard it may be tedious and error prone to use this menu. 
+6. If you do not have a DHCP server on your LAN you may configure network connection in this menu or use the command line in the next stage. Specifically it you use a non-US keyboard it may be tedious and error prone to use this menu. 
 +
 Even with DHCP active, it may be useful to set the hostname here, so that an internal DHCP-based name server receives the correct name immediately. Type "3" and fill in your hostname.
 
@@ -274,7 +274,7 @@ Web console: https://localhost:9090/ or https://uuu.vvv.www.xxx:9090/
 rockpro login:
 ----
 +
-The hostname here is default, because the box didn't receive a name from DHCP during first boot. Please note the IP address to use next with ssh or Cockpit.
+The hostname here is default, because the box did not receive a name from DHCP during first boot. Please note the IP address to use next with ssh or Cockpit.
 +
 [IMPORTANT]
 ====
@@ -291,30 +291,30 @@ b. If you are a non-US keyboard user, configure your keyboard mapping. Fist list
 +
 [source,bash]
 ----
-[…]$ localectl list-keymaps
-[…]$ sudo localectl setkeymap de-nodeadkeys
+$ localectl list-keymaps
+$ sudo localectl setkeymap de-nodeadkeys
 ----
 +
-The mapping is imediately active.
+The mapping is immediately active.
 
 c. Configure and activate the network. Adjust the IP, gateway and network settings accordingly.
 +
 First, check the existing interfaces.
 +
-[source,]
+[source,console]
 ----
-[…]# nmcli con
+# nmcli con
 NAME                  UUID                                  TYPE      DEVICE 
 'Wired connection 2'  8d971f49-033f-398a-9714-3a4e848178fb  ethernet  enp2s0 
 ----
 +
-Most likely your interfaces are named somewhat awkward way. Let's fix that to make administration of network easier and more comfortable. Don't forget to adjust the naming to your specific installation!
+Most likely your interfaces are named somewhat awkward way. Let's fix that to make administration of network easier and more comfortable. Do not forget to adjust the naming to your specific installation!
 +
-[source,]
+[source,console]
 ----
-[…]$ sudo nmcli con mod 'Wired connection 1' connection.id end0
+$ sudo nmcli con mod 'Wired connection 1' connection.id end0
 
-[…]$ sudo nmcli con mod end0 \
+$ sudo nmcli con mod end0 \
      ipv4.method manual \
      ipv4.address "xxx.xxx.xxx.xxx/yy" \
      ipv4.gateway "xxx.xxx.xxx.zzz" \
@@ -325,16 +325,16 @@ Most likely your interfaces are named somewhat awkward way. Let's fix that to ma
      ipv6.dns "xxxx.xxxx.xxxx.xxxx::vvv"  \
      connection.zone "FedoraServer"
 
-[…]$ sudo nmcli con up end0 
-[…]$ sudo systemctl  restart  NetworkManager
+$ sudo nmcli con up end0 
+$ sudo systemctl  restart  NetworkManager
 ----
 d. Reboot. You can then disconnect monitor and keyboard. The next steps all happen on the desktop.
 
 
 
-=== Final Configuration
+=== Final configuration
 
-1. On your desktop open a Browser. If you already set the correct hostname and DNS entry, use that. Otherwise, use the IP address for now. In the example above it is __http://192.168.158.172:9090__. After accepting a warning message due to a missing certificate, voilà, the Cockpit administration interface of your SBC appears.
+1. On your desktop open a Browser. If you already set the correct hostname and DNS entry, use that. Otherwise, use the IP address for now. In the example above it is http://192.168.158.172:9090. After accepting a warning message due to a missing certificate, voilà, the Cockpit administration interface of your SBC appears.
 +
 image::installation/on-sbc-020.png[Cockpit Login Screen]
 
@@ -342,11 +342,11 @@ image::installation/on-sbc-020.png[Cockpit Login Screen]
 +
 image::installation/on-sbc-030.png[Cockpit Overview Screen]
 +
-Activate administrative permissins in the top bar.
+Activate administrative permissions in the top bar.
 
 3. First *adjust hostname*
 +
-In the Box "Configuration" click on "__edit__" beside the hostname and enter a short name (display name) and a fqdn name.
+In the Box "Configuration" click on "__edit__" beside the hostname and enter a short name (display name) and an FQDN.
 
 4. *Adjust time and time zone* if necessary and not already done. Click on system time and select the time zone. Automatic time synchronization should already be enabled.
 +
@@ -356,11 +356,11 @@ If a local time server is available in your network, it can be entered here. Man
 +
 Select "Terminal" in the left navigation menu. You get a terminal access to your device, already logged in with your account.
 +
-  a. List available languages by "__localectl list-locales__". Find your locale in the list and note the token, e.g. de_DE.UTF-8. Set the language with "__sudo localeectl  set-locale LANG=TOKEN__", e.g. "__sudo localeectl  set-locale LANG=de_DE.UTF-8__".
+ a. List available languages by `localectl list-locales`. Find your locale in the list and note the token, e.g. `de_DE.UTF-8`. Set the language with `sudo localeectl set-locale LANG=TOKEN`, e.g. `sudo localeectl set-locale LANG=de_DE.UTF-8`.
 +
-  b. List available keyboard mappings by "__localectl list-keymaps__". Find your keymap in the list and note the token, e.g. de-nodeadkeys. Set the keymap with "__sudo localectl  set-keymap MAP_TOKEN__", e.g. "__sudo localectl  set-keymap de-nodeadkeys__".
+  b. List available keyboard mappings by `localectl list-keymaps`. Find your keymap in the list and note the token, e.g. de-nodeadkeys. Set the keymap with `sudo localectl set-keymap MAP_TOKEN`, e.g. `sudo localectl set-keymap de-nodeadkeys`.
 +
-  c. Finally check by "__localeectl__"
+  c. Finally check by `localeectl`
 
 6. To be able to access your account via ssh, you should install your public ssh key.
 +
@@ -368,7 +368,7 @@ Select "accounts" in the left navigation column and choose your account. At the
 +
 If you chose a simple password during the basic installation, you should replace it with a more complex one at this occasion.
 
-7. Most likely, the packages of the distributed file image are not up to date.  In the menu bar on the left, you will probably see an exclamation mark next to "**Software Updates**".  Select this menu item. A search for updates starts and after some time a list of updates appears. Select "Install all updates" and sit back. It will take a while.
+7. Most likely, the packages of the distributed file image are not up to date. In the menu bar on the left, you will probably see an exclamation mark next to "**Software Updates**". Select this menu item. A search for updates starts and after some time a list of updates appears. Select "Install all updates" and sit back. It will take a while.
 +
 If the cockpit packages are also updated, the connection is interrupted. You must then reconnect.
 +
@@ -378,7 +378,7 @@ With everything done reboot the system. In the overview screen select either reb
   a. If your DHCP is correctly configured, you should be able to *find your device by name* now. Close your browser window and start again. Write the device name and port number in the address field, e.g. http://rockpro.example.com:9090 and Cockpit should come up again (after the usual warning about an insecure connection).
   b. You should be able to log in via **ssh and your key**. Try _ssh -i .ssh/MYKEY rockpi.example.com_ and after answering a question to accept the fingerprint you should gain access.
 
-9. Finally, depending on the use case, you may need to ensure you can always track which person was logged in and when. Use Cockpits account management feature to comfortably create additional users and grant them administrativ permissions ("sudo").
+9. Finally, depending on the use case, you may need to ensure you can always track which person was logged in and when. Use Cockpits account management feature to comfortably create additional users and grant them administrative permissions (`sudo`).
 
 
 == Configuration of the storage area
@@ -387,11 +387,11 @@ As explained at the beginning, there are at least three alternatives to organize
 
 1. Filling all the space left after the base installation with the ROOT file system.
 +