# Enterprise Support for AlmaLinux

This guide describes Enterprise Support for AlmaLinux and how to set it up on your AlmaLinux system.

# What is Enterprise Support for AlmaLinux?

Enterprise Support for AlmaLinux provides a TuxCare-vetted repository of AlmaLinux updates with 16 years of support coverage, ensures long-term stability and FIPS 140-3 compliance with extended security support for select AlmaLinux minor releases, and helps to avoid costly upfront support package fees with pay-as-you-go hourly support bundles.

Available services:

• Essential Support: TuxCare-vetted repository of AlmaLinux updates with guaranteed uptime, expedited break-and-fix support and up to 16 years of support coverage
• Extended Security Updates provide an extended period of security fixes for critical and high-risk vulnerabilities for select AlmaLinux minor versions, as well as the full suite of five FIPS-validated modules (kernel, openssl, libcrypt, nss and gnutls) and FIPS-compliant security patches for FIPS-certified AlmaLinux deployments. The product also unlocks commercial use of the FIPS-validated packages.
• Enhanced Support: Enterprise-grade support for AlmaLinux and open-source applications with pay-as-you-go pricing in 5, 10, and 20-hour bundles

Learn more at https://tuxcare.com/almalinux-enterprise-support/

# Extended Security Updates

Extended Security Updates (ESU) for AlmaLinux extend the lifecycle of specific AlmaLinux minor versions by delivering both prolonged security updates for High and Critical vulnerabilities as well as FIPS-compliant security patches enabling greater stability and security for AlmaLinux deployments.

# ESU lifecycle

AlmaLinux provides a 10-year lifecycle with a new minor release arriving every 6 months, bringing new features until the fifth year. Each of the minor releases is supported for 6 months. Customers who want to remain with the specific AlmaLinux minor release for longer can opt for Extended Security Updates (ESU).

ESU delivers an extended period of security fixes for critical and high-risk vulnerabilities for select AlmaLinux minor versions, as well as the full suite of five FIPS-validated modules (kernel, openssl, libcrypt, nss and gnutls) and FIPS-compliant security patches for FIPS-certified AlmaLinux deployments. The product also unlocks commercial use of the FIPS-validated packages.

Extended Security Updates are currently available for AlmaLinux 9.2 and have planned support for AlmaLinux 9.6 and 9.10. This provision ensures that a given minor release continues to receive essential updates, allowing customers to avoid upgrading every six months and test/certify their applications against the next minor version at their own pace.

# Vulnerability coverage

TuxCare employs the Common Vulnerability Scoring System (CVSS v3) to assess the severity of security vulnerabilities. Our severity rating system for patching vulnerabilities integrates both NVD scoring and vendor scoring (when available). When the vendor's score is lower than the NVD score, we give priority to the NVD score. ESU provides security patches for High and Critical vulnerabilities (with a 7+ CVSS score) and urgent priority bug fixes. This strategy aims to reduce changes in the environment, prioritizing stability without compromising critical security.

# FIPS-compliant security patches

ESU enables continuous security for FIPS-certified AlmaLinux 9.2 deployments by offering FIPS-compliant security patches for the FIPS-validated kernel, openssl, libcrypt, nss and gnutls packages. These patches do not change the validated cryptography. They are suitable for organizations that don't require strict FIPS-certified implementations that are static and never patched (i.e. military or intelligence agencies). In case of a cryptographic vulnerability that will require a security patch that changes the validated cryptography, we will fix it by delivering a new packaged module. This module will undergo an expedited FIPS 140-3 recertification to ensure it is attested to conform to FIPS 140-3 requirements.

# Target response times

