From 72b91a966ee59333502845ae491a4919f1bdb3c3 Mon Sep 17 00:00:00 2001
From: Peter Boy <pb@resdigita.de>
Date: May 10 2021 10:53:50 +0000
Subject: Updatet content after review by nirik, added new article


---

diff --git a/docs/modules/ROOT/nav.adoc b/docs/modules/ROOT/nav.adoc
index 40f249b..609a2db 100644
--- a/docs/modules/ROOT/nav.adoc
+++ b/docs/modules/ROOT/nav.adoc
@@ -1,5 +1,6 @@
 * xref:index.adoc[Welcome]
 * xref:server-installation.adoc[Server Installation]
+** xref:server-installation-sbc.adoc[Server on Single Board Computers]
 * xref:server-administration.adoc[Server Administration]
 ** xref:sysadmin-postinstall.adoc[Post Installation Tasks]
 ** xref:sysadmin-cockpit.adoc[Cockpit]
diff --git a/docs/modules/ROOT/pages/server-installation-sbc.adoc b/docs/modules/ROOT/pages/server-installation-sbc.adoc
new file mode 100644
index 0000000..983aa05
--- /dev/null
+++ b/docs/modules/ROOT/pages/server-installation-sbc.adoc
@@ -0,0 +1,36 @@
+= Fedora Server on Single Boad Computers - Raspberry Pi & Co.
+Peter Boy; Jan Kuparinen
+:page-authors: {author}, {author_2}
+
+[NOTE]
+====
+Collection of ideas. __**– Outline proposal –**__ Please comment on server mailing list!
+==== 
+[sidebar]
+****
+Author: N.N | Creation Date: N/A | Last update: N/A | Related Fedora Version(s): 34
+****
+
+== How it works
+
+* No installation procedure as described in the generic installation guide
+* A pre-installed server disk image is transferred to the SBC boot device, typically an SD or an eMMC card. 
+* The process is easy. During the transfer, the image is adapted to the specific hardware and an initial user-specific configuration is injected.
+
+[WARNING]
+====
+When choosing a model, look for the availability of open source drivers 
+====
+
+== Why using Single Board Computer Server?
+
+* Affordable price / performance ratio for many typical tasks in the SOHO sector
+* Examples of use: Family email server, e-book library for family and friends. This does not need a full-blown NAS
+* Low power consumption, environmentally friendly
+
+== Step by step instruction
+
+* Download image file
+* Install installation software
+* Transfer file system
+* ...
\ No newline at end of file
diff --git a/docs/modules/ROOT/pages/server-installation.adoc b/docs/modules/ROOT/pages/server-installation.adoc
index 96aca92..a962469 100644
--- a/docs/modules/ROOT/pages/server-installation.adoc
+++ b/docs/modules/ROOT/pages/server-installation.adoc
@@ -4,7 +4,7 @@ Peter Boy; Jan Kuparinen
 
 [NOTE]
 ====
-Beta 1 Please comment on server mailing list!
+Status: RC – ready for publication 
 ==== 
 [sidebar]
 ****
@@ -15,7 +15,8 @@ Fedora Server Edition uses the same installation procedure as most of the other 
 
 image::serverinstall-summaryscreen.png[Anaconda Installation Summary]
 
-However, there are some peculiarities and differences for Fedora Server Edition that should be noted in deviation or in addition to the explanations over there. These are outlined in the following sections.
+While Fedora Server Edition uses the same package set as all Fedora editions, the defaults are different and more
+taylored to a server install. These defaults are outlined in the following sections, and can of cour.se be overridden either in kickstart or the installer itself
 
 And of course, the installation planning depends in many details on the target environment. As an example, a virtual machine installation requires a different approach to storage than a bare metal installation. Thus, in the former case, one does not need to worry about a RAID system. 
 
@@ -49,7 +50,9 @@ You may reinforce that rationale even further and create another small partition
 
 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.
 
