server/user-documentation
10
3
Fork 8
Code Issues Pull requests 5 Projects Activity

WIP: stg My edits to the NFS server setup docs #175

Closed
korora wants to merge 7 commits from korora/user-documentation:stg into main
pull from: korora/user-documentation:stg
merge into: server:main
Conversation 7 Commits 7 Files changed 17 +146 -2818
15 changed files with 146 additions and 2818 deletions
Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 8aba0dac9b - Show all commits

First step to synchronize the stg branch to the main banch. See ticket #174

Prev Next
Peter Boy 2025-10-27 12:13:05 +01:00
commit 8aba0dac9b

338
modules/ROOT/pages/administration/dnsmasq.adoc
View file

@ -3,346 +3,24 @@ Peter Boy; Emmmanuel Seyman
:page-authors: {author}, {author_2}
:revnumber: F35-F36
:revdate: 2022-09-23
// :revremark: a new beginning
: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.
____
== 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.
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 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.
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.
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.
In case dnsmasq is not already installed
[source,]
----
[…]# dnf install dnsmasq
----
[IMPORTANT]
[WARNING]
====
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.
**You are in the Fedora Server documentation staging area!**
Calling systemctl directly would be ineffective and would rather start yet another dnsmasq instance, which leads to conflicts.
====
This place is intended for
* discussing and improving new articles
* reviewing and correcting changes to existing articles
== Basic configuration
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
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`.
*Status of this document*: No changes
[TIP]
Study the https://docs.fedoraproject.org/en-US/fedora-server/administration/dnsmasq/[published documentation].
====
NetworkManager reads all files in that directory, independantly of the file extension. So you can't temporarily deactivate a configuration by renameing 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.
1. Activate the dnsmasq NetworkManager plugin
+
[source,]
----
[…]# 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>
----
2. Configuration of the name resolution (DNS) for the private network (example.lan)
+
[source,]
----
[…]# 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>
----
3. Configuration of the DHCP service for the private network (example.lan)
+
[source,]
----
[…]# 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
----
4. Configuration of the DHCP service for the public network (example.com)
+
[source,]
----
[…]# 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
----
6. Disabling the systemd-resolved stub resolver
+
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,]
----
[…]# 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
----
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
If machines in the private network need access to the public network, add masquerading / NAT to the firewall.
1. Enabling masquerading for the public zone and for the internal (trusted) trusted zone
+
[source,]
----
[…]# firewall-cmd --zone=FedoraServer --add-masquerade --permanent
success
[…]# firewall-cmd --zone=trusted --add-masquerade --permanent
success
[…]# firewall-cmd --reload
[…]# firewall-cmd --zone=FedoraServer --query-masquerade
yes
[…]# firewall-cmd --zone=trusted --query-masquerade
yes
----
2. Allowing forwarding from the internal, private network to the external interface and
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,]
----
[…]# 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
success
[…]# 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
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,]
----
[…]# firewall-cmd --get-active-zones
FedoraServer
interfaces: enp1s0
trusted
interfaces: vbr2s0 enp2s0
[…]# firewall-cmd --permanent --new-policy trustedToExt
success
[…]# firewall-cmd --permanent --policy trustedToExt --add-ingress-zone trusted
success
[…]# firewall-cmd --permanent --policy trustedToExt --add-egress-zone FedoraServer
success
[…]# firewall-cmd --permanent --policy trustedToExt --set-target ACCEPT
success
[…]# firewall-cmd --reload
success
----
+
This method is much clearer, improves maintainability and reduces sources of potential errors. The documentation of the upstream project provides https://firewalld.org/2020/09/policy-objects-introduction[more information].
== 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.
To make it work, just add onother configuration file. 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,]
----
[…]# vim /etc/NetworkManager/dnsmasq.d/20-DNS-libvirt-lan.conf
<i>
# /etc/NetworkManager/dnsmasq.d/20-DNS-libvirt-lan.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>
----
== Managing static DNS Entries
1. Edit the dnsmasq host file
+
The format is the same as /etc/hosts .
+
[source,]
----
[…]# vim /etc/dnsmasq.hosts
----
2. Restart NetworkManager to read the modified file.
+
[source,]
----
[…]# systemctl restart NetworkManager
----
3. Test the modification
+
[source,]
----
[…]# nslookup {NAME}
[…]# nslookup {NAME}.example.lan
----

37
modules/ROOT/pages/administration/index.adoc
View file

@ -6,37 +6,20 @@ Peter Boy; Jan Kuparinen; Emmanuel Seyman
:page-aliases: pages/sysadmin-an-introduction.adoc
== What You Find Here
General basic system administration is covered in Fedora's overall
//xref:fedora::system-administrators-guide.adoc[System Administrator's Guide].
System Administrator's Guide. However, there are some Fedora Server-specific topics that are not included therein.
[WARNING]
====
**You are in the Fedora Server documentation staging area!**
This section covers topics like name resolution tools, DHCP support, special network configuration, local disk space management, and similar topics. Other sections address specific topics such as xref:virtualization/index.adoc[virtualization] or xref:containerization/index.adoc[containerization].
//, or xref:services/index.adoc[providing services].
This place is intended for
_Currently, the compilation and description of administrative tasks is still under construction. It will be continuously expanded._
* discussing and improving new articles
* reviewing and correcting changes to existing articles
== Administrative Tools
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
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).
*Status of this document*: No changes
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.
Study the https://docs.fedoraproject.org/en-US/fedora-server/administration/[published documentation].
====
//=== Comand 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.
== 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.
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].

142
modules/ROOT/pages/administration/point-to-point-connection.adoc
View file

@ -4,136 +4,22 @@ Peter Boy
:revnumber: all up to F38
:revdate: 2023-04-18
//[NOTE]
//====
//**Status:** ready for review (2022-12-23)
//====
[abstract]
--
This configuration is a special case for environments with specific security requirements, where the connection of network nodes to each other is subject to limitation and control.
--
== How it works
Typically, a server (or desktop) is directly connected to a local network and all devices can connect directly to each other. In some environments, this is exactly what is not desired. Instead, each server (or desktop) is limited to connect directly only to a network access device, which can filter, block, or allow the data stream according to a variety of criteria. Typical use cases are high-security environments or data centers that offer collocation or dedicated, self-administered servers. In the latter case, the aim is simply to prevent administrators from inadvertently "hijacking" other customer's IP addresses by typing errors.
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.
For an IPv6 configuration, it is sufficient to specify the link address of the gateway.
== Configuration of current Fedora releases
[WARNING]
====
**You are in the Fedora Server documentation staging area!**
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,]
----
[…]# 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 place is intended for
* discussing and improving new articles
* reviewing and correcting changes to existing articles
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
*Status of this document*: No changes
Study the https://docs.fedoraproject.org/en-US/fedora-server/administration/point-to-point-connection/[published documentation].
====
This will result in a configuration file like
[source,]
----
[…]# less /etc/NetworkManager/system-connections/enp1s0.nmconnection
[connection]
id=enp1s0
uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
type=ethernet
interface-name=enp1s0
timestamp=1671717608
[ethernet]
[ipv4]
address1=192.168.133.100/32,192.168.133.1
dns=192.172.1.1
method=manual
[ipv6]
addr-gen-mode=eui64
address1=2a01:4f8:xxx:yyyy::2/64,fe80::1
dns=2a01:4f8:xxx:yy::zzz:1010;
method=manual
[proxy]
----
An alternative notation for the IPv4 part is
[source,]
----
[ipv4]
address1=192.168.133.100/32
method=manual
route1=0.0.0.0/0,192.168.133.1
----
In any case you get a
[source,]
----
[…]# 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
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,]
----
[…]# vim /etc/sysconfig/network-scripts/ifcfg-enp1s0
DEVICE=enp1s0
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.133.100
PREFIX=32
SCOPE="peer 192.168.133.1"
DEFROUTE=yes
IPV6INIT=yes
IPV6ADDR=2a01:4f8:xxx:yyyy::2/64
IPV6_DEFAULTGW=fe80::1
IPV6_DEFROUTE=yes
IPV6_DEFAULTDEV=enp1s0
----
Additionally you need a routing table.
[source,]
----
[…]# 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,]
----
[…]# 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
----
== 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,]
----
[…]# vim /etc/systemd/network/10-public.network
[Match]
MACAddress=12:34:56:78:9a:bc # or another identifier
[Network]
Gateway=192.168.133.1
[Address]
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.

197
modules/ROOT/pages/administration/virtual-routing-bridge.adoc
View file

@ -4,197 +4,20 @@ Peter Boy; Kevin Fenzi
:revnumber: F37,F38
:revdate: 2023-04-18
[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.
--
//[NOTE]
//====
//**Status:** work in progress
//====
Basically there a two ways to set up a virtual bridge.
[WARNING]
====
**You are in the Fedora Server documentation staging area!**
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.
This place is intended for
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.
* discussing and improving new articles
* reviewing and correcting changes to existing articles
This article deals with the latter variant.
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
== Prerequisites
*Status of this document*: No changes
. 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.
. Set up DNS entries for the projected VMs
== Steps to configure a basic routing bridge
1. Check the forwarding configuration
+
[source,]
----
[…]# 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
+
[source,]
----
[…]# echo 1 > /proc/sys/net/ipv4/ip_forward
[…]# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
----
+
The following file must be set up for permanent setup.
+
[source,]
----
[…]# vim /etc/sysctl.d/50-enable-forwarding.conf
# local customizations
#
# enable forwarding for dual stack
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
----
2. Checking the existing interfaces
+
[source,]
----
[…]# 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
…
----
3. Adjusting 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.
+
[source,]
----
[…]# nmcli con mod enp2s0 ipv6.addresses '2a01:4f8:210:512d::2/128'
[…]# nmcli con up enp2s0
----
4. Creating 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.
+
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.
+
[source,]
----
[…]# 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!
+
Finally, for IPv4, the routes must be created and the public addresses of all VMs must be listed
+
[source,]
----
[…]# 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"
----
5. Double check your entries, especially the IP addresses, to avoid incorrect configuration and time-consuming troubleshooting.
6. Activate the routing bridge
+
[source,]
----
[…]# nmcli con up vbr1s0
----
7. Installing a VM
+
Use Cockpit or the command line
+
[source,]
----
[…]# 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 \
--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.
8. Login to the VM and configure the public interface
+
[source,]
----
[…]# 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
----
9. If exist 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
----
10. Optionally reboot to reinitialize everything
+
[source,bash]
----
[…]# reboot
----
=== Testing the configuration
1. Check the forwarding configuration
+
[source,]
----
[…]# 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.
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.
+
[source,bash]
----
[…]# getenforce
[…]# firewall-cmd --list-all
[…]# firewall-cmd --get-active-zones
----
3. Check IPv6
(a) ping6 external desktop → host (using ipv6 notation)
(b) ping6 host → VM
(c) ping6 external desktop → VM
(d) ssh external desktop → VM
(e) traceroute6 external desktop → host
(f) traceroute6 external desktop → VM
4. Check IPv4
(a) ping external desktop → host (using ipv4 notation)
(b) ping host → VM
(c) ping external desktop → VM
(d) ssh external desktop → VM
(e) traceroute external desktop → host
(f) traceroute external desktop → VM
Study the https://docs.fedoraproject.org/en-US/fedora-server/administration/virtual-routing-bridge/[published documentation].
====

92
modules/ROOT/pages/containerization/index.adoc
View file

@ -6,92 +6,20 @@ Peter Boy
// :revremark: a new beginning
:page-aliases: container-an-introduction.adoc
Since some years "Container" are on everyone's lips. It's a prominent subject of public dicsussion. Complete operating systems are rebuilt to serve primarily as runtime environments for containers. And in public discussion "container" are mostly equated with "Docker". It is hard to find software that is not at least also offered as a Docker image. And it didn't take long for the disadvantages of such a monopolization to become apparent, e.g. in the form of serious security risks.
As we learn time and time again, one size does not fit all. A number of the advantages of containerization are widely agreed upon. But the needs and requirements in IT are so diverse that not all of them can be optimally realized by one implementation. Therefore, there are alternative container implementations with different application profiles. And containerization is not always helpful either.
[WARNING]
====
**You are in the Fedora Server documentation staging area!**
*Fedora Server supports and allows several alternatives that can be used depending on the local context and/or user's requirement profile.*
This place is intended for
== Containerization options in Fedora Server
* discussing and improving new articles
* reviewing and correcting changes to existing articles
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.
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
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.
*Status of this document*: No changes
=== Podman
Its characteristics are
* Application container
* Security enhancement: no root privileges and no central controlling daemon required
* Optimized for the interaction of multiple, coordinated containers (a "pod"), each dedicated to a specific task and cooperating with others to accomplish a complex overall task (e.g. customer management with connection to a specific database system). Reinforces the architecture principle: one and only one application per container.
* Binary compatible container image as Docker, mutually usable
* Free open source software
Podman is *natively supported by Fedora Server* and the recommended solution for application containers.
=== Docker
Its characteristics are
* Application container
* Dependent on a daemon with ROOT privileges
* Huge trove of pre-built containers for all sorts of software
* Mixture of a free community edition and a commercial product
Docker releases it own Community Edition for various distributions. Therefore there is *no native support* for Fedora Server, but a *vendor repository* maintained for Fedora.
=== LXC (libvirt)
Its characteristics are
* System container, kind of "lightweight virtual machine"
* Administration of container runtimes supported by Libvirt management routines for virtual machines as well as by Cockpit libvirt module
* Container runtime solely dependent on kernel capabilities, no own toolset
* Creation of a container disk image is not considered a task of libvirt, but a matter for the administrator. It includes composing a xml-based descriptor file. Therefore, the toolset is rated as somewhat "rough".
* Free open source software
Libvirt LXC is *natively supported by Fedora Server* (via libvirt as default virtualization tool)
=== LXC (linux containers)
Its characteristics are
* System container
* One of the first implementations of containers and the "progenitor" of (meanwhile emancipated) Docker and Podman
* Complete toolset, container images, community. Its designated successor is LXD (see next).
* Free open source software
Linux Container's LXC is *natively supported by Fedora Server* (in its LTS versions)
=== LXD (linux containers)
Its characteristics are
* System container, kind of "lightweight virtual machine"
* LXC with advanced toolset
* Complete versatile toolset, including container images and active supportive community.
* Free open source software
LXD is *not natively supported* by Fedora Server, but there is a *COPR project* available, Additionally there is *vendor support* for Fedora by a third party package manager.
=== systemd-nspawn container
Its characteristics are
* System container as a "lightweight virtual machine" and also configurable as a kind of application container (with a stub init system)
* Toolset highly integrated into systemd system management and thus a strong simplification of administration and maintenance.
* Both technically stringent and systematic documentation as well as stringent naming and structuring of the toolset, which facilitates administration.
* Rather new development and currently still somewhat rough SELinux support (so far its weakest point).
* Free open source software
The systemd-nspawn container is *natively supported by Fedora Server*.
=== Linux Vserver
It requires a modified kernel and is *not supported by Fedora Server*
=== OpenVZ
It uses a self customized version of RHEL / CentOS and is *not supported by Fedora Server*
Study https://docs.fedoraproject.org/en-US/fedora-server/containerization/[published documentation].
====

635
modules/ROOT/pages/containerization/systemd-nspawn-setup.adoc
View file

@ -6,637 +6,22 @@ Peter Boy; Jan Kuparinen
// :revremark: a new beginning
:page-aliases: container-nspawn-install.adoc
The systemd-nspawn container runtime is part of the systemd system software. It has been offloaded into its own package, systemd-container, a while ago.
The prerequisite is a fully installed basic system. A standard interface of the host to the public network is assumed, via which the container receives independent access (own IP). In addition an interface for an internal, protected net between containers and host is assumed, usually a bridge. It may be a virtual network within the host, e.g. libvirts virbr0, or a physical interface connecting multiple hosts.
But of course a container can also be operated with other variations of a network connection or even without a network connection at all.
[WARNING]
====
**You are in the Fedora Server documentation staging area!**
== 1. Setting up the nspawn container infrastructure
This place is intended for
1. *Create a container storage area*
+
The systemd-nspawn tools like machinctl look for containers in `/var/lib/machines` first. This directory is also created during the installation of the programs if it does not exist.
+
Following the Fedora server storage scheme, create a logical volume, create a file system and mount it to `/var/lib/machines`. The tools can use BTRFS properties, so this can be used as a filesystem in this case.
If you don't want to follow the Fedora Server rationale, skip this step.
+
[source,]
----
[…]# dnf install btrfs-progs
[…]# lvcreate -L 20G -n machines {VGNAME}
[…]# mkfs.btrfs -L machines /dev/mapper/{VGNAME}-machines
[…]# mkdir /var/lib/machines
[…]# vim /etc/fstab
(insert)
/dev/mapper/{VGNAME}-machines /var/lib/machines auto 0 0
* discussing and improving new articles
* reviewing and correcting changes to existing articles
[…]# mount -a
----
2. *Check and, if necessary, correct the SELinux labels*
+
Ensure that the directory belongs to root and can only be accessed by root (should be done by the installer).
+
[source,]
----
[…]# restorecon -vFr /var/lib/machines
[…]# chown root:root /var/lib/machines
[…]# chmod 700 /var/lib/machines
----
3. *Adding configuration for nspawn to the `etc/systemd` directory*
+
[source,]
----
[…]# mkdir /etc/systemd/nspawn
----
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
== 2. Creating a nspawn container
*Status of this document*: No changes
=== 2.1 Creating a container directory tree
Study the https://docs.fedoraproject.org/en-US/fedora-server/containerization/systemd-nspawn-setup/[published documentation].
====
The creation of a container filesystem or the provision of a corresponding image is treated as "out of scope" by systemd-nspawn. There are a number of alternative options. By far the easiest and most efficient way is simply to use the distribution specific bootstrap tool, DNF in case of fedora, in the container’s directory. This is the recommended procedure.
1. Creating a BTRFS subvolume with the name of the container
+
[source,]
----
[…]# cd /var/lib/machines
[…]# btrfs subvolume create {ctname}
----
2. Creating a minimal container directory tree
+
**__Fedora 34 / 35__**
+
[source,]
----
[…]# dnf --releasever=35 --best --setopt=install_weak_deps=False --installroot=/var/lib/machines/{CTNAME}/ \
install dhcp-client dnf fedora-release glibc glibc-langpack-en glibc-langpack-de iputils less ncurses passwd systemd systemd-networkd systemd-resolved vim-default-editor
----
+
F34 installs 165 packages (247M) and allocates 557M in the file system.
F35 installs 174 packages (270M) and allocates 527M in the file system.
+
**__Fedora 36__**
+
[source,]
----
[…]# dnf --releasever=36 --best --setopt=install_weak_deps=False --installroot=/var/lib/machines/{CTNAME}/ \
install dhcp-client dnf fedora-release glibc glibc-langpack-en glibc-langpack-de iputils less ncurses passwd systemd systemd-networkd systemd-resolved util-linux vim-default-editor
----
+
F36 installs 171 packages (247M) and allocates 550M in the file system.
+
**__CentOS 8-stream__**
+
First create a separate CentOS repository file (e.g. /root/centos.repo) and import CentOS keys.On this basis, perform a standard installation using DNF.
+
[source,]
----
[…]# vim /root/centos8.repo
<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.
=== 2.2 Configuration and commissioning of a system container
1. Setting the password for root
+
This requires temporarily setting SELinux to permissive, otherwise passwd will not make any changes.
+
[source,]
----
[…]# setenforce 0
[…]# systemd-nspawn -D /var/lib/machines/{ctname} passwd
[…]# setenforce 1
----
2. Provision of network interfaces for the container within the host
+
If only a connection to an internal, protected network is needed (replace the host bridge interface name accordingly):
+
[source,]
----
[…]# vim /etc/systemd/nspawn/{ctname}.nspawn
(insert)
[Network]
Bridge=vbr6s0
----
+
If a connection to the external, public network is also required, two corresponding interfaces must be provided, whereby a mac-vlan is used on the interface of the host for the external connection (again, replace the host interface names accordingly).
+
[source,]
----
[…]# vim /etc/systemd/nspawn/{ctname}.nspawn
(insert)
[Network]
MACVLAN=enp4s0
Bridge=vbr6s0
----
3. Configuration of the connection to the internal network within the container
+
[source,]
----
[…]# vim /var/lib/machines/{ctname}/etc/systemd/network/20-host0.network
(insert)
# {ctname}.localnet
# internal network interface via bridge
# static configuration, no dhcp defined
[Match]
Name=host0*
[Network]
DHCP=no
Address=10.10.10.yy/24
#Gateway=10.10.10.10
LinkLocalAddressing=no
IPv6AcceptRA=no
----
+
If the internal network is also to be used for external access via NAT, the gateway entry must be commented in. Otherwise do not!
4. Optionally, configure an additional connection to the public network via Mac Vlan
+
In this case, the gateway entry _must_ be commented _out_ in the configuration of the internal network, as mentioned in item 3.
+
[source,]
----
[…]# vim /var/lib/machinec/{ctname}/etc/systemd/network/10-mv.network
(insert)
# {ctname}.sowi.uni-bremen.de
# public interface via mac-vlan
# static configuration, no dhcp available
[Match]
Name=mv-enp*
[Link]
ARP=True
[Network]
DHCP=no
# IPv4 static configuration, no DHCP configured!
Address=134.102.3.zz/27
Gateway=134.102.3.30
# without Destination specification
# treated as default!
#Destination=
# IPv6 static configuration
Address=2001:638:708:f010::zzz/64
IPv6AcceptRA=True
Gateway=2001:638:708:f010::1
# in case of issues possible workaround
# cf https://github.com/systemd/systemd/issues/1850
#GatewayOnlink=yes
[IPv6AcceptRA]
UseOnLinkPrefix=False
UseAutonomousPrefix=False
----
+
Don't forget to adjust interface names and IP addresses accordingly!
5. Boot the container and log in
+
Check if container boots without error messages
+
[source,]
----
[…]# systemd-nspawn -D /var/lib/machines/{ctname} -b
OK Spawning container {ctname} on /var/l…01.
OK …
{ctname} login:
----
6. Checking the status of systemd-networkd
+
If inactive, activate and start the service.
+
[source,]
----
[…]# systemctl status systemd-networkd
…
[…]# systemctl enable systemd-networkd
[…]# systemctl start systemd-networkd
[…]# systemctl status systemd-networkd
----
7. Check if all network interfaces are available
+
[source,]
----
[…]# ip a
----
8. Check for correct routing
+
[source,]
----
[…]# ip route show
----
9. Configure default DNS search path
+
Specify a search domain to appended to a unary hostname without domain part, usually the internal network domain name, e.g. example.lan. Adjust the config file according to the pattern below:
+
[source,]
----
[…]# vim /etc/systemd/resolved.conf
[Resolve]
...
#dns.quad9.net
#DNS=
#FallbackDNS=
#Domains=
Domains=example.lan
#DNSSEC=no
...
----
10. Check if name resolution is configured correctly
+
[source,]
----
[…]# ls -al /etc/resolv.conf
lrwxrwxrwx. 1 root root 39 29. Dez 12:15 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
----
+
If the file is missing or is a text file, correct it.
+
[source,]
----
[…]# cd /etc
[…]# rm -f resolv.conf
[…]# ln -s ../run/systemd/resolve/stub-resolv.conf resolv.conf
[…]# ls -al /etc/resolv.conf
[…]# cd
----
+
Ensure that systemd-resolved service is enabled.
+
[source,]
----
[…]# systemctl status systemd-resolved
----
+
Activate the service if necessary.
+
[source,]
----
[…]# systemctl enable systemd-resolved
----
11. Set the intended hostname
+
[source,]
----
[…]# hostnamectl
[…]# hostnamectl set-hostname <FQDN>
----
12. Terminate the container
+
[source,]
----
[…]# <CTRL>+]]]
Container <CTNAME> terminated by signal KILL.
----
=== 2.2 Configuration and commissioning of an application container
1. Setting the password for root
+
This requires temporarily setting SELinux to permissive, otherwise passwd will not make any changes.
+
[source,]
----
[…]# setenforce 0
[…]# systemd-nspawn -D /var/lib/machines/{ctname} passwd
[…]# setenforce 1
----
2. Configuration of container properties
+
Specifying private user configuration and shared network access.
+
[source,]
----
[…]# vim /etc/systemd/nspawn/{ctname}.nspawn
(insert)
[Exec]
PrivateUsers=false
[Network]
Private=off
VirtualEthernet=false
----
3. Boot the container and log in
+
Check if container boots without error messages
+
[source,]
----
[…]# systemd-nspawn -b -D /var/lib/machines/{ctname}
OK Spawning container {ctname} on /var/l…01.
OK …
{ctname} login:
----
4. Checking the status of systemd-networkd
+
If active, deactivate the service.
+
[source,]
----
[…]# systemctl status systemd-networkd
…
[…]# systemctl disable systemd-networkd
[…]# systemctl stop systemd-networkd
[…]# systemctl status systemd-networkd
[…]# systemctl status systemd-resolved
…
[…]# systemctl disable systemd-resolved
[…]# systemctl stop systemd-resolved
[…]# systemctl status systemd-resolved
----
+
If file /etc/resolv.conf is a link, remove it.
+
[source,]
----
[…]# rm /etc/resolv.conf
----
+
Create (or edit an existing) file /etc/resolv.conf
+
[source,]
----
[…]# vim /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search <YOUR_DOMAIN>
----
5. Check if all network interfaces are available
+
[source,]
----
[…]# ip a
----
+
You should see the same interfaces and IP addresses as on the host system.
6. Check if name resolution is working correctly
+
[source,]
----
[…]# ping spiegel.de
PING spiegel.de (128.65.210.8) 56(84) bytes of data.
64 bytes from 128.65.210.8 (128.65.210.8): icmp_seq=1 ttl=59 time=19.8 ms
...
----
7. Set the intended hostname
+
[source,]
----
[…]# hostnamectl
[…]# hostnamectl set-hostname <FQDN>
----
8. Terminate the container
+
[source,]
----
[…]# <CTRL>+]]]
Container <CTNAME> terminated by signal KILL.
----
== 3. Starting the container as a system service for productive operation
1. Booting the container using systemctl
+
In this step, a separate UID/GID range is automatically created for the container.
+
[source,]
----
[…]# systemctl enable systemd-nspawn@{ctname}
[…]# systemctl start systemd-nspawn@{ctname}
[…]# systemctl status systemd-nspawn@{ctname}
----
+
On first boot after installing systemd-container, a SELinux bug currently (Fedora 34/35) blocks execution. The solution is to fix the SELinux label(s).
+
* Select the SELinux tab in Cockpit, preferably before booting the container for the first time.
* There, the AVCs are listed and solutions are offered, such as:
+
`type=AVC msg=audit(1602592088.91:50075): avc: denied { search } for pid=35673 comm="systemd-machine" name="48865" dev="proc" ino=1070782 scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=dir permissive=0`
+
The proposed solution is roughly as follows:
+
[source,]
----
[…]# ausearch -c 'systemd-machine' --raw | audit2allow -M my-systemdmachine
[…]# semodule -i my-systemdmachine.pp
----
* The operation must be repeated until no SELinux error is reported and the container starts as a service.
+
Alternatively, the SELinux CLI tool can be used, which also suggests these solutions.
2. Enable automatic start of the container at system startup
+
[source,]
----
[…]# systemctl enable systemd-nspawn@{ctname}
[…]# systemctl status systemd-nspawn@{ctname}
----
3. Log in to the container
+
[source,]
----
[…]# setenforce 0
[…]# machinectl login {ctname}
----
+
When machinectl is called with parameters for the first time, an SELinux bug (Fedora 34/35) also blocks execution. The correction is done in the same way as for the container start.
4. Completing and finalizing the container configuration
+
Within the container, perform other designated software installations and customizations.
+
In case of a CentOS 8-stream container, the epel repository should be installed (dnf install epel-release-latest-8) so that systemd-networkd is provided with updates.
5. Logging off from the container
+
After finishing all further work inside the container press <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
You will find message such as
[source,]
----
dev-hugepages.mount: Mount process exited, code=exited, status=32/n/a
dev-hugepages.mount: Failed with result 'exit-code'.
[FAILED] Failed to mount Huge Pages File System.
See 'systemctl status dev-hugepages.mount' for details.
----
DFN installs this by default, but it is not applicable inside a container. It is a general kernel configuration that cannot be changed by a container (at least as long as it is not configurable within namespaces).
The messages can be safely ignored.
=== 4.3 Package update may fail
Some packages, e.g. the `filesystem` package, may not get updated in a container (error message "Error: Transaction failed"), see also https://bugzilla.redhat.com/show_bug.cgi?id=1548403 and https://bugzilla.redhat.com/show_bug.cgi?id=1912155.
Workaround: Run before update:
[source,]
----
[…]# echo '%_netsharedpath /sys:/proc' > /etc/rpm/macros.netshared
----
When an update has already been performed, execute this command and update the package again.
As of Fedora 35, the bug should be fixed.

142
modules/ROOT/pages/index.adoc
View file

@ -1,143 +1,25 @@
= Fedora Server Documentation
Peter Boy; Jan Kuparinen; Peter W. Smith
:page-authors: {author}, {author_2}, {author_3}
:revnumber: F38-F41
:revdate: 2024-10-28
:revnumber: F38-F43
:revdate: 2025-10-27
// :revremark:
image::Logo_server2.png[Server]
== Our Mission
[WARNING]
====
**You are in the Fedora Server documentation staging area!**
*As a user, you gain the opportunity to use the server of the future right now.*
This place is intended for
Fedora Server provides a stable, flexible and universally adaptable basis for the everyday provision of digital services and information, suitable for use by all kinds of organizations and individuals.
It is based on the latest technology and as such, brings the most modern environment to users as early as possible.
* discussing and improving new articles
* reviewing and correcting changes to existing articles
*As a developer or system integrator, you preview the server of the future.*
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
Fedora Server is a platform for developers and system integrators, providing an implementation of the latest server technology for further evaluation and practical use.
You would probably prefer to study the https://docs.stg.fedoraproject.org/en-US/fedora-server/[published documentation].
== 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 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.
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.
Note that the configuration of LVM has changed. The CLI commands now only take into account partitions that are listed in `lvmdevices`.
If you use postgresql, please note that the major version has increased from 15.6 to 16.1. This means that the database tables need to be adapted.
== Why Use Fedora Server
Fedora Server Edition offers users and system administrators several attractive features:
* *You get the latest software almost immediately*: Fedora Server's biannual release cycle allows for the inclusion of the latest versions of system and application software almost immediately. This empowers users and system administrators to swiftly respond to new market options and changing or expanding customer requirements.
* *You can trust it*: Fedora Server has a sophisticated and highly engineered release and quality assurance process, which enables a high level of reliability and stability, despite a comparatively fast release cycle. It therefore achieves an excellent balance between 'bleeding edge' and maturity for productive use in mainstream deployments.
* *Confidence in security*: Enterprise-grade security minded, the Fedora release engineering results in carefully pre-configured releases, offering uncompromising security without prior extensive configuration by system administrators.
* *You can get what you need*: Fedora Server has an extensive collection of available packages, all of them subject to the same extensive release process. This opens up a wide range of possibilities for building a server very flexibly according to customer specific needs and wishes.
* *It will help ease a sysadmin workload*: Fedora Server includes the latest stable versions of modern sysadmin tools (i.e. cockpit, dnf, systemd), noticeably reducing the burden of system administration.
* *Less disruption with upgrades*: Fedora Server's short release cycle means less disruptive release jumps. There is a very easy update process without re-installation requirements. There is also the option to skip one release cycle in case new capabilities are not immediately needed. Several small updates are easier to manage than a few big updates.
* *You've got the freedom you want*: Fedora Server allows utmost freedom from restrictions imposed by commercial interests or corporate feature management, combined with excellent backward hardware compatibility (including a complete set of standard kernel drivers).
* *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?
Currently, several projects are in development:
- Further Improvements to the documentation
- Facilitation of the deployment of key services by combining rpm and Ansible
== 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.
- Please, tell us about your usage of Fedora Server
- Tell us about problems you found and how you resolved it
The easiest way is to write on our mailing list. It is a low traffic list specifically for Fedora Server Edition. It is open to everyone.
Another option is our ticket system at https://pagure.io/fedora-server/issues. However, this requires a FAS account, which you can create at link:https://accounts.fedoraproject.org[Fedora accounts]
You can also chat with us at
https://web.libera.chat/?channels=#fedora-server[#fedora-server] on libera.chat.
For additional information refer to https://docs.fedoraproject.org/en-US/fedora-server/server-communicating/[Getting in Touch]
== About previous versions of Fedora Server
=== 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.
=== 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.
=== 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.
=== 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.
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].
=== Updating to Fedora 36
Upgrading using the dnf upgrade process is fully tested and supported. No issues were found during the release tests.
A major change relates to the network configuration. It requires a manual adjustment until the next release. But no need to hurry.
For new installations, configuration files in `/etc/NetworkManager/system-connections` _replace_ the previous `ifcfg` files in `/etc/sysconfig/network-scripts`. The latter are still supported in this release for existing installations. Therefore, updating is undisturbed and the recommended procedure. The next release will remove the support. Therefore, the configuration must be transferred to the new location. This requires system administrator intervention, there is no automatic process set up. Instructions are available in the article https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/["From ifcfg to keyfiles: modernizing NetworkManager configuration in Fedora Linux 36"] in Fedora Magazine.
Other major changes are associated with the new Ansible Release 5. However, no particular problems were found in the tests.
We recommend studying the https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/[Release Notes] whether any change affects a specific installation.
// *Status of this document*: Work in progress.
====

143
modules/ROOT/pages/installation/index.adoc
View file

@ -5,143 +5,20 @@ Peter Boy; Kevin Fenzi; Jan Kuparinen
:page-authors: {author}, {author_2}, {author_3}
:page-aliases: installation-an-introduction.adoc
//[NOTE]
// ====
//**Status**: Minor updates, ready for F38
// ====
[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__.
[WARNING]
====
**You are in the Fedora Server documentation staging area!**
Fedora Server Edition uses the Fedora installation program, Anaconda, as several other editions and spins.
This place is intended for
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.
* discussing and improving new articles
* reviewing and correcting changes to existing articles
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.
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
Having done various decisions and some preparations, the installation itself is an easy step-by-step procedure, selecting one of various available methods.
*Status of this document*: No changes
== Planning ahead
=== 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.
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.
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.
So, with today's smallest possible purchasable hardware, a Fedora server can be run perfectly for a small to medium deployment.
=== Storage organization
Technically, a specific storage organization on a server itself will result in a specific partitioning of the built-in hard disk(s) and, beyond that, to the provision of external resources such as a SAN. However, this is about server installation and therefore only about partitioning the internal hard disk(s).
If you ask 3 system administrators about the best practice for hard disk partitioning, you will get at least 5 different answers. There is no clear, best way to partition your disks. A discussion of the details is beyond the scope of this article. Talk to your friends, read up on the subject, search for articles, and make your own judgment.
The Fedora Server Edition working group has also discussed this topic and agreed on a recommended default configuration. This is explained in the following sections. It prioritizes the highest possible reliability and fault tolerance for servers, as well as the lowest possible service interruption, and accepts a higher level of system administration, for example.
==== What default partitioning does
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.
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.
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.
==== The rationale
The rationale behind this is a separation of system and user data, which eases system administration, increases security, and decreases the likelihood of errors and data loss. The system area (i.e. the operating system including installed software) must be maintainable completely independently of the storage of user data. System maintenance must not jeopardize user data under any circumstances. If necessary, it must be possible to unmount user data.
Following this principle, the system administrator would later set up _additional logical volumes_ for storing an application's data and mount them at an appropriate location in the directory tree. In case of a PostgreSQL database, for example, a system administrator would create a logical volume of appropriate size, assign a descriptive name, such as `pgdata`, and mount it in the directory tree at `/var/lib/pgsql`, where Fedora PostgreSQL expects the data to reside.
In this way, any error that may occur in the file system should have as little impact as possible and jeopardize as little valuable data as at all possible. For this, the additional effort in system administration is purposely accepted.
==== Taking the rationale further
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.
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.
==== 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.
On a server, this is usually not optimal. Rather, several disks should store data redundantly in order to maintain operation in the event of a hardware failure. xref:installation/sw-raid-upon-installation.adoc[Configuring a RAID system] is one such solution.
=== Network connection
Anaconda analyzes the hardware and generates at least a basic configuration file for each network interface found, regardless of whether a carrier is present. If a DHCP service is detected, anaconda creates a corresponding complete configuration.
Some system administrators prefer a static configuration even if there is DHCP available, suspicious as they are of any possible source of failure. The network configuration is nevertheless a customization option during the installation.
== Preparations
=== 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.
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__.
=== 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.
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
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
A installation on bare metal requires to transfer the installation file to a bootable media, mostly an USB memory stick. There are several option:
. 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.
+
[source,]
----
[…]# 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,]
----
[…]$ 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.
With everything done proceed with one of the available installation procedures.
Study the https://docs.fedoraproject.org/en-US/fedora-server/installation/[published documentation].
====

190
modules/ROOT/pages/installation/interactive-local.adoc
View file

@ -4,191 +4,19 @@ Peter Boy; Stephen Daley; Kevin Fenzi
:revnumber: F37-F41
:revdate: 2024-10-15
: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.
// Before publishing on main site, 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].
// *Status of this document*: Updated to f41.
//====
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]
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.
After a successful test, the routine automatically starts __Anaconda__, the actual __Fedora installation program__.
First, the program asks for the language to be used during the installation phase. Anaconda automatically selects a corresponding keyboard mapping (you can adjust it in the next step). Both are also adopted as default settings for the system to be installed.
Anaconda will display the following installation overview, with all available configuration options.
image::installation/interactive-local-020.png[Anaconda Installation Summary]
== Server installation steps
Anaconda assigns default values to the installation steps based on a system analysis and the runtime environment. However, the overview marks 3 steps that absolutely require editing:
* __Installation Destination__, i.e. the storage
* __Root account__
* __User Creation__
Anaconda does not allow the installation to begin until all marked items have been processed. The _Begin Installation_ button is grayed out until then.
The default values assigned are usually acceptable. However, two items deserve the administrator's attention:
* __Keyboard__ in case on a non-US runtime environment
* __Network & Host Name__
[TIP]
[WARNING]
====
While working with Anaconda, help functions are available to you, which are indicated briefly at the beginning.
**You are in the Fedora Server documentation staging area!**
* Function key <ctrl>+<alt>+F1: main
* Function key <ctrl>+<alt>+F2: shell
* Function key <ctrl>+<alt>+F3: log
* Function key <ctrl>+<alt>+F4: storage-log
* Function key <ctrl>+<alt>+F5: program-log
* Function key <ctrl>+<alt>+F6: packing-log | Back to GUI
====
This place is intended for
* discussing and improving new articles
* reviewing and correcting changes to existing articles
=== Keyboard
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
__Non-US users__ should specifically check the keyboard layout. Selecting this item opens a form where you can set the keyboard layout, even several ones and their order. A change immediately affects the installer as well.
*Status of this document*: No changes
=== 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 network installation select the item and edit the form appropriately.
//as described in the https://docs.fedoraproject.org/en-US/fedora/latest/install-guide/install/Installing_Using_Anaconda/#sect-installation-gui-installation-source[corresponding Fedora&#8217;s overall Installation Guide].
// Check if we want to copy that description. The installation guide itself is offline.
_Select Network_. Its default is Mirror List. Anaconda searches an appropriate mirror and comes up with __everything repository__. In this case, _everything repository_ causes no issues, because the system uses the anaconda configuration of the server medium booted from. So it gets the correct default configuration.
When everything repo is active, the "Software Selection" item becomes active, and you have to select "Fedora Server Edition".
Alternatively, you may manually select a server repository directly.
=== Installation Destination
image::installation/interactive-local-050.png[Anaconda Installation Destination]
Select one or more disks on which to install Fedora Server. You have several options.
* *Automatic configuration*
+
Anaconda defaults to Automatic, which follows the recommended default storage organization and partitioning.
* *Software raid configuration*
+
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.
* *Custom configuration*
+
This option allows you to overwrite the default partitioning according to your requirements. You just have to specify a mountpoint and some properties, Anaconda takes care of all the required configuration steps.
+
The Advanced Custom option also opens up this option, but you have to perform all the necessary configuration steps manually by yourself.
* *External storage*
+
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__.
[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'.
====
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.
====
==== Custom storage organization
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]
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.
===== How to find out if firmware is efi-boot or bios-boot
Open a temporay shell by using `<alt>+<ctrl>+<F2>` and type into the terminal window:
[source,]
----
# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
----
The command shows in the next line either UEFI or BIOS. Use `<alt>+<ctrl>+<F6>` to return to the installation screen.
=== Networking
Before configuring the Installation Destination configure the Network & Host Name to give your server a hostname. The new hostname can be entered at the bottom of this screen and then pressing the _Apply_ button.
The hostname is important for smooth functioning of various services. Unless the server is integrated into a cluster, a fully qualified static hostname (FQN) is used, i.e. server name and the domain ('my-server.example.com'). Enter the hostname and confirm with 'Apply'.
In a cluster, the hostname is often assigned by DHCP and MAC address. In this case, leave the field untouched.
By default the installation program creates a DHCP configuration for each network interface. In the case of an active connection it is automatically started during boot.
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
First, decide if you desire to have a root account on Fedora Server. Anaconda's default configuration disables the root account to prevent malicious actors from logging in as root. Instead, Anaconda requires a user account that can acquire administrative privileges using sudo.
It is possible to secure root access using an ssh key file, but server administrators may desire to retain the ability to have root access with a password through an attached console or Cockpit login. If you decide that you would like to have password access to the root account, select Root Account, then Enable root account, and enter a password for the root account in the form that appears. For security reasons, ssh login as root is only allowed with an ssh key file by default. You are not encouraged to modify this security setting by clicking on the option, "Allow root SSH login with password".
Second, select User Creation to create a user account for Fedora Server. You are encouraged to keep the default options of "Add administrative privileges to this user account" and "Require a password to use this account" checked. Unless you have decided against the security practice of not allowing root access with a password, your user account will need these options to have administrative access to the server after installation of Fedora Server.
=== Time zone and time synchronization
You may want to check Time & Date on the Installation Summary page to ensure that you have the correct time zone and Network Time is activated. These settings ensure that your server will regularly synchronize its time with a trusted source. Having the correct time on your server will make tasks like finding events at a specific time and date in your log files easier.
On the "Installation Summary" page select "Time & Date" and check time, time zone and activation of time synchronization.
== 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].
Study the https://docs.fedoraproject.org/en-US/fedora-server/installation/interactive-local/[published documentation].
====

147
modules/ROOT/pages/installation/interactive-remote.adoc
View file

@ -6,150 +6,23 @@ Peter Boy; Kevin Fenzi; Jan Kuparinen; Jiri Konecny
:numbered:
:page-aliases: pages/installation-interactive-remote.adoc
// [NOTE]
// ====
// **Status:** In sync with released version.
// ====
[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.
== Prerequisites
Proper install media available::
You need one of the installation media variants ready to use as described in xref:installation/index.adoc[Server Installation]
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:
+
* GNOME Connections - Connections is 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:
+
[source,]
----
[...]# dnf install PACKAGE_NAME
----
+
Replace package with the package name of the client you want to use (for example, freerdp).
== 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.
=== Console access available
1. Boot the server to be installed and wait for the _boot menu_ to appear.
+
image:installation/interactive-remote-010.png[Boot Menu]
2. In the menu, select the kernel you want to boot and type _e_ to get access to the boot options and append
+
--
inst.rdp inst.rdp.username=USER inst.rdp.password=PASSWORD
--
+
to the end of the command line.
Optionally, it is possible to set a password (inst.rdp.password) and/or username (inst.rdp.username). Replace PASSWORD and USER with the password and username of your choice. Password must be at least 6 characters long. If password and/or username is not set the Anaconda installer will ask interactively.
+
[IMPORTANT]
[WARNING]
====
For security considerations, use a temporary password for the inst.rdp.password= option. It should not be a real or root password you use on any system.
====
+
The above configuration requires an active DHCP server. With none available, you must provide a static interface configuration as well.
+
--
ip=ip::gateway:netmask:hostname:interface:none inst.rdp inst.rdp.password=PASSWORD inst.rdp.username=USER
--
**You are in the Fedora Server documentation staging area!**
3. Leave the editing mode by <ctrl>-x or F10 to continue to boot and to start the installation using the selected kernel and the edited options. You get the message
+
----
Booting a command list
----
+
The system will initialize the installation program and start the necessary services. It takes some time. And after a lot of boot messages, when the system is ready, you get:
+
----
Starting installer, one moment
...
hh:mm:ss Starting GNOME remote desktop in RDP mode...
hh:mm:ss GNOME remote desktop RDP: SSL certificates generated & set
hh:mm:ss GNOME remote desktop RDP: user name and password set
hh:mm:ss Starting GNOME remote desktop.
hh:mm:ss GNOME remote desktop is now running.
hh:mm:ss GNOME remote desktop RDP IP: 192.168.122.247
hh:mm:ss GNOME remote desktop RDP host name: fedora
----
Continue with __3.2. Connecting to the server__.
This place is intended for
* discussing and improving new articles
* reviewing and correcting changes to existing articles
==== 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.
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
We won't go into this matter any further here. This is really the very last resort and is not recommended.
*Status of this document*: No changes
== Connecting to the server
. In case of a server without a console attached determine the IP address.
a. If possible, check the DHCP server for the IP of the server.
b. Scan the network subnet the server is connected to for open port 3389. Adjust the network IP address accordingly!
+
[source,bash]
----
[…]# 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).
PORT STATE SERVICE
3389/tcp closed nn-admin
MAC Address: 34:81:C4:14:21:B4 (AVM GmbH)
Nmap scan report for iMac.fritz.box (192.168.158.111)
Host is up (0.00051s latency).
...
...
PORT STATE SERVICE
3389/tcp open
MAC Address: B8:27:EB:5A:EC:84
Nmap scan report for 192.168.158.200
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.
. 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.
+
Alternatively, use freerdp client with
+
----
xfreerdp /v:192.168.158.200 /u:USER /p:PASSWORD
----
. When the connection is successfully established, a new window will open on the system running the RDP client, displaying the installation menu.
You will be presented with the familiar language selection menu.
+
.The language selection installation window
image:installation/interactive-remote-015.png[]
+
This window will provide full remote access to the installer until the installation finishes and the system reboots for the first time.
+
[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__.
Study the https://docs.fedoraproject.org/en-US/fedora-server/installation/interactive-remote/[published documentation].
====
You can then proceed with xref::installation/interactive-local.adoc[Fedora Server interactive local installation].

391
modules/ROOT/pages/installation/postinstallation-tasks.adoc
View file

@ -4,387 +4,22 @@ Peter Boy; Stephen Daley; Kevin Fenzi
:revnumber: F36-F41
:revdate: 2024-10-15
:page-aliases: pages/sysadmin-postinstall.adoc
:numbered:
[abstract]
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.
//[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].
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.
== 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.
include::partial$installation/post-install/convenient-user-login.adoc[]
== Check Cockpit access
include::partial$installation/post-install/cockpit-check-accessibility.adoc[]
== 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.
Therefore, it is best practice to minimize the number of system users and instead use virtual accounts or offload applications that require system users to virtual machines or containers. In case of an intrusion, this is a kind of second line of defense, trying to keep the server itself from being infected even then.
In addition, it is a small effort to generally prevent password-based login and to enforce key files. An exception can be defined for individual, selected users. If a server is located in a data center and can only be remotely accessed without much additional effort, it may make sense to set up a "fallback user" if key-based authentication is no longer available for some reason.
As a side effect it saves a lot of warning messages in the log file and makes it easier to check them.
include::partial$installation/post-install/disable-password-login.adoc[]
== Increase security of Cockpit access
Cockpit relies on a password based login to its web interface, even for root (unless the root account is completely locked, locking the account as part of ssh does not help here). And thus it is a potential target for brute-force attacks. In most cases, it is rarely used in daily operations and it may be a good practice to remove the general accessibility in the firewall. Instead, access Cockpit in one of the three secure alternatives described below.
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!
=== 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.
a. Execute on the local desktop
+
[source]
----
[…]$ 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.
=== Transfer and install the public key onto the server
You normally use _ssh-copy-id_ to install the public key on the server. However, this requires a password login, which was disabled for root during installation. Therefore, a detour is now required.
a. Log in to your server via sftp using the unprivileged administration account and transfer the public key file
+
[source,]
----
[…]$ 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,]
----
[…]$ ssh hostmin@example.com
----
c. On the server acquire root permissions, move the key file and adjust permissions
+
[source,]
----
[…]$ 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
a. On your local workstation test key file based access:
+
[source,]
----
[…]# 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,]
----
[…]# vi ~/.ssh/config
# ###########################################################
# my remote server, root account
# ###########################################################
Host myhost
Hostname myhost.example.com
User root
ProxyCommand none
ForwardAgent no
ForwardX11 no
Port 22
KeepAlive yes
IdentityFile ~/.ssh/<outputkeyfile>
----
+
again, replace names accordingly.
c. Check if everything works:
+
[source,]
----
[…]# ssh myhost
----
== Double check hostname and time synchronisation
Both are important for trouble-free server operation. Just in case you missed its configuration during installation or it is incorrect, now is the opportunity to fix it.
a. Check for correct hostname
+
[source,]
----
[…]# hostnamectl
----
* Set hostname if required:
+
[source,]
----
[…]# hostnamectl set-hostname <YourFQDN>
----
b. Control of time zone, time synchronisation, time
+
[source,]
----
[…]# timedatectl
----
* Correct time zone if necessary:
+
[source,]
----
[…]# timedatectl set-timezone <ZONE>
----
* If necessary, activate time synchronisation:
+
[source,]
----
timedatectl set-ntp true
----
* Correct time if necessary:
+
[source,]
----
[…]# timedatectl set-time <TIME>
----
== Consolidate network configuration
Depending on installation efforts, network configuration consolidation may be required.
It sounds trivial, but before any change of the network configuration make sure that the entries in the DNS are correct. If you change from DHCP to fixed addresses, you may need to adjust the DNS and vice versa!
a. Check IP addresses, interface and which protocol stack is used
+
[source,]
----
[…]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc n
...
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER
...
[…]# nmcli con
NAME UUID TYPE DEVICE
enp3s0 dabaa33b-25b0-3bfd-8a74-b6b40847a7a4 ethernet enp3s0
[…]# 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'
=====================================================================
Connection details (enp3s0)
=====================================================================
ipv4.method: manual
---------------------------------------------------------------------
ipv6.method: manual
---------------------------------------------------------------------
----
+
Adjust interface names to your custom config
b. Just in case IPv6 is configured as local only (fe80::....) or not static, you may set up a fixed IPv6
+
[source,]
----
[…]# 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
----
+
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.
+
Check connectivity from your local workstation. If that fails, the gateway configuration is the first suspected culprit.
+
[source,]
----
[…]# 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):
+
[source,]
----
[…]# 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
----
+
Again, don't forget to adjust names, prefix, and DNS IP addresses and check connectivity from your local workstation:
+
[source,]
----
[…]# ping <YOUR_IPv4>
----
d. Optionally you may have a look at the NetworkManager configuration file
+
[source,]
----
[…]# less /etc/NetworkManager/system-connections/enp3s0.nmconnection
----
Finally reboot now to check everything from ground up
== Check LVM storage devices
With Fedora 39 the default LVM configuration has changed. The various LVM management commands now only process registered, 'legitimate' block devices connected to the system. It is essential to check the correctness of the devices file list.
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,]
----
[…]$ 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,]
----
[…]$ sudo lvmdevices --adddev /dev/<PART>
----
Removing a device (permanently)::
This modifies the devices file in /etc/lvm/devices
+
[source,]
----
[…]$ sudo lvmdevices --deldev /dev/<PART>
----
== Consolidate storage configuration
Depending on how you decided on data storage during installation, different supplementary configuration may be required.
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.
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.
+
[CAUTION]
[WARNING]
====
This is not a recommended procedure! Don't complain in case of issues.
**You are in the Fedora Server documentation staging area!**
This place is intended for
* discussing and improving new articles
* reviewing and correcting changes to existing articles
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
*Status of this document*: No changes
Study the https://docs.fedoraproject.org/en-US/fedora-server/installation/postinstallation-tasks/[published documentation].
====
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.
== Install fail2ban
If a general disabling of the password login is not an option, the installation of fail2ban is worth considering.
// ===============================================================
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.
a. Install software
+
[source,]
----
[…]# 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,]
----
[…]# vi /etc/aliases
...
# Person who should get root's mail
#root: marc
root: real@address.for.root
[…]# newaliases
----
== 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.
// ===============================================================
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,]
----
[…]# dnf install vim-default-editor --allowerasing
[…]# dnf update
----
Add to the software list as needed.
Finally reboot the server.

379
modules/ROOT/pages/installation/sw-raid-upon-installation.adoc
View file

@ -4,380 +4,21 @@ Peter Boy; Stephen Daley; Kevin Fenzi
:revnumber: F37-F42
:revdate: 2025-08-20
[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.
The RAID configuraton starts at the "Installation Destination" window.
[WARNING]
====
**You are in the Fedora Server documentation staging area!**
.The Installation Destination window
image:installation/sw-raid/001-installationdestination.png[]
This place is intended for
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.
* discussing and improving new articles
* reviewing and correcting changes to existing articles
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.
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
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.
*Status of this document*: No changes
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,]
----
# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
----
Study the https://docs.fedoraproject.org/en-US/fedora-server/installation/postinstallation-tasks/[published documentation].
====
The command shows in the next line either UEFI or BIOS. Use `<alt>+<ctrl>+<F6>` to return to the installation screen.
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.
+
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.
* the "**Advanced Custom (Blivet-GUI)**" option
+
This way, you can and must perform each individual step of partitioning, configuring LVM volumes and creating file systems by yourself. This is the more laborious way.
+
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.
== Custom partitioning
Anaconda opens a new window:
.The custom partitioning start up screen
image:installation/sw-raid/101-custom-start.png[]
. *Check all disks for existing partitions*
+
If the area beyond __Unknown__ contains one or more partition, check whether you want to retain, reuse, or delete it. Mind that you can only reuse partitions that are set up identically on all disks.
+
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, 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.
+
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.
+
.The BiosBoot installation
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.
+
.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.
. *On a UEFI boot system only, create an EFI partition*
+
Use the "+" sign to add a partition. The "__Add a new Mount Point form__" form opens up
+
* select /boot/efi as the mount point
* enter 600 Mib as size
* Tick "Add Mount Point"
+
The installation window refreshes and now shows a /boot/efi partition on the left side under SYSTEM and a number of properties for this partition on the right side.
+
.Initial EFI system partition
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.
+
.Final EFI system partition properties
image:installation/sw-raid/125-custom-efi-2.png[]
. *Add a __boot__ Partition*
+
Tick the "+" sign and a form "Add a new Mount Point" opens again.
+
* select /boot as the mount point
* enter 1 Gib as size
* Tick "Add Mount Point"
+
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.
+
.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
+
* 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 generated LVM root volume and filesystem
image:installation/sw-raid/140-custom-generated-root.png[]
+
Now you have the opportunity the adjust Anacondas guessings.
+
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.
+
.Anaconda LVM properties form
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.
* _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.
. *Customize the storage organisation 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.
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.
== Advanced Custom partitioning
Anaconda opens a new window:
.The advancced custom partitioning start up screen
image:installation/sw-raid/201-adv-custom-start.png[]
. *Check all disks for existing partitions*
+
If there are partitions on any of the hard disks, delete the partitions if they are no longer needed. Note that you can only reuse partitions that are set up identically on all hard disks.
+
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, 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!
+
Usually, the first Disk is sda and already selected. A large blue bar at the top represents the disk. Otherwise, click onto the left side onto the sda symbol. With the "plus" symbol just beyond the central sda area you start to create
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.
+
Next, click on sdb and thus activate it for editing. Repeat the process to create a BIOSBoot partition as before.
+
When both BIOSBoot partitions have been created, check again whether the size and position are actually the same in both cases! You can switch between the two disk views by clicking on the sda1 and sda2 icons respectively.
. *On a UEFI boot system only, create an EFI partition*
+
If you have not already done so, activate the first hard disk, usually sda, by clicking on the icon in the left column. With the "plus" symbol just beyond the central sda area you start to create a partition.
+
.Creating EFI system partition
image:installation/sw-raid/210-adv-custom-uefi.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. Therefore, select "Software RAID" in the "Device type" selection box and replace "partition". Then fill out the rest of the form as indicated.
+
* select sda and sdb as RAID members
* select RAID level raid1
* enter 0.6 GiB size
* select Filesystem "EFI System Partition"
* enter Label "sysefi"
* enter Name "boot_efi"
* Enter Mountpoint /boot/efi
* Tick "OK"
+
The installation window refreshes and now shows a new RAID entry in the left column and a boot_efi partition in the sda disk.
+
.Partitions list including EFI system partition
image:installation/sw-raid/212-adv-custom-uefilist.png[]
. *Creating a __boot__ Partition*
+
Click into the free space on sda to activate it and tick the "+" sign again to open a new device form.
+
.Creating a boot partition
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 RAID level raid1
* enter 1.0 GiB size
* 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.
+
.Partitions list including EFI and boot partitions
image:installation/sw-raid/217-adv-custom-bootlist.png[]
. *Creating a system Volume Group*
+
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
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.
+
* select sda and sdb as RAID members
* 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.
** 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.
+
* Select "physical volume (LVM)" for Filesystem.
* 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.
+
.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.
+
.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.
+
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.
* 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.
+
.Creating a user physical volume on RAID
image:installation/sw-raid/230-adv-custom-usrpv.png[]
+
Either leave the suggested size value as it is to set up the entire free area for user data, or choose a smaller value to keep free disposition storage.
* Double-click onto the usrpv 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/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.
+
The overview list screen now shows a new Volume Group device "sysvg" 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.
+
.Creating the ROOT file system
image:installation/sw-raid/240-adv-custom-rootfsform.png[]
+
Leave the Device type and Avalable 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.
+
.Devices list showing partitions, two volume groups and RAID devices
image:installation/sw-raid/244-adv-custom-rootfslist.png[]
. *Some typical optional adjustments to the storage organization*
+
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.
+
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
+
** Specify the size of the file system. A value of 3 or 5 GiB is usually large enough.
** Complete the form as indicated
+
.Devices list showing the /var/log file system
image:installation/sw-raid/254-adv-custom-varloglist.png[]
+
* __Optional: Setting up a home directory storage space__
+
An Internet server that only provides web and e-mail services usually only allows administrative users that do not use the server to store important personal data. A separate file system is often superfluous.
+
But sometimes they need to upload some data for further processing on the server. You may want to keep those separate from the system files and create a small home file system, maybe just in the system Volume Group if you decided for a strict separation as recommended above.
+
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.
+
.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.
** 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__
+
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.
+
.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.
** Complete the form as indicated.
+
.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.
+
.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.
** 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.

27
modules/ROOT/pages/server-communicating.adoc
View file

@ -3,19 +3,22 @@ Peter Boy; Jan Kuparinen
:page-authors: {author}, {author_2}
:revnumber: All
: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!
[WARNING]
====
**You are in the Fedora Server documentation staging area!**
This place is intended for
* discussing and improving new articles
* reviewing and correcting changes to existing articles
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
*Status of this document*: No changes
Study the https://docs.fedoraproject.org/en-US/fedora-server/server-communicating/[published documentation].
====
* 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].
* 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].

21
modules/ROOT/pages/server-faq.adoc
View file

@ -5,11 +5,18 @@ Peter Boy; Jan Kuparinen
:revdate: 2021-03-09
// :revremark: a new beginning
[WARNING]
====
**You are in the Fedora Server documentation staging area!**
[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.
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!
How do I manage SELinux issues?::
First of all: Don’t deactivate but resolve issues - (Link to Server Sysadmin Cockpit page and Quick Docs)
This place is intended for
* discussing and improving new articles
* reviewing and correcting changes to existing articles
These documents are not approved yet and may be incomplete and/or incorrect. Take everything here with a grain of salt!
*Status of this document*: No changes
Study the https://docs.fedoraproject.org/en-US/fedora-server/server-faq/[published documentation].
====

101
modules/ROOT/pages/usecase-gui-addon.adoc
View file

@ -1,101 +0,0 @@
= Adding a graphical interface
Peter Boy; Jan Kuparinen
:page-authors: {author}, {author_2}
:revnumber: F35-F36
:revdate: 2022-03-9
// :revremark: a new beginning
Some users install Fedora Server Edition and then manually add a graphical user interface. Sometimes it is a matter of more convenient administration of a locally accessible server, sometimes it is a kind of off-label use, and desire for a server hardened runtime environment as a workstation with special requirements.
1. *Determine available graphical desktops*
+
To get an overview of available graphical user interfaces, simply list all installation groups and search through them. Unfortunately, the current naming is not consistent enough to allow a simple filtering by term.
+
[source,bash]
----
[…]# dnf group list
----
You will find
* KDE Plasma Workspaces
* Xfce Desktop (@xfce-desktop-environment)
* LXDE Desktop
* LXQt-Desktop
* Cinnamon Desktop
* MATE Desktop
* Sugar Desktop Environment
* Deepin Desktop
* i3 desktop
* Pantheon Desktop
2. *Installation of a graphical desktop*
+
You may either use the groups pretty name as shown in the group listing or the canonical name. As an example, to install the Cinnamon desktop you can use either use
+
[source,bash]
----
[…]# dnf groupinstall "Cinnamon Desktop"
----
+
or
+
[source,bash]
----
[…]# dnf install @cinnamon-desktop-environment
----
3. *Adjustment of systemd to start in graphic mode*
+
To boot into graphical mode by default, you have to adjust the default target.
+
[source,bash]
----
[…]# systemctl set-default graphical.target
----
+
With some desktop you may also need:
+
[source,bash]
----
[…]# systemctl enable gdm.service
----
+
Try it, but you may get a "Service not found" message with some desktops. No need to worry, the installed desktop will come up without that.
4. *Reboot your server*
+
[source,bash]
----
[…]# reboot
----
+
Your system will start with the selected graphical desktop.
== Additional options
You may install multiple desktops. The utilities `switchdesk` and `switchdesk-gui` can be used to switch the desktop GUI.
[source,bash]
----
[…]# dnf install switchdesk switchdesk-gui
----
In a terminal window, you can directly switch to another desktop:
[source,bash]
----
[…]# switchdesk cinnamon
----
Without naming the new desktop, a window with the available options will be displayed.
The graphical `_Desktop Switcher_` is included in the Systemadministration menu group. It always displayx a list of available desktops you can choose from.
You can switch back to booting to a text console:
[source,bash]
----
[…]# systemctl set-default multi-user.target
[…]# reboot
----
After having switched back into text mode, you can switch to the selected desktop just for the current session using
[…]# startx
However, this does not work flawlessly for every available desktop.