forked from Controls/gitea-pages
moved rhel8/9 documentations
This commit is contained in:
File diff suppressed because one or more lines are too long
@@ -0,0 +1,55 @@
|
||||
# Desktop on RHEL 8
|
||||
|
||||
## Many Servers and Managers
|
||||
|
||||
Following software is involved in getting the desktop on Linux up and running.
|
||||
|
||||
- **Display Server** paints the image onto the screen
|
||||
- **Xorg**: good ol' Unix X Server with network redirection
|
||||
- **Wayland**: new and modern
|
||||
- **Display Manager** shows up at startup to authenticate the user and then start the desktop session
|
||||
- **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
|
||||
- **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`)
|
||||
- **gnome-session-custom-session** to select a specific saved Gnome session
|
||||
- **icewm-session** IceWM starter, `Xorg` only
|
||||
- **startxfce4** XFCE starter, `Xorg` only
|
||||
- **startplasma-x11** KDE Plasma starter for `Xorg`
|
||||
- **startplasma-wayland** KDE Plasma starter for `Wayland`
|
||||
|
||||
Out of the box RHEL 8 starts Gnome using `gdm` and `Wayland`. `Xorg` is also supported. Others can be installed from EPEL, but there is no support from Red Hat.
|
||||
|
||||
## PSI Specific Desktop Settings
|
||||
Per default Puppet starts `gdm` which then starts Gnome with `Xorg` using `/usr/share/xsessions/gnome-xorg.desktop`.
|
||||
|
||||
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`.
|
||||
|
||||
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`)
|
||||
- `/var/lib/AccountsService/users/*` (for `gdm`)
|
||||
- `/var/cache/lightdm/dmrc/*.dmrc` (for `lightdm`)
|
||||
- `/var/lib/lightdm/.cache/lightdm-gtk-greeter/state` (for `lightdm` with `lightdm-gtk-greeter`)
|
||||
- start AccountsService (`systemctl start accounts-daemon.service`)
|
||||
|
||||
### XFCE
|
||||
XFCE is installed when `base::enable_xfce: true` is set in Hiera.
|
||||
It then is also used by default with `base::xfce_default: true` or `desktop::session_manager: xfce`.
|
||||
|
||||
### IceWM
|
||||
IceWM is installed when `base::enable_icewm: true` is set in Hiera.
|
||||
It then is also used by default with `desktop::session_manager: icewm-session`.
|
||||
|
||||
### Using a different Desktop (e.g. KDE)
|
||||
The respective Desktop needs to be installed, either manually or through Puppet.
|
||||
The respective Session Manager can be set as system default in Hiera with `desktop::session_manager`.
|
||||
|
||||
If a different Display Manager is needed, or `lightdm` on other occasions, then changes in our Puppet code are required.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,75 @@
|
||||
# RHEL8 Hardware Compatibility
|
||||
|
||||
Here are hardware tests with RHEL8 on standard PSI hardware documented.
|
||||
|
||||
Generally speaking has Linux a rather good hardware compatibility with PC hardware, usually the older the hardware the better the support.
|
||||
|
||||
## Desktop Hardware
|
||||
|
||||
### HP Elite Mini 800 G9 Desktop PC
|
||||
- ✔ NIC
|
||||
- ✔ GPU
|
||||
- ✔ HDMI
|
||||
- ✔ DP
|
||||
- ✔ USB
|
||||
- ✔ Audio
|
||||
|
||||
### HP Z2 Tower G9 Workstation Desktop PC
|
||||
- ✔ NIC
|
||||
- ✔ GPU
|
||||
- ✔ DP
|
||||
- ✔ USB
|
||||
- ✔ Audio
|
||||
|
||||
## Mobile Hardware
|
||||
|
||||
### HP ZBook Studio 16 inch G10 Mobile Workstation PC
|
||||
- ❌/✔ Installation only with extra steps
|
||||
- ✔ NIC (HP USB-C to RJ45 Adapter G2)
|
||||
- ✔ WLAN
|
||||
- ✔ GPU
|
||||
- ✔ USB
|
||||
- ❌/✔ Audio (manual firmware binary install from https://github.com/thesofproject/sof-bin/ required), microphone and ear plugs work, but not the speaker
|
||||
- ✔ Webcam
|
||||
- ✔ Bluetooth
|
||||
- SIM slot (not tested)
|
||||
- fingerprint scanner (not tested)
|
||||
|
||||
#### Installation
|
||||
- Nouveau driver fails on the Nvidia chip, so modesetting needs to be disabled:
|
||||
```
|
||||
bob node set-attr pcXYZ.psi.ch "kernel_cmdline=nomodeset nouveau.modeset=0"
|
||||
```
|
||||
- Register the system "Pass Through" MAC address (you find it in the BIOS).
|
||||
- Installation did not work with the "HP USB-C to RJ45 Adapter G2": use another, registered adapter or dock instead.
|
||||
- At the final boot the Nvidia drivers are installed automatically, but cannot be activated and the screen turns black. Power off and on again, then the Nvidia drivers get loaded properly on the next boot.
|
||||
|
||||
### HP EliteBook 840 14 inch G10 Notebook PC
|
||||
- ✔ WLAN
|
||||
- ✔ GPU
|
||||
- ✔ HDMI
|
||||
- ✔ USB
|
||||
- ✔ Audio
|
||||
- ✔ Webcam
|
||||
- ✔ Bluetooth
|
||||
- SIM slot (not tested)
|
||||
- Card reader (not tested)
|
||||
|
||||
|
||||
## Test Details
|
||||
|
||||
- network card by installation via network
|
||||
- GPU by running graphical desktop, for Nvidia GPUs check if Nvidia drivers are used
|
||||
- HDMI
|
||||
- DP
|
||||
- USB by mouse, keyboard
|
||||
- notebook:
|
||||
- wifi
|
||||
- bluetooth (headset working?)
|
||||
- microphone
|
||||
- speaker
|
||||
- webcam
|
||||
- Dock
|
||||
- network
|
||||
- USB by mouse, keyboard
|
||||
- HDMI
|
||||
@@ -0,0 +1,177 @@
|
||||
# Red Hat Enterprise Linux 8
|
||||
|
||||
## Production Ready
|
||||
|
||||
The central infrastructure (automatic provisioning, upstream package synchronisation and Puppet) are stable and production ready.
|
||||
|
||||
The configuration management is done with Puppet like for RHEL 7. RHEL 7 and RHEL 8 hosts can share the same hierarchy in Hiera and thus also the "same" configuration. In cases where the configuration for RHEL 7 or RHEL 8 differs, the idea is to have both in parallel in Hiera and Puppet shall select the right one.
|
||||
|
||||
|
||||
Please still consider also implementing following two migrations when moving to RHEL 8:
|
||||
- migrate from Icinga1 to [Icinga2](../admin-guide/configuration/icinga2), as Icinga1 will be decommissioned by end of 2024
|
||||
- explicit [network configuration in Hiera](../admin-guide/configuration/networking) with `networking::setup`, especially if you have static IP addresses or static routes
|
||||
|
||||
Bugs and issues can be reported in the [Linux project in JIRA](https://jira.psi.ch/browse/PSILINUX).
|
||||
|
||||
## Documenation
|
||||
|
||||
* [Installation](installation)
|
||||
* [CUDA and Nvidia Drivers](nvidia)
|
||||
* [Kerberos](kerberos)
|
||||
* [Desktop](desktop)
|
||||
* [Hardware Compatibility](hardware_compatibility)
|
||||
* [Vendor Documentation](vendor_documentation)
|
||||
|
||||
## Disk Layout
|
||||
The default partition schema for RHEL8 is:
|
||||
|
||||
- create one primary ``/boot`` partition of 1Gb;
|
||||
- create the ``vg_root`` Volume Group that uses the rest of the disk;
|
||||
- on ``vg_root`` create the following logical volumes:
|
||||
- ``lv_root`` of 14 Gb size for ``/root``;
|
||||
- ``lv_home`` of 2 Gb size for ``/home``;
|
||||
- ``lv_var`` of 8 Gb size for ``/var``;
|
||||
- ``lv_var_log`` of 3 Gb size for ``/var/log``;
|
||||
- ``lv_var_tmp`` of 2 Gb size for ``/var/log``;
|
||||
- ``lv_tmp`` of 2 Gb size for ``/tmp``.
|
||||
|
||||
## Caveats
|
||||
|
||||
### Missing or Replaced Packages
|
||||
|
||||
[List of packages removed in RHEL 8](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index#removed-packages_changes-to-packages)
|
||||
|
||||
| RHEL 7 | RHEL 8 | remarks |
|
||||
| --- | --- | --- |
|
||||
| `a2ps` | recommends to use `enscript` instead | [`enscript` upstream](https://www.gnu.org/software/enscript/) [`a2ps` upstream](https://www.gnu.org/software/a2ps/) |
|
||||
| `blt` | - | [`blt` upstream](http://blt.sourceforge.net/), does not work with newer Tk version ([source](https://wiki.tcl-lang.org/page/BLT)) |
|
||||
| `gnome-icon-theme-legacy` | - | used for RHEL 7 Icewm |
|
||||
| ... | ... | here I stopped research, please report/document further packages |
|
||||
| `devtoolset*` | `gcc-toolset*` | |
|
||||
| `git-cvs` | - | `cvs` itself is not supported by RHEL8, but available through EPEL. Still missing is the support for `git cvsimport`. |
|
||||
|
||||
|
||||
### Missing RAID Drivers
|
||||
|
||||
#### Missing RAID Drivers during Installation
|
||||
|
||||
For RHEL 8 Red Hat phased out some hardware drivers, here is an [official list](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/hardware-enablement_considerations-in-adopting-rhel-8#removed-adapters_hardware-enablement), but I also found some stuff missing not listed there.
|
||||
|
||||
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
|
||||
|
||||
```
|
||||
$ lspci -nn
|
||||
...
|
||||
82:00.0 RAID bus controller [0104]: 3ware Inc 9750 SAS2/SATA-II RAID PCIe [13c1:1010] (rev 05)
|
||||
...
|
||||
```
|
||||
The ID is in the rightmost square brackets. Then check if there are drivers available.
|
||||
|
||||
I will now focus on [ElRepo](https://elrepo.org/) which provides drivers not supported any more by Red Hat. Check the PCI Device ID on their list of (https://elrepo.org/tiki/DeviceIDs). If you found a driver, then there are also [driver disks provided](https://linuxsoft.cern.ch/elrepo/dud/el8/x86_64/).
|
||||
|
||||
There are two option in providing this driver disk to the installer:
|
||||
|
||||
1. Download the according `.iso` file and extract it on an USB stick labelled with `OEMDRV` and have it connected during installation.
|
||||
2. Extend the kernel command line with `inst.dd=$URL_OF_ISO_FILE`, e.g. with a custom Grub config on the [boot server](https://git.psi.ch/linux-infra/network-boot) or with the sysdb/bob attribute `kernel_cmdline`.
|
||||
|
||||
([Red Hat documentation of this procedure](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/performing_an_advanced_rhel_8_installation/index#updating-drivers-during-installation_installing-rhel-as-an-experienced-user))
|
||||
|
||||
At the end do not forget to enable the ElRepo RPM package repository in Hiera to also get new drivers for updated kernels:
|
||||
```
|
||||
# enable 3rd-party drivers from ElRepo
|
||||
rpm_repos::default:
|
||||
- 'elrepo_rhel8'
|
||||
```
|
||||
|
||||
#### Missing RAID Drivers on Kernel Upgrade
|
||||
|
||||
If the machine does not boot after provisioning or after an kernel upgrade with
|
||||
```
|
||||
Warning: /dev/mapper/vg_root-lv_root does not exist
|
||||
Warning: /dev/vg_root/lv_root does not exist
|
||||
```
|
||||
after a lot of
|
||||
```
|
||||
Warning: dracut-initqueue timeout - starting timeout scripts
|
||||
```
|
||||
the it could be that the RAID controller supported was removed with the new kernel, e.g. for the LSI MegaRAID SAS there is a [dedicated article](https://access.redhat.com/solutions/3751841).
|
||||
|
||||
For the LSI MegaRAID SAS there is still a driver available in ElRepo, so it can be installed during provisioning by Puppet.
|
||||
To do so add to Hiera:
|
||||
```
|
||||
base::pkg_group::....:
|
||||
- 'kmod-megaraid_sas'
|
||||
|
||||
rpm_repos::default:
|
||||
- 'elrepo_rhel8'
|
||||
```
|
||||
|
||||
### AFS cache partition not created due to existing XFS signature
|
||||
It can happen when upgrading an existing RHEL 7 installation that the puppet run produces
|
||||
```
|
||||
Error: Execution of '/usr/sbin/lvcreate -n lv_openafs --size 2G vg_root' returned 5: WARNING: xfs signature detected on /dev/vg_root/lv_openafs at offset 0. Wipe it? [y/n]: [n]
|
||||
```
|
||||
This needs to be fixed manually:
|
||||
- run the complaining command and approve (or use `--yes`)
|
||||
- run `puppet agent -t` to finalize the configuration
|
||||
|
||||
### Puppet run fails to install KCM related service/timer on Slurm node
|
||||
|
||||
The Puppet run fails with
|
||||
```
|
||||
Notice: /Stage[main]/Profile::Aaa/Systemd::Service[kcm-destroy]/Exec[start-global-user-service-kcm-destroy]/returns: Failed to connect to bus: Connection refused
|
||||
Error: '/usr/bin/systemctl --quiet start --global kcm-destroy.service' returned 1 instead of one of [0]
|
||||
Error: /Stage[main]/Profile::Aaa/Systemd::Service[kcm-destroy]/Exec[start-global-user-service-kcm-destroy]/returns: change from 'notrun' to ['0'] failed: '/usr/bin/systemctl --quiet start --global kcm-destroy.service' returned 1 instead of one of [0] (corrective)
|
||||
Notice: /Stage[main]/Profile::Aaa/Profile::Custom_timer[kcm-cleanup]/Systemd::Timer[kcm-cleanup]/Exec[start-global-user-timer-kcm-cleanup]/returns: Failed to connect to bus: Connection refused
|
||||
Error: '/usr/bin/systemctl --quiet start --global kcm-cleanup.timer' returned 1 instead of one of [0]
|
||||
Error: /Stage[main]/Profile::Aaa/Profile::Custom_timer[kcm-cleanup]/Systemd::Timer[kcm-cleanup]/Exec[start-global-user-timer-kcm-cleanup]/returns: change from 'notrun' to ['0'] failed: '/usr/bin/systemctl --quiet start --global kcm-cleanup.timer' returned 1 instead of one of [0] (corrective)
|
||||
```
|
||||
|
||||
This is caused by the use of KCM as default Kerberos credential cache in RHEL8:
|
||||
|
||||
- for RHEL8 it was recommended to use the KCM provided by sssd as Kerberos Credential Cache.
|
||||
- a major issue of this KCM is that it does not remove outdated caches
|
||||
- this leads to a Denial-of-Service situation when all 64 slots are filled, new logins start to fail after (this is persistent, reboot does not help).
|
||||
- we fix this issue by running regularly cleanup script in user context
|
||||
- this "user context" is handled by the `systemd --user` instance, which is started on the first login and keeps running until the last session ends.
|
||||
- that systemd user instance is started by `pam_systemd.so`
|
||||
- `pam_systemd.so` and `pam_slurm_adopt.so` conflict because both want to set up cgroups
|
||||
- because of this there is no `pam_systemd.so` configured on Slurm nodes thus there is no `systemd --user` instance
|
||||
|
||||
I see two options to solve this issue:
|
||||
- do not use KCM
|
||||
- get somehow systemd user instance running
|
||||
|
||||
|
||||
#### do not use KCM
|
||||
Can be done in Hiera, to get back to RHEL7 behavior do
|
||||
|
||||
aaa::default_krb_cache: "KEYRING:persistent:%{literal('%')}{uid}"
|
||||
|
||||
then there will be no KCM magic any more.
|
||||
We could also make this automatically happen in Puppet when Slurm is enabled.
|
||||
|
||||
|
||||
#### get somehow systemd user instance running
|
||||
`pam_systemd.so` does not want to take its hands off cgroups:
|
||||
https://github.com/systemd/systemd/issues/13535
|
||||
|
||||
But there is documented how to get (part?) of the `pam_systemd.so` functionality running with Slurm:
|
||||
https://slurm.schedmd.com/pam_slurm_adopt.html#PAM_CONFIG
|
||||
(the Prolog, TaskProlog and Epilog part).
|
||||
I wonder if that also starts a `systemd --user` instance or not. Or if it is possible to somehow integrate the start of it therein.
|
||||
|
||||
|
||||
### Workstation Installation Takes Long and Seams to Hang
|
||||
On the very first puppet run the command to install the GUI packages takes up to 10 minutes and it looks like it
|
||||
is hanging. Usually it is after the installation of `/etc/sssd/sssd.conf`. Just give it a bit time.
|
||||
|
||||
### "yum/dnf search" Gives Permission Denied as Normal User
|
||||
It works fine beside the below error message:
|
||||
```
|
||||
Failed to store expired repos cache: [Errno 13] Permission denied: '/var/cache/dnf/x86_64/8/expired_repos.json'
|
||||
```
|
||||
which is IMHO OK to not allow a normal user to do changes there.
|
||||
|
||||
@@ -0,0 +1,48 @@
|
||||
# Installation
|
||||
|
||||
## Minimal HW/VM Requirements
|
||||
- 4GB RAM
|
||||
- 33GB Disk
|
||||
|
||||
## Network Installation
|
||||
|
||||
The machine you want to install needs to be [registered in `sysdb`](../admin-guide/deployment/sample). If you don't have the bob command installed locally you can login to __lxsup.psi.ch__ to use it. Remember that you need a valid Kerberos ticket before modifying a sysdb entry via `bob`.
|
||||
More details regaring `bob` can be found [here](https://git.psi.ch/linux-infra/bob).
|
||||
|
||||
Optional you can set `netboot` and RHEL 8 installer but that can also be selected manually in be boot menu:
|
||||
|
||||
```
|
||||
bob node netboot $FQDN
|
||||
bob node set-attr $FQDN ipxe_installer=rhel8install
|
||||
```
|
||||
|
||||
|
||||
|
||||
### Installation with UEFI
|
||||
Start the machine and select network boot (if not already the default), then you get following menu:
|
||||
|
||||
|
||||
There select "Install Red Hat Enterprise Linux 8.7"
|
||||
|
||||
|
||||
|
||||
__NOTE:__ After the installation the boot order will be changed to localboot again! So if you reinstall make sure that you re-set the bootorder via the efi menu or the commandline: https://linux.die.net/man/8/efibootmgr
|
||||
```
|
||||
[root@lx-test-02 ~]# efibootmgr
|
||||
BootCurrent: 0004
|
||||
BootOrder: 0004,0002,0000,0001,0003
|
||||
Boot0000* EFI Virtual disk (0.0)
|
||||
Boot0001* EFI VMware Virtual SATA CDROM Drive (0.0)
|
||||
Boot0002* EFI Network
|
||||
Boot0003* EFI Internal Shell (Unsupported option)
|
||||
Boot0004* Red Hat Enterprise Linux
|
||||
|
||||
[root@lx-test-02 ~]# efibootmgr --bootorder 2,4,0,1,3
|
||||
```
|
||||
(there is no need to have the leading 000 )
|
||||
|
||||
### Installation with Legacy BIOS
|
||||
Start the machine and select network boot (if not already the default), then you get following menu, where the default depends on the `sysdb` configuration, but you may override it manualy:
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 8.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.3 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.1 KiB |
@@ -0,0 +1,333 @@
|
||||
# Kerberos on RHEL 8
|
||||
|
||||
This document describes the state of Kerberos on RHEL 8.
|
||||
This includes the current open issues, a user guide and how we solved the KCM (Kerberos Cache Manager) issues.
|
||||
At the bottom you find sequence diagrams showing the interactions concerning authentication and Kerberos.
|
||||
|
||||
## Open Problems
|
||||
|
||||
- cleanup of caches, else we might end up in DoS situation. Best we do this `systemd --unit` managed.
|
||||
- Kerberos with Firefox does not work yet.
|
||||
|
||||
## User Guide
|
||||
|
||||
### Manage Ticket for Admin User
|
||||
If you need for administrative operations a TGT from your admin user (e.g. `buchel_k-adm`), then do
|
||||
```
|
||||
OLD_KRB5CCNAME=$KRB5CCNAME
|
||||
export KRB5CCNAME=KCM:$(id -u):admin
|
||||
kinit $(id -un)-adm
|
||||
```
|
||||
and after you are done do
|
||||
```
|
||||
kdestroy
|
||||
export KRB5CCNAME=$OLD_KRB5CCNAME
|
||||
```
|
||||
to delete your administrative tickets and to get back to your normal credential cache.
|
||||
|
||||
### Update TGT on Long Running Sessions
|
||||
The TGT will be automatically renewed for 7 days.
|
||||
Note that a screen unlock or a new connection with NoMachine NX will update the credential cache with a new TGT.
|
||||
|
||||
But also manual reauthentication is possible. Inside the session you can do
|
||||
```
|
||||
kinit
|
||||
```
|
||||
Outside of the session you first need to figure out the credential cache used.
|
||||
First get the process ID of the process which needs authentication, then
|
||||
```
|
||||
$ strings /proc/$PID/environ | grep KRB5CCNAME
|
||||
KRB5CCNAME=KCM:44951:iepgjskbkd
|
||||
$
|
||||
```
|
||||
and then a
|
||||
```
|
||||
KRB5CCNAME=KCM:44951:iepgjskbkd kinit
|
||||
```
|
||||
will update given credential cache.
|
||||
|
||||
Note that for AFS it will look in all caches for a valid TGT, so logging in on the desktop or ssh with password or ticket delegation is sufficient to make AFS access work for another week.
|
||||
|
||||
### List all Credential Caches
|
||||
```
|
||||
KRB5CCNAME=KCM: klist -l
|
||||
```
|
||||
lists all caches and
|
||||
```
|
||||
KRB5CCNAME=KCM: klist -A
|
||||
```
|
||||
also the tickets therein.
|
||||
|
||||
|
||||
## Kerberos Use and Test Cases
|
||||
|
||||
- ssh authentication (authentication method `gssapi-with-mic`)
|
||||
- ssh TGT (ticket granting ticket) delegation (with `GSSAPIDelegateCredentials yes`)
|
||||
- AFS authentication (`aklog`)
|
||||
- AFS administrative operations where the user switches to a separate admin principal (e.g. `buchel_k-adm`)
|
||||
- long running sessions with `nohup`, `tmux` and `screen`
|
||||
- local desktop: get new TGT on login
|
||||
- local desktop: TGT renewal after reauthentication on lock screen
|
||||
- remote desktop with NoMachine NX: get new TGT on login
|
||||
- remote desktop with NoMachine NX: TGT renewal after reconnection
|
||||
- website authentication (`SPNEGO` with Firefox, Chrome)
|
||||
|
||||
## KCM (Kerberos Cache Manager)
|
||||
|
||||
In RHEL 7 we are using the `KEYRING` (kernel keyring) cache,
|
||||
whereas for RHEL 8 there came early the wish to use KCM instead,
|
||||
which also is the [new default](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/identity-management_considerations-in-adopting-rhel-8#kcm-replace-keyring-default-cache_considerations-in-adopting-RHEL-8).
|
||||
|
||||
The Kerberos documentation contains a [reference for all available cache types]( https://web.mit.edu/kerberos/www/krb5-latest/doc/basic/ccache_def.html).
|
||||
|
||||
The KCM cache is provided by a dedicated daemon, for RHEL8 this is `sssd_kcm` which has been programmed by Red Hat itself.
|
||||
|
||||
### Advantages of KCM
|
||||
|
||||
The advantage of KCM is that the caches are permanent and survive daemon restarts and system reboots without the need to fiddle around with files and file permission. This simplifies daemon and container use cases.
|
||||
It also automatically renews tickets which is handy for every use case.
|
||||
|
||||
### User Based vs Session Based
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
- user may destroy the cache (it is good security practice to have a `kdestroy` in `.bash_logout` to ensure nobody on the machine can use your tokens after logging out)
|
||||
- software may put tokens into the cache which suddenly are not there any more
|
||||
- the magic/heuristic used to select might not work optimally for all use cases (as we see below `sshd-kcm` fails horribly...)
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
### 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:`.
|
||||
|
||||
#### 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:
|
||||
|
||||
```
|
||||
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.
|
||||
|
||||
#### 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.
|
||||
```
|
||||
$ ssh lxdev01.psi.ch
|
||||
Last login: Tue Oct 4 09:50:33 2022
|
||||
[buchel_k@lxdev01 ~]$ klist -l
|
||||
Principal name Cache name
|
||||
-------------- ----------
|
||||
buchel_k@D.PSI.CH KCM:44951:42923
|
||||
buchel_k@D.PSI.CH KCM:44951:12312 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:42199 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:40168
|
||||
buchel_k@D.PSI.CH KCM:44951:8914 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:62275 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:27078 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:73924 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:72006
|
||||
buchel_k@D.PSI.CH KCM:44951:64449 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:60061 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:36925 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:48361 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:49651 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:76984 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:54227 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:85800 (Expired)
|
||||
[buchel_k@lxdev01 ~]$ klist -l
|
||||
Principal name Cache name
|
||||
-------------- ----------
|
||||
buchel_k@D.PSI.CH KCM:44951:12312 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:42199 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:40168
|
||||
buchel_k@D.PSI.CH KCM:44951:8914 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:62275 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:27078 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:73924 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:72006
|
||||
buchel_k@D.PSI.CH KCM:44951:64449 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:60061 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:36925 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:48361 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:42923
|
||||
buchel_k@D.PSI.CH KCM:44951:49651 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:76984 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:54227 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:85800 (Expired)
|
||||
[buchel_k@lxdev01 ~]$
|
||||
```
|
||||
Note that the automatic AFS token renewal was created after we have experienced this issue.
|
||||
|
||||
|
||||
#### Busy Loop of `goa-daemon`
|
||||
If the [GNOME Online Accounts](https://wiki.gnome.org/Projects/GnomeOnlineAccounts) encounters a number of Kerberos credential caches it goes into a busy loop and causes `sssd-kcm` to consume 100% of one core. Happily ignored bugs at [Red Hat](https://bugzilla.redhat.com/show_bug.cgi?id=1645624#c113) and [Gnome](https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/79).
|
||||
|
||||
#### Zombie Caches by NoMachine NX
|
||||
On a machine with remote desktop access using NoMachine NX I have seen following cache list in the log:
|
||||
```
|
||||
# /usr/bin/klist -l
|
||||
Principal name Cache name
|
||||
-------------- ----------
|
||||
fische_r@D.PSI.CH KCM:45334:73632 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:45334:55706 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:44226 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:40904 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:62275 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:89020 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:45334:25061 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:45334:35168 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:73845 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:47508 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:34317 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:52058 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:16150 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:84445 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:69076 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:45334:87346 (Expired)
|
||||
fische_r@D.PSI.CH KCM:45334:57070 (Expired)
|
||||
```
|
||||
or on another machine in my personal list:
|
||||
```
|
||||
[buchel_k@pc14831 ~]$ klist -l
|
||||
Principal name Cache name
|
||||
-------------- ----------
|
||||
buchel_k@D.PSI.CH KCM:44951:69748
|
||||
buchel_k@D.PSI.CH KCM:44951:18506 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:5113 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:52685 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:13951 (Expired)
|
||||
PC14831$@D.PSI.CH KCM:44951:43248 (Expired)
|
||||
PC14831$@D.PSI.CH KCM:44951:58459 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:14668 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:92516 (Expired)
|
||||
[buchel_k@pc14831 ~]$
|
||||
```
|
||||
Both show principals which I am very sure that they have not been added manually by the user. And somewhere there is a security issue, either `sssd-kcm` or NoMachine NX.
|
||||
|
||||
In another experiment I logged into a machine with `ssh` and did `kdestroy -A` which should destroy all caches:
|
||||
|
||||
```
|
||||
[buchel_k@mpc2959 ~]$ kdestroy -A
|
||||
[buchel_k@mpc2959 ~]$ klist -l
|
||||
Principal name Cache name
|
||||
[buchel_k@mpc2959 ~]$
|
||||
```
|
||||
|
||||
After I logged in via NoMachine NX I got a cache expired since more than two month:
|
||||
|
||||
```
|
||||
[buchel_k@mpc2959 ~]$ klist -l
|
||||
Principal name Cache name
|
||||
|
||||
buchel_k@D.PSI.CH KCM:44951:16795 (Expired)
|
||||
buchel_k@D.PSI.CH KCM:44951:69306
|
||||
[buchel_k@mpc2959 ~]$ klist
|
||||
Ticket cache: KCM:44951:16795
|
||||
Default principal: buchel_k@D.PSI.CH
|
||||
|
||||
Valid starting Expires Service principal
|
||||
13.07.2022 11:35:51 13.07.2022 21:26:19 krbtgt/D.PSI.CH@D.PSI.CH
|
||||
renew until 14.07.2022 11:26:19
|
||||
[buchel_k@mpc2959 ~]$ date
|
||||
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.
|
||||
|
||||
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...
|
||||
|
||||
I have not found a lot concerning Kerberos on the NoMachine website.
|
||||
|
||||
## Solution Attempts
|
||||
|
||||
Ideally we would get to a solution which can do the following:
|
||||
|
||||
- interactive user sessions are isolated do not interfer 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
|
||||
- expired caches get somehow cleaned up
|
||||
|
||||
|
||||
### Only One Cache
|
||||
|
||||
The `sssd-kcm` limits the number of caches by default to 64, but that can be changed to 1 with the `max_uid_ccaches`.
|
||||
So there would be only one cache, shared by all sessions, but at least the KCM cannot serve anything but the latest.
|
||||
|
||||
But some logins do not work any more when the maximum number of caches is hit as already documented above in the chapter "No Cleanup of Expired Caches".
|
||||
|
||||
|
||||
### 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.
|
||||
This now works very robust and can also recover from expiration when a new ticket gets available.
|
||||
|
||||
|
||||
### Setup Shared or Isolated Caches with KRB5CCNAME in own PAM Module
|
||||
|
||||
The self-made PAM module `pam_single_kcm_cache.so` improves the situation by setting
|
||||
|
||||
- `KRB5CCNAME=KCM:$UID:desktop` to use a shared credential cache for desktop sessions and `systemd --user`
|
||||
- `KRB5CCNAME=KCM:$UID:$RANDOM_LETTERS` for text sessions to provide session isolation
|
||||
|
||||
and providing a working TGT in these caches.
|
||||
|
||||
I identified so far two cases of the program flow in PAM to manage:
|
||||
- **TGT delegation** as done by `sshd` with authentication method `gssapi-with-mic`, where a new cache is created by `sshd` and then filled with the delegated ticket
|
||||
- **TGT creation** as done by `pam_sss.so` upon password authentication, where a new TGT is created an placed into the `KCM` managed default cache.
|
||||
|
||||
Now there is no simple and bullet proof selection of where the TGT ends up in KCM.
|
||||
The KCM designated default cache might it be or not.
|
||||
To work around this, the module iterates through all credential caches provided by the KCM copies a TGT which is younger than 10 s and has a principal fitting the username.
|
||||
|
||||
Note that the reason for `systemd --user` to use the same credential cache as the desktop sessions is that at least Gnome uses it to start the user programs like Evolution or Firefox.
|
||||
|
||||
The code is publicly available on [Github](https://github.com/paulscherrerinstitute/pam_single_kcm_cache).
|
||||
|
||||
## Diagrams about Kerberos related Interactions
|
||||
|
||||
Below diagrams show how PAM and especially `pam_single_kcm_cache.so` interact with the KCM in different use cases.
|
||||
|
||||
### Login with SSH using Password Authentication
|
||||
|
||||
|
||||
That is kind of the "common" authentication case where all important work is done in PAM. This is the same for login on the virtual console or when using `su` with password. At the end there is an shell session with a credential cache which is not used by any other session (unless the user shares it somehow manually). Like this session isolation is achieved.
|
||||
|
||||
### Login with SSH using Kerberos Authentication and TGT Delegation
|
||||
|
||||
|
||||
This is a bit simpler as all the authentication is done in `sshd` and only the session setup is done by PAM. Note that `sshd` does not use the default cache, but instead creates always a new one with the delegated TGT.
|
||||
|
||||
### Systemd User Instance
|
||||
|
||||
In above diagrams we see how `systemd --user` is being started. It is also using PAM to setup its own session, but it does not do any authentication.
|
||||
|
||||
|
||||
|
||||
Here we use a predefined name for the credential cache so it can be shared with the desktop sessions. The next diagram shows more in detail how `systemd --user` and the Gnome desktop interact.
|
||||
|
||||
### Gnome Desktop
|
||||
|
||||
This is the most complex use case:
|
||||
|
||||
|
||||
|
||||
At the end we have a well known shared credential cache between Gnome and `systemd --user`. This is needed `systemd --user` is used extensively by Gnome. Important is that the Kerberos setup already happens at authentication phase as there is no session setup phase for screen unlock as the user returns there to an already existing session.
|
||||
|
||||
With NoMachine NX this is configured similarly.
|
||||
|
||||
## PS
|
||||
There is an advantage in the broken `sssd-kcm` default cache selection: it forces us to make our stuff robust against KCM glitches, which might also occur with a better manager, just way less often and then it would be more harder to explain and to track down.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 216 KiB |
@@ -0,0 +1,97 @@
|
||||
@startuml
|
||||
|
||||
title
|
||||
**Desktop Authentication**
|
||||
Needs a shared credential cache with //systemd --user// as it is used to start some processes
|
||||
and the TGT needs to be updated on reauthentication when unlocking the screen.
|
||||
end title
|
||||
|
||||
actor user
|
||||
box gdm
|
||||
participant gdm
|
||||
participant libpam
|
||||
participant "pam_sssd.so" as pam_sssd
|
||||
participant "pam_systemd.so" as pam_systemd
|
||||
participant "pam_single_kcm_cache.so" as pam_single_kcm_cache
|
||||
end box
|
||||
participant sssd
|
||||
participant "systemd --user" as systemd
|
||||
box KCM
|
||||
participant "sssd-kcm" as sssd_kcm
|
||||
participant "credential cache KCM:$UID:61555" as default_cache
|
||||
participant "credential cache KCM:$UID:desktop" as shared_cache
|
||||
end box
|
||||
box Gnome
|
||||
participant "gnome-session-binary" as gnome_session
|
||||
participant "gnome-shell" as gnome_shell
|
||||
participant Firefox as firefox
|
||||
participant "gnome-terminal" as gnome_terminal
|
||||
end box
|
||||
box Active Directory
|
||||
participant KDC as kdc
|
||||
end box
|
||||
|
||||
== authentication ==
|
||||
user -> gdm : authenticates with password
|
||||
gdm -> libpam : authenticate user
|
||||
libpam -> pam_sssd : //pam_sm_setcred()//
|
||||
pam_sssd -> sssd : authenticate
|
||||
sssd -> kdc : authenticate and get TGT
|
||||
sssd -> sssd_kcm : get default cache
|
||||
sssd -> default_cache : place TGT
|
||||
libpam -> pam_single_kcm_cache : //pam_sm_setcred()//
|
||||
pam_single_kcm_cache -> sssd_kcm : iterate all suitable caches to find newest TGT
|
||||
note right: the default cache may change in between
|
||||
pam_single_kcm_cache -> default_cache: get TGT
|
||||
pam_single_kcm_cache -> sssd_kcm : create new shared cache if it does not exist yet
|
||||
create shared_cache
|
||||
sssd_kcm -> shared_cache: create
|
||||
pam_single_kcm_cache -> shared_cache: place newest TGT
|
||||
pam_single_kcm_cache -> libpam: set //KRB5CCNAME=KCM:$UID:desktop//
|
||||
|
||||
gdm -> libpam : setup session
|
||||
libpam -> pam_systemd : //pam_sm_open_session()//
|
||||
create systemd
|
||||
pam_systemd -> systemd: start if not running yet
|
||||
|
||||
== starting the desktop ==
|
||||
create gnome_session
|
||||
gdm -> gnome_session : start Gnome session
|
||||
gnome_session -> systemd : start some Gnome services
|
||||
gnome_session -> gnome_session: start more Gnome services
|
||||
create gnome_shell
|
||||
gnome_session -> gnome_shell: start Gnome Shell
|
||||
|
||||
== starting programs ==
|
||||
user -> gnome_shell: open browser
|
||||
create firefox
|
||||
gnome_shell -> firefox : start
|
||||
|
||||
user -> gnome_shell : open terminal
|
||||
gnome_shell -> systemd: start gnome-terminal
|
||||
create gnome_terminal
|
||||
systemd -> gnome_terminal: start
|
||||
|
||||
== screen lock and unlock ==
|
||||
user -> gnome_shell : lock screen
|
||||
gnome_shell -> gdm : lock screen
|
||||
|
||||
user -> gdm : authenticates with password
|
||||
gdm -> libpam : authenticate user
|
||||
libpam -> pam_sssd : //pam_sm_setcred()//
|
||||
pam_sssd -> sssd : authenticate
|
||||
sssd -> kdc : authenticate and get TGT
|
||||
sssd -> sssd_kcm : get default cache
|
||||
sssd -> default_cache : place TGT
|
||||
libpam -> pam_single_kcm_cache : //pam_sm_setcred()//
|
||||
pam_single_kcm_cache -> sssd_kcm : iterate all suitable caches to find newest TGT
|
||||
note right: the default cache may change in between
|
||||
pam_single_kcm_cache -> default_cache: get TGT
|
||||
pam_single_kcm_cache -> sssd_kcm : get shared cache
|
||||
pam_single_kcm_cache -> shared_cache: place newest TGT
|
||||
note over gdm : no session setup step
|
||||
gdm -> gnome_shell : screen unlocked
|
||||
|
||||
@enduml
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 90 KiB |
@@ -0,0 +1,54 @@
|
||||
@startuml
|
||||
|
||||
title
|
||||
**SSH with Password Authentication**
|
||||
Provide every shell session an individual and isolated credential cache in KCM.
|
||||
end title
|
||||
hide footbox
|
||||
|
||||
actor user
|
||||
box sshd
|
||||
participant sshd
|
||||
participant libpam
|
||||
participant "pam_sssd.so" as pam_sssd
|
||||
participant "pam_systemd.so" as pam_systemd
|
||||
participant "pam_single_kcm_cache.so" as pam_single_kcm_cache
|
||||
end box
|
||||
participant sssd
|
||||
participant "systemd --user" as systemd
|
||||
box KCM
|
||||
participant "sssd-kcm" as sssd_kcm
|
||||
participant "credential cache KCM:$UID:61555" as default_cache
|
||||
participant "credential cache KCM:$UID:sitmchszro" as random_cache
|
||||
end box
|
||||
participant bash
|
||||
box Active Directory
|
||||
participant KDC as kdc
|
||||
end box
|
||||
|
||||
user -> sshd : connects using //ssh//\nwith authentication method //password//
|
||||
sshd -> libpam : authenticate user
|
||||
libpam -> pam_sssd : //pam_sm_setcred()//
|
||||
pam_sssd -> sssd : authenticate
|
||||
sssd -> kdc : authenticate and get TGT
|
||||
sssd -> sssd_kcm : get default cache
|
||||
sssd -> default_cache : place TGT
|
||||
sshd -> libpam : setup session
|
||||
libpam -> pam_systemd : //pam_sm_open_session()//
|
||||
create systemd
|
||||
pam_systemd -> systemd: start if not running yet
|
||||
libpam -> pam_single_kcm_cache : //pam_sm_open_session()//
|
||||
pam_single_kcm_cache -> sssd_kcm : iterate all suitable caches to find newest TGT
|
||||
note right: the default cache may change in between
|
||||
pam_single_kcm_cache -> default_cache: get TGT
|
||||
pam_single_kcm_cache -> sssd_kcm : create new random cache
|
||||
create random_cache
|
||||
sssd_kcm -> random_cache: create
|
||||
pam_single_kcm_cache -> random_cache: place newest TGT
|
||||
pam_single_kcm_cache -> libpam: set //KRB5CCNAME=KCM:$UID:sitmchszro//
|
||||
create bash
|
||||
sshd -> bash : start
|
||||
|
||||
@enduml
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 80 KiB |
@@ -0,0 +1,49 @@
|
||||
@startuml
|
||||
|
||||
title
|
||||
**SSH with TGT Delegation**
|
||||
Provide every shell session an individual and isolated credential cache in KCM.
|
||||
end title
|
||||
hide footbox
|
||||
|
||||
actor user
|
||||
box sshd
|
||||
participant sshd
|
||||
|
||||
participant libpam
|
||||
participant "pam_systemd.so" as pam_systemd
|
||||
participant "pam_single_kcm_cache.so" as pam_single_kcm_cache
|
||||
end box
|
||||
participant "systemd --user" as systemd
|
||||
box KCM
|
||||
participant "sssd-kcm" as sssd_kcm
|
||||
participant "credential cache KCM:$UID:61555" as new_cache
|
||||
participant "credential cache KCM:$UID:sitmchszro" as random_cache
|
||||
end box
|
||||
participant bash
|
||||
|
||||
user -> sshd : connects using //ssh//\nwith //GSSAPIDelegateCredentials=yes//\nand authentication method //gssapi-with-mic//
|
||||
note right: authentication is done without libpam
|
||||
sshd -> sssd_kcm : get new cache
|
||||
create new_cache
|
||||
sssd_kcm -> new_cache : create
|
||||
sshd -> new_cache : place delegated TGT
|
||||
sshd -> libpam : setup session
|
||||
libpam -> pam_systemd : //pam_sm_open_session()//
|
||||
create systemd
|
||||
pam_systemd -> systemd: start if not running yet
|
||||
libpam -> pam_single_kcm_cache : //pam_sm_open_session()//
|
||||
pam_single_kcm_cache -> sssd_kcm : iterate all suitable caches to find newest TGT
|
||||
note right: the default cache might be KCM:$UID:61555 or not
|
||||
pam_single_kcm_cache -> new_cache: get TGT
|
||||
pam_single_kcm_cache -> sssd_kcm : create new random cache
|
||||
create random_cache
|
||||
sssd_kcm -> random_cache: create
|
||||
pam_single_kcm_cache -> random_cache: place newest TGT
|
||||
pam_single_kcm_cache -> libpam: set //KRB5CCNAME=KCM:$UID:sitmchszro//
|
||||
create bash
|
||||
sshd -> bash : start
|
||||
|
||||
@enduml
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
@@ -0,0 +1,35 @@
|
||||
@startuml
|
||||
|
||||
title
|
||||
**Startup of Systemd User Instance**
|
||||
One single //systemd --user// instance spans from the start of the first session
|
||||
to the end of the last session and has access to the same credential cache as the desktop.
|
||||
end title
|
||||
hide footbox
|
||||
|
||||
box Systemd User Instance
|
||||
participant "systemd --user" as systemd
|
||||
participant libpam
|
||||
participant "pam_single_kcm_cache.so" as pam_single_kcm_cache
|
||||
end box
|
||||
box KCM
|
||||
participant "sssd-kcm" as sssd_kcm
|
||||
participant "credential cache KCM:$UID:61555" as default_cache
|
||||
participant "credential cache KCM:$UID:desktop" as shared_cache
|
||||
end box
|
||||
|
||||
note over systemd : no authentication step
|
||||
systemd -> libpam : setup session
|
||||
libpam -> pam_single_kcm_cache : //pam_sm_open_session()//
|
||||
pam_single_kcm_cache -> sssd_kcm : iterate all suitable caches to find newest TGT
|
||||
note right: the default cache may change in between
|
||||
pam_single_kcm_cache -> default_cache: get TGT
|
||||
pam_single_kcm_cache -> sssd_kcm : create shared cache if not yet exists
|
||||
create shared_cache
|
||||
sssd_kcm -> shared_cache: create
|
||||
pam_single_kcm_cache -> shared_cache: place newest TGT
|
||||
pam_single_kcm_cache -> libpam: set //KRB5CCNAME=KCM:$UID:desktop//
|
||||
|
||||
@enduml
|
||||
|
||||
|
||||
@@ -0,0 +1,175 @@
|
||||
# CUDA and Proprietary Nvidia GPU Drivers on RHEL 8
|
||||
|
||||
Managing Nvidia software comes with its own set of challenges.
|
||||
For the most common cases are covered by our Puppet configuration.
|
||||
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**.
|
||||
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).
|
||||
|
||||
### I just need the Nvidia GPU drivers
|
||||
|
||||
Nothing needs to be done, they are installed by default when Nvidia GPUs or accelerators are found.
|
||||
|
||||
### I need CUDA
|
||||
|
||||
Set in Hiera `nvidia::cuda::enable true` and it will automatically install the suitable Nvidia drivers and newest possible CUDA version.
|
||||
|
||||
The `nvidia_persistenced` service is automatically started. If you do not want it, to set `nvidia::cuda::nvidia_persistenced::enable: false`.
|
||||
|
||||
### I need a specific CUDA version
|
||||
|
||||
Then you can additionally set `nvidia::cuda::version` to the desired version.
|
||||
The version must be fully specified (all three numbers, with X.Y.0 for the GA version).
|
||||
|
||||
Note that newer CUDA versions do not support older drivers, for details see Table 3 in the [CUDA Release Notes](https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html).
|
||||
|
||||
### I do not want the Nvidia drivers
|
||||
|
||||
Set in Hiera `nvidia::driver::enable: false`. Note this will be ignored if CUDA is enabled (see above).
|
||||
|
||||
Note they do not get automatically removed when already installed. That you would need to do by hand.
|
||||
|
||||
### I need the Nvidia drivers from a specific driver branch
|
||||
|
||||
The driver branch can be selected in Hiera with `nvidia::driver::branch`. It will then use the latest driver version of that branch. Note that only production branches are available in the PSI package repository.
|
||||
|
||||
### I need a Nvidia driver of a given version
|
||||
|
||||
This is not recommended, still it is possible to do so by setting the exact driver version (X.Y.Z, excluding the package iteration number) in Hiera with `nvidia::driver::version`.
|
||||
|
||||
If the driver version is too old, it will install an older kernel version and you will need a second reboot to activate it.
|
||||
|
||||
### My hardware is very old
|
||||
|
||||
The oldest driver branch packaged by Nvidia for RHEL 8 is `470`. For hardware only supported by older drivers it falls back to ElRepo packaged drivers. You might do that also on purpose in Hiera by setting `nvidia::driver::branch: elrepo` (or when you want an specific ElRepo branch: `nvidia::driver::branch: 390xx`).
|
||||
|
||||
Or you might just live with the fallback to Nouveau (`nvidia::driver::enable: false` in Hiera).
|
||||
|
||||
Alternatively you might also just download and install the Nvidia driver manually.
|
||||
Go to their [Download page](https://www.nvidia.de/Download/index.aspx), select and download the according installer and run it.
|
||||
You best keep Puppet off your driver by setting `nvidia::driver::enable: false` in Hiera.
|
||||
|
||||
## Versioning Mess
|
||||
|
||||
I did not find much information about Nvidia driver version structure and policy. Still I concluded that they use following pattern.
|
||||
|
||||
### 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`.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Also it is not possible to find out from the package meta information if a driver is considered beta or not. That you only find out by googling "Nvidia $DRIVER_VERSION" and looking at the respective driver page. In my experience the first few driver versions of a branch are usually "beta".
|
||||
|
||||
### 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).
|
||||
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.
|
||||
|
||||
Another more automated option to figure out the driver is the third-party tool [`nvidia-detect`](http://elrepo.org/tiki/nvidia-detect) by ElRepo. It tells which driver package from ElRepo it suggests, but it can also be used to figure out which production/long term support branch can be used.
|
||||
|
||||
### CUDA - Driver Compatibility
|
||||
|
||||
A CUDA version needs a suitably new driver version, but old CUDA versions are supported by newer driver versions (drivers are backwards-compatible). To figure out up to which CUDA version runs on your installed driver, check out "Table 3" of the [CUDA release notes](https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html). For each driver branch there is a major 11.x.0 release with possible further bugfix releases.
|
||||
|
||||
|
||||
## Manual Operation
|
||||
|
||||
Instead of using Puppet/Hiera, you may also manage the drivers manually.
|
||||
|
||||
Note that drivers made available by default are curated, that means it contains only non-beta production drivers. If you want all drivers available, you need to use `https://repos.psi.ch/rhel8/sources/cuda8/` as URL for the package repository.
|
||||
|
||||
### Select the Driver Branch
|
||||
|
||||
In the RPM package repository the driver branches are mapped to module streams, so there are different streams for different branches and `dnf module list nvidia-driver` will tell you what is available:
|
||||
|
||||
```
|
||||
# dnf module list nvidia-driver
|
||||
Last metadata expiration check: 2:37:29 ago on Mon 28 Nov 2022 09:15:57 AM CET.
|
||||
CUDA and drivers from Nvidia
|
||||
Name Stream Profiles Summary
|
||||
nvidia-driver latest default [d], fm, ks, src Nvidia driver for latest branch
|
||||
nvidia-driver latest-dkms [d] default [d], fm, ks Nvidia driver for latest-dkms branch
|
||||
nvidia-driver open-dkms default [d], fm, ks, src Nvidia driver for open-dkms branch
|
||||
nvidia-driver 418 default [d], fm, ks, src Nvidia driver for 418 branch
|
||||
nvidia-driver 418-dkms default [d], fm, ks Nvidia driver for 418-dkms branch
|
||||
nvidia-driver 440 default [d], fm, ks, src Nvidia driver for 440 branch
|
||||
nvidia-driver 440-dkms default [d], fm, ks Nvidia driver for 440-dkms branch
|
||||
nvidia-driver 450 default [d], fm, ks, src Nvidia driver for 450 branch
|
||||
nvidia-driver 450-dkms default [d], fm, ks Nvidia driver for 450-dkms branch
|
||||
nvidia-driver 455 default [d], fm, ks, src Nvidia driver for 455 branch
|
||||
nvidia-driver 455-dkms default [d], fm, ks Nvidia driver for 455-dkms branch
|
||||
nvidia-driver 460 default [d], fm, ks, src Nvidia driver for 460 branch
|
||||
nvidia-driver 460-dkms default [d], fm, ks Nvidia driver for 460-dkms branch
|
||||
nvidia-driver 465 default [d], fm, ks, src Nvidia driver for 465 branch
|
||||
nvidia-driver 465-dkms default [d], fm, ks Nvidia driver for 465-dkms branch
|
||||
nvidia-driver 470 default [d], fm, ks, src Nvidia driver for 470 branch
|
||||
nvidia-driver 470-dkms [e] default [d] [i], fm, ks Nvidia driver for 470-dkms branch
|
||||
nvidia-driver 495 default [d], fm, ks, src Nvidia driver for 495 branch
|
||||
nvidia-driver 495-dkms default [d], fm, ks Nvidia driver for 495-dkms branch
|
||||
nvidia-driver 510 default [d], fm, ks, src Nvidia driver for 510 branch
|
||||
nvidia-driver 510-dkms default [d], fm, ks Nvidia driver for 510-dkms branch
|
||||
nvidia-driver 515 default [d], fm, ks, src Nvidia driver for 515 branch
|
||||
nvidia-driver 515-dkms default [d], fm, ks Nvidia driver for 515-dkms branch
|
||||
nvidia-driver 515-open default [d], fm, ks, src Nvidia driver for 515-open branch
|
||||
nvidia-driver 520 default [d], fm, ks, src Nvidia driver for 520 branch
|
||||
nvidia-driver 520-dkms default [d], fm, ks Nvidia driver for 520-dkms branch
|
||||
nvidia-driver 520-open default [d], fm, ks, src Nvidia driver for 520-open branch
|
||||
|
||||
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 "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.
|
||||
|
||||
Finally the `*-open` module streams contain the new open source drivers which currently do not provide the full feature set of the propretiary ones.
|
||||
|
||||
### Install a Driver
|
||||
|
||||
Best works to install the whole module stream:
|
||||
```
|
||||
dnf module install "nvidia-driver:$STREAM"
|
||||
```
|
||||
|
||||
Alternatively the module stream might be enabled first (`dnf module enable "nvidia-driver:$STREAM"`) and the packages installed individually after, but then you have to figure out yourself what all is needed.
|
||||
|
||||
If the installation command is rather unhappy and complains a lot about `is filtered out by modular filtering`, then there is already a module stream enabled and some driver installed. So to clean that up do:
|
||||
```
|
||||
dnf remove cuda-driver nvidia-driver
|
||||
dnf module reset nvidia-driver
|
||||
```
|
||||
Note that this will also remove installed CUDA packages.
|
||||
|
||||
### Install CUDA
|
||||
|
||||
It is not recommended to install the `cuda` meta-package directly, because that required the latest drivers from the "new feature" branch. It is better to install the `cuda-11-x` meta-package instead, which installs the CUDA version suitable to your driver and keeps it then updated with bugfix releases to this specific major release. Check out the Table 3 in the [CUDA Release Notes](https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html) for details.
|
||||
|
||||
The `cuda` meta-package is by default excluded as explained above. If you still want to use it, do
|
||||
```
|
||||
dnf --disableexcludes cuda install cuda
|
||||
```
|
||||
|
||||
After manual CUDA installation you should think about enabling and starting `nvidia-persistenced`:
|
||||
```
|
||||
systemctl enable nvidia-persistenced
|
||||
systemctl start nvidia-persistenced
|
||||
```
|
||||
|
||||
|
||||
## Regular Tasks by the Core Linux Team
|
||||
- classify new driver branches and beta versions in the [snapshot preparation script](https://git.psi.ch/linux-infra/rpm-repo-utils/-/blob/main/bin/fix-snapshot/20_remove_nvidia_beta_drivers#L90)
|
||||
- update the latest production branch in [Puppet managed vidia software installation script](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/code/modules/profile/files/nvidia/ensure-nvidia-software#L17)
|
||||
- add more production/long term support branches supported by [`nvidia-detect`](http://elrepo.org/tiki/nvidia-detect) to the [Puppet managed Nvidia software installation script](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/code/modules/profile/files/nvidia/ensure-nvidia-software#L62)
|
||||
- update the [driver version to CUDA version mapping script](https://git.psi.ch/linux-infra/puppet/-/blob/preprod/code/modules/profile/files/nvidia/suitable_cuda_version#L21) according to new entries in the [CUDA Release Notes](https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html)
|
||||
@@ -0,0 +1,37 @@
|
||||
# Vendor Documentation
|
||||
|
||||
## User Documentation
|
||||
|
||||
* [Using the desktop environment in RHEL-8](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/)
|
||||
|
||||
## Administrator Documentation
|
||||
|
||||
* [Configuring basic system settings](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/)
|
||||
* [Administration and configuration tasks using System Roles in RHEL](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/administration_and_configuration_tasks_using_system_roles_in_rhel/)
|
||||
* [Deploying different types of servers](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/)
|
||||
* [Using SELinux ](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/)
|
||||
|
||||
## Product Documentation
|
||||
|
||||
### Red Hat Enterprise Linux 8
|
||||
* [Red Hat Enterprise Linux 8](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/)
|
||||
|
||||
### Red Hat Ansible Tower (AWX)
|
||||
* [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 Engine
|
||||
* [Ansible Documentation Overview](https://docs.ansible.com/)
|
||||
* [Ansible Engine](https://docs.ansible.com/ansible/latest/index.html)
|
||||
* [Ansible User Guide](https://docs.ansible.com/ansible/latest/user_guide/index.html)
|
||||
|
||||
### Red Hat Satellite
|
||||
* [Red Hat Satellite Documentation](https://access.redhat.com/documentation/en-us/red_hat_satellite/6.9/)
|
||||
* [Administering Red Hat Satellite](https://access.redhat.com/documentation/en-us/red_hat_satellite/6.9/html/administering_red_hat_satellite/)
|
||||
* [Managing Hosts](https://access.redhat.com/documentation/en-us/red_hat_satellite/6.9/html/managing_hosts/)
|
||||
* [Provisioning Guide](https://access.redhat.com/documentation/en-us/red_hat_satellite/6.9/html/provisioning_guide/)
|
||||
* [Content Management Guide](https://access.redhat.com/documentation/en-us/red_hat_satellite/6.9/html/content_management_guide/)
|
||||
* [Adding Custom RPM Repositories](https://access.redhat.com/documentation/en-us/red_hat_satellite/6.9/html/content_management_guide/importing_custom_content#Importing_Custom_Content-Creating_a_Custom_RPM_Repository)
|
||||
* [Uploading Content to Custom RPM Repositories](https://access.redhat.com/documentation/en-us/red_hat_satellite/6.9/html/content_management_guide/importing_custom_content#uploading-content-to-a-custom-rpm-repository)
|
||||
@@ -0,0 +1,74 @@
|
||||
# RHEL9 Hardware Compatibility
|
||||
|
||||
Here are hardware tests with RHEL9 on standard PSI hardware documented.
|
||||
|
||||
Generally speaking has Linux a rather good hardware compatibility with PC hardware, usually the older the hardware the better the support.
|
||||
|
||||
## Desktop Hardware
|
||||
|
||||
### HP Elite Mini 800 G9 Desktop PC
|
||||
- ✔ NIC
|
||||
- ✔ GPU
|
||||
- ✔ HDMI
|
||||
- ✔ DP
|
||||
- ✔ USB
|
||||
- ✔ Audio
|
||||
|
||||
### HP Z2 Tower G9 Workstation Desktop PC
|
||||
- ✔ NIC
|
||||
- ✔ GPU
|
||||
- ✔ DP
|
||||
- ✔ USB
|
||||
- ✔ Audio
|
||||
|
||||
## Mobile Hardware
|
||||
|
||||
### HP ZBook Studio 16 inch G10 Mobile Workstation PC
|
||||
- ❌/✔ Installation only with extra steps
|
||||
- ✔ NIC (HP USB-C to RJ45 Adapter G2)
|
||||
- ✔ WLAN
|
||||
- ✔ GPU
|
||||
- ✔ USB
|
||||
- ❌/✔ Audio (manual firmware binary install from https://github.com/thesofproject/sof-bin/ required), microphone and ear plugs work, but not the speaker
|
||||
- ✔ Webcam
|
||||
- ✔ Bluetooth
|
||||
- SIM slot (not tested)
|
||||
- fingerprint scanner (not tested)
|
||||
|
||||
#### Installation
|
||||
- Nouveau driver fails on the Nvidia chip, so modesetting needs to be disabled:
|
||||
```
|
||||
bob node set-attr pcXYZ.psi.ch "kernel_cmdline=nomodeset nouveau.modeset=0"
|
||||
```
|
||||
- Register the system "Pass Through" MAC address (you find it in the BIOS).
|
||||
- Installation did not work with the "HP USB-C to RJ45 Adapter G2": use another, registered adapter or dock instead.
|
||||
- At the final boot the Nvidia drivers are installed automatically, but cannot be activated and the screen turns black. Power off and on again, then the Nvidia drivers get loaded properly on the next boot.
|
||||
|
||||
### HP EliteBook 840 14 inch G10 Notebook PC
|
||||
- ✔ WLAN
|
||||
- ✔ GPU
|
||||
- ✔ HDMI
|
||||
- ✔ USB
|
||||
- ❌/✔ Audio (manual firmware binary install from https://github.com/thesofproject/sof-bin/ required)
|
||||
- ✔ Webcam
|
||||
- ✔ Bluetooth
|
||||
- SIM slot (not tested)
|
||||
- Card reader (not tested)
|
||||
|
||||
## Test Details
|
||||
|
||||
- network card by installation via network
|
||||
- GPU by running graphical desktop, for Nvidia GPUs check if Nvidia drivers are used
|
||||
- HDMI
|
||||
- DP
|
||||
- USB by mouse, keyboard
|
||||
- notebook:
|
||||
- wifi
|
||||
- bluetooth (headset working?)
|
||||
- microphone
|
||||
- speaker
|
||||
- webcam
|
||||
- Dock
|
||||
- network
|
||||
- USB by mouse, keyboard
|
||||
- HDMI
|
||||
@@ -0,0 +1,66 @@
|
||||
# Red Hat Enterprise Linux 9
|
||||
|
||||
## Alpha Testing
|
||||
|
||||
We encourage you to install RHEL9 on testing systems and tell us what we may have broken, what bugs you run into and what features you are missing. Please be aware of certain things we changed on how we want the base operating system to work, listed below.
|
||||
|
||||
Bugs and issues can be reported in the [Linux project in JIRA](https://jira.psi.ch/browse/PSILINUX).
|
||||
|
||||
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)
|
||||
|
||||
|
||||
## Changes for Base Installation
|
||||
|
||||
### No Support for AFS
|
||||
The future support model for AFS or the service and functionality it provides is currently under consideration. Consequently it has been decided not to support AFS in the PSI RHEL9 distribution at the time being.
|
||||
|
||||
|
||||
### Network Configuration
|
||||
By default the network configuration is handed over to NetworkManager which does automatic configuation.
|
||||
|
||||
If you wish different behaviour, e.g. for static IP addresses, please check out the [Network Configuration guide](../admin-guide/configuration/networking).
|
||||
|
||||
|
||||
### Disk Layout
|
||||
Provided disk size is 64GB for virtual machines.
|
||||
|
||||
| Name | Path | Size | Type | LVM |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| root | / | 16GB | xfs | yes |
|
||||
| home | /home | 2GB | xfs | yes |
|
||||
| tmp | /tmp | 2GB | xfs | yes |
|
||||
| var | /var | 16GB | xfs | yes |
|
||||
| log | /var/log | 4GB | xfs | yes |
|
||||
| boot | /boot | 1GB | ext4 | no |
|
||||
| swap | - | 4GB | swap | no |
|
||||
|
||||
|
||||
### Workstation Package Groups
|
||||
Changed the ammount of packages installed by default on workstation installation. See the comparison below:
|
||||
|
||||
| RHEL 7&8 | RHEL 9 |
|
||||
| --- | --- |
|
||||
| <ul><li>VMware platform specific packages (platform-vmware)</li><li> Container Management (container-management)</li><li> Internet Browser (internet-browser)</li><li> GNOME (gnome-desktop)</li><li> Headless Management (headless-management)</li><li> Server product core (server-product)</li><li> Hardware Monitoring Utilities (hardware-monitoring)</li><li> base-x (base-x)</li><li> core (core)</li><li> fonts (fonts)</li><li> guest-desktop-agents (guest-desktop-agents)</li><li> hardware-support (hardware-support)</li><li> input-methods (input-methods)</li><li> multimedia (multimedia)</li><li> networkmanager-submodules (networkmanager-submodules)</li><li> print-client (print-client)</li><li> standard (standard)</li></ul> | <ul><li>Internet Browser</li><li>VMware platform specific packages (platform-vmware)</li><li>GNOME (gnome-desktop)</li><li>Core (core)</li><li> fonts (fonts)</li><li> multimedia (multimedia)</li><li> office-suite (office-suite)</li><li> print-client (print-client)</li></ul> |
|
||||
|
||||
|
||||
### Tracking Epic
|
||||
https://jira.psi.ch/browse/PSILINUX-287
|
||||
|
||||
|
||||
## Caveats
|
||||
|
||||
### Missing or Replaced Packages
|
||||
|
||||
[List of packages removed in RHEL 9](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages)
|
||||
|
||||
| RHEL 8 | RHEL 9 | Remarks |
|
||||
| --- | --- | --- |
|
||||
| `mailx` | `s-nail` | S-nail is MIME capable and has extensions for line editing, S/MIME, SMTP, IMAP, POP3, and more. |
|
||||
| `platform-python, python2 (python27:2.7), python36 (python36:3.6), python38 (python38:3.8), python39 (python39:3.9)` | `python3` | As for all python* packages |
|
||||
| `pulseaudio` | `pipewire-pulseaudio` | The pulseaudio server implementation has been replaced by the pipewire-pulseaudio implementation. Note that only the server implementation has been switched. The pulseaudio client libraries are still in use. |
|
||||
| `inkscape1` | `inkscape` | Also affects `inkscape-docs` and `inkscape-view` |
|
||||
|
||||
|
||||
### Documenatation
|
||||
|
||||
* [Installation](installation)
|
||||
@@ -0,0 +1,22 @@
|
||||
# Installation
|
||||
|
||||
## Minimal HW/VM Requirements
|
||||
- 4GB RAM
|
||||
- 64GB Disk
|
||||
|
||||
## Network Installation
|
||||
|
||||
The machine you want to install needs to be [registered in `sysdb`](../admin-guide/deployment/sample). If you don't have the bob command installed locally you can login to __lxsup.psi.ch__ to use it. Remember that you need a valid Kerberos ticket before modifying a sysdb entry via `bob`.
|
||||
More details regaring `bob` can be found [here](https://git.psi.ch/linux-infra/bob).
|
||||
|
||||
Optional you can set `netboot` and RHEL 9 installer but that can also be selected manually in be boot menu:
|
||||
|
||||
```
|
||||
bob node netboot $FQDN
|
||||
bob node set-attr $FQDN ipxe_installer=rhel9install
|
||||
```
|
||||
### Installation with UEFI
|
||||
Start the machine and select network boot
|
||||
|
||||
### Installation with Legacy BIOS
|
||||
Not supported yet
|
||||
Reference in New Issue
Block a user