Red Hat Enterprise Linux (RHEL) Reviews

We are mostly using it for application servers, infrastructure servers, and database servers.

Red Hat Enterprise Linux lends itself to a lot of automation. We are able to manage many more servers with less staff and by using other Red Hat products such as Ansible. Those are the things that I like.

We are using Red Hat Enterprise Linux for containerization projects. Their Podman product has made it easier. It comes with a lot of security. It is a drop-in product or replacement for Docker. I have used Docker before and switching to Podman was very easy. I just saw the demo for the Podman desktop, and I am looking forward to using that. It will hopefully help me streamline container usage and container deployment in Kubernetes or OpenShift.

It inherently has a lot of functions built in for risk reduction, business continuity, and maintaining compliance. For example, it has SELinux, certain firewalls, logging, and all those things. It has all the built-in features required to meet the needs. We can plug in other third-party tools to have it gather information, or we can send logs to centralized locations to track activity and do audits and things like that.

I use Red Hat Insights for different things. I do not use it much to look at security risks. I know that it has those features, but I use a different tool like a Satellite server to take care of patching and things like that. Red Hat Insights provides us with vulnerability alerts and targeted guidance, but it has not affected our uptime much. It is good to see that information. I can see those vulnerabilities, and I can see action steps or remediation steps that I can take. All my servers are patched on a cycle, so as the cycle goes through, each server gets patched based on its own cycle. It does not really affect the uptime.

I like the stability that comes with Red Hat. That has always been the feature that I like. They do not always have the newest features, but they prioritize stability, which is important in the production environment.

Red Hat should keep doing what they have always done. They should continue to be a leader in the open-source space. They should keep innovating and keep creating great products. They can allow more access to their training and their products' testing. There are ways to do it now. You might have to get a certain type of account to test their products. It might be easier if you can just download the product and test it out.

In a production environment, I have been using Red Hat Enterprise Linux for about five years. I have used Red Hat Enterprise Linux clones such as Fedora and CentOS for about 15 years or maybe longer.

It is absolutely stable. It is 100% stable.

It is good. It scales well. With the tools that Red Hat provides, it does not matter if you have 10 servers, 100 servers, or 1,000 servers. They make it simpler with Ansible. Ansible is your friend.

They are top-tier. Support is probably their number one selling point. As long as you give the Red Hat engineers what they need, they are very good at providing new solutions. I would rate them a ten out of ten.

Positive

I have used Red Hat clones in other positions. I might as well just say it is Red Hat because it is a clone, so I have been using Red Hat all along if we look at different products.

I have worked with CentOS, Rocky Linux, etc. The main difference is that Red Hat's support is top-tier. There is also stability. With the ecosystem that they have built, there are a lot of tools to help me manage. They have Ansible and other great tools to help manage the product. You cannot say the same about Windows. They might have a different way of doing things.

We have deployed Red Hat Enterprise Linux on-premises. We have a hybrid cloud environment, but we run other types of servers there. They are mostly Windows, and they are run on Azure cloud. We do not run Red Hat Enterprise Linux in a hybrid cloud environment, but there is always an opportunity to do that in the future.

The Red Hat servers that we have are on-prem. We use VMware and the tools that they provide to deploy Red Hat.

Its initial deployment was done a long time ago. It is a straightforward process to install it as long as you are not trying to do anything complicated.

We do not have a deployment strategy. We install it based on the requirements. If it is a web server or database server, there are different things that you need to do, but it is pretty straightforward. It is a good process.

We took help for deploying Red Hat and purchasing the license and maybe the hardware. We probably used CDW and Advizex. They are probably based in Pittsburgh.

Time savings is the biggest return on investment. I can do more in less or a shorter amount of time. The time savings depend on what you are working on, but you can potentially have about 75% time savings.

I have very little experience with pricing and getting quotes. The whole VMware thing happened, and everybody is looking at different alternatives. At this point, any competitor is probably a good choice based on the cost.

Everyone should evaluate what their needs are, test out different products, and pick the product that is best for their needs. I know that the Red Hat Enterprise Linux is a very good solid product. One thing I would say is that their support is top-tier, so from that aspect, I would recommend Red Hat.

At this time, I am trying to develop a platform that facilitates developer workflows. We may adopt more of a GitHub mindset and use Red Hat tools, such as OpenShift and Ansible.

We are currently not using containers as much as we would like to. We are working on setting standards. That is going to come down the road. Our workloads right now are mostly virtual machines and monolithic applications built on VMs. We will use them more. We will make more microservices and use pods to contain the applications. We will use more Red Hat tools.

Overall, I would rate Red Hat Enterprise Linux a nine out of ten. There are many things to take into account. From a production perspective, it is a ten out of ten. From the innovation and latest features perspective, it is probably a seven. That is not necessarily a bad thing because that is their unique point. They prioritize stability, but if you want something with your features, you can use Fedora.

I use the solution in the company to build a lot of our software environments, so we keep different baselines on it. Right now, I'm working on setting up and installing Ansible manually, so I haven't used Red Hat Ansible Automation Platform yet, a reason why I have been still using my Red Hat Enterprise Linux (RHEL) server.

In terms of features, I found it great when I talked with Linux subject matter experts about Ansible. They further mentioned that it was native to Red Hat, which is why it wasn't going to bring over more packages or modules. The packages or modules in the tool are already there but are just not enabled because they weren't being used before I asked about them. It is super easy to enable the tool's packages or modules when I want to start messing with it.

Red Hat Enterprise Linux (RHEL) has helped me centralize development because it has a standard, which is why my company can't really have the option to mess with its different technologies. Our company's customers don't want to use Ubuntu or any other such operating systems, which is why my company has to use Red Hat Enterprise Linux (RHEL). I guess the tool is easily centralized because that is its standard, and that is the only option one has unless someone wants Windows, but again, developers don't want Windows, and so there are no other options.

Our organization has a team to take care of the containerization part. I am mostly on the infrastructure side, but my company has started to ask me for Podman Desktop and all these different container platforms, and I haven't used any of them yet.

If I dissect the built-in security features of Red Hat Enterprise Linux (RHEL) for risk reduction, business continuity, and compliance, I would say that we use VMware for risk reduction so that we have a high availability. On the top of my head, I think the Linux team probably knows more about reducing risks. Our security team has all these STIGs they want us to apply, so I don't know how much manipulation they actually have to do.

If I dissect the built-in security features of Red Hat Enterprise Linux (RHEL) for risk reduction, business continuity, and compliance, I would say that we use VMware for risk reduction so that we have a high availability. On the top of my head, I think the Linux team probably knows more about reducing risks. Our security team has all these STIGs they want us to apply, so I don't know how much manipulation they actually have to do. For business continuity, my company uses VMware, considering the ease of making snapshots of our environments, but I believe we could probably do the same with different operating systems. In our company, we just take lots of snapshots, and then if we have another VMware instance, we could just build it right back. The only compliance I know about was associated with our company's customer and their STIG requirements, but I don't know how Red Hat Enterprise Linux (RHEL) helps with it, especially considering that in our company, we have to manipulate it and how we want to do it.

In terms of the portability of applications and containers built on Red Hat Enterprise Linux (RHEL) to keep our organization agile, I would say that we have an applications team that would do it in our company. I just make sure that our company's VMs have OS and network connectivity since there is a different team that takes care of the applications.

Right now, since my company is in an air-gapped on-prem network, it is really tough to go through all the RPMs that we have to have based on different STIGs. Whenever in our company, we have to install the tool, we see that something or the other is missing, and so of the hundreds of things mentioned in the list, we have to find whether we need a particular RPM or if we need to take this one out, and that is always a trouble for the team managing Linux in our company.

I have been using Red Hat Enterprise Linux (RHEL) for more than five years.

When I spoke to one of the speakers the other day, who was a software development manager, I was told how much one could trust Red Hat Enterprise Linux (RHEL). I believe that Red Hat Enterprise Linux (RHEL) is considered a standard for a reason.

I believe that if you have enough license to support the product in your environment, then you can scale the product depending on how big your license is, and it is a super easy process where one can roll out a whole bunch of VMs and VMware.

As my signature block comes with Lockheed Martin, I think the tool's support team has been pretty attentive. If I go to a wide-scale service and once Red Hat Enterprise Linux (RHEL) sees what kind of a customer I am, I get to go to their specialized sectors, and the support has been pretty fast. I have had no issues with the product's support team. I don't use the product's support services very often. I have mainly dealt with Red Hat's support team for Ansible. I rate the technical support a seven out of ten. When I was asking the tool's support team questions when I was off the internet, I just kind of felt weird about it. For any service I ask for from the support team, I have to manipulate it depending on what we need for our company.

Neutral

I have not previously used any other product, and I have worked for the government for the past twelve years using Red Hat Enterprise Linux (RHEL).

The deployment of the product has been super easy, but when we do it through VMware, I just make a VM, and then load an ISO image, after which the deployment is done. The tool's deployment is super easy, and I am pretty much a novice when it comes to Linux.

The solution is deployed on an on-premises model.

My company did not seek the help of a third party to depot the product. The deployment was carried out by our company's employees, who have been around for decades.

The government buys the product for our company and provides us with the license for the solution.

For a colleague who is looking at open-source cloud-based operating systems for Linux, I would say that Red Hat Enterprise Linux (RHEL) is a cool product for small businesses outside of the government. I work for the government, where Red Hat Enterprise Linux (RHEL) is the standard, so if my colleagues are in the government, I would tell them they have no other options.

I am not sure about the product's deployment model since it is kind of ad hoc in nature. If a developer needs another VM, our company just provisions it through VMware, so we don't have a large-scale deployment model across different availability zones. We have our program, after which we wrap it all up and then ship it out to the customer.

As I have not compared Red Hat Enterprise Linux (RHEL) to any other operating systems in the market, I rate the tool a nine out of ten.

We first used it for application installation to run applications on Windows. We had it running on Windows. We then upgraded it. It was still on the IBM platform, but it was still x86. We have now updated it, and it is now running on IBM Linux Z.

We use it for Internet banking, core banking applications, and other peripheral applications.

It has helped with consolidation. When we first started to do clusters, we were using Oracle cluster and Red Hat cluster. The Red Hat cluster was more stable than the Oracle cluster, so we had to uninstall the Oracle cluster and just use the Red Hat feature to have floating IP addresses between two cluster nodes. Having it in a cluster was the single most useful application of Red Hat in the environment.

We use Red Hat Insights, Ansible, and Satellite. Red Hat Insights is helping us big time. A year ago, I was looking at bolstering my team to about five or so administrators. With Red Hat Insights and other tools, I am satisfied with just two administrators. They are there just to manage the system and not necessarily go down into the trenches.

It seems that Red Hat Insights provides vulnerability alerts and targeted guidance, but my team would know that better. I manage a team that does that.

Its stability is most valuable. Its administrative aspect is also good. It is relatively easy to administer. I am familiar with AIX. AIX is super easy. I did not have to struggle much to adapt to Red Hat.

They can make the extended file system dynamic. Currently, we have to bring down the server to add an Hdisk. We cannot extend the database on the fly. We have to have downtime. We want to ensure that we make the blackout periods as minimal as possible. Currently, there is a gap in the file system management. I want to be able to expand the file system in a simpler way and have the application or the database use that expansion without any downtime.

I have been using Red Hat Enterprise Linux since 2004. It has been 20 years.

There is no problem with stability. It is stable. We have a couple of Red Hat Enterprise Linux 4 still running. We also have Red Hat Enterprise Linux 6 systems. The hardware is functional, but the application was retired. We cannot get an update for it. It has been running since 2008.

Its scalability is fine. There is no problem with scalability. We can do it in real-time. Now with containers and other things, we can scale on the fly without much downtime. We can build a small system and scale it. We can start at a much lower level than several others.

It has improved tremendously. I remember when it used to be centralized. I have been to North Carolina to get training, but now they can come to us for the training. The whole support architecture has improved. We can reserve hours for calls when the need arises. If we do not use it, it is reallocated the next month to some other project. They are doing well. I am impressed.

Positive

We were using and still are using AIX, but most of the applications have been imported, so we are between AIX and Red Hat. We are also using Windows, but Red Hat has stood out. It is not yet there with AIX, but it is getting there.

We were using Ubuntu and a few other flavors, but they were not organized. They were still too open. The support and the training for Red Hat Enterprise Linux was spot on. It was exemplary. We could find support easily.

We have them in clusters, and we also have standalone ones. We have DR where we synchronize with DR. We synchronize at the file system level with DR, which eliminates some of the application limitations.

We are using it on-prem, but we have applications to be upgraded in another 18 months, which would be a hybrid cloud.

Its installation the first time was overwhelming. Once you get used to it, the team settles down, and you have knowledgeable people, it is a breeze.

We have an integrator, a reseller, and a consultant. Somebody would come in and help us connect the dots. I guess that is their reseller, and then the integrator helps us properly connect the dots.

Pedro is our accounts manager. He probably comes from Puerto Rico, and then there is Lincoln Walters from Jamaica. Together, they help us identify the resources we need for the things that we want to do.

The biggest ROI is in terms of the reduction of human resources required to manage and maintain it. The administrative duties have been vastly reduced. You can even have resources from Red Hat. They have something where you can block certain hours a month and you can just use them as needed. If you do not use them entirely, you can reallocate them. That means you can reallocate unused resources. There are savings on investment.

We are still learning about it, but our TCO has reduced because we do not have to have as much manpower, hardware, and processes to manage and operate.

Licensing is the most attractive part of it. With Red Hat Insights and Ansible, we now know that it was done with the intention of simplifying the licensing so that you get the support for what you have and not necessarily what you want to have.

Red Hat Enterprise Linux has not helped us to centralize development. We have not capitalized on that as yet. I am here at the Red Hat Summit to learn about Kubernetes and containers. It is all new to me, and at this point, I do not know from where to start. I am getting exposed to so many things, but I still need to understand from where to start. I need to know the foundations. In about 18 months, we will be going to containers. We have people developing Dockers, Kubernetes, and other things, but we need to find a way to integrate them. We will have containers running on OpenShift, but we need to know how to secure, store, and manage those containers.

I have participated in a few presentations, and I see that there are prescribed ways to ensure that you maintain compliance by upgrading. In one of the presentations, one of the presenters said to not expand or scale too quickly because some of the applications get left behind. That is something that I am taking away.

The portability of applications and containers built on Red Hat Enterprise Linux will be good for keeping our organization agile. It is flexible. They say, "Build once and run anywhere." That is the buzzword for me.

To a colleague who is looking at open-source, cloud-based operating systems for Linux instead of Red Hat Enterprise Linux, I would say that Linux is for beginners, whereas Red Hat Enterprise Linux comes with the bells and whistles and the stability for business. It is an enterprise-grade software.

Overall, I would rate Red Hat Enterprise Linux a nine out of ten. There is innovation and adaptability. Ten years ago, it was unheard of. It has grown, and it has been growing tremendously.

We are deploying Red Hat Enterprise Linux as our primary Linux OS, and we are using Ansible for some automation initiatives. Our use cases are around centralization.

We have a supported product. We are at the beginning of building a relationship with Red Hat similar to the one we have with Microsoft, Cisco, and others. It is to standardize the quality, supported version, and company. I am leading this project, and I believe Red Hat is the one.

We have built a hybrid environment. Most of it is on-prem, but we also have Azure, so we have both cloud and on-prem environments. Red Hat Enterprise Linux is helpful for patch and vulnerability management. There have been a lot of security initiatives around Windows and tightening it up, but our Linux environment was not standardized. Red Hat Enterprise Linux standardizes it. With the combination of Insights, it aligns with Windows and other security initiatives.

Red Hat Enterprise Linux has not yet enabled us to centralize development. It is too early for that. I am not very familiar with OpenShift, but with OpenShift, Kubernetes containers, and some of those capabilities, DevOps will become more integrated with Red Hat and its products in the future.

Red Hat Enterprise Linux’s built-in security features seem very good when it comes to risk reduction, business continuity, and maintaining compliance. One thing that helps is the catalog of preexisting playbooks provided by Red Hat around security. It helps you ramp up on security. It aligns it with what an IT person on the Windows side already knows to look for, such as firewalls, setting up permissions, etc. They have playbooks for Active Directory integration, security initiatives, and limiting the firewall. Building out some of the playbooks that Red Hat has in those areas was helpful in getting a good security posture for those systems.

Ansible is going to make the portability of applications and containers happen for us. The OS is important, but our ability to use Ansible and deploy via a cloud or automate via a cloud or on-prem would accomplish that.

Red Hat Insights is valuable. There is patch and vulnerability management. It is similar to what you would see with SCCM. I have a single pane of glass interface. I can approve the patches and vulnerabilities, and hopefully, between Satellite and Ansible, we can automate that process.

I am looking for training. I am a Windows guy who accidentally became a Linux guy. You volunteer a few times, and you are the guy. Right now, I am looking for training and ramping up to be able to support their products, so professional services are key. There are things like Lightspeed with IBM Watson. I do not know YAML very well, so it is going to be integral for me to create playbooks at the very beginning and be able to use the AI tools. If I say, "How do I open a port on this Cisco router?", the AI tools are going to give me the YAML code. In spite of not being a Linux guy or a great coder, I can use those tools to ramp up very quickly. Making Lightspeed a part of Red Hat deployment initiatives tremendously helps with customers' success. It gives them that extra tool. Right now, it is being sold separately as a subscription. If they could integrate that capability, people would not have to go use ChatGPT and other tools. They could use that as a part of it. It would just align things with Red Hat, so one area they can improve on is the approach to customer success for new deployments.

Red Hat Insights are instrumental in identifying vulnerabilities. I am still learning, but my understanding is that it is not directly connected to your environment to deploy a patch or vulnerability fix. It is going to give a YAML playbook to do that. It does not actually execute it. On the Windows side, I have an approval process on the server where I can say, "Deploy this patch." I thought of Insights along the same lines where I can just approve things, and then based on some backend configuration, it will implement them using Ansible, Satellite, and on-premises Ansible. It seems disconnected right now. It might not be, but to me, there seems to be a gap there. I love Insights, and I want to fully automate that approval process. This could be a point for improvement if it does not already do that.

Another area of improvement is Red Hat expressing a return on investment better. I do not know if they have determined a lot of that. I have always assumed that I could go with an open-source OS in a less expensive manner than Windows or something else. My impression is that there would be less cost, but I do not know that for certain. Red Hat building out some of that ROI on different products would be beneficial to their sales effort.

We are a brand new customer.

It is more stable than the wild west environment that I have been in. There is standardization. It is stable by standardizing.

So far, its scalability has been good. Once I get a good image built, I will get some workflows built into Ansible. I will have that process all the way down to the help desk. We will be entering variables and kicking out systems all day.

We have been using it minimally. We have about 15% Linux environment with lots of flavors. Red Hat Enterprise Linux is what we are centralizing on from now on, so we are going to do a conversion of all those. We have a new standard going forward. We have about 15% Linux systems, which would amount to about 150 systems throughout North America. It is a small footprint.

I have not had to call them much, so I do not have a good handle on support from Red Hat. Everybody gets at least a C or a five, but I am optimistic. It is going to be good. I would give them at least a seven out of ten.

Neutral

Prior to Red Hat Enterprise Linux, it was CentOS and others. CentOS was free. It was whatever was available or the developers or applications guys were familiar with.

We switched to Red Hat Enterprise Linux for centralization, to be supported, and for patching and vulnerabilities.

Most of the things that I am deploying or replacing are on-prem and on Azure cloud. It is 50/50.

The deployment was very easy. They have a great and user-friendly installation process with 9.x and above. However, just being new to it and having a security hat on, I still struggle with what should and should not be installed on the base image. It is a learning curve for me, but using the interface has been great. I was able to join Active Directory and all those things.

CDW is handling our professional services and our training, which is a separate purchase. Its initial rollout is with CDW.

We have not yet seen an ROI.

It is expensive. Everything is. I was happy to get a three-year Red Hat Enterprise Linux contract for our initial rollout. 

It is less expensive than other solutions. It is a growing company.

It is called Microsoft ARC. It now facilitates patches for Linux, but it did not include certain things. For me, there was much more benefit outside of just patching by going with Red Hat Enterprise Linux and Ansible.

I am not yet certain about Red Hat Insights' vulnerability alerts and targeted guidance. We are at the beginning. We are just adding systems. I have not set those alerts up if they exist. I assume there are some. I am also going to evaluate how accurate the vulnerability and patching information is because we have other security products that are looking at the same things on the Windows side, and they have already identified many of the vulnerabilities. As a new customer, I want to make sure that if our other system says something is a vulnerability, Red Hat Insights also says that it is a vulnerability. I want to feel confident in the vulnerabilities that I am getting from Red Hat Insights. I want to make sure that other products are also scanning for the same thing. I suspect it is.

To a colleague who is looking at open-source, cloud-based operating systems for Linux instead of Red Hat Enterprise Linux, I would recommend going for Red Hat Enterprise Linux. I cannot think of another OS that can match this.

I will start off with an optimistic ten, and I will rate Red Hat Enterprise Linux a ten out of ten.

One of the valuable features is that it's convenient. 

The rest of its features are really nice.

Red Hat enables us to achieve security standards certification. We have been certified for the PPI certification last year. 

Red Hat has been good when it comes to building with confidence and ensuring availability across our infrastructure. We are really confident about the security process.

It is implemented across multiple physical and virtual infrastructures. We have applied it on most production servers. They are integrated quite well. 

We use the Red Hat system roles feature. We have been using this for automation purposes and to find some tests. 

The response could be better for urgent issues. If there's an issue with live services, they need to be faster. 

It would be nice to have antivirus services.

There should be more upgrades to the security features. 

I've used the solution for a long time. My organization has used it for more than three years. 

The stability is good. I'd rate it eight out of ten. 

The scalability is decent. I'd rate the solution eight out of ten. Different teams and departments, including application and development teams. 

We do not have plans to increase usage in the future.

I'm very happy with the technical support.

Positive

We have got some other open systems like CentOS. We just have most of our production services to ReadyX from CentOS and Oracle. Red Hat is more secure. The support is very nice as well.

I joined the organization after deployment and wasn't involved in the implementation. 

I'm not sure if the solution requires any maintenance. 

I'm not really involved in the pricing or the licensing. However, it may be expensive. We have different licenses. 

We evaluated different options.

I'm a customer and end-user.

I'd rate the solution eight out of ten. 

The SAP solution subscriptions have made things a lot easier because it's a standard build. 

The solutions were premium and standard, which were not the same. They've combined those into just one standard version. Only the support hours are different. That is fantastic for us. It makes life easier.

For the standard subscriptions, in the past, updating the OS could increase your downtime. With the production ones, it did not. It got our non-production and production out of sync. Now, they've combined that all into one. It's just the support hours that are different. They're fantastic.

We use the SAP solution subscriptions only for SAP, which are great. 

We also use Ansible. Ansible is a wonderful tool for automation. We use it to automate our patching. We use Ansible to get playbooks to take care of anything that's manual.

We were able to achieve our security standard certifications.

Red Hat Enterprise Linux has affected our HA systems in a negative way. We're working through some of those issues.

Red Hat Enterprise Linux 8 came up with a new feature that's like a MOM API in our cluster. It goes out into the AWS side and it needs to be adjusted. It does a retry that causes a cluster to failover pretty quickly, so we turned that feature off. That's something that could be improved. 

I have been using Red Hat Enterprise Linux for a long time. It has been at least 10 to 15 years.

Support has been great. We get the right people for what we need.

Positive

The patching has been good, but we scan with Qualys all the time. It comes up with thousands of EIDs all the time, but putting on the patches seems to resolve that.

We're operating right now from 7.9 to 8.6. We have to go with the supported versions. We did qualify for RHEL 9. 

We used Unix in the past. We did have to come up with the SAP side. It was always Unix.

Overall, I would rate the solution an eight out of ten. 

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

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

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

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

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

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

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

The solution is useful for application support and automations. 

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

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

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

I have been using the solution for four years. 

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

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

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

Technical support is rated a nine out of ten. 

Positive

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

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

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

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

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

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

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

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

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

I rate the solution a seven out of ten. 

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

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

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

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

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

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

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

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

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

I have been using the solution for twelve years.

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

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

The solution is very stable. 

The solution is scalable. 

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

Positive

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

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

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

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

I rate the solution an eight out of ten.