Enterprise Linux. Red Hat of SUSE?

Er zijn heel veel Linux distributies. Als je echter zoekt naar een Linux distributie voor gebruik in een commerciële omgeving, kom je bijna altijd uit op Red Hat Enterprise Linux (RHEL) of SUSE Linux Enterprise Server (SLES). In dit artikel zetten we de mogelijkheden van beide distributies naast elkaar.

De eigenschap, die de enterprise Linux distributies zo bijzonder maakt, is support. Als je Red Hat of SUSE koopt, dan koop je feitelijk geen software, maar ondersteuning. Deze ondersteuning wordt op verschillende manieren gegeven. De software zelf is namelijk gratis en is ook op een andere manier te verkrijgen.

Wat is nu eigenlijk support?

Voordat we kijken naar de details van beide distributies, is het zaak om het eerst eens te hebben over het supportmodel, dat door beiden geleverd wordt. Onder deze support vallen een aantal zaken. Om te beginnen is er de ondersteuning voor hardware. Dit houdt in dat de distributie alle drivers aan boord heeft om op ondersteunde hardware gebruikt te worden en dat de hardware leverancier je ook kan helpen als er iets mis is met de hardware. “Support” betekent in beide gevallen ook, dat je terug kunt vallen op hulp als er iets mis gaat, maar ook dat je een Linux omgeving krijgt, die door een strikte reeks van test procedures is gegaan. De mate waarin je hulp krijgt is afhankelijk van het type contract.

Tot slot is er support op het niveau van de toepassing. Als je dure enterprise toepassingen, zoals Oracle-databases of SAP op Linux installeert, dan is het belangrijk dat de leverancier van de toepassing je kan helpen als je in de toepassing in de problemen komt. Je wilt immers niet met een kluitje in het riet gestuurd worden met een opmerking als “onze toepassing ondersteunt alleen Windows, dus we kunnen u helaas niet helpen”. Tot slot worden onder de noemer van “support” ook updates geleverd middels beveiligde repositories.

Het aardige van Linux is natuurlijk dat het een open source besturingssysteem is en dat de software zelf gratis is. Het gevolg daarvan is dat je geen geld aan Red Hat of SUSE hoeft te geven om met hun software te kunnen werken. Vooral bij Red Hat is dat heel duidelijk: het bedrijf biedt ook CentOS aan. CentOS is dezelfde software als RHEL, maar zonder support. Daarnaast is er in de Red Hat familie Fedora, maar dat is een ontwikkeldistributie, die je niet in een bedrijfsomgeving zou moeten gebruiken.

Bij SUSE is SLES de commerciële software en het onderliggende platform is SUSE Leap (momenteel in versie 42.1). De overeenkomsten tussen SLES en SUSE Leap zijn echter niet zo groot als tussen Red Hat en CentOS. Leap is weliswaar de basis voor SLES, maar er zitten duidelijke verschillen tussen Leap en SLES.

Juist het bestaan van CentOS draagt bij aan het succes van RHEL. Zoals Brian Stevens (destijds CTO bij Red Hat) ooit uitlegde: “CentOS is voor mensen, die nog niet toe zijn aan een enterprise supported Linux distributie. We geven het graag weg, want bedrijven die nu CentOS gebruiken, gaan logischerwijs over op RHEL wanneer het bedrijf daaraan toe is. Als de organisatie bijvoorbeeld Ubuntu als gratis distributie gebruikt, is die kans veel minder groot.”

Verschillen en overeenkomsten

Zoeken naar verschillen tussen diverse Linux distributies kan vanwege het open source ontwikkelmodel soms uitdagend zijn. Ze zijn bijvoorbeeld allemaal te herleiden tot de Linux kernel en ook andere standaard open source onderdelen. Toch blijkt duidelijk dat elke distributie zijn eigen nuances legt en dat maakt van SLES en RHEL dan ook twee heel verschillende besturingssystemen.

SUSE Linux Enterprise Server

SUSE Linux is van oudsher de distributie, die zich richt op beheerdersgemak. Dit blijkt uit het beheerdersprogramma YaST, dat zich ontwikkeld heeft tot een waar configuratiecentrum, waarin basis- en geavanceerde configuraties gemaakt worden. Door te werken met YaST zorgt de beheerder van SLES ervoor dat complexe configuraties aangemaakt worden, zonder dat daarvoor veel kennis is van de vaak ingewikkelde structuren in de achterliggende configuratiebestanden.

SUSE werkt al heel erg lang met YaST en helaas heeft deze beheerdersinterface vanuit het verleden een slechte reputatie. In vroege versies van SUSE kwam het weleens voor dat een configuratiebestand, dat zorgvuldig handmatig door een beheerder opgebouwd was, lomp door YaST overschreven werd met nieuwe instellingen. Deze problemen zijn echter al heel lang geleden opgelost en komen momenteel gewoon niet meer voor in moderne versies van SUSE Linux Enterprise Server. YaST integreert momenteel prima en kan ook werken met configuratiebestanden, waarin door de beheerder handmatig aanpassingen gemaakt zijn.

Als beheerder betekent dit dat je de basisconfiguratie eenvoudig in elkaar zet met YaST en vervolgens de eventueel aanwezige geavanceerde features, die niet met YaST beheerd kunnen worden, alsnog handmatig in de configuratiebestanden verwerkt. Als je daarna YaST weer opstart om op die manier verder te werken in het configuratiebestand, dan gaat dat gewoon goed.

Btrfs

Een van de meest kenmerkende eigenschappen van SLES12 is het Btrfs bestandssysteem, dat als standaard gebruikt wordt voor het systeemgedeelte van het bestandssysteem. Waar Red Hat bij de release van RHEL 12 in 2014 nog vond dat Btrfs niet stabiel genoeg was, heeft SUSE het bestandssysteem geïntegreerd als onderdeel van haar “always on” strategie. Deze integratie verandert nogal wat voor het werken met de distributie.

Om te beginnen wordt er tijdens de installatie standaard gebruikgemaakt van subvolumes.  Deze maken het mogelijk om binnen een device op directoryniveau mounts uit te voeren, waar bij elke mount gebruik gemaakt kan worden van specifieke opties. Dit betekent dat je in plaats van één root filesysteem ineens een lijst met meer dan 10 mounts ziet. Dit biedt echter ook voordelen. Ten eerste kun je per subvolume aparte mount opties meegeven en daarnaast maakt het werken met subvolumes het mogelijk om ook snapshots bij te houden. Hierdoor kun je in geval van problemen op het bestandssysteem heel eenvoudig terug naar de voorgaande versie.

De snapshot technologie is door SUSE vergaand geïntegreerd in het besturingssysteem met behulp van de snapper utility. Deze functionaliteit, die standaard aan staat, zorgt dat er een snapshot aangemaakt wordt bij elke wijziging, die een beheerder vanuit het beheerprogramma YaST aanbrengt. Daarnaast kunnen er handmatig snapshots aangemaakt worden. Snapper maakt gebruik van standaardinstellingen, die ervoor zorgen dat het systeem niet vol loopt door die snapshots. Er worden dan relatief veel recente snapshots bewaard en relatief weinig oudere snapshots, zoals dat eigenlijk in een backup strategie ook het geval is.

Snapper is ook geïntegreerd in de GRUB2 bootloader. Deze integratie zorgt ervoor dat je tijdens het opstarten terug kunt gaan naar een voorgaande versie van het besturingssysteem. Tevens zorg je er zo voor dat je problemen tijdens het opstarten eigenlijk heel eenvoudig kunt ondervangen. De snapper integratie met Grub zorgt er namelijk voor dat je eenvoudig een oudere state van je OS kunt opstarten.

Keuze

SUSE probeert ook de Linux distributie van de keuze te zijn. Dat betekent dat je als gebruiker mag kiezen welke oplossing je wilt gebruiken en er niets opgedrongen wordt. Waar Red Hat met de release van RHEL 6 bijvoorbeeld KVM als virtualisatiestandaard geïntroduceerd heeft, waarmee Xen support gedropt werd, mag je in SUSE zelf weten of je een KVM of Xen gebaseerde virtualisatiehost installeert.

Een ander gebied waar je zelf mag kiezen, is kernel level security. AppArmor is nog steeds de standaard (en je zult wat extra moeite moeten doen om dat te veranderen), maar ook op SUSE kun je tegenwoordig SELinux gebruiken om te zorgen dat je systeem goed beveiligd wordt. Er moet echter bij gezegd worden, dat de SUSE implementatie van SELinux nog wat ruw is. Zo is er bijvoorbeeld nog steeds geen goede SELinux policy, waarin de beveiligingseigenschappen van alle standaardtoepassingen, die op SLES draaien, zijn opgenomen. Daarnaast wordt standaard AppArmor gebruikt en moet je dat (indien gewenst) expliciet vervangen door SELinux. De keuze is echter niet oneindig, want zo wordt bijvoorbeeld GNOME meegeleverd als grafische omgeving en zijn er geen KDE packages beschikbaar.

Ondanks alles zijn er zaken, die beter kunnen in SUSE. Zo bevat de installatieprocedure te veel stappen. Het zou prettiger zijn om, zoals bij Red Hat, alles vanuit één hoofdscherm op te geven, waarna de installatie uitgevoerd kan worden. Ook onprettig is dat de installatie lastig zonder muis uitgevoerd kan worden. Voor de rest biedt SUSE echter een uitstekende distributie, die als waardig vervanger van Red Hat gebruikt kan worden.

Een laatste ding dat opvalt bij SUSE, is dat het bedrijf erg sterk vertegenwoordigd is in bepaalde sectoren. Voor Linux op IBM mainframes is SUSE absoluut de marktleider en daarnaast doet SUSE het erg goed met het SUSE aanbod voor SAP Hana.

Red Hat

Het valt niet te ontkennen: Red Hat is veel groter dan SUSE. Vrijwel alle grote bedrijven in Nederland hebben hun Linux gestandaardiseerd op Red Hat en zeker in de jaren dat SUSE geplaagd werd door wisselingen van eigenaren (achtereenvolgens Novell, Attachmate en nu Microfocus), zijn op grote schaal SUSE-systemen vervangen door system met Red Hat Enterprise Linux. Technisch gezien is daar echter helemaal geen reden voor.

Red Hat biedt momenteel RHEL 7.3. In deze distributie, die net als SLES 12.2 gebruik maakt van de systemd package manager, wordt een stabiel platform geleverd met duizenden packages. Waar SUSE op sommige punten ronduit vooruitstrevend is, valt het op dat dat voor Red Hat veel minder het geval is.  Zo wordt er standaard gebruikgemaakt van het oude, maar beproefte XFS bestandssysteem en wordt er ook veel minder keuze geboden in beschikbare componenten. Als medegrondlegger van SELinux, biedt Red Hat bijvoorbeeld SELinux en ook niets anders. Verder is het Btrfs bestandssysteem weliswaar beschikbaar, maar als standaard root filesystem wordt gebruikgemaakt van XFS.

Waar bij SUSE het beheergemak voorop staat en heel erg veel onderdelen via YaST geconfigureerd kunnen worden, zal de Red Hat beheerder zijn werk nog steeds op de ouderwetse UNIX-manier moeten doen. De recent geïntroduceerde Cockpit utility biedt niet meer dan een interface, waarin systeemonderdelen gemonitord kunnen worden en zijn er maar weinig opties om ook daadwerkelijk onderdelen aan te maken of te configureren. Dat Red Hat weinig grafische tools aan boord heeft, is nog enigszins te vergeven (want wie draait er nou een GUI op zijn server), maar dat de TUI (Text User Interface) tools vaak oud en soms ronduit slecht zijn, maakt het voor beginnende beheerders een stuk lastiger om Red Hat te gebruiken. Zie bijvoorbeeld de schermafbeelding van authconfig-tui, dat kennelijk al sinds 2005 niet meer is bijgewerkt. 

Voor gebruikers, die wel op hun gemak zijn op de commandline, heeft Red Hat in RHEL 7 en later goed werk geleverd. In het bash-completion package bevindt zich veel hulp om ingewikkelde commandline tools relatief eenvoudig uit te voeren. Het is bijvoorbeeld menselijk bijna niet te doen om een commando als:

nmcli con add con-name my-con ifname em1 type ethernet ip4 10.0.0.0/24 gw4 10.0.0.1

uit het hoofd te leren, maar met Tab completion (dankzij het Bash completion package) wordt het toch wel heel eenvoudig gemaakt.

Daarnaast is er waar het ontbreekt aan Tab completion goede hulp beschikbaar in de man pages, die meegeleverd worden. Nu zijn man pages niets bijzonders voor een Linux distributie, maar tussen RHEL 6 en RHEL 7 valt het echt op dat er veel aandacht besteed is aan de man pages. Nagenoeg elk moeilijk commando heeft een man pagina, waarin met duidelijke voorbeelden staat uitgelegd hoe het programma gebruikt moet worden. Red Hat is er wat ons betreft in geslaagd om het werken op de commandline eenvoudiger te maken en dat verdient een pluim.

Een onderdeel van RHEL, dat nog steeds voor de nodige vraagtekens zorgt, is NetworkManager. Waar je in RHEL 6 deze service nog gewoon uit kon zetten, is dat op RHEL 7 een stuk lastiger, omdat het de standaardservice is voor het beheren van netwerk interfaces. Met de invoering van de nmcli utility is het een stuk eenvoudiger geworden om netwerkinterfaces aan te maken, maar bij het werken met NetworkManager en gerelateerde tools krijg je nog vaak het idee dat men hier nog zoekende is en onderdelen soms te snel geïnstalleerd zijn. Zo was er tot recent een vervelende bug in nmtui (het menu-gestuurde programma om netwerkconnecties aan te maken), dat bij het configureren van een IPv6 interface steevast een segmentation fault veroorzaakte.

