Software-update: AlmaLinux 9.4

AlmaLinux logo (79 pix)De AlmaLinux OS Foundation heeft versie 9.4 van AlmaLinux uitgebracht. AlmaLinux is net als Rocky Linux een van de nieuwkomers die in het gat is gesprongen dat CentOS heeft achtergelaten. Door het grote aantal sponsors lijkt AlmaLinux een blijvertje te zijn. De releasenotes voor deze uitgave kunnen hier worden gevonden; dit zijn de releasenotes voor deze uitgave:

Release Notes and More Information

The AlmaLinux 9.4 introduces updates to enhance machine security and data protection. Enhancements in web-console and system roles automate additional operations and promote consistency in complex IT environments. The new release’s features aim to improve system availability and reliability, facilitate easier recovery operations, and enhance virtual machine snapshot capabilities in hybrid cloud environments. The new system roles introduced enable the creation and management of logical volume manager (LVM) snapshots for improved data backup and recovery processes. Additionaly, updates in the 9.4 release continues to improve performance, scalability, and reliability for developers in building and managing applications.

You can read the full release notes for this version on the wiki: AlmaLinux OS 9.4 Release Notes.

AlmaLinux 9

Versienummer 9.4
Releasestatus Final
Besturingssystemen Linux
Website AlmaLinux OS Foundation
Download https://almalinux.org/
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Bart van Klaveren

Downloads en Best Buy Guide

06-05-2024 • 19:23

32 Linkedin Whatsapp

Bron: AlmaLinux OS Foundation

Update-historie

06-05 AlmaLinux 9.4 32
23-11 AlmaLinux 8.9 0
14-11 AlmaLinux 9.3 27
05-'23 AlmaLinux 9.2 20
11-'22 AlmaLinux 9.1 21
11-'22 AlmaLinux 8.7 42
05-'22 AlmaLinux 9.0 36
05-'22 AlmaLinux 8.6 32
Meer historie

Reacties (32)

32
32
16
1
0
16
Wijzig sortering
Volgens mij is AlmaLinux hét standaard pakket geworden voor managed (web)hosting. Laatst op zoek gegaan naar een dedicated server en overal werd standaard Almalinux aangeboden.
Logische ook wel. ze zijn in het gat van centos gesprongen.
Het is een 1 op 1 redhat compateble distro.
Goed dat je het schrijft want dat is niet meer van toepassing en mijns inziens een toegevoegde waarde om dat nu te melden. AlmaLinux gebruikt tegenwoordig CentOS Stream als bron. Zie hier, hier en hier. En aangezien de switch van CentOS toentertijd naar Stream, juist de belangrijkste reden was om AlmaLinux te introduceren. Is er geen enkele reden om nu, Stream in het sausje van AlmaLinux te gebruiken. Rocky Linux hanteert nog steeds het model van: '1:1 / bug-for-bug compatible Enterprise Linux'. Dan lijkt mij de keuze simpel.
Zover ik weet gebruiken ze centos stream als source en converteren maken ze het 1 op 1 compatible.
Zover ik kan zien merk en zie ik geen verschil met redhat orgineel. Wat ik uit destileer dat ze meerdere bronnen gebruiken om het compatible te maken.
AlmaLinux is ook gewoon 'bug-for-bug compatible' met RHEL, maar het is inderdaad geen 1:1 drop-in replacement meer. Het grote voordeel daarvan is dat AlmaLinux ook bugfixes doet die niet door RHEL worden gedaan. Red Hat kent verschillende fases van ondersteuning en regelmatig worden belangrijke bugs, soms zelfs security bugs, niet meer patched met de mededeling 'not in scope'.

Als applicaties die RHEL compatible niet werken onder AlmaLinux zien ze dat als een bug (de bug-for-bug compatbility). Daarmee maakt het effectief voor de eindgebruiker niet uit of je onder AlmaLinux werkt of onder Rocky. Ik vind de extra bugfixes aan de andere kant wel een groot voordeel, dus daarom heb ik zelf een voorkeur voor AlmaLinux, ook in een enterprise omgeving waar niet voor RHEL kan worden betaald.
Je hebt de termen omgekeerd, het is een 1:1 drop in replacement (alles dat op RedHat werkt moet ook op AlmaLinux werken), maar niet bug-for-bug compatible (sommige bugs zijn gefixed op AlmaLinux maar niet op RedHat)
Volgens mij gebruik ik de termen goed, maar als ik het wel omgekeerd doe is AlmaLinux dus ook 1:1 compatible. Dat zou betekenen dat het verschil dat kelly aangeeft tussen Rocky en Alma er niet is in die vorm.
FUD: ze gebruiken idd centos stream als bron voor bugfixes op rhel. Om die reden is het juist interessanter dan het traditionele model van de rhel klonen. Dat was namelijk wachten op rhel sources, en deze dan compilen en door je eigen QA chain halen. In de praktijk een vertraging van minimaal uren tot zelfs weken (!) bij een point release. Bovendien hebben ze ook duidelijk gemaakt dat bugs op almalinux gewoon bij almalinux gemeldt kunnen worden en in principe ook gefixed voor het weer upstream aangeboden wordt. Dus niet simpelweg alleen gebruik maken van, maar ook bijdragen aan.

Tuurlijk moet je helemaal zelf weten wat je gebruikt maar baseer je op de feiten niet op onzin 😀
Al dat geneuzel van redhat omtrend centos en later dat gedoe met de repos waren voor mij de hoofdreden om m'n serverpark - waar mogelijk - naar Ubuntu LTS te verhuizen, Rocky en alma zagen er leuk uit maar 3 jaar terug nog niet bewezen en waren dus geen optie. Dus alle nieuwe installs standaardiseren daarop (of Windows 2022 server) mits een vendor een hele goede reden heeft om iets anders te gebruiken; dat wil natuurlijk niet zeggen dat de hele partij RHs en Centos uit productie verdwenen zijn maar langzaam gaan die dingen wel - project per project - op de migratie schop...
Ik heb ook alles overgezet naar Ubuntu LTS, prima alternatief. Helemaal met de 10 jaar support en updates. Almalinux is meer voor de hardcore RPM / SELinux liefhebbers.
Als je distributies wilt vergelijken, doe dan RedHat tegen Debian. Dan kan je de RedHat afgeleiden ook vergelijken met de Debian afgeleiden.

Uiteindelijk moet het allemaal niet zo heel veel uit maken. Tussen RedHat en Debian is het voornaamste verschil het installatie-pakket-formaat. Daarna zal je zien dat de meeste pakketten in beide formaten beschikbaar zijn. En zo niet, dan is er wel een ander pakket formaat dat kan landen op jou platform of er is een goede reden om daar niet beschikbaar te zijn.

En ja, RedHat maakt het voor sommige organisaties lastig met haar licentie politiek Maar als je dat vergelijkt met andere operating systemen dan valt dat nog mee.
Op servers - zonder gui - heb je gelukkig wat minder last van zaken als snaps, flatpak en al die andere dingen. Zo lang je applicatie en dependencies maar beschikbaar zijn en de vendor de boel ondersteunt.

Linux desktops is over het algemeen geneuzel in de marge voor de meeste bedrijven en is leuk voor thuis om het maar even heel cru te zeggen - ja, ik weet dat er genoeg linux desktops gebruikt worden in vele bedrijven maar in mijn persoonlijke ervaring (server wereld dus) zie je dat nooit...
ja, ik weet dat er genoeg linux desktops gebruikt worden in vele bedrijven maar in mijn persoonlijke ervaring (server wereld dus) zie je dat nooit...
Dit voelt wat contraintuitief, ik zou denken dat Windows server admins Windows gebruiken ook als desktop en Linux server admins ook Linux gebruiken als desktop. Voor redelijk homogene omgevingen dan.
Als systeem admin zit je uiteindelijk (over het algemeen) ook aan de keuze van het bedrijf vast voor je desktop omgeving; Corporate IT is meestal een hele andere club en die hebben je graag in hun beheerde Active Directory (en omliggende beheer) omgeving; je kunt rustig hele server parken beheren vanuit een ander OS als je maar aan je beheer tooling kunt en het eea remote kunt benaderen via rdp of ssh. Die servers kunnen ook rustig in een andere afdeling vallen als corp IT en zelfs helemaal buiten hun verantwoordelijkheid. Het is net hoe alle verantwoordelijkheden vallen en hoe open IT staat tegenover vrije keuze…
Uiteindelijk moet het allemaal niet zo heel veel uit maken. Tussen RedHat en Debian is het voornaamste verschil het installatie-pakket-formaat.
Daar zou ik dan nog aan toe willen voegen dat RedHat (en familie) standaard SELinux ingesteld hebben, en - dit is m.i. belangrijk - met profielen voor de (meeste?) software in de eigen repo's. In ieder geval voor de software die ik gebruik. Voor wie SELinux belangrijk vindt, is een RedHat familie distro dan wel aan te raden, anders kun je zelf SELinux profielen gaan schrijven.

Afgezien daarvan zou ik Debian kiezen.
Wat is precies het verschil tussen Alma en Rocky en waarom kiezen mensen voor de ene of de andere?
Rocky word door een universiteit gemaakt en loopt vaak wat achter in versie's en bijbehorende patches. Logische ook wel want ze hebben bij de universiteit maar beperkte resources.
Alma word ondersteund door diverse bedrijven en loopt vrij dicht op redhat.
Dacht altijd dat er een bedrijf achter rocky zat. Heb na het de nek omdraaien van centos gebruikt totdat rocky geen gebruik meer mocht maken van de red hat soucrces. Waarvoor iets te zeggen valt.

Voor mij toen een reden geweest over te stappen op debian. Past veel beter bij mij situatie van een enkele desktop en server. Dat een grote organisatie of bedrijf voor ibm + red hat gaat is begrijpelijk.
Rocky Linux is ook niet gemaakt door een universiteit maar door een stichting: Rocky Enterprise Software Foundation. Rocky Linux maakt nog steeds gebruik van Red Hat bronnen en heeft daarvoor een project opgericht samen met CIQ (het bedrijf wat de stichting steunt), SUSE en Oracle; genaamd de Open Enterprise Linux Association. De bronnen die je nodig hebt om een Enterprise Linux distro te maken c.q. te beheren zijn zonder account, vrij verkrijgbaar via: https://openela.org/
Rocky Linux is inderdaad niet afkomstig van een universiteit, Springdale Linux wel: https://www.ias.edu/math/computing/Springdale-Linux.
Heeft iemand ervaringen met het upgraden van 8 naar 9? Heb altijd een rebuild gedaan maar nu schijnt dat wel goed te werken die major upgrades.
Ja, maar heb ik ervaring mee.

Als je een installatie hebt met weinig afwijkingen van wat Red Hat levert, werkt het prima.

Zodra je extra repos hebt toegevoegd of grotere wijzigingen hebt gedaan aan core-packages heb je zo veel werk aan voorbereiding en zijn de resultaten erg wisselend. (Van minimale dingetjes tot en met het niveau dat de machine niet meer opstart in multiuser-mode zonder lang te troubleshooten.)

Mijn algemene advies: niet doen 😊
Verkeerde aanpak. Externe repos allemaal disablen, packages/configs/content uit die repos backuppen en eerst verwijderen. Dan upgraden. Die repos worden namelijk niet door de upgrade naar 9 gezet en blijft op 8. Dus voorbeeld je blijft dan mariadb-server-10.3-rhel8 geïnstalleerd houden. In dat geval DB dumpen, RHEL 9 repo en package erop en DB weer inlezen. Je moet er met de vlooienkam doorheen of elk package versie nog klopt. Zelfde geldt voor Debian. Laatst nog een machine tegengekomen met allemaal achtergebleven deb9 packages op Debian 11. Gedist-upgrade elke keer zonder nacontrole. Deze staan dan als RC gemarkeerd, maar de config wordt nog wel gebruikt. Levensgevaarlijk, nalopen met apt-show-versions. Ergo - als je weet wat je doet kan het prima.
Ergo - als je weet wat je doet kan het prima.
Het kan ook zeker, alleen is het gedoe. De zaken die je opnoemt zijn allemaal nog relatief makkelijke dingen. Het is puur afhankelijk van hoe diep je in die externe repo's zit, hoe diep je al die core-packages hebt aangepast en of je een beetje 'normale' externe repo's gebruikt. (er zijn natuurlijk heel veel repos met een discutabele kwaliteit her en der). Er is niets algemeens te zeggen over hoe het bij iemand zal uitpakken.

Daarom blijft mijn algemene advies: Niet doen.
Ik lees alleen wat algemeenheden. Noem eens voorbeelden waarmee het misgaat? Je ziet toch aan versienummers altijd waar je mee te maken hebt?
Nou moet ik even denken hoor. Het is weer even geleden.

Dingen die ik ben tegengekomen:
- Auditd-plugins opkwamen en daarmee de server dus niet meer.
- Mounts waarvan blockdevices een ander id hadden gekregen door nieuwere drivers
- RPM-dependencies van derden die gebroken worden doordat packages anders zijn ingedeeld. (functies van libraries die verplaatst zijn).

Dat soort zaken.

Uiteraard allemaal op te lossen hoor. Het een wat makkelijker/sneller dan de ander.
Maar ik heb toch echt de voorkeur om gewoon de machine opnieuw op te bouwen en de applicatiefuncties over te hevelen.
Ik hoor wat je zegt, maar die RPM dependencies daar had ik het nou net over. Uiteraard kloppen die niet meer en dat is gewoon te fixen door de repo uit te schakelen tijdens de upgrade en daarna up te daten. Packages en dependencies allemaal (evt. handmatig) verwijderen op de oude versie eerst voordat je upgrade. Is er nog geen 3rd party RHEL 9 repo, dan kan je dus ook nog niet upgraden naar 9. Niet heel spannend wat ik lees eigenlijk. Voorkeur is het inderdaad, hangt ook van de machine af.
Voor ‘privé-gebruik’ kun je ook gewoon RHEL gebruiken. Je maakt een gratis developer-account, en je kunt gratis een x-aantal machines installeren.
Ook voor productie tot 16 stuks
Klopt, maar dan heb je geen ondersteuning. Dit lijkt me niet wenselijk voor zakelijk gebruik. (nou stelt de ondersteuning van Red Hat natuurlijk niet zo heel veel voor, maar het is beter dan niets)
Maar dat zei je niet. Debian heeft ook geen support. Weet je hoe vaak die zakelijk wordt gebruikt. De documentatie van Red Hat kan je gewoon bij en die is wat meer zakelijk gericht dan die van Debian.

[Reactie gewijzigd door pennywiser op 7 mei 2024 10:22]

Helemaal waar, maar ik ben lui en maak liever geen accounts met licenties aan als het niet nodig is.
Zeker als het eigenlijk niet zoveel toevoegt (voor mij prive gebruik).
Dus dan pak ik liever Alma, Rocky of OpenSuse als ik toch echt een RPM based distro wil gebruiken.

Op kantoor is natuurlijk een heel ander verhaal, maar daar betaald de baas voor de licenties.


Om te kunnen reageren moet je ingelogd zijn

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee