Red Hat Enterprise Linux (RHEL) Reviews

We use it to host applications, services, and backend databases. We aren't using it on the cloud. Most of my customers are DoD or some type of government agency. If it's not classified, it's siloed in some way. We don't get to use a lot of the functionality that makes Red Hat cool. It's all disconnected.

In terms of version, currently, mostly everything is on versions 7 and 8. I've started pulling up some of the things from version 9, but that won't go into production for a while.

We use it because it's stable. That's half the reason, and the other half is because the DoD standardizes on it because it has a support contract, so even though we're forced to use it, it's a very good product, and it's on-prem. We probably would use it anyway.

We needed to host applications, services, and backend databases. We have a lot of Java-based applications, and we wanted something that we could deploy in different places around the world and that everybody standardized. Windows didn't really work for us on that. Most of the time, we're not connected to the Internet. We find that Red Hat or Linux in general works a little bit better for us than macOS or Windows.

It's also across the board a little bit cheaper for what we're using it for. That's a benefit we're getting from it.

We get our compliance from DISA, which is the defense information service agency. They put out security technical implementation guides. There are specific ones for Red Hat Enterprise Linux 7 and 8. The reason we're not using Red Hat Enterprise Linux 9 is that there isn't one for it yet. In terms of how we harden the operating system we're using, it's whatever they tell us to do and then whatever extra we want to do. It's as good as any other Linux other than the fact that it's supported by the DoD. For example, SELinux helps us secure across the board with contacts across different directories and things like that. They tell us how standardized the SD-WAN layout should be. We're able to go a little bit deeper into that. Red Hat uses Podman, which has SELinux, and which by default helps us a lot. 

We run Satellite on a lot of these, so having a central repository that we can use for patch management and remote execution is huge. That's something that is very difficult in a Windows environment. We're very compliance driven, so to have that built into Red Hat is easy. We don't need an agent or anything like that to get a lot of work done, so Satellite and centralized automation are the most valuable features for us. We're dabbling into Ansible but not as much as we should be.

It's obviously a security-focused operating system versus some of the other operating systems that lay you down in the terminal as root. In Red Hat Enterprise Linux 9, you can't even root. It's disabled by default now. Overall, they are definitely more security conscious, and that's also because of their primary customer space.

I've been using it for ten years or so. I've been using the solution since version 6. 

The stability of what we have deployed is good. The only time it crashes is if we do something or we try to configure a control that one of the engineers doesn't fully understand, which then breaks it. A lot of it's just like us breaking it ourselves or a customer asking for something that wasn't initially planned. Just pure deployment is good.

Its scalability is good. It's what they excel at. If we have 10 machines or 100 machines, they have the platforms to scale that up.

Overall, the customer support is good. It's better than Microsoft support. They are above and beyond that. They are better than others in terms of response time, getting somebody who knows what they're talking about, and not spinning their wheel. Usually, within the first response or two, people figure out what we're trying to troubleshoot here. We're not going from one queue to another queue or anything like that.

I'd rate them a ten out of ten. I've never had an issue with it. 

Positive

We had CentOS systems. When they changed upstream, we had to pivot some systems. We pivot some systems to Oracle Enterprise Linux, but then those eventually got transitioned to Red Hat as well.

The main reason for the switch to Red Hat was for the government customer and having a support contract. You can do Oracle Enterprise Linux without a support contract, but if you're going to buy one, you might as well get Red Hat at that point for the added benefits.

We use Kali for a couple of other use cases, and we probably won't replace it with Red Hat.

We've used a lot of flavors of Linux. One thing that sticks out for me, even in just the home lab environment or deploying at work, is that if there's some backward thing that we weren't planning on going into, if I look for a solution, nine out of ten times, I'm going to find an article on Red Hat's website where somebody has either a verified solution or somebody is talking about it and there are comments that are relevant. I hate going on ServerStack, Ubuntu Stack, or something like that, where somebody has the exact problem that you have, but there are no comments and no answers. I find that to be less true with the Red Hat platform.

The initial setup is pretty straightforward but can be tedious at times because of the compliance things that we have to implement. 

I just sat in on the training or the demo for the deployment platform, and we're already planning on setting up the Ansible automation platform where we also want to look into setting up this deployment tool because we do a lot of ISOs. We do a lot of kickstarts. We don't do any of the cloud tenants. We probably will switch to using the on-premise disconnected deployment capability because we can preconfigure everything and then run Ansible after the fact to get it all compliant.

We're the integrators or implementors of the solution.

We're forced to buy the licensing, but it's also good. I and a couple of other staff members are all Red Hat certified engineers, and then we all have our own specialties, so we don't call them a lot, but when we submit tickets, it's definitely worth it.

The ROI is mainly in terms of needing to recover from any system downtime. If we don't have an engineer on a computer doing a certain piece of research, then we're wasting money or just not generating a product, so to have the support that we can call and then reach out to us in enough turnaround time holds value for us.

The pricing is fair. The workstation licensing cost is fair. If you're running enterprise-level deployments, depending on what you're using, the volume licensing is good. I personally am worried that if they get so successful, they can increase the price, and then it won't matter because we'll be stuck on them. Hopefully, their open source mentality keeps that from happening. Where it's right now is good.

In terms of the portability of applications and containers built on Red Hat Enterprise Linux, I don't know how much that applies to us. In our case, someone develops an application in a Podman container, and we ingest that and run it, but we're not doing much more than that. So, all of the Java-based applications that we run, are run within a couple of different containers, and that's about it.

I personally use Red Hat Insights in my home lab. We can't dial out for that for a lot of customer-based work, but I personally use it. It hasn't helped avoid any emergencies because it's super low risk for what I'm using it for, but I can see the benefit of it. In a more enterprise setup, such as health care where I used to work, things probably would have been interconnected, and we would have been using Insights, but we're not using it currently.

Overall, I'd rate Red Hat Enterprise Linux a 10 out of 10. 

I am a Federal Contractor. Red Hat Enterprise Linux is one of the FedRAMP-approved operating systems, so the government is comfortable with using it. That is why we use it, even though it is a bit outdated. Most of our software runs on Red Hat Enterprise Linux because we work in Identity Access Management. For example, Oracle Identity Stack runs on Linux, so we have to use Red Hat Enterprise Linux. We follow very strict security protocols, and we use Ansible to enforce them. Red Hat Enterprise Linux is the easiest way for us to do this.

Red Hat Enterprise Linux is a trustworthy and highly scalable operating system. The federal government needs an operating system that they can rely on, with enterprise support and long-term service. As well as being stable and well-known within the community.

I have not yet experienced a disaster recovery scenario, but resiliency is important, and risk is very reliable. The auto logs are very clear. Additionally, with those support communities, it is straightforward enough to understand what we are looking for and to eventually resolve the issue.

I actually like the in-place upgrade that Red Hat Enterprise Linux offers. It has made our upgrade process from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 much easier than we originally thought. 

I know that many people prefer in-house support, but I personally prefer Red Hat's support. It is easy to get in contact with their support team.

Even though it is not directly related, the fact that Red Hat Enterprise Linux and Ansible are closely related makes it easier for us to move forward.

The package management, repository, and satellite repository are easy to use.

I am a bit biased because my client is air-gapped. This means that we cannot connect to the internet, so all of our operations are disconnected. I would like to see better support for disconnected operations. For example, the in-place upgrade from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8 initially relies on a lot of online resources. This makes sense, but it would be nice for a consumer or integrator like me to be able to say, "Hey, we need an offline solution so we can upgrade our government clients on-premises." Red Hat does provide instructions on how to create a repository, but the instructions are not very clear. This leaves us scrambling to figure out why we are missing a repository in our satellite image. Red Hat should provide a way to mirror repositories or at least provide a solution for us to bubble up packages throughout the entire process.

I have been using Red Hat Enterprise Linux for four years. We started with Red Hat Enterprise Linux 6, and we upgraded to Red Hat Enterprise Linux 7 in an airgap environment. We are currently in the process of upgrading to Red Hat Enterprise Linux 8.

Red Hat Enterprise Linux is stable.

Red Hat Enterprise Linux is scalable. It is deployed in a 10,000-plus enterprise company.

The support team is always direct and easy to find. Their answers are so helpful that I have not yet had to call them. I also appreciate how they approach troubleshooting. They don't assume that you're doing anything wrong. Instead, they try to educate you on how to fix the problem. In my experience, the support team has always been very positive.

Positive

I have experience with most Linux operating systems, including distributions like Apache, Debian, CentOS, Fedora, and others. From my perspective, Red Hat Enterprise Linux is not necessarily the top standout product, but I know that it is a product that I can rely on. It is the standard image that enterprise users in the community will use. We can rely to a degree on the standardization of how packets are used to support it. However, it does not stand out to us as much as the other products. Nevertheless, I know that it will have a positive partnership with us. Red Hat Enterprise Linux is a more suitable operating system for enterprise environments in terms of stability and reliability.

We are currently in the process of reviewing our initial solution for upgrading from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. The in-place upgrade for the airgap environment is an area where we are still struggling to understand the documentation. However, Red Hat has been very supportive and has offered us pathways to move forward. We do not have much to say at this time, as we are still in the middle of the process.

When we upgraded Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7, it took us around six months due to external factors not related to Red Hat Enterprise Linux.

Our client has a direct subscription to Red Hat.

I give Red Hat Enterprise Linux an eight out of ten. I am not a firm believer that everything is perfect right out of the gate. Everything can be improved. I am a little biased. I wish there was better support for offline environments. I understand that I am in the minority in this case, as everyone is connected to the internet now. However, as a federal contractor and integrator, we have requirements that we must meet. It is not fun having to download binaries offline and then figure out how to set up our own repository. These are not straightforward tasks like Red Hat telling me what to do. We just wish it was easier to do things like patch management. Perhaps there could be more support for air gap environments. These are not environments where we can temporarily connect to the internet. They have never seen the internet.

Depending on our customer's environment, sometimes they have GovCloud, but we still use Red Hat Enterprise Linux images there. Sometimes the customer can't use that so we use the offering from CentOS. But we still try to match it with CentOS.

The reason why some clients don't use Red Hat Enterprise Linux on the cloud is not because of security concerns. I think it's more about cost and their current contract situation. They need a low-cost, open source alternative, and our recommendation would be CentOS. However, many clients are not ready to pay for the enterprise edition of Red Hat Enterprise Linux, so they may choose to scale back their plans.

I have not used the Red Hat Enterprise Linux knowledge base strictly. I have only used the Red Hat Enterprise Linux support.

Clients who use Red Hat Enterprise Linux on the cloud, typically use AWS GovCloud. As a government integrator, we strive to design our solutions in a way that does not lock our clients into any specific cloud provider. This is why we chose Linux, as it can be run on any cloud platform. This flexibility is important to our clients from a price contract perspective. For example, Amazon provides Kubernetes services, among other things. We try to figure out open source solutions or at least architecturally determine them and provide them to our clients. For example, we can tell them that they can move all of their GovCloud data to Azure or Google Cloud. Government agencies really like Amazon right now because it is FedRAMP. However, for other classes that are not government or commercial, we try to introduce them to the CentOS perspective so that they can get a taste of the upstream.

We do not use the image builder tool provided by Red Hat. Instead, we use the one provided by Amazon. We take a base image, coordinate it with Ansible, and provide it to any environments that have used the cloud. For on-premises solutions, we strictly use manual processes.

I don't have a perspective on the golden image, which is at least with our client. The parts that we use are always evolving, so we don't really maintain the golden image. We do have a relative backup of what we deployed to, but we don't necessarily have a strict golden image.

Migrating workloads between the cloud and the data center using Red Hat Enterprise Linux is not entirely applicable to us. We did migrate from on-premises to the cloud at one point, but migrating from Red Hat Enterprise Linux on-premises to Red Hat Enterprise Linux in the cloud was not a concern for us. We knew it would be stable and fine. The main concern was migrating our customer data from our enterprise to the cloud.

If someone is looking for an open source cloud-based operating system for Linux instead of Red Hat Enterprise Linux, I would like to eventually drive them over to Red Hat Enterprise Linux, but I would recommend starting with CentOS. CentOS is a good gateway OS because it is very similar to Red Hat Enterprise Linux, and the knowledge transfer between the two is very straightforward. This makes it a good choice for users who are new to Linux, or who are looking for an OS that is compatible with Red Hat Enterprise Linux.

We are part of the State Department and use the solution to achieve operational excellence and readiness for the cloud. We think about what the next 20 to 30 years of consular systems infrastructure might look like to build and design for the next 40 years. Not many other companies think beyond a decade. 

The solution was implemented in our environment in 2014. The initial mission is still the same but how we go about it is different. For now, the solution is more for application support and making sure we are following State mandates or executive orders. 

For example, one use case involved planning, designing the implementation, and executing a launch of online passport renewals.

Our environment is moving toward tools that provide automation to remove human error. These are tactical operations and use cases. We currently use SaaS, OpenShift, and Ansible to a limited degree.

We had many issues with staff turnover during COVID. Working from home and trying to maintain databases was not ideal. During this time, the solution would have been rated a five out of ten.

Sometimes, vendors provide the government or bigger organizations with band-aids but not solutions. Everything seems to be a problem so many fixes are provided. A fix for this or a fix for that is equivalent to putting a band-aid on a large cut which will not work. Vendors tend to look at the money game because larger companies are their bread and butter. There should be an appreciation for the needs of bigger organizations.

It took some time to get us in a good position with the solution. There is definitely some growth and appreciation. We are at a place now where we can grow our environment. Today, the solution is rated a seven out of ten.

The solution is useful for application support and automations. 

A completely new setup should not be required when upgrading to a new version of the solution. For example, moving from RHEL 7.7 to RHEL 9 requires us to go through every minor version upgrade as well as RHEL 8. We do not have the ability to patch as quickly as we would like, but there are pathways. We got on 6.8 this year and migrated to 6.11 where we are trying to work on the automation portions of deployment. Before, we had variations of versions 7.2, 7.3, and 7.5 in our environment. We have not yet been able to use the supported versions that we are accustomed to with our applications. We are now on 7.9.1 and are trying to implement the minor upgrade versions in our environment. We have not yet experienced a healthy environment or the joy of using RHEL because we keep encountering issues and problems.

There are issues when upgrading or integrating with previous applications or systems such as Satellite, vRA, SaaS, or OpenShift. This is extremely, extremely important because a lot of our infrastructure is on RHEL. We need to have someone onsite to adjudicate our infrastructure's most important applications, when we would rather be able to patch them in a timely manner without having the whole world assist us. 

The solution should be more user-friendly so we better understand how to scale. It is not that we shun professional services, but there is a major knowledge gap in our understanding of the solution. 

I have been using the solution for four years. 

With anything, when you nurture it things work. Now that we are finally on 7.9 and migrated 6.11 we are actively trying to automate. This puts us in a better and more stable position. 

We rely primarily on our contracting staff or professional services for support. We receive onsite support from account engineers who apply critical patches or troubleshoot code that is not cohesive. For the most part, turnaround time is moderate but certain legacy applications are harder to troubleshoot, so they take more time.

Technical support steps in for big issues and provides good help. For example, support assisted with decommissioning 6.2 and 6.5 because they were at end of life with no option for purchasing ongoing support. We had professional services and many different products, so technical support made an exception to help with migrations and that was appreciated. 

Technical support is rated a nine out of ten. 

Positive

I do not know the setup details. The solution was implemented in 2014 and I joined the team in 2018.

We are currently experiencing issues when upgrading or integrating with previous applications and are looking for solutions. We push out patches and look at Tower. We already tried Puppet and it integrates with Satellite, but we prefer to use home-grown products. 

Because we use Satellite, it would be nice if the automation portions come from Tower or others. We have explained this to an account manager but solutions are being presented to us from a sales perspective. For example, we are told that we should ramp up, get other applications, or purchase more licenses.  

Decommissioning is one of our biggest issues. We upgrade and spin it up, but then have problems decommissioning some applications so more user licenses are required. For example, we have an unused server but cannot remove the license because we are either unable to get assistance or do not know how to perform the action.

We used vRA with the solution but it did not work for us.

We also used CloudForm but are attempting without success to decommission because it was not a useful case.

It is important to ensure there is a level of training for implementation. You need to understand compliance for your organization to determine whether vendors can provide appropriate tools. 

Do not be afraid to ask questions once the solution is implemented in your environment to ensure you are where you need to be. 

Stay on top of version or patch releases to prevent bugs or security vulnerabilities to your ISSO or agency. 

I rate the solution a seven out of ten. 

Our organization uses the solution as a scientific workstation for forecasting, data collection, data presentation, and delivery of products in the form of bulletins or images to the general public. 

We have five to ten scientists who work on installations at any given time. We need a pretty powerful but flexible cluster system to operate and develop applications for general maintenance. 

We have over one hundred sites so we need something that is efficient. We use Smart Management to distribute packages and Ansible for some of our remote, repeatable management tasks.

The solution is very good and the best choice for us because it is quite versatile and familiar to staff. It has its own quirks from time to time, but by and large, the solution has been very reliable and useful for our purposes.

We operate in a high-security environment and the solution's security profiles meet our standards.

The solution is very versatile with an intuitive, easy-to-use interface and a wealth of available applications.

The flexible and extensive system makes it easy to cluster, check redundancies, and perform data backups. 

The solution's open source aspect is appealing because it invites collaboration. 

The operating system might not be able to handle big scientific problems which require a highly parallel system and symmetric multi-processor to run logic streams simultaneously. 

I have been using the solution for twelve years.

I have used Linux since the 1990s. I started with Unix in 1979 as a student at Hopkins. I liked that Unix treated everything as a file and had a very consistent interface. 

Linux lived up to the spirit of Unix because of its core operating system that is modular with the basics and supports additional functionality as plugins. 

The solution is very stable. 

The solution is scalable. 

Technical support is responsive and very good. I rate support an eight out of ten. 

Positive

Ten years ago, I used VMS and AIX depending on the project. 

My job right now is on analytics-based systems so I use the solution. The organization has used it for twenty years. 

The setup was completed twenty years ago so I do not have details. 

The solution is easy to troubleshoot if you have familiarity with Unix systems. Any system of this scale will require maintenance but it is relatively straightforward. 

I rate the solution an eight out of ten. 

Red Hat Enterprise Linux's role-based security model enables us to provide discretionary access levels to users based on their roles and their responsibilities. We can also assign access based on service level to maintain service-level accounts for any purpose. If we need to back up a Red Hat Enterprise Linux box, we can assign a role to access that box only on the backup level. 

Red Hat Insights allows us to find vulnerabilities and conduct assessments from our central portal. It gives us insight into the compliance levels of different boxes and their licenses. Red Hat Insights helps us be proactive by giving us the details of recurring issues and vulnerabilities or zero-day threats. It automatically shows us what needs to be prioritized. It improves operations to have a single pane of glass for all your inventories and business. You can also implement automation and remedy most things from the cloud console. This is very helpful. 

Red Hat Enterprise Linux helps us achieve security standards certification. Most of our customers require compliance with regulations and internal security policy also. We have to be compliant with the profile for each standard based on Red Hat Enterprise Linux profiles or OSCAP integration. Satellite helps us remedy and manage compliance issues in daily operations.

Red Hat Enterprise Linux is the most reliable Linux flavor in terms of enterprise governance. I prefer it for its code stability, support, and integration. The lifecycle management features help us maintain compliance and keep the components updated.

The built-in security features simplify risk reduction. For example, Red Hat Enterprise Linux has built-in OSCAP profiles that we can select during implementation based on our industry and compliance needs. Using the OSCAP profile, we can minimize the effort needed to keep the software up to date. We also like the Red Hat Co-Pilot, which allows you to configure most things from the GUI.

We also have OpenShift, which enables elaborate, portable, and reliable ccontainerization. We use the System Roles feature when we have to disable root users and assign the system roles on the application level because some applications do not require root-level access or real group access. The System Role feature allows us to impose level controls and segmentation between the users. We can also automate security configurations to maintain consistency across systems over time.

I would like to use OSCAP profiles without the dependency on Red Hat Insights. If you install the OSCAP profiles from Red Hat Insights, I'm not sure if it is currently available in the cloud console. Most of the time, we manage compliance from Red Hat Satellite, but this feature could also be built into the console. Maybe it's not an issue price-wise most of the time, but it would be easier if we could use the same console and test-level capabilities.

I also want the co-pilot to provide more granular control and more features in the GUI, so we can have one configuration from the GUI itself. It would be helpful to have a feature similar to the one in Windows where we can manage all the net flows from one console in a single pane of glass and install it on-premises like an admin center. It would be great if Red Hat had some kind of admin center to manage all the Red Hat Enterprise Linux boxes without using an additional product like Satellite or something, we could use the co-pilot on all the systems to monitor the dashboard.

We started with Red Hat Enterprise Linux 6 in 2015. Now, we are on Red Hat Enterprise Linux 9, so it has been around eight or nine years.

Red Hat Enterprise Linux is a robust product. 

The scalability depends on the computing capacity and architecture. It varies based on whether we are replicating boxes or putting the Red Hat Enterprise Linux images into containers. The tool we use for orchestration is also a factor. 

I rate Red Hat support 10 out 10. We are mostly dealing with Level 1 or Level 2 support, and we always get a prompt response. Remote support is also available, which is nice. 

Positive

We used some open-source Linux flavors that are now obsolete and CentOS. Red Hat Enterprise Linux provides excellent support for migrating from CentOS to Red Hat Enterprise Linux at any level, so kudos to Red Hat for that. There is a great tool that enables us to migrate an existing application without any changes, so we can convert CentOS boxes.

There are one or two commercial Linux flavors that can compete with Red Hat, but their based on different architectures. Red Hat has a large portfolio, including OpenShift and SQL automation, offering deep integration between these tools. I don't think there is a competing product that offers a comparable product portfolio because Red Hat is under the umbrella of IBM now and also provides a multi-cloud solution. 

The initial deployment is straightforward. There's no problem. However, it also depends on what we want to achieve. Some of the options add a little complexity. It isn't very complicated, but it requires a different method. Overall, the general installation and configuration are effortless, and we don't have any issues. The initial installation can be done in 15-30 minutes, depending on the computing and storage capacity. 

We have one administrator experienced in Red Hat Enterprise Linux and enterprise Linux for maintence. We prefer a certified person who can understand the data complexities and advanced configuration, but a technician doesn't need to be a specialist to conduct the installation. 

The pricing depends upon the customer's bill of materials and what the customers are planning. Sometimes, a reseller and vendor partners provide a better price. I recommended buying the Red Hat Virtual Data Center instead of buying the Red Hat Enterprise Linux standalone licenses if anyone just wants to run a workload in the cloud environment. Virtual Data Center is the most cost-efficient.

The Red Hat Enterprise Linux license has a one-time cost, but there is an ongoing subscription for support with various levels. The license is perpetual, but we pay annually for support. Red Hat's support license is robust. You get three levels of professional support plus community support. Our banking, finance, and telecom clients rely on Red Hat Enterprise Linux entirely for their production workloads, so they need to minimize downtime. There is no comparison between professional and open source. We can provide support for some of our clients and set up redundancy, so that's something we can consider when we're looking at licensing or support costs. 

I rate Red Hat Enterprise Linux 10 out of 10. Red Hat Enterprise Linux is an affordable product and a great value. It is constantly evolving and adding capabilities. We can orchestrate a multi-cloud environment for Nutanix under Red Hat Enterprise Linux. It's an excellent product for virtualization.  

Red Hat Enterprise Linux is connected to our internal private cloud that is air-gapped.

We use Red Hat Enterprise Linux as the operating system on our network management and data management servers. It is our server operating system of choice for any type of hardware that needs to be reliable and stable.

Red Hat Enterprise Linux solved our need for automation and running containers. It is the most stable open source operating system available. When compared to other OSes, it is reliable and works well. This is important for my line of work, where I need to be able to reliably transfer files across thousands of miles. I need to do this quickly, and I have found that other OS solutions, such as Windows Server and Ubuntu Linux Server, are not as reliable or as quick. I have found myself constantly having to troubleshoot problems with these other OSes, and there is often not a lot of documentation available to help me.

The Red Hat Enterprise Linux knowledge base is awesome. Everything is documented, so I could easily find the information I needed to troubleshoot my misconfiguration issue. The knowledge base even provides suggestions for likely causes, which was helpful because most of the time, when something isn't working right on a Red Hat Enterprise Linux system, it's a configuration issue.

Security is one of the benefits of Red Hat Enterprise Linux. It is secure from the start, and it does not take long to configure it to meet government security standards. It also performs well during the staging process, and it does not break or cause services to be lost. In contrast, other operating systems often lock accounts, break, and cause services to be lost.

Simplifying risk reduction and maintaining compliance is straightforward and uncomplicated. There is plenty of documentation to help us, so if we get lost, we can refer to it to find our way.

The portability of applications and containers built on Red Hat Enterprise Linux makes it easier for our company to stay agile. We have found that our applications and programs run just fine on Red Hat Enterprise Linux, which provides a lot of supportability.

Red Hat Enterprise Linux's most valuable feature is that it comes with all the tools we need to set up and maintain an enterprise-grade system. Even if we install the minimal version of Red Hat Enterprise Linux, we will still have everything we need to get up and running quickly and easily. And if we ever need to restore our system from a backup, Red Hat Enterprise Linux makes it easy to do so, whether we are restoring from a scratch build or a backup that is a few weeks old.

A feature that I would like to see in the image builder is the ability to open the image in live mode and access a command line interface. This would allow me to immediately apply the necessary security settings required by the STIG. By doing so, I can deploy the image with the confidence that vulnerabilities present in the live network cloud service are closed before deployment, rather than applying the settings afterward as suggested in the example by Red Hat.

Ideally, I would prefer to deploy an operating system that already has all the necessary configurations in place. This would involve accessing a command line interface, adjusting configuration files as needed, setting up banners, and establishing user accounts. After making these changes, I would create an image and deploy it. I've noticed that the current image builder is primarily designed for commercial use, but as a DoD user, I have different requirements. Therefore, having an emulator or virtual terminal that allows me to interact with the kernel and make live changes, which can then be saved to create a customized ISO, would be an excellent feature to have. It would be great if Red Hat Enterprise Linux had a similar capability. Interestingly, Ubuntu Linux does offer this functionality with its "Custom Ubuntu Basic ISO Creator" (CUBIC).

