Using Fedora 37+ at CERN

This post is an update to my previous post for Fedora 24.

Much has changed in the past years for Linux at CERN, most notably the surprise end of support for Centos8. In the wake of this news, and unhappy with the new re-shuffling of CentOS in the RHEL development pipeline, several open-source “clones” were created to take the place of the now-EOL CentOS8. CERN, together with FermiLab, chose Alma linux, which is now available and officially supported.

Now that the dust has settled we have much more modern options available (although many experiments are continuing with Centos7 for some time). The current survey of officially supported releases include:

  • Alma/RHEL 9 (5.15 LTS, Python 3.9 LTS)
  • Centos Stream 9 (5.15 LTS, Python3.9 incremental)

For those people who need even newer, the process for using Fedora has gotten even simpler. The default behavior of CERN workstations (as of rhel/cs/alma 9) is to no longer to set the user $HOME directory to their AFS path, but rather a local /home/$USER path. This avoids some of the headaches caused by sssd-krb5, and means that all users need to do to have a “CERN workstation” experience with Fedora (or Ubuntu, Arch, etc. ) is setup krb5 and AFS.

Setting up Fedora 37+ for use at CERN

Starting from a fresh install, we need the dependencies for AFS and kerberos:

$ dnf install -y krb5-workstation sssd-krb5
$ curl -LO /etc/krb5.conf https://linux.web.cern.ch/docs/krb5.conf

You should now be able to get kerberos tokens with $ kinit username@CERN.CH. Don’t forget to enable using your tokens with SSH:

$ cat <<EOF >> ~/.ssh/config
GSSAPITrustDns yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
EOF 

Now for AFS. There’s been various efforts to make Fedora rpms available via copr or even yum repos directly from openAFS team over the years, but it seems these are inevitably unmaintained. AFS requires kernel modules, so the only sure-fire way is to pull the latest source rpm from OpenAFS and build it yourself:

$ dnf install -y rpm-build krb5-devel ncurses-devel pam-devel swig perl-ExtUtils-Embed
$ curl -LO https://openafs.org/dl/openafs/1.8.9/openafs-1.8.9-1.src.rpm

$ rpmbuild --rebuild --define "build_userspace 1" --define "build_modules 0" openafs-1.8.9-1.src.rpm

$ cd ~/rpmbuild/RPMS/x86_64
$ dnf install -y openafs-client-1.8.9-1.fc37.x86_64.rpm openafs-krb5-1.8.9-1.fc37.x86_64.rpm dkms-openafs-1.8.9-1.fc37.x86_64.rpm openafs-1.8.9-1.fc37.x86_64.rpm
$ echo "cern.ch" > /usr/vice/etc/ThisCell
$ systemctl enable --now openafs-client

Here, we install the minimal AFS client: openafs, openafs-client, openafs-krb5, and dkms-openafs. If you really want the static kmod-openafs, you can set define "build_modules 1" but this is often failing for bleeding-edge kernels. Finally, try it out:

$ kinit userid@CERN.CH
$ aklog
$ klist
Valid starting       Expires              Service principal
02/10/2023 11:25:29  02/11/2023 10:45:25  krbtgt/CERN.CH@CERN.CH
02/10/2023 16:17:35  02/11/2023 10:45:25  afs/cern.ch@CERN.CH

See https://linux.web.cern.ch/docs/kerberos-access for full notes

Addendum: Using CERN repo packages to automate the above

Many of the CERN-maintained packages meant for supporting RHEL/Alma can be used for Fedora as well.

$ cat <<EOF > /etc/yum.repos.d/CERN.repo
[CERN]
name=CentOS-9 Stream - CERN [HEAD]
baseurl=http://linuxsoft.cern.ch/cern/centos/s9/CERN/x86_64
enabled=0
gpgcheck=0
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-kojiv2

[CERN-testing]
name=CentOS-9 Stream - CERN - testing [HEAD]
baseurl=http://linuxsoft.cern.ch/cern/centos/s9-testing/CERN/x86_64
enabled=1
gpgcheck=0
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-kojiv2

[CERN-source]
name=CentOS-9 Stream - CERN - source [HEAD]
baseurl=http://linuxsoft.cern.ch/cern/centos/s9-testing/CERN/Source
enabled=1
gpgcheck=0
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-kojiv2
EOF

