Enable RedHat.Spelling style and revise content
Assisted-by: Pi:qwen3.5-122b-a10b
This commit is contained in:
parent
df92539d10
commit
f2f51ab1d1
32 changed files with 244 additions and 178 deletions
|
|
@ -1,6 +1,7 @@
|
|||
StylesPath = .vale/styles
|
||||
MinAlertLevel = suggestion
|
||||
Packages = RedHat
|
||||
Vocab = FedoraServer
|
||||
|
||||
[*]
|
||||
# BasedOnStyles = RedHat
|
||||
|
|
@ -35,7 +36,7 @@ RedHat.SessionId = YES
|
|||
# RedHat.Slash = YES
|
||||
RedHat.SmartQuotes = YES
|
||||
RedHat.Spacing = YES
|
||||
# RedHat.Spelling = YES
|
||||
RedHat.Spelling = YES
|
||||
# RedHat.Symbols = YES
|
||||
# RedHat.TermsErrors = YES
|
||||
# RedHat.TermsSuggestions = YES
|
||||
|
|
|
|||
65
.vale/styles/config/vocabularies/FedoraServer/accept.txt
Normal file
65
.vale/styles/config/vocabularies/FedoraServer/accept.txt
Normal file
|
|
@ -0,0 +1,65 @@
|
|||
|
||||
arabic
|
||||
bantime
|
||||
biosboot
|
||||
bootloader
|
||||
bootloaders
|
||||
chmod
|
||||
chown
|
||||
cockpit-machines
|
||||
Deepin
|
||||
diskimg
|
||||
EFF
|
||||
efi
|
||||
example.lan
|
||||
fedoraserver
|
||||
finalbootform
|
||||
homelab
|
||||
homelabs
|
||||
hostmin
|
||||
hostnamectl
|
||||
installationdestination
|
||||
Jamstack
|
||||
libnfsidmap
|
||||
libvirt
|
||||
libvirtform
|
||||
libvirtlist
|
||||
Logwatch
|
||||
LXC
|
||||
LXD
|
||||
Mindshare
|
||||
mkdir
|
||||
mv
|
||||
nat
|
||||
Netinstall
|
||||
NoCloud
|
||||
Proxmox
|
||||
QEMU
|
||||
rlogin
|
||||
rootfsform
|
||||
rootfslist
|
||||
sda
|
||||
sdb
|
||||
srvform
|
||||
srvlist
|
||||
SSHFS
|
||||
subprojects
|
||||
Sun Microsystems
|
||||
sysefi
|
||||
sysgvlist
|
||||
syspv
|
||||
syspvlist
|
||||
sysvg
|
||||
sysvgform
|
||||
uefilist
|
||||
usrhomeform
|
||||
usrhomelist
|
||||
usrpv
|
||||
usrvg
|
||||
usrvglist
|
||||
varlogform
|
||||
varloglist
|
||||
vda
|
||||
WordPress
|
||||
Xen
|
||||
Xfce
|
||||
|
|
@ -5,16 +5,16 @@ Rowan Puttergill
|
|||
:tags: SSH, Security, Access
|
||||
|
||||
[abstract]
|
||||
`SSH` (Secure Shell) is a protocol which facilitates secure communications between two systems using a client-server architecture and allows users to log into server host systems remotely. Unlike other remote communication protocols, such as `FTP`, `Telnet`, or [command]#rlogin#, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords.
|
||||
SSH (Secure Shell) is a protocol which facilitates secure communications between two systems using a client-server architecture and allows users to log into server host systems remotely. Unlike other remote communication protocols, such as FTP, Telnet, or rlogin, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
**Status:** work in progress. Content in this section is in review and being updated. Feedback welcome!
|
||||
====
|
||||
|
||||
The [application]*ssh* program is designed to replace older, less secure terminal applications used to log into remote hosts, such as [command]#telnet# or [command]#rsh#. A related program called [command]#scp# replaces older programs designed to copy files between hosts, such as [command]#rcp#. Because these older applications do not encrypt passwords transmitted between the client and the server, avoid them whenever possible. Using secure methods to log into remote systems decreases the risks for both the client system and the remote host.
|
||||
The [application]*ssh* program is designed to replace older, less secure terminal applications used to log into remote hosts, such as [command]#telnet# or [command]#rsh#. A related program called `scp` replaces older programs designed to copy files between hosts, such as `rcp`. Because these older applications do not encrypt passwords transmitted between the client and the server, avoid them whenever possible. Using secure methods to log into remote systems decreases the risks for both the client system and the remote host.
|
||||
|
||||
Fedora includes the general OpenSSH package, [package]*openssh*, as well as the OpenSSH server, [package]*openssh-server*, and client, [package]*openssh-clients*, packages. Note, the OpenSSH packages require the OpenSSL package [package]*openssl-libs*, which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.
|
||||
Fedora includes the general OpenSSH package, `openssh`, as well as the OpenSSH server, [package]*openssh-server*, and client, [package]*openssh-clients*, packages. Note, the OpenSSH packages require the OpenSSL package [package]*openssl-libs*, which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.
|
||||
|
||||
[[s2-ssh-why]]
|
||||
== Why use SSH?
|
||||
|
|
|
|||
|
|
@ -50,9 +50,9 @@ User-specific SSH configuration information is stored in `~/.ssh/` within the us
|
|||
For information concerning various directives that can be used in the SSH configuration files, see the `ssh_config`(5) and `sshd_config`(5) manual pages.
|
||||
|
||||
[[s2-ssh-clients-ssh]]
|
||||
== Using the ssh utility
|
||||
== Using the `ssh` utility
|
||||
indexterm:[ssh,OpenSSH]indexterm:[OpenSSH,client,ssh]
|
||||
The [command]#ssh# utility allows you to log in to a remote machine and execute commands there. It is a secure replacement for the [command]#rlogin#, [command]#rsh#, and [command]#telnet# programs.
|
||||
The [command]#ssh# utility allows you to log in to a remote machine and execute commands there. It is a secure replacement for the `rlogin`, [command]#rsh#, and [command]#telnet# programs.
|
||||
|
||||
Similarly to the [command]#telnet# command, log in to a remote machine by using the following command:
|
||||
|
||||
|
|
@ -149,7 +149,7 @@ After you enter the correct password, the user name will be displayed, and you w
|
|||
[[s2-ssh-client-keypairs]]
|
||||
== Generating and managing SSH keys
|
||||
indexterm:[OpenSSH,using key-based authentication]
|
||||
To be able to use [command]#ssh#, [command]#scp#, or [command]#sftp# to connect to a server, generate an authorization key pair by following the steps below. Note that keys must be generated for each user separately.
|
||||
To be able to use [command]#ssh#, `scp`, or [command]#sftp# to connect to a server, generate an authorization key pair by following the steps below. Note that keys must be generated for each user separately.
|
||||
|
||||
Fedora uses SSH Protocol 2 by default (see xref:administration/SSH-About.adoc#s2-ssh-versions[Protocol Versions] for more information). When generating new keys, Ed25519 is the recommended key type; RSA and ECDSA are also supported for compatibility with older systems.
|
||||
|
||||
|
|
@ -331,9 +331,9 @@ Note that when you log out, your passphrase will be forgotten. You must execute
|
|||
NOTE: This section is a placeholder and is not covered in the original topic. It should cover the per-user `~/.ssh/config` file (and the system-wide `/etc/ssh/ssh_config`), including `Host` blocks/aliases, common per-host options such as `HostName`, `User`, `Port`, and `IdentityFile`, the `ProxyJump` directive for jump hosts, and global defaults such as `ServerAliveInterval`.
|
||||
|
||||
[[s2-ssh-clients-scp]]
|
||||
== Using the [command]#scp# utility
|
||||
indexterm:[scp,OpenSSH]indexterm:[OpenSSH,client,scp]indexterm:[rcp]
|
||||
[command]#scp# can be used to transfer files between machines over a secure, encrypted connection. In its design, it is very similar to [command]#rcp#.
|
||||
== Using the `scp` utility
|
||||
indexterm:[scp,OpenSSH]indexterm:[OpenSSH,client,scp]indexterm:[`rcp`]
|
||||
`scp` can be used to transfer files between machines over a secure, encrypted connection. In its design, it is very similar to `rcp`.
|
||||
|
||||
To transfer a local file to a remote system, use a command in the following form:
|
||||
|
||||
|
|
@ -417,10 +417,10 @@ After you enter the correct password, you will be presented with a prompt. The [
|
|||
|Command|Description
|
||||
|[command]#ls# [pass:attributes[{blank}]_directory_pass:attributes[{blank}]]|List the content of a remote _directory_. If none is supplied, a current working directory is used by default.
|
||||
|[command]#cd# _directory_|Change the remote working directory to _directory_.
|
||||
|[command]#mkdir# _directory_|Create a remote _directory_.
|
||||
|[command]#rmdir# _directory_|Remove a remote _directory_.
|
||||
|[command]#put# _localfile_ [pass:attributes[{blank}]_remotefile_pass:attributes[{blank}]]|Transfer _localfile_ to a remote machine.
|
||||
|[command]#get# _remotefile_ [pass:attributes[{blank}]_localfile_pass:attributes[{blank}]]|Transfer _remotefile_ from a remote machine.
|
||||
|`mkdir` _directory_|Create a remote _directory_.
|
||||
|`rmdir` _directory_|Remove a remote _directory_.
|
||||
|`put` `localfile` [pass:attributes[{blank}]`remotefile`_pass:attributes[{blank}]]|Transfer `localfile` to a remote machine.
|
||||
|`get` `remotefile` [pass:attributes[{blank}]`localfile`_pass:attributes[{blank}]]|Transfer `remotefile` from a remote machine.
|
||||
|===
|
||||
|
||||
For a complete list of available commands, see the `sftp`(1) manual page.
|
||||
|
|
@ -443,7 +443,7 @@ For more information on how to connect to an OpenSSH server from Fedora, see the
|
|||
|
||||
* `ssh`(1) — The manual page for the [command]#ssh# client application provides a complete list of available command line options and supported configuration files and directories.
|
||||
|
||||
* `scp`(1) — The manual page for the [command]#scp# utility provides a more detailed description of this utility and its usage.
|
||||
* `scp`(1) — The manual page for the `scp` utility provides a more detailed description of this utility and its usage.
|
||||
|
||||
* `sftp`(1) — The manual page for the [command]#sftp# utility.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ This topic covers installing, starting, and configuring the OpenSSH server (`ssh
|
|||
[[s2-ssh-configuration-configs]]
|
||||
== Configuration files
|
||||
indexterm:[SSH protocol,configuration files]
|
||||
There are two different sets of configuration files: those for client programs (that is, [command]#ssh#, [command]#scp#, and [command]#sftp#), and those for the server (the [command]#sshd# daemon).
|
||||
There are two different sets of configuration files: those for client programs (that is, [command]#ssh#, `scp`, and [command]#sftp#), and those for the server (the [command]#sshd# daemon).
|
||||
indexterm:[SSH protocol,configuration files,system-wide configuration files]
|
||||
System-wide SSH configuration information is stored in the `/etc/ssh/` directory as described in xref:table-ssh-configuration-configs-system[System-wide configuration files] below. For the user-specific configuration files stored in `~/.ssh/`, see xref:administration/SSH-Client.adoc#table-ssh-configuration-configs-user[User-specific configuration files] in xref:administration/SSH-Client.adoc[OpenSSH Client Configuration].
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ To prevent this, you can backup the relevant files from the `/etc/ssh/` director
|
|||
[[s2-ssh-configuration-requiring]]
|
||||
== Requiring SSH for remote connections
|
||||
indexterm:[SSH protocol,insecure protocols]indexterm:[SSH protocol,requiring for remote login]
|
||||
For SSH to be truly effective, using insecure connection protocols should be prohibited. Otherwise, a user's password may be protected using SSH for one session, only to be captured later while logging in using Telnet. Some services to disable include [command]#telnet#, [command]#rsh#, [command]#rlogin#, and [command]#vsftpd#.
|
||||
For SSH to be truly effective, using insecure connection protocols should be prohibited. Otherwise, a user's password may be protected using SSH for one session, only to be captured later while logging in using Telnet. Some services to disable include [command]#telnet#, [command]#rsh#, `rlogin`, and [command]#vsftpd#.
|
||||
|
||||
These services are not installed by default in Fedora. If required, to make sure these services are not running, type the following commands at a shell prompt:
|
||||
|
||||
|
|
|
|||
|
|
@ -462,7 +462,7 @@ UEFI systems that have Secure Boot enabled might reject a PXE boot if the EFI bi
|
|||
|
||||
. **Download or copy the installation kernel and ram-disk image files to the TFTP server directory hierarchy**:
|
||||
+
|
||||
You can either copy these files directly off an installation ISO, or you can download them directly from Fedora. In this example, we create a directory to host these files and then download each of the files from the https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Everything/x86_64/os/images/pxeboot/[Fedora pxeboot download URL]:
|
||||
You can either copy these files directly off an installation ISO, or you can download them directly from Fedora. In this example, we create a directory to host these files and then download each of the files from the https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Everything/x86_64/os/images/pxeboot/[Fedora `pxeboot` download URL]:
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -557,7 +557,7 @@ dnsmasq: syntax check OK.
|
|||
$ sudo systemctl restart NetworkManager
|
||||
----
|
||||
|
||||
. **If the system is running SELinux, set the file context on the tftpboot directory**:
|
||||
. **If the system is running SELinux, set the file context on the `tftpboot` directory**:
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ default via 192.168.133.1 dev enp1s0 proto static metric 100
|
|||
|
||||
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
|
||||
Usually, you configure the interface using a text editor, e.g. given the above example
|
||||
[source,console]
|
||||
----
|
||||
# vim /etc/sysconfig/network-scripts/ifcfg-enp1s0
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ It is often desirable to provide DHCP and, where necessary, DNS within a bridge'
|
|||
|
||||
* https://networkmanager.dev/docs/admins/[Upstream documentation for administrators] (very technical)
|
||||
|
||||
* https://networkmanager.dev/docs/api/latest/nmcli.html[nmcli - command-line tool for controlling NetworkManager] Upstream's structured overview of nmcli options and parameters
|
||||
* https://networkmanager.dev/docs/api/latest/nmcli.html[nmcli - command-line tool for controlling NetworkManager] - Overview of `nmcli` options and parameters from the upstream project
|
||||
|
||||
* xref:virtualization/installation.adoc[Adding Virtualization Support in Fedora Server]
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
= Set up a virtual routing bridge (brouter)
|
||||
= Set up a virtual routing bridge (`brouter`)
|
||||
Peter Boy; Kevin Fenzi; Brett Weir
|
||||
:page-authors: {author}, {author_2}, {author_3}
|
||||
:revnumber: F37-F44
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
= Setting up a systemd-nspawn Fedora container
|
||||
= Setting up a `systemd-nspawn` Fedora container
|
||||
Peter Boy; Jan Kuparinen
|
||||
:revnumber: F43-F44
|
||||
:page-authors: {author}, {author_2}
|
||||
|
|
@ -6,7 +6,7 @@ Peter Boy; Jan Kuparinen
|
|||
:page-aliases: container-nspawn-install.adoc
|
||||
|
||||
[abstract]
|
||||
The systemd-nspawn container runtime is part of the systemd system software. It is exceptionally lightweight, flexible, and integrates deeply with systemd for seamless service management. This article covers how to set up a Fedora container.
|
||||
The `systemd-nspawn` container runtime is part of the systemd system software. It is exceptionally lightweight, flexible, and integrates deeply with systemd for seamless service management. This article covers how to set up a Fedora container.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
|
@ -15,13 +15,13 @@ The systemd-nspawn container runtime is part of the systemd system software. It
|
|||
|
||||
The only prerequisite is a fully installed basic Fedora Server system.
|
||||
|
||||
== 1. Setting up the nspawn container infrastructure
|
||||
== 1. Setting up the `nspawn` container infrastructure
|
||||
|
||||
1. *Create a container storage area*
|
||||
+
|
||||
The systemd-nspawn tools like machinectl look for system-wide usable containers in `/var/lib/machines`. This directory is also created during the installation of the program if it does not exist.
|
||||
The `systemd-nspawn` tools like `machinectl` look for system-wide usable containers in `/var/lib/machines`. This directory is also created during the installation of the program if it does not exist.
|
||||
+
|
||||
Following the Fedora server storage scheme, create an appropriate storage where to store all of the system-wide nspawn containers. Depending on your choice of storage concept, either create a ressource at /var/lib/machines or let the installation program create the default subdirectory.
|
||||
Following the Fedora server storage scheme, create an appropriate storage where to store all of the system-wide `nspawn` containers. Depending on your choice of storage concept, either create a resource at `/var/lib/machines` or let the installation program create the default subdirectory.
|
||||
+
|
||||
If you created this directory yourself, make sure that the correct SELinux labels are in place, that ownership is set to root, and that accessibility is restricted to root only.
|
||||
+
|
||||
|
|
@ -39,14 +39,14 @@ If you created this directory yourself, make sure that the correct SELinux label
|
|||
# machinectl
|
||||
No machines.
|
||||
----
|
||||
3. *Add the host configuration directory for nspawn*
|
||||
3. *Add the host configuration directory for `nspawn`*
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
# mkdir /etc/systemd/nspawn
|
||||
----
|
||||
|
||||
== 2. Create an nspawn system container
|
||||
== 2. Create an `nspawn` system container
|
||||
|
||||
In this context, the term "system container" specifically refers to a container that has a complete init system and, in particular, its own network connection. It therefore operates in a similar way to a VM, albeit without its own kernel (lightweight VM), and is otherwise largely independent of the host machine.
|
||||
|
||||
|
|
@ -54,13 +54,13 @@ In this context, the term "system container" specifically refers to a container
|
|||
|
||||
. Creating a container subdirectory
|
||||
+
|
||||
The systemd-nspawn tooling expects a subdirectory, using its name as both the container name and the default hostname.
|
||||
The `systemd-nspawn` tooling expects a subdirectory, using its name as both the container name and the default hostname.
|
||||
+
|
||||
Create a subdirectory according your storage concept.
|
||||
|
||||
. Create a minimal container directory tree
|
||||
+
|
||||
The creation of a container filesystem or the provision of a corresponding image is treated as "out of scope" by systemd-nspawn. There are a number of alternative options. By far the easiest and most efficient way is simply to use the distribution specific bootstrap tool, DNF in case of fedora, in the container's directory. This is the recommended procedure.
|
||||
The creation of a container filesystem or the provision of a corresponding image is treated as "out of scope" by `systemd-nspawn`. There are a number of alternative options. By far the easiest and most efficient way is simply to use the distribution specific bootstrap tool, DNF in case of fedora, in the container's directory. This is the recommended procedure.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -79,7 +79,7 @@ Optionally, you may add your local language package
|
|||
# dnf --releasever=44 --best --setopt=install_weak_deps=False --use-host-config --installroot=/var/lib/machines/{CTNAME} install glibc-langpack-{YOUR_LOCALE}
|
||||
----
|
||||
+
|
||||
The message: `install-info: File or directory not found for /dev/null` appears several times. The cause is that the `/dev/` file system is not yet initialized at this point. You may savely ignore the message.
|
||||
The message: `install-info: File or directory not found for /dev/null` appears several times. The cause is that the `/dev/` file system is not yet initialized at this point. You may safely ignore the message.
|
||||
|
||||
|
||||
=== 2.2 System container configuration and commissioning
|
||||
|
|
@ -105,7 +105,7 @@ In the same way you can create any other account. If you want to disallow root c
|
|||
----
|
||||
2. *Configuring host to provision network interfaces*
|
||||
+
|
||||
If you need a connection to an internal, protected network is needed (e.g. provided by libvirt) replace the host's interface by a xref:administration/virtual-bridge.adoc#_use_case_replacing_an_existing_interface_and_network[virtual bridge] if not already done, and assign its interface name to the container ressources in the host:
|
||||
If you need a connection to an internal, protected network is needed (e.g. provided by libvirt) replace the host's interface by a xref:administration/virtual-bridge.adoc#_use_case_replacing_an_existing_interface_and_network[virtual bridge] if not already done, and assign its interface name to the container resources in the host:
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -230,7 +230,7 @@ If inactive, activate and start the service.
|
|||
----
|
||||
9. *Configure default DNS search path*
|
||||
+
|
||||
Specify a search domain to appended to a unary hostname without domain part, usually the internal network domain name, e.g. example.lan. Adjust the config file according to the pattern below:
|
||||
Specify a search domain (typically your internal domain, like `example.lan`). When you look up a short hostname (e.g., server1), the system appends this domain automatically, forming server1.example.lan for DNS resolution. Update the config file accordingly.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -294,7 +294,7 @@ Activate the service if necessary.
|
|||
Container <CTNAME> terminated by signal KILL.
|
||||
----
|
||||
|
||||
== 3. Create an nspawn application container
|
||||
== 3. Create an `nspawn` application container
|
||||
|
||||
In this context, the term "application container" specifically refers to the way in which the container shares the host's network interfaces and possibly other resources, and may have either a reduced or a complete init system. It thus behaves like a standard application in a sandbox on the host.
|
||||
|
||||
|
|
@ -302,13 +302,13 @@ In this context, the term "application container" specifically refers to the way
|
|||
|
||||
. *Creating a container subdirectory*
|
||||
+
|
||||
The systemd-nspawn tooling expects a subdirectory, using its name as both the container name and the default hostname.
|
||||
The `systemd-nspawn` tooling expects a subdirectory, using its name as both the container name and the default hostname.
|
||||
+
|
||||
Create a subdirectory according your storage concept.
|
||||
|
||||
. *Create a minimal container directory tree*
|
||||
+
|
||||
The creation of a container filesystem or the provision of a corresponding image is treated as "out of scope" by systemd-nspawn. There are a number of alternative options. By far the easiest and most efficient way is simply to use the distribution specific bootstrap tool, DNF in case of fedora, in the container's directory. This is the recommended procedure.
|
||||
The creation of a container filesystem or the provision of a corresponding image is treated as "out of scope" by `systemd-nspawn`. There are a number of alternative options. By far the easiest and most efficient way is simply to use the distribution specific bootstrap tool, DNF in case of fedora, in the container's directory. This is the recommended procedure.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -327,7 +327,7 @@ Optionally, you may add your local language package
|
|||
# dnf --releasever=44 --best --setopt=install_weak_deps=False --use-host-config --installroot=/var/lib/machines/{CTNAME} install glibc-langpack-{YOUR_LOCALE}
|
||||
----
|
||||
+
|
||||
The message: `install-info: File or directory not found for /dev/null` appears several times. The cause is that the `/dev/` file system is not yet initialized at this point. You may savely ignore the message.
|
||||
The message: `install-info: File or directory not found for /dev/null` appears several times. The cause is that the `/dev/` file system is not yet initialized at this point. You may safely ignore the message.
|
||||
|
||||
|
||||
=== 3.2 Application container configuration and commissioning
|
||||
|
|
@ -388,9 +388,9 @@ You should see the same interfaces and IP addresses as on the host system.
|
|||
# hostnamectl set-hostname <FQDN>
|
||||
----
|
||||
|
||||
6. *Optional: modify the Terminalprompt*
|
||||
6. *Optional: modify the terminal prompt*
|
||||
+
|
||||
Include the name of the hostd to get ab indicator for the container
|
||||
Include the name of the host to get an indicator for the container
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ For additional information refer to https://docs.fedoraproject.org/en-US/fedora-
|
|||
|
||||
The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine.
|
||||
|
||||
Before you start the process you should use `df -h` to check the root file system. You need about 2-3 gb free space depending on your installation to store the rpm packages of the F43 release.
|
||||
Before you start the process you should use `df -h` to check the root file system. You need about 2-3 GB free space depending on your installation to store the rpm packages of the F43 release.
|
||||
|
||||
If you use postgresql, please note that the major version has increased from 16.9 to 18.0. This means that the database tables need to be adapted.
|
||||
|
||||
|
|
@ -147,15 +147,15 @@ $ sudo systemctl status postgresql
|
|||
|
||||
The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine.
|
||||
|
||||
Before you start the process you should use `df -h` to check the root file system. You need about 2-3 gb free space depending on your installation to store the rpm packages of the F41 release.
|
||||
Before you start the process you should use `df -h` to check the root file system. You need about 2-3 GB free space depending on your installation to store the rpm packages of the F41 release.
|
||||
|
||||
Please note that for an interactive remote installation, you must also add the parameter nomodeset to the kernel command line. For more information, see the corresponding installation instructions.
|
||||
Please note that for an interactive remote installation, you must also add the parameter `nomodeset` to the kernel command line. For more information, see the corresponding installation instructions.
|
||||
|
||||
=== Updating to Fedora 40
|
||||
|
||||
The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine.
|
||||
|
||||
Before you start the process you should use `df -h` to check the root file system. You need about 2-3 gb free space depending on your installation to store the rpm packages of the F40 release.
|
||||
Before you start the process you should use `df -h` to check the root file system. You need about 2-3 GB free space depending on your installation to store the rpm packages of the F40 release.
|
||||
|
||||
Note that the configuration of LVM has changed. The CLI commands now only take into account partitions that are listed in `lvmdevices`.
|
||||
|
||||
|
|
@ -169,14 +169,14 @@ There is an issue with the aarch64 SBC installation image. You cannot use a Fedo
|
|||
|
||||
The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine.
|
||||
|
||||
Before you start the process you should use `df -h` to check the root file system. You need about 2-3 gb free space depending on your installation to store the rpm packages of the F39 release.
|
||||
Before you start the process you should use `df -h` to check the root file system. You need about 2-3 GB free space depending on your installation to store the rpm packages of the F39 release.
|
||||
|
||||
|
||||
=== Updating to Fedora 38
|
||||
|
||||
The recommended procedure is upgrading using the _DNF System Upgrade_ plugin. This applies to Fedora Server Edition on hardware as well as in a virtual machine.
|
||||
|
||||
Before you start the process you should use `df -h` to check the root file system. You need about 2-3 gb free space depending on your installation to store the rpm packages of the F38 release.
|
||||
Before you start the process you should use `df -h` to check the root file system. You need about 2-3 GB free space depending on your installation to store the rpm packages of the F38 release.
|
||||
|
||||
=== Updating to Fedora 37
|
||||
|
||||
|
|
|
|||
|
|
@ -49,11 +49,11 @@ The Fedora Server Edition working group has also discussed this topic and agreed
|
|||
|
||||
A new Fedora installation creates a (modern) GPT partition table by default.
|
||||
|
||||
On a _BIOSboot_ machine, Anaconda creates at first a small (1 MiB) ```BIOS boot``` system partition on the first drive. It stores the second stage bootloader which is required by GNU/Grub. Subsequently, it creates a ``/boot``` partition of 1 GiB. It contains all the files necessary for booting Linux, especially the kernel. The remaining area is completely filled with a third partition containing one large volume group (LVM VG) named `fedora` by default. You end up with 3 primary partitions on the hard disk that use all the available space.
|
||||
On a _BIOSboot_ machine, Anaconda creates at first a small (1 MiB) `BIOS boot` system partition on the first drive. It stores the second stage bootloader which is required by GNU/Grub. Subsequently, it creates a `/boot` partition of 1 GiB. It contains all the files necessary for booting Linux, especially the kernel. The remaining area is completely filled with a third partition containing one large volume group (LVM VG) named `fedora` by default. You end up with 3 primary partitions on the hard disk that use all the available space.
|
||||
|
||||
Fedora can still use the (legacy) MBR partition scheme, provided that the disk is not larger than 2 TB. It then omits the ```BIOSboot``` partition and uses only the other two partitions.
|
||||
Fedora can still use the (legacy) MBR partition scheme, provided that the disk is not larger than 2 TB. It then omits the `BIOSboot` partition and uses only the other two partitions.
|
||||
|
||||
In the case of a _UEFI_ boot system, Anaconda creates first the required 'EFI System' partition and then adds the aforementioned ```/boot``` partition and one large LVM partition and Volume Group (VG) as described above. You will end up with 3 partitions on the hard disk that completely occupy the available space.
|
||||
In the case of a _UEFI_ boot system, Anaconda creates first the required 'EFI System' partition and then adds the aforementioned `/boot` partition and one large LVM partition and Volume Group (VG) as described above. You will end up with 3 partitions on the hard disk that completely occupy the available space.
|
||||
|
||||
In _each_ of these alternatives, Anaconda creates one logical volume of approximately 15 GiB (the exact value depends on the disk capacity of your system) named `root` for the operating system and its software. The remaining available space is at the disposal of the system administrator for free use to store user data.
|
||||
|
||||
|
|
@ -69,12 +69,12 @@ In this way, any error that may occur in the file system should have as little i
|
|||
|
||||
If you are a more experienced administrator, you may wish to further the rationale above with increased separation.
|
||||
|
||||
You will select `Custom` and create the `BIOSboot`, `efi` and `/boot` partitions as required and a small partition and VG dedicated to the operating system. A good size for this VG (eg. ```sysvg```) is, approximately, 30 GiB. Occupying the remaining space, you will create a dedicated partition and Volume group (eg. ```usrvg```) for user data. You will end up with 4 partitions on the hard disk (boot, sysvg, usrvg with Bios boot machines and hard disks up to 2 TB) rsp. 4 partitions (BIOSboot/efi, boot, sysvg, usrvg for all other machines) that use all the available space.
|
||||
You will select `Custom` and create the `BIOSboot`, `efi` and `/boot` partitions as required and a small partition and VG dedicated to the operating system. A good size for this VG (e.g. `sysvg`) is approximately 30 GiB. Occupying the remaining space, you will create a dedicated partition and volume group (e.g. `usrvg`) for user data. You will end up with 4 partitions on the hard disk: `boot`, `sysvg`, and `usrvg` for BIOS systems or those with disks up to 2 TB; or `BIOSboot`/`efi`, `boot`, `sysvg`, and `usrvg` for all other machines. All configurations use the entire available space.
|
||||
|
||||
Create a LV (e.g. ```sys_root```) of about 15 GiB for the operating system and maybe additional LVs for the runtime environment, e.g. a LV ```sys_log``` of about 5 GB. Mount it at ```/var/log``` to prevent log files from flooding and blocking the system and, vice versa, prevent that any other space issue on the root partition block your logs and complicate error analysis. The remaining free space is left for distribution as needed over time. Similar to the default partitioning, all user data is created as LVs in ```usrvg``` and mounted in the corresponding directories of the system. This is the maximum possible separation of system and user data with only one hard disk available. And with today's typical hard drive size of 2 TB and more, those dedicated 30 GBs do not interfere with the effective use of disk space anymore.
|
||||
Create a LV (e.g. `sys_root`) of about 15 GiB for the operating system and maybe additional LVs for the runtime environment, e.g. a LV `sys_log` of about 5 GB. Mount it at `/var/log` to prevent log files from flooding and blocking the system and, vice versa, prevent that any other space issue on the root partition block your logs and complicate error analysis. The remaining free space is left for distribution as needed over time. Similar to the default partitioning, all user data is created as LVs in `usrvg` and mounted in the corresponding directories of the system. This is the maximum possible separation of system and user data with only one hard disk available. And with today's typical hard drive size of 2 TB and more, those dedicated 30 GBs do not interfere with the effective use of disk space anymore.
|
||||
|
||||
|
||||
==== Raid system
|
||||
==== RAID system
|
||||
|
||||
If there is more than one disk available, the default partitioning creates, on each of the other disks, one big partition with a Physical Volume (PV) and adds it to the VG.
|
||||
|
||||
|
|
@ -141,7 +141,7 @@ $ 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 its size, it can accomodate multiple ISO files. The server sysadmin can choose between them at boot time in a selection menu. With a new version simply copy the ISO file as it is on the stick and ready to go. No more dd and no Media Writer.
|
||||
. As a system administrator, you might appreciate a tool provided by the https://www.ventoy.net/[`ventoy` project]. A small utility on a USB stick of any size takes over the presentation of the device to the hardware as bootable, and reads itself the ISO file, which is stored on a data partition of the stick. Depending on its size, it can accommodate multiple ISO files. The server sysadmin can choose between them at boot time in a selection menu. With a new version simply copy the ISO file as it is on the stick and ready to go. No more dd and no Media Writer.
|
||||
|
||||
With everything done proceed with one of the available installation procedures.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Peter Boy; Kevin Fenzi; Emmanuel Seyman
|
|||
:page-aliases: pages/installation-interactive-local.adoc
|
||||
|
||||
[abstract]
|
||||
This is the default method for manually installing Fedora if console access is available. The graphical interface is designed with the goal of making the installation as simple and speedy as possible. It is intended to facilitate the work of the system administrator by preassigning as many installation options as possible after analyzing the hardware.
|
||||
This is the default method for manually installing Fedora if console access is available. The graphical interface is designed with the goal of making the installation as simple and speedy as possible. It is intended to facilitate the work of the system administrator by automatically specifying as many installation options as possible after analyzing the hardware.
|
||||
|
||||
|
||||
// Before publishing, comment out the warning.
|
||||
|
|
@ -108,7 +108,7 @@ Anaconda defaults to Automatic, which follows the recommended default storage or
|
|||
+
|
||||
If there is more than one disk available, the default partitioning creates, on each of the other disks, one big partition with a Physical Volume (PV) and adds it to the Volume Group (VG). On a server, this is usually not optimal. Rather, you would use the opportunity to store data redundantly and open up the opportunity to maintain operation in the event of a disk failure.
|
||||
+
|
||||
If your machine does not include a hardware raid capability, you may configure a software RAID system. Switch to xref:installation/sw-raid-upon-installation.adoc[Exkurs: Configuring a software RAID during installation] and then continue here with the Network section.
|
||||
If your machine does not include a hardware raid capability, you may configure a software RAID system. Switch to xref:installation/sw-raid-upon-installation.adoc[`Exkurs`: Configuring a software RAID during installation] and then continue here with the Network section.
|
||||
|
||||
* *Custom configuration*
|
||||
+
|
||||
|
|
@ -146,7 +146,7 @@ By clicking onto the + sign you can add partitions according to your storage con
|
|||
|
||||
Fedora uses a GPT partitioning scheme. Thus, on a BIOSboot system you must add a BIOSboot partition, preferably as the first one. On a UEFIboot system you have to add an EFI system partition, preferably as the first one. If you forget it, Anaconda will remind you.
|
||||
|
||||
===== How to find out if firmware is efi-boot or bios-boot
|
||||
===== How to find out if firmware is UEFI-boot or BIOS-boot
|
||||
|
||||
Open a temporary shell by using `<alt>+<ctrl>+<F2>` and type into the terminal window:
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ For MacOS you may use one of the following options:
|
|||
--
|
||||
* __Windows App__ - provided by Microsoft for free via App Store
|
||||
* __Jump Desktop__ - commercial application via App Store
|
||||
* __freerdp__ - Free implementation of the Remote Desktop Protocol installable via homebrew or macport
|
||||
* __FreeRDP__ - Free implementation of the Remote Desktop Protocol installable via Homebrew or MacPorts
|
||||
--
|
||||
|
||||
== Booting the server
|
||||
|
|
@ -119,7 +119,7 @@ sdb 8:16 1 1001.5M 0 disk
|
|||
zram0 252:0 0 8G 0 disk [SWAP]
|
||||
----
|
||||
+
|
||||
In the example above, the USB stick is sdb. Just in case it is mounted, unmount and then format and mount it at e.g. /mnt
|
||||
In the example above, the USB stick is `sdb`. If already mounted, unmount, format, and mount at e.g. `/mnt`.
|
||||
+
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -208,7 +208,7 @@ This window will provide full remote access to the installer until the installat
|
|||
+
|
||||
[TIP]
|
||||
====
|
||||
If the screen freezes after some mouse or keyboard actions, add the kernel option __nomodeset__ before the term _inst.rdp_ to the kernel commad line in step __3.1.1__.
|
||||
If the screen freezes after some mouse or keyboard actions, add the kernel option `nomodeset` before the term _inst.rdp_ to the kernel command line in step __3.1.1__.
|
||||
====
|
||||
|
||||
You can then proceed with xref::installation/interactive-local.adoc[Fedora Server interactive local installation].
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ Even if you activated root access during installation, you have hopefully kept t
|
|||
|
||||
=== 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_' and trailing types abbreviation, e.g. '_rsa', is just a common convention, yet helpful.
|
||||
This step is to be performed only if a pair of keys does not already exist. It is best to create the key in the _.ssh_ directory of the desktop user. It should not be secured by password to enable automatic processing. The naming with leading `id_` and trailing types abbreviation, e.g. `_rsa`, is just a common convention, yet helpful.
|
||||
|
||||
a. Execute on the local desktop
|
||||
+
|
||||
|
|
@ -84,7 +84,7 @@ $ cd ~/.ssh
|
|||
$ ssh-keygen -t rsa -b 4096 -C "root@example.com" -f <outputkeyfile>
|
||||
----
|
||||
|
||||
Although the type rsa is widely used, you may adjust your key type accordingly.
|
||||
Although RSA is widely used, you may adjust your key type accordingly.
|
||||
|
||||
=== Transfer and install the public key onto the server
|
||||
|
||||
|
|
@ -407,7 +407,7 @@ 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 is time to update the system and install some useful software. Of course, 'useful software' varies depending on the use case or applications that will be run on Fedora Server. Anyway, a good choice might be vim. With vimdiff e.g. a comparison of updates of configuration files (*.rpmnew) is very comfortable and straightforward.
|
||||
Now that secure administrative access is in place, it is time to update the system and install some useful software. Of course, 'useful software' varies depending on the use case or applications that will be run on Fedora Server. Anyway, a good choice might be `vim`. With `vimdiff` e.g. a comparison of updates of configuration files (*.rpmnew) is very comfortable and straightforward.
|
||||
[source,console]
|
||||
----
|
||||
# dnf install vim-default-editor --allowerasing
|
||||
|
|
|
|||
|
|
@ -5,10 +5,10 @@ Peter Boy; Stephen Daley; Kevin Fenzi
|
|||
:revdate: 2026-04-28
|
||||
|
||||
[abstract]
|
||||
This Exkurs describes the configuration of a _software RAID_ as part of an interactive Fedora Server Edition installation. In this case, the RAID capability is provided by operating system drivers and processed by the computer CPU. It does not cover firmware raid (also called Windows RAID), which provide this capability via the computer internal firmware, nor hardware raid, where dedicated integrated hardware modules or adapters completely relieve the computer CPU of the raid processing.
|
||||
This `Exkurs` describes the configuration of a _software RAID_ as part of an interactive Fedora Server Edition installation. In this case, the RAID capability is provided by operating system drivers and processed by the computer CPU. It does not cover firmware raid (also called Windows RAID), which provide this capability via the computer internal firmware, nor hardware raid, where dedicated integrated hardware modules or adapters completely relieve the computer CPU of the raid processing.
|
||||
|
||||
|
||||
The RAID configuraton starts at the "Installation Destination" window.
|
||||
The RAID configuration starts at the Installation Destination window.
|
||||
|
||||
.The Installation Destination window
|
||||
image:installation/sw-raid/001-installationdestination.png[]
|
||||
|
|
@ -56,13 +56,13 @@ If the area beyond __Unknown__ contains one or more partition, check whether you
|
|||
+
|
||||
To delete a partition, click on it and then on the '-' sign at the bottom. At the end, all disks must either be empty or identically partitioned.
|
||||
|
||||
. *On a BIOS boot system only, create a biosboot partition on each disk*
|
||||
. *On a BIOS boot system only, create a `biosboot` partition on each disk*
|
||||
+
|
||||
On a BIOS boot system, a GPT partition table as used by Fedora requires a small BIOSBoot partition for the Grub boot loader. Create it at the beginning of each disk to keep the system operational when one disk fails. Skip this step, if your host uses UEFI!
|
||||
+
|
||||
Use the "+" sign to add a partition. In the Mount Point field select 'biosboot' and set a size of 1 MiB.
|
||||
Use the "+" sign to add a partition. In the Mount Point field select '`biosboot`' and set a size of 1 MiB.
|
||||
+
|
||||
A biosboot entry appears in the left __New Fedora 41 Installation__ section on one of he disks.
|
||||
A `biosboot` entry appears in the left __New Fedora 41 Installation__ section on one of he disks.
|
||||
+
|
||||
Repeat it and you see a second entry, usually on the same disk.
|
||||
+
|
||||
|
|
@ -71,12 +71,12 @@ image:installation/sw-raid/105-custom-biosboot-1.png[]
|
|||
+
|
||||
Select the new entry and click on __Modify__ at __Device(s)__. In the device list select one of the other disks. Then select __Update Settings__.
|
||||
+
|
||||
Anaconda updates the list of partitions in the _New Fedora 41 installation_ section so that the biosboot partition is now the first partition on different disks.
|
||||
Anaconda updates the list of partitions in the _New Fedora 41 installation_ section so that the `biosboot` partition is now the first partition on different disks.
|
||||
+
|
||||
.The adjusted BiosBoot installation
|
||||
image:installation/sw-raid/110-custom-biosboot-2.png[]
|
||||
+
|
||||
Repeat the step until all disks have a biosboot partition. This is necessary so that the system can boot from any of the other disks if the first disk fails.
|
||||
Repeat the step until all disks have a `biosboot` partition. This is necessary so that the system can boot from any of the other disks if the first disk fails.
|
||||
|
||||
. *On a UEFI boot system only, create an EFI partition*
|
||||
+
|
||||
|
|
@ -93,7 +93,7 @@ image:installation/sw-raid/120-custom-efi-1.png[]
|
|||
+
|
||||
Anaconda sets up an EFI partition on the first disk. But a RAID system must be able to boot from any of the available disks, not just the first one. Otherwise, the system would be paralyzed if that failed. One solution is to set up the EFI partition as a RAID as well.
|
||||
+
|
||||
Find the property Device Type and use the drop down list to change Standard partition to RAID. In the right side shows up a new selection box RAID level showing initially RAID1 (mirroring) in this example, because we have just 2 disks. Leave the file system as “EFI System Partition”. Choose an optional label, e.g. sysefi, and trigger “Update Settings” further below.
|
||||
Find the property Device Type and use the drop down list to change Standard partition to RAID. In the right side shows up a new selection box RAID level showing initially RAID1 (mirroring) in this example, because we have just 2 disks. Leave the file system as "EFI System Partition". Choose an optional label, e.g. `sysefi`, and trigger "Update Settings" further below.
|
||||
+
|
||||
.Final EFI system partition properties
|
||||
image:installation/sw-raid/125-custom-efi-2.png[]
|
||||
|
|
@ -108,7 +108,7 @@ Tick the "+" sign and a form "Add a new Mount Point" opens again.
|
|||
+
|
||||
A new mount point is created on sda1. On the right side there is a form to show and modify some properties. Find the property _Device Type_ and use the drop down list to change Standard partition to __RAID__. In the right side shows up a new selection box _RAID level_ showing initially RAID1 (mirroring) in this example, because we have just 2 disks. Choose the RAID level you wish and then click on _Update Settings_ further down.
|
||||
+
|
||||
Anaconda updates the form and the list beyond __New Fedora 41 Installation__. The sdx partition is gone and replaced by a (device) name, the same one you find in the property form on the right side. In the form you can add a label, e.g. sysboot, if you like, and _Update Settings_ again.
|
||||
Anaconda updates the form and the list beyond __New Fedora 41 Installation__. The `sdx` partition is gone and replaced by a (device) name, the same one you find in the property form on the right side. In the form you can add a label, e.g. `sysboot`, if you like, and _Update Settings_ again.
|
||||
+
|
||||
.Final properties of the boot device (raid partition)
|
||||
image:installation/sw-raid/130-custom-finalbootform.png[]
|
||||
|
|
@ -139,7 +139,7 @@ Select a proper RAID level and check the size policy.
|
|||
* _Maximum size_ expands the Volume Group to fill up the complete hard disk, so you can add Logical Volumes with a minimum of effort. That is the recommended way for medium size disks.
|
||||
* _Fixed size_ lets you specify a size that fulfills your foreseeable requirements and leaving some space for later adjustments that come up as a surprise.
|
||||
+
|
||||
This option also allows for an __even stronger separation of system and user data__. Specify a fixed size of 20-30 GiB for a system volume group (named e.g. fedora_sysvg). This contains the root file system and, if applicable, further system-related logical volumes. In the remaining space you will later set up a user volume group (correspondingly named fedora_usrvg) and logical volumes for user data. This gives you the greatest possible flexibility to adapt the system area to changes in demand or technical developments without touching the precious user data at all. This is recommended for large hard disks, servers with a planned longtime lifespan, or remotely located servers.
|
||||
This option also allows for an __even stronger separation of system and user data__. Specify a fixed size of 20-30 GiB for a system volume group (named e.g. `fedora_sysvg`). This contains the root file system and, if applicable, further system-related logical volumes. In the remaining space you will later set up a user volume group (correspondingly named `fedora_usrvg`) and logical volumes for user data. This gives you the greatest possible flexibility to adapt the system area to changes in demand or technical developments without touching the precious user data at all. This is recommended for large hard disks, servers with a planned longtime lifespan, or remotely located servers.
|
||||
|
||||
. *Customize the storage organization to your requirements*
|
||||
+
|
||||
|
|
@ -162,7 +162,7 @@ If there are partitions on any of the hard disks, delete the partitions if they
|
|||
+
|
||||
To delete a partition, click on it and then on the circled "x" sign below. In the end, all hard disks must either be empty or identically partitioned. In the following, we assume that the hard disks are empty.
|
||||
|
||||
. *On a BIOS boot system only, create a biosboot partition on each disk*
|
||||
. *On a BIOS boot system only, create a `biosboot` partition on each disk*
|
||||
+
|
||||
On a BIOS boot system, a GPT partition table as used by Fedora requires a small BIOSBoot partition for the Grub boot loader. Create it at the beginning of each disk to keep the system operational when one disk fails. Skip this step, if your host uses UEFI!
|
||||
+
|
||||
|
|
@ -191,7 +191,7 @@ Anaconda sets up an EFI partition on the first disk. But a RAID system must be a
|
|||
* select RAID level raid1
|
||||
* enter 0.6 GiB size
|
||||
* select Filesystem "EFI System Partition"
|
||||
* enter Label "sysefi"
|
||||
* enter Label "`sysefi`"
|
||||
* enter Name "boot_efi"
|
||||
* Enter Mountpoint /boot/efi
|
||||
* Tick "OK"
|
||||
|
|
@ -211,14 +211,14 @@ image:installation/sw-raid/215-adv-custom-boot.png[]
|
|||
In the “Device type” selection box, select “Software RAID” . The form changes.
|
||||
Then fill out the rest of the form as indicated.
|
||||
+
|
||||
* select sda and sdb as RAID members
|
||||
* select `sda` and `sdb` as RAID members
|
||||
* select RAID level raid1
|
||||
* enter 1.0 GiB size
|
||||
* keep Filesystem "xfs"
|
||||
* enter Label "sysboot"
|
||||
* enter Name "boot"
|
||||
* Enter Mountpoint /boot
|
||||
* Tick "OK"
|
||||
* keep Filesystem: `xfs`
|
||||
* enter Label: `sysboot`
|
||||
* enter Name: `boot`
|
||||
* Enter Mountpoint: `/boot`
|
||||
* Tick **OK**
|
||||
+
|
||||
The installation window refreshes and now shows another new RAID entry in the left column and a boot partition in the sda disk.
|
||||
+
|
||||
|
|
@ -239,7 +239,7 @@ Again, in the “Device type” selection box, select “Software RAID” and th
|
|||
* select RAID level raid1
|
||||
* Specify the size of the partition. There are basically three options.
|
||||
** __Leave the size as suggested by the form__, which fills the rest of the hard disk. Both system and user data are stored in a common volume group. This is appropriate for hosts with a planned lifespan of a few years or less and/or a disk capacity of less than 0.5 - 1 TB.
|
||||
** __Set aside a 20–30/50 GiB partition for the system area__ and, in the next step, another partition exclusively for user data. This is particulary recommended for systems with a planned longtime lifespan, a hard disk capacity of more than 1–2 TiB, and especially for systems in remote data centers where there is never any possibility of accessing the system console. In the latter case, it is especially important to keep system and user areas strictly separated as far as possible on the same hard disk, in order to be able to carry out any system work without ever having to touch the precious user data.
|
||||
** __Set aside a 20-30/50 GiB partition for the system area__ and, in the next step, another partition exclusively for user data. This is particularly recommended for systems with a planned longtime lifespan, a hard disk capacity of more than 1-2 TiB, and especially for systems in remote data centers where there is never any possibility of accessing the system console. In the latter case, it is especially important to keep system and user areas strictly separated as far as possible on the same hard disk, in order to be able to carry out any system work without ever having to touch the precious user data.
|
||||
** In either case, __leave some free space at the end__ to allow for possible future adjustments to changing and unpredictable needs.
|
||||
+
|
||||
In this example, we use a 30 GiB system area and the entire rest for a dedicated user area.
|
||||
|
|
@ -248,21 +248,21 @@ In this example, we use a 30 GiB system area and the entire rest for a dedicated
|
|||
* enter Name "syspv"
|
||||
* Tick "OK"
|
||||
+
|
||||
The list view refreshes and shows the harddisks with the 3 partitions and on the left column an additional RAID device.
|
||||
The list view refreshes and shows the hard disks with the 3 partitions and on the left column an additional RAID device.
|
||||
+
|
||||
.Partitions list including EFI, boot and physical volume partitions
|
||||
image:installation/sw-raid/222-adv-custom-syspvlist.png[]
|
||||
+
|
||||
In contrast to other GUIs, a volume group (VG) is not created immediately, but a "physical volume" is created first. Many other GUIs perform this step implicitly and automatically.
|
||||
+
|
||||
Double-click onto the syspv icon in the left bar to activate it and then on the Plus sign to open a device creation form.
|
||||
Double-click onto the `syspv` icon in the left bar to activate it and then on the Plus sign to open a device creation form.
|
||||
+
|
||||
.Partitions list including EFI, boot and physical volume partitions
|
||||
image:installation/sw-raid/224-adv-custom-sysvgform.png[]
|
||||
+
|
||||
Leave the Device type and Size field as is and enter "sysvg" into the Name field. Tick OK to submit the form.
|
||||
Leave the Device type and Size field as is and enter "`sysvg`" into the Name field. Tick OK to submit the form.
|
||||
+
|
||||
The overview list screen now shows a new Volume Group device "sysvg" beyond a new category "LVM".
|
||||
The overview list screen now shows a new Volume Group device `sysvg` beyond a new category "LVM".
|
||||
+
|
||||
.Devices list showing partitions, volume groups and RAID devices
|
||||
image:installation/sw-raid/226-adv-custom-sysgvlist.png[]
|
||||
|
|
@ -283,16 +283,16 @@ Either leave the suggested size value as it is to set up the entire free area fo
|
|||
.Partitions list including EFI, boot and physical volume partitions
|
||||
image:installation/sw-raid/234-adv-custom-usrvg.png[]
|
||||
+
|
||||
Leave the Device type and Size field as is and enter "usrvg" into the Name field. Tick OK to submit the form.
|
||||
Leave the Device type and Size field as is and enter "`usrvg`" into the Name field. Tick OK to submit the form.
|
||||
+
|
||||
The overview list screen now shows a new Volume Group device "sysvg" beyond a new category "LVM".
|
||||
The overview list screen now shows a new Volume Group device `usrvg` beyond a new category "LVM".
|
||||
+
|
||||
.Devices list showing partitions, two volume groups and RAID devices
|
||||
image:installation/sw-raid/236-adv-custom-usrvglist.png[]
|
||||
|
||||
. *Creating the ROOT file system*
|
||||
+
|
||||
As in the previous steps, clicking on symbol sysvg activates the unit for editing and clicking on the free area releases the plus sign. A click on the plus sign opens the dialogue for setting up a file system.
|
||||
As in the previous steps, clicking on symbol `sysvg` activates the unit for editing and clicking on the free area releases the plus sign. A click on the plus sign opens the dialogue for setting up a file system.
|
||||
+
|
||||
.Creating the ROOT file system
|
||||
image:installation/sw-raid/240-adv-custom-rootfsform.png[]
|
||||
|
|
@ -312,9 +312,9 @@ Finally, you can further customize the storage organization to your requirements
|
|||
|
||||
* __Optional: Create a separate log file system__
|
||||
+
|
||||
Some administrators like to confine the /var/log subdirectory in its own Logical Volume. This prevents excessive logging from filling up the root file system. But also vice versa, that excessive outputs of a program fill up the root file system to such an extent that no more log outputs can be saved and troubleshooting is made more difficult.
|
||||
Some administrators like to confine the `/var/log` subdirectory in its own Logical Volume. This prevents excessive logging from filling up the root file system. But also vice versa, that excessive outputs of a program fill up the root file system to such an extent that no more log outputs can be saved and troubleshooting is made more difficult.
|
||||
+
|
||||
As in the previous steps, clicking on symbol sysvg activates the unit for editing and clicking on the free area releases the plus sign. A click on the plus sign opens the dialogue for setting up a file system.
|
||||
As in the previous steps, clicking on symbol `sysvg` activates the unit for editing and clicking on the free area releases the plus sign. A click on the plus sign opens the dialogue for setting up a file system.
|
||||
+
|
||||
.Creating log file system
|
||||
image:installation/sw-raid/250-adv-custom-varlogform.png[]
|
||||
|
|
@ -336,7 +336,7 @@ But sometimes they need to upload some data for further processing on the server
|
|||
+
|
||||
For a large number of users, use the user area, if available
|
||||
+
|
||||
** Select a suitable Volume Group, double-click on the device in the left column (sysvg or usrvg), and then into the free space to release the "plus" button.
|
||||
** Select a suitable Volume Group, double-click on the device in the left column (`sysvg` or `usrvg`), and then into the free space to release the "plus" button.
|
||||
+
|
||||
.Creating a home file system
|
||||
image:installation/sw-raid/260-adv-custom-usrhomeform.png[]
|
||||
|
|
@ -348,26 +348,26 @@ image:installation/sw-raid/260-adv-custom-usrhomeform.png[]
|
|||
.Storage overview including a home file system
|
||||
image:installation/sw-raid/264-adv-custom-usrhomelist.png[]
|
||||
|
||||
* __Optional: Setting up a server (/srv) storage space__
|
||||
* __Optional: Setting up a server (`/srv`) storage space__
|
||||
+
|
||||
According to the Filesystem Hierarchy Standard (FHS), a system should store site-specific data served by the server, such as data and scripts for web servers, data offered by FTP servers, etc. in /srv. These belong into a separate file system.
|
||||
|
||||
** Select a suitable Volume Group, in this example usrvg if available. Double-click on the device in the left column and then into the free space to release the "plus" button.
|
||||
** Select a suitable Volume Group, in this example `usrvg` if available. Double-click on the device in the left column and then into the free space to release the "plus" button.
|
||||
+
|
||||
.Creating a srv file system
|
||||
.Creating a `/srv` file system
|
||||
image:installation/sw-raid/270-adv-custom-srvform.png[]
|
||||
|
||||
** Leave the Device type and Available devices as is.
|
||||
** Specify a reasonable size depending on your system planning.
|
||||
** Complete the form as indicated.
|
||||
+
|
||||
.Devices list showing the srv file system
|
||||
.Devices list showing the `/srv` file system
|
||||
image:installation/sw-raid/274-adv-custom-srvlist.png[]
|
||||
|
||||
* __If applicable: Setting up a virtual machine's storage space__
|
||||
+
|
||||
|
||||
** Select a suitable Volume Group, in this example usrvg if available. Double-click on the device in the left column and then into the free space to release the "plus" button.
|
||||
** Select a suitable Volume Group, in this example `usrvg` if available. Double-click on the device in the left column and then into the free space to release the "plus" button.
|
||||
+
|
||||
.Creating a libvirt file system
|
||||
image:installation/sw-raid/280-adv-libvirtform.png[]
|
||||
|
|
@ -380,4 +380,4 @@ image:installation/sw-raid/280-adv-libvirtform.png[]
|
|||
image:installation/sw-raid/284-adv-custom-libvirtlist.png[]
|
||||
|
||||
|
||||
Finally, click on Done, in the upcoming list accept the Changes and return now to the original guide, probably xref::installation/interactive-local.adoc#_networking[Fedora Server interactive local installation] guide.
|
||||
Finally, click on Done, in the upcoming list accept the Changes and return now to the original guide, probably xref::installation/interactive-local.adoc#_networking[Fedora Server interactive local installation] guide.
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Thus, the question of appropriateness depends much on several criteria and inten
|
|||
|
||||
== How Fedora supports the diversity of single board computers
|
||||
|
||||
Fedora distributes a generic Fedora Server Edition image, preconfigured for Raspberry Pi. Additionally, it provides a utility to transfer the image to the prospective boot medium, usually an SD card. To support multiplemodels, the transfer program is able to (re-)configure the disk image for an alternative SBC model. Optionally, it can also make some adjustments to the initial configuration.
|
||||
Fedora distributes a generic Fedora Server Edition image, preconfigured for Raspberry Pi. Additionally, it provides a utility to transfer the image to the prospective boot medium, usually an SD card. To support multiple models, the transfer program is able to (re-)configure the disk image for an alternative SBC model. Optionally, it can also make some adjustments to the initial configuration.
|
||||
|
||||
== Conclusion
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ ARM single-board computers typically have only __one data storage medium__, an S
|
|||
|
||||
== How it works
|
||||
|
||||
Even though many SBC devices now also feature eMMC modules or m.2 NVMe interfaces, the boot process remains very simple. The minimal firmware continues to boot from the SD card, and possibly supplementally from eMMC or an SPI flash module. The device expects a ready-to-use operating system, configured precisely for the respective hardware, including low-level hardware initialization.
|
||||
Even though many SBC devices now also feature eMMC modules or m.2 NVMe interfaces, the boot process remains very simple. The minimal firmware continues to boot from the SD card, and may also use eMMC or an SPI flash module. The device expects a ready-to-use operating system, configured precisely for the respective hardware, including low-level hardware initialization.
|
||||
|
||||
A widely used software that provides this functionality is the bootloader __u-boot__. It is basically a collection of low-level, model-specific device drivers.
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ Even though the installation works quite differently, Fedora Server ultimately f
|
|||
|
||||
== Prerequisites
|
||||
|
||||
* Of course, you need a *suitable single board computer* model, _supported by Fedora_ and with a network connection, keyboard and display. A simple text console is perfectly sufficient.
|
||||
* Of course, you need a *suitable single board computer* model, _supported by Fedora_ and with a network connection, keyboard, and display. A simple text console is perfectly sufficient.
|
||||
+
|
||||
[WARNING]
|
||||
====
|
||||
|
|
@ -57,7 +57,7 @@ The utility should basically be usable with any Linux desktop, but not with Wind
|
|||
|
||||
Basically, Fedora Server on SBC follows the same storage configuration principles as on 'full-blown' Server Hardware. Please, read the section "Storage organization" in the xref:installation/index.adoc#_storage_organization[installation overview] and the supplementary information in the xref:installation/postinstallation-tasks.adoc#_consolidate_storage_configuration[Post installation tasks] section. Fedora Server Edition implements this principle, which originated in professional IT, __on SBCs__ as well.
|
||||
|
||||
Fedora uses UEFI as the boot system, but on SBCs it still uses a DOS/MBR partition table. Therefore, it first creates a FAT partition for EFI and a small /boot partition, used by grub2 bootloader. Thereafter, it creates another partition including one LVM volume group (VG) as described in the forementioned guide.
|
||||
Fedora uses UEFI as the boot system, but on SBCs it still uses a DOS/MBR partition table. Therefore, it first creates a FAT partition for EFI and a small /boot partition, used by grub2 bootloader. Thereafter, it creates another partition including one LVM volume group (VG) as described in the aforementioned guide.
|
||||
|
||||
For practical reasons, the downloaded deliverable is limited to just under 8 GB in total. During or after installation, the size is adjusted to the existing hardware.
|
||||
|
||||
|
|
@ -256,7 +256,7 @@ If you enter a "c", the user configuration will be closed and you will return to
|
|||
+
|
||||
Usually, leave the ntp server as is.
|
||||
+
|
||||
If you are uncomfortable with the entry here, you can also enter this and all the following information later comforatbly with the Web interface.
|
||||
If you are uncomfortable with the entry here, you can also enter this and all the following information later comfortably with the Web interface.
|
||||
|
||||
6. If you do not have a DHCP server on your LAN you may configure network connection in this menu or use the command line in the next stage. Specifically it you use a non-US keyboard it may be tedious and error prone to use this menu.
|
||||
+
|
||||
|
|
@ -295,7 +295,7 @@ $ localectl list-keymaps
|
|||
$ sudo localectl setkeymap de-nodeadkeys
|
||||
----
|
||||
+
|
||||
The mapping is imediately active.
|
||||
The mapping is immediately active.
|
||||
|
||||
c. Configure and activate the network. Adjust the IP, gateway and network settings accordingly.
|
||||
+
|
||||
|
|
@ -342,11 +342,11 @@ image::installation/on-sbc-020.png[Cockpit Login Screen]
|
|||
+
|
||||
image::installation/on-sbc-030.png[Cockpit Overview Screen]
|
||||
+
|
||||
Activate administrative permissins in the top bar.
|
||||
Activate administrative permissions in the top bar.
|
||||
|
||||
3. First *adjust hostname*
|
||||
+
|
||||
In the Box "Configuration" click on "__edit__" beside the hostname and enter a short name (display name) and a fqdn name.
|
||||
In the Box "Configuration" click on "__edit__" beside the hostname and enter a short name (display name) and an FQDN.
|
||||
|
||||
4. *Adjust time and time zone* if necessary and not already done. Click on system time and select the time zone. Automatic time synchronization should already be enabled.
|
||||
+
|
||||
|
|
@ -378,7 +378,7 @@ With everything done reboot the system. In the overview screen select either reb
|
|||
a. If your DHCP is correctly configured, you should be able to *find your device by name* now. Close your browser window and start again. Write the device name and port number in the address field, e.g. http://rockpro.example.com:9090 and Cockpit should come up again (after the usual warning about an insecure connection).
|
||||
b. You should be able to log in via **ssh and your key**. Try _ssh -i .ssh/MYKEY rockpi.example.com_ and after answering a question to accept the fingerprint you should gain access.
|
||||
|
||||
9. Finally, depending on the use case, you may need to ensure you can always track which person was logged in and when. Use Cockpits account management feature to comfortably create additional users and grant them administrativ permissions ("sudo").
|
||||
9. Finally, depending on the use case, you may need to ensure you can always track which person was logged in and when. Use Cockpits account management feature to comfortably create additional users and grant them administrative permissions (`sudo`).
|
||||
|
||||
|
||||
== Configuration of the storage area
|
||||
|
|
@ -387,11 +387,11 @@ As explained at the beginning, there are at least three alternatives to organize
|
|||
|
||||
1. Filling all the space left after the base installation with the ROOT file system.
|
||||
+
|
||||
This is the simplest solution and the only sensible one for disks of up to 16gb.
|
||||
This is the simplest solution and the only sensible one for disks of up to 16 GB.
|
||||
|
||||
2. Extend the partition and volume group to the remaining available disk space, extend the logical volume with the ROOT file system to about 12gb and leave the remaining area for logical volumes for dedicated payloads (database, libraries, etc.).
|
||||
2. Extend the partition and volume group to the remaining available disk space, extend the logical volume with the ROOT file system to about 12 GB and leave the remaining area for logical volumes for dedicated payloads (database, libraries, etc.).
|
||||
+
|
||||
This is the most flexible solution and preserves all options for the system administrator depending on the actual progression of usage. It is especially recommended for disks of 64gb and more, but should also be considered with a size of 32 gb.
|
||||
This is the most flexible solution and preserves all options for the system administrator depending on the actual progression of usage. It is especially recommended for disks of 64 GB and more, but should also be considered with a size of 32 GB.
|
||||
|
||||
3. You may reinforce the rationale of separating system and user data even further and create a separate partition and volume group for user data. This seems a bit far-fetched for a (small) SBC, but is nevertheless worth considering if a very large volume and correspondingly a large amount of data are present (a rule of thumb: larger 500 GB).
|
||||
|
||||
|
|
@ -400,8 +400,8 @@ This is the most flexible solution and preserves all options for the system admi
|
|||
Any of the alternatives as above start with the same administrative tasks.
|
||||
|
||||
1. Login via ssh or switch to terminal in Cockpit
|
||||
2. Use lsblk to determine the device name of your disk storage, most likely mmcblk1
|
||||
3. Invoke _sudo cfdisk_ with that device name:
|
||||
2. Use `lsblk` to determine the device name of your disk storage, most likely mmcblk1
|
||||
3. Invoke ``sudo cfdisk`` with that device name:
|
||||
+
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -427,7 +427,7 @@ $ sudo pvresize /dev/mmcblk1p3
|
|||
Physical volume "/dev/mmcblk1p3" changed
|
||||
1 physical volume(s) resized or updated / 0 physical volume(s) not resized
|
||||
----
|
||||
7. Select "Storage" in Cockpit and inspect the Volume Group _fedora_ in the upper right corner. The displayed size now shows an amount that indicates a complete fill of the entire disc rsp. as configured.
|
||||
7. Select "Storage" in Cockpit and inspect the Volume Group _fedora_ in the upper right corner. The displayed size now shows that the entire disk has been filled as configured.
|
||||
8. A click onto the fedora volume group brings up the logical volume view. In the "Logical volumes" list expand the root LV (/dev/fedora/root).
|
||||
+
|
||||
image::installation/on-sbc-100.png[Volume resize]
|
||||
|
|
@ -509,7 +509,7 @@ Unfortunately you cannot log in right now because you do not know the password.
|
|||
+
|
||||
You have to rebuild the device operating system on SD card and add a SSH public key to be able to login via SSH as user root.
|
||||
+
|
||||
Beforehand you need to create pair of SSH keys if not already exist. It is best to create the key in the .ssh subdirectory of your home dir. 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. Execute on the local desktop and adjust appropriately:
|
||||
Beforehand you need to create pair of SSH keys if not already exist. It is best to create the key in the .ssh subdirectory of your home dir. It should not be secured by password to enable automatic processing. The naming with leading `id_` and trailing types abbreviation, e.g. `_rsa`, is just a common convention, yet helpful. Execute on the local desktop and adjust appropriately:
|
||||
+
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -518,7 +518,7 @@ $ mkdir ~/.ssh
|
|||
$ ssh-keygen -t rsa -b 4096 -C "root@example.com" -f ~/.ssh/<outputkeyfile>
|
||||
----
|
||||
+
|
||||
As an example you may use the name `id_mysbc_rsa`. Although the type rsa is widely used, you may adjust your key type accordingly.
|
||||
As an example you may use the name `id_mysbc_rsa`. Although RSA is widely used, you may adjust your key type accordingly.
|
||||
+
|
||||
Turn off the SBC, remove the SD card and connect it to your desktop again as in section "Preparations". Transfer the operating system image file again as in step 5 of that section but use an additional option:
|
||||
+
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ The kernel space NFS server features high performance and is therefore selected
|
|||
There are three packages which provide basic support for kernel space NFS:
|
||||
|
||||
nfs-utils::
|
||||
is the main package and provides a daemon for the kernel NFS server and related tools. It also contains the _showmount_ program to query the mount daemon on a remote host for available resources, eg listing the clients which are mounted on that host. It also contains the mount.nfs and umount.nfs programs.
|
||||
is the main package and provides a daemon for the kernel NFS server and related tools. It also contains the `showmount` program to query the mount daemon on a remote host for available resources, e.g. listing the clients which are mounted on that host. It also contains the mount.nfs and umount.nfs programs.
|
||||
|
||||
libnfsidmap::
|
||||
NFSv4 User and Group ID Mapping Library that handles mapping between names and ids for NFSv4.
|
||||
|
|
@ -308,11 +308,11 @@ This option enables subtree checking. (Default)
|
|||
This option disables subtree checking, which has mild security implications, but can improve reliability in some circumstances.
|
||||
|
||||
root_squash/no_root_squash::
|
||||
Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff.
|
||||
Map requests from UID/GID 0 to the anonymous UID/GID. Note that this does not apply to any other UIDs or GIDs that might be equally sensitive, such as user bin or group staff.
|
||||
Turn off root squashing. This option is mainly useful for disk-less clients.
|
||||
|
||||
all_squash/no_all_squash::
|
||||
Map all uids and gids to the anonymous user. Useful for NFS exported public FTP directories, news spool directories, etc.
|
||||
Map all UIDs and GIDs to the anonymous user. Useful for NFS exported public FTP directories, news spool directories, etc.
|
||||
Turn off all squashing. (Default)
|
||||
|
||||
anonuid=UID::
|
||||
|
|
@ -321,15 +321,15 @@ These options explicitly set the uid and gid of the anonymous account. This opti
|
|||
anongid=GID::
|
||||
Read above (anonuid=UID)
|
||||
|
||||
Setting the crossmnt option on the main pseudo mountpoint has the same effect as setting nohide on the sub-exports: It allows the client to map the sub-exports within the pseudo filesystem. These two options are mutually exclusive.
|
||||
Setting the `crossmnt` option on the main pseudo mountpoint has the same effect as setting `nohide` on the sub-exports: It allows the client to map the sub-exports within the pseudo filesystem. These two options are mutually exclusive.
|
||||
|
||||
=== Administration
|
||||
|
||||
When the nfs service starts, the /usr/sbin/exportfs command launches and reads this file, passes control to rpc.mountd (if NFSv2 or NFSv3) for the actual mounting process, then to rpc.nfsd where the file systems are then available to remote users.
|
||||
When the NFS service starts, the `/usr/sbin/exportfs` command launches and reads this file, passes control to `rpc.mountd` (if NFSv2 or NFSv3) for the actual mounting process, then to `rpc.nfsd` where the file systems are then available to remote users.
|
||||
|
||||
When issued manually, the /usr/sbin/exportfs command allows the root user to selectively export or unexport directories without restarting the NFS service. When given the proper options, the /usr/sbin/exportfs command writes the exported file systems to /var/lib/nfs/xtab. Since rpc.mountd refers to the xtab file when deciding access privileges to a file system, changes to the list of exported file systems take effect immediately.
|
||||
When issued manually, the `/usr/sbin/exportfs` command allows the root user to selectively export or `unexport` directories without restarting the NFS service. When given the proper options, the `/usr/sbin/exportfs` command writes the exported file systems to `/var/lib/nfs/xtab`. Since rpc.mountd refers to the `xtab` file when deciding access privileges to a file system, changes to the list of exported file systems take effect immediately.
|
||||
|
||||
The following is a list of commonly used options available for /usr/sbin/exportfs:
|
||||
The following is a list of commonly used options available for `/usr/sbin/exportfs`:
|
||||
|
||||
|
||||
|
||||
|
|
@ -348,9 +348,9 @@ The following is a list of commonly used options available for /usr/sbin/exportf
|
|||
If no options are passed to the /usr/sbin/exportfs command, it displays a list of currently exported file systems.
|
||||
|
||||
|
||||
==== Using exportfs with NFSv4
|
||||
==== Using `exportfs` with NFSv4
|
||||
|
||||
The exportfs command is used in maintaining the NFS table of exported file systems. When typed in a terminal with no arguments, the exportfs command shows all the exported directories.
|
||||
The `exportfs` command is used in maintaining the NFS table of exported file systems. When typed in a terminal with no arguments, the `exportfs` command shows all the exported directories.
|
||||
|
||||
Since NFSv4 no longer utilizes the rpc.mountd protocol as was used in NFSv2 and NFSv3, the mounting of file systems has changed.
|
||||
|
||||
|
|
@ -370,7 +370,7 @@ exportfs -o rw,nohide,insecure,no_subtree_check gss/krb5p:/exports/opt
|
|||
exportfs -o rw,nohide,insecure,no_subtree_check gss/krb5p:/exports/etc
|
||||
----
|
||||
|
||||
In this example, clients are provided with multiple file systems to mount, by using the --bind option which creates unbreakeable links.
|
||||
In this example, clients are provided with multiple file systems to mount, by using the `--bind` option which creates unbreakable links.
|
||||
|
||||
Because of the pseudo-file systems feature, NFS version 2, 3 and 4 export configurations are not always compatible. For example, given the following directory tree:
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ The easiest way is to create the required volumes with __Cockpit__, the web-base
|
|||
|
||||
== Installation
|
||||
|
||||
1. Install the Apache httpd web server. Today, you will almost always need the modules for managing SSL connections and the module for domain monitoring. Everything now runs via https.
|
||||
1. Install the https://httpd.apache.org/[Apache HTTP Server]. Today, you will almost always need the modules for managing SSL connections and the module for domain monitoring. Everything now runs via HTTPS.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -84,7 +84,7 @@ Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /u
|
|||
+
|
||||
image::services/httpd-basic-setup-030.png[Fedora test page]
|
||||
|
||||
4. If you plan to manage Let's Encrypt certificates using certbot install
|
||||
4. If you plan to manage Let's Encrypt certificates using EFF's https://certbot.eff.org/[`certbot`] tool
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -103,7 +103,7 @@ $ sudo -i
|
|||
# mkdir -p /srv/SITENAME/htdocs
|
||||
----
|
||||
+
|
||||
It you opt for thinly provisioned volumes use Cockpit to create the volume, format the filesystem and permanently mount it at the base location `/srv/SITENAME/`. Cockpit performs all these steps, you just need to create the htdocs subdirectory.
|
||||
It you opt for thinly provisioned volumes use Cockpit to create the volume, format the filesystem and permanently mount it at the base location `/srv/SITENAME/`. Cockpit performs all these steps, you just need to create the `htdocs` subdirectory.
|
||||
+
|
||||
With /srv/ as the base directory you must adjust the SELinux labels.
|
||||
+
|
||||
|
|
@ -371,11 +371,11 @@ Delete the provisional `index.html` file and fill your Web content into the Docu
|
|||
==== The phenomenon
|
||||
|
||||
1. If the website uses a DocumentRoot directory different from /var/www/html, then the Servers http protocol variant will display the correct content and the https variant will use /var/www/html or the distribution provided default page instead.
|
||||
2. If you use Let's encrypt certbot to manage certificates, it installs a valid certificate, but a https request results in an invalid certificate complain.
|
||||
2. If you use `certbot` to manage certificates, it installs a valid certificate, but an HTTPS request results in an invalid certificate error.
|
||||
|
||||
==== The cause
|
||||
|
||||
The httpd service always sets a "default" server. The intended use is to answer requests for which the httpd service can not identify a web server configuration. Typically, this happens when a client addresses the web page by the server's IP address instead of its name or there is still an old DNS entry. The distribution provides a default ssl configuration as part of mod_ssl. This default gets associated with the server's hostname or DNS record and takes precedence over the user-created configuration.
|
||||
The httpd service always sets a "default" server. The intended use is to answer requests for which the httpd service can not identify a web server configuration. Typically, this happens when a client addresses the web page by the server's IP address instead of its name or there is still an old DNS entry. The distribution provides a default SSL configuration as part of mod_ssl. This default gets associated with the server's hostname or DNS record and takes precedence over the user-created configuration.
|
||||
|
||||
==== The solution
|
||||
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ The package provides the pure server functionality. Fedora additionally loads th
|
|||
Install 3 packages
|
||||
----
|
||||
|
||||
The installer should have adjusted all SELinux labels in the pgsql directory already created. Check:
|
||||
The installer should have adjusted all SELinux labels in the `pgsql` directory already created. Check:
|
||||
[source,console]
|
||||
----
|
||||
# ls -alZ /var/lib/pgsql/
|
||||
|
|
@ -76,11 +76,11 @@ The installer should have adjusted all SELinux labels in the pgsql directory alr
|
|||
If the installation program missed something, fix it executing
|
||||
[source,console]
|
||||
----
|
||||
# restorecon -vFr /var/lib/pgsql
|
||||
# restorecon -vFr /var/lib/pgsql
|
||||
# ls -alZ /var/lib/pgsql/
|
||||
----
|
||||
|
||||
It is also a prerequisite that exclusively the user postgres has access to the directory pgsql and its subdirectories. Usually the installer takes care of it. Fix it if necessary.
|
||||
It is also a prerequisite that exclusively the user postgres has access to the directory `pgsql` and its subdirectories. Usually the installer takes care of it. Fix it if necessary.
|
||||
[source,console]
|
||||
----
|
||||
# chown -R postgres:postgres /var/lib/pgsql
|
||||
|
|
@ -147,7 +147,7 @@ If local regulations make it necessary to replace these procedures with a dedica
|
|||
|
||||
==== Client user access
|
||||
|
||||
In the initial configuration PostgreSQL, the postgresql user restricts any authentication to peer as described above, or ident (i.e., an ident server that Fedora does not install). In most cases you need password-based authentication. The details depend on the prospective clients. As a typical use case we will accept connections from the internal network to VMs, by default 192.168.122.0/24.
|
||||
In the initial configuration PostgreSQL, the postgresql user restricts any authentication to peer as described above, or `ident` (i.e., an `ident` server that Fedora does not install). In most cases you need password-based authentication. The details depend on the prospective clients. As a typical use case we will accept connections from the internal network to VMs, by default `192.168.122.0/24`.
|
||||
|
||||
The configuration is done in the file `pg_hba.conf` in the `data` subdirectory. Edit the file to match the pattern below.
|
||||
[source,console]
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ After completing the site design and content and launching the site, you may wan
|
|||
|
||||
* Customize the base address
|
||||
+
|
||||
Specifically you want to modify the base address of your WordPress site, from wordpress to e.g. mycuteblog. Edit the WordPress Apache configuration file:
|
||||
Specifically you want to modify the base address of your WordPress site, from WordPress to e.g. `mycuteblog`. Edit the WordPress Apache configuration file:
|
||||
+
|
||||
[source,bash]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -25,13 +25,13 @@ For more than a decade now, server hardware has been powerful enough to run not
|
|||
//====
|
||||
|
||||
|
||||
Virtualization means that several complete and probably different operating systems – the virtual guest machines (guest VM) – run on one and the same hardware, even if intended for a different hardware architecture (full virtualization). In any case, each guest VM uses its own kernel and operates as far as possible independently and isolated from each other and the host system. The basis is a 'hypervisor' that manages hardware resources and assigns them to the individual operating systems rsp. virtual guest machines.
|
||||
Virtualization means that several complete and probably different operating systems – the virtual guest machines (guest VM) – run on one and the same hardware, even if intended for a different hardware architecture (full virtualization). In any case, each guest VM uses its own kernel and operates as far as possible independently and isolated from each other and the host system. The basis is a hypervisor that manages hardware resources and allocates them to the virtual guest machines.
|
||||
|
||||
Containers are an alternative often discussed. Here, several containers use the kernel of the host system simultaneously. The mutual isolation is lower, but the performance overhead is also lower.
|
||||
|
||||
== Virtualization options in Fedora
|
||||
|
||||
=== XEN
|
||||
=== Xen
|
||||
|
||||
Xen was the first virtualization technique suitable for inclusion in a open source distribution as Fedora. This solution first boots a hypervisor that manages resource access and then subsequently loads the distribution kernel, which in the case of Xen takes on a special management function (Dom0). This technology is called 'Type-1' hypervisor and is the basis of many commercial virtualization solutions, especially in the mainframe world.
|
||||
|
||||
|
|
@ -121,4 +121,4 @@ In addition, most distributions also provide a "cloud base image", a base system
|
|||
|
||||
It is very different to what extent these cloud base images resemble an autonomous server of the respective distribution. In the case of Fedora, there is intentionally a fairly low resemblance to Fedora Server Edition. This path might be considered to be of limited usefulness.
|
||||
|
||||
Installation is accomplished on the command line with a single and simple invocation of the virt-install program. The article xref::virtualization/vm-install-cloudimg-centos9.adoc[Creating a virtual machine using a distribution's Cloud base image - the example of CentOS] describes the work to do in detrail for CentOS 9 stream.
|
||||
Installation is accomplished on the command line with a single and simple invocation of the virt-install program. The article xref::virtualization/vm-install-cloudimg-centos9.adoc[Creating a virtual machine using a distribution's Cloud base image - the example of CentOS] describes the work to do in detail for CentOS 9 stream.
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ After completion, the file system is immediately available and is also permanent
|
|||
|
||||
==== Command line
|
||||
|
||||
Some administrators may prefer the command line for easy scripting. Create a Logical Volume of appropriate size, 50 GiB in this esample, either in the system Volume Group (named fedora by default) or in the user data VG if created during installation. Adjust size and VG name as required.
|
||||
Some administrators may prefer the command line for easy scripting. Create a Logical Volume of appropriate size, 50 GiB in this example, either in the system Volume Group (named fedora by default) or in the user data VG if created during installation. Adjust size and VG name as required.
|
||||
[source,console]
|
||||
----
|
||||
# lvcreate -L 50G -n libvirt fedora
|
||||
|
|
@ -91,7 +91,7 @@ Usually, installation sets the SELinux labels properly. Otherwise, set them manu
|
|||
----
|
||||
If everything is correct, the next step is to activate autostart after re-boot and start KVM and libvirtd.
|
||||
|
||||
With Fedora 35 libvirt switched to a _modular archtecture_ (since version 7.6.0-3) while used a single monolithic libvirt daemon up to Fedora 34 (version 7.0.0-x). The installation procedure is the same because the packaging system takes care of the differences. But activation and start up differs as well as installation and configuration of an internal protected virtual network between VMs and the host.
|
||||
With Fedora 35 libvirt switched to a _modular architecture_ (since version 7.6.0-3) while used a single monolithic libvirt daemon up to Fedora 34 (version 7.0.0-x). The installation procedure is the same because the packaging system takes care of the differences. But activation and start up differs as well as installation and configuration of an internal protected virtual network between VMs and the host.
|
||||
|
||||
=== Activation and startup with Fedora 34
|
||||
|
||||
|
|
@ -110,9 +110,9 @@ By default, libvirt creates a (virtual) bridge with an interface virbr0, the IP
|
|||
|
||||
=== Activation and startup with Fedora 35 and up
|
||||
|
||||
The libvirt Fedora installation procedure provides systemd startup scripts that take care of enabling and starting the various unix sockets and services as needed. This includes support for qemu, xen, and lxc. Configuration of vbox is disabled by default. The drivers determine during startup whether the required prerequisites are met and abort otherwise. The default services, qemu and lxc in case of Fedora Server, are started at boot time. If not used for about one minute they are deactivated, but will restart on demand as soon as a virtual machine is started (either by command line or Cockpit service). There is no need for administrator intervention at all.
|
||||
The libvirt Fedora installation procedure provides systemd startup scripts that take care of enabling and starting the various Unix sockets and services as needed. This includes support for QEMU, Xen, and LXC. Configuration of `vbox` is disabled by default. The drivers determine during startup whether the required prerequisites are met and abort otherwise. The default services, qemu and lxc in case of Fedora Server, are started at boot time. If not used for about one minute they are deactivated, but will restart on demand as soon as a virtual machine is started (either by command line or Cockpit service). There is no need for administrator intervention at all.
|
||||
|
||||
The network configuration is slightly different. The services do not start at boot time, like qemu, lxc, etc., but on demand at first access. Therefore, you will not get an interface virbr0 until some libvirt service requests it. That is sometimes inconvenient, e.g. if you use that interface for non-libvirt services, too (e.g. lxd or nspawn container). You may prefer to enable the virt-network service anyway:
|
||||
The network configuration is slightly different. The services do not start at boot time, like qemu, lxc, etc., but on demand at first access. Therefore, you will not get an interface virbr0 until some libvirt service requests it. That is sometimes inconvenient, e.g. if you use that interface for non-libvirt services, too (e.g. LXD or `nspawn` container). You may prefer to enable the `virtnetworkd` service anyway:
|
||||
|
||||
1. *Optionally, activate libvirt's internal network*
|
||||
+
|
||||
|
|
@ -138,7 +138,7 @@ Alternatively, you may want to completely discard libvirt's internal network. Yo
|
|||
do systemctl start virt${drv}d{,-ro,-admin}.socket ; done
|
||||
----
|
||||
+
|
||||
The virtualization functionality can be used immediately. An interface virbr0 as well as a dnsmasq server is now available, regardless of when and if a libvirt service is started. The virtnetwork service will terminate if no libvirt service starts up within the first 1-2 minutes (and later restart automatically if needed). But the interface and the dnsmasq server remain regardless.
|
||||
The virtualization functionality can be used immediately. An interface virbr0 as well as a dnsmasq server is now available, regardless of when and if a libvirt service is started. The `virtnetworkd` service will terminate if no libvirt service starts up within the first 1-2 minutes (and later restart automatically if needed). But the interface and the dnsmasq server remain regardless.
|
||||
+
|
||||
The virtualization services virtqemud.service, etc will be dormant it no VM has been started as well. But the socket is active and will start the corresponding service on demand.
|
||||
+
|
||||
|
|
@ -184,7 +184,7 @@ lines 1-23 ...
|
|||
|
||||
The default configuration of the internal network (virbr0) activates just a DHCP Server. If the virtual machines should also be able to communicate with each other and the host, then adding a DNS server is at least very advantageous. It is easier and less error-prone to address VMs and the host by name instead of IP numbers.
|
||||
|
||||
The first step is to choose a domain name. A top-level ".local" is explicitly not recommended, nor taking one of the official top-level names. But for example, you can take the official domain name and replace the last, top-level part with 'lan' or 'internal' or `localnet`. An official domain example.com would translate to an internal domain example.lan. We use that one throughout this tutorial. The host gets the internal name host.example.lan.
|
||||
The first step is to choose a domain name. A top-level `.local` is explicitly not recommended, nor taking one of the official top-level names. But for example, you can take the official domain name and replace the last, top-level part with `lan` or `internal` or `localnet`. An official domain `example.com` would translate to an internal domain `example.lan`. We use that one throughout this tutorial. The host gets the internal name host.example.lan.
|
||||
|
||||
Use the libvirt tool to adjust the default network. Replace names and placeholders as required. Delete the line with "forward mode = 'nat'" if you do not want to allow access to the public network via the virtual network.
|
||||
[source,xml]
|
||||
|
|
@ -406,7 +406,7 @@ When first used, the list of virtual machines displayed in the center of the pag
|
|||
|
||||
Typically you use one Pool for installation media, stored at /var/lib/libvirt/boot. "Installation media" would be a suitable descriptive pool name. Select 0 Storage pools in the box and then Create storage pool. A new form opens.
|
||||
|
||||
If you are logged in as an administrative user (even if having used sudo su - ), you are asked to select a connection type, "system" or "session". This selection is presented in various configuration forms, so we explain here. Use "system" for production deployments, the common case. Select "session" in the special case of testing, development, and experimentation. The "session" option does not support any custom or advanced networking, but works pretty much everwhere (including containers) and without any privileges. The libvirt project provides additional information for developers. If you are logged in directly as root, this line does not show up. Instead, everything is treated as system; i.e. production deployment (never do development or experimentation as root).
|
||||
If you are logged in as an administrative user (even if having used sudo su - ), you are asked to select a connection type, "system" or "session". This selection is presented in various configuration forms, so we explain here. Use "system" for production deployments, the common case. Select "session" in the special case of testing, development, and experimentation. The "session" option does not support any custom or advanced networking, but works pretty much everywhere (including containers) and without any privileges. The libvirt project provides additional information for developers. If you are logged in directly as root, this line does not show up. Instead, everything is treated as system; i.e. production deployment (never do development or experimentation as root).
|
||||
|
||||
Next enter "Installation media" as the name, "Filesystem directory" as the type, and /var/lib/libvirt/boot as the target path.
|
||||
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ options kvm_intel nested=1
|
|||
+
|
||||
Log in to the virtual server that is to host additional virtual machines.
|
||||
|
||||
2. Add virtualization support to this virtual Maschine. Follow the steps as described in xref:virtualization/installation.adoc[Adding Virtualization Support].
|
||||
2. Add virtualization support to this virtual machine. Follow the steps as described in xref:virtualization/installation.adoc[Adding Virtualization Support].
|
||||
|
||||
3. Check the installation
|
||||
+
|
||||
|
|
@ -88,7 +88,7 @@ $ sudo virt-host-validate qemu
|
|||
...
|
||||
----
|
||||
+
|
||||
There may be 2 warnings about IOMMU and secure guest support, which you can savely ignore.
|
||||
There may be 2 warnings about IOMMU and secure guest support, which you can safely ignore.
|
||||
|
||||
4. Finally, create a Fedora Server Edition VM following the steps as described in xref:virtualization/vm-install-diskimg-fedoraserver.adoc[Creating a virtual machine using Fedora Server Edition disk image] and configure it as needed.
|
||||
|
||||
|
|
|
|||
|
|
@ -283,7 +283,7 @@ Cockpit should start up as soon as you connect with your browser.
|
|||
|
||||
== Using virt-install for a CLI interactive minimal effort installation
|
||||
|
||||
This type of installation uses the `--cloud-init` parameter of `virt-install` without any value or subparameters. The approach causes the generation and display of a root password shortly after the start of installation, enabling a one-time login. You have to note or copy it, of course.
|
||||
This type of installation uses the `--cloud-init` parameter of `virt-install` without any value or parameters. The approach causes the generation and display of a root password shortly after the start of installation, enabling a one-time login. You have to note or copy it, of course.
|
||||
|
||||
Apart from that, the configuration is limited to configuring and starting DHCP-supported Ethernet interfaces. Other interfaces are basically defined but not dealt with further.
|
||||
|
||||
|
|
|
|||
|
|
@ -179,7 +179,7 @@ image::virtualization/diskimg-fedoraserver-03.png[]
|
|||
.Network and devices screen
|
||||
image::virtualization/diskimg-fedoraserver-04.png[]
|
||||
+
|
||||
In the network section, you see one Interface with Source default, i.e. virbr0. In order to easily manage the default route, this interface - the first one created - should connect to the public external network. Therefore, we start with changing this interface into the public one. Important: To keep the intended order of interfaces, do nothing else at tis point as to edit this interface!
|
||||
In the network section, you see one Interface with Source default, i.e. virbr0. In order to easily manage the default route, this interface - the first one created - should connect to the public external network. Therefore, we start with changing this interface into the public one. Important: To keep the intended order of interfaces, do nothing else at this point as to edit this interface!
|
||||
|
||||
5. Select the _Edit_ button to adjust the network connection setup.
|
||||
+
|
||||
|
|
@ -258,7 +258,7 @@ Please make a selection from the above ['c' to continue, 'h' to help, 'q' to
|
|||
quit, 'r' to refresh]:
|
||||
----
|
||||
+
|
||||
The "[x]" in front of Create user indicates that the user creation process is activ. Accordingly, password authentication is enabled for the new user as well as administrator privileges. Fill in the required information and in any case ensure to activate the adminstrator privileges! It automatically adds "wheel" to Groups.
|
||||
The "[x]" in front of Create user indicates that the user creation process is active. Accordingly, password authentication is enabled for the new user as well as administrator privileges. Fill in the required information and in any case ensure to activate the administrator privileges! It automatically adds "wheel" to Groups.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -316,7 +316,7 @@ The virtual server is up and running now, and ready for login. The initial confi
|
|||
|
||||
2. *Login*
|
||||
+
|
||||
Login with your credentials you have choosen in the first boot screen described above.
|
||||
Login with your credentials you have chosen in the first boot screen described above.
|
||||
|
||||
3. *Optionally: Adjust locale and non-US keyboard layout*
|
||||
+
|
||||
|
|
@ -485,7 +485,7 @@ default via 192.168.122.1 dev enp2s0 proto dhcp src 192.168.122.107 metric 101
|
|||
192.168.158.0/24 dev enp1s0 proto kernel scope link src 192.168.158.160 metric 100
|
||||
----
|
||||
+
|
||||
Delete the NAT route to avoid issues because of ambigous routes by some application software.
|
||||
Delete the NAT route to avoid issues because of ambiguous routes by some application software.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -557,7 +557,7 @@ Select partition vda4, select type, scroll down and assign type "Linux LVM".
|
|||
----
|
||||
11. *Close the virsh console mode*
|
||||
+
|
||||
You were automatically in virsh's console mode until now. Exit this mode and you will be back on the host system.
|
||||
You were automatically in `virsh`'s console mode until now. Exit this mode and you will be back on the host system.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -575,7 +575,7 @@ Anyway, you should now test to connect via ssh to the system using the usual way
|
|||
|
||||
Fedora Server VM guest basically follows the same storage organization principles as a bare metal installation. The xref:installation/index.adoc#Planning_ahead[Fedora Server Installation Guide] explains the principles and the available choices. You have to make the same choice here.
|
||||
|
||||
The distributed disk image features a disk size of about 10 gb. This is not intended as a default value to use but as a starting value for adaptation to the specific installation requirement. You have probably already adjusted the desired maximum size during the <<Provisioning the Server VM image>>. Check the output from cfdisk to see whether the last partition has actually been adjusted accordingly. If not, shutdown the virtual machine and adjust the size now.
|
||||
The distributed disk image features a disk size of about 10 GB. This is not intended as a default value to use but as a starting value for adaptation to the specific installation requirement. You have probably already adjusted the desired maximum size during the <<Provisioning the Server VM image>>. Check the output from `cfdisk` to see whether the last partition has actually been adjusted accordingly. If not, shutdown the virtual machine and adjust the size now.
|
||||
|
||||
When qemu-img increases the maximum size of the image file, the last partition is also enlarged accordingly by default. However, the programme can neither adjust the volume group contained within the partition nor the logical volume of the root filesystem.
|
||||
|
||||
|
|
@ -684,7 +684,7 @@ Create a Logical Volume and file system of appropriate size, mount it at `/srv/`
|
|||
# mkdir /srv/<MYWEBAPP>
|
||||
----
|
||||
+
|
||||
This creates a Logical Volume and XFS file system of 20G, mounts t at `/srv` and creates a Subdirectory for the Webapp's data. Add additional subdirectories for each application.
|
||||
This creates a Logical Volume and XFS file system of 20G, mounts t at `/srv` and creates a Subdirectory for the web app's data. Add additional subdirectories for each application.
|
||||
|
||||
b. The elaborate way using thin provisioning
|
||||
+
|
||||
|
|
@ -723,7 +723,7 @@ In this example we create a Logical Volume of 4G at maximum. The system will cr
|
|||
thinpool systemVG twi-aotz-- 20.00g ...
|
||||
----
|
||||
+
|
||||
Repeat this step fot every application you have to provide with storage.
|
||||
Repeat this step for every application you have to provide with storage.
|
||||
|
||||
* Mounting the file system at the intended location
|
||||
+
|
||||
|
|
@ -741,7 +741,7 @@ Repeat this step for every application you have to provide with storage.
|
|||
Instead of using the command line, you can also switch to __Cockpit__ and perform each of these operations in a graphical User Interface.
|
||||
|
||||
|
||||
=== Creating additional storage ressources
|
||||
=== Creating additional storage resources
|
||||
|
||||
Another way so separate system and user data is to create a separate virtual data disk.
|
||||
|
||||
|
|
@ -770,7 +770,7 @@ Format specific information:
|
|||
extended l2: false
|
||||
----
|
||||
|
||||
. Continue on the host and add the disk to the virtual machine. Use the first available diskname. The system disk is vda, so the next available disk name is vdb. If you are unsure check in the virtual machine, e.g. using '__lsblk__'.
|
||||
. Continue on the host and add the disk to the virtual machine. Use the first available disk name. The system disk is vda, so the next available disk name is `vdb`. If you are unsure check in the virtual machine, e.g. using `lsblk`.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -788,9 +788,9 @@ If you want to modify something, detach the file first.
|
|||
Disk detached successfully
|
||||
----
|
||||
|
||||
. On the virtual machine, use cfdisk to partition the disk according to your requirements. The example creates one partition spanning the entire disk capacity.
|
||||
. On the virtual machine, use `cfdisk` to partition the disk according to your requirements. The example creates one partition spanning the entire disk capacity.
|
||||
+
|
||||
First, cfdisk displays a list for selecting the partitioning type. Select GPT.
|
||||
First, `cfdisk` displays a list for selecting the partitioning type. Select GPT.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -42,9 +42,9 @@ Note: This document assumes that you have ssh access to a Proxmox node and that
|
|||
|
||||
=== Locate the image file and upload it to Proxmox
|
||||
|
||||
Before we create the VM, we will need to find and upload our disk image to the Proxmox node. In the screenshot below you can see that we explored the system to determine that it is using centralized NFS storage mounted at /mnt/pve/nfs-kraken, and we made a directory at some point called osimages to contain our disk images.
|
||||
Before we create the VM, we will need to find and upload our disk image to the Proxmox node. In the screenshot below you can see that we explored the system to determine that it is using centralized NFS storage mounted at /mnt/pve/nfs-kraken, and we made a directory at some point called `osimages` to contain our disk images.
|
||||
|
||||
Once you create a directory to house your disk images, you will need to upload the disk image file via scp into the Proxmox node. `scp [image_filename] root@[node_name]:/path/to/images/[image_filename]`
|
||||
Once you create a directory to house your disk images, you will need to upload the disk image file via `scp` into the Proxmox node. `scp [image_filename] root@[node_name]:/path/to/images/[image_filename]`
|
||||
|
||||
[source,console]
|
||||
----
|
||||
|
|
@ -183,7 +183,7 @@ Now that the VM itself has been built, we need to log in to the Proxmox node via
|
|||
|
||||
** This test article has storage mounted at /mnt/pve/nfs-kraken/osimages/, but your path will be different.
|
||||
|
||||
* Use the qm disk import command to import your disk image.
|
||||
* Use the `qm disk import` command to import your disk image.
|
||||
|
||||
** `qm disk import [vm_number] [image_name.qcow2] [target_storage] --format qcow2`
|
||||
|
||||
|
|
|
|||
|
|
@ -262,7 +262,7 @@ Select _Import_ to create the basic virtual VM definition. It takes a short time
|
|||
|
||||
Clicking the virtual machine name in the list opens a detailed configuration page.
|
||||
|
||||
image::virtualization/vm-install-diskimg-virtbuilder-020.png[Cockpit `__Virtual machin overview form__`]
|
||||
image::virtualization/vm-install-diskimg-virtbuilder-020.png[Cockpit `__Virtual machine overview form__`]
|
||||
|
||||
|
||||
=== Autostart
|
||||
|
|
@ -271,7 +271,7 @@ Adjust the autostart option in the upper part according to your need.
|
|||
|
||||
=== Network connections
|
||||
|
||||
The list of network interfaces shows only one interface, the internal network managed by libvirt. However, you want to have external access, too. The key part of most VMs is to isolate public accesse from the host server for security reasons.
|
||||
The list of network interfaces shows only one interface, the internal network managed by libvirt. However, you want to have external access, too. The key part of most VMs is to the isolation of public access from the host server for security reasons.
|
||||
|
||||
To enable public access, you can either bind a virtual bridge to the interface or use Mac-vlan. The latter adds virtual interfaces to the physical interface, each with its own Mac address and its own IP (and alias IPs if needed). The libvirt toolkit refers to this as `__direct attachment__`. It is now the recommended approach. It acts similar to a bridge, but with less system load. The disadvantage is that direct communication between the host and the VMS is not possible, but between the VMs it is. Hosts and VMs can only communicate via the internal, protected network. For administrators of remote, not directly accessible servers, the additional big advantage is that after the initial configuration, there is no need to touch the precious network connection again.
|
||||
|
||||
|
|
@ -300,7 +300,7 @@ If you look around, you will find
|
|||
The resemblance of a CentOS server is not perfect, but fairly well done.
|
||||
|
||||
== Conclusion
|
||||
Overall, the virt-builder/guestfs-tools-project provides an amazing opportunity to quickly and straightforwardly create a well-crafted virtual machine, instantiating various different distributions. Fortunately, it is an open source project, but unfortunately the "openness" did not receive detailed attention. It is very hard to figure out how to access the source code. So, it is difficult to learn how the virtual machine is built in detail and to check for potential malicious ingredients. The provided information is quite scanty and sometimes misleading. For example, the information on Fedora reads: "Fedora® 35 Server". However, the virtual machine created does not have much to do with "Fedora Server Edition". More appropriate would be something like "Some server based on Fedora RPM's". Sponsored by Red Hat, a lot of Red Hat engineers are engaged in the project. So you may (and should) pay some leap of faith, anyway.
|
||||
Overall, the virt-builder/guestfs-tools-project provides an amazing opportunity to quickly and straightforwardly create a well-crafted virtual machine, instantiating various different distributions. Fortunately, it is an open source project, but unfortunately the "openness" did not receive detailed attention. It is very hard to figure out how to access the source code. So, it is difficult to learn how the virtual machine is built in detail and to check for potential malicious ingredients. The provided information is quite scanty and sometimes misleading. For example, the information on Fedora reads: "Fedora® 35 Server". However, the virtual machine created does not have much to do with "Fedora Server Edition". More appropriate would be something like "Some server based on Fedora RPMs". Sponsored by Red Hat, a lot of Red Hat engineers are engaged in the project. So you may (and should) pay some leap of faith, anyway.
|
||||
|
||||
A system administrator cannot expect to get a differently built, but otherwise identical build of a distribution. This will need a closer assessment and more or less detailed rework.
|
||||
|
||||
|
|
@ -319,7 +319,7 @@ An alternative is an xref:virtualization/vm-install-cloudimg-centos9.adoc[instan
|
|||
--graphics none:: Fixed, enforces a redirect of the VM login prompt to the host terminal window for immediate access.
|
||||
Enables to login either via Cockpit terminal window or via host terminal using `virsh console <VM_NAME>` (you may have to issue one or two additional <enter>)
|
||||
--disk /var/lib/libvirt/images/VM_NAME.qcow2, format=qcow2,bus=virtio:: disk image file, adjust VM_NAME
|
||||
--network direct,source=enpXsY,source_mode=bridge, model=virtio:: specify _external_ netwok (macvlan) __first__, it will get the name eth0 as usual. Adjust interface name as appropriate.
|
||||
--network direct,source=enpXsY,source_mode=bridge, model=virtio:: specify _external_ network (macvlan) __first__, it will get the name eth0 as usual. Adjust interface name as appropriate.
|
||||
--network bridge=virbr0,model=virtio:: specify the _internal_ network (libvirt generated bridge) _second_. It will get the name eth1 as usual.
|
||||
|
||||
=== Virt-install in Fedora or CentOS
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ If you want to save the disk image for future VM creation, select shutdown, copy
|
|||
____
|
||||
*__Excursus__: Save generated virtual machine for later reuse*
|
||||
|
||||
Sometimes, after selecting __Shutdown__ the machine automatically start again. Login with your administrativ account and perform a shutdown: `sudo shutdown -h now`. Then switch to a host's terminal window and execute:
|
||||
Sometimes, after selecting __Shutdown__ the machine automatically start again. Login with your administrative account and perform a shutdown: `sudo shutdown -h now`. Then switch to a host's terminal window and execute:
|
||||
[source,console]
|
||||
----
|
||||
# qemu-img convert -O qcow2 /var/lib/libvirt/images/{VM_NAME}.qcow2 /var/lib/libvirt/boot/fedora-servervm-img.qcow2
|
||||
|
|
@ -291,7 +291,7 @@ Refer to the corresponding section in the xref:installation/postinstallation-t
|
|||
|
||||
1. *Making vim the default editor*
|
||||
+
|
||||
If you are a somewhat experienced administrator, you are probably annoyed that Namo, default editor since Fedora 34, always pops up when you want to edit crontab or similar. It is therefore worth reconfiguring right from the start.
|
||||
If you are a somewhat experienced administrator, you are probably annoyed that nano, the default editor since Fedora 34, always pops up when you want to edit crontab or similar. It is therefore worth reconfiguring right from the start.
|
||||
+
|
||||
[source,console]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ The _Storage_ page of the virtual machine (vm2) displays the _Devices_ section i
|
|||
|
||||
image::virtualization/vm-management-cockpit-008.png[Cockpit create logical volume form]
|
||||
|
||||
Replace the preset name by a descriptive term, here e.g. webservice, and choose a suitable size. Due to the dynamic space allocation of the qcow2 format you may choose the size definitely a bit generous. However, a later extension with Cockpit is very easy to perform.
|
||||
Replace the preset name by a descriptive term, here e.g. web service, and choose a suitable size. Due to the dynamic space allocation of the qcow2 format you may choose the size definitely a bit generous. However, a later extension with Cockpit is very easy to perform.
|
||||
|
||||
With _Purpose_ the form also offers the option to create a pool for "thinly provisioned volumes", which in turn accommodates logical volumes allocating space dynamically. In case of a VM this is usually not as helpful as on physical machines, because the qcow2 disk image files already provide for a kind of thin provisioning. But your mileage may vary.
|
||||
|
||||
|
|
@ -145,7 +145,7 @@ Cockpit supports the creation of additional virtual disks (but unfortunately not
|
|||
|
||||
image::virtualization/vm-management-cockpit-010.png[Cockpit add a virtual disk form]
|
||||
|
||||
In the example above we create a 30gb disk for Web service. _Add_ creates a disk image in /var/lib/libvirt/images and adds it to the Cockpit VM details page. You may check in the terminal window using __lsblk__. It shows a disk vdb without any partition so far.
|
||||
In the example above we create a 30gb disk for Web service. _Add_ creates a disk image in /var/lib/libvirt/images and adds it to the Cockpit VM details page. You may check in the terminal window using `lsblk`. It shows a disk vdb without any partition so far.
|
||||
|
||||
The Host Cockpit simply creates a new (virtual) hard disk and "plugs" it into the virtual machine. Configuration and setup of the hard disk occurs within the VM. Their Cockpit can perform that very easily. Open a new tab in your browser, open Cockpit of the VM and select _Storage_ over there.
|
||||
|
||||
|
|
@ -227,7 +227,7 @@ image::virtualization/vm-management-cockpit-034.png[Cockpit delete a libvirt vir
|
|||
|
||||
Probably you do not want a public interface but that machine well protected from the public network. So you delete the public interface. A simple click on _Delete_ will remove that interface from the virtual machine (after confirmation). If you check the network configuration inside the machine an _nmcli device show_ lists only one device as attached to the still existing connection. And _ip a_ lists just lo and enp7s0.
|
||||
|
||||
An _nmcli conn show_ still lists the connection enp1s0, but without an attached device. The reason is that it was the first interface explicitly set up during installation. Therefore it was persisted in /etc/NetworkManager/system-connected and the file is still there (allthough without any device configuration options). Cockpit does not delete a configuration file.
|
||||
An _nmcli conn show_ still lists the connection enp1s0, but without an attached device. The reason is that it was the first interface explicitly set up during installation. Therefore it was persisted in /etc/NetworkManager/system-connected and the file is still there (although without any device configuration options). Cockpit does not delete a configuration file.
|
||||
|
||||
== Simplified Access to VMs Cockpit
|
||||
|
||||
|
|
|
|||
|
|
@ -33,12 +33,12 @@ convention, [ ...::2] is used for this address.
|
|||
+
|
||||
[source,]
|
||||
----
|
||||
[…]# nmnmcli con mod 'enp3s0' ipv6.method manual \
|
||||
[…]# nmcli con mod 'enp3s0' ipv6.method manual \
|
||||
ipv6.addresses <YOUR_IPv6>::2/64 \
|
||||
ipv6.gateway fe80::1 \
|
||||
ipv6.dns "2a01:4f8:0:1::add:1010 2a01:4f8:0:1::add:9999" +
|
||||
[…]# nmnmcli con up <NAME>
|
||||
[…]# nmnmcli con reload
|
||||
[…]# nmcli con up <NAME>
|
||||
[…]# nmcli con reload
|
||||
----
|
||||
+
|
||||
Check on the local desktop if a ping6 works:
|
||||
|
|
@ -52,12 +52,12 @@ Check on the local desktop if a ping6 works:
|
|||
+
|
||||
[source,]
|
||||
----
|
||||
[…]# nmnmcli con mod 'enp3s0' ipv4.method manual \
|
||||
[…]# nmcli con mod 'enp3s0' ipv4.method manual \
|
||||
ipv4.addresses <YOUR_IPv4> / 27 \
|
||||
ipv4.gateway \ +
|
||||
ipv6.dns "213.133.98.98 213.133.99.99 213.133.100.100"
|
||||
[…]# nmnmcli con up <_NAME>
|
||||
[…]# nmnmcli con reload
|
||||
[…]# nmcli con up <_NAME>
|
||||
[…]# nmcli con reload
|
||||
----
|
||||
+
|
||||
Check from the local desktop if a ping6 works:
|
||||
|
|
@ -146,7 +146,7 @@ bantime = 6600
|
|||
backend = auto
|
||||
|
||||
# The main configuration file defines all services but
|
||||
# deactivates them by default. We have to activate those neeeded
|
||||
# deactivates them by default. We have to activate those needed
|
||||
[sshd]
|
||||
enabled = true
|
||||
----
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue