Red Hat Enterprise Linux (RHEL) Reviews

The main use case is general system administration, which includes configuring networking, configuring storage volumes, managing users, and running backup applications.

Application performance is one of its main benefits. The applications that run on RHEL are very stable. 

I've not done much work with containers, but with general applications, as compared to other solutions that I've used, RHEL has the best portability. I have not had any issues or application failures while migrating. I've moved virtual machines and systems from one platform to another, and I've never been scared of RHEL. I never had to deal with application failures while moving them from one place to there. That's why I'm pretty confident with RHEL when it comes to working with it.

I like its integrations. I would put it higher than any other Linux version when it comes to availability. Its integrations with different applications and solutions are the best. We work with a lot of clients that use RHEL, and we could easily and quickly integrate any cloud solution, virtualization solution, storage solution, or software with the RHEL system. It is better than the other solutions we have worked with.

I like the way the updates are done and the way packages can be installed through the Red Hat Package Manager. I like it because of how fast and straightforward it is.

Its user interface could be better for people who want to use the GUI. They can provide a better user interface with more features. Storage works perfectly fine. Of course, continuous improvements should be made all the time, but it isn't at all lacking when it comes to storage and other features.

I've been using RHEL for four years, but in the last 12 months, I've used it more.

It is the most stable one. It is very stable. 

It has the ability to scale. I know that it can scale, but because of my limited experience with scaling, I don't know how good scaling is. I have only done the basic scaling, but I would assume that it can scale way more than what I have done.

Most of my usage of it is on a private cloud. I've used it in a hybrid cloud environment, but I've not done a lot of work with the hybrid cloud because most of the clients we work with have private clouds. The little bit of experience I have had with the hybrid cloud was related to basic application installation and scaling. For the scaling part, I was able to have the applications first in the private cloud and then migrate or move it to a hybrid cloud. I was able to integrate them, and I was able to change the environment, as well as have them work in a cluster. The scaling part was seamless. It was pretty easy. It was easier than I thought.

The private cloud is deployed at three locations. The public cloud is deployed across two regions. There are a lot of users of this solution. There are different systems for different applications and different services. I can't put a number on the total number of users. Some systems have 50 and some systems have close to 70. There are systems with just 10 or 5 users.

They can be faster. Because I work in support, I classify support in terms of how well you can resolve an issue and how fast you can resolve an issue. They don't reply fast enough. In a lot of instances, they don't get back to you immediately, and you have to wait for a while after creating a support ticket. They can be faster at that, but when it comes to resolving your issue, they are good. Overall, I would rate their support a seven out of ten.

Neutral

Prior to using RHEL, I was using Windows. I've also done a lot of work with Ubuntu, SUSE, and other Linux solutions, but Red Hat is the best one. I prefer it over other solutions because I'm used to it, and I find it better than other solutions. I'm used to the commands, and it is easy for me to navigate my way through it. If I have to choose between Windows and Linux, I would always go with Linux and choose RHEL because of its stability and agility.

I also use CentOS for my personal things or running some tests. For example, if I want to run a test with a client, it doesn't make sense to run a test in the client's production environment. I have a test environment with CentOS, and I run the test on CentOS before going to RHEL. I'm pretty comfortable using CentOS. CentOS is like my own testing environment.

The reason I switched over to RHEL was that over here, almost everybody or every client who uses Linux has RHEL. So, I had to understand how RHEL works. I realized that most people use it because of its stability. People find this system and its architecture good. A lot of clients talked about how they preferred the architecture of RHEL. Some clients find the commands to be easily readable, and some clients find it easy to integrate with others. A lot of clients find patching and package management pretty easy.

In terms of the deployment model, we have a private cloud. We have VMware for virtualization and Azure Stack for the private cloud. There are also public clouds, such as GCP, AWS, and Azure, and then there is the physical hardware. Some of our deployments are on physical hardware. So, we deploy RHEL on physical servers, and then, there's also the hybrid model when some clients want to integrate the private cloud and the public cloud together. They want the public cloud to be like a backup environment, or they want the private cloud to be a backup environment.

I was mostly involved in the deployment of the hardware and the private cloud.  I was also a part of the team that set up the hybrid environment, but I didn't do a lot of work on the public cloud side. The only complex part of the deployment was the hybrid configuration, where we were trying to interconnect the private cloud and the public cloud. The deployment on the public cloud was more straightforward than the deployment on the private cloud because, on a public cloud, the image is already there, whereas, on a private cloud, you have to set the image up yourself.

Each deployment model took approximately one week to deploy, but the hybrid model, requiring interconnecting the private and public clouds, took more than a week because there were a lot of dependencies.

In terms of maintenance, it does require maintenance. That's the main reason why people pay for support. 

We have definitely seen an ROI. There are around 15% savings.

It is pretty expensive, but it is worth it. Generally, in an enterprise environment, there is no cheap solution. This is coming from someone who is working with a company that provides a lot of solutions a bit cheaper than the industry standard. In the enterprise environment, I believe no solution is inexpensive, but RHEL is still pretty expensive.

Additional costs that I am aware of are usually for support and setup. A lot of banks use RHEL. I've seen the cost of the support and setup. Some of them complain about it, but they also talk about how well it works.

I have not compared the overall costs of open-source competitors to the overall costs of RHEL when it comes to supporting business operations over time. The only other distribution for which I have seen the pricing is AIX, which was a bit more expensive than RHEL.

I would always advise doing a proof of concept where the client gives out his requirements and you run a proof of concept based on those requirements to make them confident of purchasing the solution. It is always better if a proof of concept is done. This way, everybody knows what they're getting into.

Its built-in security features are definitely helpful, but at the end of the day, you have to go further than using the built-in ones. You have to do a few other things yourself. The built-in features are helpful for compliance, but we, and most enterprise organizations, always want to go further than using built-in features because some built-in features could be more open to risks. We use the best built-in features, but we always want to go further and integrate other features into the RHEL system.

I have used Red Hat Insights only once, and I have not worked much with it, but my colleagues handling monitoring used it. It was helpful for the unpatched system. They checked Red Hat Insights and saw the systems that need patching. We got an email saying that it is a security requirement and that we need to patch them because it may affect the security of the systems. Coincidentally, after doing the patching, we read blogs about security hacks out there for some of the older systems that were not patched early enough.

Red Hat Insights provide us with vulnerability alerts, but I am not sure about targeted guidance. Vulnerability alerts have impacted the uptime, which is something that we take very seriously. Uptime was one of the major reasons we wanted to work with Insights because we didn't want any attacks that would cause downtime.

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

Our company uses one of the solution's varieties, mostly CentOS. We are restructuring and moving to the licensed version of RHEL and its derivatives. 

We use both RHEL 7 and 8 mostly in the cloud but also have a small data center where the solution is used on bare metal. Our team does a lot of AIML work where we set up instances to run simulations. 

We are moving a bit into Redshift because we do not have many staff members with containerization or Kubernetes experience. 

We run most things on the solution and its impact has been huge. We do have a few items on Ubuntu but question its use. Conceptually, Ubuntu is for amateurs and RHEL and CentOS are for professional organizations with hardened security. 

The YUM repository is valuable. We are in an interesting situation because we cannot have access to direct YUM or browser repositories so we have to copy to a Nexus server and pull from there. From what we have seen, pretty much everything is available right there. 

The solution's use of Kubernetes as an internal or core process on the system is brilliant. You eventually get to Kubernetes whether via Redshift or other tools and do not have to worry about your hardware because you deploy and push to the infrastructure without worry. 

The Cockpit makes it very easy to maintain systems because you do not have the overhead of running gooey but still have the interface. I am a Linux person and had issues with Windows because they required gooey on servers when it was not necessarily needed. 

The solution is moving away from CentOS and there are growing pains from the customer's perspective. It was purchased by IBM and they are for profit which everyone understands. There is a huge shake up right now because customers who run CentOS do not know what to do with all their systems. One of the reasons CentOS is used for government offices is its security feature that does not change because it occurs after route. The solution placed CentOS in the middle so government customers do not trust it. The way the rollout occurred caused a lot of mistrust with Red Hat. 

The SELinux is great but the Amazon security features cause issues. For example, we run RHEL and CentOS on AWS but they control the cloud and do not give us access to security features. We have to go through multiple layers to deploy an instance. Something that could be controlled with a firewall or blocking ports is now controlled by security groups inside AWS that we cannot access. 

I am newer to the solution but our company has been using it for a long time. 

I previously worked with an Intel customer who used a lot of CentOS, so I am aware in that sense. I am very familiar with the YAM and DNF. I have even played a bit with Rocky which is not specific to the solution. 

My work in systems and software supports one of our teams. 

Technical support staff are personable and quick to get to problems. Support is better than other vendors and I rate it a ten out of ten. 

Positive

I used to work for a government organization that was heavily into AWS. One of the reasons they embraced open source was because Oracle was too expensive. They put everything into AWS rather than open source, so they will soon be in the exact same position where everything is proprietary. 

The solution is easy to set up but sometimes there are issues with custom software deployments. For example, we want to use Ansible in RHEL 8 but the software is only supported in RHEL 7. We question whether we should install an old version of Python to get things to run. 

The solution is pretty easy to troubleshoot. 

Our organization is huge but I handle the setup for instances in our small data center.

I do not deal with money, but I see an ROI in terms of the engineers' skills because they can reapply them to multiple RHELs and incidents. 

The solution is moving away from its open source roots and licensing is a little bit of an issue. 

We use Ubuntu, but not much. 

Primarily, we are dedicated to RHEL and CentOS to the point that we do not see Windows as a viable server option. Microsoft's cloud is getting traction but it only makes sense if you have a solution meant for Windows. 

We also use Redshift and Cockpit. There is consistency across products so they are backward compatible with familiar operations. For example, you could use RHEL 8, YUM, or DNF because the syntaxes are identical.  

The solution is very into Ansible and we are trying to drive everything to it.

Look at the security features of the solution and compare them with other options. Open source is great, but at the end of the day, you need someone supporting the product. Another option is to just listen to groups that write on the internet, but you have to decide if you trust that along with their adversaries. 

Government offices have to worry about adversaries from other countries because the code they use is unclear. The idea of open source is to be able to evaluate the code but it is not clear if anyone actually reviews it. 

I rate the solution a ten out of ten. 

We have warehouse management systems (WMSs) where we run Oracle as our database. The app tier is basically Java. We are using a vendor-supplied Java, and the application itself is managed by the vendor. There are just one-offs here and there, such as utility boxes, but the majority is Oracle and the application that connects to Oracle.

On larger systems, like HANA, we have it deployed physically. On everything else, we have deployed it in a VMware environment. It is all on-premises. While there is some cloud, that is being done by contractors. 

We are on versions 6 through 8. As soon as version 9 gets released to GA, I am going to start working on getting that image ready. Currently, about half our images are on version 8, two-fifths are on version 6, and then version 7 is squeezed in-between.

The solution provides features that help me tweak or configure the operating system for optimal use, such as Insights Client, which I have used quite a bit to help me.

Our users are removed from the environment. They don't really know that they are running on RHEL. There have been very few complaints about speeds, application, or stability on RHEL platforms. Whereas, on Windows platforms, there are a lot of complaints.

Satellite 6.10 and RHEL integrate with each other perfectly. This integrated approach enables me to be a single person managing my images since it does a lot of the manual labor that I used to do, such as building patches, doing system maintenance, and keeping systems consistent. It does all that stuff for me. So, it has offloaded those responsibilities, giving me more work-life balance.

It is a bit on the pricier side. However, due to the stability and support that they provide to my management and me, we really don't see a reason to choose another way to go. Red Hat offers excellent support in a sphere where it is difficult to find good support.

I have been using RHEL since 2013.

It is a good operating system. It is very stable. It does not take a lot of maintenance. You set it up well and it runs. To give some perspective, we also have Windows admins. That team is about six people and growing. They manage twice as many servers as I manage, keeping them busy all the time. Whereas, I pretty much have a life; the work-life balance is very good.

RHEL is very stable. You build an image and deploy it, then it runs.

As far as the operating system contributing to reliability, it is very stable and has low maintenance. It keeps running.

We found that two of our outages in the past eight years were related to the operating system. All our other outages were related to the application and the use of the application.

I don't find the solution’s tracing and monitoring tools impact performance at all.

We can scale out. When we need more machines, we just build more machines. That is not a problem. We don't do the scale ups or any of the other scaling that is out there. That is partially because of the way our applications work. You need to scale according to the application. If the application requires new nodes, we just spin up another node and it is no problem. I could run 10,000 images, and it is not a problem.

Because we buy companies, we will probably continue to increase the usage of RHEL. I don't think that will be a problem because it is so stable. We are running about 200 images right now and about 60% of those are in production. I can't see it shrinking, but I can see it growing.

I like the fact that they really dig into things and then provide answers. As the single Linux guy, I kind of need that second admin next to me sometimes to say, "Hey, what about this?" and I am able to do that through the portal. I get my questions answered and trouble tickets resolved.

The technical support is superior to many vendors with whom we interact. They pay attention. Rarely will I run into a support person who doesn't seem to know what they are doing, then it doesn't take very long to get the issue escalated to somebody else. Out of a hundred cases, I have probably escalated three times. I would rate the support as 10 out of 10.

Positive

I came from a Unix background. I was on HP-UX on OSS and AIX. So, the transition to Linux was very simple. I am a command line person, so I wasn't scared. I just moved into it and found it to be very attractive. In fact, I don't run GUIs on any of my Linux boxes.

The biggest benefit for me, coming out of the Unix arena, was that it matched Unix very closely. So, I am able to draw on my Unix experience and use that in the RHEL environment. There is almost a non-existent learning curve in my situation.

The initial setup of RHEL is about 10 times easier than Windows. It is literally just click, click, bang. It just installs. If you have a problem with the install, you just reinstall it. It takes very little time to install, about 10 minutes. As a base image, it is very easy to set up. Then, you have post tweaks that you need to do, and I have scripts for that. Since I can script it all, I just run another command, then boom and it is all done.

For my implementation strategy, I build the gold image, which is basically just going through the CD and making my selections for a base image. Then, I freeze that image, which is on VMware, and run my scripts. My scripts basically set up logs for auditing. Whether we are going to ship logs or keep logs locally, it sets up the basic users. For instance, it will set up my account with pseudo access so I can do the remainder of the work using my account with pseudo access. It sets up tracing, the host name, IP addresses, and ESXi host files. It sets up the basic fundamentals of an operating system and gets it ready for deploying the application. 

There are also different kinds of file systems that need to be deployed and additional users that need to be added. Those are all manual processes.

We have one admin who manages all the images. That is the return on investment. The company hasn't had to hire a second admin (FTE) to keep things running.

We have moved to the Simple Content Access (SCA) model. It is much easier to do renewals and see how I am using my licenses. I used to have to do it all by hand. It would take me a good couple of hours every few months to make sure that we were up to snuff on everything. However, with the new model that they have, this is very easy. I just go to cloud.redhat.com to look and see how I am utilizing my licenses. If I am running out of bounds, I can find out why. If it is simply that we have images that need to be removed, we remove those images. If we need to buy more licenses, then we can start the process of purchasing more licenses.

I think it is worth the price. I wish the pricing was a little bit more friendly, so when I go to my boss, he tells me, "That's too much money." I can say, "It's not too much money."

Especially if you are a newbie, buy the support and use the support. Get a couple of images going and really play around with them: crash them, burn them, and figure out how support functions when you have a really gnarly situation. Otherwise, it is just inserting the CD and booting the machine. It is very easy to set up and run.

I have looked at SUSE or Ubuntu. They are so radically different in their total management, e.g., everything from getting packages to configuration and in how that is all done. Therefore, it would be a learning curve to go to another solution. So, there is benefit in staying with RHEL. 

I do not have a lot of experience with Ubuntu or SUSE. Those would be the bigger contenders. The thing that I keep coming back to though as I'm talking to vendors and VARs is that though SUSE is a contender out there in the SAP landscape, RHEL has the stability. SUSE appears to function more like a desktop operating system ported to a server environment, whereas RHEL is built from the server hub. The management tools show that. It is a mature management infrastructure.

There are some things that are nice about SUSE. People talk about their app configuration wizards, but if you're coming from a Unix background overall, RHEL feels like a real operating system.

My interaction with Ubuntu has been as a desktop. It is very GUI-oriented. In my estimation, it is more like a toy. It is deployed in server environments, but it is more because admins are familiar with the desktop version of it. They just port that over as opposed to having grown up on Unix and moved into Ubuntu.

A Unix admin will prefer to go into something like Red Hat, Rocky Linux, AlmaLinux, or even Oracle Enterprise Linux because they will simply feel much more like a data center operating system than some of these other solutions.

RHEL provides features that help speed deployment. I am currently learning how to take advantage of those features.

As far as deployment goes, I build a golden image VM and just deploy the images themselves. I don't really use any RHEL tools specifically for the deployment portion.

The solution is constantly expanding and moving into new areas, like jumping into the cloud.

