Versions Compared

Old Version 30

changes.mady.by.user Scott Cantor

Saved on

compared with

New Version Current

changes.mady.by.user Scott Cantor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Shibboleth can be built on most versions of 32- and 64-bit Linux, but is officially supported only on the following distributions at this time, using the RPM packages available from the project's official mirrors:

  • Red Hat Enterprise 7/ 8/9

  • CentOS 7

  • Rocky Linux 8/9

  • Amazon Linux 2

  • Amazon Linux 2023

Packages for CentOS 7 are still being produced but that platform is no longer supported officially as it has reached the end of Red Hat’s public support.

Packages for CentOS 8 are still being produced but the platform is no longer supported officially due to it having transitioned to an unstable floating package set, and the packages may stop working at any time.

See the SystemRequirements page for more detail on this.

The official packages are built for, and integrate with, only the Apache (httpd) package that is supplied with the OS. When building from source or SRPM, you can accomodate any version of Apache (or its derivations) that is compatible.

Note

RHEL 6/7. CentOS 6/7

Information about Red Hat Enterprise 6/7 and CentOS 6/7

Warning

SELinux

Information about SELinux

If your distribution supports the RPM package manager, it is strongly suggested that you install using RPMs built for your specific distribution, or by rebuilding the SRPM source packages provided. If this is not possible, you can build from source.

...

Note

Upgrading the OS

Recent Linux versions occasionally provide an in-place upgrade path. Whether this works or not, it will not upgrade your Shibboleth packages nor will it properly adjust the yum/dnf repository file, resulting in failure. If you wish to do this, uninstall the SP first and then reinstall it with the proper repository file afterward.

SP Upgrades

Upgrading to new SP releases is handled automatically when RPMs are used, or in the case of a source build when "make install" is run using the same installation prefix. The system prevents configuration files from being overwritten and skips "initial install" tasks like generating keys. In the case of RPM upgrades, services should be appropriately restarted, but with source builds that step has to be done manually.

...