Red Hat Enterprise Linux (RHEL) Reviews

We are in a closed environment, so submitting a ticket can be painstaking as only a few of us have access to do so. We primarily use Red Hat for its stability, and it's one of the few Linux operating systems that meet our security constraints.

I find the satellite feature the most valuable. It allows us to manage disconnected workstations, keeping their patching, software updates, and bug fixes up to date. We can collect all the necessary updates on a connected system and then transfer them to a disconnected system. Each client thinks it's connected to an external satellite infrastructure, making management very easy.

The Image Builder feature seems very helpful. We currently use Kickstart to build systems.

The support can be lackluster sometimes, especially in our disconnected space where we have specific requirements. Occasionally, we encounter support representatives who are not familiar with our setup. So, in that space, personalized and tailored support based on each use case could be better.

In additional features, I would have said being more on the bleeding edge, but RHEL 9 was released, which is a nice push forward. So right now, I don't think there's anything specific. I find the product stack to be pretty decent.

I have been using this solution for three years. We are using versions 7.9 and 8.7.

It's very stable, but that's also why it falls behind at times. For example, if you have newer hardware like systems A and B that were released within the last year, there might be potential sleep issues, specifically with S3 sleep, that require manual patching and intervention in the kernel. It's because they are trying to support newer systems on a much older framework.

I believe RHEL 9 is supposed to mitigate that a little bit. It aims to provide a balance between the latest stable release and the older version that is, like, five years old. They're trying to meet somewhere in the middle.

We have around 30 workstations and approximately 60 servers.

The customer service and support team depends on the environment you are in. The support can be spotty. The support can be spotty; at least they've tried to be helpful. Sometimes they'll just point you to a documentation link, practically like Googling it for you, and it's like, "No, we've already looked at this. Can you please review the logs further?" And sometimes, I'll have to go and pinpoint specific areas to look at. And then it's like, "Oh, okay." 

It's not always very thorough. But it's hit or miss. So I think it's just a people thing. If you get somebody in support who really likes their job or enjoys fixing things, they're going to go out of their way, as opposed to someone who does the bare minimum.

Neutral

The initial setup is very straightforward. It's pretty easy to enable it. After weeks of setting up a Linux Kickstart, the whole system can be deployed. The whole bare-metal system can be deployed in around thirty minutes. So it's really fast, especially for a bare-metal image with a lot of packages installed.

When it comes to maintaining compliance, I think it's pretty good. However, for risk reduction, we have to rely on other software and tools. So I can't really say that Red Hat provides that specific functionality for us. But I think it's good for maintaining compliance is very easy, especially with satellite. It makes it easy for us to access package and vulnerability information, allowing us to identify and resolve any issues. Overall, it works quite well. If you use the right products, I believe you can have all the necessary components in one place.

The portability of applications and containers is pretty good, although there is one issue. With the transition to Red Hat 8, Docker was removed. As a result, there is an issue with using Podman, specifically related to certain types of authentication in a mixed Windows-Linux environment. Due to the way secrets and related functionalities work, Podman cannot be utilized in that scenario. Therefore, there are some challenges to address in this regard.

I believe Red Hat should have maintained compatibility with Docker or at least their own Red Hat Docker until they could bring their software up to speed.

We did the implementation ourselves. The documentation is pretty good.

I save at least a few hours weekly using Red Hat Enterprise Linux (RHEL). 

We got the license through a third party. They buy licenses in bulk for us. We pay them, and they handle the licensing.

Moreover, Red Hat's pricing and licensing structure seems fine. There's not a huge separation. The licenses can cover everything without worrying about the core count, socket count, or similar complexities like VMware and other big companies. It's simple enough to figure out which support contract you want based on the level of support you need.

It's an open source product.

Overall, I would rate the product an eight out of ten. The product is good, and the documentation is really comprehensive. The support is satisfactory as well. Based solely on the product itself, without considering support, we find it stable and capable of supporting various architectures. The documentation is particularly good and stands out. It provides valuable resources, including bug fixes, to people with developer accounts, which are free. Having all that information available is very helpful and resourceful, especially when troubleshooting Linux-related issues.

The documentation is very good, making it easier to troubleshoot any peculiar Linux-related problems.

We are a fintech company that uses Red Hat Enterprise Linux for enterprise and financial applications. Red Hat Enterprise Linux is deployed on servers at two sites. Access is mostly limited to IT staff because it is only used on our servers, not employee workstations. 

