Compare commits

..

No commits in common. "main" and "main" have entirely different histories.

44 changed files with 643 additions and 156 deletions

View file

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

View file

@ -8,5 +8,5 @@ jobs:
image: docker.io/jdkato/vale
steps:
- uses: actions/checkout@v7
- run: vale sync
- run: vale README.md modules/ROOT/pages/ modules/ROOT/partials/
- run: vale .

3
.gitignore vendored
View file

@ -6,6 +6,3 @@ preview.pid
*.bak
*~
*swp
# vale
.vale/styles/RedHat/

View file

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

View file

@ -75,7 +75,7 @@ Someone will see your pull request and either merge it, or provide feedback if t
Antora introduces two new terms:
* **Component** - Simply put, a component is a part of the documentation website with its own menu. Components can also be versioned. In the Fedora Docs, we use separate components for user documentation, the Fedora Project, Fedora council, Mindshare, FESCO, but also for subprojects such as CommOps or Modularity.
* **Module** - A component can be broken down into multiple modules. Modules still share a single menu on the site, but their sources can be stored in different git repositories, even owned by different groups. The default module is called "ROOT" (that is what is in this example). If you do not want to use multiple modules, only use "ROOT". But to define more modules, simply duplicate the "ROOT" directory and name it anything you want. You can store modules in one or more git repositories.
* **Module** - A component can be broken down into multiple modules. Modules still share a single menu on the site, but their sources can be stored in different git repositories, even owned by different groups. The default module is called "ROOT" (that's what is in this example). If you don't want to use multiple modules, only use "ROOT". But to define more modules, simply duplicate the "ROOT" directory and name it anything you want. You can store modules in one or more git repositories.
## Local preview
@ -136,9 +136,9 @@ And replaced it with a pointer to my fork:
...
```
I could also point to a local repository, using `HEAD` as a branch to preview what is changed without the need of making a commit.
I could also point to a local repository, using `HEAD` as a branch to preview what's changed without the need of making a commit.
**Note:** I would need to move the repository under the `docs-fp-o` directory, because the builder will not see anything above.
**Note:** I would need to move the repository under the `docs-fp-o` directory, because the builder won't see anything above.
So I would need to create a `repositories` directory in `docs-fp-o` and copy my repository into it.
```

View file

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

View file

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

Binary file not shown.

After

Width:  |  Height:  |  Size: 80 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 115 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 89 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 123 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 119 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 126 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 133 KiB

View file

Before

Width:  |  Height:  |  Size: 612 KiB

After

Width:  |  Height:  |  Size: 612 KiB

Before After
Before After

View file

@ -35,9 +35,12 @@
** xref:services/filesharing-nfs-installation.adoc[File sharing with NFS Installation]
** xref:services/mdns.adoc[Local domains with mDNS]
* Use Cases
** xref:usecases/wordpress-installation.adoc[Installing Wordpress CMS]
** xref:usecases/gui-addon.adoc[Adding a graphical user interface]
* Example Use Cases
** xref:usecase-gui-addon.adoc[Adding a graphical user interface]
* Tutorials
** xref:tutorials/imagefactory.adoc[ImageFactory - How to create a virtual machine disk image]
** xref:tutorials/wordpress-installation.adoc[Installing Wordpress CMS]
* xref:server-on-sbc/index.adoc[Special: Fedora Server on ARM Single Board Computers - the Raspberry Pi & Co]
** xref:server-on-sbc/uboot-installation.adoc[Installation based on u-boot]

View file

@ -17,7 +17,7 @@ This topic covers connecting to OpenSSH servers using `ssh`, `scp`, and `sftp`,
[NOTE]
====
To connect to an OpenSSH server from a client machine, you must have the [package]*openssh-clients* package installed. If it is not already installed, run:
To connect to an OpenSSH server from a client machine, you must have the [package]*openssh-clients* package installed. If it isn't already installed, run:
[source,bash]
---

View file

@ -104,7 +104,7 @@ NetworkManager takes care of the dnsmasq plugin operation. Configuration files i
[TIP]
====
NetworkManager reads all files in that directory, independently of the file extension. So you cannot temporarily deactivate a configuration by renaming it.
NetworkManager reads all files in that directory, independently of the file extension. So you can't temporarily deactivate a configuration by renaming it.
====
The example here uses 2 interfaces, an external public interface enp1s0 (public.tld) and an internal private interface enp2s0 (internal.lan). You may add any number of additional interfaces by adding corresponding config files as in the examples here.
@ -208,7 +208,7 @@ The example shows the binding of the network interface and then sets the differe
+
The subnet mask (dhcp-option=1) is set to <255.255.255.0>, the default router or gateway (dhcp-option=3) is set to <www.xxx.yy.zz>, and the DNS server (dhcp-option=6) is set to <www.xx.yy.z>. Substitute values appropriate to your network.
+
In this example, no permanent or fixed IP addresses are assigned, but examples are provided as commented lines, so that you can see how to add an entry to assign a particular IP address to a host based on its MAC address.
In this example, no permanent or fixed IP addresses are assigned, but examples are provided as commented lines, so that you can see how to add an entry to assign a particular IP address to a host based on it's MAC address.
+
The example enables a DHCP range within the network and assigns hosts IP addresses from <vvv.ww.xx.y> to <vvv.ww.xx.z> with leases lasting for 24 hours. Substitute values as appropriate for your network.
@ -430,14 +430,14 @@ Dnsmasq can be configured to act as a PXE service, by enabling the TFTP server a
Systems that use legacy BIOS to perform a network boot behave differently to systems that use UEFI firmware to do the same. Since most modern systems use UEFI and systems booting using legacy BIOS can complicate setup, the configuration described in this example focuses only on UEFI support.
. **Install packages required to support PXE boot clients**:
1. **Install packages required to support PXE boot clients**:
+
[source,console]
----
$ sudo dnf install grub2-tools grub2-efi-x64-modules
----
. **Create the TFTP server directories and provide the network boot loader files**:
2. **Create the TFTP server directories and provide the network boot loader files**:
+
[source,console]
----
@ -456,11 +456,11 @@ Netboot directory for x86_64-efi created. Configure your DHCP server to point to
+
[NOTE]
====
UEFI systems that have Secure Boot enabled might reject a PXE boot if the EFI binaries are not signed. The most simple solution to this issue is to disable Secure Boot in the UEFI firmware when you need to perform network-based installation.
UEFI systems that have Secure Boot enabled might reject a PXE boot if the EFI binaries aren't signed. The most simple solution to this issue is to disable Secure Boot in the UEFI firmware when you need to perform network-based installation.
====
. **Download or copy the installation kernel and ram-disk image files to the TFTP server directory hierarchy**:
3. **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]:
+
@ -472,7 +472,7 @@ $ curl -L -o /tmp/vmlinuz https://dl.fedoraproject.org/pub/fedora/linux/releases
$ sudo mv /tmp/{vmlinuz, initrd.img} /var/lib/tftpboot/fedora44
----
. **Create the PXE Boot configuration files**:
4. **Create the PXE Boot configuration files**:
+
PXE Boot configuration files define the boot menu that loads once the system is connected to the TFTP server.
+
@ -504,7 +504,7 @@ menuentry 'Exit to next boot device' {
}
----
. **Add a dnsmasq configuration entry to enable the TFTP service**:
4. **Add a dnsmasq configuration entry to enable the TFTP service**:
Create and edit the file at `/etc/NetworkManager/dnsmasq.d/10-TFTP.conf` using your preferred editor running under `sudo` to acquire root privileges:
+
[source,]
@ -533,7 +533,7 @@ In the configuration, DHCP matching is used to tag the request for the appropria
You can optionally edit the dhcp-boot directive to specify a server hostname or server IP where the TFTP service is located if not on the current dnsmasq host.
Note that if you only want the TFTP service to be available on a particular network interface you can change the `enable-tftp` option to `enable-tftp=<IFNAME>`.
. **Enable access to the TFTP service (UDP port 69) in your firewall**:
6. **Enable access to the TFTP service (UDP port 69) in your firewall**:
+
If you're running firewalld, you can do this by running the following commands:
+
@ -543,21 +543,21 @@ $ sudo firewall-cmd --zone=FedoraServer --permanent --add-service=tftp
$ sudo firewall-cmd --reload
----
. **Test the dnsmasq configuration to make sure that it is still valid**:
7. **Test the dnsmasq configuration to make sure that it is still valid**:
+
[source,console]
----
$ dnsmasq --test
dnsmasq: syntax check OK.
----
. **Restart NetworkManager to restart the dnsmasq plugin and enable the TFTP configuration**:
8. **Restart NetworkManager to restart the dnsmasq plugin and enable the TFTP configuration**:
+
[source,console]
----
$ sudo systemctl restart NetworkManager
----
. **If the system is running SELinux, set the file context on the tftpboot directory**:
9. **If the system is running SELinux, set the file context on the tftpboot directory**:
+
[source,console]
----
@ -567,10 +567,10 @@ $ sudo restorecon -R -v /var/lib/tftpboot
+
[TIP]
====
If semanage is not available, install the `policycoreutils` package.
If semanage isn't available, install the `policycoreutils` package.
====
. **Network boot a client system to check that it is assigned an IP address and that the network based installation starts**:
10. **Network boot a client system to check that it is assigned an IP address and that the network based installation starts**:
+
While the client system is booting, you can monitor the NetworkManager logs to check that DHCP requests are received and that the service responds correctly:
+

View file

@ -96,7 +96,7 @@ Use the original IP address from the IP address listing, but change the /64 to /
$ sudo nmcli con mod enp2s0 ipv6.addresses '2a01:4f8:210:512d::2/128'
$ sudo nmcli con up enp2s0
----
+
[TIP]
====
In the example, the connection name matches the device name. You might need to check the network connection name that the device is attached to, when you run the `nmcli con` commands. For example, run: `nmcli con|grep nmcli enp2s0` to get the names of the network connections that the enp2s0 device is connected to.

View file

@ -5,7 +5,7 @@ Peter Boy
:revdate: 2026-05-17
:page-aliases: container-an-introduction.adoc
For several years, "Container" has been on everyone's lips. It is a prominent subject of public discussion. Complete operating systems are rebuilt to serve primarily as runtime environments for containers. And in public discussion "container" are mostly equated with "Docker". It is hard to find software that is not at least also offered as a Docker image. It did not take long for the disadvantages of such a monopolization to become apparent, e.g. in the form of serious security risks.
For several years, "Container" has been on everyone's lips. It's a prominent subject of public discussion. Complete operating systems are rebuilt to serve primarily as runtime environments for containers. And in public discussion "container" are mostly equated with "Docker". It is hard to find software that is not at least also offered as a Docker image. It didn't take long for the disadvantages of such a monopolization to become apparent, e.g. in the form of serious security risks.
As we learn time and time again, one size does not fit all. A number of the advantages of containerization are widely agreed upon. But the needs and requirements in IT are so diverse that not all of them can be optimally realized by one implementation. Therefore, there are alternative container implementations with different application profiles. And containerization is not always helpful either.

View file