Teveel packages?

Red Hat Enterprise Linux bevat heel veel packages en soms krijg je de indruk dat het er zoveel geworden zijn, dat dit tot problemen lijdt. Zo hebben we in RHEL 7.2 meegemaakt dat door installatie van nieuwe packages updates van dependencies geïnstalleerd werden, die door andere onderdelen van het systeem niet ondersteund werden. Hierdoor was een herstart niet meer mogelijk. SUSE heeft dit probleem gedeeltelijk opgelost door te werken met modules, waardoor het kernbesturingssysteem redelijk compact blijft. Helaas past Red Hat deze oplossing echter (nog) niet toe.

De keuze van Red Hat is duidelijk om een betrouwbare distributie te leveren. Daarom heeft Red Hat gekozen voor XFS in plaats van Btrfs, want het bestandssysteem is immers het belangrijkste deel van het OS. Ook biedt Red Hat geen keuze tussen KVM en Xen of tussen SELinux en AppArmor. Daar zit echter ook een goede argumentatie achter: meer producten ondersteunen, betekent minder focus. Het resultaat is dat er op Red Hat een uitstekende implementatie is van bijvoorbeeld SELinux, terwijl je op SUSE zowel bij SELinux als bij AppArmor het idee krijgt dat ze net niet helemaal af zijn.

Wat ook opvalt bij Red Hat is dat er meer coherentie zit in de verschillende onderdelen. Dit zie je bijvoorbeeld, doordat configuratiebestanden consistent zijn onderverdeeld, waarbij het deel dat uit de packages komt in /usr/lib geïnstalleerd wordt en het deel dat custom is voor een installatie in /etc belandt. Daarnaast geven de man pagina’s niet de indruk afkomstig te zijn van allemaal verschillende open source projecten, maar zie je duidelijk dat er eenheid zit in de manier waarop ze zijn opgebouwd. Zo vind je standaardonderdelen, zoals voorbeelden in man pagina’s van moeilijke commando’s, consistent overal weer terug. Het resultaat van deze consistente opbouw is dat je op basis van je inzicht in die structuur als beheerder zelf kunt beredeneren waar je bepaalde soorten informatie vindt. Dit maakt dat RHEL een distributie is waarin je je als beheerder heel snel thuis zult voelen.

Welke distributie?

Als je oppervlakkig naar de prijzen van de distributies kijkt, lijkt het alsof RHEL $ 349 per jaar kost, waar SLES met een list price van $ 799 dubbel zo duur is. Schijn bedriegt echter, want de RHEL versie van $ 349 is een self support versie en die wordt door SUSE al voor $ 99 geboden. De goedkoopste RHEL versie met support is net als SLES beschikbaar voor $ 799, dus qua prijs maakt het niet heel veel uit. Als echter met virtualisatie gewerkt wordt, is SUSE goedkoper. Ook het toevoegen van geavanceerde opties, zoals High Availability, valt bij SUSE beter uit. Er zijn echter ook andere factoren, die een rol spelen.

Kijkend naar vooruitstrevendheid, vinden wij SUSE er als beste uitkomen. We snappen dat Red Hat Btrfs twijfelachtig vond van kwaliteit in 2014, maar we vinden de keuze van SUSE om alle instabiele componenten eruit te halen en zo toch een betrouwbaar bestandssysteem te leveren beter. Het resultaat is dat je met SUSE echt een Linux distributie krijgt, die gebouwd is rondom een visie: de visie van “always on”. Red Hat is conservatiever qua keuze voor technologie en dat sluit zeker ook aan bij de behoeften van sommige bedrijven. Wat ons bij Red Hat erg aanspreekt, is de consistente manier waarop de distributie in elkaar zit. Je weet beter dan bij SUSE waar je als beheerder bepaalde onderdelen terug kunt vinden en dat maakt het werken met Red Hat soms eenvoudiger.

Als het echter om eenvoud gaat, is YaST van SUSE onvolprezen. Geen enkele andere distributie is erin geslaagd om zo’n veelzijdige en stabiele beheerinterface mee te leveren. Daar kan Red Hat met Cockpit, maar ook met andere tools, niet aan tippen. Daar staat dan wel weer tegenover dat Red Hat veel gedaan heeft aan onderliggende structuren en werkwijzen op RHEL 7, waardoor het bedrijf erin is geslaagd om het werken op de commandline een stukje eenvoudiger te maken.