As an example, a commonly used helper package is locmap. It’s not directly install-able, due to the rpm being hard-linked to Alma9’s system python 3.9. You’ve already seen how to rebuild a source rpm against your newer kernel, so how about newer python?

$ repoquery --requires locmap
/usr/bin/python3
bind-utils
iproute
krb5-workstation
locmap-plugin-puppet-facts
locmap-plugin-xldap
locmap-release
puppet-afs
puppet-agent >= 1.9
puppet-alternatives
puppet-augeasproviders_core
puppet-augeasproviders_pam
puppet-cernbox
puppet-cernphone
puppet-chrony
puppet-concat
puppet-cvmfs
puppet-eosclient
puppet-firewalld
puppet-inifile
puppet-kerberos
puppet-keytab
puppet-lpadmin
puppet-mailalias_core
puppet-nscd
puppet-postfix
puppet-ssh
puppet-stdlib
puppet-sudo
puppet-systemd
puppet-zoom
python(abi) = 3.9
python3-PyYAML
python3-ldap
python3-netaddr
python3-setuptools
python3.9dist(setuptools)
useraddcern

There’s a couple of options here:

  1. We could install this rpm while ignoring all of it’s dependencies, then manually install them ourselves as needed (tedious)
  2. Update the python3 version requested by the rpm (slightly less tedious)

The relevant fix looks like this:

$ dnf download locmap
$ rpmrebuild -enp locmap-*.rpm

This will open your editor to the rpm .spec file. The relevant lines causing our particular headache are:

Requires:      python(abi) = 3.9
Requires:      python3.9dist(setuptools)

Comment these lines out (or possibly update them and the install paths to your system python version (3.11 for fc37.) The resulting rpm is ready for install in ~/rpmbuild/RPMS/noarch/locmap-*noarch.rpm. If you looked further in the spec file, you’ll see that locmap is essentially a python module like you might install from Pypi, which installs python3.9 site-package files. So don’t forget to install python3.9 for use, along with the modules requested by the rpm:

$ dnf install -y python3.9
$ alternatives --install /usr/bin/python3 python3 /usr/bin/python3.9 1
$ python3 -m ensurepip
$ python3 -m pip install pyyaml netaddr pyyaml setuptools

Rinse and repeat for any dependencies. As you can see, it can turn into a headache, so best avoided if possible.

Printing at CERN

Using an operating system other than those officially supported, printers can be added via CUPS.

Example from Fedora 34:

Find your printer from cern’s printservice webpage. Copy the printer ppd from lxplus and install deps:

sudo dnf install -y cups-lpd system-config-printer
scp lxplus:/etc/cups/ppd/your-printer-name.ppd ~

From here, run system-config-printer and configure a new LPD/LPR printer.

Host: <your-printer-name>.print.cern.ch

Queue: <your-print-name>

then simply accept the rest of the default settings & test print!

Enabling h264 and others on Windows N insider

Windows 10 N is essentially the same version as the non-N version, with specific licensed codecs and other materials excluded. You can install these normally via the Microsoft Windows Media Feature Packs.

I made the unfortunate mistake of selecting Windows 10 Pro N for a computer, and being stubborn and not wanting to change the license, I have been continuously running into problems created when you update early with Windows Insider program.

So far, Microsoft does not rebuild the media feature packs for insider builds. Microsoft has not released a script to let you do this yourself (ala source rebuild for those familiar with Linux).

If you want to use Netflix, youtube, or any other modern web content that requires these media codecs, you were SOL on Windows 10 N and insider builds.

Until I stumbled across these instructions:

  1. Download the latest Windows Media Feature Pack & extract the contents:
    • expand -f:* Windows-media-packxx.msu . ; expand -f:* Microsoft-media-featurexx.cab .
  2. Copy the following files into Windows/System32:
  • mfperfhelper.dll
  • msmpeg2vdec.dll
  • mf.dll
  • mfplat.dll
  • evr.dll
  1. Install the following registry keys: (copy/paste to .reg file and import by double-clicking the file)
  2. Windows Registry Editor Version 5.00
    
    [HKEY_CLASSES_ROOT\CLSID\{62CE7E72-4C71-4D20-B15D-452831A87D9D}]
    @="Microsoft H264 Video Decoder MFT"
    
    [HKEY_CLASSES_ROOT\CLSID\{62CE7E72-4C71-4D20-B15D-452831A87D9D}\InprocServer32]
    @="C:\\Windows\\System32\\msmpeg2vdec.dll"
    "ThreadingModel"="Both"
    
    [HKEY_CLASSES_ROOT\CLSID\{e79167d7-1b85-4d78-b603-798e0e1a4c67}]
    @="MF Media Source Activate"
    
    [HKEY_CLASSES_ROOT\CLSID\{e79167d7-1b85-4d78-b603-798e0e1a4c67}\InProcServer32]
    @="C:\\Windows\\System32\\mfcore.dll"
    "ThreadingModel"="Both"
    

Using Fedora 24+ at CERN

This post has been updated – please see Fedora 37+ here

Updated Spring 2018

It seems RHEL8/CC7 will likely be branched from Fedora27 development, so hopefully these things will hold for future. Tracking down the sssd bug for Fedora 26+ was a pain!

CERN has decided that future linux releases will be a stock version of centos + cern repository. This makes things quite simple for anyone who might want to use fedora, as we are very close to stock system.

add CERN repo
cat>/etc/yum.repo.d/cern.repo << EOF [cern] name=cern baseurl=http://linuxsoft.cern.ch/cern/centos/7/cern/x86_64 enabled=1 gpgcheck=0 EOF
Install kerberos and afs
Install gotcha dependencies

ocsinventory-agent -this package is not any longer from default Fedora repos. Get it here.

# for Fedora 27. See above link for other versions of Fedora
dnf install https://rpm.ocsinventory-ng.org/ocsinventory-release-latest.fc27.ocs.noarch.rpm
Install packages from cern repo
  • dnf may complain about per(Module::Install) or other perl libraries missing – these are simply called perl-Module-Install in fedora repos. rpmfind.net is your friend here.
sudo dnf install CERN-CA-certs cern-get-keytab cern-get-sso-cookie cern-wrappers locmap useraddcern

Now we install everything with dnf. Finally, you can simply follow the cern cc7 instructions and add your cern account native with addusercern afsid

One final note: If you have Fedora 26+, there is a bug from sssd. You need to add the following line to your /etc/sssd/sssd.conf under [sssd]:

[sssd]
enable_files_domain=false

You can read more about this particular “feature” here

Building KDE (Plasma) 5 on RHEL / CentOS 7

With a fresh install of CentOS 7 I’m going to try and install KDE (Plasma) 5.

For fun, I’ll try and make it available to all users from the /opt/ directory.

According to KDE Developers the reason why Plasma is not available from repositories is due to missing support for cmake 2.8.12+.

UPDATED – CMAKE 3.5+ is now available in the epel-testing repo! QT5.6 is now available as well!

SO! Step1: Install dependencies:

yum-config-manager --enable epel-testing
yum install cmake3*, qt5-* 
ln -s /usr/bin/cmake3 /usr/bin/cmake

*cmake for centos7 does not install as `cmake’ but cmake3. I do not know why.

Test with “qtdiag” (should return 5.5.1) and “cmake3 -version”(should return 3.5.0)

Cool.

To build latest* we need wayland. New(er) Wayland. Without building yourself from source, you can get it from jmliger’s copr. Once you have that saved in /etc/yum.repos.d/ you can simply

yum install wayland*

 

Step 2: Build KDE*

I chose to use the KDE src-build script to make life easier.

Note: my kdesrc-builrc file was in /opt/kde/sources/kdesrc-build/ and the contents are as follows:

global

    source-dir  /opt/kde/sources
    build-dir  /opt/kde/build
    kdedir  /opt/kde/install
    log-dir  /opt/kde/logs

    git-repository-base     kde-projects kde:
    cmake-options -DCMAKE_BUILD_TYPE:STRING=debug

    cxxflags -pipe -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat -Werror=format-security -Werror=return-type -Wno-variadic-macros -Wlogical-op -Wmissing-include-dirs -std=c++11

    make-options -j4

    ignore-kde-structure    true       
    stop-on-failure         true       

end global

include /opt/kde/sources/kdesrc-build/kf5-frameworks-build-include
include /opt/kde/sources/kdesrc-build/kf5-workspace-build-include

In addition to the above official instructions, I needed bzr, and some other additional *-devel libraries (build with –debug flag to see what you’re missing)

Working KDE/Plasma 5.21 on Centos 7.2