Aligning with many industry standards and regulatory requirements, TuxCare is committed to delivering timely security updates. For instance, the Payment Card Industry Data Security Standard (PCI DSS) mandates that all 'High' vulnerabilities (CVSS score of 7.0+) must be addressed within 30 days. Other regulations and standards, such as the Health Insurance Portability and Accountability Act (HIPAA) for healthcare organizations or the Federal Information Security Management Act (FISMA) for government agencies, uphold similar requirements. We aim to deliver security patches for Critical and High-risk vulnerabilities (CVSS 7+) within 14 days from when the vulnerabilities become publicly disclosed. This rapid response time significantly reduces the window of opportunity for potential attackers and meets most security regulation requirements.

# Supported packages

ESU provides updates for a comprehensive list of packages integral to server operations (100+ packages), providing maximum security for your operating system. You can view the full list of supported packages, as well as get detailed information on the patched CVEs, here https://cve.tuxcare.com/. Support for additional packages can be provided on request.

# Errata advisories

ESU provides qualified security and selected bug-fix errata advisories across all architectures. They can help users track which Common Vulnerabilities and Exposures (CVE) are resolved and which bugs have been addressed. You can view the full list of released advisories here https://cve.tuxcare.com/els/releases.

# OVAL patch definitions

Leveraging Open Vulnerability and Assessment Language (OVAL) patch definitions with OVAL-compatible tools, e.g. OpenSCAP, users can accurately check their systems for the presence of vulnerabilities:

• AlmaLinux 9.2 FIPS: https://repo.tuxcare.com/tuxcare/9.2/almalinux9.2-fips-oval.xml
• AlmaLinux 9.2 ESU: https://repo.tuxcare.com/tuxcare/9.2/almalinux9.2-esu-oval.xml

# RSS releases feeds

• AlmaLinux 9.2 FIPS: https://cve.tuxcare.com/rss_feed/releases/almalinux9.2fips
• AlmaLinux 9.2 ESU: https://cve.tuxcare.com/rss_feed/releases/almalinux9.2esu

# Technical support

All TuxCare products include technical support provided according to the support policy https://tuxcare.com/TuxCare-support-policy.pdf. It delivers 24/7/365 access to our engineers through the TuxCare Support Portal https://tuxcare.com/support-portal/ and to our online knowledge base. Technical Support for Extended Security Updates provides assistance with:

• ESU repository setup issues
• Package update problems (package conflicts, missing dependencies)
• FIPS and CVE-related questions
• ePortal issues
• AlmaLinux kernel crash issues (root cause analysis)

# GnuPG Keys

The TuxCare ESU/FIPS packages and repositories are cryptographically signed with a GPG key, so you can verify the legitimacy of the software you download and the source of the download. The details of our key are below:

• Public key: rsa4096/8D50EB66 (2023-03-06)
  • Fingerprint: FAD7 8590 81D0 738B 7A82 8496 D07B F2A0 8D50 EB66
  • ID: TuxCare (Software Signing Key) packager@tuxcare.com
  • Installation location: /etc/pki/rpm-gpg/RPM-GPG-KEY-TuxCare
  • Download link: RPM-GPG-KEY-TuxCare

# Installing tuxctl

Requirements

• AlmaLinux 9.2 operating system
• x86_64 or aarch64 architecture
• Extended Security Updates license key (should be obtained from portal.tuxcare.com)
• Internet access

tuxctl is the setup tool for TuxCare's Enterprise Support for AlmaLinux, which will configure your system to receive patches from the TuxCare repositories. To install tuxctl you need to install the tuxcare-release package first. This package contains the TuxCare repo definitions, TuxCare GPG key and the tuxctl setup tool. Run the following as root:

# dnf -y install https://repo.tuxcare.com/tuxcare/tuxcare-release-latest-9.2.$(uname -i).rpm

The second step is to activate your license on the system. You should run the tuxctl tool as root with your ESU license key provided as a command line argument like so:

# tuxctl --license-key ESU-XXXXXXXXXXXXXXXXXXXXXXXX

This tool will do the following:

1. Check your OS and architecture
2. Check your license key for validity and purchased extensions
3. Check if your system is already registered
4. Register to CloudLinux Network
5. Obtain a token to access the restricted TuxCare repos
6. Enable the TuxCare ESU repo
7. Switch the default AlmaLinux repos to use repo.tuxcare.com
8. Import the TuxCare GPG key