I have been using Red Hat Enterprise Linux for two years.

Red Hat Enterprise Linux is stable.

Red Hat Enterprise Linux is a scalable operating system. Red Hat Enterprise Linux offers a wide range of options and features, and we are only just beginning to explore its full potential.

The initial setup is straightforward. I installed Red Hat Enterprise Linux using the stick method. I had to create nine different partitions, all of which were encrypted. This is where things got a little complicated. We need to decide whether to create a LUKS partition or partition and build our image on top of a LUKS partition. Initially, I was individually encrypting each partition using the "encrypt" option. However, this is not ideal because we cannot grow or shrink an LVM partition that is on an encrypted partition. Once the partition is created, it is set in stone. So, I needed to figure out how to encrypt just the partition and then create an LVM partition on top of the encrypted partition, such as SDA3. This was a bit of a challenge, and there is not a lot of documentation on how to do this. The documentation that is available is a bit confusing, and I got lost a few times. Once I figured it out, it was not too bad. The entire deployment process takes about 20 minutes.

We have seen a return on investment in all areas with Red Hat Enterprise Linux, including productivity. We use it in our daily operations in almost all of our systems. In one form or another, Red Hat Enterprise Linux is running on our systems. If we are not running Red Hat Enterprise Linux, our systems are unstable.

I give Red Hat Enterprise Linux a ten out of ten.

For those who are looking at other open source cloud-based operating systems for Linux, I would recommend Red Hat Enterprise Linux. It is well-documented and has a large pool of information available. We can also use CentOS content with Red Hat Enterprise Linux. The pool of information for Red Hat Enterprise Linux is far greater than some other open-source solutions.

The environment in which we deployed the solution is enterprise-level.

There are multiple use cases, and I am mostly focused on information security. Before we promote an ACS policy to production, we should be able to test that build and see how that policy behaves for that build. We use Podman to build some test images and get them to our development box. Then we use commands that we scan against those images. That has been one of the major use cases. 

In the future, we'll move our automation program from an on-premises Windows server to a Linux server. Over a period of time, we want to move those applications to the cloud and OpenShift. Currently, we have many legacy applications that are still being run on Windows Server, and we use the title job scheduler for that. Once we mature and gain more confidence, we want to containerize those applications and move them to OpenShift and Linux.

Red Hat Enterprise Linux's most valuable features are the Podman and a lot of packages that come inbuilt as part of the regular package. Podman gives you the opportunity to build those images. Since it's a public registry, you cannot pull those images from a docker, and proxy blocks that. If we know how to recreate that scenario, we use Podman to recreate that image.

Red Hat Enterprise Linux should provide more training because many people are not very familiar with Linux's user interface. If it is made very similar to Windows and people can relate to it, they would be more comfortable.

I have been using Red Hat Enterprise Linux for seven to eight years.

Red Hat Enterprise Linux is a stable solution.

I have experience interacting with Red Hat support for ACS. The initial level of support is very minimal. They try to collect all the data, then go to developers or technical people, which usually takes time. So we don't get an immediate response. Hence, there is scope for improvement in Red Hat Enterprise Linux's customer support.

Raising a ticket and having somebody look into it takes time. I rate raising a ticket and addressing it a six to seven out of ten. However, we interact with a responsive relationship manager, who escalates and gets issues fixed. I rate this relationship manager an eight out of ten.

Neutral

Since we have the capability to test vulnerable images, we know much in advance what their impact will be. We can test ACS policies against those vulnerable images. That gives us early visibility instead of deploying that application and finding what is happening there. Using Red Hat Enterprise Linux and all associated components gives us that visibility into vulnerable images, and we can set policies based on whatever we see. So in terms of business impact, we avoid many vulnerabilities that get into the production.

We run some applications on the cloud, but they are not business-critical applications. We run all business-critical applications on-premises. We are not dependent on the cloud for business-critical applications. We are not locked with the vendor.

We use Qualys to scan the underlying node. We expect any critical vulnerabilities to be patched as early as possible. We have an enterprise policy wherein any business-critical vulnerabilities seen on business-critical applications or nodes need to be fixed within 30 days. If some running application is exposed to the internet, we want that to be prioritized. If vendors can prioritize a 30-day life cycle for critical vulnerabilities, that would really help many other organizations.

Red Hat Enterprise Linux is the only option we are currently looking at. We don't want to go with Windows. We already have this ecosystem where we use OpenShift, and it's already integrated with ACS. So we would not like to go with any other different OS. Red Hat Enterprise Linux will integrate easily with the entire ecosystem.

