Compare commits
12 commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 1c0e701d60 | |||
| 80e7273e5f | |||
| ab015451d0 | |||
| 347423205d | |||
| ef3d51cdb8 | |||
| 4604338e92 | |||
|
b62a65b2f8 | ||
|
5997723964 | ||
| 565ec22597 | |||
| cf3dd11c02 | |||
| 391c06bcab | |||
| b4db67e754 |
10 changed files with 72 additions and 56 deletions
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: fedora
|
||||
version: rawhide
|
||||
version: f33
|
||||
# Navigation is in the main 'fedora' component:
|
||||
# https://pagure.io/fedora-docs/release-docs-home
|
||||
|
|
|
|||
36
build.sh
36
build.sh
|
|
@ -3,25 +3,30 @@
|
|||
image="docker.io/antora/antora"
|
||||
cmd="--html-url-extension-style=indexify site.yml"
|
||||
|
||||
if [ "$(uname)" == "Darwin" ]; then
|
||||
if uname | grep -iwq darwin; then
|
||||
# Running on macOS.
|
||||
# Let's assume that the user has the Docker CE installed
|
||||
# which doesn't require a root password.
|
||||
echo ""
|
||||
echo "This build script is using Docker container runtime to run the build in an isolated environment."
|
||||
echo ""
|
||||
docker run --rm -it -v $(pwd):/antora $image $cmd
|
||||
docker run --rm -it -v "$(pwd):/antora" "${image}" ${cmd}
|
||||
|
||||
elif [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then
|
||||
elif uname | grep -iq linux; then
|
||||
# Running on Linux.
|
||||
# there isn't an antora/aarch64 container, antora can be installed locally
|
||||
# Check whether podman is available, else faill back to docker
|
||||
# which requires root.
|
||||
|
||||
if [ -f /usr/bin/podman ]; then
|
||||
if [ -f /usr/local/bin/antora ]; then
|
||||
/usr/local/bin/antora "${cmd}"
|
||||
elif uname -m | grep -iwq aarch64; then
|
||||
echo "no antora/aarch64 container try just \`npm install -g @antora/cli @antora/site-generator-default\`"
|
||||
elif [ -f /usr/bin/podman ]; then
|
||||
echo ""
|
||||
echo "This build script is using Podman to run the build in an isolated environment."
|
||||
echo ""
|
||||
podman run --rm -it -v $(pwd):/antora:z $image $cmd
|
||||
podman run --rm -it -v "$(pwd):/antora:z" "${image}" ${cmd}
|
||||
|
||||
elif [ -f /usr/bin/docker ]; then
|
||||
echo ""
|
||||
|
|
@ -29,18 +34,19 @@ elif [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then
|
|||
echo ""
|
||||
|
||||
if groups | grep -wq "docker"; then
|
||||
docker run --rm -it -v $(pwd):/antora:z $image $cmd
|
||||
else
|
||||
docker run --rm -it -v "$(pwd):/antora:z" "${image}" ${cmd}
|
||||
else
|
||||
echo "You might be asked for your password."
|
||||
echo "You can avoid this by adding your user to the 'docker' group,"
|
||||
echo "but be aware of the security implications."
|
||||
echo "See https://docs.docker.com/install/linux/linux-postinstall/"
|
||||
echo ""
|
||||
echo "This build script is using $runtime to run the build in an isolated environment. You might be asked for your password."
|
||||
echo "You can avoid this by adding your user to the 'docker' group, but be aware of the security implications. See https://docs.docker.com/install/linux/linux-postinstall/."
|
||||
echo ""
|
||||
sudo docker run --rm -it -v $(pwd):/antora:z $image $cmd
|
||||
fi
|
||||
sudo docker run --rm -it -v "$(pwd):/antora:z" "${image}" ${cmd}
|
||||
fi
|
||||
else
|
||||
echo ""
|
||||
echo "Error: Container runtime haven't been found on your system. Fix it by:"
|
||||
echo "$ sudo dnf install podman"
|
||||
exit 1
|
||||
echo "Error: Container runtime haven't been found on your system. Fix it by:"
|
||||
echo "$ sudo dnf install podman"
|
||||
exit 1
|
||||
fi
|
||||
fi
|
||||
|
|
|
|||
|
|
@ -3,13 +3,13 @@
|
|||
include::{partialsdir}/entities.adoc[]
|
||||
|
||||
[[ch-Wayland]]
|
||||
= The Wayland Display Server
|
||||
Wayland is a display server which was (at the time of writing) introduced as the default display server in GNOME. It is said that Wayland will eventually replace X11 as the default display server on Linux and many distributions have begun implementation of Wayland. Wayland is a more modern display server and has a smaller code base currently. Wayland is still under development, and there are still applications and behaviours that don't work as expected, you may find that some applications have not been updated to work properly in Wayland and currently the only way these applications will run is using Xorg instead of Wayland. This includes some legacy system applications and games.
|
||||
= The Wayland Protocol
|
||||
|
||||
Wayland is a display server protocol which was (at the time of writing) introduced as the default in GNOME. It is said that Wayland will eventually replace X11 as the default display server on Linux and many distributions have begun implementation of Wayland. Wayland is a more modern protocol and has a smaller code base currently. Wayland is still under development, and there are still applications and behaviours that don't work as expected, you may find that some applications have not been updated to work properly in Wayland and currently the only way these applications will run is using Xorg instead of Wayland. This includes some legacy system applications and games.
|
||||
|
||||
.Wayland in Fedora
|
||||
Wayland is enabled by default in the GNOME Desktop. You can choose to run GNOME in X11 by choosing the Gnome on xorg option in the session chooser on the login screen. Currently KDE still uses X11 and although there is a plasma-wayland session available, it is not considered stable or bugfree at this time.
|
||||
|
||||
.Determining whether you are using Wayland
|
||||
== Determining whether you are using Wayland
|
||||
One way to determine if you're running in Wayland, is to check the value of the variable $WAYLAND_DISPLAY. To do this type:
|
||||
|
||||
[source,bash]
|
||||
|
|
@ -34,9 +34,9 @@ There is also a legacy X11 server provided with Wayland for compatibility purpos
|
|||
$ xlsclients
|
||||
----
|
||||
|
||||
There is also the `lg` (looking glass) tool in GNOME that will allow you to determine what display server a window is using. To do this, you run the application by typing `lg` in the run dialog or at the command line, select "`Windows`" in the upper right corner of the tool, and click on the application name (or open window) you want to know about. If the window is running in wayland it will say "`MetaWindowWayland`" and if it is running in X11 it will say "`MetaWindowX11`".
|
||||
There is also the `lg` (looking glass) tool in GNOME that will allow you to determine which protocol a specific window is using. To do this, you run the application by typing `lg` in the run dialog or at the command line, select "`Windows`" in the upper right corner of the tool, and click on the application name (or open window) you want to know about. If the window is running in wayland it will say "`MetaWindowWayland`" and if it is running in X11 it will say "`MetaWindowX11`".
|
||||
|
||||
.Additional Resources
|
||||
== Additional Resources
|
||||
To find out more about Wayland, please see the following website:
|
||||
|
||||
https://wayland.freedesktop.org/
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
:BZURL: link:https://pagure.io/fedora-docs/system-administrators-guide/issues[https://pagure.io/]
|
||||
:HOLDER: Red Hat, Inc. and others
|
||||
:MAJOROS: Fedora
|
||||
:MAJOROSVER: Fedora 32
|
||||
:MAJOROSVER: Fedora 33
|
||||
:OSORG: The Fedora Project
|
||||
:PKGOS: 32
|
||||
:PKGOS: 33
|
||||
:PRODUCT: Fedora Documentation
|
||||
:PRODVER: Rawhide
|
||||
:PRODVER: 33
|
||||
:YEAR: 2020
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@ include::{partialsdir}/entities.adoc[]
|
|||
|
||||
[[ch-OpenSSH]]
|
||||
= OpenSSH
|
||||
:toc:
|
||||
|
||||
indexterm:[OpenSSH]
|
||||
`SSH` (Secure Shell) is a protocol which facilitates secure communications between two systems using a client-server architecture and allows users to log into server host systems remotely. Unlike other remote communication protocols, such as `FTP`, `Telnet`, or [command]#rlogin#, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords.
|
||||
|
||||
|
|
@ -132,7 +134,7 @@ In order to perform tasks described in this section, you must have superuser pri
|
|||
indexterm:[SSH protocol,configuration files]
|
||||
There are two different sets of configuration files: those for client programs (that is, [command]#ssh#, [command]#scp#, and [command]#sftp#), and those for the server (the [command]#sshd# daemon).
|
||||
indexterm:[SSH protocol,configuration files,system-wide configuration files]indexterm:[SSH protocol,configuration files,user-specific configuration files]
|
||||
System-wide SSH configuration information is stored in the `/etc/ssh/` directory as described in xref:OpenSSH.adoc#table-ssh-configuration-configs-system[System-wide configuration files]. User-specific SSH configuration information is stored in `~/.ssh/` within the user's home directory as described in xref:OpenSSH.adoc#table-ssh-configuration-configs-user[User-specific configuration files].
|
||||
System-wide SSH configuration information is stored in the `/etc/ssh/` directory as described in xref:table-ssh-configuration-configs-system[System-wide configuration files]. User-specific SSH configuration information is stored in `~/.ssh/` within the user's home directory as described in xref:table-ssh-configuration-configs-user[User-specific configuration files].
|
||||
|
||||
[[table-ssh-configuration-configs-system]]
|
||||
.System-wide configuration files
|
||||
|
|
@ -219,7 +221,7 @@ Someone could be eavesdropping on you right now (man-in-the-middle attack)!
|
|||
It is also possible that the RSA host key has just been changed.
|
||||
----
|
||||
|
||||
To prevent this, you can backup the relevant files from the `/etc/ssh/` directory (see xref:OpenSSH.adoc#table-ssh-configuration-configs-system[System-wide configuration files] for a complete list), and restore them whenever you reinstall the system.
|
||||
To prevent this, you can backup the relevant files from the `/etc/ssh/` directory (see xref:table-ssh-configuration-configs-system[System-wide configuration files] for a complete list), and restore them whenever you reinstall the system.
|
||||
|
||||
[[s2-ssh-configuration-requiring]]
|
||||
=== Requiring SSH for Remote Connections
|
||||
|
|
@ -262,7 +264,7 @@ If you are working on a system other than a new default installation, check that
|
|||
|
||||
To be able to use [command]#ssh#, [command]#scp#, or [command]#sftp# to connect to the server from a client machine, generate an authorization key pair by following the steps below. Note that keys must be generated for each user separately.
|
||||
|
||||
{MAJOROSVER} uses SSH Protocol 2 and RSA keys by default (see xref:OpenSSH.adoc#s2-ssh-versions[Protocol Versions] for more information).
|
||||
{MAJOROSVER} uses SSH Protocol 2 and RSA keys by default (see xref:s2-ssh-versions[Protocol Versions] for more information).
|
||||
|
||||
.Do not generate key pairs as root
|
||||
[IMPORTANT]
|
||||
|
|
@ -405,7 +407,7 @@ ssh-copy-id -i ~/.ssh/id_ecdsa.pub USER@hostname
|
|||
+
|
||||
This will copy the content of `~/.ssh/id_ecdsa.pub` into the `~/.ssh/authorized_keys` on the machine to which you want to connect. If the file already exists, the keys are appended to its end.
|
||||
|
||||
See xref:OpenSSH.adoc#s3-ssh-configuration-keypairs-agent[Configuring ssh-agent] for information on how to set up your system to remember the passphrase.
|
||||
See xref:s3-ssh-configuration-keypairs-agent[Configuring ssh-agent] for information on how to set up your system to remember the passphrase.
|
||||
|
||||
.Never share your private key
|
||||
[IMPORTANT]
|
||||
|
|
@ -750,7 +752,7 @@ HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
|
|||
|
||||
. On user's systems. remove keys belonging to hosts from the `~/.ssh/known_hosts` file if the user has previously logged into the host configured above. When a user logs into the host they should no longer be presented with the warning about the hosts authenticity.
|
||||
|
||||
To test the host certificate, on a client system, ensure the client has set up the global `/etc/ssh/known_hosts` file, as described in xref:OpenSSH.adoc#proc-Trusting_the_Host_Signing_Key[Trusting the Host Signing Key], and that the server's public key is not in the `~/.ssh/known_hosts` file. Then attempt to log into the server over SSH as a remote user. You should not see a warning about the authenticity of the host. If required, add the [option]`-v` option to the SSH command to see logging information.
|
||||
To test the host certificate, on a client system, ensure the client has set up the global `/etc/ssh/known_hosts` file, as described in xref:proc-Trusting_the_Host_Signing_Key[Trusting the Host Signing Key], and that the server's public key is not in the `~/.ssh/known_hosts` file. Then attempt to log into the server over SSH as a remote user. You should not see a warning about the authenticity of the host. If required, add the [option]`-v` option to the SSH command to see logging information.
|
||||
|
||||
[[sec-Creating_SSH_Certificates_for_Authenticating_Users]]
|
||||
==== Creating SSH Certificates for Authenticating Users
|
||||
|
|
@ -833,7 +835,7 @@ drwx------. 3 user1 user1 4096 May 7 12:37 ..
|
|||
-rw-r--r--. 1 user1 user1 421 May 7 12:37 id_rsa.pub
|
||||
----
|
||||
+
|
||||
See xref:OpenSSH.adoc#s2-ssh-configuration-keypairs[Using Key-based Authentication] for more examples of key generation and for instructions on setting the correct directory permissions.
|
||||
See xref:s2-ssh-configuration-keypairs[Using Key-based Authentication] for more examples of key generation and for instructions on setting the correct directory permissions.
|
||||
|
||||
. The chosen public key must be copied to the server designated as the CA, in order to be signed. The secure copy command can be used to do this, the command has the following format:
|
||||
+
|
||||
|
|
@ -852,7 +854,7 @@ admin@ca-server.example.com's password:
|
|||
id_rsa.pub 100% 421 0.4KB/s 00:00
|
||||
----
|
||||
+
|
||||
If you have configured the client system to trust the host signing key as described in xref:OpenSSH.adoc#proc-Trusting_the_Host_Signing_Key[Trusting the Host Signing Key] then you should not see a warning about the authenticity of the remote host.
|
||||
If you have configured the client system to trust the host signing key as described in xref:proc-Trusting_the_Host_Signing_Key[Trusting the Host Signing Key] then you should not see a warning about the authenticity of the remote host.
|
||||
|
||||
. On the CA server, sign the user's public key. For example, as `root`:
|
||||
+
|
||||
|
|
|
|||
|
|
@ -399,8 +399,7 @@ In order to enable signing of externally built modules, the tools listed in the
|
|||
|===
|
||||
|Tool|Provided by Package|Used on|Purpose
|
||||
|[command]#openssl#|[package]*openssl*|Build system|Generates public and private X.509 key pair
|
||||
|[command]#sign-file#|[package]*kernel-devel*|Build system|Perl script used to sign kernel modules
|
||||
|[command]#perl#|[package]*perl*|Build system|Perl interpreter used to run the signing script
|
||||
|[command]#sign-file#|[package]*kernel-devel*|Build system|C application used to sign kernel modules
|
||||
|[command]#mokutil#|[package]*mokutil*|Target system|Optional tool used to manually enroll the public key
|
||||
|[command]#keyctl#|[package]*keyutils*|Target system|Optional tool used to display public keys in the system key ring
|
||||
|===
|
||||
|
|
@ -617,18 +616,18 @@ There are no extra steps required to prepare your kernel module for signing. You
|
|||
~]#{nbsp}make -C /usr/src/kernels/$(uname -r) M=$PWD modules
|
||||
----
|
||||
|
||||
. Sign your kernel module with your private key. This is done with a Perl script. Note that the script requires that you provide both the files that contain your private and the public key as well as the kernel module file that you want to sign.
|
||||
. Sign your kernel module with your private key. This is done with a C application. Note that the application requires that you provide both the files that contain your private and the public key as well as the kernel module file that you want to sign.
|
||||
+
|
||||
[subs="attributes"]
|
||||
----
|
||||
~]#{nbsp}perl /usr/src/kernels/$(uname -r)/scripts/sign-file \
|
||||
~]#{nbsp}/usr/src/kernels/$(uname -r)/scripts/sign-file \
|
||||
sha256 \
|
||||
my_signing_key.priv \
|
||||
my_signing_key_pub.der \
|
||||
my_module.ko
|
||||
----
|
||||
|
||||
Your kernel module is in ELF image format and this script computes and appends the signature directly to the ELF image in your `my_module.ko` file. The [command]#modinfo# utility can be used to display information about the kernel module's signature, if it is present. For information on using the utility, see xref:Working_with_Kernel_Modules.adoc#sec-Displaying_Information_About_a_Module[Displaying Information About a Module].
|
||||
Your kernel module is in ELF image format and this application computes and appends the signature directly to the ELF image in your `my_module.ko` file. The [command]#modinfo# utility can be used to display information about the kernel module's signature, if it is present. For information on using the utility, see xref:Working_with_Kernel_Modules.adoc#sec-Displaying_Information_About_a_Module[Displaying Information About a Module].
|
||||
|
||||
Note that this appended signature is not contained in an ELF image section and is not a formal part of the ELF image. Therefore, tools such as [command]#readelf# will not be able to display the signature on your kernel module.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ GRUB 2 reads its configuration from the `/boot/grub2/grub.cfg` file on tradition
|
|||
|
||||
The GRUB 2 configuration file, `grub.cfg`, is generated during installation, or by invoking the [application]*/usr/sbin/grub2-mkconfig* utility, and is automatically updated by [command]#grubby# each time a new kernel is installed. When regenerated manually using [application]*grub2-mkconfig*, the file is generated according to the template files located in `/etc/grub.d/`, and custom settings in the `/etc/default/grub` file. Edits of `grub.cfg` will be lost any time [application]*grub2-mkconfig* is used to regenerate the file, so care must be taken to reflect any manual changes in `/etc/default/grub` as well.
|
||||
|
||||
Normal operations on `grub.cfg`, such as the removal and addition of new kernels, should be done using the [command]#grubby# tool and, for scripts, using [command]#new-kernel-pkg# tool. If you use [command]#grubby# to modify the default kernel the changes will be inherited when new kernels are installed. For more information on [command]#grubby#, see xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool[Making Persistent Changes to a GRUB 2 Menu Using the grubby Tool].
|
||||
Normal operations on `grub.cfg`, such as the removal and addition of new kernels, should be done using the [command]#grubby# tool and, for scripts, using [command]#new-kernel-pkg# tool. If you use [command]#grubby# to modify the default kernel the changes will be inherited when new kernels are installed. For more information on [command]#grubby#, see xref:#sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool[Making Persistent Changes to a GRUB 2 Menu Using the grubby Tool].
|
||||
|
||||
The `/etc/default/grub` file is used by the [command]#grub2-mkconfig# tool, which is used by `anaconda` when creating `grub.cfg` during the installation process, and can be used in the event of a system failure, for example if the boot loader configurations need to be recreated. In general, it is not recommended to replace the `grub.cfg` file by manually running `grub2-mkconfig` except as a last resort. Note that any manual changes to `/etc/default/grub` require rebuilding the `grub.cfg` file.
|
||||
|
||||
|
|
@ -59,11 +59,11 @@ For information on using [application]*Dracut*, see xref:kernel-module-driver-co
|
|||
|
||||
Changes to the GRUB 2 menu can be made temporarily at boot time, made persistent for a single system while the system is running, or as part of making a new GRUB 2 configuration file.
|
||||
|
||||
* To make non-persistent changes to the GRUB 2 menu, see xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Making_Temporary_Changes_to_a_GRUB_2_Menu[Making Temporary Changes to a GRUB 2 Menu].
|
||||
* To make non-persistent changes to the GRUB 2 menu, see xref:#sec-Making_Temporary_Changes_to_a_GRUB_2_Menu[Making Temporary Changes to a GRUB 2 Menu].
|
||||
|
||||
* To make persistent changes to a running system, see xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool[Making Persistent Changes to a GRUB 2 Menu Using the grubby Tool].
|
||||
* To make persistent changes to a running system, see xref:#sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool[Making Persistent Changes to a GRUB 2 Menu Using the grubby Tool].
|
||||
|
||||
* For information on making and customizing a GRUB 2 configuration file, see xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Customizing_the_GRUB_2_Configuration_File[Customizing the GRUB 2 Configuration File].
|
||||
* For information on making and customizing a GRUB 2 configuration file, see xref:#sec-Customizing_the_GRUB_2_Configuration_File[Customizing the GRUB 2 Configuration File].
|
||||
|
||||
[[sec-Making_Temporary_Changes_to_a_GRUB_2_Menu]]
|
||||
== Making Temporary Changes to a GRUB 2 Menu
|
||||
|
|
@ -89,7 +89,7 @@ linux16 /vmlinuz-4.2.0-1.fc23.x86_64 root=/dev/mapper/fedora-root ro rd.md=
|
|||
|
||||
The [option]`rhgb` and [option]`quiet` parameters can be removed in order to enable system messages.
|
||||
|
||||
These settings are not persistent and apply only for a single boot. To make persistent changes to a menu entry on a system, use the [command]#grubby# tool. See xref:Working_with_the_GRUB_2_Boot_Loader.adoc#bh-Adding_and_Removing_Arguments_from_a_GRUB_Menu_Entry[Adding and Removing Arguments from a GRUB Menu Entry] for more information on using [command]#grubby#.
|
||||
These settings are not persistent and apply only for a single boot. To make persistent changes to a menu entry on a system, use the [command]#grubby# tool. See xref:#bh-Adding_and_Removing_Arguments_from_a_GRUB_Menu_Entry[Adding and Removing Arguments from a GRUB Menu Entry] for more information on using [command]#grubby#.
|
||||
|
||||
[[sec-Making_Persistent_Changes_to_a_GRUB_2_Menu_Using_the_grubby_Tool]]
|
||||
== Making Persistent Changes to a GRUB 2 Menu Using the grubby Tool
|
||||
|
|
@ -199,6 +199,16 @@ title=Fedora (4.2.0-1.fc23.x86_64) 23 (Workstation Edition)
|
|||
|
||||
See the `grubby(8)` manual page for more command options.
|
||||
|
||||
.Adding a new entry with additionnal kernel arguments
|
||||
To add a new entry with the default kernel but with additionnal kernel arguments and make it the default entry, use:
|
||||
|
||||
[subs="macros"]
|
||||
----
|
||||
~]# grubby --add-kernel $(grubby --default-kernel) --copy-default --args=crashkernel=128M --title "Default kernel with kdump support" --make-default
|
||||
----
|
||||
|
||||
In this example, we set the `crashkernel=128M` argument for kdump support.
|
||||
|
||||
[[sec-Customizing_the_GRUB_2_Configuration_File]]
|
||||
== Customizing the GRUB 2 Configuration File
|
||||
|
||||
|
|
@ -428,7 +438,7 @@ Alternatively, if you want to keep the files in the `/etc/grub2.d/` directory, m
|
|||
[[sec-GRUB_2_Password_Protection]]
|
||||
== GRUB 2 Password Protection
|
||||
|
||||
GRUB 2 supports both plain-text and encrypted passwords in the GRUB 2 template files. To enable the use of passwords, specify a superuser who can reach the protected entries. Other users can be specified to access these entries as well. Menu entries can be password-protected for booting by adding one or more users to the menu entry as described in xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Setting_Up_Users_and_Password_Protection_Specifying_Menu_Entries[Setting Up Users and Password Protection, Specifying Menu Entries]. To use encrypted passwords, see xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Password_Encryption[Password Encryption].
|
||||
GRUB 2 supports both plain-text and encrypted passwords in the GRUB 2 template files. To enable the use of passwords, specify a superuser who can reach the protected entries. Other users can be specified to access these entries as well. Menu entries can be password-protected for booting by adding one or more users to the menu entry as described in xref:#sec-Setting_Up_Users_and_Password_Protection_Specifying_Menu_Entries[Setting Up Users and Password Protection, Specifying Menu Entries]. To use encrypted passwords, see xref:#sec-Password_Encryption[Password Encryption].
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
|
|
@ -606,7 +616,7 @@ This method completely removes all GRUB 2 configuration files and system setting
|
|||
~]#{nbsp}grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
|
||||
----
|
||||
|
||||
. Now follow the procedure in xref:Working_with_the_GRUB_2_Boot_Loader.adoc#sec-Reinstalling_GRUB_2[Reinstalling GRUB 2] to restore GRUB2 on the `/boot/` partition.
|
||||
. Now follow the procedure in xref:#sec-Reinstalling_GRUB_2[Reinstalling GRUB 2] to restore GRUB2 on the `/boot/` partition.
|
||||
|
||||
[[sec-GRUB_2_over_a_Serial_Console]]
|
||||
== GRUB 2 over a Serial Console
|
||||
|
|
@ -631,7 +641,7 @@ To make persistent changes to a menu entry on a system, use the [command]#grubby
|
|||
~]# grubby --remove-args="rhgb quiet" --args=console=ttyS0,115200 --update-kernel=DEFAULT
|
||||
----
|
||||
|
||||
The [option]`--update-kernel` parameter also accepts the keyword `ALL` or a comma separated list of kernel index numbers. See xref:Working_with_the_GRUB_2_Boot_Loader.adoc#bh-Adding_and_Removing_Arguments_from_a_GRUB_Menu_Entry[Adding and Removing Arguments from a GRUB Menu Entry] for more information on using [command]#grubby#.
|
||||
The [option]`--update-kernel` parameter also accepts the keyword `ALL` or a comma separated list of kernel index numbers. See xref:#bh-Adding_and_Removing_Arguments_from_a_GRUB_Menu_Entry[Adding and Removing Arguments from a GRUB Menu Entry] for more information on using [command]#grubby#.
|
||||
|
||||
If required to build a new GRUB 2 configuration file, add the following two lines in the `/etc/default/grub` file:
|
||||
|
||||
|
|
@ -672,7 +682,7 @@ console=pass:attributes[{blank}]_ttyS0,9600n8_
|
|||
|
||||
Where [option]`console=ttyS0` is the serial terminal to be used, [option]`9600` is the baud rate, [option]`n` is for no parity, and [option]`8` is the word length in bits. A much higher baud rate, for example `115200`, is preferable for tasks such as following log files.
|
||||
|
||||
For more information on serial console settings, see xref:Working_with_the_GRUB_2_Boot_Loader.adoc#bh-Installable_and_External_Documentation[Installed Documentation]
|
||||
For more information on serial console settings, see xref:#bh-Installable_and_External_Documentation[Installed Documentation]
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -767,9 +777,9 @@ Note that in GRUB 2, resetting the password is no longer performed in single-use
|
|||
|
||||
Two procedures for resetting the `root` password are shown here:
|
||||
|
||||
* xref:Working_with_the_GRUB_2_Boot_Loader.adoc#proc-Resetting_the_Root_Password_Using_an_Installation_Disk[Resetting the Root Password Using an Installation Disk] takes you to a shell prompt, without having to edit the grub menu. It is the shorter of the two procedures and it is also the recommended method. You can use a server boot disk or a netinstall installation disk.
|
||||
* xref:#proc-Resetting_the_Root_Password_Using_an_Installation_Disk[Resetting the Root Password Using an Installation Disk] takes you to a shell prompt, without having to edit the grub menu. It is the shorter of the two procedures and it is also the recommended method. You can use a server boot disk or a netinstall installation disk.
|
||||
|
||||
* xref:Working_with_the_GRUB_2_Boot_Loader.adoc#proc-Resetting_the_Root_Password_Using_rd.break[Resetting the Root Password Using rd.break] makes use of [command]#rd.break# to interrupt the boot process before control is passed from `initramfs` to `systemd`. The disadvantage of this method is that it requires more steps, includes having to edit the GRUB menu, and involves choosing between a possibly time consuming SELinux file relabel or changing the SELinux enforcing mode and then restoring the SELinux security context for `/etc/shadow/` when the boot completes.
|
||||
* xref:#proc-Resetting_the_Root_Password_Using_rd.break[Resetting the Root Password Using rd.break] makes use of [command]#rd.break# to interrupt the boot process before control is passed from `initramfs` to `systemd`. The disadvantage of this method is that it requires more steps, includes having to edit the GRUB menu, and involves choosing between a possibly time consuming SELinux file relabel or changing the SELinux enforcing mode and then restoring the SELinux security context for `/etc/shadow/` when the boot completes.
|
||||
|
||||
[[proc-Resetting_the_Root_Password_Using_an_Installation_Disk]]
|
||||
.Resetting the Root Password Using an Installation Disk
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
:experimental:
|
||||
include::{partialsdir}/entities.adoc[]
|
||||
|
||||
|
|
@ -198,7 +197,7 @@ Be careful to escape the glob expressions when passing them as arguments to a [c
|
|||
DNF searches only package names when using glob expressions. To search for a version of a package, include a dash and part of the version number as follows:
|
||||
|
||||
----
|
||||
~]# dnf search kernel*-4*
|
||||
~]# dnf list kernel*-4*
|
||||
Last metadata expiration check performed 2:46:09 ago on Thu May 14 23:23:51 2015.
|
||||
Installed Packages
|
||||
kernel.x86_64 4.0.0-1.fc22 @System
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
#!/bin/sh
|
||||
|
||||
if [ "$(uname)" == "Darwin" ]; then
|
||||
if [ "$(uname)" = "Darwin" ]; then
|
||||
# Running on macOS.
|
||||
# Let's assume that the user has the Docker CE installed
|
||||
# which doesn't require a root password.
|
||||
echo "The preview will be available at http://localhost:8080/"
|
||||
docker run --rm -v $(pwd):/antora:ro -v $(pwd)/nginx.conf:/etc/nginx/conf.d/default.conf:ro -p 8080:80 nginx
|
||||
docker run --rm -v "$(pwd):/antora:ro" -v "$(pwd)/nginx.conf:/etc/nginx/conf.d/default.conf:ro" -p 8080:80 nginx
|
||||
|
||||
elif [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then
|
||||
elif [ "$(expr substr "$(uname -s)" 1 5)" = "Linux" ]; then
|
||||
# Running on Linux.
|
||||
# Fedora Workstation has python3 installed as a default, so using that
|
||||
echo ""
|
||||
|
|
|
|||
6
site.yml
6
site.yml
|
|
@ -1,12 +1,12 @@
|
|||
site:
|
||||
title: Local Preview
|
||||
start_page: fedora:system-administrators-guide:index
|
||||
start_page: fedora:system-administrators-guide:index.adoc
|
||||
content:
|
||||
sources:
|
||||
- url: .
|
||||
branches: HEAD
|
||||
- url: https://pagure.io/fedora-docs/release-docs-home.git
|
||||
branches: master
|
||||
branches: f33
|
||||
ui:
|
||||
bundle:
|
||||
url: https://asamalik.fedorapeople.org/ui-bundle.zip
|
||||
|
|
@ -18,5 +18,5 @@ output:
|
|||
destinations:
|
||||
- provider: archive
|
||||
runtime:
|
||||
pull: true
|
||||
fetch: true
|
||||
cache_dir: ./cache
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue