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.

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.

Currently, we're running our web servers on Red Hat Enterprise Linux. 

It improves our security posture, especially around patching. It has built-in security features for risk reduction and maintaining compliance. SELinux, which is basically the default firewall provided by Red Hat, allows me to secure myself in terms of the network ports that are exposed or enabled, which reduces the risk. When you have a web server, you have a public IP, and for the public, it's easy to do a port scan on that particular public IP, but when you do implement proper security controls in terms of firewalls, you're able to enable only those ports that you need for communication. For example, for a web server, you'll enable port 443 for HTTPS and one or two extras for a particular requirement for Tomcat or something else. The setup and configuration are quite easy. OS-level patching is a big deal for us for maintaining compliance. With the enterprise subscription, you do get patches as soon as they're released by Red Hat.

It helps with portability. I can take a snapshot of my Red Hat virtual machine and restore it anywhere regardless of the virtualization platform, as long as the processor architecture stays the same. For example, if you're doing a backup and restore from a RISC-based processor, you can always restore it to any other RISC-based processor. Similarly, if you're taking a backup or a snapshot on any X86-based processor, you can restore it on the same processor architecture, regardless of the platform you're running. It could be Dell, IBM, or something else. Portability is a huge but often understated feature. It means that if a server has gone down, regardless of the issue, when I have the backup, I can get my services back online in a matter of minutes by just doing a snapshot restore from one server to another, or from one container platform to another. It enables me to have the highest levels of uptime for my applications. Of course, it's also impacted by the hardware I'm running. I'd rate it a nine out of ten in that aspect.

Standardizing our web applications with Red Hat Enterprise Linux has enabled us to take advantage of automating some of the workflows. For example, previously when I had a mixture of different distributions, if I wanted to deploy a particular setting across all of them, I had to do configurations on each distribution separately, whereas now, all my web servers are running on Red Hat, so I can create a simple YAML script and apply the same configuration across all of them. 

In terms of development also, configurations have been evened, and when you're taking advantage of open-source tools, it even becomes easier. We've integrated some of the native tools, such as YAML, into our CI/CD pipelines, and it's easy for our developers to deploy the same source code across different servers. For example, if you have Application A that is clustered across three or four servers, you can easily use that one single pipeline and do the same configuration across all three clustered servers. It saves us time. We are also getting a bit of quality control because we are sure that the same configuration has been applied to all three clustered servers. It has enabled us to centralize the process of DevOps in our organization.

The first one is security. Initially, the reason for going for Red Hat was mostly around security because our web servers are normally public-facing, but now, all the other distributions have probably also caught up in terms of security settings. 

Aside from security, the advantage of Red Hat as compared to the other distributions is the availability of support and patching. When you have an enterprise subscription with Red Hat, you get support and patching. If you're deploying a new product in the market and you're not sure of its compatibility with Red Hat, you can easily reach out to their support team, and they'll be able to guide you about whether they support that particular product and how far have they gone in terms of testing how Red Hat works with that particular product. For example, we were deploying a new Nginx server a few months ago, and we were not sure whether the latest version was supported by Red Hat. We had a support call and got one of the engineers into a session, who was able to take us through the level of support provided by the Red Hat operating system for the latest Nginx application. Support is very crucial in such cases. Patching is also crucial. In the case of any common vulnerability exposure that has been or can be exploited, you can rely on Red Hat to quickly patch that vulnerability.

One of the reasons for preferring Red Hat is that you can run it on X86-based hardware from Intel or AMD, or you can run it on RISC processors, such as IBM or Sun Microsystems. In terms of portability, it's supported by all the virtualization platforms out there, such as Hyper-V, VMware, and OpenShift for containers. For portability, I'd rate it a nine out of ten.

Deploying clusters on Red Hat, as well as on Oracle Linux, is a bit involving. I'd like them to simplify the setup or at least give meaningful log files to be able to see what's happening at the cluster level. 

It has been close to 10 years since we have been using it in our organization, but personally, I've dealt with Red Hat in production for two years.

It's quite stable. I haven't had any issues in terms of performance and stability with my Red Hat servers. If I have an issue, it's normally a hardware-related issue or a storage-related issue. It's rarely at the OS level.

It's quite scalable. I personally haven't had any issues in terms of scaling Red Hat, be it in a virtual machine or be it through a container. I haven't had any issues in terms of scaling. I do know one limitation they have, but it applies to very few people. For example, the amount of RAM they support does not reach one terabyte. However, I've not had a use case where I needed to have one terabyte of RAM on one particular server.