I need more experience with their self-monitoring tools. That is the one area where I feel like I am lacking. I am still using a lot of the stuff that I learned in the Unix realm. I haven't really matured into using the specifics that are being supplied. I am a member of the accelerators team and have been exposed to some of these tools through their lectures. I am starting to play with them a little bit, but I have not fully gone into that arena. So, there is improvement needed on my access to RHEL.

I would rate the solution as 10 out of 10.

My customers primarily use Red Hat Enterprise Linux for application hosting and small databases. It is used for hosting Java applications and small web servers.

Cloud-based Red Hat Enterprise Linux deployments provide cost savings. If customers are purchasing a physical server, they need to have a proper setup. They need to have a data center, cabling, and a lot of other things. For cost-saving purposes, they are going for a cloud. As an operating system, it offers the same functionality on-prem or on the cloud.

It saves money for company owners. It helps our customers save money and do things quickly. They can build servers quickly. There is a menu where they can fill in the VM name and other details and attach storage. In ten minutes, they have a server ready.

I am Red Hat certified. I train people in corporations and educational institutes. Red Hat's material is very good. Their testing system is awesome. If someone is certified in Red Hat, you know that they know it well. There are millions of videos on YouTube, but they are not always updated. On the Red Hat site, the documentation is very clear. You just need to focus and study for two to three months to get certified.

Nowadays, delays are common with their support, and it often takes time to get assistance from experienced engineers.

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

Red Hat Enterprise Linux is an excellent product, and its stability has improved significantly over time. It can operate for extended periods, like six months to one year, without issues.

Red Hat Enterprise Linux scales well with increasing user demands or infrastructure size. It is easily available and efficiently adapts to varying needs.

Most customers host medium-sized applications on the cloud. Storing a big application can lead to higher costs.

The technical support from Red Hat has declined over the past four or five years. It could be because there are not many skilled people. When we raise a case, it is attended by junior people or new people, which wastes two to three days. We might even have to raise the severity of the ticket. However, when senior people take ownership of the case, the support is awesome. They give proper support. This was not the case earlier, so whenever we raised a ticket, we got an immediate response from Red Hat.

Positive

The initial setup is smooth.

We have Cloud-based deployments. We are using AWS, GCP, Azure, and other cloud platforms. We also have on-premises deployment. Some customers also have a mixed deployment with the cloud and on-prem but in such environments, I have seen problems in terms of performance. For example, if my database is on-prem on Red Hat Enterprise Linux, and I am storing my application on the cloud on Red Hat Enterprise Linux, whenever someone hits the website, there will be latency issues. I sorted out such issues for a customer. I suggested they migrate their server from the cloud to on-prem because their database was quite big. With a mixed setup, they were having a lot of issues in terms of performance and storing data. It was very slow. After they moved it on-prem, it was much faster. This is not a Red Hat-related issue. From the operating system side, no improvements are required. However, cloud providers need to improve their facilities.

For patching, I use Red Hat Satellite, and for configuration, I use Red Hat Ansible. Leapp upgrades are also awesome. A month back, I upgraded Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9. I created detailed documentation about the procedure. There were about 14 steps. It was straightforward.

With Red Hat Insights, we can see the security threats. Red Hat Insights is integrated with Red Hat Satellite. It will be helpful from the patching point of view. It lets you do subjective analytics of servers.

I did some research on pricing a long time ago, and at that time, it was much cheaper than Windows. I do not have current details about pricing, but it is affordable.

Overall, I would rate Red Hat Enterprise Linux a ten out of ten.

Our use case for Red Hat Enterprise Linux is for production applications. 

We are a Managed Service Provider. Red Hat Enterprise Linux enables us not to be worried about vulnerabilities, security, and patching.

The most valuable features are the subscriptions and upgrades. 

We need to have more flexibility on the developed versions. Not everybody is ready to subscribe to enterprise versions. They would like to test the tool without subscriptions. 

We chose Red Hat Enterprise Linux because of its security. 

We use Red Hat Enterprise Linux with AWS. We started our practice with AWS, and most customers use it instead of GCP or Azure. We use the product in a hybrid environment, mostly when shifting the containers or existing workloads from legacy systems. 

Most of the customers use Red Hat Enterprise Linux because it is the only approved OS. The tool's knowledge base is good but is limited to subscriptions. 

