Subscribe to GEN
Login to GEN
Nobody rings a Linux specialist to be told how popular Linux is. They ring because a server has dropped to an emergency console and will not come back, because an mdraid array has failed to assemble, because a volume group is missing a physical volume, or because something on the box looks wrong and nobody in the building can say whether it has been broken into. That is the work, and it is what our engineers do.
Service levels run from a 4 hour response Monday to Friday through to 30 minutes, 24 hours a day, every day of the year including bank holidays. There is no support contract, no minimum term and no notice period: you buy hours at our published rates and you draw against them. Every tier reaches an engineer, because we do not employ anybody to read a script at you first.
Linux faults are not vague. By the time somebody picks up the phone the system has usually told them exactly what is wrong, in a form nobody on site can act on. These are the cases that arrive most often.
A dracut or initramfs shell, an unbootable root filesystem, a bad entry in fstab or crypttab, a GRUB configuration that no longer points at a kernel that exists, a full /boot after an upgrade, or a systemd unit failing early enough to stop the boot. We work from the console, serial or IPMI, get the system up, and then find out what put it there.
Degraded and failed arrays, superblocks that no longer agree, arrays that will not assemble after a controller change or a disk reorder, and the far more dangerous case of a rebuild started onto the wrong member. We read the metadata before touching anything, assemble read-only where we can, and image the members first when the data matters more than the clock.
Volume groups reporting a missing physical volume, metadata restored from archive, thin pools that have run out of metadata space, snapshots that have filled and been dropped, and logical volumes recovered after a partition table was rewritten underneath them. Most LVM problems are recoverable, and most become unrecoverable at the hands of somebody guessing.
Unexplained outbound traffic, a load average with nothing to account for it, cron and systemd timers nobody wrote, altered SSH configuration and authorised keys, or a hosting provider notice. The first advice is usually to stop: do not reboot, do not reinstall, and do not delete anything, because all three destroy the evidence that tells you how they got in and whether they are still there.
ext4 and XFS repair, journals that will not replay, corruption after a power event, and ZFS and Btrfs pools that will not import or mount. We work on images rather than originals wherever the equipment allows it.
A server the last administrator built, undocumented, still running something the business depends on. We audit it, document it, and take it on from there.
If a system is down now, raise it on the HelpDesk. If you believe the system has been compromised, say so when you raise it, and leave it running.
Very few Linux tickets are about Linux itself. They are about the thing running on it: a web server returning 502, a database that will not start after a power cut, a mail server that has stopped being accepted anywhere, a container host that has filled its disk. We support the operating system and the stack sitting on top of it as one system, because that is how the fault behaves, and because the answer is very often in a layer nobody had thought to look at.
Apache and nginx configuration, virtual hosts, rewrites, reverse proxying, HAProxy and Caddy, TLS certificates with Let's Encrypt and certbot including the renewals that quietly stopped, and the 502, 504 and connection reset faults that come from the layer behind rather than the web server itself.
PHP-FPM pool sizing and process management, opcache, memory and execution limits, major PHP version upgrades on live sites, plus Python WSGI and ASGI, Node.js and Java workloads run under systemd.
MariaDB, MySQL and PostgreSQL installation, tuning, replication and failover, InnoDB crash recovery, corrupt tables, runaway queries, upgrades between major versions, and backups that are verified by restoring them rather than by the job reporting success.
Docker and Podman, Compose stacks, image builds and registries, storage drivers and volumes, networking and published ports, resource limits, and Kubernetes where the estate genuinely warrants it. Also the routine causes of a container host falling over: unpruned images, logs with no rotation, and a full /var/lib/docker.
Postfix, Dovecot and Exim, SPF, DKIM and DMARC, TLS, queue and deliverability problems, and the blacklist removals that follow a compromised account or an open relay.
Samba including domain membership and file server roles, NFS, rsync, OpenLDAP, FreeIPA and Kerberos.
BIND, Unbound and dnsmasq, DHCP, NTP and chrony, WireGuard, OpenVPN and StrongSwan, and the firewall rules in nftables, iptables or firewalld that sit around all of it.
Redis, Memcached, RabbitMQ, Prometheus, Grafana, Zabbix and centralised logging, configured to alert on things that matter rather than everything.
Where the stack is on our own infrastructure, see GEN Cloud. Where it is on yours, on your premises or at another provider, it makes no difference to how we support it.
Linux is not a single product, and a support offer that stops at Red Hat and Debian is not a Linux support offer. We fully support Alpine, Arch, Rocky, Alma, Red Hat, Fedora, Kali, Mint, Debian, NixOS, SuSE and Ubuntu, we take on CentOS and other distributions that have reached end of life, and we can support most of the rest. Our own routing, switching, firewalls, servers, telephony and virtualisation run on Linux internally, across the same distributions our customers use, so the differences between them are something we live with daily rather than look up.
The distributions most of our customers run each have their own page: AlmaLinux, Rocky Linux, CentOS, Red Hat Enterprise Linux, Fedora, Debian and Ubuntu.
We support Arch Linux too, but we do not recommend it for business production. Its rolling release model means there is no fixed release to test against, and a single update can change a great deal at once. For production we would normally steer you towards AlmaLinux or Debian.
A growing part of our Linux work is not on servers at all. It is on devices: industrial controllers, gateways, kiosks, instrumentation, single board computers and custom hardware, where Linux is the firmware rather than the operating system and the vendor who built it has moved on, been acquired, or simply stopped answering. Most of this work has reached us by referral from customers and from other engineers, which tells you how few people take it on.
Yocto and OpenEmbedded layers and recipes, Buildroot, OpenWrt, and plain cross-toolchains, including taking on an existing build tree nobody in the business now understands.
U-Boot, device tree, kernel configuration and patching, board support packages, serial console and JTAG access to boards with no documentation left.
Kernel and userspace drivers for I2C, SPI, CAN, GPIO, UART, RS485 and USB peripherals, and getting a working driver out of a vendor blob that only ever built on one old kernel.
Read-only root filesystems, overlay and tmpfs layouts, flash wear and filesystem choice, watchdogs, and A/B update schemes that survive a power cut halfway through.
Secure boot and signed images, disabling the debug paths that shipped by accident, credential handling on devices sitting on customer networks, and the long tail of CVEs in a kernel and BusyBox that were frozen years ago.
Reproducing a build for hardware whose original supplier has gone, extracting and rebuilding firmware, and keeping a fleet in service when replacement is not commercially realistic.
Small platforms are supported as seriously as large ones: Alpine, Raspberry Pi OS, OpenWrt and BusyBox based systems included.
Hardening is the other half of the compromise conversation. Most of the Linux systems we are called to after a break-in were not attacked cleverly: they were reachable, out of date, and running more than they needed to. Hardening is unglamorous work that removes those three conditions, and it is done properly against a benchmark and a written record, not by pasting a list of settings from the internet into sshd_config.
Patch discipline runs underneath all of it: vulnerability scanning and CVE tracking against what you actually run, with remediation scheduled rather than deferred. See preventative maintenance for how that is delivered as an ongoing service.
CIS benchmark and STIG alignment, applied and evidenced per system, with the deviations your applications genuinely require documented rather than quietly skipped.
Exposed services and listening sockets, packages and daemons nobody uses, firewall design with nftables or firewalld, and network segmentation between the systems that do not need to reach one another.
SSH configuration and key management, sudo policy that is specific rather than blanket, service accounts that cannot log in, and removal of the accumulated accounts belonging to people who left.
SELinux and AppArmor policy written and enforced, rather than the permissive mode most estates quietly settled for years ago.
sysctl and kernel parameter hardening, module blacklisting, systemd unit sandboxing, secure boot, and LUKS encryption at rest.
auditd rules that produce something usable, file integrity monitoring, log shipping off the host so the logs survive the incident, and detection of permission and configuration drift.
"The server is slow" is a symptom, not a diagnosis, and it is very rarely solved by adding more hardware to it. We measure first, with perf, ftrace, bpftrace and the rest, find the actual constraint, and fix that. A system that has been properly profiled usually turns out to be waiting on one thing.
I/O scheduler selection, queue depth and readahead, filesystem choice and mount options, RAID chunk and stripe alignment, LVM layout, and where an SSD cache tier genuinely pays.
NUMA topology and process placement, CPU pinning and isolation, governor and C-state configuration, swappiness, transparent huge pages, and dirty page writeback behaviour.
TCP stack tuning, offload settings, interrupt affinity and ring buffers, bonding and MTU, and the packet loss that gets blamed on the application for months.
MariaDB, PostgreSQL, nginx, Apache, PHP-FPM and Java workloads tuned against the operating system underneath them rather than in isolation.
Guest and host tuning for KVM and Proxmox, virtio configuration, storage path selection, and container resource limits that reflect the real workload.
Real time kernels, tickless configuration and jitter reduction for telephony, trading, instrumentation and control systems.
Beyond fault work, GEN provides Linux consultancy to organisations getting more from what they already run, or making a planned move away from a proprietary platform or an unsupported distribution.
Moving off Windows, legacy Unix, or a distribution that has reached end of life, with a realistic path and minimal disruption.
Linux server environments, high availability clusters, storage and network configurations built to last.
Bash, Ansible and Python automation to remove manual process and the errors that come with it.
OpenLDAP, FreeIPA and Kerberos for single sign-on and policy across a large Linux estate.
Docker, Podman and Kubernetes design, deployment and operational support.
Structured Linux training for system administrators, engineers and developers, from foundations through to advanced operations, on site, remotely, or as bespoke programmes built around your own environment. See Linux training for current course availability and pricing.
GEN fully support Alpine, Arch, Rocky, Alma, Red Hat, Fedora, Kali, Mint, Debian, NixOS, SuSE and Ubuntu, and can support most of the rest. GEN's own routing, switching, firewalls, servers, telephony and virtualisation run on Linux across the same distributions customers use.
Yes. GEN take on CentOS and other distributions that have reached end of life, and can also plan a move away from an unsupported distribution with a realistic path and minimal disruption.
Leave it running, raise it on the GEN HelpDesk and say that you believe it has been compromised. Do not reboot, do not reinstall and do not delete anything, because all three destroy the evidence that shows how they got in and whether they are still there.
Yes. GEN recover degraded and failed mdraid arrays, arrays that will not assemble after a controller change or a disk reorder, and LVM2 volume groups reporting a missing physical volume. Engineers read the metadata before touching anything, assemble read-only where they can, and image the members first when the data matters more than the clock. Most LVM problems are recoverable, and most become unrecoverable at the hands of somebody guessing.
Yes. GEN support the operating system and the stack on top of it as one system: Apache and nginx, PHP-FPM, MariaDB, MySQL and PostgreSQL, Docker and Podman, Postfix, Dovecot and Exim, Samba, DNS, VPNs and firewalls, whether the system is on GEN Cloud, on your premises or at another provider.
Yes. GEN work on industrial controllers, gateways, kiosks, instrumentation, single board computers and custom hardware, including Yocto, Buildroot and OpenWrt build systems, U-Boot, device tree and kernel drivers, and keeping a fleet in service when the original vendor has moved on or stopped answering.
Service levels run from a 4 hour response Monday to Friday through to 30 minutes, 24 hours a day, every day of the year including bank holidays. Every tier reaches an engineer, not somebody reading a script.
No. There is no support contract, no minimum term and no notice period. Customers buy hours at GEN's published rates and draw against them.
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.