We have around 20 Red Hat servers. They're distributed across Azure and on-premise. They're normally running web services. Most of the applications they run are accessed by everyone in the organization, and there are 3,000 to 5,000 users.

So far, I've not had an incident for which I needed to take their support. I have not yet contacted Red Hat support.

We were mainly running CentOS, but then Red Hat dropped their support for CentOS. For us, our security posture is highly important. Our major pain point was around patching. Whenever we had any vulnerable web servers exposed to the public internet, we were not able to get patching for any CVEs that were found. That's why we switched our web servers to Red Hat. Patching was Red Hat's main advantage. In terms of security features and control, such as user management and permissions, Red Hat is quite similar to other distributions. I don't see any difference in terms of other aspects. The switch wasn't because of a lack of features, but after switching to Red Hat, we are now exposed to their enterprise features or tools, such as OpenShift. So, our investment in Red Hat was because of their support and patching.

We have deployed Red Hat on-prem on Hyper-V. We've also deployed Red Hat on-prem on VMware, and we also have Red Hat on Azure Cloud. In terms of version, we have everything from 7.2 and all the way to 7.6. We currently don't have any real deployment of version 8 or version 9.

I'm the person who does most of the deployments. The deployment is quite easy. I'd rate it an eight out of ten in terms of the ease of deployment. Deploying Red Hat would be quite easy even for a beginner system administrator because it guides you during the deployment. It asks you whether you want to use a feature or what features you want to install alongside the operating system. Do you want a file server, or do you want a web server? The installation is quite straightforward and simple.

For me, normally the complete configuration from deploying the OS and managing storage, users, and security takes less than 30 minutes. In less than 30 minutes, I'm usually up and running.

We do everything in-house. We don't use any third-party help. Usually, I do all the deployments myself, but I also have an assistant. So, we currently have two people: me and my assistant.

It doesn't really require any maintenance. It just requires occasional patches. That's also handled by me and my assistant.

There is definitely an ROI. Automation definitely reduces the time taken to implement a particular task and the number of employees needed to do the same task. For me, it's majorly in terms of automation, uptime, and availability. The fact that Red Hat is quite portable means that whenever one of my systems goes down, I can easily just take a snapshot and get my services back online. 

Their licensing is quite okay. It isn't expensive, and it's slightly cheaper than Microsoft. Taking into account its features, its price is okay.

Support is something that serious enterprises would want to have. The advantage of running an open-source tool is that you do not have to pay for the tool in terms of licensing, but you don't have support. In certain situations, you might need support. For example, when one of your systems goes down, but you do not have the expertise internally to recover it. Depending on the industry you're working with, having downtime might not be optimal or might be costly. It might even be costlier than paying for the support or licensing of Red Hat.

Apart from support, for organizations that have some of their services exposed to the public internet, security is very important. They would want the patches for the latest common vulnerability exposures found to be affecting the particular systems they are running. So, support and security are the key features why any serious organization should choose Red Hat as opposed to an open-source tool.

We evaluated other options, but they were probably inadequate. We had the option of using AIX, but it wasn't portable for our use case. 

It's normally an issue of balancing the cost of support and the features that you are looking to achieve. If security is number one to any organization, Red Hat is a no-brainer. If support is a key issue, Red Hat again is a no-brainer. If you're facing any security or support issues, I'd recommend going with a distribution that has some sort of licensing tied to it.

I'd 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.

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. 

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 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.

We use the solution internally for developing our software, including running databases and banking applications. These are the kinds of services we provide to customers, as well as our own internal software products.

The solution has helped enormously in terms of development and infrastructure. It enables us to centralize development and improve productivity significantly by providing a stable platform with documentation and best practices for deploying robust solutions.

One of the most valuable features is the ease of consumption and the extensive community-driven resources. The documentation is extensive, allowing users to get started without difficulty. 

Additionally, the support and stability provided by Red Hat Enterprise Linux contribute significantly to its value.

The solution requires a lot of prerequisites and understanding of the Red Hat ecosystem before one can get started. This complexity could be improved. 

More comprehensive support for OpenShift integrations and a less customized, Red Hat-specific setup process would be beneficial.

We have been using the solution for more than ten years.

The solution has been stable. We partner closely with Red Hat, and the operating system has been reliable for a long time.

I am not directly involved with scaling aspects, so I can't provide specific insights on this.

We have been very happy with customer service and support. Red Hat offers prompt support with a good turnaround time, effectively addressing any issues.

Positive

The pricing is competitive. It is not cheap. That said, it provides value considering what it offers.

I would suggest that anyone starting to develop should consider starting with a community-based version, however, for production workloads, it is important to have the support model from Red Hat as it provides stability and quick issue resolution.