Added metadata

modules/ROOT/nav.adoc

@@ -6,7 +6,7 @@
 ** xref:bugzilla/find-duplicates.adoc[Finding duplicate bugs]
 ** xref:bugzilla/correct-component.adoc[Finding the correct component]
 ** xref:bugzilla/spam.adoc[Reporting Bugzilla spam]
-** xref:bugzilla/email-notifications.adoc[Managing email notifications]
+** xref:bugzilla/email-notifiRunningcations.adoc[Managing email notifications]
 
 * xref:getting-started-guide.adoc[Getting started with Fedora]
 
@@ -41,6 +41,7 @@
 ** xref:installing-from-source.adoc[Installing Software from Source]
 ** xref:installing-spotify.adoc[Installing Spotify on Fedora]
 ** xref:installing-skype.adoc[Installing Skype on Fedora]
+** xref:zoom.adoc[Installing Zoom on Fedora]
 
 * Usage and customisation
 ** xref:changing-hostname.adoc[Changing Hostname]
@@ -50,7 +51,7 @@
 ** xref:gnome-shell-extensions.adoc[Using GNOME Shell extensions]
 ** xref:wine.adoc[Running Windows applications with Wine]
 ** xref:create-gpg-keys.adoc[Creating GPG Keys]
-** xref:bootloading-with-grub2.adoc[Bootloading with GRUB2]
+** xref:grub2-bootloader.adoc[The GRUB2 Bootloader]
 ** xref:root-account-locked.adoc[Root Account Locked]
 ** xref:proc_setting-key-shortcut.adoc[Setting a key shortcut to run an application in GNOME]
 ** xref:disabling-automatic-screenlock.adoc[Disabling the GNOME automatic screen locking]

modules/ROOT/pages/grub2-bootloader.adoc

@@ -1,14 +1,11 @@
-= Bootloading with GRUB2
+= The GRUB2 Bootloader – Installation and Configuration 
 Michael Wu; The Fedora Documentation Team
 :revnumber: unknown
 :revdate: 2012-05-11
 :category: Administration
 :tags: How-to  Booting 
-//:page-aliases: 
+:page-aliases: installing-grub2.adoc
 
-// Optional  free form useful additional information as comment
-
-//include::{partialsdir}/unreviewed-message.adoc[]
 
 *GRUB2* is the latest version of *GNU GRUB*, the _GRand Unified Bootloader_. A bootloader is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the operating system kernel. In Fedora, the kernel is Linux. The kernel then initializes the rest of the operating system.
 

modules/ROOT/pages/installing-grub2.adoc

@@ -1,38 +0,0 @@
-ifdef::context[:parent-context: {context}]
-:context: bootloading-with-grub2
-:md: en-US/modules
-
-
-= Bootloading with *GRUB2*
-
-
-// include::{partialsdir}/unreviewed-message.adoc[]
-[IMPORTANT]
-====
-**Editor's Note** 
-
-This page is currently in the process of revision. If you find any weaknesses in the content, please let us know. Use the right button below the blue header banner.
-====
-
-*GRUB2* is the latest version of *GNU GRUB*, the _GRand Unified Bootloader_.
-A bootloader is the first software program that runs when a computer
-starts. It is responsible for loading and transferring control to the
-operating system kernel. In Fedora, the kernel is Linux. The kernel then initializes
-the rest of the operating system.
-
-*GRUB2* is the follower of the previous version *GRUB* (version 0.9x). The original version is available under the name *GRUB Legacy*.
-
-Since Fedora 16, *GRUB2* has been the default bootloader on x86 BIOS
-systems. For upgrades of BIOS systems, the default is also to install
-*GRUB2*, but you can opt to skip bootloader configuration entirely.
-
-include::{partialsdir}/proc_discovering-the-firmware-type.adoc[leveloffset=+1]
-
-include::{partialsdir}/proc_installing-grub2-on-bios-system.adoc[leveloffset=+1]
-
-include::{partialsdir}/proc_installing-grub2-on-efi-system.adoc[leveloffset=+1]
-
-include::{partialsdir}/proc_adding-other-operating-systems-grub2.adoc[leveloffset=+1]
-
-ifdef::parent-context[:context: {parent-context}]
-ifndef::parent-context[:!context:]

modules/ROOT/pages/systemd-understanding-and-administering.adoc