-On a server, this is usually not optimal. Rather, several disks should store data redundantly in order to maintain operation in the event of a hardware failure. Manual partitioning is necessary for this. Select "Installation Destination" in the Summary Screen, the options "Custom" and "Advanced Custom (Blivet-GUI)" both enable manual partitioning.
+On a server, this is usually not optimal. Rather, several disks should store data redundantly in order to maintain operation in the event of a hardware failure. Technically, you will prefer to configure a RAID system. For details you may hava a look at the Fedora https://docs.fedoraproject.org/en-US/fedora/f34/install-guide/install/Installing_Using_Anaconda/#sect-installation-gui-manual-partitioning-swraid[Installation Guide]. 
+
+Manual partitioning is necessary for this. Select "Installation Destination" in the Summary Screen, the options "Custom" and "Advanced Custom (Blivet-GUI)" both enable manual partitioning.
 
 On Bios boot machines and hard disks with a maximum of 2 TB, select the comfortable "Custom" option.
 
@@ -69,7 +72,7 @@ Hard disks larger than 2 TB require a GPT disk label and an additional BIOSboot 
 
 By default the installation program creates a DHCP configuration for each network interface. In case of an active connection it is automatically started during boot. 
 
-In case of servers it is often preferrable to configure a static IP address. This ensures a valid network connection at system start even if the DHCP server is defective. Select the network interface, activate the IPv4 rsp. IPv6 tab. Switch from DHCP to manual and add an IP spezification.
+In case of servers it is often preferrable to configure a static IP address. This ensures a valid network connection at system start even if the DHCP server is defective. Select the network interface, activate the IPv4 rsp. IPv6 tab. Switch from DHCP to manual and add an IP specification.
 
 Note: Post F32 NetworkManager stores the configuration in __/etc/NetworkManager/connected_systems/*.network__!
 
@@ -77,7 +80,7 @@ Note: Post F32 NetworkManager stores the configuration in __/etc/NetworkManager/
 
 As a minimum, you must set a password for the ROOT account. Select 'Root Password' below 'USER SETTINGS' and enter an appropriate password. For security reasons, ssh login as root is only allowed with key-file, but the account is not locked. It is not advisable to modify these security settings! This way, secure root access via ssh key file is still an option and, in an emergency, also with a password via an attached console or Cockpit login. 
 
-If there is no direkt terminal access available create a fall back user (e.g. hostmin) with password authentication active and administration privilege (group wheel & sudo su). In such a case, this is the only way to get access to the server after the reboot! And even later, it is the only way to get administrative access if for some reason the private key file is not available.
+If there is no direct terminal access available create a fall back user (e.g. hostmin) with password authentication active and administration privilege (group wheel & sudo su). In such a case, this is the only way to get access to the server after the reboot! And even later, it is the only way to get administrative access if for some reason the private key file is not available.
 
 == Time zone and time synchronization
 
diff --git a/docs/modules/ROOT/pages/sysadmin-postinstall.adoc b/docs/modules/ROOT/pages/sysadmin-postinstall.adoc
index 1f2df4c..945da3e 100644
--- a/docs/modules/ROOT/pages/sysadmin-postinstall.adoc
+++ b/docs/modules/ROOT/pages/sysadmin-postinstall.adoc
@@ -4,7 +4,7 @@ Peter Boy; Jan Kuparinen
 
 [NOTE]
 ====
-Beta Version (1)! Please comment on server mailing list
+Status: RC – Ready for publication 
 ==== 
 [sidebar]
 ****
@@ -15,11 +15,11 @@ These post-install tasks are all optional. The system administrator has to decid
 
 == 1. Set up root login via key file
 
-According to the default installation, SSH login is only possible using an RSA key file. However, the setup cannot be done as part of the installation. If this step is omitted, logging in as root via SSH is not possible.
+According to the default installation, SSH login is only possible using an SSH key file. However, the setup cannot be done as part of the installation. If this step is omitted, logging in as root via SSH is not possible.
 
-=== Prepare a pair of private / public RSA keys
+=== Prepare a pair of private / public keys
 
-This step is to be performed only if a pair of RSA keys does not already exist. It is best to create the key in the _.ssh_ directory of the desktop user. It should not be secured by password to enable automatic processing. The naming with leading 'id_' und trailing '_rsa' is just a common convention, yet helpful.
+This step is to be performed only if a pair of keys does not already exist. It is best to create the key in the _.ssh_ directory of the desktop user. It should not be secured by password to enable automatic processing. The naming with leading 'id_' und trailing types abbreviation, e.g. '_rsa' is just a common convention, yet helpful.
 
 a. Execute on the local desktop 
 +
@@ -27,17 +27,21 @@ a. Execute on the local desktop
 ----
 […]# mkdir ~/.ssh 
 […]# cd ~/.ssh 
-[…]# ssh-keygen -t rsa -b 4096  -C "root@example.com" -f id_<outputkeyfile>_rsa
+[…]# ssh-keygen -t rsa -b 4096  -C "root@example.com" -f <outputkeyfile>
 ----
 
+Although the type rsa is widely used, you may adjust your key type accordingly.
+
 === Transfer and Install the Public Key onto the Server
 
+You normally use _ssh-copy-id_ to install the public key on the server. However, this requires a password login, which was disabled for root during installation. Therefore, a detour is now required. 
+
 a. Log in to your server via sftp using the unprivileged administration account and transfer the public key file
 +
 [source,]
 ----
 […]# sftp hostmin@example.com
-sftp> put ~/.ssh/id_<outputkeyfile>_rsa.pub
+sftp> put ~/.ssh/<outputkeyfile>.pub
 sftp> quit
 ----
 
@@ -55,7 +59,7 @@ c. On the server acquire root permissions, move the key file and adjust permissi
 […]$ sudo su -
 […]# mkdir /root/.ssh 
 […]# cd  /root/.ssh
-[…]# mv /home/hostmin/id_<outputkeyfile>_rsa.pub /root/.ssh/authorized_keys
+[…]# mv /home/hostmin/<outputkeyfile>.pub /root/.ssh/authorized_keys
 […]# chown  -R  root.root  /root/.ssh
 […]# chmod 700 /root/.ssh
 […]# chmod 600 ~/.ssh/*
@@ -68,10 +72,10 @@ a. On your local workstation test key file based access:
 +
 [source,]
 ----
-[…]# ssh -i ~/.ssh/id_<outputkeyfile>_rsa  root@example.com
+[…]# ssh -i ~/.ssh/<outputkeyfile>  root@example.com
 ----
 +
-adjust file and domain name as appropriate.
+adjust file, file type, and domain name as appropriate.
 
 a. To simplify access create a configuration file on your desktop and define a short name for the connection:
 +
@@ -89,7 +93,7 @@ Host myhost
         ForwardX11 no
         Port 22
         KeepAlive yes
-        IdentityFile ~/.ssh/id_<outputkeyfile>_rsa
+        IdentityFile ~/.ssh/<outputkeyfile>
 ----
 +
 again, replace names accordingly.
@@ -191,12 +195,12 @@ b. Just in case IPv6 is configured as local only (fe80::....) or not static, you
 +
 [source,]
 ----
-[…]# nmnmcli con mod 'enp3s0' ipv6.method manual \
+[…]# nmcli con mod 'enp3s0' ipv6.method manual \
   ipv6.addresses <YOUR_IPv6_PREFIX>::2/64 \
   ipv6.gateway fe80::1 \
   ipv6.dns "2a01:4f8:xx:yy::zzz:8888 2a01:4f8:xx:yy::zzz:9999"
-[…]# nmnmcli con up 'enp3s0'
-[…]# nmnmcli con reload
+[…]# nmcli con up 'enp3s0'
+[…]# nmcli con reload
 ----
 +
 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.
@@ -213,12 +217,12 @@ c. Optionally reconfigure IPv4 as static. But make sure the IPv6 address works a
 +
 [source,]
 ----
-[…]# nmnmcli con mod 'enp3s0' ipv4.method manual \
+[…]# nmcli con mod 'enp3s0' ipv4.method manual \
   ipv4.addresses <YOUR_IPv4>/27 \
   ipv4.gateway <GATEWAY> \
   ipv6.dns "<DNS1_IPv4> <DNS2_IPv4>"
-[…]# nmnmcli con up'enp3s0'
-[…]# nmnmcli con reload
+[…]# nmcli con up'enp3s0'
+[…]# nmcli con reload
 ----
 +
 Again, don't forget to adjust names, prefix, and DNS IP addresses and check connectivity from your local workstation:
@@ -279,6 +283,8 @@ c. Test that everything works as expected
 
 The software monitors the log files for authentication errors.  In case of multiple retries from the same IP address, the source IP gets blocked by the firewall. This is to prevent brute force methods for cracking passwords and bots checking for weak passwords. However, if an error occurs in the authentication process, a system administrator may also lock himself out.
 
+If you disabled system users password Login in the previous step so sshd only allows keys, you may skip this section. There will be nothing to log in this regard anymore.
+
 a. Installation of the software and the required Postfix
 +
 [source,]