Overall, I rate Red Hat Enterprise Linux an eight out of ten.

We use RHEL for high-performance computing. We host most of our production servers in our data center. Red Hat is a great package that helps us customize most of the data and dependent packages we receive from the Red Hat operating system. Most of our server requirements are being managed with Red Hat Enterprise Linux.

We mainly use Red Hat for our application deployments, standalone servers, and VMs.

We use this solution in a university. Most of the production servers and applications are required for the students.

We've seen a benefit in hosting servers and email security. RHEL provides excellent results and performance. It helps us achieve our goals for scalability and services.

We normally run crontab to keep our servers up-to-date. It works well with Red Hat Enterprise Linux because it has an advanced suite of features that can be effectively used for production servers. 

It also has RPM Package Manager, which includes most of the tools and utilities that every organization needs to have.

There is portability in the applications and containers built on Red Hat, which keeps our organization agile. Enterprise Linux offers flexibility in terms of dependent packages.

Red Hat Linux definitely enables us to achieve security standard certification. Most enterprise solutions need to comply with security standards. Many Linux-based operating systems fail to provide security because of open-source techniques.

Most of our production servers fail to deploy in Linux. When we deploy in RHEL we don't think about security because it has a lot of features like policy management. We can give specific access to specific users who require SSH or Telnet. It's more flexible because it can be altered easily.

We have used many Linux-based operating systems for production purposes, but this is the only solution that guarantees performance and scalability. When we run industry servers, they demand high performance.

It has great software support because it has a wide range of tools and utility products in the database. It's relatively easy to use enterprise products, and we don't need to add packages from other third-party sources. They definitely have a good database.

Red Hat's built-in security features simplify risk reduction and maintain compliance because Linux is mostly open source. We're running most of the production servers in this operating system, so we don't require a third-party solution because RHEL has a great range of security products with an inbuilt firewall. The inbuilt firewall is highly dependable and we can customize rules for outbound and inbound traffic, and specific accesses can be quickly returned in the script files. It has a great command line.

Red Hat allows us to build with confidence and ensure availability across physical, virtual, and cloud infrastructures. It already has a reliable operating system. Most companies rely on it for deployment on cloud and on-premise. With cloud, they prefer Red Hat because of the high-performance computing cluster.

It has great support for VMs and unlimited VM support. It's being deployed in our data centers and other large environments. It allows us to streamline the management of our infrastructure and makes it possible for more than one hundred servers and VMs to run, and it's up to date.

Red Hat Linux enables us to achieve security standards certification.

The graphical user interface should be more user-friendly. It's a concern because the command line is perfectly fine.

I have used this solution for five years.

It's very stable.

It's definitely scalable because we're deploying it in our VMs.

Technical support is satisfactory. There are forums that are also useful.

Positive

We used CentOS. It's a different setup than Red Hat. CentOS is also a Linux-based distribution. CentOS is open-source, so we don't need to pay for it. Compared to CentOS, Red Hat has advanced features but the cost is still high, so it's problematic for medium-level customers.

We switched to Red Hat because the service providers like high-performance computing. We mostly have high-performance computing deployed in our data center. We needed Enterprise Linux as a minimum requirement. Red Hat Enterprise Linux supports high-performance computing solutions, and packages have to be installed from their repositories. That's a must for any IT enterprise organization now.

CentOS is an open-source solution and provides 70% of the features that Red Hat provides. We pay Red Hat for the repository and application support.

It has a great set of dependable packages, software, and a collection of utilities embedded in that operating system. We don't need to get apps from the repositories. There aren't a lot of errors in the Red Hat operating system, which makes it useful for our system administrator.

The initial setup is very easy. It took about four or five hours.

The solution requires maintenance and constant updates.

Implementation was done in-house by a team of three people.

The pricing and licensing are a bit higher for Red Hat Enterprise because we're able to get 70% of its features with the CentOS version. For the 30% of features that Red Hat provides, I think they need to reduce the licensing fee.

I would rate this solution as nine out of ten.

My advice is if you're actually testing, you don't need to go with this solution. If you're an advanced Linux user or server administrator, you will definitely require Red Hat because many of the latest solutions require dependency-based repositories. It will be very easy if you're active with this operating system.

This has a set of repositories built into the database. We don't need to go anywhere to set up all of the databases and repositories. Everything is embedded into the solution.

If you're looking for HPC and NVIDIA clusters, most of the supercomputers need to have the solution, so it's better to have it equipped with that.