Red Hat Enterprise Linux offers performance stability, and it's easy to scale up or down by adding servers. The OS is easy to monitor and integrate with other systems. We use all these applications as containers. Red Hat has a container platform called OpenShift that we use to deploy containers. It's effortless to deploy and redeploy Red Hat Enterprise Linux. You can easily deploy it across multiple platforms and move it from one provider to another.

The operating system helps us meet security standards for the financial industry. You need high levels of security in this business to protect your financial data. Red Hat Enterprise Linux has various security features. 

We use the System Roles feature primarily with Ansible. It's powerful. You can use it to perform complex tasks, and it simplifies processes. For example, it helps you change network settings for storage, security, monitoring, etc. System roles help us automate security configurations and maintain consistency across systems. They have playbooks we can get from their website, and it's all based on system roles. 

My company uses Red Hat Insights only for systems with internet access, but most of our environment is offline. 

Red Hat Enterprise Linux is easy to manage, update, and integrate. I also like Red Hat Enterprise Linux's built-in security features. You need to enable them by default or keep them enabled if you want your system to be secured. It protects most of the system components. 

Red Hat Enterprise Linux's monitoring could be improved. I would like additional monitoring features, like a greater ability to monitor services and workloads running. Satellite can provide centralized monitoring of subscriptions and deployments. You can build a monitoring console, but there is no native monitoring. 

I have been using Red Hat Enterprise Linux for four or five years.

Red Hat Enterprise Linux is stable like every other Linux distro. It works fine. We have had no issues. 

Red Hat Enterprise Linux is easy to scale. You can clone it, deploy another instance, and scale it up with a few changes. 

I rate Red Hat's support an eight out of ten. I contact them often. Red Hat's support is helpful. They can solve your issue most of the time or point you in the right direction. 

Positive

Deploying Red Hat Enterprise Linux is mostly straightforward, but it depends on your requirements and the settings you need to apply. We typically do everything in-house. Red Hat Enterprise Linux requires a little maintenance. We need to do patching, clean up the file system, rotate logs, etc. 

I rate Red Hat Enterprise Linux a nine out of ten. If you don't know anything about Red Hat Enterprise Linux, you should read up on it. It will do everything you want. Red Hat Enterprise Linux is excellent.

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.

I use Red Hat to run applications like Apache, MySQL databases, etc. It is suitable for data storage and firewall. I can also measure performance with the SAR tools and do all I need with the Linux stack. I run several server farms, community applications, and more. Multiple teams use it. We have a hybrid setup, but we try to keep the use cases separate for each, so they're not transiting that much.

RHEL has made it easier to create, view, and update pools. We spin up a new one when necessary. We can quickly bring one down and move the traffic over, and it's a lot simpler to keep, update, and manage our application.

The solution has helped us achieve security standard certifications. Having the reporting on Ansible and other management components helps. We have a dashboard we can use and a blueprint to assist with the container. RHEL's toolkit helps us see which versions are running, so we can keep it lightweight. Also, having a newer base image ensures we have a standard. We always get what we're expecting. 

It helps us centralize development and move DevOps forward. They have a lot of support from multiple providers. I like having that standard. It makes it more straightforward for our developers to do troubleshooting here and there. The pipeline and support from the Red Hat team made a difference.

Red Hat support is pretty good. They're online, so you can look up things once you have support. Their AB integration has improved. It's easy to manage storage for moving, syncing LBM, etc.  

Red Hat excels at built-in security. There are lots of new security features in terms of profiles, email, using satellite, and disabling root login. They've got modules and built-in Ansible features. You can customize how it remediates, and Ansible will tell you what's out of compliance as you add rules.

Their container platforms are among the easiest to manage. Once you're done pre-testing, it is easy to migrate after you deploy in a sandbox. They have their inbox IDE and the like. 

I also think it's great that you can use one payment management system if it works correctly. You can see your overall footprint from both sides together on one screen.

I would like Insight to include some features from OpenSCAP, which they offer for compliance services. I played with it a little bit, but haven't gotten the updated setup to get that. It creates excellent documentation.

I have been using RHEL for 10 to 15 years.

RHEL is one of the more stable Linux platforms. 

RHEL is pretty scalable and easily rentable.

I rate RHEL support a nine out of ten. We can do captures to easily show them the issues we're having, and their response times are above average.

Positive

We had some smaller setups with this where we had some room for development, but now we're trying to standardize everything using smaller footprints, and not having to manage more workspace stuff. Now we're pretty much in RHEL and working on that.

RHEL was already there when I joined the organization, so I inherited it. In terms of maintenance, we try to keep it up to date. 

RHEL's price seems to be consistently changing, depending on what you're after. We might need a more extended license to lock in a price if it keeps changing. It would be nicer if it stayed steady within a specific range, but it's negotiable. We try to negotiate, and maybe a more extended contract would be better. 

When comparing to other solutions, you must consider the reporting and security features. It's an expense that we need to pay in terms of compliance. When you talk with your partner companies or potential customers, they need to know that we're on the ball and keeping up.

We have considered other solutions, but we see the added value from Red Hat, and there are many more features, so we must have support. I'd say we didn't do too much evaluation. We liked Red Hat from the get-go because they've got backing from IBM now. Also, they have started their own server- or container-oriented stuff. It helps to consider if we'll ever work with just Red Hat on AWS, given the ease of spinning things up.

I rate Red Hat Enterprise Linux a nine out of ten overall. I don't think RHEL is exactly perfect, but it's a trusted, easy and well-supported solution. They are constantly improving and trying to make it easier. 

We primarily use RHEL for LAMP stacks. Our deployment is currently on-premises, but if they change their licensing model on the cloud, we might start rolling it out in the GCP. It's used globally in VMware environments. We use it in APAC and AMEA, but the majority of the deployments are in the US. The major platforms that we run on it are PLM environment and digital asset management.

Our shop is what we call out of the box and if it doesn't run on a container out of the box, then we don't run it on a container. So none of our stuff is running containers right now.

RHEL has made our operations more reliable by giving us a more repeatable process. After we've built it once, we know it will work the same way the next time we build it. It has reduced the time I spend training my operations team, and the cost of ownership is low. 

The OSCAP scanner and Ansible help enforce company security standards, decreasing our exposure to attacks, data loss, ransomware, etc. From an operations point of view, managing the environment requires less overhead.

I like the Ansible automation and RHEL's backward compatibility with Script. It's also reliable. I also used the OSCAP stuff for a while for PCI/PI compliance. That was pretty handy and straightforward. I like the SE Linux for the LAMP stacks.

The cost could be lowered. We don't use RHEL in the cloud because Ubuntu is cheaper. Ubuntu factors support costs into the license when you're running it in the cloud, and it's a fraction of the cost of what RHEL is. I'm also not sure if RHEL supports open-source products. If they do, they don't advertise it. Adding stuff like Apache and other open-source tools like Tomcat to their support portfolio would help.

I have been using RHEL for 12 years

Linux is highly scalable in general, especially if you are using the container model, but unfortunately, we're not. I have no problem with scaling Linux or Red Hat's specific implementation of it.

I rate Red Hat support eight out of 10. Most of the support engineers are competent and helpful.

Positive

When I deployed RHEL initially, it was not very straightforward, but it's relatively easy today. The difference is the improvements to Satellite. Satellite Version 5 was kind of clunky. Version 6 seemed a little more straightforward and reliable. We don't use any kickstart, golden image, and roll and update, so there's not much to our strategy. 

The initial deployment took over a week, but it took about two days when we moved to RHEL 6. 

RHEL is competitive on-premises, but it's too expensive in the cloud. There are many cheap solutions for the cloud. In terms of upfront costs, open-source is more affordable and, in many cases, free. The long-term cost of support, staffing, and maintenance make it untenable. 

I have used Ubuntu and CentOS. I'm not a fan of Debian platforms. That's the main difference.

I rate Red Hat Enterprise Linux nine out of 10. I've been pretty happy with RHEL over the years. That's 20 years of Unix right there. I tell anybody coming into Linux or Unix to learn the program. Scripting is your best friend, and you can't understand automation if you don't understand basic scripting. 

If you've never seen Unix or RHEL before, go to a class and learn how to do it in a lab so you don't have to screw up your job. Once you're comfortable with that,  start learning containers because I firmly believe containers will replace how we do most of what we do today.

We're using it to support security applications. We also use it for various infrastructure aspects, such as hosting Satellite or Ansible Automation or Confluence. We have a mix of different apps running on it.

Our improvement as an organization, from using RHEL, has been the ability to take the stance of an infrastructure-as-code approach. We've seen that with automation of server deployment, getting them spun up a lot faster. Traditionally, the environment was using Satellite and Kickstart. Regardless of whether we were bare metal or virtual, it could take a couple of hours to Kickstart a server. Moving to infrastructure-as-code and deploying a server takes about 10 minutes until it's ready to use. It's a lot faster.

In addition to Satellite, we're using Ansible Tower. Those are the only ones we're paying for. We use other products, like Red Hat IDM for identity management but that's part of RHEL. When it comes to the integration between these products and RHEL, we're able to use Satellite for our dynamic inventory, with Ansible to help deploy new servers or manage servers, and we use Ansible Tower to patch our servers. Everything works pretty well.

That integration has helped to improve things compared to how they were when I got here. For example, we have a more automated process for patching. As we develop it and work through issues, we hope it will be more of a pipeline and a lot easier and faster, compared to how it was done before. Similarly for building servers, now that we're able to use Satellite as our dynamic inventory, we're able to run Ansible, whether it's predefined playbooks or ad hoc, without having to do something manually or maintain an inventory file.

We also use the AppStream feature in some cases. We have a couple of applications that require different versions, and we're able to install it and it makes the requirements for those specific applications.

The most valuable features are

• stability
• supportability.

Those have been the two common and important features over the years. They're pretty equal. You want to have something that's up and running and stable, something that's not going to crash. But if we do have an issue, we can get somebody for technical support who can help us work through the problems.

As for the consistency of application and user experience, we spin it up and almost forget about it. It just does what it's supposed to do, regardless of the underlying infrastructure. It's all good and there are no issues as far as supporting applications or things crashing go. Because it's doing what it's supposed to do, it's not a source of concern.

And similarly, there are no issues when it comes to deploying current applications and emerging workloads across bare metal, virtualized, hybrid cloud, and multi-cloud environments. We just have to take note of whatever the requirements are for the application we're deploying, to make sure requirements are met, and then build a server based on those requirements.

In this environment, I'm not doing any cloud work, but in my last environment we did do a bunch of public and private cloud and we had no issues there. It worked fine and as expected in AWS and OpenStack. We were doing infrastructure-as-code in that environment as well. We would create an image-base, whether for AWS or OpenStack, and then we would automate the deployment again, using Terraform and Ansible for configuration. It made deployment of cloud-based workloads relatively quick.

My biggest issue right now is Red Hat Consulting and trying to use some of their services to help get us going. Technically, they're good, but we seem to have issues with scheduling.

Also, we initially deployed it with Red Hat Satellite. We're now moving more to automation using Terraform within VMware, to automate the clone and then follow up with Ansible to configure. Red Hat's standard deployment is with Satellite and Kickstart, but we're looking at other options to help speed it along. We do have a mix of bare metal and virtualized servers and it's easier to spin up in the virtualized world versus bare metal. That's why we're looking at some options outside of Red Hat, for the bare metal. We'd like something that we can use to build a server a lot faster, as well as address network latency issues.

I have been using Red Hat Enterprise Linux (RHEL) since version 4 or even before that, since 2000 or 2001, before it was RHEL.

In the environment I'm in right now, we've never had any issues. It's very stable. 

In another environment that I worked in, we had some Oracle Databases, but that wasn't really an issue with the operating system. It was more an issue with some configuration items between the database and the OS. And that was about four years ago.

In the last company I worked for we were deploying a PasS environment, where we were doing some stuff with containers, and RHEL worked well. In my current environment, it's more of an application base but, again, it seems to scale. Both have worked fine.

Red Hat's tech support has been pretty good. I'll open up a ticket to see if I can get information from Red Hat when I don't have the time to find it on my own. But 99 percent of the time we get great support and we're able to get the answers that we need.

Positive

The pricing is fair. We do a bunch of dev work and there is some free dev licensing out there that's great for doing proof of concept work. When that was brought out a couple of years ago we heard about it, but it didn't seem to have been communicated to our Red Hat representative. We would ask him about it and it seemed that they were confused. 

But the cost has been pretty stable over the years for what you get.

We figure out what we need for servers, make our purchase, and then manage it all in Satellite. We just make sure we're using what we pay for.

In the past, I've used other versions of Unix, such as Solaris and HP-UX, as far as paid versions go. In other environments we also used community versions, like CentOS and Oracle Linux. 

Oracle Linux would probably be the closest thing to a paid solution, although I think it's free. But using Oracle Linux wasn't a good experience. Dealing with Oracle support was not the best. Maybe it has improved, but it just wasn't the same as Red Hat support.

Times have changed from when I first started using it. Back then it was just a matter of putting a CD in and installing it. One of the companies I worked for did a lot of homegrown stuff and I used their tools that were like Kickstart. Now it is all automation with infrastructure-as-code. The complexity of deployment is about the same. Some of what we're doing to deploy stuff is outside of Red Hat and it's a matter of finding what tools are available.

We're in the process of deploying something right now where we have different versions of Python. That's the only use case we have with multiple versions on the same server. I don't expect any issues, but it's still early in that deployment.

We have three people dedicated to maintaining the infrastructure environment that we work in. That includes managing Linux servers, the applications that go with them, and dealing with day-to-day tasks like patching. It's the typical life cycle maintenance functions: break/fix, dealing with hardware issues, deploying new applications, and maintaining a VMware environment.

The reason we're using it is because it's stable and we know we can get support. I know there are other versions of Linux, ones that I've used, but I've never experienced the kind of support with those versions that Red Hat has provided. Red Hat is a stable Linux solution provider.

We have various use cases with about 12,000 instances across four data centers and three different clouds. In general, it's for the adoption of and standardization with other vendors, so that other vendors' software is known to work. We're doing lift-and-shift of existing hardware infrastructure that is onsite into the Cloud.

It enables us to deploy current applications and emerging workloads across bare-metal, virtualized, hybrid cloud, and multi-cloud environments. Typically, there haven't been a lot of issues in terms of the reliability of applications across these environments.

The AppStream feature provides access to up-to-date languages and tools in a way that interoperates with third-party source code. It makes it a lot easier to maintain that, as well as keeps our developers happy by having newer versions of development languages available.

In addition, as we roll into version 8 and, upcoming, 9, it makes the migrating of older applications into these environments easier.

We also use Red Hat JBoss Fuse and Red Hat Insights, the latter being a part of RHEL. Red Hat products integrate greatly with the OS itself. We're pretty pleased with that. The integrated approach simplifies our operations to a great extent.

The most valuable features are the

• flexibility of the OS itself
• reliability
• support model.
  

Also, the two versions we use are fairly standard. Most of our applications work with versions 6, 7, and 8 meaning migration and maintainability are pretty good.

In addition, we run multiple versions of the same application on a specific operating system, between different instances. RHEL is great at managing and maintaining those different versions. It's so much easier, and it does it without destroying the operating system itself.

I don't see anything that needs improvement with RHEL itself, but there is room for improvement of the support infrastructure for it. The management and updates to Satellite, which is the support update, have been cumbersome at best, including releases and changes to a release. Communication on how that will work going forward has not been great.

I've been using Red Hat Enterprise Linux (RHEL) for about 20 years.

We chose Red Hat for the stability.

The scalability is really good too. In terms of increasing our usage, I can only foresee it becoming greater in the environment.

Sometimes the tech support is hit and miss, but most of the time they're really responsive and knowledgeable. If the first-line tech doesn't know something, they will escalate quickly.

If I were to compare the tech support from Dell, HP, and Red Hat, Red Hat is probably our best support structure.

Positive

I've been with my current company for 10 years. We've used other UNIX platforms, like Solaris and AIX, but those are for different use cases. The company I started at, which was bought, had seven different implementations and I standardized them on RHEL, before the acquisition.

We switched to RHEL because those seven different operating systems were supporting a single team and none of them had a great management infrastructure, or they were just plain open source with no support. And getting to a single, supported, managed environment was the goal.

Red Hat's open-source approach was a factor when we chose the solution. I'm a big fan of the entire open-source consortium. The more people there are who can look at the code, validate it, and make sure it works as it moves upstream into the solidified package that Red Hat supports, the better. It gives you more visibility, more transparency, and you can customize it more. Whereas with closed code, you have no idea what's going on in the background.

The initial setup of the solution is relatively simple. It's pretty much click, click, click, done. And the single subscription and install repository for all types of systems make the purchasing and installation processes easier.

Depending on the platform, deployment of a single RHEL instance could take anywhere from  five to 30 minutes. Bare metal is going to take longer than deploying the cloud.

The licensing is a subscription model and the only product whose model I don't like is Ansible. At $100 per server, with 12,000 servers, it adds up.

My biggest advice would be to read the documentation and reach out to Red Hat, or even just search the internet, so that you understand what you're getting into and what you're implementing.