@@ -0,0 +1,607 @@
+= Understanding and administering systemd
+Christopher Engelhard; Kamil Páral;  Caleb McKee 
+:revnumber: unknown
+:revdate: 2020-08-05
+:category: Administration
+:tags: How-to  Upgrade 
+:source-highlighter: prettify
+:page-aliases: understanding-and-administering-systemd.adoc
+
+
+
+[abstract]
+Learn the basic principles of the _systemd_ init system: how to configure it and use it to administer the system.
+
+
+== Understanding systemd
+
+_Systemd_ is a system and service manager for Linux, compatible with SysV and LSB init scripts. _Systemd_ provides:
+
+* Aggressive parallelization capabilities
+* Uses socket and D-Bus activation for starting services
+* Offers on-demand starting of daemons, keeps track of processes using Linux cgroups
+* Supports snapshotting and restoring of the system state
+* Maintains mount and automount points
+* Implements an elaborate transactional dependency-based service control logic.
+
+The `systemctl` command is the primary tool to manage _systemd_. It combines the functionality of SysVinit's `service` and `chkconfig` commands into a single tool you can use to enable and disable services permanently or only for the current session.
+
+_Systemd_ manages so-called *_units_*, which are representations of system resources and services. This following list shows the unit types that _systemd_ can manage:
+
+service::
+  A service on the system, including instructions for starting, restarting, and stopping the service.
+
+socket::
+  A network socket associated with a service.
+
+device::
+  A device specifically managed with _systemd_.
+
+mount::
+  A mountpoint managed with _systemd_.
+
+automount::
+  A mountpoint automatically mounted on boot.
+  
+swap::
+  Swap space on the system.
+
+target::
+  A synchronization point for other units. Usually used to start enabled services on boot.
+
+path::
+  A path for path-based activation. For example, you can start services based on the state of a certain path, such as whether it exists or not.
+
+timer::
+  A timer to schedule activation of another unit.
+
+snapshot::
+  A snapshot of the current _systemd_ state. Usually used to rollback after making temporary changes to _systemd_.
+
+slice::
+  Restriction of resources through Linux Control Group nodes (cgroups).
+
+scope::
+  Information from _systemd_ bus interfaces. Usually used to manage external system processes.
+
+
+
+== Starting, stopping, and querying systemd services
+
+You can perform various management tasks to control _systemd_ services using the `systemctl` command. The following is a set of example commands to demonstrate how to use `systemctl` to manage _systemd_ services.
+
+[discrete]
+== Prerequisites
+
+You are logged in as a user with administrator-level permissions.
+
+[discrete]
+== Procedure
+
+The following commands control the `foo` service:
+
+* Activate a service immediately:
++
+----
+# systemctl start foo 
+----
+
+* Deactivate a service immediately:
++
+----
+# systemctl stop foo 
+----
+
+* Restart a service:
++
+----
+# systemctl restart foo 
+----
+
+* Show the status of a service including, whether it is running or not:
++
+----
+# systemctl status foo 
+----
+
+* Enable a service to be started on boot:
++
+----
+# systemctl enable foo 
+----
+
+* Disable a service to not start during boot:
++
+----
+# systemctl disable foo 
+----
+
+* Prevent a service from starting dynamically or even manually unless unmasked:
++
+----
+# systemctl mask foo 
+----
+
+* Check if a service is enabled or not:
++
+----
+# systemctl is-enabled foo
+----
+
+[discrete]
+=== Related Information
+
+* Run `man systemctl` for more details.
+
+
+== Modifying existing systemd services
+
+This example shows how to modify an existing service. Service modification are stored within `/etc/systemd/system`, in a single file or in a subdirectory named after the service. For example, this procedure modifies the `httpd` service.
+
+[discrete]
+=== Prerequisites
+
+* You are logged in as a user with administrator-level permissions.
+
+* You have a configured `httpd` server running through _systemd_.
+
+[discrete]
+=== Procedure
+
+. _Systemd_ services can be modified using the `systemctl edit` command.
++
+----
+# systemctl edit httpd.service
+----
++
+This creates an override file `/etc/systemd/system/httpd.service.d/override.conf` and opens it in your text editor. Anything you put into this file will be *added* to the existing service file.
+
+. Add your custom configuration. For example:
++
+----
+[Service]
+Restart=always
+RestartSec=30
+----
++
+To replace an option that can be set multiple times, it must cleared first, otherwise the override file will add the option a second time.
++
+----
+[Service]
+ExecStart=
+ExecStart=<new command>
+----
+
+. Save the file. _Systemd_ automatically loads the new service configuration.
+
+. Restart the `httpd` service:
++
+----
+# systemctl restart httpd
+----
+
+To completely replace (instead of just add to/modify) an existing service file, use `systemctl edit --full`, e.g.  `systemctl edit --full httpd.service`. This will create `/etc/systemctl/system/httpd.service`, which will be used instead of the existing service file.
+
+[discrete]
+=== Related Information
+
+* See link:#common-service-parameters[Common service parameters] for more information about the parameters used in this procedure.
+
+
+
+== Creating new systemd services
+
+This example shows how to create a unit file for a custom service. Custom unit files are located in `/etc/systemd/system/` and have a `.service` extension. For example, a custom `foo` service uses `/etc/systemd/system/foo.service` unit file.
+
+[discrete]
+=== Prerequisites
+
+* You are logged in as a user with administrator-level permissions.
+
+[discrete]
+=== Procedure
+
+This procedure creates a basic configuration file to control the `foo` service.
+
+. Create and edit the new configuration file:
++
+----
+# nano /etc/systemd/system/foo.service
+----
+
+. The next few steps describe each section its parameters to add to the file:
+
+.. The `[Unit]` section provides basic information about the service. The `foo` service uses the following parameters:
++
+`Description`::
+  A string describing the unit. _Systemd_ displays this description next to the unit name in the user interface. 
+`After`::
+  Defines a relationship with a second unit. If you activate the unit, _systemd_ activates it only after the second one. For example, the `foo` service might require network connectivity, which means the `foo` services specifies `network.target` as an `After=` condition. 
++
+The resulting `[Unit]` section looks like this:
++
+----
+[Unit]
+Description=My custom service
+After=network.target
+----
+
+.. The `[Service]` section provides instructions on how to control the service. The `foo` service uses the following parameters:
++
+`Type`::
+  Defines the type of _systemd_ service. In this example, the `foo` service is a `simple` service, which starts the service without any special consideration.
+`ExecStart`::
+  The command to run to start the service. This includes the full path to the command and arguments to modify the service.
++
+The resulting `[Service]` section looks like this:
++
+----
+[Service]
+Type=simple
+ExecStart=/usr/bin/sleep infinity
+----
+
+.. The `[Install]` section provides instructions on how _systemd_ installs the service. The `foo` service uses the following parameters:
++
+`WantedBy`::
+  Defines which service triggers the custom service if enabled with `systemctl enable`. This is mostly used for starting the custom service on boot. In this example, `foo.service` uses `multi-user.target`, which starts `foo.service` when _systemd_ loads `multi-user.target` on boot.
+
+. The full `foo.service` file contains the following contents:
++
+----
+[Unit]
+Description=My custom service
+After=network.target
+
+[Service]
+Type=simple
+ExecStart=/usr/bin/sleep infinity
+
+[Install]
+WantedBy=multi-user.target
+----
++
+Save the file.
+
+. To make _systemd_ aware of the new service, reload its service files
++
+----
+# systemctl daemon-reload
+----
+
+
+. Start the custom `foo` service:
++
+----
+# systemctl start foo
+----
+
+. Check the status of the service to ensure the service is running:
++
+----
+$ systemctl status foo
+● foo.service - My custom service
+   Loaded: loaded (/etc/systemd/system/foo.service; static; vendor preset: disabled)
+   Active: active (running) since Thu 2017-12-14 14:09:12 AEST; 6s ago
+ Main PID: 31837 (sleep)
+    Tasks: 1 (limit: 4915)
+   CGroup: /system.slice/foo.service
+           └─31837 /usr/bin/sleep infinity
+
+Dec 14 14:09:12 dansmachine systemd[1]: Started My custom service.
+----
+
+[discrete]
+=== Related Information
+
+* See link:#common-service-parameters[Common service parameters] for more information about the parameters used in this procedure.
+
+
+
+== Converting SysVinit services to systemd
+
+Older versions of Fedora use SysVinit scripts to manage services. This section provides some guidelines on how to convert a SysVinit script to a _systemd_ equivalent.
+
+[discrete]
+=== Prerequisites
+
+* You are logged in as a user with administrator-level permissions.
+
+* You have a custom SysVinit script to convert to a _systemd_ configuration.
+
+[discrete]
+=== Procedure
+
+. Identify the runlevels in your SysVinit script. This is usually defined with `chkconfig` directive in the commented section at the beginning of the script. For example, the following indicates the service is using runlevels 3, 4, and 5:
++
+----
+# chkconfig: 235 20 80
+----
++
+systemd uses targets instead of runlevels. Use the table in <<#converting-sysvinit-services>> to map the runlevels to targets. In this example, runlevels 2, 3, and 5 are all multi-user runlevels, so the _systemd_ service can use the following:
++
+----
+[Install]
+WantedBy=multi-user.target
+----
++
+If you enable the custom _systemd_ service to start at boot (`systemctl enable foo.service`), _systemd_ loads the service when loading the `multi-user.target` at boot time.
+
+. Identify the dependent services and targets. For example, if the custom service requires network connectivity, specify the `network.target` as a dependency:
++
+----
+[Unit]
+Description=My custom service
+After=network.target
+----
+
+. Identify the command used to start the service in the SysVinit script and convert this to the _systemd_ equivalent. For example, the script might contain a `start` function in the following format:
++
+[source,bash]
+----
+start() {
+  echo "Starting My Custom Service..."
+  /usr/bin/myservice -D
+}
+----
++
+In this example, the `/usr/bin/myservice` command is the custom service command set to daemonize with the `-D` option. Set the `ExecStart` parameter to use this command:
++
+----
+[Service]
+ExecStart=/usr/bin/myservice -D
+----
+
+. Check the SysVinit script to see if the service uses a special command to restart the service. For example, the script might contain a `reboot` function that reloads the service:
++
+[source,bash]
+----
+reboot() {
+  echo "Reloading My Custom Service..."
+  /usr/bin/myservice reload
+}
+----
++
+In this example, the `/usr/bin/myservice` command is the custom service command and reloads the service using the `reload` subcommand. Set the `ExecReload` parameter to use this command:
++
+----
+[Service]
+ExecReload=/usr/bin/myservice reload
+----
++
+Alternatively, you can omit `ExecReload` and use the default behavior, which kills the service and starts it again.
+
+. Check the SysVinit script to see if the service uses a special command to stop the service. For example, the script might contain a `stop` function that reloads the service:
++
+[source,bash]
+----
+reboot() {
+  echo "Stopping My Custom Service..."
+  /usr/bin/myservice shutdown
+}
+----
++
+In this example, the `/usr/bin/myservice` command is the custom service command and stop the service gracefully using the `shutdown` subcommand. Set the `ExecStop` parameter to use this command:
++
+----
+[Service]
+ExecStop=/usr/bin/myservice shutdown
+----
++
+Alternatively, you can omit `ExecStop` and use the default behavior, which kills the service.
+
+. Review the SysVinit script and identify any additional parameters or functions. Use _systemd_ parameters to replicate any identified SysVinit functions that might be relevant to your service.
+
+[discrete]
+=== Related Information
+
+* See link:#common-service-parameters[Common service parameters] for more information about the parameters used in this procedure.
+
+
+
+== Common service parameters
+
+=== Unit Parameters
+
+This section contains parameters you can use in the `[Unit]` section of a service. These parameters are common to other _systemd_ units.
+
+This list is a summarized version. For a full list of these parameters and their descriptions, run `man systemd.unit`.
+
+Description::
+  A free-form string describing the service. 
+
+Documentation::
+  A space-separated list of URIs referencing documentation for this service or its configuration. Accepted are only URIs of the following types: `http://`, `https://`, `file:`, `info:`, `man:`. 
+
+Requires::
+  Configures requirement dependencies on other services. If this service gets activated, the units listed here are activated too. If one of the dependent services fails to activate, _systemd_ does not start this service. This option may be specified more than once or you can specify multiple space-separated units.
+
+Wants::
+  Similar to `Requires`, except failed units do not have any effect on the service.
+
+BindsTo::
+  Similar to `Requires`, except stopping the dependent units also stops the service.
+
+PartOf::
+  Similar to `Requires`, except the stopping and restarting dependent units also stop and restart the service.
+
+Conflicts::
+  A space-separated list of unit names that, if running, cause the service not to run.
+
+Before, After::
+  A space-separated list of unit names that configures the ordering of dependencies between services.
+
+OnFailure::
+  A space-separated list of unit names that are activated when this service enters a failed state.
+
+=== Install Parameters
+
+This section contains parameters you can use in the `[Install]` section of a service. These parameters are common to other _systemd_ units.
+
+This list is a summarized version. For a full list of these parameters and their descriptions, run `man systemd.unit`.
+
+Alias::
+    A space-separated list of additional names this service shall be installed under. The names listed here must have the same suffix (i.e. type) as the service filename.
+
+RequiredBy, WantedBy::
+    Defines the service as dependent of another service. This usually define the target to trigger an enabled service to run. These options are analogous to the `Requires` and `Wants` in the `[Units]` section.
+
+Also::
+    Additional units to install or uninstall when this service is installed or uninstalled.
+
+=== Service Parameters
+
+This section contains parameters you can use in the `[Service]` section of a service unit. These parameters are specific only to _systemd_ service units.
+
+This list is a summarized version. For a full list of these parameters and their descriptions, run `man systemd.unit`.
+
+Type::
+  Configures the process start-up type for this service service:
++
+* `simple` - The service starts as the main process. This is the default.
+* `forking` - The service calls forked processes and run as part of the main daemon.
+* `oneshot` - Similar to `simple`, except the process must exit before _systemd_ starts follow-up services.
+* `dbus` - Similar to `simple`, except the daemon acquires a name of the D-Bus bus.
+* `notify` - Similar to `simple`, except the daemon sends a notification message using `sd_notify` or an equivalent call after starting up.
+* `idle` - Similar to `simple`, except the execution of the service is delayed until all active jobs are dispatched.
+
+RemainAfterExit::
+  A boolean value that specifies whether the service shall be considered active even if all its processes exited. Defaults to no.
+
+GuessMainPID::
+  A boolean value that specifies whether _systemd_ should guess the main PID of a service if it cannot be determined reliably. This option is ignored unless `Type=forking` is set and `PIDFile` is not set. Defaults to yes.
+
+PIDFile::
+  An absolute filename pointing to the PID file of this daemon. Use of this option is recommended for services where `Type=forking`. _Systemd_ reads the PID of the main process of the daemon after start-up of the service. _Systemd_ does not write to the file configured here, although it removes the file after the service has shut down. 
+
+BusName::
+  A D-Bus bus name to reach this service. This option is mandatory for services where `Type=dbus`.
+
+ExecStart::
+  The commands and arguments executed when the service starts.
+
+ExecStartPre, ExecStartPost::
+  Additional commands that are executed before or after the command in `ExecStart`.
+
+ExecReload::
+  The commands and arguments to execute when the service reloads.
+
+ExecStop::
+  The commands and arguments to execute when the service stops. 
+
+ExecStopPost::
+  Additional commands to execute after the service stops.
+
+RestartSec::
+  The time in seconds to sleep before restarting a service.
+
+TimeoutStartSec::
+  The time in seconds to wait for the service to start.
+
+TimeoutStopSec::
+  The time in seconds to wait for the service to stop.
+
+TimeoutSec::
+  A shorthand for configuring both `TimeoutStartSec` and `TimeoutStopSec` simultaneously. 
+
+RuntimeMaxSec::
+  A maximum time in seconds for the service to run. Pass `infinity` (the default) to configure no runtime limit.
+
+Restart::
+  Configures whether to restart the service when the service's process exits, is killed, or reaches a timeout:
++
+* `no` - The service will not be restarted. This is the default.
+* `on-success` - Restart only when the service process exits cleanly (exit code 0).
+* `on-failure` - Restart only when the service process does not exit cleanly (node-zero exit code).
+* `on-abnormal` - Restart if the process terminates with a signal or when a timeout occurs.
+* `on-abort` - Restart if the process exits due to an uncaught signal not specified as a clean exit status.
+* `always` - Always restart.
+
+
+
+== Mapping runlevels to targets
+
+_Systemd_ targets serve a similar purpose to SysVinit runlevels but act a little differently. Each target has a name instead of a number and each serves a specific purpose. _Systemd_ implements some targets by inheriting all of the services of another target and adding additional services to it. Some _systemd_ targets mimic the common sysvinit runlevels, which means you can switch targets with the familiar `telinit RUNLEVEL` command. The runlevels assigned a specific purpose on vanilla Fedora installs (0, 1, 3, 5, and 6) have a 1:1 mapping with a specific _systemd_ target.
+
+However, this is not the case for user-defined runlevels 2 and 4. To make use of those runlevels, create a new named _systemd_ target such as `/etc/systemd/system/$YOURTARGET` that takes one of the existing runlevels as a base, make a directory `/etc/systemd/system/$YOURTARGET.wants`, and then symlink the additional services to enable into that directory.
+
+The following is a mapping of SysVinit runlevels to _systemd_ targets.
+
+[cols="2,5,5",options="header"]
+.Runlevel to target mapping
+|===
+|Sysvinit Runlevel |systemd Target |Notes
+
+|0 |runlevel0.target, poweroff.target |Halt the system.
+
+|1, s, single |runlevel1.target, rescue.target |Single user mode.
+
+|2, 4 |runlevel2.target, runlevel4.target, multi-user.target
+|User-defined/Site-specific runlevels. By default, identical to 3.
+
+|3 |runlevel3.target, multi-user.target |Multi-user, non-graphical.
+Users can usually login via multiple consoles or via the network.
+
+|5 |runlevel5.target, graphical.target |Multi-user, graphical. Usually
+has all the services of runlevel 3 plus a graphical login.
+
+|6 |runlevel6.target, reboot.target |Reboot
+
+|emergency |emergency.target |Emergency shell
+|===
+
+
+
+== Mapping service commands
+
+The following table demonstrates the _systemd_ equivalent of SysVinit commands.
+
+NOTE: All recent versions of `systemctl` assume the `.service` suffix if left off the service name. For example, `systemctl start frobozz.service` is the same as `systemctl start frobozz`.
+
+[cols=",,",options="header",]
+|===
+|Sysvinit Command |systemd Command |Notes
+|`service frobozz start`|`systemctl start frobozz`|Used to start a service (not reboot persistent)
+
+|`service frobozz stop`|`systemctl stop frobozz`|Used to stop a service (not reboot persistent)
+
+|`service frobozz restart`|`systemctl restart frobozz`|Used to stop and then start a service
+
+|`service frobozz reload`|`systemctl reload frobozz`|When supported, reloads the config file without interrupting pending operations.
+
+|`service frobozz condrestart`|`systemctl condrestart frobozz`|Restarts if the service is already running.
+
+|`service frobozz status`|`systemctl status frobozz`|Tells whether a service is currently running.
+
+|`ls /etc/rc.d/init.d/`|`systemctl` or `systemctl list-unit-files --type=service` or +
+`ls /lib/systemd/system/\*.service /etc/systemd/system/*.service`|Used to list the services that can be started or stopped +
+Used to list all the services and other units
+
+|`chkconfig frobozz on`|`systemctl enable frobozz`|Turn the service on, for start at next boot, or other trigger.
+
+|`chkconfig frobozz off`|`systemctl disable frobozz`|Turn the service off for the next reboot, or any other trigger.
+
+|`chkconfig frobozz`|`systemctl is-enabled frobozz`|Used to check whether a service is configured to start or not in the current environment.
+
+|`chkconfig --list`|`systemctl list-unit-files --type=service` or `ls /etc/systemd/system/*.wants/`|Print a table of services that lists which runlevels each is configured on or off
+
+|`chkconfig --list \| grep 5:on`|`systemctl list-dependencies graphical.target`|Print a table of services that will be started when booting into graphical mode
+
+|`chkconfig frobozz --list`|`ls /etc/systemd/system/*.wants/frobozz.service`|Used to list what levels this service is configured on or off
+
+|`chkconfig frobozz --add`|`systemctl daemon-reload`|Used when you create a new service file or modify any configuration
+|===
+
+NOTE: All `/sbin/service` and `/sbin/chkconfig` commands listed in the table continue to work on _systemd_-based systems and are translated to native equivalents as necessary. The only exception is `chkconfig --list`.
+
+
+
+== Additional resources
+
+* http://www.freedesktop.org/wiki/Software/systemd[Project homepage]
+* http://0pointer.de/blog/[Lennart Poettering's blog] with lots of information about _systemd_. Lennart is the primary _systemd_ developer
+* http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions[freedesktop.org's _systemd_ FAQ]
+* http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks[freedesktop.org's _systemd_ Tips & Tricks]
+* http://fosdem.org/2011/interview/lennart-poettering.html[Interview with the developer]
+
+

modules/ROOT/pages/understanding-and-administering-systemd.adoc

@@ -1,38 +0,0 @@
-ifdef::context[:parent-context: {context}]
-:context: understanding-and-administering-systemd
-:source-highlighter: prettify
-
-[id='understanding-and-administering-systemd']
-= Understanding and administering systemd
-:toc:
-
-Learn the basic principles of the _systemd_ init system: how to configure it and use it to administer the system.
-
-include::{partialsdir}/con_understanding-systemd.adoc[leveloffset=+1]
-
-include::{partialsdir}/proc_starting-stopping-and-querying-systemd-services.adoc[leveloffset=+1]
-
-include::{partialsdir}/proc_modifying-existing-systemd-services.adoc[leveloffset=+1]
-
-include::{partialsdir}/proc_creating-new-systemd-services.adoc[leveloffset=+1]
-
-include::{partialsdir}/proc_converting-sysvinit-services.adoc[leveloffset=+1]
-
-include::{partialsdir}/ref_common-service-parameters.adoc[leveloffset=+1]
-
-include::{partialsdir}/ref_mapping-runlevel-to-targets.adoc[leveloffset=+1]
-
-include::{partialsdir}/ref_mapping-service-commands.adoc[leveloffset=+1]
-
-
-== Additional resources
-
-* http://www.freedesktop.org/wiki/Software/systemd[Project homepage]
-* http://0pointer.de/blog/[Lennart Poettering's blog] with lots of information about _systemd_. Lennart is the primary _systemd_ developer
-* http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions[freedesktop.org's _systemd_ FAQ]
-* http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks[freedesktop.org's _systemd_ Tips & Tricks]
-* http://fosdem.org/2011/interview/lennart-poettering.html[Interview with the developer]
-
-ifdef::parent-context[:context: {parent-context}]
-ifndef::parent-context[:!context:]
-

modules/ROOT/pages/upgrading-fedora-online.adoc

@@ -1,84 +1,57 @@
 = Upgrading Fedora using package manager
+ Ben Cotton; Kamil Páral;  Caleb McKee 
+:revnumber: F37, F38
+:revdate: 2022-05-04
+:category: Administration
+:tags: How-to  Upgrade 
+//:page-aliases: 
+
+[abstract]
+This page contains information explaining how to upgrade Fedora online using `dnf` (without the xref:dnf-system-upgrade.adoc[DNF system upgrade plugin]).
 
-This page contains information explaining how to upgrade Fedora online
-using `dnf` (without the xref:dnf-system-upgrade.adoc[DNF system upgrade plugin]).
 
 [WARNING]
 ====
-
 This is not a supported upgrade method. Read xref:upgrading.adoc[Upgrading to a new release of Fedora] to see a list of supported and tested upgrade methods. The steps included in the guide are *at your own risk*.
-
 ====
 
-[[upgrading-fedora-using-dnf-directly]]
 == Upgrading Fedora using dnf directly
 
-[[participate]]
 == Participate
 
-If you are upgrading using link:https://fedoraproject.org/wiki/DNF[DNF] and it shows any general dependency
-issues, please file them in http://bugzilla.redhat.com[Bugzilla]. But
-please read this page, all references pages and search the mailing list
-archives before filing bugs. And of course, please help keep this page
-updated.
+If you are upgrading using link:https://fedoraproject.org/wiki/DNF[DNF] and it shows any general dependency issues, please file them in http://bugzilla.redhat.com[Bugzilla]. But please read this page, all references pages and search the mailing list archives before filing bugs. And of course, please help keep this page updated.
 
 If you want to help make live upgrades work smoothly, join the
 link:SIGs/LiveUpgrade[Live Upgrade Special Interest Group].
 
-[[upgrading-across-multiple-releases]]
 == Upgrading across multiple releases
 
-If you need to upgrade across several releases, it is generally
-recommended to go one release at a time: for example, rather than going
-directly from Fedora 31 to Fedora 33, first go to Fedora 32 and then to Fedora 33. This tends to
-reduce the number of package dependency issues you may encounter. If you
-are upgrading from an link:End_of_life[End of life] release, please also
-see link:#eol[the end-of-life section].
+If you need to upgrade across several releases, it is generally recommended to go one release at a time: for example, rather than going directly from Fedora 31 to Fedora 33, first go to Fedora 32 and then to Fedora 33. This tends to reduce the number of package dependency issues you may encounter. If you are upgrading from an link:End_of_life[End of life] release, please also see link:#eol[the end-of-life section].
 
-[[instructions-to-upgrade-using-dnf]]
 == Instructions to upgrade using dnf
 
-[[backup-your-system]]
 === 1. Backup your system
 
-Backup any personal data to an external hard drive or to another
-machine. If there is some unrecoverable error that requires a fresh
-install, you don't want to lose any data.
+Backup any personal data to an external hard drive or to another machine. If there is some unrecoverable error that requires a fresh install, you don't want to lose any data.
 
-[[read-about-common-problems]]
 === 2. Read about common problems
 
-Further down in this page there is a list of common problems specific to
-dnf upgrades for specific versions. Some of them require attention
-before the upgrade.
+Further down in this page there is a list of common problems specific to dnf upgrades for specific versions. Some of them require attention before the upgrade.
 
-General advice on upgrading Fedora can be found on the link:https://docs.fedoraproject.org/en-US/quick-docs/upgrading/[Upgrading] page.
-You should also read the
-http://docs.fedoraproject.org/install-guide/[Installation Guide] and
-http://docs.fedoraproject.org/release-notes/[Release Notes] for the
-version you plan to upgrade to - they contain important information
-regarding upgrading issues. Finally, check the list of
-link:Common_bugs[Common bugs].
+General advice on upgrading Fedora can be found on the link:https://docs.fedoraproject.org/en-US/quick-docs/upgrading/[Upgrading] page. You should also read the http://docs.fedoraproject.org/install-guide/[Installation Guide] and http://docs.fedoraproject.org/release-notes/[Release Notes] for the version you plan to upgrade to - they contain important information regarding upgrading issues. Finally, check the list of link:Common_bugs[Common bugs].
 
-[[clean-stuff]]
 === 3. Clean Stuff
 
-Review and remove all .rpmsave and .rpmnew files before and after
-upgrading. (And if you have selinux enabled then remember to check
-security context if you move config files around.)
+Review and remove all .rpmsave and .rpmnew files before and after upgrading. (And if you have selinux enabled then remember to check security context if you move config files around.)
 
 TIP: *Find unused config files* + Merge and resolve the changes found by the following script: `dnf install rpmconf; rpmconf -a`. Now find and remove old config which nobody owns: `rpmconf -c`.
 
-Now is a good time to remove packages you don't use - especially
-non-standard packages.
+Now is a good time to remove packages you don't use - especially non-standard packages.
 
-TIP: *Find and review "unused" packages* + You can find packages not required by other packages with the tool `package-cleanup` from the `dnf-utils` package: `dnf install dnf-utils; package-cleanup --leaves`.
-These packages could be candidates for removal, but check to see whether you use them directly or if they are used by applications not backed by rpm packages. Remove them with `dnf remove package-name-and-version`.
-Another useful tool for cleaning up unused packages is `rpmreaper`. It's an ncurses application that lets you view rpm dependency graph and mark packages for deletion. Marking one package can make other packages leaf, which you can see immediately, so you don't have to run the tool several times to get rid of a whole sub-tree unused packages. Install with `dnf install rpmreaper`.
+TIP: *Find and review "unused" packages* + You can find packages not required by other packages with the tool `package-cleanup` from the `dnf-utils` package: `dnf install dnf-utils; package-cleanup --leaves`. These packages could be candidates for removal, but check to see whether you use them directly or if they are used by applications not backed by rpm packages. Remove them with `dnf remove package-name-and-version`. Another useful tool for cleaning up unused packages is `rpmreaper`. It's an ncurses application that lets you view rpm dependency graph and mark packages for deletion. Marking one package can make other packages leaf, which you can see immediately, so you don't have to run the tool several times to get rid of a whole sub-tree unused packages. Install with `dnf install rpmreaper`.
 
 TIP: *Find and review "lost" packages* + You can find orphaned packages (i.e. packages not in the repositories anymore) with `package-cleanup --orphans`. This will also show packages which have been partially uninstalled but where the "%postun" script failed.
 
-[[do-the-upgrade]]
 === 4. Do the upgrade
 
 If you have 3rd party repositories configured, you may need to adjust
@@ -175,7 +148,6 @@ in `/var/cache/dnf`.
 # dnf clean all
 ....
 
-[[upgrade-all-packages]]
 ==== Upgrade all packages
 
 CAUTION: *Never upgrade on battery power* + Never run the upgrade operation on battery power! Always connect to the mains, if using a laptop. However, if your system does have a battery, it's a good idea to ensure it's charged and connected in case of a power outage during the upgrade.
@@ -195,7 +167,6 @@ If it seems like you must remove a package with many dependencies, especially on
 
 If you are at all unsure in any way, ask for help on a mailing list, forum or IRC before removing packages.
 
-[[make-sure-fedora-is-upgraded]]
 === 5. Make sure Fedora is upgraded
 
 Distro-sync will usually take care of upgrades for the third party
@@ -229,7 +200,6 @@ For example
     "Office/Productivity" "System Tools"
 ....
 
-[[preparing-for-reboot]]
 === 6. Preparing for reboot
 
 Before booting you should usually install the bootloader from your new
@@ -251,7 +221,6 @@ cp --backup=numbered -a /boot/grub2/grub.cfg{,.bak} # create backup copy
 /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg # update config file
 ....
 
-[[cleanup-your-system]]
 === 7. Cleanup your system
 
 Again, cleanup your system as described in section 2. Also you might
@@ -262,26 +231,18 @@ files from older Fedora releases in the following directories:
 * /var/cache/mock
 * /var/lib/mock
 
-[[release-specific-notes]]
 == Release specific notes
 
-Note: the release-specific notes for link:End_of_life[End of life]
-releases are on the
-link:Upgrading_from_EOL_Fedora_using_package_manager[EOL packager
-manager upgrade page].
+Note: the release-specific notes for link:End_of_life[End of life] releases are on the
+link:Upgrading_from_EOL_Fedora_using_package_manager[EOL packager manager upgrade page].
 
-[[from-pre-release]]
 === From pre-release
 
-If you are upgrading to a final release from an Alpha, Beta, or release
-candidate, please see link:Upgrading_from_pre-release_to_final[Upgrading
-from pre-release to final].
+If you are upgrading to a final release from an Alpha, Beta, or release candidate, please see link:Upgrading_from_pre-release_to_final[Upgrading from pre-release to final].
 
-[[to-rawhide]]
 === To Rawhide
 
-See the link:Releases/Rawhide[Rawhide] release page for more information
-on Rawhide.
+See the link:Releases/Rawhide[Rawhide] release page for more information on Rawhide.
 
 ....
 # dnf upgrade
@@ -295,7 +256,6 @@ on Rawhide.
 # touch /.autorelabel
 ....
 
-[[fedora-31]]
 === Fedora 31
 Before running
 
@@ -311,12 +271,10 @@ dnf module reset libgit2 exa bat
 
 See link:https://bugzilla.redhat.com/show_bug.cgi?id=1747408[Bug 1747408].
 
-[[fedora-30]]
 === Fedora 30
 
 No special instructions. Follow the above instructions.
 
-[[fedora-29]]
 === Fedora 29
 
 No special instructions. Follow the above instructions.
@@ -324,18 +282,10 @@ No special instructions. Follow the above instructions.
 [[upgrading-from-legacy-end-of-life-eol-fedora-releases]]
 === Upgrading from legacy end of life (EOL) Fedora releases
 
-Note that Fedora strongly recommends against ever running an end-of-life
-release on any production system, or any system connected to the public
-internet, in any circumstances. You should never allow a production
-Fedora deployment to reach end-of-life in the first place.
+Note that Fedora strongly recommends against ever running an end-of-life release on any production system, or any system connected to the public internet, in any circumstances. You should never allow a production Fedora deployment to reach end-of-life in the first place.
 
-With that in mind, if you do have an end-of-life release installed on a
-system you cannot just discard or re-deploy, you can attempt to upgrade
-it, though this is a less-tested and less-supported operation.
+With that in mind, if you do have an end-of-life release installed on a system you cannot just discard or re-deploy, you can attempt to upgrade it, though this is a less-tested and less-supported operation.
 
-For detailed instructions on upgrades from EOL releases, please read
-link:Upgrading_from_EOL_Fedora_using_package_manager[Upgrading from EOL
-Fedora using package manager].
+For detailed instructions on upgrades from EOL releases, please read link:Upgrading_from_EOL_Fedora_using_package_manager[Upgrading from EOL Fedora using package manager].
 
-See a typo, something missing or out of date, or anything else which can be
-improved? Edit this document at https://pagure.io/fedora-docs/quick-docs.
+See a typo, something missing or out of date, or anything else which can be improved? Edit this document at https://pagure.io/fedora-docs/quick-docs.

modules/ROOT/pages/upgrading.adoc

@@ -1,23 +1,26 @@
-[[ch-Upgrading]]
 = Upgrading to a new release of Fedora
+ Jun Aruga; Kamil Páral; Ben Cotton
+:revnumber: F37, F38
+:revdate: 2022-09-14
+:category: Administration
+:tags: How-to  Upgrade 
+//:page-aliases: 
+
+
 
 [IMPORTANT]
 ====
-
 . Make your system *fully up-to-date* before attempting system upgrade to a new Fedora release.
 . Be sure to *back-up your data* before upgrading your Fedora system in the event something breaks and leaves your system unusable.
 . Read the xref:fedora:release-notes:index.adoc[Release Notes] carefully before attempting an upgrade.
-
 ====
 
 
-[[sect-upgrading-to-the-next-fedora-workstation-release]]
 == Upgrading to the next Fedora Workstation release
+
 [NOTE]
 ====
-
 This is the recommended upgrade method for the Fedora Workstation.
-
 ====
 
 
@@ -37,13 +40,11 @@ _Download_ in the _"Fedora Linux <number> Available"_ section to begin upgrading
 the new release.
 
 
-[[sect-upgrading-using-the-dnf-system-upgrade-plugin]]
 == Upgrading using the DNF System Upgrade plugin
+
 [NOTE]
 ====
-
 This is the recommended upgrade method for all other Fedora installations.
-
 ====
 
 This method is used to a upgrade Fedora installation using the command-line.
@@ -51,33 +52,28 @@ It is also used to troubleshoot issues with packages preventing the graphical me
 
 For instructions on upgrading with the DNF system upgrade plugin, refer to the xref:dnf-system-upgrade.adoc[DNF System Upgrade] page.
 
-[[sect-upgrading-to-major-versions-in-silverblue]]
 == Upgrading between major versions in Fedora Silverblue
+
 [NOTE]
 ====
-
 Upgrading between major versions (such as from Fedora 36 to Fedora 37) can be completed using the Software application. Alternatively, Silverblue can be upgraded between major versions using the `ostree` command..
-
 ====
+
 For instructions on upgrading Fedora Silverblue Host, refer to the link:++https://docs.fedoraproject.org/en-US/fedora-silverblue/updates-upgrades-rollbacks/#upgrading++[dedicated page].
 
-[[sect-can-i-upgrade-between-fedora-releases-using-only-dnf]]
 == Can I upgrade between Fedora releases using only DNF?
+
 [WARNING]
 ====
-
 This is not a supported upgrade method.
-
 ====
 
 Upgrading between Fedora releases without the xref:dnf-system-upgrade.adoc[DNF System Upgrade plugin] or <<sect-upgrading-to-the-next-fedora-workstation-release,GNOME Software>> are not tested by the Fedora QA team, and are therefore not supported by the community. You can follow xref:upgrading-fedora-online.adoc[Upgrading Fedora using package manager], but you're doing that *at your own risk*.
 
-[[sect-upgrade-from-prerelease-to-final-release]]
 == Upgrading from pre-release (beta) to final public release (stable)
 
 If you are using a pre-release of Fedora, you shouldn't need to do anything to get the final public release, other than updating packages as they become available. You can use `sudo dnf upgrade` or wait for desktop notification. When the pre-release is released as final, the `fedora-repos` packages will be updated and your `updates-testing` repository will be disabled. Once this happens (on the release day), it is highly recommended to run `sudo dnf distro-sync` in order to align package versions with the current release.
 
-[[sect-how-do-i-upgrade-to-rawhide-and-branched]]
 == How do I upgrade to Rawhide and Branched?
 
 link:++https://fedoraproject.org/wiki/Releases/Rawhide++[Rawhide] and link:++https://fedoraproject.org/wiki/Releases/Branched++[Branched] are the development releases of Fedora.
@@ -88,7 +84,6 @@ See the link:++https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle++[Fedora
 
 Upgrading to a Branched release or to Rawhide can be done using xref:dnf-system-upgrade.adoc[DNF System Upgrade].
 
-[[sect-upgrading-from-end-of-life-releases]]
 == Can I upgrade from an End Of Life (EOL) release?
 
 Fedora strongly discourages running an end-of-life release on any production system, or any system connected to the public internet.
@@ -97,7 +92,6 @@ You should never allow a production Fedora deployment to reach end-of-life in th
 With that in mind, if you do have an end-of-life release installed on a system you cannot just discard or re-deploy, you upgrade using xref:dnf-system-upgrade.adoc[DNF System Upgrade].
 Note that upgrades are only tested from the two previous releases.
 
-[[sect-upgrading-using-the-fedora-installer-anaconda]]
 === Upgrading using the Fedora installer (anaconda)?
 
 Fedora releases up to Fedora 17 included upgrade functionality in the Fedora installer, anaconda.
@@ -109,7 +103,6 @@ After you select storage devices the installer should offer you the option to up
 
 [IMPORTANT]
 ====
-
 If your installation is located on a 'specialized' storage device, be sure to configure and select it.
-
 ====
+

modules/ROOT/pages/using-nested-virtualization-in-kvm.adoc

@@ -2,11 +2,11 @@
 Fedora Documentation Team
 :revnumber: F36 onwards
 :revdate: 2023-02-21
+:category: Administration
+:tags: How-to Workstation Virtualization
 
 // Optional  free form useful additional information as comment
 
-:category: Administration
-:tags: How-to Workstation Virtualization
 
 [abstract]
 //------

modules/ROOT/pages/wine.adoc

@@ -1,19 +1,20 @@
-= Wine
+= Wine – Running Windows applications in the Fedora GUI
+ Héctor H. Louzao Pozueco;  Ankur Sinha; Akshata Khedekar
+:revnumber: unknown
+:revdate: 2022-10-03
+:category: Virtualisation
+:tags: How-to  Windows Wine 
+//:page-aliases: 
 
-http://winehq.org/[Wine] is an open source implementation of the Windows
-API on top of X and OpenGL.
+[abstract]
+http://winehq.org/[Wine] is an open source implementation of the Windows API on top of X and OpenGL.
 
-Wine emulates the Windows runtime environment by translating Windows 
-system calls into POSIX-compliant system calls, recreating the directory
-structure of Windows systems, and providing alternative implementations 
-of Windows system libraries, system services through https://wiki.winehq.org/Wineserver[wineserver].
+Wine emulates the Windows runtime environment by translating Windows  system calls into POSIX-compliant system calls, recreating the directory structure of Windows systems, and providing alternative implementations of Windows system libraries, system services through https://wiki.winehq.org/Wineserver[wineserver].
 
 == Packages
 
-Fedora's Wine packages are split up to allow for smaller installations.
-The `wine` meta package will bring with it the most important components
-of Wine.
-Expert users may want to pick specific components from the list
+Fedora's Wine packages are split up to allow for smaller installations. The `wine` meta package will bring with it the most important components
+of Wine. Expert users may want to pick specific components from the list
 https://packages.fedoraproject.org/pkgs/wine/[here].
 The current versions of the Wine packages can also be seen on the https://packages.fedoraproject.org/pkgs/wine/wine/[Fedora packages application].
 

modules/ROOT/pages/zoom.adoc

@@ -1,5 +1,12 @@
 = Installing Zoom on Fedora
- 
+ N.B.; The Fedora Documentation Team
+:revnumber: unknown 
+:revdate: 2022
+:category: Administration
+:tags: How-to Video  
+//:page-aliases: 
+
+
 == Description
 https://www.zoom.us[Zoom Video Communications]. Inc. is an American communications technology company headquartered in San Jose, California.
 It provides videotelephony and online chat services through a cloud-based peer-to-peer software platform and is used for teleconferencing, telecommuting, distance education, and social relations.