Merge pull request 'fixed all typos' (#17) from pombas_n/documentation:main into main

Reviewed-on: linux/documentation#17
2026-09-29 08:30:12 +02:00
commit 1d526bd5ff
@@ -1,9 +1,9 @@
 # Overview

 This is the collection of all Linux related documentation.
-The documentation is build via a gitea runner and hosted via gitea-pages. The content is accessible at: https://linux.psi.ch 
+The documentation is built via a gitea runner and hosted via gitea-pages. The content is accessible at: https://linux.psi.ch 

-To change stuff, simply edit the the Markdown files and push to the git repository. The rendered page will update a few seconds afterwards (Don't forget to refresh your browser cache for the page!). 
+To change stuff, simply edit the Markdown files and push to the git repository. The rendered page will update a few seconds afterwards (Don't forget to refresh your browser cache for the page!). 

 To test locally:
 ```
@@ -2,7 +2,7 @@

 Access for the `root` user can be limited to be only allowed from certain bastion hosts.

-By default this is enabled except for a few networks, see [reponsible Puppet code](https://gitea.psi.ch/puppet/puppet/src/branch/preprod/code/modules/profile/manifests/networking/params.pp) for details.
+By default this is enabled except for a few networks, see [responsible Puppet code](https://gitea.psi.ch/puppet/puppet/src/branch/preprod/code/modules/profile/manifests/networking/params.pp) for details.

 You may alternatively control the use of bastion hosts yourself by setting in Hiera the boolean value `aaa::user_bastions`.

@@ -16,7 +16,7 @@ aaa::radius_servers: [ 'nps01.psi.ch', 'nps02.psi.ch' ]
 aaa::radius_timeout: 60
 ```

-Beside this, ensure that `ChallengeResponseAuthentication yes` is set correctly in your sshd config (this is the default configuration - so if no changes where configured to sshd this should be ok!).
+Beside this, ensure that `ChallengeResponseAuthentication yes` is set correctly in your sshd config (this is the default configuration - so if no changes were configured to sshd this should be ok!).

 Prerequisite for this is, that your server can reach the RADIUS servers (in the example nps01.psi.ch and nps02.psi.ch) and that you received a shared secret from the RADIUS admin.
 (at the time of writing the RADIUS server are supported by group 9521)
@@ -2,7 +2,7 @@


 ## Extra Configuration
-Custom configration to the sshd config file can be added via the `ssh_server::extra_config` key. The config will be added at the end of the `/etc/ssh/sshd_config` file.
+Custom configuration to the sshd config file can be added via the `ssh_server::extra_config` key. The config will be added at the end of the `/etc/ssh/sshd_config` file.

 ### Force Command

@@ -8,7 +8,7 @@ aaa::sudo_rules:
   - 'telegraf ALL=(root) NOPASSWD: /usr/lib/telegraf/scripts/nxserver_report.sh'
 ```

-If the rules should be grouped in seperate files in /etc/sudoers.d, you can use the following syntax:
+If the rules should be grouped in separate files in /etc/sudoers.d, you can use the following syntax:

 ```yaml
 aaa::sudoersd:
@@ -16,7 +16,7 @@ aaa::users:
  - '+:muster_h:LOCAL'
 ```

-Note that administrative users (see below) always have normal access without being explicitely listed in `aaa::users`.
+Note that administrative users (see below) always have normal access without being explicitly listed in `aaa::users`.

 ## Allow Access for External, Global, Experiment or Service Accounts
 - `aaa::allow_external_accounts: true` allows for external accounts
@@ -39,7 +39,7 @@ If AD changes should be reflected rather soonish, then change to
 ```
 aaa::sssd_cache_timeout: 300
 ```
-but please do not lower the renewal interwal to such values as it causes quite some constant traffic and load to the AD and the node itself. The renewal value is not applied if it is bigger than the timeout. You may also explicitely disable it with
+but please do not lower the renewal interval to such values as it causes quite some constant traffic and load to the AD and the node itself. The renewal value is not applied if it is bigger than the timeout. You may also explicitly disable it with
 ```yaml
 aaa::sssd_cache_renewal_interval: null
 ```
@@ -30,7 +30,7 @@ mta::myhostname: 'foobar.psi.ch'

 ## Sending Emails Via An Other SMTP Relay

-If your machine is in the default network zone (i.e. PSI intranet) sending via a differnet mail gateway than the default can be done like this:
+If your machine is in the default network zone (i.e. PSI intranet) sending via a different mail gateway than the default can be done like this:

 ```yaml
 base::enable_mta: true
@@ -38,7 +38,7 @@ mta::relays:
  'default': 'test-smtp-relay.psi.ch'
 ```

-Wether the email is accepted by the mail relay depends on the relays configuration. Contact the relay admin what the rules for his gateway are.
+Whether the email is accepted by the mail relay depends on the relays configuration. Contact the relay admin what the rules for his gateway are.


 ## Configure Server as Mail Relay
@@ -1,6 +1,6 @@
 # Permanent Kerberos with gssproxy and Password Keytab

-If there are accounts which run software permamently e.g. used for data collection and shall always be able to write to Kerberos protected network shares, there you may provide the `gssproxy` service with a password keytab.
+If there are accounts which run software permanently e.g. used for data collection and shall always be able to write to Kerberos protected network shares, there you may provide the `gssproxy` service with a password keytab.
 After Kerberos for NFS and CIFS is handled transparently and there is no need to `kinit`, renew and anything like this because that is handled transparently in the background by `gssproxy` automatically.

 !!! warning Attention
@@ -28,7 +28,7 @@ for mac in $(bob node list-macs $OLD_FQDN); do bob node add-mac $NEW_FQDN $mac;

 In Hiera ensure that a host specific configuration file exists for the FQDN with the same content as for the old hostname.

-## Acutal Hostname Change
+## Actual Hostname Change

 On the node as `root` run

@@ -28,7 +28,7 @@ In Hiera you can select this option with
 networking::setup: auto
 ```

-And what does NetworkManager actually do by default? It attemps automatic configuration on all interfaces (DHCP, SLAAC). Additionally the user may add desired connections. This might be Wifi, VPN, but also normal Ethernet. Automatic configuration is only attempted if there is no such specific configuration.
+And what does NetworkManager actually do by default? It attempts automatic configuration on all interfaces (DHCP, SLAAC). Additionally the user may add desired connections. This might be Wifi, VPN, but also normal Ethernet. Automatic configuration is only attempted if there is no such specific configuration.

 DNS configuration as such is learned by autoconfiguration/manual connection configuration and will not be managed by Puppet.

@@ -100,9 +100,9 @@ The default value (if not specified) for `ipv6_method` is _auto_.
 The default connection type is `ethernet` (alias for `802-3-ethernet`).
 The network connection hash needs to specify the NIC for the connection either by name with the key `interface_name` or by MAC address with the key `mac_address`.

-Next you need to specify how IPv4 configuration should be done. The key `ipv4_method` supports the values `auto`, `dhcp`, `manual`, `disabled`, `link-local`. All except `manual` do not need further configuation. For `manual` the `ipv4_address` in the CIDR format "IP/network mask bits". For the default router has to be set with the key `ipv4_gateway`.
+Next you need to specify how IPv4 configuration should be done. The key `ipv4_method` supports the values `auto`, `dhcp`, `manual`, `disabled`, `link-local`. All except `manual` do not need further configuration. For `manual` the `ipv4_address` in the CIDR format "IP/network mask bits". For the default router has to be set with the key `ipv4_gateway`.

-We did not look into IPv6 configuration yet and usualy it is best to switch it off by setting `ipv6_method` to `disabled`.
+We did not look into IPv6 configuration yet and usually it is best to switch it off by setting `ipv6_method` to `disabled`.

 To keep an interface down the setting `state` can be set to `down` (default is `up`).

@@ -118,7 +118,7 @@ networking::connection::psi_network:
 The first key level is the section in the NetworkManager configuration file (on the command line usually the first part before the dot), the second key level is the name of the value to be set.

 ### Infiniband Connection Definition
-For infiniband connections the configuration is similar to ethernet. Additionally there is there is the `type: 'infiniband` setting accompanied by an `additional_config` key holding an `infiniband` key with the infinibad specific optioins, as you see in below example:
+For infiniband connections the configuration is similar to ethernet. Additionally there is the `type: 'infiniband` setting accompanied by an `additional_config` key holding an `infiniband` key with the infiniband specific options, as you see in below example:

 ```
 networking::connection::ipoib_network:
@@ -177,7 +177,7 @@ NetworkManager also supports other types like `wifi`, `vpn`, `bridge`, `vlan`, e


 ### Interface Bonding
-For a bonded interfaces there is an own list named `networking::bondings` which defines which configuration defined in `networking::bonding::$NAME` hashes should be appled:
+For bonded interfaces there is an own list named `networking::bondings` which defines which configuration defined in `networking::bonding::$NAME` hashes should be appled:

 ```
 networking::bondings:
@@ -202,7 +202,7 @@ networking::bonding::bond0:
 ```
 Feel free to extend the documentation here or provide a link for detailed explanation of the bond options.

-By default the connection name is automatically used name of the bonding interface, Still, you can use speaking names instead for the connection if you specifiy the interface name explicitely:
+By default the connection name is automatically used name of the bonding interface, Still, you can use speaking names instead for the connection if you specify the interface name explicitly:

 ```
 networking::bondings:
@@ -11,6 +11,6 @@ ntp_server::allow:
  - '10.10.10.10'
 ```

-## Management Access for Unpriviledged Users
+## Management Access for Unprivileged Users

 A user which belongs to the group `chrony` is allowed to control the NTP server with `chronyc`.
@@ -43,7 +43,7 @@ rm ~/.config/dconf/user

 ### dconf Values

-In Hiera `dconf` settings can be configured with the `gnome::dconf::settings` key which contains a hash with the individual pathes and therein the individual configurations:
+In Hiera `dconf` settings can be configured with the `gnome::dconf::settings` key which contains a hash with the individual paths and therein the individual configurations:
 ```
 gnome::dconf::settings:
  'org/gnome/nautilus/preferences':
@@ -34,7 +34,7 @@ The desktop configuration can be further refined and/or adapted by following key
 desktop::display_manager: gdm  # available options: gdm (default), lightdm, none

 # this will set the default session manager aka desktop
-desktop::session_manager: gnome-xorg # availale options: gnome-xorg (default on RHEL8), gnome-wayland (default on RHEL9), gnome-classic, xfce, ...
+desktop::session_manager: gnome-xorg # available options: gnome-xorg (default on RHEL8), gnome-wayland (default on RHEL9), gnome-classic, xfce, ...
 ```
 No display manager (`desktop::display_manager: none`) is useful for terminal server or other servers where only virtual desktops, but no real physical access is required.

@@ -34,4 +34,4 @@ Applications marked as favorites are not shown in the application grid. This is
 Favorite apps might not be shown when certain hardware is connected, see [upstream bug](https://github.com/micheleg/dash-to-dock/issues/941).

 ### Panel
-Empty application grid on RHEL9, see [upsteam bug](https://github.com/home-sweet-gnome/dash-to-panel/issues/1891).
+Empty application grid on RHEL9, see [upstream bug](https://github.com/home-sweet-gnome/dash-to-panel/issues/1891).
@@ -20,9 +20,9 @@ xrdp::mode: 'virtual_desktops_only'
 ### Access to Physical Desktop

 !!! warning
-    Accessing to your/a real physcial destop session causes a security risk with people having physical access to the workstation. They can see on the real monitor what you are doing and interfer with keyboard and mouse. It is similar as if you are away from the workstation and have the screen unlocked.
+    Accessing to your/a real physical desktop session causes a security risk with people having physical access to the workstation. They can see on the real monitor what you are doing and interfere with keyboard and mouse. It is similar as if you are away from the workstation and have the screen unlocked.

-Note that due to technical limitiations it is only possible to access the primary screen in multi-monitor setups.
+Note that due to technical limitations it is only possible to access the primary screen in multi-monitor setups.

 For accessing the physical desktop there are three different modes supported:

@@ -32,7 +32,7 @@ xrdp::mode: 'access_users_physical_desktop_or_fallback_to_virtual_desktop'

 This allow to access to currently running desktop of the accessing user or, if none exists, creates automatically a virtual desktop.
 Note that you should log out of the virtual desktop before logging in again on the physical desktop.
-But it is fine to have multiple different users running own virtual desktops as long as they are different to the one useing the physical desktop.
+But it is fine to have multiple different users running own virtual desktops as long as they are different to the one using the physical desktop.

 ```yaml
 xrdp::mode: 'access_physical_desktop_of_whatever_user_logged_in'
@@ -105,7 +105,7 @@ After Gnome should start properly again.
 !["Session Already Running" dialog](xrdp/session_already_running.png)


-Systemd and Gnome do not really allow for more than one conncurrent session for the same user.
+Systemd and Gnome do not really allow for more than one concurrent session for the same user.

 Easiest solution: reboot/powercycle the machine.

@@ -32,5 +32,5 @@ autofs::slash_net: true

 ## Configure own autofs Maps

-For own maps place the `auto.master` part of the configuration in `/etc/auto.master.d/` in an unique file with the `.autofs` suffix. From there you link your map files, which can be placed everywhere, often directly in `/etc`. To manage this via Puppet/Hiera you might check out the [Distribute Files Guide](../files/distribute_files).
+For own maps place the `auto.master` part of the configuration in `/etc/auto.master.d/` in a unique file with the `.autofs` suffix. From there you link your map files, which can be placed everywhere, often directly in `/etc`. To manage this via Puppet/Hiera you might check out the [Distribute Files Guide](../files/distribute_files).

@@ -17,7 +17,7 @@ On workstation type systems this is enabled by default starting with RHEL9

 ## Adding a Share

-For a new or exsting share find a suitable path below `/psi.ch/group` or  `/psi.ch/project` and inform the [NAS Team](mailto:cits2-nas@psi.ch) or the [Linux Core Group](mailto:linux-eng@psi.ch).
+For a new or existing share find a suitable path below `/psi.ch/group` or  `/psi.ch/project` and inform the [NAS Team](mailto:cits2-nas@psi.ch) or the [Linux Core Group](mailto:linux-eng@psi.ch).

 ## Kerberos and Permanent Running Software
 Checkout [Permanent Kerberos with gssproxy and Password Keytab](../basic/gssproxy_with_keytab) if you want to access this, e.g. with background processes without having to type passwords (`kinit`) regularly.
@@ -37,7 +37,7 @@ files::symlinks:
  '/opt/foo': '/var/lib/foo'
 ```

-Before RHEL9 by default the symlink definitions are not merged over the full Hiera hierarchy, only the most specific definiton is used. To allow merge, set
+Before RHEL9 by default the symlink definitions are not merged over the full Hiera hierarchy, only the most specific definition is used. To allow merge, set

 ```yaml
 files::symlinks::merge: true
@@ -97,7 +97,7 @@ files::files:
  /etc/logo.png:
    hiera_file: files/logo.png
 ```
-Here none of the usual decryption, inheritence or interpolation functionality of Hiera is applied, the file is just copied as is.
+Here none of the usual decryption, inheritance or interpolation functionality of Hiera is applied, the file is just copied as is.

 Additional file parameters:
 - `owner`: file owner (optional, default `root`)
@@ -131,7 +131,7 @@ To synchronize a git repository to the host you might list them in the `files::g
 - `owner`: what user owns the files in the repository
 - `group`: what group owns the files in the repository
 - `user`: what user shall be used to run the git commands
- `umask`: umask to use for all file operatons
+- `umask`: umask to use for all file operations
 - ... for all options see the [vcsrepo documentation](https://forge.puppet.com/modules/puppetlabs/vcsrepo/reference#vcsrepo)

 Example:
@@ -189,7 +189,7 @@ Note that once downloaded files are kept on the Puppet server. On each Puppet ru

 ### Single Downloads

-"Simple" downloads can go with the hash `files::download` where you can map destination file pathes to URLs or with more detailed configuration including token and destination file permissions:
+"Simple" downloads can go with the hash `files::download` where you can map destination file paths to URLs or with more detailed configuration including token and destination file permissions:

 ```yaml
 files::download:
@@ -270,7 +270,7 @@ The option `force: true` is only needed for directories. For a directory, if abs
 ## Known Problems

 ### Downloading TAR File Fails
-Following warning/error happend with an uncompressed tar file being distributed:
+Following warning/error happened with an uncompressed tar file being distributed:

 ```bash
 Warning: Using a checksum in a file's "content" property is deprecated. The ability to use a checksum to retrieve content from the filebucket using the "content" property will be removed in a future release. The literal value of the "content" property will be written to the file. The checksum retrieval functionality is being replaced by the use of static catalogs. See https://puppet.com/docs/puppet/latest/static_catalogs.html for more information.
@@ -211,7 +211,7 @@ Here you need to set `remounts: false` because FUSE cannot do remounts.

 Only removing a mount point definition from Hiera does not unmount and remove it from the node. This can then be done manually by unmounting it and removing it from `/etc/fstab`.

-Alternatively an `absent` mount defintion as in below example will automatically unmount and remove the mount `/etc/fstab` entry:
+Alternatively an `absent` mount definition as in below example will automatically unmount and remove the mount `/etc/fstab` entry:

 ```
 mounter::def::scratch:
@@ -31,7 +31,7 @@ Then `lvs` gives the sizes of the volumes inside:

 ### Extend System Volume

-This can be done in Hiera with the `vgroot::path` key where for each volume which should be increased a new minium size can be set:
+This can be done in Hiera with the `vgroot::path` key where for each volume which should be increased a new minimum size can be set:

 ```
 vgroot::path:
@@ -14,11 +14,11 @@ Before starting the actual configuration you need to get for your team the "EAB-

 ## Configuration for Webserver/Webservice

-1. Best place the "EAB-KID" and the "EAB-HMAC-KEY" [encrypted](../../puppet/hiera#secrets) as variables `acme::eab-kid` and `acme::eab-hmac-key` on your top level YAML file so that they are availabe on all your nodes if needed. Please ensure you encrypt them as string and not as files as newlines which got encrypted will break the script.
+1. Best place the "EAB-KID" and the "EAB-HMAC-KEY" [encrypted](../../puppet/hiera#secrets) as variables `acme::eab-kid` and `acme::eab-hmac-key` on your top level YAML file so that they are available on all your nodes if needed. Please ensure you encrypt them as string and not as files as newlines which got encrypted will break the script.
 2. Install the required software, at least `certbot`.
-3. Prepare a renewal script required to roll out new certficiates to your (web)server and place it in `/etc/letsencrypt/renewal-hooks/post/`
+3. Prepare a renewal script required to roll out new certificates to your (web)server and place it in `/etc/letsencrypt/renewal-hooks/post/`
 4. Create a service which initializes `certbot` with all the required configuration. If you want to use more alias domain names, add them at the end of the `certbot` command as additional `--domain` parameters. At the end this initial command should also call the renewal-hook script to prepare the (web)server.
-5. Enable the `certbot-renew` timer which automatically keeps the certificates updated and will call the renewal-hoop when required.
+5. Enable the `certbot-renew` timer which automatically keeps the certificates updated and will call the renewal-hook when required.

 Full Hiera example:

@@ -46,7 +46,7 @@ files::files:
    content: |
      #!/bin/bash
      systemctl reload nginx
-  # Inital setup of certbot
+  # Initial setup of certbot
  /usr/local/libexec/certbot-initial:
    mode: "0500"
    content: |
@@ -101,7 +101,7 @@ Either configure your webserver to use the generated certificates and keys from
 Your renewal script may also copy the files instead and also change permissions so it fits whatever the (web)server needs.

 !!! note
-    Important! Best use fullchain.pem as some tools like curl testmight not have the necessary intermediate certificates!
+    Important! Best use fullchain.pem as some tools like curl test might not have the necessary intermediate certificates!

 Additional aliases can be added to the config by adding additional `--domain <name>` options in the `/usr/local/libexec/certbot-initial` file.

@@ -110,10 +110,10 @@ If you want to do changes, e.g. to the aliases, then best revoke the old certifi
 certbot revoke --cert-name $FQDN
 ```
 or whatever was the original `--cert-name`.
-Then adapt the configuration in Hiera and run Puppet. By restarting the `certbot-inital.service` (or rebooting) it will get a new certificate witht he new configuration:
+Then adapt the configuration in Hiera and run Puppet. By restarting the `certbot-initial.service` (or rebooting) it will get a new certificate with the new configuration:
 ```
 puppet agent -t
-systemctl restart certbot-inital.service
+systemctl restart certbot-initial.service
 ```


@@ -123,7 +123,7 @@ There are several images that use certbot integrated into whatever service you a
 In this documentation the nginx container is called nginx, please be aware of that when copying the documentation!

 To get your certificates inside a container you need to volume mount `/etc/letsencrypt/live` into your container, where you would expect your certificates to be. Be careful, the certificate and key are in the same folder!
-Also you need to "manually" reload the webserver using the certificate, when "ordering" a certificate and when its renewed by certbot. Bellow are the steps needed. The code blocks assume that you configured the cli.ini file with puppet module files:files already.
+Also you need to "manually" reload the webserver using the certificate, when "ordering" a certificate and when its renewed by certbot. Below are the steps needed. The code blocks assume that you configured the cli.ini file with puppet module files:files already.

 ```yaml
  nginx:
@@ -84,9 +84,9 @@ Additionally to/instead of the admins you can list the notification recipients i
 - AD groups with `%` as prefix to their name
 - plain e-mail addresses

-### Notificiation Time Restrictions
+### Notification Time Restrictions

-Notificiations for warnings and alerts are sent out by default during office hours, this means from Monday to Friday 08:00 - 17:00.
+Notifications for warnings and alerts are sent out by default during office hours, this means from Monday to Friday 08:00 - 17:00.

 This can be configured in Hiera with the `icinga2::alerting::severity` key which is `4` by default. Following options are possible:

@@ -109,7 +109,7 @@ Please note that services where the `criticality` variable is set then time when
 | `B`                 | office hours |
 | `C`                 | never        |

-The minimal settings are applied, e.g. a service with criticality `C` will never cause a notificiation independent of the node severity.
+The minimal settings are applied, e.g. a service with criticality `C` will never cause a notification independent of the node severity.

 To receive notification messages over SMS, you need to register your mobile phone with Icinga2. You may request this informing icinga2-support@psi.ch about your wish. Alternatively you will get an e-mail with the request to do so when the first SMS was supposed to be sent out for you and the phone number is still missing.

@@ -149,7 +149,7 @@ If it is a Linuxfabrik plugin, you find a link at "Notes" which points to the do
 ### Example "Kernel Ring Buffer (dmesg)" Message Ignore List Customization
 Another check which can easily have false alerts, but also has a big potential to signal severe kernel or hardware issues, is the check of the kernel log (dmesg).

-If you conclude that a given message can savely be ingored, you may add it onto the ignore list, where a partial string match will make it ignored in the future:
+If you conclude that a given message can safely be ignored, you may add it onto the ignore list, where a partial string match will make it ignored in the future:
 ```
 icinga2::service_check::customize:
  'Kernel Ring Buffer (dmesg)':
@@ -165,7 +165,7 @@ dmesg --clear
 ```

 ### Example "Systemd Units Failed" Ignore List Customization
-It migth also be OK if some Systemd (Service) Units fail:
+It might also be OK if some Systemd (Service) Units fail:

 ```
 icinga2::service_check::customize:
@@ -203,7 +203,7 @@ icinga2::custom_service:
 Below `icinga2::custom_service` set the name of the service/service check as it will be seen in Icingaweb. Then the possible arguments are
 - `command` to issue a check command
 - `template` to inherit from given service template
- `agent` shall the `command` run on the agent or the satellite, only if `themplate` is not set, default is `true`
+- `agent` shall the `command` run on the agent or the satellite, only if `template` is not set, default is `true`
 - `vars` hash with arguments for the service check
 - `perf_data` if performance data should be recorded and performance graph should be shown, default is `false`

@@ -335,7 +335,7 @@ This check is automatically enabled.

 This check is enabled automatically with Hiera configuration `base::enable_lsi_raid: true`.

-Following check specifc variables can be set:
+Following check specific variables can be set:

 ```
 lsi_raid_controller
@@ -4,9 +4,9 @@ For the systemd journal size restriction and rate limiting can be fine tuned.

 ## Size Restriction

-In Hiera `log_client::journal_system_max_use` (default `50%`) limits the total size of the journal, whereas `log_client::journal_system_keep_free` (default `25%`) ensures how much disk space is keep free in `/var/log` for other use. In addition to the syntax described in [journald.conf(5)](https://www.freedesktop.org/software/systemd/man/latest/journald.conf.htm) (bytes or use K, M, G, T, P, E as units) we also support percentages, i.e. `25%` means that the journal will use mostly/spare at least 25% of `/var/log`. Note that for the use of a percentage limit `/var/log` must be an own partition, else absolute values need to be set.
+In Hiera `log_client::journal_system_max_use` (default `50%`) limits the total size of the journal, whereas `log_client::journal_system_keep_free` (default `25%`) ensures how much disk space is kept free in `/var/log` for other use. In addition to the syntax described in [journald.conf(5)](https://www.freedesktop.org/software/systemd/man/latest/journald.conf.htm) (bytes or use K, M, G, T, P, E as units) we also support percentages, i.e. `25%` means that the journal will use mostly/spare at least 25% of `/var/log`. Note that for the use of a percentage limit `/var/log` must be an own partition, else absolute values need to be set.

-`log_client::journal_system_max_file_size` limits the size of an individual journal file. Default ist `32M`.
+`log_client::journal_system_max_file_size` limits the size of an individual journal file. Default is `32M`.

 If there is no need for a persistent log at all, it can be disabled with
 ```
@@ -18,5 +18,5 @@ rpm_repos::default:
 ```

 ```{note}
-If you configure a RPM repository from Gitea you might need to add an access token in front of the URL!
+If you configure an RPM repository from Gitea you might need to add an access token in front of the URL!
 ```
@@ -23,7 +23,7 @@ rpm_repos::default:
  - "environment_modules"
 ```

-Afterwards you can install the environment-modules package as usual via dnf or hiera configuraiton.
+Afterwards you can install the environment-modules package as usual via dnf or hiera configuration.

 !!! warning
    If you install the latest environment-modules package you might break other software that depends on the environment-modules package provided by RHEL. Use at your own risk!
@@ -61,9 +61,9 @@ One the installation is complete you can launch Mathematica by running the `math

 ## License Activation

-Mathematica requires a valid license to run. Therefor you need to configure the license server of PSI. This can be done as follows:
+Mathematica requires a valid license to run. Therefore you need to configure the license server of PSI. This can be done as follows:

-1. Launche Mathematica (Following dialog will appear on the first launch)
+1. Launch Mathematica (Following dialog will appear on the first launch)
 ![](mathematica/mathematica_01.png)
 2. Click on "Other ways to activate" and then select "Activate through a Wolfram network license server"
 ![](mathematica/mathematica_02.png)
@@ -12,7 +12,7 @@ rpm_repos::default:

 Note that repositories for different versions of RHEL can be added and only the fitting ones will be configured on the node.

-If the package repositories are managed by a Puppet module, then it is good practice is to define a specific package repository list in [`common.yaml`](https://gitea.psi.ch/puppet/puppet/src/branch/preprod/data/common.yaml) and then to install it only when needed. An example is `profile::telegraf` which only installes the repositories listed in `rpm_repos::influx` when needed.
+If the package repositories are managed by a Puppet module, then it is good practice is to define a specific package repository list in [`common.yaml`](https://gitea.psi.ch/puppet/puppet/src/branch/preprod/data/common.yaml) and then to install it only when needed. An example is `profile::telegraf` which only installs the repositories listed in `rpm_repos::influx` when needed.

 ## Package Repository Definition

@@ -39,7 +39,7 @@ Note for `name` attribute, that only has to be unique on the machine where they

 ### Package Repository URL

-Overriding the URL of a package repository definition on a stricter scope is considered bad practice. The URL defines the actual "identiy" of the package repository definition. It is confusing if it gets different meanings at different places. It is like one passport which will identify different persons in different countries.
+Overriding the URL of a package repository definition on a stricter scope is considered bad practice. The URL defines the actual "identity" of the package repository definition. It is confusing if it gets different meanings at different places. It is like one passport which will identify different persons in different countries.

 If different sources are needed, define and name them appropriately. They point to one given repository and the package repository lists are the place to select what should be applied on a given node.

@@ -62,7 +62,7 @@ If certain packages provided by given repository should be ignored on the nodes,
 ## Using Specific Package Repository Snapshot
 Most of the externally sourced package repositories on https://repos.psi.ch/rhel7 (RHEL7), https://repos.psi.ch/rhel8 (RHEL 8) and https://repos.psi.ch/rhel9 (RHEL 9) have snapshots which can be used to freeze the available package versions to a given date.

-The tags are different per major OS version and are definied in the Hiera hash `rpm_repos::tag`, below you see the default:
+The tags are different per major OS version and are defined in the Hiera hash `rpm_repos::tag`, below you see the default:

 ```
 yum_client::repo_tag: 'prod'
@@ -73,7 +73,7 @@ rpm_repos::tag:
    redhat9: 'rhel-9'
 ```

-So for RHEL 7 the default is `prod` and can be overriden on `yum_client::repo_tag` (backwards compatibility) or on the `redhat7` attribute of `rpm_repos::tag`.
+So for RHEL 7 the default is `prod` and can be overridden on `yum_client::repo_tag` (backwards compatibility) or on the `redhat7` attribute of `rpm_repos::tag`.

 To fix to a specific snapshot on RHEL 8, the `redhat8` attribute has to be set on `rpm_repos::tag`, the default is `rhel-8` which points to the latest snapshot.

@@ -85,7 +85,7 @@ The available tags your find at

 ## Package Repositories made Available by the Linux Group

-Availabe on all systems are:
+Available on all systems are:

 - RedHat [BaseOS](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/package_manifest/baseos-repository), [AppStream](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/package_manifest/appstream-repository) and [CodeReady](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/package_manifest/codereadylinuxbuilder-repository) repositories
 - [Extra Packages for Enterprise Linux (EPEL) repositories](https://docs.fedoraproject.org/en-US/epel/)
@@ -117,7 +117,7 @@ To be added/defined in [`common.yaml`](https://gitea.psi.ch/puppet/puppet/src/br

 A small list of packages managed by the Linux Team.

- *RHEL8*: make v4.3 from [CentOS](https://rpmfind.net/linux/RPM/centos-stream/9/baseos/x86_64/make-4.3-7.el9.x86_64.html) as v4.2.1 has been reported to to make trouble
+- *RHEL8*: make v4.3 from [CentOS](https://rpmfind.net/linux/RPM/centos-stream/9/baseos/x86_64/make-4.3-7.el9.x86_64.html) as v4.2.1 has been reported to make trouble
 - latest [Zoom client](https://zoom.us/download?os=linux)
 - latest [Webex client](https://www.webex.com/downloads.html)
 - latest [Slack client](https://slack.com/downloads/linux)
@@ -126,7 +126,7 @@ A small list of packages managed by the Linux Team.
 - `pli-assets` containing the PSI and the Customer Self Service logo, any hints about the source rpm are welcome
 - *RHEL8*: [mod_gearman v4.0.1](https://mod-gearman.org/download/v4.0.1/rhel8/x86_64/)
 - *RHEL8*: lightdm-gtk v2.0.8-3.pli, a patched lightdm-gtk-greeter ([SRPM](https://gitea.psi.ch/linux/lightdm-gtk-rpm), [PR](https://github.com/Xubuntu/lightdm-gtk-greeter/pull/121)) which allows to limit the presented keyboard layouts
- Code Beamer Office pluging v9.5.0 managed by Gilles Martin
+- Code Beamer Office plugin v9.5.0 managed by Gilles Martin
 - storecli 007.2007.0000.0000 managed by Marc Caubet Serrabou
 - [pam_single_kcm_cache PAM Module](https://github.com/paulscherrerinstitute/pam_single_kcm_cache) managed by Konrad Bucheli
 - [nvidia-detect](http://elrepo.org/tiki/nvidia-detect) copied over from ElRepo to make it generally available
@@ -5,7 +5,7 @@ It also has an automatic software update feature, but for this functionality we

 Except on workstationi-type systems this is disabled.

-It can be explicitely be disabled with
+It can be explicitly be disabled with
 ```
 desktop::enable_packagekit: false
 ```
@@ -17,7 +17,7 @@ Currently there exist the following package groups in the main [`common.yaml`](h
 - `base::pkg_group::qt5`
 - `base::pkg_group::root`

-but further ones can be created in Hiera at lower hierachies and added to `base::package_groups`, for example
+but further ones can be created in Hiera at lower hierarchies and added to `base::package_groups`, for example

 ```
 base::pkg_group::java:
@@ -131,7 +131,7 @@ To make packages unavailable for installation, even though provided by the packa
 base::package_exclude:
    - 'epics-base-7.0.6*'
 ```
-This list is merged over the full Hiera hierachy, so there is no need to copy exclusions from higher levels when creating an exclusion on a low level.
+This list is merged over the full Hiera hierarchy, so there is no need to copy exclusions from higher levels when creating an exclusion on a low level.

 This list can also be used to opt out packages from other, maybe inherited package groups. But unlike the `:absent` tag in a package list it will not uninstall a package when found.

@@ -145,7 +145,7 @@ dnf versionlock add $PACKAGE
 ```
 for every package you do not wish to get updates installed any more. If there are newer packages you might test with `dnf update --assumeno` if it does not show your software any more, while other updates are still possible. Sometimes this can cause dependency resolution failures and you might need to add a version lock for one or more packages which depend on the locked package.

-After you best put the resulting `/etc/dnf/plugins/versionlock.list` in Hiera with [`files::files`](../files/distribute_files) for reproducability.
+After you best put the resulting `/etc/dnf/plugins/versionlock.list` in Hiera with [`files::files`](../files/distribute_files) for reproducibility.

 ### Kernel Version Lock
 A full kernel version lock needs to include a number of packages. For RHEL8:
@@ -166,8 +166,8 @@ get_deps() {
  
  group=$(get_group $module/$version)
  info=$(get_info $group $module $version)
-  ALLIGN=$(expr 40 - $space)
-  printf "%-${ALLIGN}s %s\n" "$module/$version" "($info)"
+  ALIGN=$(expr 40 - $space)
+  printf "%-${ALIGN}s %s\n" "$module/$version" "($info)"
  dependency_file_1=/opt/psi/$group/modulefiles/$module/.deps-$version
  dependency_file_2=/opt/psi/$group/$module/$version/.dependencies
  
@@ -216,7 +216,7 @@ HDF5_LZ4/2018.05 ("Dmitry Ozerov <dmitry.ozerov@psi.ch>")
 DirAx/1.17 ("Dmitry Ozerov <dmitry.ozerov@psi.ch>")
 ```

-As the dependencies are already resolved recusively, you can now simply copy all the listed modules with the copy function defined above.
+As the dependencies are already resolved recursively, you can now simply copy all the listed modules with the copy function defined above.

 Example for crystfel 0.10.2:
 ```bash
@@ -24,9 +24,9 @@ For system tools, that should run consistently on all systems you may decide to

 ## Python Versions

-On __RHEL8__ the Platform (and usual Default) Python version is __3.6__. As the time of writing following Python versions are additinally available: _3.8_, _3.9_, _3.11_, _3.12_ .
+On __RHEL8__ the Platform (and usual Default) Python version is __3.6__. As the time of writing following Python versions are additionally available: _3.8_, _3.9_, _3.11_, _3.12_ .

-On __RHEL9__ the Platform (and usual Default) Python version is __3.9__. As the time of writing following Python versions are additinally available: _3.11_, _3.12_
+On __RHEL9__ the Platform (and usual Default) Python version is __3.9__. As the time of writing following Python versions are additionally available: _3.11_, _3.12_


 ## Configuration
@@ -74,7 +74,7 @@ __IMPORTANT:__ Note that packages installed with `pip` are not updated automatic
 For additional information on how to install packages (including `pip`) please check out [this guide](packages).

 ```{note}
-The packages prefixed with `python3-` are for the default Default Python version. For newer versions RedHat has a versioned prefix like `python38-` or `python3.11-`. There might not be for all libraries packages for all availabe Python versions. Then you might need to install your library with `pip`.
+The packages prefixed with `python3-` are for the default Default Python version. For newer versions RedHat has a versioned prefix like `python38-` or `python3.11-`. There might not be for all libraries packages for all available Python versions. Then you might need to install your library with `pip`.
 ```

 ### PYPI Package Caching Proxy
@@ -67,7 +67,7 @@ selinux::fcontext:
 a unique arbitrary key name for each entry is needed.


-If you wish to have the same fcontext configuation as another path do
+If you wish to have the same fcontext configuration as another path do

 ```yaml
 selinux::fcontext::equivalence:
@@ -95,7 +95,7 @@ Such a module can be created from recorded violations with
 ```
 ausearch --raw | audit2allow -r -m $CUSTOM_SELINUX_MODULE_NAME
 ```
-Note that the `setroubleshootd` log output ususally gives you a narrower search filter for `ausearch` for each recorded violation.
+Note that the `setroubleshootd` log output usually gives you a narrower search filter for `ausearch` for each recorded violation.

 Each such module needs to be added with a unique key at the Hiera key `selinux::modules::te`. A full example is

@@ -47,7 +47,7 @@ base::services:

 ## Manage Services with Custom Unit Files (full new service)

-It is also possible to provide a full systemd unit file if there is none already. For this define the different secions and their content with subkeys below the `options` key as in below example:
+It is also possible to provide a full systemd unit file if there is none already. For this define the different sections and their content with subkeys below the `options` key as in below example:

 ```
 # The following service stops users from accessing the node
@@ -87,7 +87,7 @@ base::services:
        options:
            ...
 ```
-Often this is done to start the service with different options, then you need to reset the orginal value with an emty entry: 
+Often this is done to start the service with different options, then you need to reset the original value with an empty entry: 

 ```
 base::services:
@@ -3,7 +3,7 @@

 ## Create New Timer

-To have custom executables run regulary on given time/interval, you may use the `base::timers` Hiera key:
+To have custom executables run regularly on given time/interval, you may use the `base::timers` Hiera key:

 ```
 base::timers:
@@ -25,7 +25,7 @@ This then creates both the required timer and service unit files for systemd.

 For each timer following keys are mandatory

- `description` for a short explaination what it is about
+- `description` for a short explanation what it is about
 - `command` for the command to run
 - `on_calendar` defining when it should run using the [`systemd` calendar event format](https://www.freedesktop.org/software/systemd/man/systemd.time.html#Calendar%20Events), (alternatively see also chapter "CALENDAR EVENTS" of `man systemd.date`)

@@ -20,7 +20,7 @@ The pgroup folders and `raw` and `work` links in `/<facility>/<beamline>/data` a

 The purpose of the toplevel folders is the following:

-| Folder Name | Pupose |
+| Folder Name | Purpose |
 | ----------- | ------ |
 | bin | scripts and wrapper scripts that need to be in the PATH of a linux system |
 | config | Configuration files for applications |
@@ -28,7 +28,7 @@ The purpose of the toplevel folders is the following:
 | config/launcher | Configuration files for the epics launcher |
 | applications | Application binaries for the beamline/endstation | 
 | data | data storage of the beamline/endstation organized by pgroup `<pgroup>/[raw|work]` Propriatary, non PSI pgroups, do not have a `work` storage/folder|
-| code | Place to checkout code that should be available all accross the beamline/endstation |
+| code | Place to checkout code that should be available all across the beamline/endstation |
 | misc | Whatever else ... If there is a need that people have their own "workspace" we propose to use `<username>` subfolders here ... |

 ### Permissions
@@ -2,7 +2,7 @@

 __Docker__ and __Podman__ are different implementations of an OCI container runtime. There are distinct differences (see below) although their usage is more or less the same. The usage is mutual exclusive, i.e. __you cannot use/install both at the same time!__

-One very confusing fact is, that if you installed _Podman_ you still have a command called `docker` available. Therefore you might experience differences in behaviour by executing the very exact commmand on different systems (which either have Podman or Docker installed).
+One very confusing fact is, that if you installed _Podman_ you still have a command called `docker` available. Therefore you might experience differences in behaviour by executing the very exact command on different systems (which either have Podman or Docker installed).


 !!! warning
@@ -14,7 +14,7 @@ One very confusing fact is, that if you installed _Podman_ you still have a comm
 If you have problems with connectivity this might be due to the default docker network range being used by AIT.

 !!! Usage
-    You can use 10.3.0.0/16 and 10.4.0.0/16 savely. They have been assigned as default docker networks by AIT.
+    You can use 10.3.0.0/16 and 10.4.0.0/16 safely. They have been assigned as default docker networks by AIT.
    Podman's default net 10.88.0.0/16 is save to use.

 ### Docker-ce example
@@ -32,7 +32,7 @@ If you have problems with connectivity this might be due to the default docker n

 ## Docker
 Docker-CE will have always the latest features in docker engine and docker compose.
-The docker repo is enabled by default and the packages can be installed by using follwing code in hiera.
+The docker repo is enabled by default and the packages can be installed by using following code in hiera.

 ```yaml
 base::pkg_group::extra:
@@ -28,7 +28,7 @@ mount_nfs -o sec=krb5,nfsvers=4 lx-fs.psi.ch:/packages_misc ~/some_directory
 (on __Windows__ - it should be/is also possible with Windows >=10 to mount the NFS4 share- https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mount - details to be added here)


-Once your folder/folders is/are created and your are autorized to write into these folders you can place RPMs and files into that directory/directories
+Once your folder/folders is/are created and your are authorized to write into these folders you can place RPMs and files into that directory/directories

 __Important__: Once mounted, to be able to change things on the filesystem you have to have a valid kerberosticket for your PSI user. 
 ```
@@ -58,7 +58,7 @@ https://$lx_reposerver/<os>/$lx_repo_tag/<repository_name>
 This ensures that the systems will always use the correct repository server url to access the repositories. (e.g. in the DMZ/extranet the DNS hostname of the repository is different ...)


-The content of the custom repositories are managed on a a dedicated NFS4 share. On this share groups can have different folders where they place/manage their rpms. These RPMs are periodically synced to the main repository share (i.e. every 15 minutes), so what you see on the `packages_misc` is not exactly what will end up on the repository server. Upon sync the repository will be automatically build via the create-repo command.
+The content of the custom repositories are managed on a dedicated NFS4 share. On this share groups can have different folders where they place/manage their rpms. These RPMs are periodically synced to the main repository share (i.e. every 15 minutes), so what you see on the `packages_misc` is not exactly what will end up on the repository server. Upon sync the repository will be automatically built via the create-repo command.

 The structure of the share is usually as follows:

@@ -86,7 +86,7 @@ chmod g+w <reponame>
 chmod g+s <reponame>

 # set NFS4 ACL to ensure the group can always write
-# ensure that you repace the id of the group !!!
+# ensure that you replace the id of the group !!!
 nfs4_setfacl -a A:dfg:35593:RWX /modules/test
 ```

@@ -40,7 +40,7 @@ curl --remote-header-name --remote-name "$URL"
 ```
 ## Installation

- add two CD-ROM drives to the virual hardware
+- add two CD-ROM drives to the virtual hardware
 - map the first CD-ROM drive to the OS ISO image
 - map the second CD-ROM drive to the kickstart ISO image
 - boot the VM into the OS ISO image
@@ -18,7 +18,7 @@ The general process for a installation is:
 The default way to interact with sysdb is to use [bob](https://gitea.psi.ch/linux/bob). `bob` is already set up on `lxsup.psi.ch` for general use. Remember that you need a valid Kerberos ticket before modifying a sysdb entry via `bob`.
 As a first time user ensure that you are part of the group `unx-puppet_usr` for accssing `lxsup.psi.ch` and of the respective administrator group of your environment (third column in the output of `bob env list -v`).

-Altenatively you many have on your workstation a local copy of `bob`. This can be done by installing the RPM from the pli-misc repository - https://repos.psi.ch/rhel8/latest/pli-misc/ or by installing the Python package manually. More details regaring `bob` can be found [here](https://gitea.psi.ch/linux/bob).
+Alternatively you many have on your workstation a local copy of `bob`. This can be done by installing the RPM from the pli-misc repository - https://repos.psi.ch/rhel8/latest/pli-misc/ or by installing the Python package manually. More details regarding `bob` can be found [here](https://gitea.psi.ch/linux/bob).

 ## Hardware/VM Requirements

@@ -54,7 +54,7 @@ bob node set-attr $FQDN network=static
 bob node set-attr $FQDN puppet_group=cluster
 bob node set-attr $FQDN puppet_subgroup=compute

-# use a differnt puppet environment
+# use a different puppet environment
 bob node set-attr $FQDN puppet_env=prod
 ```

@@ -93,7 +93,7 @@ bob node set-attr $FQDN system_disk=md126
 ```

 The ordering of disks (`sda`, `sdb`, ...) might sometimes not be stable.
-To explicitely select the disk you might use on of the links below `/dev/disk` like
+To explicitly select the disk you might use one of the links below `/dev/disk` like

 ```bash
 bob node set-attr $FQDN system_disk=disk/by-path/pci-0000:a1:00.0-ata-1
@@ -1,6 +1,6 @@
 # DMZ Installation

-The deployment in the DMZ ist the basically the same as [internaly](basic_installation), but there are a few points to consider:
+The deployment in the DMZ is basically the same as [internally](basic_installation), but there are a few points to consider:

 - the commissioning can only be done in the special DMZ commissioning network

@@ -33,5 +33,5 @@ lrwxrwxrwx. 1 puppet puppet 11  1. Mai 09:49 x04sa-cons-01.psi.ch -> ../data/sls
 ```

 ```{note}
-If the host has a long hostname it might be necesssary to also delete the link with the hashed name! e.g. `awi-cha-dba8004`
+If the host has a long hostname it might be necessary to also delete the link with the hashed name! e.g. `awi-cha-dba8004`
 ```
@@ -11,7 +11,7 @@ Following software is involved in getting the desktop on Linux up and running.
  - **gdm** Gnome Display Manager is default on RHEL 8
  - **lightdm** is very flexible, but automatic Gnome screen lock does not work with it, manual locking would be needed (`dm_tool lock`)
  - **sddm** the Simple Desktop Display Manager from the KDE world fails due to a kernel bug on RHEL 8.6
- **Greeter**: user interface part of the display manager, e.g. for `lightdm` it is exchangable
+- **Greeter**: user interface part of the display manager, e.g. for `lightdm` it is exchangeable
 - **Accounts Service** (`accounts-daemon`) used by `gdm` to learn about/store user information (last desktop session, profile image, etc)
 - **Session Manager** starts the actual desktop. The installed options are found in `/usr/share/wayland-sessions/` for `Wayland` and `/usr/share/xsessions/` for `Xorg`. 
  - **gnome-session** normal Gnome starter (for `Xorg` and `Wayland`)
@@ -28,7 +28,7 @@ Per default Puppet starts `gdm` which then starts Gnome with `Xorg` using `/usr/

 Normally the Display Managers offer the user to select one of the available Desktop Sessions (`*.desktop` files in `/usr/share/wayland-sessions/` and `/usr/share/xsessions/`). This has been disabled as normally at the PSI this is more set per system and not per user.

-In Hiera the actual Desktop Session to be started can be selected/overriden by setting the `desktop::session_manager` to one of the `.desktop` files in above listed directories. Set it e.g. to `gnome-wayland` to test `Wayland`. It will then end up as default session manager in `/etc/accountsservice/user-templates/standard`.
+In Hiera the actual Desktop Session to be started can be selected/overridden by setting the `desktop::session_manager` to one of the `.desktop` files in above listed directories. Set it e.g. to `gnome-wayland` to test `Wayland`. It will then end up as default session manager in `/etc/accountsservice/user-templates/standard`.

 Note when changing the default Session Manager, previous users will still get the one they used before. To reset that, you need to delete
 - stop AccountsService (`systemctl stop accounts-daemon.service`)
@@ -13,7 +13,7 @@ Please still consider also implementing following two migrations when moving to

 Bugs and issues can be reported in the [Linux Issues project](https://gitea.psi.ch/linux/issues/issues).

-## Documenation
+## Documentation

 * [Installation](../basic_installation.md)
 * [CUDA and Nvidia Drivers](nvidia)
@@ -59,7 +59,7 @@ For RHEL 8 Red Hat phased out some hardware drivers, here is an [official list](

 Installation with an unsupported RAID adapter then fails as the installer does not find a system disk to use.

-To figure out what driver you need, best go the the installer shell or boot a rescue linux over the network and on the shell check the PCI Device ID of the RAID controller with
+To figure out what driver you need, best go to the installer shell or boot a rescue linux over the network and on the shell check the PCI Device ID of the RAID controller with

 ```
 $ lspci -nn
@@ -91,7 +91,7 @@ It also automatically renews tickets which is handy for every use case.

 Intuitively I would expect that something delicate as authentication is managed per session (ssh, desktop, console login, ...). 

-Aparently with KCM this is not the case. It provides a default cache which is supposed to be the optimal for you and that can change any time.
+Apparently with KCM this is not the case. It provides a default cache which is supposed to be the optimal for you and that can change any time.

 Problems I see with this are
 - user may change his principal, eg. for admin operations (`kinit buchel_k-adm`) which is then used by all sessions
@@ -101,25 +101,25 @@ Problems I see with this are

 So if we have more than one session on a machine (e.g. people connecting via remote desktop and ssh at the same time), the cross-session side-effects can cause unexpected behaviour.

-In contrast to this for AFS token renewal having access to new tokens is helpful, as this allows prolong the time a `PAG` (group of processes authenticated against AFS) is working as long as there is at least one valid ticket available.
+In contrast to this for AFS token renewal having access to new tokens is helpful, as this allows prolonging the time a `PAG` (group of processes authenticated against AFS) is working as long as there is at least one valid ticket available.
 Or even to recover when a new ticket comes available again.

-A way to get KCM of of the business of selecting the "optimal" cache is to select it yourself and provide the session/software one specific cache by setting the `KRB5CCNAME` environment variable accordingly (e.g. `KCM:44951:66120`). Note when set to `KCM:` it will use as default cache the one KCM believes should be the default cache. And that can change for whatever reason.
+A way to get KCM out of the business of selecting the "optimal" cache is to select it yourself and provide the session/software one specific cache by setting the `KRB5CCNAME` environment variable accordingly (e.g. `KCM:44951:66120`). Note when set to `KCM:` it will use as default cache the one KCM believes should be the default cache. And that can change for whatever reason.


 ### Problems of `sssd_kcm`

-To check the Kerberos credential cache, you can use `klist` to look a the current default cache and `klist -l` to look at all available caches. Note that the first listed cache is the default cache. Of course that is only valid when there is no  `KRB5CCNAME` environment variable set or it is `KCM:`.
+To check the Kerberos credential cache, you can use `klist` to look at the current default cache and `klist -l` to look at all available caches. Note that the first listed cache is the default cache. Of course that is only valid when there is no  `KRB5CCNAME` environment variable set or it is `KCM:`.

 #### No Cleanup of Expired Caches
 The most obvious and [well known problem](https://github.com/SSSD/sssd/issues/3593) of `sshd-kcm` is that it does not remove expired tokens and credential caches. I agree that it should not have an impact as this is mostly cosmetic. But that is only the case when everything can cope with that...

-By default is is limited to 64 caches, but when that limit was hit, then it was not possible any more to authenticate on the lock screen:
+By default it is limited to 64 caches, but when that limit was hit, then it was not possible any more to authenticate on the lock screen:

 ```
 Okt 05 14:57:11 lxdev01.psi.ch krb5_child[43689]: Internal credentials cache error
 ```
-So this causes a denial of service problem, we need to deal with somehow, e.g. by regulary removing expired caches. And note that these caches are persistent and do not get removed on reboot.
+So this causes a denial of service problem, we need to deal with somehow, e.g. by regularly removing expired caches. And note that these caches are persistent and do not get removed on reboot.

 #### Use of Expired Credential Caches 
 In below example you see that on the ssh login, I got a new default cache. But after a few minutes (there was a Desktop login from my side and maybe an automatic AFS token renewal in between), I get an expired cache as default cache.
@@ -244,7 +244,7 @@ renew until 14.07.2022 11:26:19
 Do Sep 22 08:37:41 CEST 2022
 [buchel_k@mpc2959 ~]$ 
 ```
-Note that a non-expired cache is available, but NoMachine NX explicitely sets `KRB5CCNAME` to a specific KCM cache. And it contains a ticket/cache which is supposed to the gone.
+Note that a non-expired cache is available, but NoMachine NX explicitly sets `KRB5CCNAME` to a specific KCM cache. And it contains a ticket/cache which is supposed to be gone.

 So there is a security bug in `sssd-kcm`: it does not fully destroy tickets when being told so. And there is another security issue in the NoMachine NX -> `sssd-kcm` interaction. I assume that it talks with the KCM as root and gets somehow (or has saved somewhere) old caches and moves them over into user context. But the cache may originally not have belonged to the user...

@@ -254,7 +254,7 @@ I have not found a lot concerning Kerberos on the NoMachine website.

 Ideally we would get to a solution which can do the following:

- interactive user sessions are isolated do not interfer with each other
+- interactive user sessions are isolated do not interfere with each other
 - AFS can get hold of new tickets and inject them into the PAGs as long as the user somehow regularly authenticates
 - `systemd --user` which is residing outside of the interactive user sessions is happy as well
 - `goa-daemon` sees only one cache
@@ -272,7 +272,7 @@ But some logins do not work any more when the maximum number of caches is hit as
 ### renew-afstoken Script/Daemon

 For AFS we (Achim and I) made the script `renew-afstoken` which is started as per PAG daemon by PAM upon login. 
-Out of the available KCM caches it selects a suitable one to regulary get a new AFS token.
+Out of the available KCM caches it selects a suitable one to regularly get a new AFS token.
 This now works very robust and can also recover from expiration when a new ticket gets available.


@@ -7,7 +7,7 @@ Those are discussed in the first chapter, more details you find more below.

 ## Hiera Configuration

-Changes in Hiera are forwared by Puppet to the node, but **not applied**.
+Changes in Hiera are forwarded by Puppet to the node, but **not applied**.
 They are applied on **reboot**.
 Alternatively you might execute `/opt/pli/libexec/ensure-nvidia-software` in a safe moment (no process using CUDA and the desktop will be restarted).

@@ -60,11 +60,11 @@ I did not find much information about Nvidia driver version structure and policy

 ### Driver Branches

-Their drivers are oranized in driver branches. As you see for example in their [Unix Driver Archive](https://www.nvidia.com/en-us/drivers/unix/) noted as e.g. `470.xx series`.
+Their drivers are organized in driver branches. As you see for example in their [Unix Driver Archive](https://www.nvidia.com/en-us/drivers/unix/) noted as e.g. `470.xx series`.

 There are `Production` and `New Feature` branches (and, on the above linked page, a `Beta Version` which is not linked to any of the above branches (yet?)).

-Such a branch can be considered a major release and with new braches adding support for new hardware or removing support for old hardware.
+Such a branch can be considered a major release and with new branches adding support for new hardware or removing support for old hardware.
 The drivers within certain branches are maintained quite a long time. Individual drivers in that branch get increasing version numbers which just start with the same first "branch" number.

 In the RPM repo there are more branches available than listed in the [Unix Driver Archive](https://www.nvidia.com/en-us/drivers/unix/). It is not possible to find out retrospectively to what type of branch it belongs. My guess is that the "Legacy" section lists only the production/long term support branches.
@@ -73,7 +73,7 @@ Also it is not possible to find out from the package meta information if a drive

 ### What Driver \[Branch] for which Hardware

-The most authorative way to do so is to chech the [Appendix A of the README of a recent driver](http://us.download.nvidia.com/XFree86/Linux-x86_64/525.78.01/README/supportedchips.html).
+The most authoritative way to do so is to check the [Appendix A of the README of a recent driver](http://us.download.nvidia.com/XFree86/Linux-x86_64/525.78.01/README/supportedchips.html).
 There search for your model or PCI ID. Then check out at the top of the respective table which legacy driver it still supports.
 Or it might be the current driver.

@@ -130,7 +130,7 @@ nvidia-driver   520-open          default [d], fm, ks, src  Nvidia driver for 52
 Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
 # 
 ```
-The first try would be to pick the number of the desired branch. Currently the `520*` and `latest` are empty because the drivers where removed.
+The first try would be to pick the number of the desired branch. Currently the `520*` and `latest` are empty because the drivers were removed.

 The "number only" module streams contain precompiled drivers for some kernels. Note that for older branches or older drivers it may not be precompiled for the latest kernel version. For older branches I had the experience that the `*-dkms` module stream works better for newer kernels. But I did not manage to do "real" DKMS with them, that means compiling the translation layer of any given driver version for whatever kernel. Feel free to update this guide or to tell the Core Linux Team if you found a working procedure.

@@ -20,7 +20,7 @@
 * [Red Hat Ansible Tower (AWX)](https://docs.ansible.com/ansible-tower/)
 * [Red Hat Ansible Tower (AWX) Installation and Reference Guide](http://docs.ansible.com/ansible-tower/latest/html/installandreference/index.html)
 * [Red Hat Ansible Tower (AWX) User Guide](http://docs.ansible.com/ansible-tower/latest/html/userguide/index.html)
- * [Red Hat Ansible Tower (AWX) Adminsitration Guide](http://docs.ansible.com/ansible-tower/latest/html/administration/index.html)
+ * [Red Hat Ansible Tower (AWX) Administration Guide](http://docs.ansible.com/ansible-tower/latest/html/administration/index.html)

 ### Red Hat Ansible Engine
  * [Ansible Documentation Overview](https://docs.ansible.com/)
@@ -11,7 +11,7 @@ The configuration management is done with Puppet as with RHEL8.

 Bugs and issues can be reported in the [Linux Issues project](https://gitea.psi.ch/linux/issues/issues).

-Additional ressource [Considerations in adopting RHEL 9](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/considerations_in_adopting_rhel_9/index#doc-wrapper)
+Additional resource [Considerations in adopting RHEL 9](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/considerations_in_adopting_rhel_9/index#doc-wrapper)


 ## Install Documentation
@@ -24,7 +24,7 @@ The future support model for AFS or the service and functionality it provides is


 ### Network Configuration
-By default the network configuration is handed over to NetworkManager which does automatic configuation.
+By default the network configuration is handed over to NetworkManager which does automatic configuration.

 If you wish different behaviour, e.g. for static IP addresses, please check out the [Network Configuration guide](../../configuration/basic/networking.md).

@@ -44,7 +44,7 @@ Provided disk size is 64GB for virtual machines.


 ### Workstation Package Groups
-Changed the ammount of packages installed by default on workstation installation. See the comparison below:
+Changed the amount of packages installed by default on workstation installation. See the comparison below:

 | RHEL 7&8 | RHEL 9 |
 | ---      | ---    |
@@ -3,7 +3,7 @@
 ## General Directives
 Regardless of the content of this documentation, all PSI directives have precedence and need to be applied/followed. Among others these are some of the most relevant ones regarding IT systems:

- [AW-95-06-01](https://DLS01P.PSI.CH/documents/jsp/qv?id=PSIcgc_fi20220000526102) / [AW-95-06-01e](https://DLS01P.PSI.CH/documents/jsp/qv?id=PSIcgc_fi20220000526095) Usage and Monitoring of IT Ressources at PSI
+- [AW-95-06-01](https://DLS01P.PSI.CH/documents/jsp/qv?id=PSIcgc_fi20220000526102) / [AW-95-06-01e](https://DLS01P.PSI.CH/documents/jsp/qv?id=PSIcgc_fi20220000526095) Usage and Monitoring of IT Resources at PSI
 - [AA-9500-142](https://DLS01P.PSI.CH/documents/jsp/qv?pri=PSIcgc&ft=cgcDocument@STORE_MAIN_CGC&q_cgcId=ID22023011616445798386)/[AA-9500-142e](https://DLS01P.PSI.CH/documents/jsp/qv?id=PSIcgc_fi20230003212302) Handling of Software Updates

 ## Version Control
@@ -12,7 +12,7 @@ Everything must be in version control before being used on production systems. I


 ## Hiera
-The naming of the variables inside Hiera depends on the scope usage of the variables. The variables beeing used only inside one specific class will be named `base_class_name::variable` where `base_class_name` is the last part of class name, without the part before the last `::` separator. Example: the `permit_root_login` variable for the `profile::ssh_server` class will be named `ssh_server::permit_root_login`.
+The naming of the variables inside Hiera depends on the scope usage of the variables. The variables being used only inside one specific class will be named `base_class_name::variable` where `base_class_name` is the last part of class name, without the part before the last `::` separator. Example: the `permit_root_login` variable for the `profile::ssh_server` class will be named `ssh_server::permit_root_login`.


 ## External Code
@@ -33,7 +33,7 @@ When putting system names into configuration files, we always use lower case and

 ## Software Update Policy

-It is in the responsibilty of the owner/administrator of a system to care about the software update policy and its application!
+It is in the responsibility of the owner/administrator of a system to care about the software update policy and its application!

 ### Automatic Updates

@@ -1,3 +1,3 @@
 # Admin Guide

-This is documenation relevant for system admins.
+This is documentation relevant for system admins.
@@ -1,6 +1,6 @@
 # Puppet Client

-The Puppet Agent updates the configuration on the node. It automatically runs regulary, for configuration details check the [configuration guide](../configuration/basic/puppet_agent).
+The Puppet Agent updates the configuration on the node. It automatically runs regularly, for configuration details check the [configuration guide](../configuration/basic/puppet_agent).

 The puppet client can be manually triggered/run by calling following command on the client:

@@ -30,7 +30,7 @@ The client will keep this environment until

 For testing purpose you might want to change the Puppet server to which a test node is attached to. To do so do, change the ``server`` in the ``[main]`` section of ``/etc/puppetlabs/puppet/puppet.conf`` accordingly.

-Then delete the current host and CA certficate and the CRL:
+Then delete the current host and CA certificate and the CRL:

 ```bash
 rm -f /etc/puppetlabs/puppet/ssl/certs/*
@@ -29,7 +29,7 @@ The following video shows all the necessary steps in detail. (The left terminal

 ![](puppet_environments/dev_environments.mp4)

-Once you are done with the develoment and testing create a merge request for the branch to the __preprod__ branch.
+Once you are done with the development and testing create a merge request for the branch to the __preprod__ branch.

 ### Development Environment Names

@@ -1,6 +1,6 @@
 # Mitigation copy.fail 
 !!!hint
-    The lastest RHEL kernels do not include the vulnerability anymore, so please update to `kernel-4.18.0-553.123.1.el8_10` (RHEL8) or `kernel-5.14.0-611.54.1.el9_7` (RHEL9).  
+    The latest RHEL kernels do not include the vulnerability anymore, so please update to `kernel-4.18.0-553.123.1.el8_10` (RHEL8) or `kernel-5.14.0-611.54.1.el9_7` (RHEL9).  
    **With this or newer kernels below mitigation is not required**.

 Following command can be used to disable the vulnerable feature in the current default kernel.
@@ -87,9 +87,9 @@ To remove multiple users at once you can also open a general Incident.
    - In case the user is not part of the group, the user needs to contact the respective responsible (i.e. beamline scientist in case of a beamline) to add him to the group. The management of the group membership is currently done in DUO.

 ### General
-Howto identify and kill high load sessions on the ssh gateway, useful commands for usage diagnostic:
+How to identify and kill high load sessions on the ssh gateway, useful commands for usage diagnostic:

-`top` or `htop` wil list heavy CPU consumers (see manpages for details)
+`top` or `htop` will list heavy CPU consumers (see manpages for details)
 `w` will list all user connections (see manpage for details)
 `w <username>` will list connections for a specific user
 
@@ -41,7 +41,7 @@ These files then can be accessed over `lxsup.psi.ch:/data/serial_console`.
 ## Send Grub Output to Serial Port

 For sending out Grub debug information over the serial port to a file because it is to much to fit the screen or for later inspection, you might do the following:
- in the Grub menue type `c` to get to the command line
+- in the Grub menu type `c` to get to the command line
 - configure the serial port with
 ```
 serial --unit=0 --speed=115200
@@ -22,7 +22,7 @@ If there is not DHCP, the static network information provided manually is possib

 ## Infiniband

-Infiniband can generally cause installation problem, expecially in the initial phase, when iPXE tries to load the configuration file. As a general rule, disable PXE on all Infiniband cards.
+Infiniband can generally cause installation problem, especially in the initial phase, when iPXE tries to load the configuration file. As a general rule, disable PXE on all Infiniband cards.

 Anyway this is not always enough since it happens that iPXE recognized anyway the Infiniband card as the first device (with MAC address ``79:79:79:79:79:79``) and tries to get configuration file for that.

@@ -19,7 +19,7 @@ because the PSI firewall only allows connections from a certain gateway, eg
 ## Known Errors

 ### Problematic `.bashrc`/`.bash_profile`
-Some people load a pmodule or a conda environment when bash is started. This can easily break the Gnome Startup as this can bring in incompatible tools and libraries. Suspicous is also setting the `LD_LIBRARY_PATH` environment variable. Once even `PATH` was the culprit because an incompatible `kinit` was used after.
+Some people load a pmodule or a conda environment when bash is started. This can easily break the Gnome Startup as this can bring in incompatible tools and libraries. Suspicious is also setting the `LD_LIBRARY_PATH` environment variable. Once even `PATH` was the culprit because an incompatible `kinit` was used after.


 ### pam_sss Errors
@@ -20,7 +20,7 @@ sr0
 #
 ```

-and configured in LVM as pysical volumes:
+and configured in LVM as physical volumes:

 ```
 # pvs
@@ -46,4 +46,4 @@ and the logical volumes:

 This [guide](https://www.suse.com/c/recovering-lost-lvm-volume-disk/) is rather helpful in doing so.

-If you miss pysical volumes you see in the block device setup (`lsblk --fs`), then you should check out if there is a `filter` setting in `/etc/lvm/lvm.conf` or some device files in `/etc/lvm/devices/`. If you want to see everything in the LVM tools you should remove these device files and the filter setting.
+If you miss physical volumes you see in the block device setup (`lsblk --fs`), then you should check out if there is a `filter` setting in `/etc/lvm/lvm.conf` or some device files in `/etc/lvm/devices/`. If you want to see everything in the LVM tools you should remove these device files and the filter setting.
@@ -64,7 +64,7 @@ Settings for ens160:
    Link detected: yes
 ```

-Link statistics (driver-specific, but look for errors/discards/dropped) can be aquired as follows:
+Link statistics (driver-specific, but look for errors/discards/dropped) can be acquired as follows:

 ```bash
 [root@lx ~]# ethtool -S ens160
@@ -22,7 +22,7 @@ Error: Transaction test error:
  file /usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json conflicts between attempted installs of egl-wayland-1.1.13.1-3.el9_8.x86_64 and egl-gbm-2:1.1.3-1.el9.x86_64
 ```

-the issue can be resolved by folling the steps below:
+the issue can be resolved by following the steps below:

 1. Install the egl-wayland package:
    ```bash
@@ -27,7 +27,7 @@ sssd-common-1.16.5-10.el7_9.12.x86_64
 ```
 Now you can try to remove one or both packages, maybe you need to remove also packages which depend on this one. Then install it again. 

-## Berkley DB Issue
+## Berkeley DB Issue

 ### BDB0087 DB_RUNRECOVERY

@@ -40,7 +40,7 @@ auth        optional      pam_echo.so "Have passed pam_localuser and pam_unix"

 ## PAM Call Stack with SystemTap

-When debugging an PAM issue with the RedHat support, they provided us a neat Systemtab script to create a PAM call stack of the `do_pam_setcred()` function in sshd. You find it [here](_static/para-callgraph-pam.stp).
+When debugging a PAM issue with the RedHat support, they provided us a neat SystemTap script to create a PAM call stack of the `do_pam_setcred()` function in sshd. You find it [here](_static/para-callgraph-pam.stp).

 For other PAM functions or other processes this script would need changes.

@@ -53,5 +53,5 @@ Finally a
 ```
 stap -x $PID -v ./para-callgraph-pam.stp
 ```
-will make the Systemtab script observe the given process `$PID`. On the first run it will fail and tell what debug packages it needs to have installed.
+will make the SystemTap script observe the given process `$PID`. On the first run it will fail and tell what debug packages it needs to have installed.

@@ -172,7 +172,7 @@ Create a new SELinux policy file for the events logged since the start of your t
 ausearch -ts 14:28 --raw | audit2allow -M my-application
 ```

-This will create a `my-application.te` policy file with the source code (e.g. to be modified and distributed with Ansible or Puppet) and the copiled `my-application.pp` policy file.
+This will create a `my-application.te` policy file with the source code (e.g. to be modified and distributed with Ansible or Puppet) and the compiled `my-application.pp` policy file.

 If you just need the TE source code as output (e.g. for Puppet), then do

@@ -3,7 +3,7 @@
 Users can be added to a unix group by this workflow:
 [SSH Gateway - User Guide](https://linux.psi.ch/services-user-guide/unix_groups)

-The administrators registered for a group will get an approval request email. Uppon approval the user will be automatically added to the group.
+The administrators registered for a group will get an approval request email. Upon approval the user will be automatically added to the group.

 You can also add users on their behalf. If you are one of the admins of the groups the request will be automatically approved (no need to approve it additionally)

@@ -2,7 +2,7 @@

 ## 27.01.2026 - Retirement Gitlab Services

-It is not possible any more to sign up for a payed access extensions for the Gitlab server git.psi.ch. The respective workflows mentioned in the previous announcements are retired now.
+It is not possible any more to sign up for a paid access extensions for the Gitlab server git.psi.ch. The respective workflows mentioned in the previous announcements are retired now.

 ## 30.09.2025 - End of Support RHEL7 30 June 2026

@@ -8,10 +8,10 @@ There are several types of accounts, which are usually indicated by a
 prefix or suffix:

 -   __Normal Account__ - No prefix or suffix. Older accounts are just last names, newer accounts are LASTNAME_X, where X is the first letter of the given name.
-   __Global Account (gac-accounts)__ - These have a `gac-` prefix. These are shared accounts where several people know the password. Note that some global accounts were originially experiment accounts and share the properties of experiment accounts
+-   __Global Account (gac-accounts)__ - These have a `gac-` prefix. These are shared accounts where several people know the password. Note that some global accounts were originally experiment accounts and share the properties of experiment accounts

 !!! warning
-    GAC accounts __must not__ be used for administrative tasks (also see: AW-95-17-02 Logical Access Control). Therefore membership in groups granting such privilidges is not permitted.
+    GAC accounts __must not__ be used for administrative tasks (also see: AW-95-17-02 Logical Access Control). Therefore membership in groups granting such privileges is not permitted.

 -   __Administrator Account__ - Marked with an `-adm` suffix.
 -   __External Users__ - These accounts start with an `ext-` prefix and are provided to external users, ie. those who are not PSI employees.
@@ -22,10 +22,10 @@ Official documentation on PSI IT account naming convention can be found [here](h

 To be able to easily distinguish between the different account types, a user shall be assigned to

-  | Unix Group         | Accont Type | Test User |
+  | Unix Group         | Account Type | Test User |
  |--------------------|-------------|-----------|
  | `unx-lx_users`     | normal user | `lx_test` |
-  | `unx-lx_adm_users` | administrator acccounts for normal users | `lx_test-adm` |
+  | `unx-lx_adm_users` | administrator accounts for normal users | `lx_test-adm` |
  | `unx-lx_gac_users` | global accounts | `gac-lx_test` |
  | `unx-lx_ext_users` | external accounts | `ext-lx_test` |
  | `unx-lx_ext_adm`   | external adm accounts (group should actually be named `unx-lx_ext_adm_users` but because of character limitations we abbreviated)| `ext-lx_test-adm`|
@@ -49,7 +49,7 @@ A GAC account is a:
  - Ensure the password is kept secret and only is known by authorized people
  - Ensure the password cannot be guessed, is according to password policies and is changed regularly

-GAC accounts __must not__ be used for administrative tasks (also see: AW-95-17-02 Logical Access Control). Therefore membership in groups granting such privilidges is not permitted.
+GAC accounts __must not__ be used for administrative tasks (also see: AW-95-17-02 Logical Access Control). Therefore membership in groups granting such privileges is not permitted.

 ## UID Allocation

@@ -53,7 +53,7 @@ here `lx-sysdb-test-00.psi.ch` which gets a hashed NetBIOS hostname
 ```
   3 05/12/23 08:39:15 lx-sysd-3563a67$@D.PSI.CH
 ```
-or `merlin-export-01.psi.ch` which has an automatically shortend NetBIOS name which was joined before we started to use the hashed NetBIOS hostnames:
+or `merlin-export-01.psi.ch` which has an automatically shortened NetBIOS name which was joined before we started to use the hashed NetBIOS hostnames:
 ```
   7 29.10.2019 11:24:04 MERLIN-EXPORT-0$@D.PSI.CH
 ```
@@ -15,7 +15,7 @@ As the network installation requires a TFTP boot server, the old server still ne
 1. rename the VM to *-old and create a new one
 2. update MAC address in https://gitea.psi.ch/lx/bootstrap/src/branch/prod/generate-pxe-uefi
 3. run `generate-pxe-uefi` and update the result in https://gitea.psi.ch/lx/network-boot or https://gitea.psi.ch/lx/network-boot-dmz
-4. ensure the kickstart files is also regenerated an availalbe on `lx-sync-01.psi.ch:/packages/kickstart`
+4. ensure the kickstart files is also regenerated an available on `lx-sync-01.psi.ch:/packages/kickstart`
 5. boot the new VM and let it install the OS
 6. as soon as the installer has started shut down the old server
 7. after reboot run `dnf upgrade`
@@ -2,7 +2,7 @@

 ## Overview
 DNS resolution is pointing to the F5/WAF for all services.
-HTTPS requests are terminated and inspected by the WAF, SSH is just proxied trough to have a simple DNS setup.
+HTTPS requests are terminated and inspected by the WAF, SSH is just proxied through to have a simple DNS setup.

 ![Gitea](gitea/gitea_setup_overview.png)

@@ -30,7 +30,7 @@ See the ansible code for more information.
 The service is deployed and updated with ansible bootstrap.
 To upgrade or downgrade a container or tinker with configurations, logo, frontpage template you can edit the respective files and run the playbook.
 When installing the service from scratch and it will fail when deploying the snippets, pages and runner container due to missing tokens.
-These tokens must be generated within the running Gitea instance first and added to `host_vars` for upgrade and configuration purposes the playbook is indempotent.
+These tokens must be generated within the running Gitea instance first and added to `host_vars` for upgrade and configuration purposes the playbook is idempotent.

 - Gitea Admin User
  - Create a Administrative User within the GUI or CLI
@@ -119,7 +119,7 @@ ENABLED=true
 ## Service Users
 Since local login is disabled, service users need to be created inside the gitea container with the gitea admin "console".
 There is two types of users, bot and regular. Bot users can only be used in Gitea CI/CD workflows, to "login" to gitea with a script or similar a regular user is needed.
-See commands bellow.
+See commands below.

 ```bash
 # connect to the container as user git
@@ -131,12 +131,12 @@ gitea admin user create --username {org-gitea} --email {username@psi.ch} --restr
 # create service user with random password and an access token for read operations
 gitea admin user create --username {org-gitea}  --access-token --access-token-name read --access-token-scopes read:repository,read:package,read:issue,read:misc --email yourmail@psi.ch --random-password --must-change-password=false

-# create a token with a give scope (scopes can be found here: https://gitea.psi.ch/user/settings/applications) that can be comma seperated but without spaces!
+# create a token with a give scope (scopes can be found here: https://gitea.psi.ch/user/settings/applications) that can be comma separated but without spaces!
 gitea admin user generate-access-token --username {org-gitea} --token-name {username-scope} --scopes {read|write:scope}
 ```

 ## Mapping AD Groups to Teams
-To realize access control with Active Directory groups in Gitea organizations a JSON file needs to edited in the admin pannel. This can be done as follows:
+To realize access control with Active Directory groups in Gitea organizations a JSON file needs to edited in the admin panel. This can be done as follows:

 1.  Navigate to: 'Site Administration -> Identity&Access -> Authentication Sources -> PSI LDAP -> "Map LDAP Groups.."
 ![step 1](_static/gitea_ldap_sync_step_1.png)
@@ -149,7 +149,7 @@ To realize access control with Active Directory groups in Gitea organizations a
 ![step 2](_static/gitea_ldap_sync_step_2.png)


-If you get an error message updateing, you probably made an error in formating the JSON (Commas or indentation)
+If you get an error message updating, you probably made an error in formatting the JSON (Commas or indentation)
 ```json
 {
    "CN=kst-1337,OU=Official,OU=Groups,OU=psi,DC=d,DC=psi,DC=ch": {
@@ -1,5 +1,5 @@
 # Gitea (Test)
-Documentation about the setup for reproducability.
+Documentation about the setup for reproducibility.
 There is an additional data disk, mapped to /srv that contains all Gitea data.
 All code can be found here: https://gitea-test.psi.ch/lx/Gitea

@@ -94,7 +94,7 @@ rm ./data/git/.gnupg/public-keys.d/pubring.db.lock

 ## Database
 Database just needs login information created beforehand and shared in gitea and db compose section and .env.
-SSL can be configured additionaly - Maybe todo?
+SSL can be configured additionally - Maybe todo?

 ## Pages
 Pages are exposed with a caddy webserver in a container that queries the Gitea API for the keyword `gitea-pages`. An application token needs to be created beforehand to start the container (I used the administrators account). 
@@ -15,7 +15,7 @@ We want to support monitoring of the Linux machines in Icinga2. The Icinga2 infr

 ## Automated Host Configuration

-The Linux part of the Icinga2 Master configuration is manged using Ansible in the [`icinga_master` role in the `bootstrap` repo](https://gitea.psi.ch/lx/bootstrap/src/branch/prod/ansible/roles/icinga_master).
+The Linux part of the Icinga2 Master configuration is managed using Ansible in the [`icinga_master` role in the `bootstrap` repo](https://gitea.psi.ch/lx/bootstrap/src/branch/prod/ansible/roles/icinga_master).

 For Puppet managed nodes there is an automated import pipeline using the Icinga Director. For the central infrastructure itself there is a predefined Configuration Basket snapshot which is installed by manual Ansible run.

@@ -54,7 +54,7 @@ It contains two parts:

 The import as such is triggered every 10 minutes by the `sysdb-director-import` timer.

-To avoid interference with manual Director change operations the import script checks first if there are no undeployed objects. If so it it will not run.
+To avoid interference with manual Director change operations the import script checks first if there are no undeployed objects. If so it will not run.

 A Director import pipeline needs first a Import Source which imports the data from an external source. The second element is the Sync Rule which then creates actual Director objects out of the data provided by one or more Import Sources

@@ -67,12 +67,12 @@ The pipeline for host groups imports the list of sysdb host groups and the filte
 The host import contains all the special configuration for a host. But there we need two sync rules, where `awi-lx-sysdb-host-sync-rule` creates and fills the host object.

 The second `awi-lx-sysdb-service-override-sync-rule` just fills `host.vars._override_servicevars` which the Director does not touch in the normal import.
-The reason is that this variable stores usually manual serice override changes made in Director, an those should survive normal imports. But as we also manage these in Hiera, we need a `Update only` sync rule which allows also to set this variable.
+The reason is that this variable stores usually manual service override changes made in Director, an those should survive normal imports. But as we also manage these in Hiera, we need a `Update only` sync rule which allows also to set this variable.

 ##### Director Import of Notification Users
 Here the actual user information comes from the AD. But as we do not import all users, but only those who want to be notified, we also need to modify what is being imported.

-An LDAP filter selects these users specificly. The filter has three sections:
+An LDAP filter selects these users specifically. The filter has three sections:
 - users we do not want (service users, etc)
 - departments we want
 - notification users for Linux machines
@@ -116,7 +116,7 @@ From our side we need the following manual setup
  - Author: `Core Linux Research Services`
  - Comment:
    ```
-    By default manged RHEL systems do not alert or send notifications, they just collect monitoring information in Icinga2.
+    By default managed RHEL systems do not alert or send notifications, they just collect monitoring information in Icinga2.
    To enable alerting, set in Hiera:
        icinga2::alerting::enable: true
    ```
@@ -23,7 +23,7 @@ To add a new metric source manually go about like this:
 ## Configuration

 ### Grafana Dashboard Management
-Dashboards can be automatically imported into grafana via files on the filesytem: https://grafana.com/docs/grafana/latest/administration/provisioning/#dashboards
+Dashboards can be automatically imported into grafana via files on the filesystem: https://grafana.com/docs/grafana/latest/administration/provisioning/#dashboards

 **/etc/grafana/provisioning/dashboards/importer.yaml**:
 ```yaml
@@ -272,20 +272,20 @@ Note, the `nxserver` is not in the PATH by default. Therefore it is necessary to

 # nx.psi.ch

-All administration tasks are more or less automated in: https://gitea.psi.ch/nomachine/nomachine_ansible. Please refere to the documentation there to add/remove rules/nodes, etc.
+All administration tasks are more or less automated in: https://gitea.psi.ch/nomachine/nomachine_ansible. Please refer to the documentation there to add/remove rules/nodes, etc.

 SSH access to nx.psi.ch is only possible via mgt-gw.psi.ch

 Following things are good to know regarding nx.psi.ch:

- If a node gets reinstalled it needs to be removed / readded to nx.psi.ch
+- If a node gets reinstalled it needs to be removed / re-added to nx.psi.ch
 - If there is no rule for a node everybody that can login on that node can access this node! (therefore each node needs a no access default rule)
 - Get members of a group:
  ```
  getent group svc-nx | sed -e 's/^svc-nx:\*:35341://g' | tr ',' '\n' | sort
  ```
 - A node that is attached to a Cloud Server instance cannot be connected to another Cloud Server instance
- Whether a node can be connected directly (regardless whether it is attached to a Cloud/Teminal Server instance ) depends on the nodes configuration
+- Whether a node can be connected directly (regardless whether it is attached to a Cloud/Terminal Server instance ) depends on the nodes configuration
 - There is a notification mechanism inside NX Cloud Server (e.g. to inform users about upcoming downtimes)


@@ -1,6 +1,6 @@
 # NoMachine - Configuration

-To install and configure nomachine vie hiera following variables are needed:
+To install and configure nomachine via hiera following variables are needed:

 ```yaml
 base::enable_nomachine: true
@@ -122,7 +122,7 @@
                    <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 245px; margin-left: 241px;">
                        <div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;">
                            <div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: none; font-style: italic; white-space: normal; overflow-wrap: normal;">
-                                node randomly choosen
+                                node randomly chosen
                                <br/>
                                or re-connect to existing connection
                            </div>
@@ -31,7 +31,7 @@ This usecase covers:
 ## nomachine-proxy
 nomachine-proxy is a service for whole PSI. It is usually used as a bridge between Windows consoles and Linux world. The main user (historically and by need) is GFA. They usually use this service to ssh to other computers to open applications for monitoring/steering the GFA accelerators. 

-nomachine-proxy was a replacement of gfa-nx service, the main purpose was as a bridge between Windwows desktops and the Linux world. From the beginning it was postulated that nomachine-proxy nodes will be small virtual machines, that users shouldn't use for computational intensive purposes. The amount of software on the nodes will be "reasonable" for purpose of interactive work (editiing small files, browsing internal pages, jumping to other hosts etc..). We added few software on user requests:
+nomachine-proxy was a replacement of gfa-nx service, the main purpose was as a bridge between Windwows desktops and the Linux world. From the beginning it was postulated that nomachine-proxy nodes will be small virtual machines, that users shouldn't use for computational intensive purposes. The amount of software on the nodes will be "reasonable" for purpose of interactive work (editing small files, browsing internal pages, jumping to other hosts etc..). We added few software on user requests:
 https://gitea.psi.ch/puppet/data-lx

 Since user can't choose which node to login via nomachine, user home is shared on all these nodes(from netapp), with a very small quota (this is usually a problem for users, since they use firefox on that nodes and cache occupies that quota):
@@ -51,7 +51,7 @@ nodes provide a minimal desktop with a browser but no additional tools

 ## merlin-nx

-merlin-nx is used by internal and external users. The main usecase is for preparing jobs, submitting jobs, post-processing and visualization to the merlin cluster. Some applications are pretty heavy if they have to open it through SSH with X11 forwarding, NoMachine is mainly used for such use cases instead. But also there are users using the Merlin desktop as their daily way of working (even for submitting command line based jobs).  3D acceleration is a common use case for visualzation, therefore, GPU card is in general preferred.
+merlin-nx is used by internal and external users. The main usecase is for preparing jobs, submitting jobs, post-processing and visualization to the merlin cluster. Some applications are pretty heavy if they have to open it through SSH with X11 forwarding, NoMachine is mainly used for such use cases instead. But also there are users using the Merlin desktop as their daily way of working (even for submitting command line based jobs).  3D acceleration is a common use case for visualization, therefore, GPU card is in general preferred.

 Typical X-based software used in NoMachine are ANSYS, Relion, Paraview, Matlab and Gothic. Using NoMachine for submitting jobs (allocations) with X11 forwarding to the cluster it's also commonly used (ANSYS, Paraview).

@@ -20,7 +20,7 @@ specific projects, since profiles should be generic enough to be
 reusable.


-Components are gernerally useful Puppet modules and they reside in an own git repository and are handled like any other externally used module.
+Components are generally useful Puppet modules and they reside in an own git repository and are handled like any other externally used module.


 ## Hiera queries
@@ -88,7 +88,7 @@ You can use the `erb` tool to test the variable interpolation. One easy way is t
 %>
 ```

-and then use a commmand line like the following to pipe it through `erb`
+and then use a command line like the following to pipe it through `erb`

 ```
 erb <(cat /tmp/test-vars.erb /tmp/my-template.erb)
@@ -1,7 +1,7 @@

 # Overview

-Puppet is used in master mode and the general idea is to make large use of independent and (relatively) small puppet modules and composing profiles and roles based on them to create classes that are assigned to the hosts. By independence of puppet modules we mean that each puppet module targets a single functionality (eg. `web server`, `grafana server`) and this is choosen to keep the code of the single module smaller, more coherent and easier to debug.
+Puppet is used in master mode and the general idea is to make large use of independent and (relatively) small puppet modules and composing profiles and roles based on them to create classes that are assigned to the hosts. By independence of puppet modules we mean that each puppet module targets a single functionality (eg. `web server`, `grafana server`) and this is chosen to keep the code of the single module smaller, more coherent and easier to debug.

 Furthermore the system makes use of some puppet modules from the [puppet forge](https://forge.puppet.com). These puppet modules are not accessed directly but through a PSI mirror.

@@ -13,7 +13,7 @@ At https://puppet.psi.ch/ , a small web app to delete server side certificates i

 ## Branches

-You can create a branch to develop new code from the master branch of the puppet repository. To test the code, a directory with the same name as the branch can be created at puppet:/srv/puppet/code/dev/envs/ . Upon creating the directory, preprod gets rsynced in here. If the branch alrady exists and if it's to be pulled, that can be done via the command:
+You can create a branch to develop new code from the master branch of the puppet repository. To test the code, a directory with the same name as the branch can be created at puppet:/srv/puppet/code/dev/envs/ . Upon creating the directory, preprod gets rsynced in here. If the branch already exists and if it's to be pulled, that can be done via the command:

 ```
 git pull origin xyz
@@ -32,7 +32,7 @@ This is a bit tricky because the automated process wants to load from ISO and pa
 1. rename the VM to *-old and create a new one
 2. update MAC address in https://gitea.psi.ch/lx/bootstrap/src/branch/prod/generate-pxe-uefi
 3. run `generate-pxe-uefi` and update the result in https://gitea.psi.ch/lx/network-boot or https://gitea.psi.ch/lx/network-boot-dmz
-4. ensure the kickstart files is also regenerated an availalbe on `lx-sync-01.psi.ch:/packages/kickstart`
+4. ensure the kickstart files is also regenerated an available on `lx-sync-01.psi.ch:/packages/kickstart`
 5. on `lx-sync-01.psi.ch:/packages/kickstart` modify the respective kickstart file by removing all manual IP configuration and changing to `--bootproto=dhcp` to make it get an dynamic IP which does not conflict with the one used by the old server
 6. boot the new VM and let it install the OS
 7. get the dynamcially assigned IP from vSphere
@@ -67,7 +67,7 @@ The steps to create and configure a new **GIT** project are:
        ```
    - for the runner configuration check out the new Hiera data repo and add `.gitea/workflows/hiera_update.yaml` from [another one](https://gitea.psi.ch/puppet/data-lx/raw/branch/master/.gitea/workflows/hiera_update.yaml).

-3. Disable unnecesary Gitea features
+3. Disable unnecessary Gitea features
   - In `data-<environment_name` -> `Settings`, or directly: https://gitea.psi.ch/puppet/data-(environment_name)/settings:
       - untick `Enable Repository Wiki`
       - untick `Enable Projects`
@@ -10,7 +10,7 @@ On these systems there is currently only the [`lxdev` Hiera environment](https:/

 To get a node to boot into the test setup, you need a special network boot configuration for grub in the [`network-boot` repo](https://gitea.psi.ch/lx/network-boot).
 Best do in `grub.d` a symlink from the full qualified hostname to `use-sysdb-test`.
-Then in the root directory you need another symlink from `grub.cfg-01-$MAC` (use dashes instead of colons to separte the MAC address bytes) to the symlink with your hostname in `grub.d`. This last file is looked up by grub during network boot. The symlink cascade is to know what MAC address belongs to what host and what is the intend of the special configuration.
+Then in the root directory you need another symlink from `grub.cfg-01-$MAC` (use dashes instead of colons to separate the MAC address bytes) to the symlink with your hostname in `grub.d`. This last file is looked up by grub during network boot. The symlink cascade is to know what MAC address belongs to what host and what is the intend of the special configuration.

 ## Icinga2 Test Server

@@ -16,7 +16,7 @@ and then use `tcpdump -i ens192 ...`

 ## Accounts

-### AD Attributres / Login Information
+### AD Attributes / Login Information
 There are some Active directory attributes that are not synced between the different ActiveDirectory servers. This results in the fact, that depending on which Active Directory server answers your query you might get different answers back. The not synced attributes include:

 - badPasswordTime
@@ -29,7 +29,7 @@ These attributes are synced:
 - whenCreated
 - whenChanged

-### Pasword Reset e-account
+### Password Reset e-account

 A usual password reset of an e-accounts in DUO need max 5 minutes to be visible on all PSI systems.
 (IAM checks every minute for DUO jobs + IAM workflow execution time + AD distribution time)
@@ -25,7 +25,7 @@ On both servers there are symlinks from `/opt/WebHosting/nginx.conf -> /etc/ngin

 ### Docker Compose

-The docker network is segmented with docker networks. These can be seen at the bottom of the compose file. It is concidered best practice to put a DB that is only used by one service into its own "backend". An example can be gathered from hedgedoc.
+The docker network is segmented with docker networks. These can be seen at the bottom of the compose file. It is considered best practice to put a DB that is only used by one service into its own "backend". An example can be gathered from hedgedoc.

 ### Deployment lx-docker-01.psi.ch

@@ -27,9 +27,9 @@ There are 3 Email mailing lists that can be used for communication

 - __[linux-eng@psi.ch](mailto:linux-eng@psi.ch)__: This is the mailing list of the AWI Linux Core Team

- __[linux-announce@lists.psi.ch](mailto:linux-announce@lists.psi.ch)__: All people can subscribe to this list via [sympa](https://psilists.ethz.ch/sympa/info/linux-announce). It is intendet for outgoing communication to everybody that is interested in linux topics
+- __[linux-announce@lists.psi.ch](mailto:linux-announce@lists.psi.ch)__: All people can subscribe to this list via [sympa](https://psilists.ethz.ch/sympa/info/linux-announce). It is intended for outgoing communication to everybody that is interested in linux topics

- __[linux@psi.ch](mailto:linux@psi.ch)__: This is a mailing list for incoming messages and/or for internal discussion. This list (it is a Outlook/Exchange managed distribution list) only contains the people that are regarded as the core team. If you want to be part of that team, drop an email stating so to this list!
+- __[linux@psi.ch](mailto:linux@psi.ch)__: This is a mailing list for incoming messages and/or for internal discussion. This list (it is an Outlook/Exchange managed distribution list) only contains the people that are regarded as the core team. If you want to be part of that team, drop an email stating so to this list!


 ## Documentation / Knowledgebase
@@ -17,8 +17,8 @@ We rely on industry standards and professional solutions to ensure the sustainab
 ## Security and Compliance

 - **Action**: We work on eliminating/upgrade/... vulnerable systems and services.
- **Support**: We provide latest updates. We provide our skills and knowhow for vulnerability and icident analyis.
- **Security Policies**: Establish Linux-specific security policies and procedures (e.g., user permissions, firewall settings) to make PSI resilient and robust to cyber threads.
+- **Support**: We provide latest updates. We provide our skills and knowhow for vulnerability and incident analysis.
+- **Security Policies**: Establish Linux-specific security policies and procedures (e.g., user permissions, firewall settings) to make PSI resilient and robust to cyber threats.
 - **Compliance**: Our Linux systems should/must comply with relevant regulatory requirements (e.g., GDPR, HIPAA).

 ## Standardization and Deployment
@@ -35,7 +35,7 @@ We rely on industry standards and professional solutions to ensure the sustainab
 ## Monitoring and Performance Tuning

 - **Monitoring Tools**: Deploy monitoring tools to track Linux system performance and health.
- **Performance Optimization**: We provide our skills and knowhow to analize performance problems.
+- **Performance Optimization**: We provide our skills and knowhow to analyse performance problems.

 ## Training and Support
 - **Training**: Organize training sessions and workshops to enhance Linux skills within PSI.
@@ -48,7 +48,7 @@ We rely on industry standards and professional solutions to ensure the sustainab
 - **Backup Solutions**: We rely and implement robust backup solutions for critical Linux data and configurations. (provided by other PSI teams)
 - **Disaster Recovery**: Develop our system for easy disaster recovery.

-## Continous Improvement
+## Continuous Improvement

 - **Feedback Loop**: Establish a feedback loop to gather insights from users and stakeholders for continuous improvement.
 - **Periodic Reviews**: Conduct periodic reviews of our strategy and services to adapt to evolving needs and technological advancements. (? do we or our management do that?)
@@ -7,10 +7,10 @@ Authentication on the GUI (gitea.psi.ch) only works with a PSI account in EntraI
 The UPN of a PSI user is its email address
 Password
 PSI MFA
-If you are logged in to outlook or any other PSI application that uses MFA you will be logged in automaticaly!
+If you are logged in to outlook or any other PSI application that uses MFA you will be logged in automatically!

 ### SSH
-RSA keys must be longer than 3000 bits! We suggest you create a eliptic curve key: 'ssh-keygen -t ed25519'
+RSA keys must be longer than 3000 bits! We suggest you create a elliptic curve key: 'ssh-keygen -t ed25519'

 To clone a repo or change its remote to SSH you can use this commands

@@ -25,11 +25,11 @@ GIT with HTTPS can be done with a Personal Access Token created here: https://gi
 - Password is your created token

 ## External User
-External users must be created in DUO or via HR, otherwise they are not automatically synced to the correct access group: m365-app_git_rest. If this group is missing the user wont be able to login.
+External users must be created in DUO or via HR, otherwise they are not automatically synced to the correct access group: m365-app_git_rest. If this group is missing the user won't be able to login.
 Open a SNOW Ticket to get your user in that group or contact the AD Team.

 ### GUI
-The UPN of a external user is 'ext-user_name@psi.ch'
+The UPN of an external user is 'ext-user_name@psi.ch'
 Password
 PSI MFA

@@ -72,7 +72,7 @@ The gitea token will then be mailed to you. If you are searching for the user in
 - A valid E-Mail (this can be an email address that does not exist in reality) that is not registered yet in Gitea


-### Challenges of using PAT on a external collaboration platform and its alternatives
+### Challenges of using PAT on an external collaboration platform and its alternatives

 User access tokens acting like a password to all resources the user has access to. This can be dangerous. (The reason MFA login is enforced)

@@ -131,7 +131,7 @@ https://gitea.psi.ch/bruhn_b/submodules-fix
 This is not production tested and needs a bit more love to fix all branches and tags.


-## Miscellanious
+## Miscellaneous

 ### I use Firefox and SSO does not work

@@ -23,7 +23,7 @@ Migration:
 - Choose the Source you want to migrate from
 - Enter the HTTPS clone URL
 - On the source you need to create an access token for that project
-  - Token to migrate a single project [How to create a project accesss token in Gitlab](https://docs.gitlab.com/user/project/settings/project_access_tokens/#create-a-project-access-token)
+  - Token to migrate a single project [How to create a project access token in Gitlab](https://docs.gitlab.com/user/project/settings/project_access_tokens/#create-a-project-access-token)
  - Tokens can also be created for groups.
  - Token to migrate multiple projects you have permissions on [How to create a personal access token in Gitlab](https://docs.gitlab.com/user/profile/personal_access_tokens/#create-a-personal-access-token)
 - Paste the token in "Access Token"
@@ -24,7 +24,7 @@ More details about this action can be found at https://gitea.psi.ch/actions/uplo

 Every organization has its own (docker) container registry.

-Here some examples how to work with the Container registry that is build into gitea.psi.ch:
+Here some examples how to work with the Container registry that is built into gitea.psi.ch:

 ```bash
 # login to the gitea container registry
@@ -41,7 +41,7 @@ docker pull gitea.psi.ch/{owner}/{image}:{tag}
 docker run -it --rm gitea.psi.ch/{owner}/{image}:{tag}
 ```

-You can automatically build an push a container into the registry via a gitea action workflow. An example you can find here:
+You can automatically built an push a container into the registry via a gitea action workflow. An example you can find here:

 https://gitea.psi.ch/images/alpine-mkdocs/src/branch/main/.gitea/workflows/build_push.yaml

@@ -7,7 +7,7 @@ Our runners can run different docker images for your workflows please refer to h
 If none of the default runners available suits you, you can contact [Gitea Project](mailto:gitea@psi.ch) and we can find a solution that fits you best.

 ## Actions
-Actions can sometimes be used from GitHub, but are likely to break. There are some actions in https://gitea.psi.ch/actions that are proven working. Also you can checkout https://gitea.com/actions/ and if you find any usefull to you we can mirror these. [Gitea Project](mailto:gitea@psi.ch)
+Actions can sometimes be used from GitHub, but are likely to break. There are some actions in https://gitea.psi.ch/actions that are proven working. Also you can checkout https://gitea.com/actions/ and if you find any useful to you we can mirror these. [Gitea Project](mailto:gitea@psi.ch)

 ## Custom Runner

@@ -6,7 +6,7 @@ Since Gitea has no way to publish snippets we introduce snippets.psi.ch
 When you press "Continue with PSI Gitea account" the Auth token used with Gitea will be reused to login to snippets. 
 Snippets can be read by anonymous users / services but only created by a logged in user.

- Public, every logged in User can browse your snippets in the "All" menue.
+- Public, every logged in User can browse your snippets in the "All" menu.
 - Unlisted, the snippet is only visible with a direct link.
 - Private, the snippet is only visible to you.

@@ -11,9 +11,9 @@ Following settings allow/restrict access to projects:
 - Public
  - Enables read access to unauthenticated users (Also from the internet)
 - Limited
-  - Visible to authenticated internal users (potentialy all PSI users excluding external users)
+  - Visible to authenticated internal users (potentially all PSI users excluding external users)
 - Private
-  - Visible to explicitely added users
+  - Visible to explicitly added users

 More can be found here:  https://docs.gitea.com/usage/permissions
 If you want to have an AD (Active Directory) Group attached to a team you may contact [Gitea Project](mailto:gitea@psi.ch).
@@ -1,6 +1,6 @@
 # gmgt.psi.ch

-gmgt.psi.ch is the jumphost to reach GMGTW (WinSRV) via RDP or iLO (https:443) in the GFA managment network.
+gmgt.psi.ch is the jumphost to reach GMGTW (WinSRV) via RDP or iLO (https:443) in the GFA management network.

 The access group is manually managed via puppet/hiera: https://gitea.psi.ch/puppet/data-lx/src/branch/master/default/lx-gmgt-01.psi.ch.yaml 

@@ -6,7 +6,7 @@ Instead of accessing pypi.org directly PSI provides a caching proxy for pypi pac

 1. Speed - the caching proxy might/will improve the dependency resolution and download speed for installing packages
 2. Once downloaded/installed packages will still be available even if they are not accessible on the internet any more.
-3. Accessibility - pypi.psi.ch is accessible from all PSI networks (including the onces without internet access)
+3. Accessibility - pypi.psi.ch is accessible from all PSI networks (including the ones without internet access)

 ###  Usage
 The url to use the CachingProxy is: https://pypi.psi.ch/simple:
@@ -36,7 +36,7 @@ To check whether your pip client is using this address you can simply issue a:
 pip install -h
 ```

-Check whats written in the descripiton of the option --index-url:
+Check what's written in the descripiton of the option --index-url:

 ```bash
 % pip install -h | grep -A5 index-url 
@@ -1,7 +1,7 @@
 # Webhooks to Microsoft Teams
-For the old MessageCard format used by some Apps - See the code snippet bellow.
+For the old MessageCard format used by some Apps - See the code snippet below.

-Flows are always owned by its creator. Make sure to share it with people from your team. More information to that bellow.
+Flows are always owned by its creator. Make sure to share it with people from your team. More information to that below.

 ## Configuring
 Login to https://make.powerautomate.com/ with your AD Account used at PSI.
@@ -10,7 +10,7 @@ Login to https://make.powerautomate.com/ with your AD Account used at PSI.
    - There might be also a tst and prd environment. These are for agents and or powerbi workflows.
 2. Click on Templates to the left and search for "Webhook", choose "Send webhook alerts to a channel" or "Send webhook alerts to a chat"
 3. The flow will connect to Microsoft Teams -> Continue -> Create (Its a known bug that in non default Environments the chat / channel dialog is skipped. We configure it later)
-4. Click Edit in the top left and delete all charts except the "When a Teams webhook request is recieved"
+4. Click Edit in the top left and delete all charts except the "When a Teams webhook request is received"
 ![Should look like this](MS_Teams_Webhooks/cleanup.png)
 5. Click the "+" and search for "Card" and choose "Post card in chat or channel"
 ![Visual Helper](MS_Teams_Webhooks/card.png)
@@ -5,7 +5,7 @@ Beamline consoles are the crucial systems to operate a beamline at one of PSIs'

 ## Access Control

-Consoles follow a strict access control design. Nobody has access to to beamline resources/systems except she/he is member of one of the following groups:
+Consoles follow a strict access control design. Nobody has access to beamline resources/systems except she/he is member of one of the following groups:

 - `unx-sls_<beamline>`
 - `unx-sls_beamline>_bs`
@@ -38,7 +38,7 @@ The consoles will have following directory structures available
 ```bash
 /<facility>/<beamline>
 /<facility>/<beamline>/bin              # this folder is automatically in the PATH
-/<facility>/<beamline>/config           # configration data for applications
+/<facility>/<beamline>/config           # configuration data for applications
 /<facility>/<beamline>/applications     # beamline applications and scripts
 /<facility>/<beamline>/data             # beamline data
 /<facility>/<beamline>/data/<pgroup>
@@ -136,7 +136,7 @@ From outside PSI connections can be established in two ways, VPN or via SSH/hopx

 #### SSH/hopx.psi.ch

-Connections via hopx.psi.ch can be establised as follows:
+Connections via hopx.psi.ch can be established as follows:

 1. Open an interactive session to hopx.psi.ch and leave this session open!

@@ -180,7 +180,7 @@ The experiment data is stored in `/<facility>/<beamline>/data/<pgroup>/raw` and

 ### My included TIFF files in CAQTM is doesn't work / looking ugly...

-TIFF is not a supported CAQTM file format (see official communication Controls). Issues might be temporarily resolved by installing particualr qt packages (which need to be named and requested by you/beamline). However we recommend to not use TIFFs in CAQTDM so that you have full support from Controls.
+TIFF is not a supported CAQTM file format (see official communication Controls). Issues might be temporarily resolved by installing particular qt packages (which need to be named and requested by you/beamline). However we recommend to not use TIFFs in CAQTDM so that you have full support from Controls.

 ### How to configure an application to start at login?

@@ -5,7 +5,7 @@ The usual place to set environment variables is `~/.bashrc`, but these variables
 To influence all user spawned processes, you might add one or more `*.conf` files into
 `~/.config/environment.d/`. 

-Following example (`~/.config/environment.d/swiss.conf`) keeps all texts in original English, but changes date/date/paper sizes and other formating elements to what is usual locally in Switzerland:
+Following example (`~/.config/environment.d/swiss.conf`) keeps all texts in original English, but changes date/date/paper sizes and other formatting elements to what is usual locally in Switzerland:

 ```
 LC_ADDRESS=de_CH.UTF-8
@@ -21,7 +21,7 @@ LC_NUMERIC=de_CH.UTF-8
 ```
 See the [manual](https://www.freedesktop.org/software/systemd/man/latest/environment.d.html#Configuration%20Format) about more details of the configuration format.

-Also be aware you need to have these files locally in your home directory, you cannot use links to your `U:`-drive from the ["Partially Shared Home"-feature](partially_shared_home) because they are not availabe so early in the session setup process.
+Also be aware you need to have these files locally in your home directory, you cannot use links to your `U:`-drive from the ["Partially Shared Home"-feature](partially_shared_home) because they are not available so early in the session setup process.

 Note this does not work on RHEL7.

@@ -14,7 +14,7 @@ The package `evolution-ews` needs to be installed before starting.

 ## Configure Your Mail Account

-If you first open Evolution you get automatically to the "Mail Configuration Assistant", else you select in the "Edit" menu "Accounts", and then klick the "+Add" dropdown and select `Mail Account`. Then you should get
+If you first open Evolution you get automatically to the "Mail Configuration Assistant", else you select in the "Edit" menu "Accounts", and then click the "+Add" dropdown and select `Mail Account`. Then you should get

 ![Welcome](evolution_for_o365/evolution01_wizard_welcome.png)

@@ -60,5 +60,5 @@ The solution does a bind mount from `~/.mozilla/firefox_$FQDN` to `~/.mozilla/fi

 One can install both the RHEL 7 and the RHEL 8 solution at the same time, they are tolerant to each other.

-The special solution for RHEL 7 is required because Red Hat patched out the support for `systemd --user`. An issue with this solution is that the bind mount is never cleared. It is ensured that there is only one per user, but this one stays until the machine shuts down or it is manually unmounted. But the the tool is slim and uses less than 1 MB resident memory per instance.
+The special solution for RHEL 7 is required because Red Hat patched out the support for `systemd --user`. An issue with this solution is that the bind mount is never cleared. It is ensured that there is only one per user, but this one stays until the machine shuts down or it is manually unmounted. But the tool is slim and uses less than 1 MB resident memory per instance.