I can't think of very much that needs to be improved with RHEL. The model that they have for maintaining patching, and their cadence on Zero-day attacks is fantastic, and their support is really good. I don't see any issues.

We use a combination of Red Hat and Oracle Linux in different parts of the organization. We have a cluster, where RHEL is running. The instances are both virtualized and real, depending on which part of the cluster you're utilizing. They are set up as either RAC or single instance, depending on what we are trying to achieve in terms of performance.

We have PeopleSoft systems that are all deployed on Red Hat. We also use it for deploying simple websites. PostgreSQL is running on the systems, along with a frontend that was created by the developers. We also use it for DNS fallback authentication.

We have quite a few Windows systems, as well, and some of the applications that we used to run on Linux have now been migrated to Windows.

We have a mixed environment, although, in the cluster, our deployment is primarily on-premises. There are some deployments into different cloud providers, depending on the service that we're looking for. However, when we head into the cloud, we tend to go to Product as a Service rather than Infrastructure as a Service or the like. This means that we're less concerned about the underlying operating system and we try to avoid interacting with it as much as possible. So, it is just virtualization in this case.

We rely on RHEL for stability, control, and reliable updates. There may be other Linux variants that work as well or better but we're quite happy with this solution.

We try very hard to ensure that everything is working irrespective of what it's running on, in terms of the operating system and middleware, including what database is running. RHEL helps maintain consistency of application and user experience, regardless of the underlying infrastructure, simply by not being part of the problem.

RHEL enables us to deploy applications across bare metal servers and virtualized environments, and it's an area where everything seems to be working okay. It is reliable and there is nothing that is causing us grief at the moment. The only ones causing us trouble are the applications that we're customizing, although that is nothing at the operating system level.

You can set up the security services quite quickly, which we found very useful in our context because we're a highly public organization and we need to ensure that we've got things patched as quickly as possible.

This is a very robust product that doesn't require a lot of handling. It just works. It doesn't really matter whether we've got Apache components on it or anything else. It'll run.

We have used RHEL's monitoring tools, albeit very rarely. The last time we used this feature, we were trying to track down a problem with one of our LDAP services and we were not getting any useful response back from support for that service. Ultimately, we were able to track the issue to a particular character in a user's surname.

There is nothing to work on in terms of speed and performance.

We started using Red Hat Linux approximately 15 years ago.

Overall, the stability is very good.

The most recent stuff that's been a little bit kinky was in the release of version 8. They were looking to change things around with how the product is built, so it just took us a while before we started using it.

I think we waited until version 8.1 was out and then we were fine. It was a case of us letting that version settle a little bit, as opposed to version 6 and version 7, which we went straight to once released.

Scalability-wise, it suits the needs of our organization and we haven't tried to do anything more than that. When we had multinode, Oracle RAC systems, we had a four-node RAC, each of them had four CPUs and 64 gigs of RAM, and they were all running one database. Performance was not an issue with the database.

This is one of those systems that people can use without knowing it, in a web context. Pretty much all of our research staff and students are using it, at least to a degree, even if it's just for storage management. From their perspective, if you ask them what they're using then it's just a Windows share, but in reality, it's RHEL. There are between 30,000 and 50,000 users in this category, and the majority of them wouldn't even know it was Red Hat.

We've got a fairly straightforward Red Hat implementation but the users do a variety of jobs. Some of the work that we do is implementation integration, so there are no specific users per see. It's just about migrating data and files, depending on what we need. The people that use it in this capacity are academic staff, finance staff, libraries, IT staff, students, and researchers. It is also used by systems engineers, senior systems engineers, the senior security person, my manager, and his boss. There is also a deputy director and the director.

We're probably not going to increase our usage by any level of significance. At the same time, we're probably not going to decrease in any great rush either. We're in a phase where we're looking at what can be put into cloud systems, and we are targeting Product as a Service in that space rather than infrastructure.

Essentially, we're looking to move away from managing operating systems when we put stuff in the cloud, but we still have hundreds of servers, just in one of our locations. The majority of them have no plans to move at this stage, so our installed base is fairly stable.

Primarily, we haven't had to use technical support and I can't recall the last time we actually had to log a call with them. It's a really good situation to be in.

