Fix typographical errors in partials

Assisted-by: OpenCode:gpt-oss-120b
This commit is contained in:
Brett Weir 2026-07-12 23:51:25 -07:00
commit 152643145e
6 changed files with 11 additions and 11 deletions

View file

@ -1,9 +1,9 @@
// Text excerpt about installing fail2ban
// consumer postinstallation-tasks.adoc (main), hetzner-dc.adoc
//
Open Cockpit in your desktops browser
Open Cockpit in your desktop's browser
`https://host.example.com:9090`. Accept the security warning of your browser. Cockpit uses a self signed certificate.
If you disabled root access during installation (recommended), login as root is not possible.
If you disabled root access during installation (recommended), logging in as root is not possible.
Login with your administrative user account. At the top you will see a warning that the Web Console is running with limited permissions. Enable administrator access so that all administrative privileges are automatically available after login.

View file

@ -1,6 +1,6 @@
// Text excerpt about installing fail2ban
// consumer postinstallation-tasks.adoc (main), hetzner-dc.adoc
There are several ways to improve the security of Cockpit axxess. All of them are based on permanently withdrawing access to Cockpit in the firewall. So, reconfigure the firewall permanently.
There are several ways to improve the security of Cockpit access. All of them are based on permanently withdrawing access to Cockpit in the firewall. So, reconfigure the firewall permanently.
[source,]
----
@ -37,6 +37,6 @@ c. Use a secure local proxy
+
* Install Cockpit on your local Fedora workstation or on a lab server shielded by a firewall. Configure this instance to access any of your remote Cockpit instances using Cockpits remote administration capability. It uses a protected ssh connection in the public network.
+
* In the upper left corner of Cockpit you will see the name of the logged in user and the desktop rsp. the (local) lab server name, along with an expand icon. This opens a box where you can switch to another server or add a new one.
* In the upper left corner of Cockpit you will see the name of the logged-in user and the (local) lab server name, along with an expand icon. This opens a box where you can switch to another server or add a new one.
+
* The `Add new host` link opens a simple form to fill in hostname and user. Use your administrative user name on the (remote) server. And you can assign a color. Select automatic login via ssh keyfile. Cockpit will create one for you if none exists or otherwise uses an existing one. For a newly created key, Cockpit installs the public key on the remote server, too.

View file

@ -1,9 +1,9 @@
// Text excerpt about setting up a comfortable, key-based user login
// consumer postinstallation-tasks.adoc (main), hetzner-dc.adoc
//
A key file for SSH saves the annoying and error-prone typing of the hopefully secure and sufficiently long password. Additionally, you may prepare your local desktop to use a short name instead of having to type in a complete FQN hostname.
An SSH key file saves the otherwise annoying and errorprone typing of the hopefully secure and sufficiently long password. Additionally, you may prepare your local desktop to use a short name instead of having to type in a complete FQN hostname.
a. On your desktop (Linux or macOS), create a SSH keyfile if not already available. It should not be secured by password to enable automatic processing.
a. On your desktop (Linux or macOS), create an SSH keyfile if not already available. It should not be secured by password to enable automatic processing.
+
[source,]
----

View file

@ -24,7 +24,7 @@ b. Reload the sshd daemon
c. Test that everything works as expected
+
* Is an authorised user able to log in?
* Is an authorized user able to log in?
* Are other users rejected with the message "Permission denied (publickey,gssapi-keyex,gssapi-with-mic)"?
* If this does not work and/or other users are able to log in with a password besides your known authorized user,
** install the latest updates.

View file

@ -1,6 +1,6 @@
// Text excerpt about installing fail2ban
// consumer postinstallation-tasks.adoc (main), hetzner-dc.adoc
The software monitors the log files for authentication errors. In case of multiple retries from the same IP address, it reconfigures the firewall on the fly to block the source IP. This is to prevent brute force methods for cracking passwords and bots checking for weak passwords. However, a system administrator may also lock himself out, if they happen to make a mistake. Therefore, you can exclude destinct IP addresses, e.g. the administrators desktop, from blocking.
The software monitors the log files for authentication errors. In case of multiple retries from the same IP address, it reconfigures the firewall on the fly to block the source IP. This is to prevent bruteforce methods for cracking passwords and bots checking for weak passwords. However, a system administrator may also lock himself out if a mistake is made. Therefore, you can exclude distinct IP addresses, e.g., the administrator's desktop, from blocking.
a. Installation of the software
+
@ -23,7 +23,7 @@ bantime = 6600
backend = auto
# The main configuration file defines all services but
# deactivates them by default. We have to activate those neeeded
# deactivates them by default. We have to activate those needed
[sshd]
enabled = true
----
@ -38,4 +38,4 @@ d. Control in the log
[source,]
----
[…]# tail -f /var/log/fail2ban.log
----
----

View file

@ -4,7 +4,7 @@
Fedora includes a tool, dnf-automatic, which supports several modes of update automation:
do not apply, notify admin, apply and notify admin, apply without notification. In particular, alternatives 2 and 3 are definitely worth considering. A general principle might be: Alternative 2 is the minimum choice for almost any system, alternative 3 is not at all suitable for critical systems that must not fail under any circumstances.
We recommend to install at least alternative 2:
We recommend installing at least alternative 2:
[source,]
----
[…]# dnf install dnf-automatic