The upgrade migration is straightforward. For the initial projects, we used to execute CLI scripts. We plan to upgrade the system if everything works well in the lower environment. 

I have used the image builder feature. I rate the overall product a nine out of ten. 

We primarily use it for OS purposes. 

It's very good for support compared to other operating systems. For decades, it's been providing good support and service. Even during implementation, there's a dedicated team to answer any queries. We are a very big company running critical applications and having that support is very important.

The patching tool is good. We're also introducing the possibility of automation.

The built-in security features are okay when it comes to simplifying risk reduction. It makes life easier, especially in regards to the lifecycle and what we need to install, et cetera. The features and tools help us to maintain security overall. 

It is easy to maintain compliance.

The portability of applications and containers is good. Now we are just starting with the containers and anything related to Kubernetes. 

Red Hat is always providing security on time. Any vulnerabilities are immediately dealt with to fill the gap and deal with the issue.

It's a good tool. I'm very confident with this product.

The system role features for automation security configurations, et cetera, for Ansible, we started using it. We are new in terms of automation. We'll start to use it heavily in the near future. Ansible is another great tool from Red Hat.

It enables us to maintain consistency across systems over time. My role is to maintain stability, even during upgrades and patches. So far, it's been a positive experience. We use the entire ecosystem around Red Hat.

We use Red Hat Insights. From a security perspective, we may stop using it. With Insight, if you have Red Hat Satellite, it gives you an in-depth view of everything. The only thing missing is the insights related to performance. We may not continue with it. We'll see if we'll push it and have everything on the cloud. 

In the area we are using it, we are satisfied.

Maybe in OpenShift, which is our next step, there can be more improvements with integration with Kubernetes. We're not experts there yet. 

Maybe it could have a better user experience and less coding. Reducing the effort for the end user or administrator would be ideal to make daily operation and maintenance easier. 

If they can make the integration with Ansible easier, that would be ideal.

They should offer more in terms of learning materials to make learning easier. 

They need to make things more affordable or accessible. 

The solution is stable. We barely have any issues with a server setup. So far, it's manageable. The biggest challenge is the criticality of releasing patches. When we have any critical alerts we action them. We tend to try to wait for the release of a stable version. 

How many people use the solution depends on the application. We likely have thousands of users. We do have some products that maybe only have a few or a few hundred. 

We've had no challenges with scaling. It can support any type of load within the data center. 

Support is excellent. 

Positive

We did use a different OS. I have used Unix in the past. I started with Unix 30 years ago. I've also used SUSE. Red Hat offered more service and support. 

I was involved in the deployment. Our team managed the process. It's pretty straightforward. We handle implementation, tuning, and patching. 

How long it takes to implement the product depends. We're trying to mitigate the time by automating with Ansible. We want to handle one VM or server in five or fewer minutes, however, it can take days. At this point, we can provision servers in a few minutes. It's becoming faster. 

We have a team of ten to run the infrastructure on the OS level. 

I'm not an expert on ROI. We are paying to use the solution, however, the utilization we get and the support both offer good value. 

The pricing model isn't something I deal with directly. The pricing is fair, especially compared to virtualization like VMware. We do use VMware and are thinking about moving sandboxes and testing over to Red Hat. This may end up being a big cost savings with our CAPEX and OPEX. 

From the price level, the cost is almost the same for us, if we look at Red Hat versus SUSE, however, we get a higher level of support with Red Hat. 

Red Hat was always our first choice. 

We're a Red Hat customer. 

I'd rate the solution nine out of ten. 

We are a telecommunications operator using Red Hat Enterprise Linux for our technical applications due to its supportability and robust management features.

Red Hat Enterprise Linux's built-in security features aid in simplifying risk reduction. In the past, patches fortified the security features, but now, with playbooks, we can automate and address any findings for any Common Platform Enumeration. When integrated with Red Hat Insights, the solution can identify the CPE and provide the remediation playbook. This expedites detection, remediation, and testing by Red Hat, thanks to the playbooks provided by satellite as well as malware detection.

Maintaining compliance with Red Hat Enterprise Linux is easy because it supports various out-of-the-box compliance policies, such as CIS. Whether we are running OpenSCAP on-premises or Insights, we can perform compliance testing using OpenSCAP to verify adherence to the Red Hat Enterprise Linux security guidelines, as well as other well-known guidelines and framework compliance. I have found that all the compliance policies I required were already included out of the box.

Red Hat Enterprise Linux is ready to help keep our organization agile when it comes to the portability of applications and containers because all the applications are developed by the vendor. Red Hat Enterprise Linux is the preferred choice in our industry because the applications we use are swiftly certified by the vendor, so we don't have to verify them ourselves.

Red Hat Enterprise Linux provides enhanced security for our servers, and we are aware of patching requirements in advance. Additionally, the pre-certification of Red Hat Enterprise Linux applications expedites deployment as we no longer need to go through the certification process ourselves. Moreover, Red Hat Enterprise Linux offers excellent support, ensuring that any issues that may arise are promptly addressed, which is crucial for our environment where we must maintain an uptime of 99.99999 percent.

Red Hat Enterprise Linux enables us to achieve security standards certification because it is driven by various compliance policies that include everything we need out of the box. This makes it easy to enforce security rules, and security patches are applied regularly. With Insights, we have malware detection, CPE filings, and remediation capabilities. In addition to the reactive approach, we also benefit from a proactive approach, allowing us to stay informed about the events around us, which helps us implement temporary solutions if needed until a permanent fix becomes available.

With Red Hat Enterprise Linux, we can build with confidence, knowing that it is available across physical, virtual, and cloud infrastructures. The operating system provides certifications, ensuring that we can deploy with 100 percent certainty, knowing that the applications will work. Additionally, it offers identity security and excellent support from the Red Hat team. Without this support, we would have to rely on searching within the community and downloading untested patches, which may function in small environments but not for larger ones with sensitive applications.

Red Hat Insights helps us prevent emerging issues related to security or noncompliance settings. One of the steps we take before going live is using OpenSCAP to ensure compliance with our standards. This is followed by our own security scanning and verification process. If any issues are not known within Red Hat, we can always refer to all the findings. Once the system is in production, regular monitoring allows us to use Insights to identify any new findings and apply necessary patches or workarounds. The knowledge base available on the servers enables us to take proactive measures even before a security patch becomes available. The new malware detection feature in Insights helps protect end-user information.

Insights provide vulnerability alerts and specific guidance. With each system, we can view the detected Common Platform Enumeration and receive advice on how to address it. These features have protected our systems from potential attacks, thereby increasing our uptime.

Red Hat has introduced a fast server, where Red Hat Enterprise Linux can be integrated or connected to via a client. This connection allows us to identify numerous vulnerabilities in malware easily and facilitates simpler patching. Activating the Red Hat addons on this server creates a perfect match when seeking a well-hardened OS using the gold image, as it eliminates the need to address issues from an existing image. Additionally, Red Hat Insights is a valuable and essential tool. In the telecom industry, we rely on basic products that necessitate an OS with robust security support and regular patches. 

We have not succeeded in creating an image from Red Hat Insights for Red Hat Enterprise Linux, including custom partitioning and custom scripts. This would have been helpful.

Red Hat Insights reporting can be enhanced by incorporating performance components, making it a central tool for vulnerability assessment, compliance monitoring, and much more. The performance component is available on Red Hat Enterprise Linux, but we need to maintain the dashboard on-premises, which requires us to switch between systems instead of performing all tasks from a single location.

Managing the destination for netting on the Netserver using Red Hat Enterprise Linux could be made more user-friendly.

I would like to have enhancements in the data files to help with deployments.

I have been using Red Hat Enterprise Linux for over ten years. I started in 2012 using version five.

Red Hat Enterprise Linux is stable.

Red Hat Enterprise Linux is scalable, but the scalability is achieved at a different layer compared to adding memory to a virtual machine or container.

Compared to other support departments for Red Hat products, the Red Hat Enterprise Linux support team stands out as one of the fastest, most cooperative, and understanding teams.

Positive

The initial setup is straightforward. In the past, it was complex when Red Hat acquired Ansible because many of the modules were community resources that lacked full support. As a result, creating a playbook to deploy the OS was a painful process, as there was a chance it would not work, and we would not have the necessary support. However, currently, deploying Red Hat Enterprise Linux is easy. We have never deployed only one operating system at a time, but it would take less than one hour to do so.

I would rate Red Hat Enterprise Linux an eight out of ten due to the complexity of its network boost management issue.

We have Red Hat Enterprise Linux deployed in one location.

Red Hat Enterprise Linux is used in our environment to run the application for all of our customers, and only around ten people have access to it.

Red Hat Enterprise Linux requires maintenance for applying new patches, releases, and debugging. 

My organization has different departments. In my department, we mostly work with containerization. I am using Red Hat Enterprise Linux as a part of OpenShift. I use the basic package and base image of Red Hat Enterprise Linux.

For scale-up in our platform, we use CoreOS as the master, and for the workers, we use the Red Hat Enterprise Linux service. From OpenShift version 4.10 onwards, we cannot use Red Hat Enterprise Linux 7 worker nodes. We were using Red Hat Enterprise Linux 7 worker nodes, so we upgraded to Red Hat Enterprise Linux 8. 

For OpenShift, there are some recommendations from Red Hat in terms of what needs to be used for the control plane and what needs to be used for the worker nodes. When you are using CoreOS and Red Hat Enterprise Linux worker nodes, there are some difficulties in managing them. For example, when you upgrade OpenShift, you need to upgrade two times. The control plane is upgraded separately because it uses CoreOS. The control plane has a lot of certificate updates that will in turn be updated on the worker nodes, so you have one restart of all worker nodes, and then when you need to upgrade your worker nodes, there will be one more restart. 

Overall, you have two reboots in your production environment, which is an issue, but it is related to your choice of product in your environment. We have this issue because we opted to use Red Hat Enterprise Linux 7 or Red Hat Enterprise Linux 8 worker machines, whereas Red Hat recommends using CoreOS because it is pretty fast in terms of rebooting and functionality. When you upgrade the control plane, that itself will update the worker nodes, so you are done in one shot. When you need to upgrade your Red Hat Enterprise Linux machines, you need to use the Ansible Playbook. You can then upgrade to Red Hat Enterprise Linux 7, 8, or any other version. Regardless of the versions, you can upgrade the operating system and the OpenShift version. For this purpose and for some ad-hoc activities, we are using Ansible Playbooks.

For us, its security, management, stability, and hardening are most valuable. All of these features are better in Red Hat Enterprise Linux as compared to Microsoft Windows.

Red Hat Enterprise Linux is very good in terms of risk assessment. It is also good for maintaining compliance. It is better than Microsoft Windows.

From the administration perspective, I do not have any issues with Red Hat Enterprise Linux. For me, it is more convenient than Microsoft Windows.

My organization has been using Red Hat Enterprise Linux for a long time. They have been using it before I joined the organization.

It is pretty good in terms of stability. It is a stable product. I would rate it a nine out of ten in terms of stability because sometimes the packages can have bugs.

Its scalability is good. I would rate it a nine out of ten in terms of scalability.

We never encountered any issues while using OpenShift.

I have mostly been working with Red Hat Enterprise Linux. 

I have been involved in the deployment of OpenShift. It is pretty straightforward. We just need to get the licensing, and we just need to create a pool for our containers session in Red Hat Satellite. We can do the configuration from there. It does not take long because we are adding the nodes to OpenShift. During the scale-up process, we only need to subscribe to the nodes with the Red Hat subscription. It does not take much time. If we have a good spec, the scale-up would not take much time. It would take less than twenty minutes. It is pretty fast.

In terms of maintenance, when we have the bug report, we need to do the security assessments. Over time, there might be some bugs related to some packages. At that time, if it is critical, we will be scheduling a maintenance activity on our platform. 

Red Hat provides high availability from the application perspective. You get high availability when you are using OpenShift, so when you are doing a maintenance activity on the OpenShift side, there would not be any downtime. The high availability is very good. For the end-users, there would not be any application outages if you configure your application with proper replicas. They would not even realize that there is a maintenance activity happening to the underlying workers.

It was implemented in-house.

We did not evaluate other solutions. Red Hat Enterprise Linux is the choice of most of the companies.

If you want to integrate with OpenShift or build an OpenShift cluster with the master Red Hat Enterprise Linux and worker Red Hat Enterprise Linux, you can do that, but you need to plan your upgrade or maintenance activities. It would be better if you choose CoreOS for both. CoreOS would be a better choice in terms of maintenance activities or upgrade activities in the future. If you cannot afford that, you can go with the Red Hat Enterprise Linux operating system, but you need to do two upgrades. You first need to upgrade the control plane and then you need to separately update your worker nodes. That is the only thing you need to keep in mind.

I would rate Red Hat Enterprise Linux a ten out of ten.