After installation you'll see the following message:

TuxCare installed successfully

This means your system is registered and ready to receive updates from TuxCare.

This server already has a TuxCare token installed
To force re-registration, please run the script with --force

# tuxctl --force -l ESU-XXXXXXXXXXXXXXXXXXXXXXXX

# SaaS usage

If you are using ESU with our SaaS license in AWS, then the instructions are slightly different. You should login to your instance and run the following as root (use of --fips is optional depending on your needs):

# dnf -y install https://repo.tuxcare.com/tuxcare/tuxcare-release-latest-9.2.$(uname -i).rpm

# tuxctl --saas --fips

If you want to reclaim a license when you terminate an instance, you should first run:

# tuxctl --delete

De-registration successful

Then you can use that license to register another instance.

If you want to check if you've already registered an instance, you can run the following to display your token:

# tuxctl --validate

Server is registered with token EXTENDED_SECURITY_UPDATES-SERVER-xxxxx

If the instance has no license installed, it will return:

Server is not registered

# Enabling FIPS 140-3 mode

First please ensure you have installed the tuxcare-release package as described above. If you haven't already registered your ESU license using tuxctl the next step will also do that for you.

To enable the FIPS repo, install the FIPS 140-3 validated packages, enable FIPS mode and configure grub to boot into the FIPS-validated kernel, please run these commands as root, substituting in your license key:

# tuxctl --fips -l ESU-XXXXXXXXXXXXXXXXXXXXXXXX
# dnf -y install openssl-3.0.7-20.el9_2.tuxcare.1 kernel-5.14.0-284.11.1.el9_2.tuxcare.6
# dnf -y install gnutls-3.7.6-23.el9_2.tuxcare.3 nettle-3.8-3.el9_2.tuxcare.1 libgcrypt-1.10.0-10.el9_2.tuxcare.3 nss-3.90.0-6.el9_2.tuxcare.1
# grubby --set-default=/boot/vmlinuz-5.14.0-284.11.1.el9_2.tuxcare.6.$(uname -i)
# fips-mode-setup --enable
# reboot

Once you've logged in after the reboot, run these commands and check the output matches to confirm it worked:

$ fips-mode-setup --check
FIPS mode is enabled.

$ uname -r
5.14.0-284.11.1.el9_2.tuxcare.6.x86_64

$ openssl list -providers | grep -A3 fips
  fips
    name: OpenSSL FIPS Provider for AlmaLinux 9
    version: 3.0.7-1d2bd88ee26b3c90
    status: active

# Uninstalling tuxctl

To uninstall tuxctl, disable the ESU/FIPS functionality and revert to AlmaLinux community repo's, you can run the following as root:

# dnf -y remove almacare-release tuxcare-release

# fips-mode-setup --disable

# sed -i \
  -e 's|https://repo.tuxcare.com/almalinux/|https://repo.almalinux.org/almalinux/|' \
  -e 's|^# mirrorlist|mirrorlist|' \
  -e 's|^baseurl|# baseurl|' \
  -e 's|$tuxcare_releasever/$tuxcare_token|$releasever|g' \
  -e 's|almacare|tuxcare|g' \
  -e 's|$tuxcare_releasever|$releasever|g' \
  -e '/^exclude/d' \
  /etc/yum.repos.d/almalinux*.repo

# reboot

To completely remove the TuxCare packages, after following the above steps, run the following as root:

# dnf remove *tuxcare*

In most cases this will be the end of the uninstallation procedure, however if you see an error message like the following, then you may have to use grubby or grub2-reboot or simply the grub menu, to reboot into a non-TuxCare kernel first:

Error:
 Problem: The operation would result in removing the following protected packages: sudo, systemd, kernel-core, dnf
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Then run the following:

# dnf downgrade openssl libgcrypt gnutls nettle nss
# dnf remove kernel*tuxcare*
# dnf upgrade

# Essential and Enhanced Support

# 1. Introduction

In April 2023, TuxCare, a division of CloudLinux Inc., launched Enterprise Support for AlmaLinux, delivering a range of services for AlmaLinux workloads. It provides two levels of support, the essential level, focused on the operating system, and the enhanced support focused on applications. This document defines those services.

Overview of Services

There are two levels of support services for AlmaLinux:

Essential Support - a limited technical support offering that covers AlmaLinux installation/update issues (packaging, dependencies, repositories), migration issues (from CentOS/OracleLinux/RHEL to AlmaLinux), operating systems bugs/kernel crashes, a self-service portal, as well as an online knowledge base

Enhanced Support - an enterprise technical support service covering a range of open-source software running on AlmaLinux, a self-service portal, as well as an online knowledge base.

# 2. Definitions

"Customer," "End User," "User," "You/Your" shall mean an organization which has a valid license to the Product that is supported in accordance with this Program.

"Customer Technical Lead" shall mean an employee or authorized contractor of Customer who shall complete required AlmaLinux product training, in order to serve as Customer's first line of internal support for the purpose of triaging AlmaLinux-related product issues, and who shall have authority to submit Technical Support Incidents and Service Requests to TuxCare Technical Support

"Incident" shall mean any event reported by the Customer, which is not part of the standard operation of a Product, and which causes, or may cause an interruption to, or a reduction in, the quality of service provided by the Product.

"Incident Severity/Urgency" shall mean a measure of the business criticality of an incident or problem based on the business needs of the Customer. See Appendix 1 for more details.

"Known Error" shall mean a Problem that becomes a Known Error when the root cause is known, and a temporary workaround or permanent alternative has been identified.

"Problem" shall mean an unknown underlying cause of one or more Incidents. It becomes a Known Error when the root cause is known, and a temporary workaround or permanent alternative has been identified.

"Product(s)" shall mean software product(s) of TuxCare, which the Customer has purchased, deployed, and installed in accordance with the terms of a License Agreement between TuxCare and the Customer.

"Product Error" shall mean undeclared behaviour of the Product.

"Response time" shall mean the elapsed time measured from the moment of any incident receipt until confirmation of receipt by TuxCare to the initiator (via the support system).

"Service Request" shall mean a request from a Customer for support, delivery, information, advice, or documentation, which is not related to an incorrect functioning or non-functioning of the Product(s).

"Upgrade" shall mean a Product update associated with assigning a new version number.

"Workaround" shall mean a procedure that may serve as a temporary solution to an incident.

# 3. Service Features

# 4. Description of Support Program

# Accessing Technical Support

TuxCare Technical Support is designed for enterprise clients with trained IT staff which provide initial ‘1st-line' support to triage incidents. Customer and TuxCare will agree on Customer Technical Leads with the client, who will be entitled to access TuxCare Technical Support services; Customer Technical Leads must complete AlmaLinux training requirements. Customer Technical Leads may submit Technical Support Incidents and Service Requests to:

1. Technical Support ticketing system: https://tuxcare.com/support-portal/

• Acceptance of requests 24 hours a day, 365 days a year
• Unlimited number of tickets may be submitted
• Customers will be supplied with instructions describing the use of the ticketing system during onboarding
• User accounts will be created for each nominated user within each client organization
• User accounts will have access to log, view and respond to tickets

2. Email: acceptance of requests 24 hours a day, 365 days a year:

• New tickets may be created by simply emailing the support desk: support@tuxcare.com

$ aws sts get-caller-identity --query Account --output text

123456789012

$ curl -s http://169.254.169.254/latest/dynamic/instance-identity/document | grep accountId

  "accountId" : "123456789012",

All customers are entitled to access the Support knowledgebase, FAQs, and other self-service tools as may be offered by Enterprise Support for AlmaLinux.

# Response Time