@ -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 it's interface name to the container ressources in the host:
+
[source,console]
----
@ -191,7 +191,7 @@ In this case, the gateway entry must be commented out in the configuration of th
UseAutonomousPrefix=False
----
+
Do not forget to adjust interface names and IP addresses accordingly!
Don't forget to adjust interface names and IP addresses accordingly!
5. *Boot the container and log in*
+
@ -465,7 +465,7 @@ After finishing all further work inside the container press <ctrl>]]] ( Mac: <ct
5. *Optionally: Autostart of the container at hosts boot up*
+
The well-known 'systemctl enable ...' does not work here due to coordination issues of NetworkManager and systemd and network interception of libvirt. There are 2 ways to autostart a container:
The well-known 'systemctl enable ...' doesn't work here due to coordination issues of NetworkManager and systemd and network interception of libvirt. There are 2 ways to autostart a container:
a. __(Re-)Activate rc.local__
+

View file

@ -62,7 +62,7 @@ Detailed step-by-step instructions are given for various typical areas of applic
We are not aware of any issue when upgrading from Fedora 43.
== What is in the pipeline?
== What's in the pipeline?
Currently, several projects are in development:
@ -72,7 +72,7 @@ Currently, several projects are in development:
== You are welcome to contribute
You do not have to be a programmer, a developer or a technical nerd to contribute to the development of Fedora Server. We are especially interested in feedback from our users and potential new users.
You don't have to be a programmer, a developer or a technical nerd to contribute to the development of Fedora Server. We are especially interested in feedback from our users and potential new users.
- Please, tell us about your usage of Fedora Server
- Tell us about problems you found and how you resolved it
@ -163,7 +163,7 @@ If you use postgresql, please note that the major version has increased from 15.
=== Installing Fedora 39
There is an issue with the aarch64 SBC installation image. You cannot use a Fedora Server Edition host to transfer the distribution image onto a SD card. Use Fedora Workstation or any other non-LVM system.
There is an issue with the aarch64 SBC installation image. You can't use a Fedora Server Edition host to transfer the distribution image onto a SD card. Use Fedora Workstation or any other non-LVM system.
=== Updating to Fedora 39
@ -182,7 +182,7 @@ Before you start the process you should use `df -h` to check the root file syste
Upgrading using the dnf upgrade process is fully tested and supported. No issues were found during the release tests.
With release 37 we additionally deliver a Fedora Server KVM virtual disk image. Now it is much easier to provision a Fedora server with virtual machines.
With release 37 we additionally deliver a Fedora Server KVM virtual disk image. Now it's much easier to provision a Fedora server with virtual machines.
The Fedora KVM image resembles a standard Fedora Server installation as close as possible. An administrator should not detect any differences in the work routines - except for hardware specific actions, of course. For details see the supplemented user documentation xref:virtualization/vm-install-diskimg-fedoraserver.adoc[Creating a virtual machine using Fedora Server Edition disk image].

View file

@ -71,7 +71,7 @@ If you are a more experienced administrator, you may wish to further the rationa
You will select `Custom` and create the `BIOSboot`, `efi` and `/boot` partitions as required and a small partition and VG dedicated to the operating system. A good size for this VG (eg. ```sysvg```) is, approximately, 30 GiB. Occupying the remaining space, you will create a dedicated partition and Volume group (eg. ```usrvg```) for user data. You will end up with 4 partitions on the hard disk (boot, sysvg, usrvg with Bios boot machines and hard disks up to 2 TB) rsp. 4 partitions (BIOSboot/efi, boot, sysvg, usrvg for all other machines) that use all the available space.
Create a LV (e.g. ```sys_root```) of about 15 GiB for the operating system and maybe additional LVs for the runtime environment, e.g. a LV ```sys_log``` of about 5 GB. Mount it at ```/var/log``` to prevent log files from flooding and blocking the system and, vice versa, prevent that any other space issue on the root partition block your logs and complicate error analysis. The remaining free space is left for distribution as needed over time. Similar to the default partitioning, all user data is created as LVs in ```usrvg``` and mounted in the corresponding directories of the system. This is the maximum possible separation of system and user data with only one hard disk available. And with today's typical hard drive size of 2 TB and more, those dedicated 30 GBs 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 don't interfere with the effective use of disk space anymore.
==== Raid system
@ -91,9 +91,9 @@ Some system administrators prefer a static configuration even if there is DHCP a
=== Choosing the right installation medium
Fedora Server comes with its own special installation ISO image, either as a full local installation or as a network installation. If at all possible, use one of the two https://fedoraproject.org/server/download[Fedora Server Edition] alternatives ("Standard" or "Netinstall") and avoid booting from another image. Anaconda, the installation program and the GUI look alike for any edition or spin, but are tailored differently under the hood, e.g. with different configuration defaults.
Fedora Server comes with its own special installation ISO image, either as a full local installation or as a network installation. If at all possible, use one of the two https://getfedora.org/en/server/download/[Fedora Server Edition] alternatives ("Standard" or "Netinstall") and avoid booting from another image. Anaconda, the installation program and the GUI look alike for any edition or spin, but are tailored differently under the hood, e.g. with different configuration defaults.
That is why you do not get a "Fedora Server Edition" as a result with the "__Everything__" installation medium, even if you select "Fedora Server" as a software package. This can lead to various problems during operation and is __not supported__.
That's why you don't get a "Fedora Server Edition" as a result with the "__Everything__" installation medium, even if you select "Fedora Server" as a software package. This can lead to various problems during operation and is __not supported__.
=== Download the proper installation media
@ -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.
. And as a (typically busy) server sysadmin to be, you might appreciate a tool provided by the Open Source https://www.ventoy.net/[ventoy] project. A small utility on a USB stick of any size takes over the presentation of the device to the hardware as bootable, and reads itself the ISO file, which is stored on a data partition of the stick. Depending on it's size, it can accomodate multiple ISO files. The server sysadmin can choose between them at boot time in a selection menu. With a new version simply copy the ISO file as it is on the stick and ready to go. No more dd and no Media Writer.
With everything done proceed with one of the available installation procedures.

View file

@ -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 doesn't include a hardware raid capability, you may configure a software RAID system. Switch to xref:installation/sw-raid-upon-installation.adoc[Exkurs: Configuring a software RAID during installation] and then continue here with the Network section.
* *Custom configuration*
+

View file

@ -131,7 +131,7 @@ $ sudo mount /dev/sdb1 /mnt
. Create and edit a kickstart file _ks.cfg_ in the root directory of the USB flash drive.
+
If possible, you should provide a static network configuration, so you'll know the IP address. If that is not possible and DHCP is available, you can omit the "network" line. Anaconda will then use DHCP and display the address it receives.
If possible, you should provide a static network configuration, so you'll know the IP address. If that isn't possible and DHCP is available, you can omit the "network" line. Anaconda will then use DHCP and display the address it receives.
+
[source,bash]
----
@ -154,7 +154,7 @@ Continue with __3.2. Connecting to the server__.
If none of the above options work with your server and network configuration, you could patch the installation media as a last resort. As an example, you can change the grub boot lines in /isolinux/grub.conf. You would need to add the RDP parameter and remove the integrity test, as this is the default line but would fail after patching.
We will not go into this matter any further here. This is really the very last resort and is not recommended.
We won't go into this matter any further here. This is really the very last resort and is not recommended.
== Connecting to the server
. In case of a server without a console attached determine the IP address.

View file

@ -248,7 +248,7 @@ b. Just in case IPv6 is configured as local only (fe80::....) or not static, you
# nmcli con reload
----
+
Again, do not forget to adjust names, prefix, and DNS IP addresses. Pay special attention to the gateway. Using a local address of 1 (fe80::1) is a widely used convention.Another is the IPV6 prefix with the address 1. But each provider may have an even different approach.
Again, don't forget to adjust names, prefix, and DNS IP addresses. Pay special attention to the gateway. Using a local address of 1 (fe80::1) is a widely used convention.Another is the IPV6 prefix with the address 1. But each provider may have an even different approach.
+
Check connectivity from your local workstation. If that fails, the gateway configuration is the first suspected culprit.
+
@ -258,7 +258,7 @@ Check connectivity from your local workstation. If that fails, the gateway confi
# # e.g. ping6 2a01:xxx:yyy:zzz::2
----
c. Optionally reconfigure IPv4 as static. But make sure the IPv6 address works and do not change both protocol stacks at the same time (and in the worst case drop connectivity at all):
c. Optionally reconfigure IPv4 as static. But make sure the IPv6 address works and don't change both protocol stacks at the same time (and in the worst case drop connectivity at all):
+
[source,console]
----
@ -270,7 +270,7 @@ c. Optionally reconfigure IPv4 as static. But make sure the IPv6 address works a
# nmcli con reload
----
+
Again, do not forget to adjust names, prefix, and DNS IP addresses and check connectivity from your local workstation:
Again, don't forget to adjust names, prefix, and DNS IP addresses and check connectivity from your local workstation:
+
[source,console]
----
@ -330,7 +330,7 @@ b. If you have chosen the _Default_ partitioning but are _not content_ with the
+
[CAUTION]
====
This is not a recommended procedure! Do not complain in case of issues.
This is not a recommended procedure! Don't complain in case of issues.
====
+
Cockpit provides an easy way for this. On the right side of the 'root' filesystem line select the 3 dot button. Choose _Grow_ for the logical volume. Determine the new size as needed.
@ -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's time to update the system and install some useful software. Of course, 'useful software' varies depending on the use case or applications that will be run on Fedora Server. Anyway, a good choice might be vim. With vimdiff e.g. a comparison of updates of configuration files (*.rpmnew) is very comfortable and straightforward.
[source,console]
----
# dnf install vim-default-editor --allowerasing

View file

@ -13,13 +13,13 @@ The RAID configuraton starts at the "Installation Destination" window.
.The Installation Destination window
image:installation/sw-raid/001-installationdestination.png[]
The _Local Standard Disk_ list must include at least two hard disks. And please, ignore the USB drive that provides the installation system, in case Anaconda does not hide the installation media anyway.
The _Local Standard Disk_ list must include at least two hard disks. And please, ignore the USB drive that provides the installation system, in case Anaconda doesn't hide the installation media anyway.
Before you start with partitioning, you have to determine the boot type of your system, UEFI boot or BIOS (or legacy) boot system. Fedora defaults to the GPT partitioning scheme which was created with UEFI boot systems in mind. On a BIOS boot system, it requires a special partition.
NOTE: Just in case you need a DOS/MBR partitioning scheme for some good reason, you can override the GPT default by adding "inst.mbr" to the kernel boot parameter at the initial boot screen.
If you do not know the type of your system for sure, you can check the system now. Open a temporary shell by using `<alt>+<ctrl>+<F2>` and type into the terminal window:
If you don't know the type of your system for sure, you can check the system now. Open a temporary shell by using `<alt>+<ctrl>+<F2>` and type into the terminal window:
[source,console]
----
# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
@ -31,7 +31,7 @@ There are then two installation options:
* The "**Custom**" option
+
This way you just specify the mountpoints and Anaconda performs all the necessary steps for you. If needed you can adjust some properties afterwards. That is the comfortable way.
This way you just specify the mountpoints and Anaconda performs all the necessary steps for you. If needed you can adjust some properties afterwards. That's the comfortable way.
+
Unfortunately, Anaconda does not necessarily keep the arrangement of the partitions that you have chosen, but sorts the partitions as it sees fit. This causes no problems at all in everyday operation. But if, for example, you have placed a partition at the end to preserve the possibility of making adjustments later, that could go wrong.
@ -121,7 +121,7 @@ Use the "+" sign to add another Mount Point
* enter 15 Gib as size
* Tick "Add Mount Point"
+
Anaconda creates a new mount point. From the context Anaconda guesses to assign the device type LVM, to create a Volume Group using the default name _fedora_ appending the systems hostname, if you already configured the network, and to assign the device name root. The size of 15 GiB is the same as a default configuration would do. That is a lot of work that Anaconda saves you.
Anaconda creates a new mount point. From the context Anaconda guesses to assign the device type LVM, to create a Volume Group using the default name _fedora_ appending the systems hostname, if you already configured the network, and to assign the device name root. The size of 15 GiB is the same as a default configuration would do. That's a lot of work that Anaconda saves you.
+
.Anaconda generated LVM root volume and filesystem
image:installation/sw-raid/140-custom-generated-root.png[]
@ -172,7 +172,7 @@ a partition.
.Create a BIOS Boot partition
image:installation/sw-raid/205-adv-custom-biosboot.png[]
+
First select "Bios Boot" in the „Filesystem“ selection field and then enter 1 MiB as the size. An OK creates the partition and updates the free space area. 1 MiB is quite sufficient, but sometimes the dialogue insists on 2 MiB and corrects the entry accordingly. That is fine, too.
First select "Bios Boot" in the „Filesystem“ selection field and then enter 1 MiB as the size. An OK creates the partition and updates the free space area. 1 MiB is quite sufficient, but sometimes the dialogue insists on 2 MiB and corrects the entry accordingly. That's fine, too.
+
Next, click on sdb and thus activate it for editing. Repeat the process to create a BIOSBoot partition as before.
+

View file

@ -11,4 +11,4 @@ Can I see a built preview of this template to get a better idea about the result
Is writing documentation hard and dreadful?::
Absolutely not (OK, just joking). Writing documentation in AsciiDoc is very simple and straightforward. In fact, writing documentation makes you happy. Just try it yourself!
How do I manage SELinux issues?::
First of all: Do not deactivate but resolve issues - (Link to Server Sysadmin Cockpit page and Quick Docs)
First of all: Dont deactivate but resolve issues - (Link to Server Sysadmin Cockpit page and Quick Docs)

View file

@ -61,6 +61,6 @@ The choice of an SBC model therefore requires careful consideration if you do no
[WARNING]
====
When choosing a device for Fedora Server, check carefully if the available hardware capabilities are compatible with the intended use and are actually supported by Fedora. Take everything with a grain of salt. Do not expect everything to work just smoothly with SBCs. It is best to ask in advance on the arm mailing list.
When choosing a device for Fedora Server, check carefully if the available hardware capabilities are compatible with the intended use and are actually supported by Fedora. Take everything with a grain of salt. Don't expect everything to work just smoothly with SBCs. It is best to ask in advance on the arm mailing list.
====

View file

@ -41,14 +41,14 @@ Even though the installation works quite differently, Fedora Server ultimately f
+
[WARNING]
====
The critical passage is "supported by Fedora". When choosing a device for Fedora Server, check carefully if it is really actually supported. Unlike the x86 universe, do not expect everything to work just as smoothly in ARM, e.g. aarch64. Take everything with a grain of salt. It is best to ask in advance on the arm mailing list or Matrix room.
The critical passage is "supported by Fedora". When choosing a device for Fedora Server, check carefully if it is really actually supported. Unlike the x86 universe, don't expect everything to work just as smoothly in ARM, e.g. aarch64. Take everything with a grain of salt. It is best to ask in advance on the arm mailing list or Matrix room.
====
* A *Fedora system*, which provides the Fedora utility program, __arm-image-installer__.
+
The utility should basically be usable with any Linux desktop, but not with Windows or MacOS. You have to install VirtualBox or any other virtualization software that is able to provide direct access to the physical USB port or SD card slot, and install Fedora as a guest system.
//+
//If your device is a Raspberry Pi model 3 or 4 you do not need to make any adjustments and can install Balena Etcher instead to transfer the image to the SD card.
//If your device is a Raspberry Pi model 3 or 4 you don't need to make any adjustments and can install Balena Etcher instead to transfer the image to the SD card.
* A *pluggable disk* of suitable size, practically, this is either an SD card or eMMC storage on a removable daughter board. The absolute minimum capacity is 8 GB, but a capacity of 32 GB should be fine and affordable nowadays.
@ -148,7 +148,7 @@ Other Devices:
arndale chiliboard cl-som-am57x rpi2 rpi3 rpi4 olpc_xo175
----
+
If you do not find your board, check the _boards.d_ directory directly just in case the list is not up to date.
If you don't find your board, check the _boards.d_ directory directly just in case the list is not up to date.
+
[source,bash]
----
@ -180,11 +180,11 @@ Consult the https://fedoraproject.org/wiki/Architectures/ARM/Installation#Arm_Im
=== Basic installation and configuration
At the SBC terminal, we perform only the minimum, absolutely necessary configuration, namely the creation of a user including password and administrative privileges. Just in case your network does not provide DHCP, you have to configure the IP address as well. Everything else can be more conveniently accomplished via ssh or Cockpit from the desktop.
At the SBC terminal, we perform only the minimum, absolutely necessary configuration, namely the creation of a user including password and administrative privileges. Just in case your network doesn't provide DHCP, you have to configure the IP address as well. Everything else can be more conveniently accomplished via ssh or Cockpit from the desktop.
1. make sure that the SBC is disconnected from power.
2. Connect monitor, keyboard and network cable, insert the micro SD card.
3. Connect the SBC to power and wait. After some time a lot of messages scroll across the screen. If the network interface does not provide DHCP, in includes a NetworkManager error message. You can safely ignore it for now. It finally ends with a simple, text-based input mask for the first boot configuration.
3. Connect the SBC to power and wait. After some time a lot of messages scroll across the screen. If the network interface doesn't provide DHCP, in includes a NetworkManager error message. You can safely ignore it for now. It finally ends with a simple, text-based input mask for the first boot configuration.
+
[source,console]
----
@ -258,7 +258,7 @@ 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.
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.
6. If you don't have a DHCP server on your LAN you may configure network connection in this menu or use the command line in the next stage. Specifically it you use a non-US keyboard it may be tedious and error prone to use this menu.
+
Even with DHCP active, it may be useful to set the hostname here, so that an internal DHCP-based name server receives the correct name immediately. Type "3" and fill in your hostname.
@ -274,7 +274,7 @@ Web console: https://localhost:9090/ or https://uuu.vvv.www.xxx:9090/
rockpro login:
----
+
The hostname here is default, because the box did not receive a name from DHCP during first boot. Please note the IP address to use next with ssh or Cockpit.
The hostname here is default, because the box didn't receive a name from DHCP during first boot. Please note the IP address to use next with ssh or Cockpit.
+
[IMPORTANT]
====
@ -308,7 +308,7 @@ NAME UUID TYPE DEVICE
'Wired connection 2' 8d971f49-033f-398a-9714-3a4e848178fb ethernet enp2s0
----
+
Most likely your interfaces are named somewhat awkward way. Let's fix that to make administration of network easier and more comfortable. Do not forget to adjust the naming to your specific installation!
Most likely your interfaces are named somewhat awkward way. Let's fix that to make administration of network easier and more comfortable. Don't forget to adjust the naming to your specific installation!
+
[source,console]
----
@ -505,7 +505,7 @@ Enter the address _https://192.168.158.172:9090_ into your browser. If successfu
+
image::installation/on-sbc-060.png[Cockpit Overview Screen]
+
Unfortunately you cannot log in right now because you do not know the password.
Unfortunately you can't log in right now because you don't 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.
+

View file

@ -50,7 +50,7 @@ Read on to learn how to configure mDNS.
https://avahi.org/[Avahi] provides an implementation of mDNS that is available on most, if not all, Linux distributions.
Avahi may already be installed, but if it is not, install with `dnf`:
Avahi may already be installed, but if it isn't, install with `dnf`:
[source,console]
----

View file

@ -181,7 +181,7 @@ Some of the possible authentication methods require additional settings for SELi
=== Connection options
Now you are allowed to authenticate from machines on the internal network, but you still cannot connect from the internal network to the PostgreSQL server. The default configuration restricts connection initially to the local host to avoid any security vulnerabilities in the first place.
Now you are allowed to authenticate from machines on the internal network, but you still can't connect from the internal network to the PostgreSQL server. The default configuration restricts connection initially to the local host to avoid any security vulnerabilities in the first place.
Connections granted are configured in ~/data/postgresql.conf. To grant access to VMs on the internal network as well as from local host, edit the file near the beginning to match the pattern below.
[source,console]

View file

@ -0,0 +1,325 @@
= ImageFactory how to create a virtual machine disk image
Peter Boy; Jason Beard
:revnumber: F37-F38
:page-authors: {author}, {author_2}
:revdate: 2024-01-14
[abstract]
//----
The objective here is to learn to create a standard Fedora Server Edition bootable virtual disk image to be used as a base for further customization. The tool chain is the same as used by Fedora release engineering team. It ensures compatibility as much as possible and is making the installation as simple and speedy as possible.
//----
The goal is to set up a working environment to create customized, bootable and ready to be used Fedora Server virtual machine disk images. The tool to be used, ImageFactory, is a bit of a challenge. Therefore, we start with setting up a complete and known to work base setting. On this solid basis, they can then start modifying and adapting the configuration to their needs. That way, in case of bugs, it is quite easy to locate the probable cause.
== Why ImageFactory
There are many tools to create a VM virtual disk image. ImageFactory is probably one of the oldest and not necessarily in the best of shape. Its key advantage is that it is also used for building Fedora releases. You can use a variety of resources maintained by the Fedora Release Engineering team. This greatly facilitates the work and makes up for the aforementioned disadvantage.
== Requirements
There are some items to take into account.
* You use ImageFactory exclusively via __CLI__. There is no graphical interface. So you should be __familiar with the terminal__.
* We use _Fedora Server_ here, but in principle any of the Fedora desktop systems is usable as well.
* In this example, you need root permissions to execute the build process (sudo is sufficient, of course).
* ImageFactory is completely based on a "__Kickstart__" file that controls the whole process. We provide a Kickstart file for download in the appendix, which creates a complete Fedora Server Edition VM. It serves here as a “Hello World” example, but is also suitable as a starting point for your own development.
+
Getting a Kickstart file to work correctly according to your goals is the hardest (and only) challenge to meet.
// Verweis hier auf Dokumentation, evt. "Creating the Kickstart File RH documentation"
* And it requires a _template_ file that provides metadata about the image to be created. The content is pretty standard and doesn't need any special attention. We provide a template file for download in the appendix.
== Preparation
=== Create a working environment
ImageFactory uses a virtual machine to tailor the image, so you need virtualization capabilities. If you work directly with your host (i.e. on hardware), you need to xref:virtualization/vm-install-diskimg-fedoraserver.adoc[install Virtualisation]. Furthermore, ImageFactory installs a variety of software that an admin would not necessarily want to see in the everyday working environment. It is therefore recommended to create a dedicated virtual machine for this purpose if possible and use nested virtualization in it.
1. _On your host (on hardware) if not already done_: Add virtualization capability as described in xref:virtualization/installation.adoc[Adding Virtualization Support].
2. __Optional: Install a dedicated Fedora Server virtual machine__, follow the steps as described in xref:virtualization/vm-install-diskimg-fedoraserver.adoc[Creating a virtual machine using Fedora Server Edition disk image] and add virtualization capability as described in xref:virtualization/installation.adoc[Adding Virtualization Support], too.
+
_Nested virtualization_ should already work in Fedora, check as described in xref:virtualization/nested-virtualization.adoc[Setting up Nested Virtualization].
3. Ensure the _Guestfish suite is installed_ to get the utilities to access and modify generated disk image files. If you follow xref:virtualization/installation.adoc[Adding Virtualization Support] exactly, it is. Otherwise install it.
+
[source,console]
----
$ sudo dnf install guestfs-tools
----
+
Check to really install `guestfs-tools`, not `libguestfs-tools` (unless you need additional windows guests related software).
4. Ensure that you have at least about 25 GB space available in your working environment.
5. If you want to make use of Fedora Kickstart files you need to have `git` installed.
=== Install ImageFactory
ImageFactory includes the base package and various plugins for different target platforms. To be able to use ImageFactory practically, all plugins should be installed, regardless of the target format. Additionally, the package pykickstart provides several helper programs, among others ksflatten to check and optimize the kickstart file.
1. _Create logical volumes_ for ImageFactory working files. To make it easy use _Cockpit_.
a. First create a thin image pool of about 25 G wherein you can create the file systems actually to be used. This allows you to use the available space flexibly. In the _Storage_ tab select the system volume group in the _Devices_ box on the right side. In the list of _Logical volumes_ select __Create new logical volume__.
+
image::tutorials/imagefactory-kvm/030-create-thinpool-en.png[Cockpit Create thin pool]
+
The list of logical volumes show a thin pool and a button to create thin volumes inside.
+
image::tutorials/imagefactory-kvm/035-show-thinpool-en.png[Cockpit show thin pool]
b. Create a thin volume named _imagefactory_ of max. 20 G for the working directory of ImageFactory and format an XFS filesystem to be mounted at /var/lib/imagefactory.
+
image::tutorials/imagefactory-kvm/040-create-thinvolume-en.png[Cockpit show thin pool]
+
Now, the list of logical volumes includes a new volume below imgfact_pool
+
image::tutorials/imagefactory-kvm/045-show-thinvolume-en.png[Cockpit show thin pool]
c. Repeat the step b to create a logical volume of maximal 10 G named _oz_ to be mounted at /var/lib/oz
+
image::tutorials/imagefactory-kvm/059-list-volumes-en.png[Cockpit list volumes]
2. _Install Imagefactory_
+
[source,console]
----
$ sudo dnf install imagefactory imagefactory-plugins* pykickstart
----
+
This installs about 209 packages (in F38). To be sure, check and restore the SELinux labels for the installation directories.
+
[source,console]
----
$ sudo /sbin/restorecon -R -vF /var/lib/imagefactory
$ sudo /sbin/restorecon -R -vF /var/lib/oz
----
3. _Adjust Imagefactory configuration_
a. __Enlarge the amount of working memory__ for OZ, the backend used by ImageFactory.
+
[source,console]
----
$ sudo sed -i -e 's/# memory = 1024/memory = 2048/' /etc/oz/oz.cfg
----
b. Optional: _Switch the image output format_ from the default "raw" type to qcow2 to save disk space. If you have plenty thereof, leave it as is.
+
[source,console]
----
$ sudo vim /etc/oz/oz.cfg
(edit)
#image_type = raw
image_type = qcow2
----
=== Set up a working directory
At a convenient location, create a directory where you will store all your working files, for example, in your home directory.
[source,console]
----
$ mkdir ~/imagefactory
----
It will primarily be used to store the kickstart and the template files. You may use your personal account and use sudo for all commands. However, it is more convenient to work as root. This is only advisable in a dedicated VM as explained above.
==== The Kickstart file
The kickstart file describes the content of the disk image to create. Fetch the link:{attachmentsdir}/tutorials/imagefactory/fedora-server-kvm-dev.ks[basic kickstart file "fedora-server-kvm-dev.ks"]. Probably it is a good idea to clone the https://pagure.io/fedora-kickstarts[Fedora kickstart repository] as well. It may be advantageous to check for a file with a similiar target you want to create and start with that. In any case, a look at the various Kickstart files can give you ideas on how to achieve your goal.
1. Fetch the link:{attachmentsdir}/tutorials/imagefactory/fedora-server-kvm-dev.ks[basic kickstart file] and store it into this working directory. In many cases clicking the link stores the file into you default download directory, ~/Downloads in case of Fedora desktops or Macs.
+
[source,console]
----
$ mv ~/Downloads/fedora-server-kvm-dev.ks ~/imagefactory/
----
2. Optional: _Clone the Fedora kickstart repository_ for easy access to reference material.
+
[source,console]
----
$ mkdir ~/imagefactory/FedoraKickstarts
$ git clone https://pagure.io/fedora-kickstarts.git -o upstream ~/imagefactory/FedoraKickstarts
----
+
If you are planning to contribute your VM you should create a fork, too, so you can provide a pull request.
==== The download URL helper file
ImageFactory uses Anaconda to create the disk image. It uses the network installatin method and needs appropriate URLs for Download. Anaconda expects this information as part of the installation specification, i.e. within the corresponding section of the Kickstat file. To simplify the management of the download URLs, they are offloaded to an include file named "fedora-repo.ks". In this file you can easily manage different Fedora versions and download sources without disturbing the flow in the Kickstart file.
You have to create this file in your working directoy. In this example we name it `fedora-repo.ks` which is the same name as Fedora is using. This way you can contribute your work as you go.
The exact content depends entirely on local conditions. The basis is the following sample:
[source,console]
----
$ vim ~/imagefactory/fedora-repo.ks
# Include the appropriate repo definitions
# uncomment the repo specification to use.
# Fedora Release mirrors
#repo --name=fedora --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-37&arch=x86_64
#repo --name=updates --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f37&arch=x86_64
#url --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-37&arch=x86_64
## Regional Fedora release mirror (F37 / x86_64)
#repo --name="fedora-rwth" --baseurl=http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/37/Server/x86_64/os
#repo --name="updates-rwth" --baseurl=http://ftp.halifax.rwth-aachen.de/fedora/linux/updates/37/Everything/x86_64/
# Use network installation
#url --url="http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/37/Everything/x86_64/os/"
## Koji image creation (branched development tree)
repo --name="koji-override-0" --baseurl=https://kojipkgs.fedoraproject.org/compose/branched/Fedora-38-20230312.n.0/compose/Everything/x86_64/os
repo --name="koji-override-1" --baseurl=https://kojipkgs.fedoraproject.org/compose/branched/Fedora-38-20230312.n.0/compose/Server/x86_64/os
# Use network installation
url --url="https://kojipkgs.fedoraproject.org/compose/branched/Fedora-38-20230312.n.0/compose/Everything/x86_64/os"
----
==== The template file
The template file describes meta data of the disk image to create. That includes the repository to download and the size of the disk image. Don't worry too much about the download URL. It will be overwritten by the kickstart file.
Fetch the corresponding link:{attachmentsdir}/tutorials/imagefactory/fedora-server-kvm-dev.tdl[basic template file] and store it into the working directory. In many cases clicking the link stores the file into you default download directory, ~/Downloads in case of Fedora desktops or Macs.
[source,console]
----
$ mv ~/Downloads/fedora-server-kvm-dev.tdl ~/imagefactory/
----
The version number inside the template file (22) is not necessarily the Fedora target version. For some reason it is best to leave it untouched! But you have to adjust the download URL!
== Working with ImageFactory
=== Create an image file
1. prepare and optimize kickstart file with ksflatten:
+
[source,console]
----
$ ksflatten -c fedora-server-kvm-dev.ks -o fedora-server-kvm-dev-fl.ks
----
2. Check using ksvalidator
+
[source,console]
----
$ ksvalidator -i fedora-server-kvm-dev-fl.ks
----
3. Create the image
+
Using a vm and guestfs-tools to adapt the image. This is the _preferred operation_ mode.
+
[source,console]
----
$ sudo imagefactory --debug base_image --file-parameter install_script \
fedora-server-kvm-dev-fl.ks fedora-server-kvm-dev.tdl \
--parameter offline_icicle true
----
+
The creation process takes some time. Therefore, the debug option provides some feedback about the progress.
+
ImageFactory creates a non-system temporary VM to build the image, which is visible in Cockpit's VM list. It is usefull to watch the terminal window of this instance during the build. It shows a log of all the building steps and specifically errors or warnings. Unfortunately, the VM gets destroyed when Imagefactory finishes.
+
Additionally, you find loging output in the /var/lib/oz directory. Often specifically useful are the (virtual) screenshots in the respective subdirectory.
4. Output in case of a successful generation
+
[source,console]
----
============ Final Image Details ============
UUID: 4ebde351-e81b-427f-96b7-5acd5680013d
Type: base_image
Image filename: /var/lib/imagefactory/storage/4ebde351-e81b-427f-96b7-5acd5680013d.body
Image build completed SUCCESSFULLY!
----
=== Check out a created image file
To access the filesystem inside a generated image, use guestfs-tools. Ensure that the image in _not used_ in an active VM.
1. Copy the generated vm into the libvirt installation media pool
+
[source,console]
----
# qemu-img convert -c -O qcow2 /var/lib/imagefactory/storage/xxx-yyy-zzz.body /var/lib/libvirt/boot/fedora-server-kvm-dev.qcow2
----
2. Check and analyze the file system
+
[source,console]
----
# cd /var/lib/libvirt/boot
# guestfish -a fedora-server-kvm-dev.qcow2
Welcome ….
><fs> run
...(wait)
><fs> list-filesystems
/dev/...
><fs> quit
----
3. Mount the file system(s)
+
Following the list of file systems above, mount each filesystem and check
+
[source,console]
----
# mkdir /mnt/test
# guestmount -a fedora-server-kvm-dev.qcow2 -m /dev/xxx/yyy /mnt/test
----
4. Clean up
+
[source,console]
----
# mkdir /mnt/test
# guestmount -a fedora-server-kvm-dev.qcow2 -m /dev/xxx/yyy /mnt/test
----
=== Instantiate and test a created image
1. Copy the generated vm into the libvirt disk image pool
+
[source,console]
----
# cp /var/lib/libvirt/boot/fedora-server-kvm-dev.qcow2 /var/lib/libvirt/images/vm-test.qcow2
----
2. Instantiate a VM
+
[source,console]
----
# virt-install --name vm-test \
--memory 4096 --cpu host --vcpus 2 --graphics none\
--os-variant fedora-unknown\
--import \
--disk /var/lib/libvirt/images/vm-test.qcow2,format=qcow2,bus=virtio \
--network type=direct,source=enp1s0,source_mode=bridge,model=virtio \
--network bridge=virbr0,model=virtio
----
Follow the steps as specified in xref:virtualization/vm-install-diskimg-fedoraserver.adoc#_minimal_initial_configuration[Creating a virtual machine using Fedora Server Edition disk image Minimal initial configuration].
// xref:/virtualization/vm-install-diskimg-fedora-server.adoc#_minimal_initial_configuration
=== Adjust the Kickstart file
You are ready now to modify the Kickstart file according your local requirements and create an image and test it again and again.
//== Trouble shooting
//TBD
//* export LIBGUESTFS_BACKEND=direct

View file

@ -3,7 +3,6 @@ Peter Boy
:revnumber: F38,F39
:page-authors: {author}
:revdate: 2024-01-14
:page-aliases: pages/tutorials/wordpress-installation.adoc
[abstract]
WordPress is a common blog system that can also be used for simple websites. Fedora includes an RPM package, so the installation is very simplified. This article focuses on Fedora-specific implementation details.
@ -30,7 +29,7 @@ Another good first overview provides the https://fedoramagazine.org/[_Fedora Mag
* We assume a correctly installed Fedora Server Edition release 38 or 39. For details see xref:installation/index.adoc[Fedora Server Installation Guide].
* WordPress stores most of the content in a database. Accordingly, it requires access to a working database system and does not even start up without. Currently, it https://wordpress.org/plugins/postgresql-for-wordpress/[no longer supports PostgreSQL], the Fedora Server Edition preferred and specifically supported database system. It just supports MariaDB or MySQL, which are included in Fedora as well.
* WordPress stores most of the content in a database. Accordingly, it requires access to a working database system and doesn't even start up without. Currently, it https://wordpress.org/plugins/postgresql-for-wordpress/[no longer supports PostgreSQL], the Fedora Server Edition preferred and specifically supported database system. It just supports MariaDB or MySQL, which are included in Fedora as well.
+
So you have to install either MariaDB or MySQL following xref:quick-docs:installing-mysql-mariadb.adoc[Installing MySQL/MariaDB]. In terms of WordPress, both systems work equally smoothly. Following Fedora's preference for truly OSS software we use MariaDB here.
+
@ -174,7 +173,7 @@ Note: Currently no SSL access is defined, only http protocol is available.
+
The Fedora default page is displayed.
+
image::usecases/wordpress/fedora-default-page.png[Fedora default page]
image::tutorials/wordpress/fedora-default-page.png[Fedora default page]
. Your WordPress installation is available at
+
@ -185,7 +184,7 @@ http://example.com/wordpress
+
If you implemented the access restriction as proposed, you get the default Apache login screen. Otherwise and after authentication you see the basic WordPress graphical configuration page.
+
image::usecases/wordpress/initial-installation-page.png[Fedora default page]
image::tutorials/wordpress/initial-installation-page.png[Fedora default page]
+
Complete the various items as appropriate.

View file

@ -3,7 +3,6 @@ Peter Boy; Jan Kuparinen
:revnumber: F35-F36
:page-authors: {author}, {author_2}
:revdate: 2022-03-9
:page-aliases: pages/usecase-gui-addon.adoc
Some users install Fedora Server Edition and then manually add a graphical user interface. Sometimes it is a matter of more convenient administration of a locally accessible server, sometimes it is a kind of off-label use, and desire for a server hardened runtime environment as a workstation with special requirements.

View file

@ -75,7 +75,7 @@ The big disadvantage is that this process is very time-consuming. If several VMs
As the tool to run the distribution's native installer, Fedora recommends __Cockpit__, a web-based graphical and comfortable administration tool. An alternative is Virt-Manager, also a graphical utility. However, it must be installed on the local workstation (Linux only) and then works via a ssh connection. Execution on Fedora Server itself is not supported, as Fedora Server is designed to be "headless", i.e. without a graphical user interface.
Experienced administrators can also initialize an installation via the command line using VNC and virt-install. However, if you do not have a routine for this and no stock of configuration snippets to build on, this is also quite time-consuming and, moreover, then error-prone.
Experienced administrators can also initialize an installation via the command line using VNC and virt-install. However, if you don't have a routine for this and no stock of configuration snippets to build on, this is also quite time-consuming and, moreover, then error-prone.
=== Virtual disk image

View file

@ -112,7 +112,7 @@ By default, libvirt creates a (virtual) bridge with an interface virbr0, the IP
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 don't start at boot time, like qemu, lxc, etc., but on demand at first access. Therefore, you won't get an interface virbr0 until some libvirt service requests it. That's 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:
1. *Optionally, activate libvirt's internal network*
+
@ -229,11 +229,11 @@ Check if the DNS resolution works.
== Adjusting the hosts DNS resolution configuration
In order for the host to initiate communication with its virtual machines, it must query the name server set up in the previous step for internal domains. So we need Split DNS. The default systemd-resolved DNS client in Fedora is basically split-DNS capable. Unfortunately it currently does not cooperate well with libvirt's virtual network and needs additional administrative efforts.. and its usage is quite unstable. Therefore we recommend switching to dnsmasq for the time being to provide stable split DNS.
In order for the host to initiate communication with its virtual machines, it must query the name server set up in the previous step for internal domains. So we need Split DNS. The default systemd-resolved DNS client in Fedora is basically split-DNS capable. Unfortunately it currently doesn't cooperate well with libvirt's virtual network and needs additional administrative efforts.. and its usage is quite unstable. Therefore we recommend switching to dnsmasq for the time being to provide stable split DNS.
[WARNING]
====
The following procedure does not work for Fedora 35-39. Do not use it with these releases. Switch to dnsmasq for the time being as described in the next chapter instead.
The following procedure doesn't work for Fedora 35-39. Don't use it with these releases. Switch to dnsmasq for the time being as described in the next chapter instead.
====
1. The name resolver service _systemd-resolved_ introduced with Fedora 33 can do this automatically. But libvirt handles its interfaces on its own and must therefore inform systemd-resolved about it. A script in a hook provided by libvirt can take care of this. You have to adjust the local domain name (${example.lan} in the script below) accordingly!
@ -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 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 doesn't 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.

View file

@ -42,7 +42,7 @@ a generic tool to modify any non-running virtual machine, provided by `guestfs-t
== What you get
In particular, you get time. The workload is significantly lower and correspondingly faster.
But by cloud base image you (usually) do not get an alternatively built but otherwise identical build of a (server) distribution. There are some subtle differences. Some are conceptual. For example, most cloud images do not install a firewall. The cloud system usually provides this function. The use concept for the persistent storage is also different due to technical differences. And last but not least, cloud image developers may have different goals than the developers of the server variant installation of a distribution.
But by cloud base image you (usually) don't get an alternatively built but otherwise identical build of a (server) distribution. There are some subtle differences. Some are conceptual. For example, most cloud images do not install a firewall. The cloud system usually provides this function. The use concept for the persistent storage is also different due to technical differences. And last but not least, cloud image developers may have different goals than the developers of the server variant installation of a distribution.
_It is up to the system administrator to decide whether the functionality is identical to the extent that the advantages outweigh the disadvantages and it makes sense to use a specific cloud image as a virtual machine._
@ -111,7 +111,7 @@ Then select the installation type _Cloud base image_ from the drop down menu. Th
Finally tick __Set cloud init parameters__. The form changes again and reveals the last 3 lines. Enter a root password, optionally an additional user name and password.
[IMPORTANT]
====
You _must_ enter a root password. This will activate the root account at the same time. Otherwise, you can not obtain administrative privileges. The additional user account does not help!
You _must_ enter a root password. This will activate the root account at the same time. Otherwise, you can not obtain administrative privileges. The additional user account doesn't help!
====
[IMPORTANT]
====
@ -211,7 +211,7 @@ From a terminal window in the host system you should be able to ping your VM usi
$ ping vm1-el9
----
+
If the name service setup in the host is correct, the short name should work. Otherwise try the internal FQDN name (i.e. something like vm1-el9.example.lan). If name resolution does not work, switch to the VM's Cockpit terminal window. Use `ip a` to determine the internal IP and use this to ping the VM.
If the name service setup in the host is correct, the short name should work. Otherwise try the internal FQDN name (i.e. something like vm1-el9.example.lan). If name resolution doesn't work, switch to the VM's Cockpit terminal window. Use `ip a` to determine the internal IP and use this to ping the VM.
+
If pinging the IP address works, fix the name resolution. Otherwise check again network configuration.
2. *Check external connections*
@ -432,7 +432,7 @@ Check for connectivity:
# ping 192.168.122.1 # your host system internal virtual network address
----
+
The VM can connect to internal and external destinations. The name resolution for the vm itself cannot work because the static hostname is not set yet. The external host address is not responding due to Mac vlan technology and the internal name resolution is not working yet.
The VM can connect to internal and external destinations. The name resolution for the vm itself can't work because the static hostname is not set yet. The external host address is not responding due to Mac vlan technology and the internal name resolution is not working yet.
+
Check the interface devices.
+
@ -485,7 +485,7 @@ Next resize the file system, if not already done. First check the size of the fi
Exit and close the console typing <ctrl>+].
You may reboot the VM and than check /var/lib/libvirt/dnsmasq/virbr0.status again. It is now listing a hostname, internal name resolution is working now.
You may reboot the VM and than check /var/lib/libvirt/dnsmasq/virbr0.status again. It's now listing a hostname, internal name resolution is working now.
If your external DHCP server provides dynamic DNS as well, you should be able to connect to your VM from the public network:
[source,batch]

View file

@ -119,9 +119,9 @@ Copy the customized distribution file into the disk image pool, then use `virt-i
====
We use here "fedora-unknown" as os variant. The reason is that the list of known OS versions is usually only updated at a later stage. You could also try “--os-variant fedora44”.
====
The parameters are quite descriptive and must be adjusted as needed. This example configures two network interfaces. One interface shares the physical public interface in direct mode. the other provides an internal interface via a virtual bridge, as defined during the libvirt installation process. If your public interface resembles a virtual bridge, adjust the command accordingly. Leave out the ones you do not need. You will find a more detailed explanation in the https://github.com/virt-manager/virt-manager/blob/main/man/virt-install.rst[upstream documentation].
The parameters are quite descriptive and must be adjusted as needed. This example configures two network interfaces. One interface shares the physical public interface in direct mode. the other provides an internal interface via a virtual bridge, as defined during the libvirt installation process. If your public interface resembles a virtual bridge, adjust the command accordingly. Leave out the ones you dont need. You will find a more detailed explanation in the https://github.com/virt-manager/virt-manager/blob/main/man/virt-install.rst[upstream documentation].
Then, a lot of messages scroll across the screen. If the network interface does not provide DHCP, in includes a NetworkManager error message. You can safely ignore this message for now. Finally, it ends with a simple, text-based input mask for the first-boot-configuration.
Then, a lot of messages scroll across the screen. If the network interface doesn't provide DHCP, in includes a NetworkManager error message. You can safely ignore tjis message for now. Finally, it ends with a simple, text-based input mask for the first-boot-configuration.
[source,console]
----
@ -312,7 +312,7 @@ linux login:
+
In the first lines you may see two SELinux messages alike "systemd-gpt-auto-generator[xxxx]: Failed to dissect: Permission denied". You can safely ignore these messages.
+
The virtual server is up and running now, and ready for login. The initial configuration process is idiosyncratic, but it is simple and straightforward.
The virtual server is up and running now, and ready for login. The initial configuration process is idiosyncratic, but it's simple and straightforward.
2. *Login*
+
@ -425,7 +425,7 @@ If you followed the example installation above you should find
...
----
+
If the external interface does not provide DHCP you will not find an assigned IP address for enp1s0. That is what we would need to fix next.
If the external interface doesn't provide DHCP you won't find an assigned IP address for enp1s0. That's what we would need to fix next.
b. Next let's *check and fix NetworkManager naming*
+
@ -437,7 +437,7 @@ NAME UUID TYPE DEVICE
'Wired connection 1' 8d971f49-033f-398a-9714-3a4e848178fb ethernet ---
----
+
Most likely your interfaces are a named somewhat awkward way. Let's fix that to make administration of network easier and more comfortable. Do not forget to adjust the naming to your specific installation!
Most likely your interfaces are a named somewhat awkward way. Let's fix that to make administration of network easier and more comfortable. Don't forget to adjust the naming to your specific installation!
+
[source,console]
----
@ -464,7 +464,7 @@ We take the external interface as an example here.
# systemctl restart NetworkManager
----
d. The interface enp2s0 for the internal libvirt network may show an IPv6 IP, which we do not use. Therefore, you should disable IPv6 on the internal interface
d. The interface enp2s0 for the internal libvirt network may show an IPv6 IP, which we don't use. Therefore, you should disable IPv6 on the internal interface
+
[source,console]
----

View file

@ -84,7 +84,7 @@ root@pve-m-0's password:
=== Verify the image is in place
While not completely necessary, we logged back in to the Proxmox node and verified that the file had actually uploaded to the target directory. We will come back to this path later when it is time to import the disk image to a VM.
While not completely necessary, we logged back in to the Proxmox node and verified that the file had actually uploaded to the target directory. We'll come back to this path later when it is time to import the disk image to a VM.
[source,console]
----
@ -220,7 +220,7 @@ When the import process finishes you should get a success message like the one s
=== VM configuration: Disk
Now that the disk is part of the VM, we can go back to the hardware tab, highlight the new unused disk, and click edit. You should not need to change anything and can safely just click `Add`.
Now that the disk is part of the VM, we can go back to the hardware tab, highlight the new unused disk, and click edit. You shouldn't need to change anything and can safely just click `Add`.
image::virtualization/vm-proxmox-13.png[VM Configuration: Disk]
@ -232,7 +232,7 @@ image::virtualization/vm-proxmox-14.png[VM Configuration: Boot Order]
=== VM console: First boot
Now we are ready open up the console and boot the VM for the first time. You should see the normal GRUB boot loader and kernel messages stream across the console until you are presented with the final setup menu.
Now we're ready open up the console and boot the VM for the first time. You should see the normal GRUB boot loader and kernel messages stream across the console until you are presented with the final setup menu.
image::virtualization/vm-proxmox-15.png[VM Console: First Boot]

View file

@ -71,7 +71,7 @@ This template was generated by a script in the libguestfs source tree:
Associated files used to prepare this template can be found in the
same directory.
----
Some system administrator may not know off the top of their head what the @core module leaves off. And the abbreviated link provided does not help much either.
Some system administrator may not know off the top of their head what the @core module leaves off. And the abbreviated link provided doesn't help much either.
=== Minimal effort customization
Even a quick and experimental setup should take the opportunity to set a number of configurations for the virtual machine very easily right from the start. These include
@ -97,7 +97,7 @@ Please, adjust the above example as appropriate!
Specifically, _US users_ will omit the 6th line ('--firstboot-command "localectl..."') of the virt-builder command; others will have to adjust the keyboard layout. On your local Fedora Server, run `localectl list-keymaps` to get a list of supported keyboard layouts and their identifiers.
If you are performing a shortterm test installation, you may omit the third line (`--root-password ...`) of the virt-builder command for convenience and work directly as root. The app will automatically generate a password and display it. Do not forget to copy and store it safely.
If you are performing a shortterm test installation, you may omit the third line (`--root-password ...`) of the virt-builder command for convenience and work directly as root. The app will automatically generate a password and display it. Don't forget to copy and store it safely.
You get a lot of output. The process takes some time. Be patient.
@ -136,7 +136,7 @@ The example above adds 10 GiB. The maximum virtual disk size of the CentOS image
+
You can resize the virtual disk later, too. Therefore, there is no reason to plan too generously in terms of size now.
+
You should _not_ increase the maximum virtual disk image size by the _virt-builder parameter_ `--size`. It would increase the physical disk size to the same amount, which you probably do not want.
You should _not_ increase the maximum virtual disk image size by the _virt-builder parameter_ `--size`. It would increase the physical disk size to the same amount, which you probably don't want.
2. Additional information provides the virt-install https://libguestfs.org/virt-builder.1.html[man page].
== Using virt-install CLI to instantiate the VM
@ -256,7 +256,7 @@ Specify a name for the virtual machine to be created. It must be unique at least
Fill the remaining fields accordingly. Finally, deactivate __Immediately start VM__. Otherwise, you will not be able to specify the network environment and the first boot autoconfiguration can not configure the network.
Select _Import_ to create the basic virtual VM definition. It takes a short time and then the Virtual machines page is displayed again. It is list of virtual machines now shows an entry with the just defined VM in the status "Shut off" and as next action "Run".
Select _Import_ to create the basic virtual VM definition. It takes a short time and then the Virtual machines page is displayed again. Its list of virtual machines now shows an entry with the just defined VM in the status "Shut off" and as next action "Run".
=== Extended definition of the virtual machine

View file

@ -154,7 +154,7 @@ ____
There are some post-install task that are specific for a virtual machine. Otherwise, it is the same tasks that are performed after a bare-metal installation.
____
Before you start the post installation tasks you may consider to 'sparsify' the image, i.d. to mask out currently unused space and convert the image to thin provisioning (and so using the dynamic capabilities of the qcow2 image format). You must use a host terminal window. Cockpit does not currently support such an operation.
Before you start the post installation tasks you may consider to 'sparsify' the image, i.d. to mask out currently unused space and convert the image to thin provisioning (and so using the dynamic capabilities of the qcow2 image format). You must use a host terminal window. Cockpit doesn't currently support such an operation.
[source,console]
----
# qemu-img convert -O qcow2 /var/lib/libvirt/images/{VM_NAME}.qcow2 /var/lib/libvirt/images/{VM_NAME}-sparse.qcow2

View file

@ -76,7 +76,7 @@ Fedora Servers default storage setup is based on the concept of _segmenting stor
You have three options now:
1. Enlarge the existing partition and Volume group to add logical Volume as needed. That is the way of Fedora Server's default partitioning scheme. Unfortunately, you cannot enlarge partition and VG using Cockpit but have to use the terminal CLI in a one time action. Later, you can use to add or enlarge Logical volumes as needed using Cockpit.
1. Enlarge the existing partition and Volume group to add logical Volume as needed. That's the way of Fedora Server's default partitioning scheme. Unfortunately, you can't enlarge partition and VG using Cockpit but have to use the terminal CLI in a one time action. Later, you can use to add or enlarge Logical volumes as needed using Cockpit.
2. Avoid using the terminal and create an additional partition and Volume Group using just Cockpit. As with 1. you can use Cockpit again to add or enlarge Logical volumes as needed.
@ -165,13 +165,13 @@ image::virtualization/vm-management-cockpit-020.png[Cockpit enlarge libvirt pool
In the example above, the system administrator choose to provide a separate storage for the dedicated libvirt directory tree in __/dev/usrvg/libvirt__. Selecting `Grow` you get a form where you have to enter just the desired new size. Cockpit does everything else, including the adjustment of the file system, completely on its own.
It could not be simpler or faster.
It couldn't be simpler or faster.
== Manage network connectivity
=== Manage libvirt virtual network
The current version of Cockpit (255) does not offer such many configuration options for a libvirt managed virtual network so far. Cockpit lists the existing virtual networks under the "Network" link at the top line by line. Mostly this is only the default network. By expanding the line, the editing options become visible.
The current version of Cockpit (255) doesn't offer such many configuration options for a libvirt managed virtual network so far. Cockpit lists the existing virtual networks under the "Network" link at the top line by line. Mostly this is only the default network. By expanding the line, the editing options become visible.
image::virtualization/vm-management-cockpit-025.png[Cockpit libvirt virtual networks overview]
@ -225,13 +225,13 @@ As an example, the virtual machine is equipped with two interfaces, a public (en
image::virtualization/vm-management-cockpit-034.png[Cockpit delete a libvirt virtual interface]
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.
Probably you don't 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.
== Simplified Access to VMs Cockpit
Typically, a (physical) server does host not only one, but several or even a huge number of VMs. Each VM will have a running Cockpit Web Interface. To access it, you have to open a Browser window, connect and login to respective VM you want to work with separately - even if you only want to do the most minimalist of tasks. It is certainly not difficult, but it is cumbersome.
Typically, a (physical) server does host not only one, but several or even a huge number of VMs. Each VM will have a running Cockpit Web Interface. To access it, you have to open a Browser window, connect and login to respective VM you want to work with separately - even if you only want to do the most minimalist of tasks. It's certainly not difficult, but it is cumbersome.
For convenience, Cockpit provides the option to access the Cockpit instance of the VMs from the web interface of one instance, conveniently the host. The communication between the involved Cockpit instances is not handled via HTTP protocol but via SSH. Therefore, authentication can also be done via a key file. This is more secure and also more convenient.
@ -239,14 +239,14 @@ In the upper left corner you will see the name of the logged in user and the ser
image::virtualization/vm-management-cockpit-036.png[Cockpit select of add a Cockpit instance]
The _Add new host_ link opens a simple form to fill in hostname and user. And you can assign a color. If you connect the VM using a direct public interface (mac-vlan) you cannot use that interface because a direct access from host to vm via mac-vlan is not supported for technical reasons. You have to use the internal interface (usually libvirt provided `virbr0`). As a user, you should select the unprivileged administrative account that can be created during the VM installation by Anaconda.
The _Add new host_ link opens a simple form to fill in hostname and user. And you can assign a color. If you connect the VM using a direct public interface (mac-vlan) you can't use that interface because a direct access from host to vm via mac-vlan is not supported for technical reasons. You have to use the internal interface (usually libvirt provided `virbr0`). As a user, you should select the unprivileged administrative account that can be created during the VM installation by Anaconda.
Cockpit will then connect and ask for the user's password.
image::virtualization/vm-management-cockpit-038.png[Cockpit login to remote instance]
On this occasion, select automatic login via ssh keyfile. Cockpit will create one for you if none exists or otherwise uses an existing one created previously for another Cockpit connection. Cockpit installs the public key in the VM, too. You do not have to bother with all these details.
On this occasion, select automatic login via ssh keyfile. Cockpit will create one for you if none exists or otherwise uses an existing one created previously for another Cockpit connection. Cockpit installs the public key in the VM, too. You don't have to bother with all these details.
You can also log in as root. However, the default configuration does block a password-supported root ssh login. You have to generate a keyfile pair manually in advance and also install the public part in the VM. You can then select it for a root connection.
@ -254,7 +254,7 @@ You can also log in as root. However, the default configuration does block a pas
A Fedora installation makes several efforts to minimize public exposure. One of these is to prevent password-based root login via public interface. At the same time, Fedora Server installs by default Cockpit and opens the firewall accordingly. That way it introduces a password-based login again, including terminal access. That counteracts in a way the ssh measure.
It is OK to make the post installation tasks as easy and painless as possible. But securing Cockpit access has to be one of the post installation tasks. All the more so as Cockpit is usually not used on a daily basis, but runs largely unused and unattended in the background.
It's OK to make the post installation tasks as easy and painless as possible. But securing Cockpit access has to be one of the post installation tasks. All the more so as Cockpit is usually not used on a daily basis, but runs largely unused and unattended in the background.
There are several options.
@ -288,7 +288,7 @@ You can access the Cockpit interface using `https://localhost:9090` in your favo
== Concluding remarks
The examples here cover only the most common administrative tasks in virtual machine management. Currently, Cockpit can not completely replace the terminal window CLI. But the software is regularly updated and extended. A task that is currently not supported might be included in the next release. It is worth getting into the habit of briefly checking Cockpit's support for each new task.
The examples here cover only the most common administrative tasks in virtual machine management. Currently, Cockpit can not completely replace the terminal window CLI. But the software is regularly updated and extended. A task that is currently not supported might be included in the next release. It's worth getting into the habit of briefly checking Cockpit's support for each new task.