When deciding what OS to use, there are many factors that come into play for a variety of reasons. This page attempts to outline some of the specific differences, while focusing on the reasons that many in the AlmaLinux community have cited as the reasons they pick AlmaLinux. The enterprise linux ecosystem is vast and has many differentiators that are nuanced, hard to articulated, and don't fit easily into charts, but we have attempted to capture some of the differentiations below.
In June of 2023 Red Hat announced that they would no longer be shipping their sources for Red Hat Enterprise Linux (RHEL) to git.centos.org, and would be limiting access to RHEL's sources to their customers. As a result of that change, we adjusted where we get our sources to match where RHEL gets its source. AlmaLinux utilizes package sources from both RHEL and CentOS Stream to build its distribution, in addition to other upstream sources, ensuring that our operating system remains stable and safe to use for our users.
You can hear specifics about how AlmaLinux is built today in this presentation(opens new window) from AlmaLinux Day: Germany, in March of 2024.
At the outset, it was important to the founding members of the AlmaLinux OS project to set the structure around the project in such a way that it is nearly impossible for bad actors to take control of the project and use it for personal gain. The project needed to be able to operate with a single mission: its community. While corporate social responsibility is a noble aim, the B Corp option wasn’t a good fit as it didn’t comply with AlmaLinux’s ‘north star’ of putting ownership of the OS, the IP, and the project’s direction in the hands of the community.
* major version compatible: aims for compatibility with the corresponding major version of RHEL
+** minor version compatible: aims for compatibility with the corresponding minor version of RHEL
+*** achieving FIPs compliance is a very complex and multi-year process not easily represented here, but links to the most recent information are provided.
Note: Previous versions of this table included a row for SecureBoot, but all distros now offer it, so it was removed.
The AlmaLinux Build System is managed by the SIG/Build System SIG.
The project is open for community contributions. If you are interested in contributing to the Build System project, we recommend you start by checking the AlmaLinux Build System project milestones(opens new window) for ongoing tasks and following the guidelines below.
When you are ready to create a pull request with your suggested changes, please follow the commit guidelines to keep our commit messages consistent across all repositories around the AlmaLinux Build System.
To contribute to development we recommend deploying the AlmaLinux Build System locally(opens new window) and following these guide steps for possible modifications and commit guidelines.
Help on keeping our Build System SIG documentation up to date (READMEs in repos, wiki, docs, SIG wiki page, etc).
Testing (experience with pytest), we need help to:
+
Increase our test coverage in repos that already have tests.
Add tests to those that don't have tests at all.
Design and implement integration/e2e tests that involve different services.
Familiar with Ansible? Help us in testing and improving our current ansible roles to deploy the AlmaLinux Build System.
Interested in supply-chain security and SBOM? Help us in defining the next steps toward providing and expanding the current SBOM data that AlmaLinux OS is generating.
When you are ready to create a pull request with your suggested changes, please follow the guidelines below to make our commit messages consistent across all repositories around the AlmaLinux Build System.
Every contributor should make commit messages that:
Make sense (grammatically).
Are meaningful/clear enough -> describe the change(s) made to the code.
Include references to a GitHub issue (whenever possible).
Include references to fixed (or resolved) issue(s).
This guide also aims to cover not only atomic commits made by contributors but also how merge commits must be performed.
Depending on the context, a commit message might have specific needs in different situations, i.e.:
There is only a single commit that fixes a single issue.
When there is a list of meaningful commits that fixes one or several issues at a time.
When there's no issue involved.
Even if we don't want to be very pedantic about how commits look (unless we decide to strengthen the policy for other reasons), we'd like to be more or less consistent with the goals described above.
Should contain a short (72 chars or less) summary.
Should contain more detailed explanatory text. Wrap it to 72 characters. The blank line separating the summary from the body is critical (unless you omit the body entirely).
Further paragraphs come after blank lines.
Bullet points are okay, too.
+
Typically a hyphen or asterisk is used for the bullet, followed by a single space. Use a hanging indent.
If you want to add references to fixed or resolved issue(s), do it at the end as in the example:
The body is a more detailed explanatory text. Wrap it to 72 characters. The blank line separating the summary from the body is critical (unless you omit the body entirely).
Further paragraphs come after blank lines.
Bullet points are okay, too.
Typically a hyphen or asterisk is used for the bullet, followed by a single space. Use a hanging indent.
When writing the body part, you can add as many details as you want to the commit message. Just remember:
The body is optional if the subject is enough to describe the commit.
Wrap lines to 72 characters.
Using the imperative or simple past tenses is acceptable, but please be consistent.
Feel free to describe what you think it's worth being described as if you were your colleague (who is more or less familiar with the code) and would like to understand what happened by just reading a few lines.
The footer is a perfect place to add references as links to fixed or resolved issue(s). If you have not referenced issues in the subject, then they can be added here:
Not having referenced issues is a possibility in case of dependency version updates and so on.
Can use a bullet list for the list of references.
Although using GitHub's abbreviations is okay, we require using the full URL as it will be meaningful if somebody is not reading the commit message through GitHub's interface.
Some commits might not be meaningful or might not include references to specific GitHub issues, so they cannot follow the same structure or be as fully descriptive. Since 99% of the time we merge pull requests (hereinafter PRs), we should add the relevant data in the commit message. By relevant data we mean the branch the code is coming from, and the information we would like to know about the commits as described earlier in the document, so that it can be understood later.
Sometimes, a PR has a single and meaningful commit message that doesn't require referencing an issue, i.e.:
Bump Pydantic from 1.10.7 to 1.10.8
In this case, we can do a squash and merge for the commit to end up in the repository in the following way:
Bump Pydantic from 1.10.7 to 1.10.8 (#562)
You can also create a merge commit message this way.
Merge pull request #562 from javihernandez:pydantic-1.10.8
+
+Bump Pydantic from 1.10.7 to 1.10.8
+
Of course, and as always, ensure that if the change is motivated by a GitHub issue, please do add a reference in the commit message as described in the previous section of the document.
Usually, PRs involve more than one single commit. Ideally, they all should follow the structure described in this document, but sometimes this is not the case. We can see commit messages like:
Addressed review comments.
Fixed typo.
etc.
+Which, for obvious reasons, do not provide a lot of information about the commit. For this reason, all our merge commit messages must:
Reference the branch being merged.
Reference the pull request.
+As optional things to add, merge commit messages can also (and we encourage you to) include:
Highlight, description or main goal of the PR.
Add references to fixed or resolved issues as described earlier.
You can refer to this example when writing the commit. The merge commit(opens new window) includes:
PR number
A branch being merged
Since it's a 2 commits PR, linking to issue being resolved is not mandatory, as usually described in one of the commits. For single commit PRs, we can add the reference in the merge commit if it's missing. In the example, we're referencing the PR and the issue that it fixes, not the branch being merged, but anybody can go and check the branch this commit is coming from.
Before you start writing a wiki page/instruction or modifying an existing one, we strongly recommend:
Look through existing open and closed issues(opens new window) for similar content, to prevent duplication.
Open an issue(opens new window) on the repo to propose your content before you begin writing it to ensure that is appropriate for the AlmaLinux Wiki and to collaborate with the AlmaLinux OS Foundation, Team and Community.
You can use a container engine like Podman or Docker to deploy a local development version of wiki inside a container.
Requirements: Docker or Podman
The wiki repository contains the Containerfile file that is used to create a container image with development dependencies installed. The command to create the container image requires setting a container name which, for example, is wiki_dev:
podman build -t wiki_dev .
+
WARNING
It's recommended to rebuild the container image if there is a change in the package.json file to make sure it matches the deployed version of vuepress.
+You can do it either by removing the current one and building the new one documented above or by creating a new one with a different name without removing the old one.
Now you can create a container from this image whenever is needed from the image that was built above and mount docs to /wiki/docs inside the container:
podman run --name wiki_dev --rm-i-t-p8080:8080 -v"$(pwd)"/docs:/wiki/docs:ro,z localhost/wiki_dev
+
The options of the command are:
+
podman/docker - container engine
run - create a container
--name wiki_dev - name a container wiki_dev
--rm - remove the container once it is stopped
-i -t - an interactive terminal session where you can track the deployment process and check the logs. Stop it with Ctrl+C.
-p 8080:8080 - map the port number 8080 inside the container to 8080 on the host
-v "$(pwd)"/docs:/wiki/docs:ro,z - mount docs in the current directory on /wiki/docs inside the container read-only (ro). ,z is needed only for systems that have SELinux.
localhost/wiki_dev - the name of the container image
We kindly ask that all members respect each other's diverse skills and abilities by acknowledging and appreciating the unique contributions each person brings to the team. Remember to provide as much detail as possible when sharing your expertise to enhance understanding and collaboration among all members.
AlmaLinux Wiki documentation is written with Markdown(opens new window). Some HTML elements can also be used.
All the content is located in the /wiki/docs directory.
To create a new page:
Navigate to the /wiki/docs directory.
Create a markdown file page-name.md with a clear name that corresponds to the topic of the page.
In order to get a page displayed, enlist it in the config.js file that is located in the /wiki/docs/.vuepress directory.
When editing an existing page or writing a new one, we recommend you follow this style guide.
The top of the page should include meta data with the page title. It should match the file/page name and topic.
---
+title: ' '
+---
+
If applicable (for example, when creating a new guide), fill out the form below and place it as a table at the top of the page right after the title.
Experience Level
⭑⭑⭒⭒⭒ (Intermediate)
Last modified date
YYYY-MM-DD
If possible, evaluate the level of skills and experience needed based on the target audience. Experience level options: Beginner, Intermediate, Advanced, Fluent and Proficient
Put the last modified or updated date below the experience level. The date format should go as YYYY-MM-DD.
If using this form is not applicable here, it's preferable to write right after the page title the date when the page was last modified. Please, stick, to the following format:
It's recommended to use clear and simple language.
It's preferable to divide the content into sections, including these basic ones:
+
Introduction: stating what the page is about.
Body: describing all the instructions.
Version specific directions: Remember that AlmaLinux currently more than one supported major version. If the directions differ for each release, consider dividing your instructions for each supported version into separate sections.
Known caveats: If there are any known or popular issues, write them as a separate section.
+We encourage images in guides, but please follow the below guidelines
If the page includes images, put them in the /wiki/docs/.vuepress/public/images directory where all images are stored.
The image name should be clear to understand and match the topic subject it's related to.
The image should not violate any trademarks or copyrights and should be relevant to the content.
The image should not contain any personal information for security reasons.
The image should be a proper size that is clear to read.
The image will serve from /images/, so do not change the beginning of this path.
All the commands (even separate ones) and code blocks should be formatted as code blocks, not as inline code:
{your command(s)/code}
+
If there's any example output/code/result, consider mentioning it right after according to the format below. Also, consider formatting it as a code block or as an image.
An example output you may see:
example
+
If there's anything to warn about or provide a tip, highlight it with markdown tips and warnings.
If there are trademarks mentioned on the page, we recommend writing Trademark notices at the bottom of the page.
Before committing the changes and creating a pull request, we also recommend to:
Any member of the AlmaLinux OS Foundation, Team and Community can take part in the review process and request any changes or updates.
+Merging the content is under the AlmaLinux OS Foundation and Team responsibility.
AlmaLinux OS is, at its base, a collection of packages. For anyone who would like to contribute to the operating system, we have a collection of ways to help!
The AlmaLinux Build System supports Community repositories, allowing users to create packages of their projects and share them with others.
If they are useful for the AlmaLinux community at large, these packages can also be released to the Synergy repository. Not all packages are a good fit for Synergy, but we are happy to consider them! Once your package is building successfully, you can ask for it to be considered to be included in the SIG/Core(opens new window) room on chat.almalinux.org(opens new window)
When you are ready to create a pull request with your suggested changes, please follow the guidelines below to make our commit messages consistent across all repositories around the AlmaLinux Build System. Every contributor could use this document to make commits that:
Make sense (grammatically).
Are meaningful/clear enough -> describe the change(s) made to the code.
Include references to an issue (whenever possible).
This guide also aims to cover not only atomic commits made by contributors but also how merge commits must be performed.
Depending on the context, a commit message might have specific needs in different situations, i.e.:
There is only a single commit that fixes a single issue.
When there is a list of meaningful commits that fixes one or several issues at a time.
When there's no issue involved.
Even if we don't want to be very pedantic about how commits look (unless we decide to strengthen the policy for other reasons), we'd like to be more or less consistent with the goals described above.
Should contain a short (72 chars or less) summary.
Should contain more detailed explanatory text. Wrap it to 72 characters. The blank line separating the summary from the body is critical (unless you omit the body entirely).
Further paragraphs come after blank lines.
Bullet points are okay, too.
+
Typically a hyphen or asterisk is used for the bullet, followed by a single space. Use a hanging indent.
The body is a more detailed explanatory text. Wrap it to 72 characters. The blank line separating the summary from the body is critical (unless you omit the body entirely).
Further paragraphs come after blank lines.
Bullet points are okay, too.
Typically a hyphen or asterisk is used for the bullet, followed by a single space. Use a hanging indent.
When writing the body part, you can add as many details as you want to the commit message. Just remember:
The body is optional if the subject is enough to describe the commit.
Wrap lines to 72 characters.
Using the imperative or simple past tenses is acceptable, but please be consistent.
Feel free to describe what you think it's worth being described as if you were your colleague (who is more or less familiar with the code) and would like to understand what happened by just reading a few lines.
At AlmaLinux, we're dedicated to providing a high-quality experience for our community. We believe that thorough testing is crucial to guaranteeing the quality and reliability of the distribution. We put a lot of effort into testing and making sure everything works smoothly regardless of where or what you run.
New AlmaLinux OS Beta and Stable versions are released every six months. We rely on our community to help us test Beta releases by providing feedback, reporting bugs, and identifying issues. Your input is crucial in ensuring our production releases are smooth and successful and we welcome your participation in this process.
If you're interested in contributing to Beta testing, please, see the installation/upgrade instructions in release notes and join the testing(opens new window) chat channel to stay informed.
AlmaLinux has implemented openQA - a tool created and maintained by SUSE - for the automation of testing. With openQA we set up testing environments and scenarios, making it easier to run tests to reproduce the installation process of our images. This helps us identify and fix any issues with the installer, graphics, branding, and visual defects, allowing our developers to quickly and efficiently test AlmaLinux and catch any problems before they're released to the public.
openQA is publicly available at openqa.almalinux.org(opens new window) and users can monitor the testing progress and see the results as screenshots and video recordings.
We have long-term goals of improving our openQA infrastructure with additional tests and expanding our openQA documentation on our wiki. If you're interested in contributing to openQA, please, see more details on the openQA wiki page and join the testing(opens new window) chat channel to stay updated and involved.
AlmaLinux OS is binary compatible with RHEL® and part ways in some matters. Before releasing an updated package with a patch or security fix, the AlmaLinux OS Foundation invites the community to participate in testing before its official release.
AlmaLinux offers one project for upgrading your operating system in-place (ELevate(opens new window)), and one for migrating to AlmaLinux (AlmaLinux-deploy(opens new window))! We're actively working on improving them with the community's help, and invite you to join us.
Red Hat, and Red Hat Enterprise Linux, are trademarks or registered trademarks of Red Hat, Inc. or its subsidiaries in the United States and other countries.
AlmaLinux OS development, infrastructure management, and overall project promotion are organized using our community chat. There are many ways to contribute to AlmaLinux OS - testing, quality assurance, documentation, and more. We'd love to welcome you! To help get you started, here is a Q&A video on the subject:
And here are some ideas to get you going:
How you or your team can contribute their time:
Content Creation: Create engaging content around interesting projects which showcase the use of AlmaLinux
ELevate - assist in expanding ELevate capabilities (migrations from additional versions), adding PES data for packages
Improve or expand documentation on our wiki
Become part of the infrastructure team for AlmaLinux – help maintain AlmaLinux core infrastructure, including build, test & mirror infrastructure
Become part of the security team for AlmaLinux - help define security architecture, maintain periodic audits and log reviews, etc.
Become part of the AlmaLinux build team - work on rebuilding RHEL packages, and building packages requested by the community. Assist in packing for EPEL.
Expert help - help users on our Mailing List, Mattermost chat & Reddit
Events staffing - represent AlmaLinux at LUG & Linux / OpenSource conferences - when they are geographically close to your location
Help with AlmaLinux branding - Web design, graphical design - almalinux.org website (Hugo!), swag or sticker design
Help get AlmaLinux through Common Criteria certification - CIS Benchmark and STIGs
Participate in the development of build platform, mirror platform - or any other part of the infrastructure (Python, JavaScript)
Improve or expand the translations of the AlmaLinux website
If your company benefits from the existence of AlmaLinux, consider sponsoring AlmaLinux enabling all of the work we do across the world!
Since AlmaLinux aims to be as close to RHEL as possible, it should have nearly identical bugs as the current release of RHEL. AlmaLinux recommends following an "upstream first" approach in order to help not just the AlmaLinux but the whole EL community:
Try to reproduce the steps and check whether the bug is present in CentOS Stream or has been already fixed.
If present, it means that the bug is upstream. Please, submit the bug to CentOS Stream bugzilla(opens new window) providing all the necessary information about an issue and reproducing steps. This is the contribution path to get the bug fix into the upstream, which will, in turn, be built into AlmaLinux.
If you are able to help investigate and fix the bug, please collaborate with CentOS Stream, as this is the best an AlmaLinux Community Member can do. Check the CentOS Contributor's Guide(opens new window) for more details.
If the bug is AlmaLinux-specific, please open a bug on AlmaLinux Bug Tracker(opens new window) providing all the necessary information about an issue and reproducing steps.
If you are interested in contributing, and learning more details about the technology stack of the tool and tests, please, visit the repository(opens new window).
To make AlmaLinux successful, we need the close involvement of the community members. We use our bug tracking system to find, track, and fix bugs. We encourage AlmaLinux users to help us by filling in bug-reports. You can track and discuss all bugs on bugs.almalinux.org(opens new window).
The importance of documentation cannot be understated, as it is like an investment in the future. It can take time and energy, but it is essential to create full and comprehensive documentation together.
If you want to participate, please, follow the guidelines.
We want to make sure that AlmaLinux images in Azure Cloud will use local mirrors for each region, and don't pay for traffic. More info here.
# 4. Promotion, blog posts, translations, and more!
If you are looking to flex skills not directly involved in development, we are always looking for guest blog posts, help with translations of our website, folks to staff events, and much more! Reach out in the Marketing(opens new window) channel for more info!
If you're seeking assistance in connecting with the appropriate individual or group, or if you're interested in guidance on becoming a contributor to AlmaLinux, please don't hesitate to reach out. Join chat or reach out on our forums(opens new window)! Our community of amazing users of all experience levels are happy to help you puzzle out your problem.
AlmaLinux OS Foundation is starting the election of the Board of Directors. We have 7 open positions to fill.
+The election will start on September 4th, 2022.
At this stage we are looking for nominees for the Board of Director position. To be nominated you have to:
Be a member for at least 3 month by Sep 4th, 2022
Nominated by AlmaLinux member in good standing
To nominate someone email name & contact information of nominee to election2022@almalinux.org
The election starts on Sep 4th, 2022 and run until Sep 19th, 2022. If we don't reach quorum by Sep 19th, the election will stay open until quorum is reached.
To reach the quorum we need 50% of all members to vote.
Who can be nominated?
Any member in good standing, approved by the membership committee not less than 3 months before the election
Note: only members in good standing may nominate a potential board member, and each nominee must have a supporting member (you cannot nominate yourself).
My company is a member sponsor, can it nominate any company employee?
Yes, sponsors can nominate any company employee, but if the employee is terminated, or company sponsorship laps, the person will be required to step down from the role.
Can I nominate myself?
No, you must be nominated by a supporting member in good standing.
How can I nominate someone?
E-Mail name & contact information of nominee to election2022@almalinux.org
Who can vote?
Any Platinum, Gold, Silver, Contributor, User, Alumnus, or Mirror member in good standing, approved by the membership committee on or before August 23rd
How can I vote?
You will get a link to the voting page in your e-mail on the day voting starts.
How many votes does each member get?
Contributor, Alumnus, Mirror members: 1 vote each
Platinum sponsors: 50 votes each
Gold sponsors: 15 votes each
Silver sponsors: 5 votes each
What is the minimum number of votes you need to win?
At least 50% of our membership must vote in order for the election to be valid
Top 7 candidates with most votes will win
How many seats are on the board, and how many are vacant?
There are 7 seats on the board, 3 are vacant, and 4 are up for re-election.
How long does a director serve?
A term on the board is 3 years, unless the director leaves for any reasons.
What platform will you use for the elections?
Helios.
Who can be nominated?
Any member in good standing, approved by the membership committee not less than 3 months before the election
Note: only members in good standing may nominate a potential board member, and each nominee must have a supporting nominee
Can I nominate myself?
No, you must be nominated by a supporting member in good standing
How are vacancies handled in the event that a director leaves before the end of their term?
If a seat is vacated less than three months before a planned election, the board may fill the vacancy by a majority vote, or may choose to leave the seat vacant.
If a seat is vacated more than three months before a planned election, the board must trigger an election to fill the seat or appoint someone to fill the seat.
Are directors on the board compensated?
Board positions are not compensated positions
Is Director at the AlmaLinux OS Foundation a full-time position?
It is not a full-time position.
How is the Chair of the board of directors elected?
The chair is one of the officers elected at the first meeting of the board of directors, or as needed.
Will the current board members need to be re-elected?
Yes, at every term they need to be re-nominated and elected
Can two members of the board also work at the same company?
Sure! AlmaLinux OS, much like RHEL and CentOS Stream, is a general purpose operating system. If it works with RHEL, then it should work exactly the same on AlmaLinux. We are not 1:1 with CentOS Stream, as Stream may at points track well ahead of our releases.
In July of 2023, we announced(opens new window) that we were shifting our goal from being a downstream rebuild of RHEL to maintaining ABI compatibility with RHEL. For the AlmaLinux team that means that everything from software applications to kernel modules that work on RHEL will work on AlmaLinux, and if they don't we would consider that a bug.
We chose the name AlmaLinux in homage to the open source community around the world. Alma means soul in Spanish and other Latin languages. A vital part of Open Source is the passionate, diverse developer community, helping support the work of projects like the Linux kernel and really all open and free software. We believe that community is the soul of Linux, and Linux distribution users are indebted to the community's efforts.
# How is the community protected from future course changes?
The AlmaLinux OS Foundation is a 501(c)(6) that was founded in March of 2021 to own and manage the AlmaLinux OS project. We have been involving the community since the beginning, and the governing board is chosen by members of the foundation. At all times, AlmaLinux OS will be free and open.
AlmaLinux OS is a community-owned and driven, stable, and secure Linux distribution. AlmaLinux is an opportunity for us to provide a Linux distribution that serves the broader community and which powers the computing needs of a wide range of users. Whether you are running a particle accelerator unlocking the mysteries of the universe, a Top500 HPC cluster, an enterprise running your database workloads, or a developer working on open source projects, AlmaLinux is for you.
AlmaLinux puts out new releases--fast. We typically release with a day or two of upstream RHEL releases. Updates are generally within 24 hours.
Our governance is under a 501(c)(6) non-profit organization to facilitate our objectives of being open, transparent and participatory. Community members who apply for membership in the foundation (for free) and are able to vote on the governing board of the AlmaLinux project and on critical decisions. There is no "ownership," and no controlling shareholders or interests. The foundation is by the members, for the members. All board meeting minutes are published and shared, including financial positions.
# What architectures and platforms do you support?
AlmaLinux currently supports four architectures - x86_64, aarch64, ppc64le, and s390x - providing full parity with upstream. In addition, we provide a wide range of other images and repositories: traditional ISOs, cloud and container images, live media, WSL - Windows Subsystem for Linux, and Raspberry Pi.
AlmaLinux provides a commitment to security updates and bug fixes for a period of 10 years for each major version. Moreover, AlmaLinux provides Errata, public OVAL streams, OpenSCAP and SCAP Workbench packages, including the availability of the official CIS Benchmark for AlmaLinux(opens new window). AlmaLinux has SBOM integrated into our build pipeline, facilitating software supply chain security.
# Where does AlmaLinux get package sources? How AlmaLinux is built?
The process in general looks like this:
We clone the upstream sources from the CentOS git repositories. These are the same source that Red Hat uses to build their packages.
De-branding: any trademarks are replaced at this point, and the .alma postfix is added to the end of the modified packages' "Release" field to distinguish our packages from upstream ones. You can also check the Modified packages page for more details.
TIP
Note: Most RPMs are rebuilt directly from the sources. The rebranding is required when any of the text/visual displays says Red Hat or RHN license manager enforcements.
# How do I migrate a single host from CentOS to AlmaLinux?
AlmaLinux developed a migration tool(opens new window) to make it simple to migrate to AlmaLinux from other Linux distributions including CentOS and CentOS Stream.
You can read more details and find guide steps on the Migration wiki page.
# How do I migrate an entire fleet of servers from CentOS to AlmaLinux?
Since AlmaLinux is compatible with RHEL®, your applications and services should be completely interoperable. You can rapidly migrate any number of servers using AlmaLinux-deploy(opens new window).
The AlmaLinux community has developed the ELevate project as an initiative to support migrations between a major version of RHEL-derivatives. It uses the Leapp utility(opens new window) and a few patches(opens new window) to support migration from CentOS are used to perform the upgrade.
The AlmaLinux OS Foundation is committed to supporting AlmaLinux including stable and thoroughly tested updates and security patches until:
Release
End-of-Life
AlmaLinux 8.x
2029
AlmaLinux 9.x
2032
Each minor version reaches end of life when the new version is released. For example, AlmaLinux 9.2 reached end of life with the release of AlmaLinux 9.3.
# I found a bug in RHEL; can I contribute the bug fix to AlmaLinux?
Since AlmaLinux aims to be as close to RHEL as possible, it should have nearly the same bugs as the current release of RHEL. AlmaLinux recommends following an "upstream first" approach to fix these bugs by testing against CentOS Stream, and submitting them to CentOS Stream(opens new window). For more information, please, see the Contribute page.
To make AlmaLinux successful, we need the close involvement of the community members. We use our bug tracking system to find, track, and fix bugs. We encourage AlmaLinux users to help us by filling in bug-reports. You can track and discuss all bugs on bugs.almalinux.org(opens new window).
# How can I request a package be added to AlmaLinux?
Having codenames for operating systems has a long history and has been adopted widely. While they aren't needed for us specifically, we keep them as part of our distribution both as an homage to our roots, and because the add a bit of levity to our work. Each minor version of AlmaLinux follows a specific pattern.
AlmaLinux 8 - blue color + cat name
AlmaLinux 9 - green color + cat name
Icelandic people believed that cats can eat you for Christmas dinner.
Many sailors and fishermen think that if a cat falls overboard, a storm will show up and the ship will be capsized.
Every Norwegian Forest Cat is supposedly thought to be either a fairy or a goblin in disguise.
The AlmaLinux project prefers to ignore such superstitions and goes for the Japanese version of the cat’s soul nature - the maneki-neko(opens new window) is an iconic Japanese talisman that, it’s believed, brings good fortune to its owner. One legend explains that a Japanese cat once waved a paw to beckon a lord into a house, which saved him from being struck by lightning a moment later, and so a cat who beckons with her paw is considered a lucky gesture.
Which is why we have decided to choose color + cat breed for AlmaLinux release naming convention. The first release was named Purple Manul, and the releases since have followed the same pattern.
Red Hat, Red Hat Enterprise Linux are trademarks or registered trademarks of Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The AlmaLinux Worldwide Community is made up of users with diverse skill sets and experience levels who can assist and support you across a range of questions, topics, and troubleshooting technical issues.
There are various spaces, forums and chats for discussions so that you can reach out to the Community.
TIP
Please, note, that typically signing up is required to join AlmaLinux discussion spaces.
Community chats allow users to communicate in various channels, each with specific topics like Packaging, Cloud, and Documentation, etc. If you have a question or need help, post a question in the General(opens new window) channel or in the relevant channel for assistance.
AlmaLinux OS also provides public forums for free information sharing and assistance from other AlmaLinux members. Additional Subforum categories foster conversations around a specific aspect of AlmaLinux.
First you need to create a Weblate(opens new window) account. You could use accounts from other service providers or fill in the form shown below to create it.
Choosing each one of the two should send you to a page similar to the image below.
Then choose the language you want to translate to. For this example, I'll choose Hebrew(opens new window).
After translating from English to your chosen language (.e.g Hebrew) press on "Save and continue" and your translation will be sent eventually as a PR to the almalinux.org repo(opens new window) and reviewed by a member of the marketing SIG or another team lead, then merged as appropriate.
Live Media is a way to try AlmaLinux on your computer without installing it to the hard drive. You can run it from a USB or DVD to preview and for system rescue needs. Images support both BIOS and UEFI, including Secure Boot mode.
dd: Start the dd command to write DVD/CD iso image.
+if=AlmaLinux-8-x86_64-Live-GNOME-Mini-beta-1.iso: path to the input file.
+of=/dev/sdc : path to destination USB disk/stick.
+status=progress: display a progress bar while writing the image to the USB stick such as /dev/sdb.
+That’s all! You now have ready Live AlmaLinux on a USB stick.
WARNING
This example is for AlmaLinux 8. Don't forget to replace 8 version with 9 to work with AlmaLinux 9 image.
Windows:
For Windows OS there is a helpful free and open-source application - Rufus(opens new window).
Open the application, choose your target USB, ISO you need to burn, press start - and Live OS is ready to run.
macOS:
The cross-platform tool balenaEtcher(opens new window) is used to write images on macOS. It is simple too. Open balenaEtcher, choose the image and the USB, press Flash.
Mirrors are extremely important to provide a fast and reliable
+infrastructure, and we are very grateful to people and organizations that
+help us with this. The current list of public mirrors can be found on the
+mirrors.almalinux.org(opens new window) website.
You can create a public AlmaLinux mirror in a few easy steps:
Make sure that you have enough free space: 500GB per major version is the suggested minimum. As there are currently two supported major versions (8 and 9) the recommended minimum storage space is 1TB.
Optional but recommended
Use updated version of rsync with xxhash support.
xxhash provides a superior hashing algorithm to rsync which lightens the load on the source and destination
+servers.
+We maintain an up-to-date version
+of rsync in the AlmaLinux backports repository. To use this repository on EL8 and EL9 distros:
The official tier0 rsync mirrors are in Atlanta, GA, USA, and Seattle, WA, USA. We use geolocation-based DNS steering to send your traffic to the closest tier0 mirror. If your mirror is not in the United States or you are
+otherwise seeing suboptimal speed from this source we recommend performing the initial sync from a mirror
+close to you. Make sure that your cron syncs from the official mirror, however.
Create a cron task to sync it periodically (we recommend updating the
+mirror every 3 hours):
Our mirrorlist URL tries to serve the best mirror to a client based on IPinfo geolocation data
+so having accurate IPinfo data ensures the best possible experience for users.
Fork the github.com/AlmaLinux/mirrors(opens new window)
+repository and create a pull request that will add a YAML file describing
+your mirror to the mirrors.d directory.
+You can use the official AlmaLinux repo file(opens new window)
+as an example. Your mirror does not have to provide all the protocols
+that our main mirror provides, but either HTTP or HTTPS is required. Format of a mirror's config is described below.
+Also, you can validate your config to use some JSON online validator using that JSON schema(opens new window) and converting your config to JSON.
---
+name: <domain name of a mirror, e.g. almalinux.mirror.link>
+cloud_type: <azure|aws. It'll be required if a mirror is located in AWS/Azure cloud>
+address:
+ http: <http URL to a mirror, e.g. http://almalinux.mirror.link/almalinux>
+ https: <https URL to a mirror, e.g. https://almalinux.mirror.link/almalinux>
+ rsync: <rsync URL to a mirror, e.g. rsync://almalinux.mirror.link/almalinux>
+ ftp: <ftp URL to a mirror, e.g. ftp://almalinux.mirror.link/almalinux>
+update_frequency: <update frequency of a mirror, e.g. 1h>
+sponsor: <Name of a mirror's sponsor/holder, e.g. Some company name>
+sponsor_url: <URL of a mirror's sponsor/holder, e.g. http://some.company.name>
+email: <e-mail of a mirror's sponsor/holder, e.g. admin@some.company.name>
+geolocation:
+ continent: <name of a continent, e.g. North America; this field is not mandatory>
+ country: <two-letter name of a country, e.g. US>
+ state_province: <name of a province, e.g. New York>
+ city: <name of a city, e.g. New York>
+private: <true|false. A mirror is available in some local network if the param is true>
+monopoly: <true|false. The mirrors list contains only this private mirror for a suitable client if param is true>
+# The list will be required if a mirror is local or cloud.
+# It contains subnets behind which located a private mirror.
+# Also, it can be string and contains URL which returns json list with subnets
+subnets:
+ - <network mask>
+# That parameter can specify ASN which is maintained by a mirror is located in cloud
+# It can be number or list of numbers:
+# asn: 40162
+# or
+# asn:
+# - 41222
+# - 91213
+# or
+# asn: [12345, 98765]
+asn: <ASN number or list of ASN numbers, see https://en.wikipedia.org/wiki/Autonomous_system_(Internet)>.
+# The list will be required if a mirror is located in Azure/AWS cloud
+cloud_regions:
+ - <cloud_region of Azure/AWS, e.g. australiacentral2>
+...
+
The AlmaLinux OS Foundation is 501(c)(6) non-profit organization. It owns all assets related to AlmaLinux OS. It is governed by a set of Bylaws(opens new window).
The goals of a Community-owned operating system needs to include transparency in all things. If you ever have a question, request, or need that isn't being satisfied through the available channels, you may always reach out to any member of the board for assistance. As of January 10th, 2023 the board has adopted a Code of Ethics(opens new window).
As of December 17, 2023, the foundation has a 9 board directors.
Daniel Pearson(opens new window) - Daniel is a current Director at AlmaLinux and is the CEO of KnownHost, LLC (promoted from COO during the election window), a current AlmaLinux Gold Sponsor, serves on the AlmaLinux OS Foundation membership committee.
Moshe Bar(opens new window) - Moshe is a current Director at AlmaLinux and is the CEO of CodeNotary, Inc., an AlmaLinux Gold Sponsor
Jun Yoshida(opens new window) - Jun is a current Director at AlmaLinux, and is the driving force behind MIRACLE LINUX
Non-voting invited experts to the board
David Snead(opens new window) - David is the current Legal Counsel at WebPros and acts in a general advisory role for the AlmaLinux OS Foundation board
Igor Seletskiy has stepped down from the Board of Directors, and the Board has elected benny Vasquez to replace him.
The board will be expanded to up to 13 directors (as new Platinum members arrive) to make sure that no single company controls the AlmaLinux OS Foundation.
Need to be "assigned" as belonging to AlmaLinux OS Foundation, need to come up with signing ceremony, who controls it
Q3 2023: Need to come up with rules for holding keys
EV certificate for Secure Boot
We've been on an AlmaLinux owned cert since 8.8/9.2
DONE
Logo License for the foundation
Transfer documents, and initial acquisition document uploaded into a Logo Transfer folder, transfer document signed
DONE - all assets in the Google drive
# Minutes of AlmaLinux OS Foundation Board Meetings
The Board of Directors meets monthly on the second Tuesday of the month. At each meeting, the board works to keep minutes so that they can be approved as part of that meeting and shared immediately after the meeting completes. In the event that there is little to discuss, the Chair of the board may opt to cancel a meeting, allowing the board to meet every other month.
In September of 2021, the Board of Directors opened up membership applications(opens new window) for all the members of the AlmaLinux community wishing to participate in the future of AlmaLinux. The Board also ratified the Membership Committee Governance, and appointed a selection of existing Foundation Members to participate in the Membership Committee.
The Membership Committee meets on the third Tuesday of every month for 30 minutes as long as there are applicants to be reviewed, and reviews as many applications as the time allows.
As of Oct 11, 2021 the Membership Committee consists of:
Daniel Pearson, COO of KnownHost, and Current Chair of the Membership Committee
The AlmaLinux Engineering Steering Committee (ALESCo), is a self-governing body made of active contributors to the project that will guide the technical direction of the AlmaLinux distribution. Participation in the meetings, discussions around potential changes, and other needs will be open to the AlmaLinux community, unless prevented for specific reasons (for example: an embargoed security patch). This committee was formed by vote of the 32nd meeting(opens new window) of the AlmaLinux OS Foundation board, May 8th of 2024.
Adding your voice to the ALESCo discussions is the easiest way to participate! You can show up to a meeting, add a vote or perspective to a change discussion, or ask or answer questions in chat! Not every participant needs to be a member of ALESCo, but if you do, we will soon have a way for you to express your interest.
Where we chat
We use the AlmaLinux mattermost for most communication.
Dubbed “air traffic control” for all engineering matters, ALESCo will ensure AlmaLinux’s robustness, reliability, and sustainability while working collaboratively with and overseeing technical decisions in relevant Special Interest Groups (SIGs). The committee will hold five key responsibilities:
As the committee gets its feet under it, this section will be expanded to include more information. Initially, this committee's responsibilities will be defining a collection of processes:
how the AlmaLinux project accepts requests for changes from the community
what changes the project is willing to consider
how the project solicits feedback from the greater AlmaLinux community about the changes it considers
how community members express interest in joining ALESCo
The foundation board appointed the initial committee members, but the rest of the management of the members will be done by the committee itself. Current members:
This proposal was a collaboration between the foundation board and many community members, and now acts as the governing document for this committee. Adjustments to this governing document require board approval.
The AlmaLinux Engineering Steering Committee (ALESCo) is dedicated to guiding the technical direction of the AlmaLinux distribution on a day-to-day basis within the guidelines set forth by the board, ensuring its robustness, reliability, sustainability, and relevance in the open-source ecosystem. ALESCo will work collaboratively with, and oversee relevant technical-focused Special Interest Groups (SIGs) to achieve these goals. It is "air traffic control" for engineering matters.
Policy Oversight: Create and maintain policies on the management of technical aspects of the AlmaLinux project. Its primary purpose is to be a policy-making group for when the need arises; for example, to lay out a clear framework for when we would deviate from upstream to provide a CVE or bug-fix patch early. Examples:
+
Change Proposals: Evaluate and approve new features or changes proposed for inclusion in AlmaLinux or relating to AlmaLinux's technical and engineering operations.
Package and Software Decisions: Supervise the inclusion, updating, and maintenance of software packages in the AlmaLinux repositories and ultimately decide which packages are added and removed from AlmaLinux.
Conflict Mediation: Act as a final arbiter in technical disputes related to AlmaLinux's operations within the community, ensuring decisions align with the project's best interests.
Long-Term Stability Focus: Prioritize the unique needs of users by ensuring enterprise-grade stability, compatibility, and long-term support in ALESCo's decisions. This includes a commitment to rigorous testing of updates, maintaining consistent software packages and configurations, emphasizing security, and providing comprehensive documentation to support deployments at all scales.
Release Management: Oversee the release cycle of AlmaLinux to meet the needs and expectations of our users per our mission statement.
SIG Liaisons: Each technical SIG needs to ensure ALESCo is aware of its plans and actions. To address this, if an ALESCo member is not actively participating in the SIG, it should work with the SIG to ensure a liaison attends ALESCo meetings.
Transparency: All meetings, decisions, and discussions will be public, ensuring transparency and community involvement. ALESCo members must publicly disclose their employer and any conflicts of interest, and maintain this disclosure in the wiki, updating it as necessary for accuracy.
Appointments: The first ALESCo members are to be appointed by the Board of Directors. After the initial appointment, the membership of ALESCo will manage itself - adding members or filling vacancies as deemed necessary by vote of the current members. ALESCo members are expected to have and maintain relevant knowledge and understanding of the technical aspects surrounding AlmaLinux as well as the greater enterprise Linux and open source ecosystems to allow them to make informed decisions in policy creation and voting.
Term Duration: ALESCo members are appointed with no set term. Every 6 months, at the time of chair election within ALESCo, each member is to be asked if they intend to continue serving or choose to step down.
Meeting Frequency: ALESCo will meet regularly, no less than once per month.
Decision Making: Decisions will be made based on a majority vote. In case of a tie, the chairperson (or a designated member) will have the deciding vote.
Quorum: A quorum is defined as 50% of members +1 with a minimum quorum always being at least four (4) members. A quorum is required for any votes.
Dissolution: At a point where the ALESCo is no longer functioning for the good of the AlmaLinux community, the board reserves the right to dissolve the committee and reform it with new members.
The position of the chair will rotate among the elected members of ALESCo on a semi-annual basis- a 6-month term. This ensures diverse leadership and prevents a single point of prolonged control, fostering a more inclusive decision-making process.
To ensure a smooth transition, the outgoing chair will work closely with the incoming chair, facilitating knowledge transfer and operational continuity.
The chair will be elected by members of ALESCo.
The chair cannot serve more than 2 consecutive terms (1 year) as chair.
The chair's primary responsibility is coordinating and facilitating meetings. The chair holds no special powers outside of what is defined in this document.
AlmaLinux 10's default x86_64 microarchitecture build will be v3, following RHEL. Approved building and maintaining x86_64_v2 as a separate architecture for AlmaLinux 10.
+
Unanimous decision.
AlmaLinux 10 will have frame pointers enabled, diverging from RHEL 10 which will not have frame pointers.
+
Unanimous decision
AlmaLinux will publish a rolling-style distro build, serving as a continuous beta release, starting with AlmaLinux 10.
+
We can package server-side components in AlmaLinux
We can package client-side components in EPEL
benny: Concerned about further deviation from RHEL
+
Retracted after clarification of no modifcations to kernel, and only addition of packages
Neal: Virt stack in RHEL remains relatively close to upstream, so good for maintainability of these additions
Neal: Upstream libvirt maintainers are good to work with, can probably propose running their CI against AlmaLinux Kitten 10
Voted to enable/build necessary packages for AlmaLinux 10 unanimously
Tabled discussion of adding back to AlmaLinux 9 at a later time
benny: ALESCo Live Community Q&A
+
No ALESCo members against this
Will be moderated by benny
Potentially quarterly
benny will coordinate a time that works for ALESCo members, maybe Sept. 4 or Sept. 11
Great for transparency and community engagement
Disabled HW in RHEL10
+
Andrew: What should we re-enable
+
All: Mellanox definitely
Andrew: 10s of devices disabled in EL10 kernel
Jonathan: QLogic & other less-used devices?
Neal: Linux Plumbers will be useful to make connections to RHEL kernel maintainers
+
They are generally willing to merge things for RHEL-disabled components as long as they don't impact enabled-components.
We probably need a separate process for users to request hardware enablement of devices
Ben: Already has requests within UCL for re-adding support for QLogic cards
Alex (Board): Must be careful when enabling things that might appear easy to flip a flag now but will potentially later become more difficult to maintain.
Jonathan: We can agree on an initial list of things to re-enable that are very common and/or we have direct experience with and vote on the rest as demand arises throughout the AlmaLinux 10 life cycle.
Elkhan: Separate kernel for PPC with KVM enabled
+
Neal: Basically what centos hyperscale does with their kernel - RHEL-ish config (based on Fedora) + enablement on some thingfs
Neal: What if we just re-enable it in the main Alma kernel since it is a flag?
+
Jonathan: We can mark that feature specifically as experimental, even in the main Alma kernel
Andrew: Just changing the flag isn't enough, a few patches are required to get it to build
Elkhan: Use-case is openQA and image building
+
All: not aware of any use-cases or requests from users
Ben: Separate workflow for kernel-specific requests?
+
Neal: fits within the other already-discussed to-be-defined change request processes
Andrew: Secure-Boot Signing ELRepo or other 3rd party kernels
+
Building works, signing works, never got further feedback on if we want to do this or not
Are we going to collaborate with 3rd party if we were to do this?
Neal: Anything we sign should be AlmaLinux-hosted
+
All: agreed on this point
Neal: Have discussed with Jonathan about also maintaing the Hyperscale kernel for AlmaLinux
Jonathan: Situation is too fluid right now to make a decision on this at the moment.
Jonathan: Better if we have a SIG that wants to maintain something within AlmaLinux versus pulling from a 3rd party
Neal: Signing SIG kernels in general
+
We have to be able to trust the full tree and trace back all changes to the origin
Jonathan: Motion to revisit this at a later time
+
All: agreed
Jonathan: Revisit ALESCo meeting times
+
Have heard from interested community members they cannot attend the current time of 10AM EST
Was difficult to select current time, tough to fit into ALESCo members schedules given varying countries/schedules
Neal: Potential compromise is scheduling the community Q/A sessions at varying times to be more accessible
Cody: Can re-run a discussion among ALESCo members to try to find a new time
AlmaLinux OS offers Amazon Machine Images in a number of formats and regions for consumption on AWS. All AlmaLinux OS AMIs are completely free of charge regardless of the deployment channel.
The AWS Marketplace is a curated digital catalog used to find, deploy and manage software offerings. All AWS Marketplace products undergo thorough review and vetting by the AWS team to ensure security and quality.
Community AMIs are images that are shared directly by the AlmaLinux OS Foundation for others to utilize directly within their infrastructure. Below is a complete list of currently published AMIs and their corresponding IDs. For purposes of automation and integration into build tools and CI/CD pipelines, this list is also available as a CSV(opens new window) file.