When submitting a ticket, Customers will select the appropriate Severity Level, as defined in Appendix A, from a drop-down list; TuxCare reserves the right to change the Severity Level based on available information. TuxCare will use reasonable efforts to respond to support requests within the initial response times described below, based on the Severity Level of the incident.

# Incident Resolution Cooperation

Some incidents may require reproduction by TuxCare for the purpose of testing and verifying a product error. Customer agrees to provide TuxCare with all information which may be necessary for reproducing the condition under which the incident will re-occur and could be examined.

TuxCare will endeavor to reproduce the incident as soon as all the necessary information and software and/or hardware is provided. If the incident could not be reproduced, Customer should grant TuxCare a supervised remote access to the malfunctioning system. If the incident cannot be reproduced by either party, or Customer did not grant access to the network environment where the incident could be reproduced, or if it is detected that the incident's cause lies beyond the Product, the incident cannot be classified within this Support Program.

An incident may at any time be either on the Customer's side (i.e. Customer is taking actions that will promote/expedite the resolution of the issue by TuxCare) or on the AlmaLinux side. An incident is on the Customer's side when TuxCare engineers request information from the Customer. When Customer provides the requested information to TuxCare, the incident is considered to be on the side of the latter. The period during which the incident may be on the Customer's side is limited to one calendar week. If the Customer's response is overdue, the incident is closed by timeout.

# Appendices

# Appendix A. Incident Severity Levels

# Appendix B: Quality management

Incident escalation

Customer may escalate unresolved incidents or reports of dissatisfaction according to the following scheme:

Provision of reports on open incidents

During the process of incident resolution, TuxCare will use reasonable effort to promptly provide the Customer with information regarding open incidents' status, according to the following table.

Limitations of the Support Services

Technical support covered by any of the TuxCare Support Programs shall not be provided in the following cases:

• Incidents already resolved for the Customer (e.g., an incident that occurred on one installed copy of the Product after the same incident had been resolved for another copy of the Product)
• Troubleshooting of all issues similar or identical to already resolved issues (i.e. the incidents to which a previously produced solution can be applied without additional guidance from TuxCare)
• Incidents caused by Customer's hardware malfunction
• Incidents caused by software platform incompatibility (including, but not limited to beta software, new versions of service packs or additions, whose compatibility with the Product has not been confirmed by AlmaLinux)
• Incidents caused by installing and running third-party applications (including, but not limited to the list of unsupported or incompatible applications published in the documentation)
• Incidents for which the Customer cannot provide accurate information, as reasonably requested by TuxCare, in order to reproduce, investigate, and resolve the incident
• Incidents which arise as a result of neglect or incorrect use of TuxCare instructions, which, if properly used, would have prevented the Incident

# Installing tuxctl (Essential Support)

Similarly to the ESU instructions above, Essential Support customers should install tuxcare-release and register their server using tuxctl. The main difference is the choice of OS version - you must install the RPM specifically for your AlmaLinux version, currently 8.8, 8.10, 9.2 and 9.4 are supported.

If you are unsure, run this to find your exact OS version:

$ cat /etc/almalinux-release

AlmaLinux release 8.10 (Cerulean Leopard)

You can browse https://repo.tuxcare.com/tuxcare/ and find the correct RPM, or you can figure it out by substituting the version number (8.8, 8.10, 9.2 or 9.4) then install it as root, for example:

# dnf -y install https://repo.tuxcare.com/tuxcare/tuxcare-release-latest-8.10.$(uname -i).rpm

The second step is to activate your license on the system. You should run the tuxctl tool as root with your Essential Support license key provided as a command line argument like so:

# tuxctl --license-key ESA-XXXXXXXXXXXXXXXXXXXXXXXX

Essential Support customers can upgrade to a new minor version, for example from 9.2 to 9.4 by editing the /etc/dnf/vars/tuxcare_releasever file to specify the new version, like so:

# echo 9.4 > /etc/dnf/vars/tuxcare_releasever
# dnf upgrade