Subscribe to GEN
Login to GEN
When we chose an enterprise Linux for our own servers, we chose AlmaLinux: a solid, dependable distribution, governed by a non-profit foundation rather than a single vendor, with a project that responds quickly when something needs fixing. We support it for customers on exactly the same basis, so the engineer who takes your call runs the same distribution, on the same kind of hardware, every day.
Service levels run from a next business day response to 30 minutes, 24 hours a day, every day of the year. There is no contract, no minimum term and no notice period: you buy hours at our published rates and draw against them.
An enterprise distribution has one job: to stay put. Servers built on it should run for years, take their security updates without drama, and reach the end of a long lifecycle on a date everybody knew about when they were installed. AlmaLinux does that. It tracks Red Hat Enterprise Linux closely, it is free to use in production, and nobody has to buy a subscription to receive the updates that keep a server secure.
The way it is run matters as much as the code. AlmaLinux is governed by the AlmaLinux OS Foundation, a non-profit with a community board, so its direction is not decided by one company's commercial priorities. In our experience the project is engaged and quick to respond, which is exactly what you want behind a platform you intend to keep for a decade.
AlmaLinux is open source. Whether you support the Foundation is entirely your decision, and not one we will make for you. If you do choose to, do it directly with the Foundation, so the money reaches the project rather than enriching a reseller.
AlmaLinux faults are rarely vague. The system usually says exactly what is wrong, in a form nobody on site can act on. These are the cases that arrive most often.
A dracut emergency shell after a kernel update, missing or broken boot loader entries, an initramfs without the driver the storage needs, or a full /boot. We get the system up from the console, then find out what put it there.
Denials that stop an application, contexts lost after files were moved, and filesystems that need relabelling. We fix the policy, with booleans, contexts or a targeted module, rather than switching SELinux off and leaving the server weaker than it was.
Failed or half-completed transactions, module stream conflicts, EPEL and third party repositories that no longer agree with the base system, and version locks that quietly stopped a server receiving security updates.
NetworkManager and nmcli configuration, bonding, VLANs and bridges, firewalld zones and rich rules, and the connectivity that disappeared after an upgrade converted the old network scripts.
XFS repair, LVM volume groups reporting a missing physical volume, mdraid arrays that will not assemble, and filesystems that filled up and took the services with them. We work on images rather than originals wherever the equipment allows.
Unexplained outbound traffic, cron jobs and systemd timers nobody wrote, or altered SSH keys. Do not reboot, reinstall or delete anything: all three destroy the evidence of how they got in. Raise it on the HelpDesk and leave it running.
The applications on top, from Apache, nginx and PHP-FPM to MariaDB, PostgreSQL and containers, are covered on our Linux support page. We support the operating system and the stack as one system, because that is how the fault behaves.
From CentOS 7. A great many CentOS 7 servers are still in production after its end of life, doing important work and receiving no security updates. We move them to AlmaLinux 8 in place with the ELevate project and Leapp, and on to AlmaLinux 9 where that is the right target, without rebuilding the server or reinstalling its applications. Where an in-place upgrade is the wrong answer, because the server is simply too far gone, we will say so and rebuild it properly instead.
From Rocky Linux, Oracle Linux, RHEL or CentOS 8. These convert to AlmaLinux of the same major version in place, using the AlmaLinux migration tooling, usually with a single reboot.
Between AlmaLinux releases. Major version upgrades from 8 to 9 and from 9 to 10, planned against the software you actually run, rather than attempted on a Friday afternoon.
Older unsupported systems are covered on our legacy system support page.
Most AlmaLinux servers we are called to after an incident were not unlucky. They were behind on updates, exposed more than they needed to, and nobody was watching them. The ongoing work that prevents that is not glamorous, and it is where most of the value is.
Security updates applied in agreed windows and verified afterwards, with new CVEs against the software you run raised the same day. Delivered as part of a maintenance plan, driven by our asset register.
CIS benchmark alignment, SELinux kept in enforcing mode, SSH and sudo policy, firewalld configured to what the server actually needs, and the unused services removed.
Servers watched by Oversight, and backups verified by restoring them rather than by trusting the job report.
Yes. GEN provide 24/7 enterprise support for AlmaLinux across the UK, with service levels from a next business day response to 30 minutes, 24 hours a day, every day of the year. GEN run AlmaLinux on their own servers, and support is delivered by in-house UK engineers with no outsourced first line and no contract.
Yes. GEN migrate CentOS 7 servers to AlmaLinux 8 in place using the ELevate project and Leapp, then on to AlmaLinux 9 where required. Every migration starts with a pre-upgrade assessment, and the system is imaged or snapshotted before anything changes, so there is always a way back.
Yes. Systems running Rocky Linux, Oracle Linux, RHEL or CentOS 8 can be converted to AlmaLinux of the same major version in place, using the AlmaLinux migration tooling, without rebuilding the server or reinstalling its applications.
AlmaLinux aims for application binary compatibility with RHEL, so software built and certified for RHEL generally runs on AlmaLinux unchanged. Where a vendor insists on RHEL itself for certification, GEN will say so before a migration rather than after it.
AlmaLinux 8, 9 and 10, and earlier releases that have reached end of life. GEN also support the RHEL family around it, including CentOS, Rocky Linux and RHEL, and the migrations between them.
No. AlmaLinux is free and open source, and GEN's support does not depend on any subscription. Whether to support the AlmaLinux OS Foundation is the customer's own decision; anyone who chooses to should do so directly with the Foundation, so the money reaches the project rather than a reseller.
Service levels run from a next business day response to 30 minutes, 24 hours a day, every day of the year including bank holidays. Different servers in the same estate can sit at different levels, so production can have the fastest cover while a test system sits on something lighter.
No. There is no support contract, no minimum term and no notice period. Customers buy hours at published rates and use them as they need them, or take a fixed price annual maintenance plan if they prefer a predictable cost.
Our engineers are UK based and in-house, with no offshore outsourcing: the specialist who takes your case is the specialist who works it, and they hold the production experience to match the equipment in front of them. Risk is assessed before anything is changed, the SAPR method is applied to every fault, and five shifts a day mean an overnight handover is a conversation between two engineers rather than a note left in a ticket. Our AI runs on our own hardware in our own data centres, and it never writes a word you read.
There is no support contract, no minimum term and no notice period. You buy hours at our published rates, use them when you need them, and what you do not use carries over. How GEN support works sets all of it out in full.
