From bccf7200994ef0289e5f107ff4f0507415f0766b Mon Sep 17 00:00:00 2001 From: pombas_n Date: Mon, 28 Sep 2026 17:14:01 +0200 Subject: [PATCH] fixed all typos --- Readme.md | 4 ++-- .../configuration/access/bastion_hosts.md | 2 +- docs/admin-guide/configuration/access/mfa.md | 2 +- .../configuration/access/sshd_configuration.md | 2 +- docs/admin-guide/configuration/access/sudo.md | 2 +- .../configuration/access/system_access.md | 2 +- .../configuration/basic/ad_integration.md | 2 +- .../configuration/basic/configuration_email.md | 4 ++-- .../basic/gssproxy_with_keytab.md | 2 +- .../configuration/basic/host_rename.md | 2 +- .../configuration/basic/networking.md | 12 ++++++------ .../configuration/basic/ntp_server.md | 2 +- .../admin-guide/configuration/desktop/dconf.md | 2 +- .../configuration/desktop/desktop.md | 2 +- .../configuration/desktop/program_starter.md | 2 +- docs/admin-guide/configuration/desktop/xrdp.md | 8 ++++---- docs/admin-guide/configuration/files/autofs.md | 2 +- .../files/central_storage_mount.md | 2 +- .../configuration/files/distribute_files.md | 10 +++++----- docs/admin-guide/configuration/files/mount.md | 2 +- .../configuration/files/partitioning.md | 2 +- docs/admin-guide/configuration/https/acme.md | 16 ++++++++-------- .../configuration/monitoring/icinga2.md | 14 +++++++------- .../configuration/monitoring/journald.md | 4 ++-- .../software/custom_repositories.md | 2 +- .../software/environment_modules.md | 2 +- .../configuration/software/mathematica.md | 4 ++-- .../software/package_repositories.md | 14 +++++++------- .../configuration/software/packagekit.md | 2 +- .../configuration/software/packages.md | 6 +++--- .../configuration/software/pmodules.md | 6 +++--- .../configuration/software/python.md | 6 +++--- .../software/selinux_configuration.md | 4 ++-- .../configuration/software/services.md | 4 ++-- .../configuration/software/timers.md | 4 ++-- docs/admin-guide/consoles.md | 4 ++-- docs/admin-guide/container.md | 6 +++--- docs/admin-guide/custom_repositories.md | 6 +++--- .../deployment/advanced_installation.md | 2 +- .../deployment/basic_installation.md | 6 +++--- .../admin-guide/deployment/dmz_installation.md | 2 +- docs/admin-guide/deployment/re_installation.md | 2 +- docs/admin-guide/deployment/rhel8/desktop.md | 4 ++-- docs/admin-guide/deployment/rhel8/index.md | 4 ++-- docs/admin-guide/deployment/rhel8/kerberos.md | 18 +++++++++--------- docs/admin-guide/deployment/rhel8/nvidia.md | 10 +++++----- .../deployment/rhel8/vendor_documentation.md | 2 +- docs/admin-guide/deployment/rhel9/index.md | 6 +++--- docs/admin-guide/guidelines.md | 6 +++--- docs/admin-guide/index.md | 2 +- docs/admin-guide/puppet/puppet_client.md | 4 ++-- docs/admin-guide/puppet/puppet_environments.md | 2 +- .../security/mitigation_copyfail.md | 2 +- docs/admin-guide/ssh_gateways.md | 4 ++-- docs/admin-guide/troubleshooting/boot.md | 2 +- docs/admin-guide/troubleshooting/deployment.md | 2 +- docs/admin-guide/troubleshooting/login.md | 2 +- docs/admin-guide/troubleshooting/lvm.md | 4 ++-- docs/admin-guide/troubleshooting/network.md | 2 +- docs/admin-guide/troubleshooting/nvidia.md | 2 +- docs/admin-guide/troubleshooting/packages.md | 2 +- docs/admin-guide/troubleshooting/pam.md | 4 ++-- docs/admin-guide/troubleshooting/selinux.md | 2 +- docs/admin-guide/unix_groups.md | 2 +- docs/announcements/index.md | 2 +- docs/engineering-guide/accounts-and-groups.md | 10 +++++----- docs/engineering-guide/active-directory.md | 2 +- docs/engineering-guide/boot_server.md | 2 +- docs/engineering-guide/gitea-dmz.md | 12 ++++++------ docs/engineering-guide/gitea.md | 4 ++-- docs/engineering-guide/icinga2.md | 10 +++++----- docs/engineering-guide/metrics.md | 2 +- .../nx_nomachine/administration.md | 6 +++--- .../nx_nomachine/configuration.md | 2 +- .../overview_nomachine-proxy.drawio.svg | 2 +- .../engineering-guide/nx_nomachine/usecases.md | 4 ++-- docs/engineering-guide/puppet/modules.md | 4 ++-- docs/engineering-guide/puppet/overview.md | 2 +- docs/engineering-guide/puppet_server.md | 2 +- docs/engineering-guide/repo_server.md | 2 +- docs/engineering-guide/sysdb_environments.md | 2 +- docs/engineering-guide/test_systems.md | 2 +- docs/engineering-guide/troubleshooting.md | 4 ++-- docs/engineering-guide/webhosting.md | 2 +- docs/index.md | 4 ++-- docs/management/strategy.md | 8 ++++---- docs/services/gitea/authentication.md | 8 ++++---- docs/services/gitea/gitea-faq.md | 4 ++-- docs/services/gitea/gitea-migration.md | 2 +- docs/services/gitea/gitea-packages.md | 4 ++-- docs/services/gitea/gitea-runner.md | 2 +- docs/services/gitea/gitea-snippets.md | 2 +- docs/services/gitea/index.md | 4 ++-- docs/services/gmgt.md | 2 +- docs/services/python.md | 4 ++-- docs/user-guide/MS_Teams_Webhooks.md | 6 +++--- docs/user-guide/consoles.md | 8 ++++---- docs/user-guide/env_variables.md | 4 ++-- docs/user-guide/evolution_for_o365.md | 2 +- docs/user-guide/firefox_profile_per_host.md | 2 +- docs/user-guide/index.md | 2 +- docs/user-guide/kerberos_lifetime.md | 2 +- docs/user-guide/personal_drive.md | 6 +++--- docs/user-guide/putty.md | 4 ++-- docs/user-guide/ssh_client_config.md | 4 ++-- docs/user-guide/ssh_host_key_certificates.md | 4 ++-- docs/user-guide/ssh_to_legacy_linux.md | 4 ++-- docs/user-guide/thunderbird_for_o365.md | 8 ++++---- docs/user-guide/xrdp.md | 10 +++++----- 109 files changed, 231 insertions(+), 231 deletions(-) diff --git a/Readme.md b/Readme.md index 7a8fa843..30c96220 100644 --- a/Readme.md +++ b/Readme.md @@ -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: ``` diff --git a/docs/admin-guide/configuration/access/bastion_hosts.md b/docs/admin-guide/configuration/access/bastion_hosts.md index c0b93152..801fecc3 100644 --- a/docs/admin-guide/configuration/access/bastion_hosts.md +++ b/docs/admin-guide/configuration/access/bastion_hosts.md @@ -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`. diff --git a/docs/admin-guide/configuration/access/mfa.md b/docs/admin-guide/configuration/access/mfa.md index a741a1b1..6b98609f 100644 --- a/docs/admin-guide/configuration/access/mfa.md +++ b/docs/admin-guide/configuration/access/mfa.md @@ -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) diff --git a/docs/admin-guide/configuration/access/sshd_configuration.md b/docs/admin-guide/configuration/access/sshd_configuration.md index 32405c1b..6884c195 100644 --- a/docs/admin-guide/configuration/access/sshd_configuration.md +++ b/docs/admin-guide/configuration/access/sshd_configuration.md @@ -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 diff --git a/docs/admin-guide/configuration/access/sudo.md b/docs/admin-guide/configuration/access/sudo.md index 9592982b..c0aa1482 100644 --- a/docs/admin-guide/configuration/access/sudo.md +++ b/docs/admin-guide/configuration/access/sudo.md @@ -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: diff --git a/docs/admin-guide/configuration/access/system_access.md b/docs/admin-guide/configuration/access/system_access.md index 9b17fbc1..7d6281a9 100644 --- a/docs/admin-guide/configuration/access/system_access.md +++ b/docs/admin-guide/configuration/access/system_access.md @@ -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 diff --git a/docs/admin-guide/configuration/basic/ad_integration.md b/docs/admin-guide/configuration/basic/ad_integration.md index 2a04c8f9..095ed2fe 100644 --- a/docs/admin-guide/configuration/basic/ad_integration.md +++ b/docs/admin-guide/configuration/basic/ad_integration.md @@ -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 ``` diff --git a/docs/admin-guide/configuration/basic/configuration_email.md b/docs/admin-guide/configuration/basic/configuration_email.md index c65d8c04..4d683b6e 100644 --- a/docs/admin-guide/configuration/basic/configuration_email.md +++ b/docs/admin-guide/configuration/basic/configuration_email.md @@ -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 diff --git a/docs/admin-guide/configuration/basic/gssproxy_with_keytab.md b/docs/admin-guide/configuration/basic/gssproxy_with_keytab.md index e7565895..6e97d50f 100644 --- a/docs/admin-guide/configuration/basic/gssproxy_with_keytab.md +++ b/docs/admin-guide/configuration/basic/gssproxy_with_keytab.md @@ -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 diff --git a/docs/admin-guide/configuration/basic/host_rename.md b/docs/admin-guide/configuration/basic/host_rename.md index a6743283..d10a4f5c 100644 --- a/docs/admin-guide/configuration/basic/host_rename.md +++ b/docs/admin-guide/configuration/basic/host_rename.md @@ -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 diff --git a/docs/admin-guide/configuration/basic/networking.md b/docs/admin-guide/configuration/basic/networking.md index 061c9128..a8b89b6d 100644 --- a/docs/admin-guide/configuration/basic/networking.md +++ b/docs/admin-guide/configuration/basic/networking.md @@ -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: diff --git a/docs/admin-guide/configuration/basic/ntp_server.md b/docs/admin-guide/configuration/basic/ntp_server.md index e58fb722..e420d015 100644 --- a/docs/admin-guide/configuration/basic/ntp_server.md +++ b/docs/admin-guide/configuration/basic/ntp_server.md @@ -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`. diff --git a/docs/admin-guide/configuration/desktop/dconf.md b/docs/admin-guide/configuration/desktop/dconf.md index 6369f2ec..855da295 100644 --- a/docs/admin-guide/configuration/desktop/dconf.md +++ b/docs/admin-guide/configuration/desktop/dconf.md @@ -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': diff --git a/docs/admin-guide/configuration/desktop/desktop.md b/docs/admin-guide/configuration/desktop/desktop.md index 4becc18e..0af5f7cc 100644 --- a/docs/admin-guide/configuration/desktop/desktop.md +++ b/docs/admin-guide/configuration/desktop/desktop.md @@ -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. diff --git a/docs/admin-guide/configuration/desktop/program_starter.md b/docs/admin-guide/configuration/desktop/program_starter.md index f70d8839..132ae218 100644 --- a/docs/admin-guide/configuration/desktop/program_starter.md +++ b/docs/admin-guide/configuration/desktop/program_starter.md @@ -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). diff --git a/docs/admin-guide/configuration/desktop/xrdp.md b/docs/admin-guide/configuration/desktop/xrdp.md index 017342e5..08f5695d 100644 --- a/docs/admin-guide/configuration/desktop/xrdp.md +++ b/docs/admin-guide/configuration/desktop/xrdp.md @@ -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. diff --git a/docs/admin-guide/configuration/files/autofs.md b/docs/admin-guide/configuration/files/autofs.md index 7c83df07..145ba159 100644 --- a/docs/admin-guide/configuration/files/autofs.md +++ b/docs/admin-guide/configuration/files/autofs.md @@ -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). diff --git a/docs/admin-guide/configuration/files/central_storage_mount.md b/docs/admin-guide/configuration/files/central_storage_mount.md index 9dc1e1fb..b9996a7a 100644 --- a/docs/admin-guide/configuration/files/central_storage_mount.md +++ b/docs/admin-guide/configuration/files/central_storage_mount.md @@ -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. diff --git a/docs/admin-guide/configuration/files/distribute_files.md b/docs/admin-guide/configuration/files/distribute_files.md index 196a3c8e..2be051b6 100644 --- a/docs/admin-guide/configuration/files/distribute_files.md +++ b/docs/admin-guide/configuration/files/distribute_files.md @@ -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. diff --git a/docs/admin-guide/configuration/files/mount.md b/docs/admin-guide/configuration/files/mount.md index 0e1f23c4..730a36eb 100644 --- a/docs/admin-guide/configuration/files/mount.md +++ b/docs/admin-guide/configuration/files/mount.md @@ -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: diff --git a/docs/admin-guide/configuration/files/partitioning.md b/docs/admin-guide/configuration/files/partitioning.md index 30e8fcbd..d91adf3a 100644 --- a/docs/admin-guide/configuration/files/partitioning.md +++ b/docs/admin-guide/configuration/files/partitioning.md @@ -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: diff --git a/docs/admin-guide/configuration/https/acme.md b/docs/admin-guide/configuration/https/acme.md index 830dd6b5..72e1d5b7 100644 --- a/docs/admin-guide/configuration/https/acme.md +++ b/docs/admin-guide/configuration/https/acme.md @@ -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 ` 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: diff --git a/docs/admin-guide/configuration/monitoring/icinga2.md b/docs/admin-guide/configuration/monitoring/icinga2.md index 28f2df11..cd959364 100644 --- a/docs/admin-guide/configuration/monitoring/icinga2.md +++ b/docs/admin-guide/configuration/monitoring/icinga2.md @@ -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 diff --git a/docs/admin-guide/configuration/monitoring/journald.md b/docs/admin-guide/configuration/monitoring/journald.md index 761d9d9d..35828912 100644 --- a/docs/admin-guide/configuration/monitoring/journald.md +++ b/docs/admin-guide/configuration/monitoring/journald.md @@ -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 ``` diff --git a/docs/admin-guide/configuration/software/custom_repositories.md b/docs/admin-guide/configuration/software/custom_repositories.md index b71f1fde..1e69ce31 100644 --- a/docs/admin-guide/configuration/software/custom_repositories.md +++ b/docs/admin-guide/configuration/software/custom_repositories.md @@ -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! ``` diff --git a/docs/admin-guide/configuration/software/environment_modules.md b/docs/admin-guide/configuration/software/environment_modules.md index 8b2f908f..8818edd7 100644 --- a/docs/admin-guide/configuration/software/environment_modules.md +++ b/docs/admin-guide/configuration/software/environment_modules.md @@ -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! diff --git a/docs/admin-guide/configuration/software/mathematica.md b/docs/admin-guide/configuration/software/mathematica.md index 9f55aa61..85040d52 100644 --- a/docs/admin-guide/configuration/software/mathematica.md +++ b/docs/admin-guide/configuration/software/mathematica.md @@ -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) diff --git a/docs/admin-guide/configuration/software/package_repositories.md b/docs/admin-guide/configuration/software/package_repositories.md index b5db0bf1..32f1a487 100644 --- a/docs/admin-guide/configuration/software/package_repositories.md +++ b/docs/admin-guide/configuration/software/package_repositories.md @@ -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 diff --git a/docs/admin-guide/configuration/software/packagekit.md b/docs/admin-guide/configuration/software/packagekit.md index 8a95fb23..2f4862eb 100644 --- a/docs/admin-guide/configuration/software/packagekit.md +++ b/docs/admin-guide/configuration/software/packagekit.md @@ -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 ``` diff --git a/docs/admin-guide/configuration/software/packages.md b/docs/admin-guide/configuration/software/packages.md index ce631201..965a8a39 100644 --- a/docs/admin-guide/configuration/software/packages.md +++ b/docs/admin-guide/configuration/software/packages.md @@ -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: diff --git a/docs/admin-guide/configuration/software/pmodules.md b/docs/admin-guide/configuration/software/pmodules.md index 3be168b1..322d4c65 100644 --- a/docs/admin-guide/configuration/software/pmodules.md +++ b/docs/admin-guide/configuration/software/pmodules.md @@ -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 ") DirAx/1.17 ("Dmitry Ozerov ") ``` -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 diff --git a/docs/admin-guide/configuration/software/python.md b/docs/admin-guide/configuration/software/python.md index 3408ee56..3773bc85 100644 --- a/docs/admin-guide/configuration/software/python.md +++ b/docs/admin-guide/configuration/software/python.md @@ -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 diff --git a/docs/admin-guide/configuration/software/selinux_configuration.md b/docs/admin-guide/configuration/software/selinux_configuration.md index e0e14b15..9b21dd90 100644 --- a/docs/admin-guide/configuration/software/selinux_configuration.md +++ b/docs/admin-guide/configuration/software/selinux_configuration.md @@ -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 diff --git a/docs/admin-guide/configuration/software/services.md b/docs/admin-guide/configuration/software/services.md index bbf742f4..cf746f5d 100644 --- a/docs/admin-guide/configuration/software/services.md +++ b/docs/admin-guide/configuration/software/services.md @@ -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: diff --git a/docs/admin-guide/configuration/software/timers.md b/docs/admin-guide/configuration/software/timers.md index 7fb43f7d..d5f845b4 100644 --- a/docs/admin-guide/configuration/software/timers.md +++ b/docs/admin-guide/configuration/software/timers.md @@ -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`) diff --git a/docs/admin-guide/consoles.md b/docs/admin-guide/consoles.md index d72e5ee1..1742425a 100644 --- a/docs/admin-guide/consoles.md +++ b/docs/admin-guide/consoles.md @@ -20,7 +20,7 @@ The pgroup folders and `raw` and `work` links in `///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 `/[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 `` subfolders here ... | ### Permissions diff --git a/docs/admin-guide/container.md b/docs/admin-guide/container.md index 32810580..1eab5cfd 100644 --- a/docs/admin-guide/container.md +++ b/docs/admin-guide/container.md @@ -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: diff --git a/docs/admin-guide/custom_repositories.md b/docs/admin-guide/custom_repositories.md index daee2181..17eb3a8a 100644 --- a/docs/admin-guide/custom_repositories.md +++ b/docs/admin-guide/custom_repositories.md @@ -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//$lx_repo_tag/ 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 chmod g+s # 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 ``` diff --git a/docs/admin-guide/deployment/advanced_installation.md b/docs/admin-guide/deployment/advanced_installation.md index d5a2a177..13dc2fa5 100644 --- a/docs/admin-guide/deployment/advanced_installation.md +++ b/docs/admin-guide/deployment/advanced_installation.md @@ -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 diff --git a/docs/admin-guide/deployment/basic_installation.md b/docs/admin-guide/deployment/basic_installation.md index 413dd4b6..a7d6db7a 100644 --- a/docs/admin-guide/deployment/basic_installation.md +++ b/docs/admin-guide/deployment/basic_installation.md @@ -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 diff --git a/docs/admin-guide/deployment/dmz_installation.md b/docs/admin-guide/deployment/dmz_installation.md index 96577aa7..02c15b67 100644 --- a/docs/admin-guide/deployment/dmz_installation.md +++ b/docs/admin-guide/deployment/dmz_installation.md @@ -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 diff --git a/docs/admin-guide/deployment/re_installation.md b/docs/admin-guide/deployment/re_installation.md index 68a2b8bc..d4416f6a 100644 --- a/docs/admin-guide/deployment/re_installation.md +++ b/docs/admin-guide/deployment/re_installation.md @@ -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` ``` diff --git a/docs/admin-guide/deployment/rhel8/desktop.md b/docs/admin-guide/deployment/rhel8/desktop.md index 9a4baacb..1e7cebb5 100644 --- a/docs/admin-guide/deployment/rhel8/desktop.md +++ b/docs/admin-guide/deployment/rhel8/desktop.md @@ -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`) diff --git a/docs/admin-guide/deployment/rhel8/index.md b/docs/admin-guide/deployment/rhel8/index.md index 77abf852..3fb151fb 100644 --- a/docs/admin-guide/deployment/rhel8/index.md +++ b/docs/admin-guide/deployment/rhel8/index.md @@ -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 diff --git a/docs/admin-guide/deployment/rhel8/kerberos.md b/docs/admin-guide/deployment/rhel8/kerberos.md index fc5dfcd0..57c4432e 100644 --- a/docs/admin-guide/deployment/rhel8/kerberos.md +++ b/docs/admin-guide/deployment/rhel8/kerberos.md @@ -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. diff --git a/docs/admin-guide/deployment/rhel8/nvidia.md b/docs/admin-guide/deployment/rhel8/nvidia.md index a4359fd9..abc26112 100644 --- a/docs/admin-guide/deployment/rhel8/nvidia.md +++ b/docs/admin-guide/deployment/rhel8/nvidia.md @@ -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. diff --git a/docs/admin-guide/deployment/rhel8/vendor_documentation.md b/docs/admin-guide/deployment/rhel8/vendor_documentation.md index fd413776..65d53c75 100644 --- a/docs/admin-guide/deployment/rhel8/vendor_documentation.md +++ b/docs/admin-guide/deployment/rhel8/vendor_documentation.md @@ -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/) diff --git a/docs/admin-guide/deployment/rhel9/index.md b/docs/admin-guide/deployment/rhel9/index.md index e5f35d5f..38463553 100644 --- a/docs/admin-guide/deployment/rhel9/index.md +++ b/docs/admin-guide/deployment/rhel9/index.md @@ -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 | | --- | --- | diff --git a/docs/admin-guide/guidelines.md b/docs/admin-guide/guidelines.md index dd6953c5..32a30bf4 100644 --- a/docs/admin-guide/guidelines.md +++ b/docs/admin-guide/guidelines.md @@ -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 diff --git a/docs/admin-guide/index.md b/docs/admin-guide/index.md index 41ceab08..c41ceaef 100644 --- a/docs/admin-guide/index.md +++ b/docs/admin-guide/index.md @@ -1,3 +1,3 @@ # Admin Guide -This is documenation relevant for system admins. +This is documentation relevant for system admins. diff --git a/docs/admin-guide/puppet/puppet_client.md b/docs/admin-guide/puppet/puppet_client.md index f9c5dae3..e9a26d37 100644 --- a/docs/admin-guide/puppet/puppet_client.md +++ b/docs/admin-guide/puppet/puppet_client.md @@ -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/* diff --git a/docs/admin-guide/puppet/puppet_environments.md b/docs/admin-guide/puppet/puppet_environments.md index ad943232..b29e850b 100644 --- a/docs/admin-guide/puppet/puppet_environments.md +++ b/docs/admin-guide/puppet/puppet_environments.md @@ -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 diff --git a/docs/admin-guide/security/mitigation_copyfail.md b/docs/admin-guide/security/mitigation_copyfail.md index ac73c894..3585bc03 100644 --- a/docs/admin-guide/security/mitigation_copyfail.md +++ b/docs/admin-guide/security/mitigation_copyfail.md @@ -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. diff --git a/docs/admin-guide/ssh_gateways.md b/docs/admin-guide/ssh_gateways.md index baa6cc89..7f081fe8 100644 --- a/docs/admin-guide/ssh_gateways.md +++ b/docs/admin-guide/ssh_gateways.md @@ -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 ` will list connections for a specific user diff --git a/docs/admin-guide/troubleshooting/boot.md b/docs/admin-guide/troubleshooting/boot.md index 895da287..6c2672e9 100644 --- a/docs/admin-guide/troubleshooting/boot.md +++ b/docs/admin-guide/troubleshooting/boot.md @@ -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 diff --git a/docs/admin-guide/troubleshooting/deployment.md b/docs/admin-guide/troubleshooting/deployment.md index 17b57dcb..dd6e7efb 100644 --- a/docs/admin-guide/troubleshooting/deployment.md +++ b/docs/admin-guide/troubleshooting/deployment.md @@ -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. diff --git a/docs/admin-guide/troubleshooting/login.md b/docs/admin-guide/troubleshooting/login.md index ec43a993..209f432b 100644 --- a/docs/admin-guide/troubleshooting/login.md +++ b/docs/admin-guide/troubleshooting/login.md @@ -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 diff --git a/docs/admin-guide/troubleshooting/lvm.md b/docs/admin-guide/troubleshooting/lvm.md index 165d1698..faa0551a 100644 --- a/docs/admin-guide/troubleshooting/lvm.md +++ b/docs/admin-guide/troubleshooting/lvm.md @@ -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. diff --git a/docs/admin-guide/troubleshooting/network.md b/docs/admin-guide/troubleshooting/network.md index 6a924ebe..e38b61e5 100644 --- a/docs/admin-guide/troubleshooting/network.md +++ b/docs/admin-guide/troubleshooting/network.md @@ -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 diff --git a/docs/admin-guide/troubleshooting/nvidia.md b/docs/admin-guide/troubleshooting/nvidia.md index e5b13e71..885b978f 100644 --- a/docs/admin-guide/troubleshooting/nvidia.md +++ b/docs/admin-guide/troubleshooting/nvidia.md @@ -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 diff --git a/docs/admin-guide/troubleshooting/packages.md b/docs/admin-guide/troubleshooting/packages.md index a4d3f4a2..13a976c1 100644 --- a/docs/admin-guide/troubleshooting/packages.md +++ b/docs/admin-guide/troubleshooting/packages.md @@ -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 diff --git a/docs/admin-guide/troubleshooting/pam.md b/docs/admin-guide/troubleshooting/pam.md index 7b954e6b..9f90303c 100644 --- a/docs/admin-guide/troubleshooting/pam.md +++ b/docs/admin-guide/troubleshooting/pam.md @@ -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. diff --git a/docs/admin-guide/troubleshooting/selinux.md b/docs/admin-guide/troubleshooting/selinux.md index 2a7753eb..7def03f3 100644 --- a/docs/admin-guide/troubleshooting/selinux.md +++ b/docs/admin-guide/troubleshooting/selinux.md @@ -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 diff --git a/docs/admin-guide/unix_groups.md b/docs/admin-guide/unix_groups.md index 0eb31228..f01cc581 100644 --- a/docs/admin-guide/unix_groups.md +++ b/docs/admin-guide/unix_groups.md @@ -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) diff --git a/docs/announcements/index.md b/docs/announcements/index.md index 3e60da4a..f8661ea8 100644 --- a/docs/announcements/index.md +++ b/docs/announcements/index.md @@ -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 diff --git a/docs/engineering-guide/accounts-and-groups.md b/docs/engineering-guide/accounts-and-groups.md index b4d7ee9e..ba6579e0 100644 --- a/docs/engineering-guide/accounts-and-groups.md +++ b/docs/engineering-guide/accounts-and-groups.md @@ -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 diff --git a/docs/engineering-guide/active-directory.md b/docs/engineering-guide/active-directory.md index 2e1a0388..5f278ad2 100644 --- a/docs/engineering-guide/active-directory.md +++ b/docs/engineering-guide/active-directory.md @@ -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 ``` diff --git a/docs/engineering-guide/boot_server.md b/docs/engineering-guide/boot_server.md index 79bb4240..2991062e 100644 --- a/docs/engineering-guide/boot_server.md +++ b/docs/engineering-guide/boot_server.md @@ -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` diff --git a/docs/engineering-guide/gitea-dmz.md b/docs/engineering-guide/gitea-dmz.md index 6ecde907..1c102b36 100644 --- a/docs/engineering-guide/gitea-dmz.md +++ b/docs/engineering-guide/gitea-dmz.md @@ -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": { diff --git a/docs/engineering-guide/gitea.md b/docs/engineering-guide/gitea.md index c950ee67..f3af50b8 100644 --- a/docs/engineering-guide/gitea.md +++ b/docs/engineering-guide/gitea.md @@ -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). diff --git a/docs/engineering-guide/icinga2.md b/docs/engineering-guide/icinga2.md index 83b73e7c..6ecbf6ab 100644 --- a/docs/engineering-guide/icinga2.md +++ b/docs/engineering-guide/icinga2.md @@ -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 ``` diff --git a/docs/engineering-guide/metrics.md b/docs/engineering-guide/metrics.md index bec818f5..8b1e07d3 100644 --- a/docs/engineering-guide/metrics.md +++ b/docs/engineering-guide/metrics.md @@ -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 diff --git a/docs/engineering-guide/nx_nomachine/administration.md b/docs/engineering-guide/nx_nomachine/administration.md index 408be908..3ce5a2d7 100644 --- a/docs/engineering-guide/nx_nomachine/administration.md +++ b/docs/engineering-guide/nx_nomachine/administration.md @@ -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) diff --git a/docs/engineering-guide/nx_nomachine/configuration.md b/docs/engineering-guide/nx_nomachine/configuration.md index 9a6544ac..0ad153f3 100644 --- a/docs/engineering-guide/nx_nomachine/configuration.md +++ b/docs/engineering-guide/nx_nomachine/configuration.md @@ -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 diff --git a/docs/engineering-guide/nx_nomachine/overview_nomachine-proxy.drawio.svg b/docs/engineering-guide/nx_nomachine/overview_nomachine-proxy.drawio.svg index bce77e99..c01c1283 100644 --- a/docs/engineering-guide/nx_nomachine/overview_nomachine-proxy.drawio.svg +++ b/docs/engineering-guide/nx_nomachine/overview_nomachine-proxy.drawio.svg @@ -122,7 +122,7 @@
- node randomly choosen + node randomly chosen
or re-connect to existing connection
diff --git a/docs/engineering-guide/nx_nomachine/usecases.md b/docs/engineering-guide/nx_nomachine/usecases.md index 0bdffe5f..339cbd4a 100644 --- a/docs/engineering-guide/nx_nomachine/usecases.md +++ b/docs/engineering-guide/nx_nomachine/usecases.md @@ -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). diff --git a/docs/engineering-guide/puppet/modules.md b/docs/engineering-guide/puppet/modules.md index c5d29719..545d7a6a 100644 --- a/docs/engineering-guide/puppet/modules.md +++ b/docs/engineering-guide/puppet/modules.md @@ -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) diff --git a/docs/engineering-guide/puppet/overview.md b/docs/engineering-guide/puppet/overview.md index 592893f6..4f0c5f04 100644 --- a/docs/engineering-guide/puppet/overview.md +++ b/docs/engineering-guide/puppet/overview.md @@ -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. diff --git a/docs/engineering-guide/puppet_server.md b/docs/engineering-guide/puppet_server.md index 56749ee5..820f8c0a 100644 --- a/docs/engineering-guide/puppet_server.md +++ b/docs/engineering-guide/puppet_server.md @@ -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 diff --git a/docs/engineering-guide/repo_server.md b/docs/engineering-guide/repo_server.md index a13b0e12..c351a661 100644 --- a/docs/engineering-guide/repo_server.md +++ b/docs/engineering-guide/repo_server.md @@ -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 diff --git a/docs/engineering-guide/sysdb_environments.md b/docs/engineering-guide/sysdb_environments.md index 1b99ef6d..623c7c01 100644 --- a/docs/engineering-guide/sysdb_environments.md +++ b/docs/engineering-guide/sysdb_environments.md @@ -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- `Settings`, or directly: https://gitea.psi.ch/puppet/data-(environment_name)/settings: - untick `Enable Repository Wiki` - untick `Enable Projects` diff --git a/docs/engineering-guide/test_systems.md b/docs/engineering-guide/test_systems.md index bffc0538..da40f2bb 100644 --- a/docs/engineering-guide/test_systems.md +++ b/docs/engineering-guide/test_systems.md @@ -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 diff --git a/docs/engineering-guide/troubleshooting.md b/docs/engineering-guide/troubleshooting.md index f89f315a..e66b7f77 100644 --- a/docs/engineering-guide/troubleshooting.md +++ b/docs/engineering-guide/troubleshooting.md @@ -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) diff --git a/docs/engineering-guide/webhosting.md b/docs/engineering-guide/webhosting.md index 22a032e5..9cf5a037 100644 --- a/docs/engineering-guide/webhosting.md +++ b/docs/engineering-guide/webhosting.md @@ -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 diff --git a/docs/index.md b/docs/index.md index 632ab24a..2f64177f 100644 --- a/docs/index.md +++ b/docs/index.md @@ -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 diff --git a/docs/management/strategy.md b/docs/management/strategy.md index 928e4d15..e9a25c5c 100644 --- a/docs/management/strategy.md +++ b/docs/management/strategy.md @@ -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?) diff --git a/docs/services/gitea/authentication.md b/docs/services/gitea/authentication.md index 114b9390..f90cfcf3 100644 --- a/docs/services/gitea/authentication.md +++ b/docs/services/gitea/authentication.md @@ -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 diff --git a/docs/services/gitea/gitea-faq.md b/docs/services/gitea/gitea-faq.md index 36cff930..1b2db10e 100644 --- a/docs/services/gitea/gitea-faq.md +++ b/docs/services/gitea/gitea-faq.md @@ -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 diff --git a/docs/services/gitea/gitea-migration.md b/docs/services/gitea/gitea-migration.md index 854b8bff..0131a424 100644 --- a/docs/services/gitea/gitea-migration.md +++ b/docs/services/gitea/gitea-migration.md @@ -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" diff --git a/docs/services/gitea/gitea-packages.md b/docs/services/gitea/gitea-packages.md index c081f0f2..42270783 100644 --- a/docs/services/gitea/gitea-packages.md +++ b/docs/services/gitea/gitea-packages.md @@ -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 diff --git a/docs/services/gitea/gitea-runner.md b/docs/services/gitea/gitea-runner.md index cccf4215..c229e2e9 100644 --- a/docs/services/gitea/gitea-runner.md +++ b/docs/services/gitea/gitea-runner.md @@ -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 diff --git a/docs/services/gitea/gitea-snippets.md b/docs/services/gitea/gitea-snippets.md index 4e026a52..005b56aa 100644 --- a/docs/services/gitea/gitea-snippets.md +++ b/docs/services/gitea/gitea-snippets.md @@ -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. diff --git a/docs/services/gitea/index.md b/docs/services/gitea/index.md index 5a36cd0a..719a104a 100644 --- a/docs/services/gitea/index.md +++ b/docs/services/gitea/index.md @@ -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). diff --git a/docs/services/gmgt.md b/docs/services/gmgt.md index fe6c6b53..b2a9800f 100644 --- a/docs/services/gmgt.md +++ b/docs/services/gmgt.md @@ -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 diff --git a/docs/services/python.md b/docs/services/python.md index 3faa7d39..e2ee5c1f 100644 --- a/docs/services/python.md +++ b/docs/services/python.md @@ -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 diff --git a/docs/user-guide/MS_Teams_Webhooks.md b/docs/user-guide/MS_Teams_Webhooks.md index 12ac37f1..6d756a81 100644 --- a/docs/user-guide/MS_Teams_Webhooks.md +++ b/docs/user-guide/MS_Teams_Webhooks.md @@ -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) diff --git a/docs/user-guide/consoles.md b/docs/user-guide/consoles.md index 928c1cf4..4dd74bb4 100644 --- a/docs/user-guide/consoles.md +++ b/docs/user-guide/consoles.md @@ -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_` - `unx-sls_beamline>_bs` @@ -38,7 +38,7 @@ The consoles will have following directory structures available ```bash // ///bin # this folder is automatically in the PATH -///config # configration data for applications +///config # configuration data for applications ///applications # beamline applications and scripts ///data # beamline data ///data/ @@ -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 `///data//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? diff --git a/docs/user-guide/env_variables.md b/docs/user-guide/env_variables.md index 6dc59a6c..2d07a2a2 100644 --- a/docs/user-guide/env_variables.md +++ b/docs/user-guide/env_variables.md @@ -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. diff --git a/docs/user-guide/evolution_for_o365.md b/docs/user-guide/evolution_for_o365.md index 4bce189a..11d210e9 100644 --- a/docs/user-guide/evolution_for_o365.md +++ b/docs/user-guide/evolution_for_o365.md @@ -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) diff --git a/docs/user-guide/firefox_profile_per_host.md b/docs/user-guide/firefox_profile_per_host.md index 7e2db0b4..cbd743c6 100644 --- a/docs/user-guide/firefox_profile_per_host.md +++ b/docs/user-guide/firefox_profile_per_host.md @@ -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. diff --git a/docs/user-guide/index.md b/docs/user-guide/index.md index fd8cc0c7..71c8fa01 100644 --- a/docs/user-guide/index.md +++ b/docs/user-guide/index.md @@ -1,6 +1,6 @@ # User Guide -This guide contains tricks and recipies for end users using Red Hat Enterprise Linux 7 or 8 as provided by the Core Linux Research Services group. +This guide contains tricks and recipes for end users using Red Hat Enterprise Linux 7 or 8 as provided by the Core Linux Research Services group. - How to [Order or Replace a Linux System or Console](order_linux_system) - Configure [VPN Access](vpn) diff --git a/docs/user-guide/kerberos_lifetime.md b/docs/user-guide/kerberos_lifetime.md index 96ae5730..4d984bbe 100644 --- a/docs/user-guide/kerberos_lifetime.md +++ b/docs/user-guide/kerberos_lifetime.md @@ -11,5 +11,5 @@ Valid starting Expires Service principal ``` To seamlessly continue you need to obtain a new Kerberos ticket before by running `kinit`. -It will then ask your password and after sucessful authentication there will be a newly acquired Kerberos ticket which will do it again one week. +It will then ask your password and after successful authentication there will be a newly acquired Kerberos ticket which will do it again one week. diff --git a/docs/user-guide/personal_drive.md b/docs/user-guide/personal_drive.md index a1011813..098d06d9 100644 --- a/docs/user-guide/personal_drive.md +++ b/docs/user-guide/personal_drive.md @@ -20,8 +20,8 @@ If `~/network_drives/` remains empty, or still does not exit please open a Servi ## Automatically Link or Copy Files in Local Home !!! warning - - Use this feature conciously and only for files which you really need on "all" machines. - - Do not link `~/.cache`, `~/.mozilla` or the full `~/.config` (indvidual files below are fine). + - Use this feature consciously and only for files which you really need on "all" machines. + - Do not link `~/.cache`, `~/.mozilla` or the full `~/.config` (individual files below are fine). - Use copy or download over link to avoid problems with network connectivity (e.g. for laptops). Shared homes create a set of problems due to the fact most (graphical) Linux software is designed and implemented. Therefore it is recommended to use local homes wherever possible. However, in certain few cases it might be useful to have particular configurations and/or settings synchronized across multiple machines. @@ -77,7 +77,7 @@ Note that if the intended _symlink_ location already exists (e.g `.ssh`), then i The copy and download feature will always overwrite an existing file. And you only can configure individual files with those. -The link feature has the advantage that changes are immedately reflected on all other systems. But it depends on stable network connectivity which you may not always have, e.g. with a laptop. Therefore we usually recommend to use copy instead of link. +The link feature has the advantage that changes are immediately reflected on all other systems. But it depends on stable network connectivity which you may not always have, e.g. with a laptop. Therefore we usually recommend to use copy instead of link. When using the copy or download feature then network connectivity only needs to be available initially and on the first connect after the source file has been changed. However, you need to be aware of that changes on the local (destination) files do not propagate automatically to other systems and might get reset on the next login! So you need to do these changes always also on the source file on the U: drive or in the download source. diff --git a/docs/user-guide/putty.md b/docs/user-guide/putty.md index 14987cad..40f7e209 100644 --- a/docs/user-guide/putty.md +++ b/docs/user-guide/putty.md @@ -6,7 +6,7 @@ The default settings of Putty allow to connect to a Linux host. But when there a ![Failing AFS](putty/missing_kerberos_ticket_delegation.png) -This is due to missing Kerberos ticket delegation. Note that you may recover from this on the Linux shell by entering `kinit` and then your password to opain a new Kerberos ticket and `aklog` to log into AFS. +This is due to missing Kerberos ticket delegation. Note that you may recover from this on the Linux shell by entering `kinit` and then your password to obtain a new Kerberos ticket and `aklog` to log into AFS. ## Disable Kerberos in Putty @@ -21,5 +21,5 @@ Kerberos tickets get invalid at some point after AFS will refuse access. To check when this will be run `klist` and in the output check below `krbtgt/D.PSI.CH@D.PSI.CH` the `renew until` timestamp. To seamlessly continue you need to obtain a new Kerberos ticket before by running `kinit`. -It will then ask your password and after sucessful authentication there will be a newly acquired Kerberos ticket which will do it for one week and AFS is happy as long too. +It will then ask your password and after successful authentication there will be a newly acquired Kerberos ticket which will do it for one week and AFS is happy as long too. diff --git a/docs/user-guide/ssh_client_config.md b/docs/user-guide/ssh_client_config.md index 87c1eb3b..7ee3f69a 100644 --- a/docs/user-guide/ssh_client_config.md +++ b/docs/user-guide/ssh_client_config.md @@ -1,6 +1,6 @@ # Personal SSH Client Configuration -Here you find suggestions and best practices for a SSH client configuration file `~/.ssh/config`. +Here you find suggestions and best practices for an SSH client configuration file `~/.ssh/config`. The assumption is that you are working at the PSI campus or are connected over VPN using `AnyConnect` or `openconnect`. A good SSH config is a rather personal thing. First there are useful defaults, then starting points for common use cases. @@ -68,7 +68,7 @@ Host x09lb-* !x09lb-gw* Host pc* mpc* vpc* vmpc* ProxyJump mgt-gw.psi.ch -# do trusted connecion by using FQDN (needed for AFS access, etc.) +# do trusted connection by using FQDN (needed for AFS access, etc.) Host *.psi.ch GSSAPIDelegateCredentials yes ForwardAgent yes diff --git a/docs/user-guide/ssh_host_key_certificates.md b/docs/user-guide/ssh_host_key_certificates.md index 382bd1eb..48705fdb 100644 --- a/docs/user-guide/ssh_host_key_certificates.md +++ b/docs/user-guide/ssh_host_key_certificates.md @@ -1,6 +1,6 @@ # SSH Host Key Certificates -The SSH host keys of Puppet managed Linux hosts have a certficate which avoids below key acceptance question: +The SSH host keys of Puppet managed Linux hosts have a certificate which avoids below key acceptance question: ```bash $ ssh hipa-gw @@ -13,7 +13,7 @@ Are you sure you want to continue connecting (yes/no)? To accept SSH host keys with a certificate, please update either `~/.ssh/known_hosts` (your user only) or `/etc/ssh/ssh_known_hosts` (system-wide) as follows: ```bash -# SSH host key certficate CA managed by PSI Puppet +# SSH host key certificate CA managed by PSI Puppet @cert-authority * ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBF2xLCCHNmXSeY+qNPmdo/jO2AXrcHyQDqZLBzWVwk2/GqMRDl4mavZLBPyQPNeLGAPc+BHg7iRC65wQQEeYOVU= @cert-authority * ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKhIx/obIiiO9AtrUgj7pF8kAgv4g9Dp+DRXilkmlkxK ``` diff --git a/docs/user-guide/ssh_to_legacy_linux.md b/docs/user-guide/ssh_to_legacy_linux.md index 83df50ad..456b0ffa 100644 --- a/docs/user-guide/ssh_to_legacy_linux.md +++ b/docs/user-guide/ssh_to_legacy_linux.md @@ -1,7 +1,7 @@ # SSH To Legacy Linux Systems -On RHEL8 and newer systems Redhat started to remove the support for certain SSL algoriths that are considered unsafe to use. -Therefore connections to (very) old Linux systems do not work out of the box withouth specifying certain exceptions/paramaters +On RHEL8 and newer systems Redhat started to remove the support for certain SSL algorithms that are considered unsafe to use. +Therefore connections to (very) old Linux systems do not work out of the box without specifying certain exceptions/parameters The most common options that might be needed are the following: ```bash diff --git a/docs/user-guide/thunderbird_for_o365.md b/docs/user-guide/thunderbird_for_o365.md index 9adeaa1f..078ab4f0 100644 --- a/docs/user-guide/thunderbird_for_o365.md +++ b/docs/user-guide/thunderbird_for_o365.md @@ -21,7 +21,7 @@ Inside the PSI network access to E-Mail services using IMAP is protected by auto For setting up Thunderbird you first need to get the [PSI scanner certificate](thunderbird_for_o365/cert_PSI_FW_SSL_Scanner_TRUST.crt.zip) and unpack it. -Open Thunderbird. If this is your first account, it will show a account setup assisant which you can exit or close. +Open Thunderbird. If this is your first account, it will show an account setup assistant which you can exit or close. ![Open Settings](thunderbird_for_o365/thunderbird01_open_settings.png) @@ -62,7 +62,7 @@ For "OUTGOING SERVER" set the "Hostname" to `smtp.office365.com`, the "Port" to ![OAuth2 Login](thunderbird_for_o365/thunderbird08_oauth_login.png) -This is followed by a Microsoft login page where you need to enter your normal PSI AD/Windows password, maybe asking for second factor authentification (Authenticator app or token code). +This is followed by a Microsoft login page where you need to enter your normal PSI AD/Windows password, maybe asking for second factor authentication (Authenticator app or token code). ![Done](thunderbird_for_o365/thunderbird09_success.png) @@ -97,7 +97,7 @@ Go to "Copies & Folders" of your account and untick below "When sending messages Best you send now a test message and check if you get a copy in "Sent Items". -## Addressbook with PSI Email Adresses +## Addressbook with PSI Email Addresses ![Open Settings](thunderbird_for_o365/thunderbird01_open_settings.png) @@ -158,7 +158,7 @@ The next time you write a new message and enter something into the "To" line, ![Directory Password](thunderbird_for_o365/thunderbird40_directory_password.png) -you need to enter your Windos/AD password and then it will also search the PSI wide user directory. +you need to enter your Windows/AD password and then it will also search the PSI wide user directory. ## Calendar Integration diff --git a/docs/user-guide/xrdp.md b/docs/user-guide/xrdp.md index eb01c8aa..ebce507b 100644 --- a/docs/user-guide/xrdp.md +++ b/docs/user-guide/xrdp.md @@ -20,7 +20,7 @@ Enable the `Always ask for credentials` checkbox and remove the Windows domain p ![Remote Desktop Connection tool with proper user name](xrdp/windows_remote_desktop_client_02.png) -Then press `Connect`. Now on the first time it will ask to accept the certficate of the device you try to connect to: +Then press `Connect`. Now on the first time it will ask to accept the certificate of the device you try to connect to: ![Remote Desktop Connection tool certificate warning](xrdp/windows_remote_desktop_client_03.png) @@ -47,14 +47,14 @@ Also here you need to accept the certificate on first connect. The default option when you connect is `remote session (new or existing)` which will create a new virtual desktop session or attach again to an existing one. -Note that if there is already a local desktop session, it is not possible ot create a virtual desktop session and the connection will simply close without error message when this is tried. +Note that if there is already a local desktop session, it is not possible to create a virtual desktop session and the connection will simply close without error message when this is tried. ## Access Existing Desktop Session -This will give access to the deskop session which is running on the local screen. But this does not work automatically, that needs a bit of preparation. To be able to connect, the desktop session needs to be accessible with VNC on port 5900. +This will give access to the desktop session which is running on the local screen. But this does not work automatically, that needs a bit of preparation. To be able to connect, the desktop session needs to be accessible with VNC on port 5900. ### Gnome Desktop Sharing -An userfriendly way to achive this is to use the Gnome Desktop Sharing feature. But you need to prepare that while working locally connected on the real attached screen and keyboard. +A user-friendly way to achieve this is to use the Gnome Desktop Sharing feature. But you need to prepare that while working locally connected on the real attached screen and keyboard. Open the `Settings` tool and therein `Sharing`: @@ -73,7 +73,7 @@ When connecting with RDP, then select on the login screen `local desktop session ### `x11vnc` -Another option is to use `x11vnc` to share the desktop. This tool is run from the terminal and can be used to share also other desktop envrionments like XFCE or KDE. It can also be started on demand from remote if an `ssh` connection to the host can be etablished. It will use your normal password to authenticate the connection. +Another option is to use `x11vnc` to share the desktop. This tool is run from the terminal and can be used to share also other desktop environments like XFCE or KDE. It can also be started on demand from remote if an `ssh` connection to the host can be established. It will use your normal password to authenticate the connection. The suggested way to start it is: ```