It's an interesting situation because we use Oracle Enterprise Linux primarily. It is really not very different from RHEL because it's just recompiled and they resend it. We use RHEL on one of our clusters, which has about 300 nodes in it and is used in research. In short, we use both Oracle Linux and Red Hat Linux, but the reality is that nothing much is different between the two of them.

We initially implemented Red Hat and we consolidated everything to Oracle Linux because it was cheaper from a support standpoint. That was when Red Hat Enterprise Linux version 4 was out. I think that version 5 had only just been released and we switched to Oracle, which is the same thing anyway.

The last time the research cluster was updated, it switched from the IRIX operating system to Red Hat on HP. They weren't necessarily going to implement Red Hat but we had to make sure that everything was licensed correctly, and that's how it came into play. Since it is not using our Oracle license, but it's already bought and paid for, we have not consolidated it. We could consolidate again but it doesn't make a lot of difference in terms of what we do on a day-to-day basis. It runs the same and it operates the same.

We were running version 7 of Red Hat on the cluster and we have versions 4, 5, 6, 7, and 8 running in the Oracle Linux space. The applications running on version 4 will only run on that version, and there are only two of those left. We have three instances of version 5, about 30 running on version 6. We are trying to reduce this number and we had more than 60 running on version 6 a few months ago. The fact that this is going down is nice.

Versions 7 and 8 are still supported, so the specific version is not a concern.

Prior to using Linux, we used Digital's TruCluster. However, after Digital was bought by HP, they discontinued the product.

The initial setup was fairly straightforward. We put in the satellite server and then ran the config on each of the nodes to tell them where it was. After that, the updates were happening and there wasn't anything else to be done.

We did not use a formal approach for our implementation and deployment. It was probably more haphazard than structured.

We implemented it in-house.

We have four people that support it, although they do not work on it full-time. For example, the person who works on it most consistently also does work in the networking and firewall space, as well as identity management. We have more support staff for Windows within our environment.

The most recent change we made is a flag that had to be set on the kernel for some of the machines. Setting the flag means that you can patch it without having to reboot. This wasn't particularly problematic, although we had to make sure that it was in place because we now have patching occurring on a monthly basis.

In general, there is not much to do in terms of maintenance. The biggest drama has come from organizing upgrades to the application side that sits on top, rather than the operating system itself.

We've had some done ROI analysis over the years and it's always interesting when you read them. When you consider the initial implementation and you couple that with what we did with Oracle, we saved about $500,000 USD on purchasing all of the different parts by going with Red Hat.

This is significant as well because we still had the same capability with the hardware.

We've had similar kinds of examples thrown at us over the years, but primarily that's when comparing HP-UX and other vendor-closed products.

The price is something that can be improved, as they are still being undercut.

We are an educational institution and as such, what we pay is less than the average company. There are no costs in addition to the standard licensing fees.

Red Hat's single subscription and install repository for all types of systems is something that we're quite interested in because it's simpler and easy to manage hundreds of virtual machines. However, from a pricing standpoint, it's part of the problem because it's what Red Hat utilizes to explain why they cost more.

The Oracle licensing of support for the same Red Hat product is cheaper, and it's cheaper to the level of significance that it makes it worthwhile. We have spoken with the salespeople at Red Hat about it, and they have said that there was nothing they could do.

It's starting to become a question mark over the patching with version eight. We might be changing, but we're unlikely to be changing from Red Hat. It's more a case of who's running our support, be it Oracle or Red Hat. However, we would need to look at the numbers next time we renew, which is not until next year.

Prior to choosing RHEL, we looked at a number of different things. We conducted a fairly large scan of product offerings and our analysis included cost, availability, and support. It took us about three months to go through the process and Red Hat was successful.

The fact that Red Hat is open-source was a consideration, but it wasn't necessarily a winning ticket at the time. We came from a closed source product that we were very happy with but when we were looking at the alternative closed source options, none of them were even close in terms of product offering. Also, they were actually more expensive. So, when looking at the open-source with support opportunity that we were presented with from Red Hat, it was very much a cheaper option that also brought with it a lot of reliability. That is why we chose it.

RHEL provides features that help to speed deployment, although we don't use their tools. We use tools from a third party.

My advice for anybody who is looking into implementing RHEL is to make sure that it is going to work for you. Ensure that it supports all of the products that you need it to support once you've actually assessed all of those things. It is a quality product, there's no doubt about that. Once you have made that assessment, I would say, "Great, go for it."

In summary, this is one of the products that works well and does what we need.

I would rate this solution a nine out of ten.