| Table of Contents |
|---|
The Service Provider is written in fairly portable C++ with dependencies on a mixture of C and C++ libraries, and is in principle buildable on most Operating Systems, but we provide official support for only the platforms below at this time, which also correspond to the exact platforms for which we produce some form of official packaging.
...
Building from source is possible (and somewhat easier than in the past) but this is still byeond beyond the capabilities of most and not encouraged unless you have a need to produce extensions to the software (or need the FastCGI modules, see below).
...
We officially support the following Linux distributions (x86_64 only):
Red Hat Enterprise
and CentOS 6, 7, 8SUSE Linux Enterprise Server 12SP4,12SP57/8/9
CentOS 7
Rocky Linux 8/9
Amazon Linux 2
Amazon Linux 2023
The same platforms do have unofficial aarch64 packages for ARM distributions available. These packages are not officially supported but are believed to be suitable for testing.
The reason for this policysmall set of options, aside from limiting our scope, has to do with packaging: is that these are the versions we explicitly provide packages for (in the form of RPMs built by the OpenSUSE build service under the oversight of the project team) , and are therefore the versions for which we can provide security updates.
We may produce packages for older or other unsupported platforms at the discretion of the project team, but do so solely as a service to the community and do not officially support versions other than those above.
Note that support for OpenSUSE itself has essentially ended because a third party has produced packages for the SP that are included with that OS, so our support is limited to the older official versions for which we provided packages.
We are discussing with the Consortium's members how best to tackle some form of support for other distributions such as Debian that would delineate our role vs. the role of the packaging teams. We also partially support the following Linux distributions through our support options for Consortium members:
Debian
SUSE Linux Enterprise Server and OpenSUSE
In practice, we do not simply ignore bug reports or questions about these, and other, distributions since the majority are of general applicability, but there are cases where more esoteric bugs are in fact limited to a platform and that is something we take into consideration. We offer members a higher degree of tolerance for questions and issues requiring deeper investigation on these partially-supported platforms.
It is generally possible to build the software and all dependencies on most Unix, Linux, and BSD versions (with problems likely cropping up on non-x86/64 architectures or the more unusual stuff like AIX that tends to have poor open source support generally).
Note that Solaris is no longer officially supported as of V3, which is a change from V2. We don't deliberately seek to break the build there, but in practice most of our releases will tend to need minor patches to deal with fairly obscure C++ compiler differences, so a clean build is unlikely. The extra work necessary to keep the build working there is one of the reasons we have dropped it.
Web Servers
Officially we support the use of Apache 2.2 and 2.4 and FastCGI. Functionally, the source continues to include older Apache module support.
...
We provide the FastCGI modules when the requisite libraries are available on the OS.
Mac OS
...
macOS
Support for macOS is now unofficial due to the effort required and the lack of interest. There is a macport for all the dependencies and the SP itself and we will help to maintain this on a voluntary basis for now and it is not officially supported.
Web Servers
As of this version, we now provide port variants that allow the SP to be built against either Apache as provided by Apple, which has been deprecated, or from the MacPorts version. For compatibility, the default port variant continues to assume Apple'sThe unofficial port is designed to be used with the Apache provided by macports.
We do not recommend the use of the old prefork MPM and strongly encourage the worker MPM. The prefork option will fail under load in a variety of cases, with some limited workarounds possible.