We are a Linux shop, so a lot of our engineers are familiar with Linux. We try to push Red Hat Enterprise Linux instead of Windows. The reason for it in the beginning was licensing. Some of it was because of the way the contract was set up. It was cheaper, but we do use it now just for the ease of it. I do not know if it is because of Ansible, which we use for a lot of our day-to-day operations, that we tend to lean more toward Red Hat.

Red Hat Enterprise Linux has affected our system's uptime or security. I know Microsoft publishes zero-day vulnerabilities for Windows as fast as Red Hat, but we noticed that in terms of problems or alerts that we get for attacks or viruses, there is not anything on the Red Hat side. That is why we feel that it is more secure. It might be just the nature of Red Hat where all services and ports are off. It is not like Windows where everything is on, and you have to turn it on. I was having a conversation with one of the gentlemen who is also attending the Red Hat conference, and I got to know that there are built-in NIST features with Red Hat that we could turn on, so we do not have to try to figure out how to harden our system.

The testing of the updates or the packages of the kernel is valuable because I used to be a part of the Fedora project. I know it is all vetted out before it gets to production, but a majority of it is the support and the relationships I have with the Red Hat employees assigned to our account.

As they move over to newer versions, certain things change, which is expected as the technology matures or new things come out, but what really surprises me are the features that are there in the cloud, such as Red Hat Insights. They are not there on-prem. There are a lot of things on the cloud portal that I did not notice before, and I was surprised because we were unaware of them. Red Hat is doing a lot of investment in that sense.

The knowledge base offered by Red Hat Enterprise Linux is good. It is easy to parse through all of the knowledge base. I do not know if Windows does it because I have not looked at it, but in Red Hat's knowledge base, there are a lot of things. They fast-track a lot of things in their knowledge base, even when they are not yet official. Especially with the tie-in with Bugzilla, even though it is not a true KB, we can see and follow if other people in the world are hitting a certain problem or something similar to what we are experiencing. I like that.

It would be great to have an overview of how various Red Hat products work together. They can show how to tie all those pieces together and how to have the products that we work together for our day-to-day processes.

I started with the company around 2012, and they have been using it even before then. At that time, it was Red Hat Enterprise Linux 5, and now, we are up to Red Hat Enterprise Linux 9.

In 10 or 11 years of using Red Hat solutions, I have opened only one or two support tickets. It probably was something during a patch and during Satellite 5 to Satellite 6 migration. I would rate them a 10 out of 10.

In Linux, there are so many different flavors, but I am partial to Red Hat because I have been a part of the Fedora project. At our place, we have only two operating systems: Microsoft Windows and Red Hat Enterprise Linux. I know CentOS, but that is usually because the appliance from the vendor was set up using that. That is why we had a few instances of CentOS in the past, but nowadays, I do not see any other flavors of Linux.

For the majority of our use cases for Red Hat, we have on-prem deployments. There are some things that they are trying to spin up on AWS. I do not know if they are cloud-native apps or not, but I know our developers are now moving on to it.

I have been involved in the initial setup, upgrades, and migration of Red Hat Enterprise Linux. I did not have any problems while going from major OS versions. I always push new upgrades or homogeneous migrations, such as from version 6 to version 7 to version 8. There is probably an option to upgrade in place. Overall, with Red Hat OS, I have not seen many problems. A long time ago, when they went from Python 2 to Python 3, there were certain things we had to change in the script.

I know that Red Hat is moving to Wayland from X11, but I do not see any problems there. From Satellite 5 to 6, it was a bit hard in the beginning, but now, it is pretty self-explanatory. Overall, everything about which we had questions was very well documented.

In terms of our upgrade and/or migration plans to stay current, first, we look at the EOL and the roadmap of Red Hat because of security. We used to offer every single version before the said EOL happened, but now, we just do an n-minus-one. We try to maintain the newest and one level below version. SAP users are the biggest Red Hat Enterprise Linux users in our environment. They have a particular PAM and upgrade path that they have to do with Red Hat. We also wait to be certified to certain versions, but our main strategy is the newest and one major version down. We try to get everybody off the other versions.

Our provisioning is all done using VMware products. We have a vRealize automation, now called the Aria automation, to spin it up. Patching is done through Satellite. I do not do it, but when I watch them doing it, it seems it is just using remote SSH commands against the list of non-prod and prod servers. It is something simple. We do not seem to be doing anything complicated. I am wondering if there is a better way to do versioning control or patching and whatnot, but currently, it is very simple.

I am satisfied with the management experience not only in terms of patching but also the day zero to day one or day two stuff. We are interested in utilizing Ansible to eliminate human error and whatnot. During provisioning, we have Pearl scripts that we have to manually trigger. I know we can use Ansible for that, but it comes down to the cost of entry which is still very high.

A lot of people are moving into the core count for licensing. We still have a few with one-to-one standard server licensing, but we are utilizing the virtualization host licensing. We license it based on the host, not based on VMs, which is cool. I was very happy that there was certain licensing with SAP to have access to SAP repos. Its cost was the same as the regular one, so I was happy about that.

The only pricing that bugs me right now is the Ansible pricing. We wanted to take a look at Ansible, but the biggest thing a year back with Ansible was that the management did not want to spend half a million on Ansible Tower. They wanted to see first if we would use it and not waste money. I do not know if things have changed now, but Ansible is probably still expensive. That is one of the routes that we want to go to. We will see if we can utilize Ansible Tower, so pricing-wise, that is the only thing that pops up. It is too expensive. The cost of entry seems quite high.

Overall, I do not see any issues with what we have spent on Red Hat. We also have learning subscriptions that we pay to Red Hat for the training, and I do not feel we have wasted any money.

Red Hat Enterprise Linux has built-in features, but we do not use them. It is one of the things about which I need to talk to our account manager. There are so many different ways to skin a cat. My department has so much money, so they bought everything, but a lot of the security features, such as SELinux, are disabled for us. We handle the firewall rules, access lists, and other things at another location rather than on the actual VM itself. It does not hurt to do it at multiple places, but operations-wise, it would be a nightmare, so we try not to do it. I know there are a lot of cool new things built in Red Hat, and that is something we should circle back and take a look at.

I have seen Red Hat Insights. I clicked on it one time when our account manager was showing us something. They have so many features in the cloud that we do not know we can use. Maybe it is wrong to assume, but the reason I do not look at Red Hat Insights is that a part of our patching is already included. We are not that strict about what we patch in terms of the versions. It is useful, but Red Hat emails us anyway. They tell about the severity of an issue. We do not look at Red Hat Insights. We see those emails and we see CVEs. If a package is installed and applicable to our VMs, we just use Satellite and patch that particular vulnerability.

I have also tried the web console once. It looked interesting, but we do not have much use for it because a lot of our customers or application owners are server admins. About 99% of our Red Hat installs are all minimal installs. We do not have a GUI. There is just a terminal screen. Even though they could console in and do whatnot, it is all done via SSH.

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

My primary use case for it is to run Jenkins servers.

Red Hat Enterprise Linux is critical for our operations. We use it for all of our Linux servers.

It works. It's consistent. It's well-documented. These are valuable aspects to me.

Red Hat Enterprise Linux 9 updates the Cipher Suites and the security proceeds it. I wasn't pleasantly surprised because a bunch of our server communication didn't work. Having the Cipher Suites updated is a good thing but was not convenient.

I feel positive about the built-in security features when it comes to simplifying the risk and reduction and maintaining compliance. I'm also a Windows Server administrator so, compared to my Windows Server experience, I have very positive feelings about Red Hat Enterprise Linux security based on how easy it is to keep things patched, up-to-date, and compliant.

Some of the repositories and some of the DNS versions are very old. I just deployed something using Ruby and the DNS stable repository was sufficiently old that the Ruby project I was using didn't work.

I would like more transparency and better options other than using something like Ruby Version Manager. I'd rather be able to get modern, up-to-date versions from the base repositories.

We have been using Red Hat Enterprise Linux for ten years. We're on a bunch of different versions. We're anywhere between version six and nine. My personal project is on nine.

We still have Windows servers.

Red Hat Enterprise Linux is very resource-intensive, and it's hard to secure because Windows, the base use case, is all things to all people.

I generally like Linux server products. I like the way they specialize, and I like the default security posture.

We have a hybrid environment. We do have some things in the cloud. We're using both Azure and AWS as our cloud providers.

I was involved in the process of migrating our Jenkins servers to Red Hat Enterprise Linux 9. It was not straightforward or complex because we changed a lot of things about our deployment. We tried to improve and streamline, and in the process, we broke some of our pipelines.

It was not smooth, but that was not necessarily because of Red Hat Enterprise Linux, except for some of the security upgrades. We could not use the old RSA keys that we were using with RHEL 6 with RHEL 9. This meant that we either had to loosen our security by allowing legacy keys or tighten things down. We chose to tighten things down.

Another challenge is that we have some old Red Hat Enterprise Linux applications that are running on very old versions. We are trying to get everything off of RHEL 6 and 7 and onto RHEL 9, but there are a few applications that are stuck on RHEL 6 for various reasons.

We are getting rid of all of our Linux servers, so the biggest challenge right now is migrating our applications to RHEL 9.

When it comes to provisioning and patching, it is pretty manual. The company uses VMware, and the process is pretty manual and involves a certain number of shell scripts. I know we're trying to adopt Ansible, but we're not very far along.

I've had a very positive experience with Red Hat Enterprise Linux. My only point of comparison is Ubuntu, which I use for personal projects.

Red Hat Enterprise Linux is a solid enterprise product with a greater emphasis on security. However, Ubuntu Server is easier to use in many ways compared to Red Hat Enterprise Linux. This may just be a matter of familiarity, but I find it easier to get current versions of Ruby with Ubuntu than with Red Hat Enterprise Linux.

This is based on my somewhat limited use, but it's my impression nonetheless. That's what keeps it from being a ten out of ten.

We have an older environment with a lot of servers. They are development servers for a lot of in-house development. We have a lot of things. We have Ruby on Rails, Java, and a lot of Oracle applications

Red Hat Enterprise Linux is mostly on-prem in my current job. In my previous jobs, we have had it on AWS or Azure.

Red Hat Enterprise Linux's built-in security features are good when it comes to simplifying risk reduction and maintaining compliance. It is something that they do very well. It is one of the reasons why we like running it. It is rock solid in all areas. Red Hat does a really good job of keeping on top of vulnerabilities and making the patching process easy.

Red Hat Enterprise Linux has impacted our uptime and security. We have had no breaches, and our systems are usually up.

Red Hat Enterprise Linux has not yet enabled us to achieve security standards certification because that is not a requirement for where we are, but I am pretty confident that we would meet those standards. Our security teams are usually chasing problems on the other side of the house.

I like most of the features. I like its stability. I like its views. It provides a very stable environment. There is not a lot of downtime. There are not a lot of issues. Primarily, we are deploying things and configuring things, and occasionally, we add new things for developers as needed, but it does not require much troubleshooting or break fixing. That is rare.

The knowledge base offered by Red Hat Enterprise Linux is another thing I like about it. It is particularly easy to find an answer to your problem online. There is very good documentation, very good user communities, and good support when you need it.

The upgrade procedures are a little bit cumbersome. It would be nice if they are not because every three or four years we have to update, and I find that to be a bit on the cumbersome side. We have been able to automate most of it, but we still run into things where the job does not finish. There are things that require additional steps. There are things that need to be removed and that always require manual intervention. I do not know how they can get rid of that, but it is cumbersome in an environment where you have hundreds or thousands of servers.

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

I would rate their support a nine out of ten. I just do not give tens. I am sure there are some areas where they can improve, but they are good. They are responsive.

I have got experience with Windows and Solaris before that. Red Hat Enterprise Linux is my favorite. With Solaris, that stream stopped a long time ago, but Red Hat Enterprise Linux has all of the nice things about it, and they have continued to develop and build many new things. For instance, when you had to patch on a Solaris box, you had to take the server down into single-user mode and apply the patching. I like it better than Windows in every way. It is more intuitive to me. I like that I can do more things from the command line. It is easier to automate things.

I have been involved in the upgrades and some migrations for migrating things from Solaris. We also had CentOS, which was converted to DevStream, so we have had to change those to Red Hat. The upgrades and migrations were not terribly difficult. Usually, the tools were there. We called support when we ran into problems, but for the most part, it worked.

I have used Convert2RHEL. It was a bit helpful. It did the job.

We mostly use Ansible for deployment, patching, and managing the system in general. Our experience has been good. I am looking at some of the newer things they have at the conference that we have not had a chance to play with, but it meets our needs.

We have seen a return on our investment. We are able to do what we need to do without any problems or interruptions, and we are able to do it quickly.

For me, it is not too bad, but my company pays the bill, so I do not worry too much about it.

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

Red Hat Enterprise Linux is the underlying licensing system that our third-party tool uses. It offers convenience. We can open a case when we want to escalate anything.

The tool's insights included with licensing is good. Security patching is also a good feature for us.

I don't like the UI changes that come with different versions.

The tool's support is good. Sometimes, support comes from India. I try to wait and ensure remote support is from the US so that it fits the timeline.

The product's deployment is straightforward.

We are a big data shop that has around 700-800 nodes.

Red Hat Enterprise Linux Leapp was very helpful. It is very easy to use.

Our servers run for 500 days, and we reboot them every 600 days.

I search through Red Hat Enterprise Linux's knowledge base daily.

We use Red Hat Enterprise Linux 8.6 since the third-party tool is compatible with it.

We use satellites for the operating system and Ansible to do the configuration.

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

We use Red Hat Enterprise Linux to host website content.

The tool's most valuable features are stability and maturity. Linux offers cost efficiency. Red Hat comes at the top of other Linux vendors. I am very satisfied with Red Hat Enterprise Linux's maturity.

We had issues migrating from the old to the new Red Hat Enterprise Linux version in the virtual environment. It forced us to spin up a new virtual environment to have the new Red Hat Enterprise Linux version.

I have been using Red Hat Enterprise Linux for over 15 years.

My experience with Red Hat's support team is positive. They are a lot better than our cloud CMS vendor.

We used Sun Microsystems and Unix on on-prem.

The product supports our hybrid cloud strategy well.

We move workloads between different clouds and data sandboxes.

Red Hat Enterprise Linux's knowledge base is quite extensive. It is free, which helps us to advocate the product. I would like it to continue and rate it positive.

The Red Hat Enterprise Linux web console was helpful and offered visibility through dashboards. It helped us see what was going on with our system.

I rate it a nine out of ten.

We use Red Hat Enterprise Linux for our on-prem VM infrastructure. Recently, we got the OpenShift platform to help with containerization on-prem.

Moreover, containerization is one way we're trying to get rid of any legacy. We don't patch. We try to have a fresh build with the newer version of the patch. We try to use those Red Glue deployment strategies and remove whatever we find in misconfiguration or vulnerability instances rather than fixing them. We redeploy it.

In terms of improvement within the Linux environment, especially for a non-IT company like ours, where we have a limited number of Linux administrators and specialists in Linux hardening and security, Red Hat Enterprise Linux plays a significant role.

It eases the burden by restricting the use of open-source Linux and preventing the development community from obtaining their own images. This is crucial for maintaining a secure supply chain and ensuring the lockdown of live Linux packages.

However, when it comes to security compliance, I have not been exposed to the Red Hat Enterprise Linux security; we got the advanced cluster security from OpenShift, which has some vulnerability tracking within the cluster. Within Red Hat Enterprise Linux, I have not experienced the security console yet.

Red Hat Enterprise Linux has affected our systems and our security. It helps us achieve security standards. It's one of the hardening requirements so, it helps with that compliance requirement.

With standardization across the environment, we don't have to generate multiple artifacts for compliance, and having a single Linux platform management like Red Hat Enterprise Linux helps to satisfy auditors a little faster.

From a security perspective, the overall hardening of Red Hat Enterprise Linux is good. It has been effective in enhancing security.

Image management and hardening are essential, so we don't have to procure open-source Linux images that developers can get themselves. It adds a layer of security with signed images.

The knowledge base is pretty good.

From a cloud perspective, I'm looking for more integrations with native cloud services. For example, the ability to use native Azure Key Vault instead of Ansible Key Vault or Red Hat Key Vault.

Additionally, integrating image services from Red Hat into native image repositories such as Azure, Google, or third-party image repositories like JFrog is crucial. The key focus is on integration.

Red Hat should not become Microsoft and lock down functionalities within Red Hat.

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

We have premium support, so it is pretty good.

We are a mix of some other cloud virtualization technologies. The overall cloud information will define how we look down the road.

With Linux management, the pros are that it makes management a little easier. Overall, it is just a single view of the images we deploy in the organization.

The cons are that the integrations are a little tricky sometimes, and then we have to make exceptions to our policies. Better integration, more native service using more credentialless authentication, and authorization like using service principles or managing these over-store credentials would make it better.

Currently, the emphasis is on on-premises solutions.

Overall, I would rate the solution a seven out of ten because it needs more integrations.

We have general use cases.

It's a well-supported OS. I don't know what we'd use if we didn't have it.

Moreover, the last time I had an issue flagged with the vulnerability, I was able to go to the Red Hat website and find a patch. It worked pretty well.

The built-in security worked well when it came to solidifying risk production and maintaining compliance. The uptime or security of our systems has been pretty solid.

It helps us maintain our security standards and keeps us up to date on security.

One of the most valuable features is the package manager because it makes it easier to keep everything up to date.

The package compatibility between different releases is a little confusing sometimes.

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

We've also used Ubuntu.

It's a matter of certain servers that need to be kept secure, so we chose Red Hat.

When I order a server in our organization, it comes installed, and then they spin it up.

I am involved in the upgrade processes. The upgrades weren't complex but required some downtime. We don't normally upgrade until a particular OS version becomes end-of-life and the new one starts.

Our in-house IT department did the deployment. We have a separate IT department that leverages the training provided by Red Hat.

Overall, I would rate the solution a nine out of ten because most of the information I need I could find on the Red Hat website.

We have Ansible deployed on our Red Hat Enterprise Linux servers. We use it to manage the security of our fleet of Ubuntu virtual machines.

Red Hat Enterprise Linux is way ahead of Ubuntu in terms of security and compliance. It is mainly the ecosystem of data science tools that our developers want that pushes us in that direction. As a security engineer, I have a lot more peace at night knowing that my Red Hat servers are doing a good job keeping our Ansible infrastructure safe because that has fingers into everything we do. It is pretty critical.

Red Hat Enterprise Linux has not affected our system's uptime in any particularly noticeable way.

Red Hat Enterprise Linux has not enabled us to achieve security standards certification because we do not have any yet. We will have them hopefully in the future.

There are some nice integrations with scanning for vulnerabilities. That is the feature I have enjoyed the most because I am a security person, and that is my bread and butter.

Ansible has certainly been a game-changer. It is a lot easier to keep a whole bunch of virtual machines consistent with each other and make a change consistently across all of them. We use them for data science activities. Our data scientists are constantly trying out new packages and downloading new tools. We have to enable them to have root access on their machines but also need to ensure that they are not doing anything stupid at the same time. There are competitors to Ansible, but we are a big Python shop, so it is a very comfortable environment for us.

The only issue we have had with it is around the SELinux configuration because the way Ansible installs, it sticks the platform passwords in a flat file. We want that locked down more strongly than what is there currently with SELinux.

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

I would rate their support an eight out of ten.

Primarily, we have used Ubuntu. We have had some of our use cases on CentOS, and then, of course, our workstations are all Windows, but I wish they were not.

We chose Ansible, and that chose Red Hat Enterprise Linux for us.

We use Red Hat Enterprise Linux in the cloud. We have Azure because it is the corporate standard. We do not have any concerns about using Red Hat Enterprise Linux in the cloud. Obviously, everything in the cloud is more exposed than everything on-prem, but it has got good, sensible, and secure defaults built in, so there are no concerns there.

In terms of Red Hat Enterprise Linux upgrades, when we upgraded Ansible this fall, that pushed us from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. It should be a little easier from now on. Now that we have made the big jump from the older Ansible to AAP, we will probably be upgrading the systems on a quarterly basis.

We probably have not yet seen an ROI. We purchased it a couple of years ago, but we have not had the time to put it to as much use as we wanted to put it to. The cost is low, so it would not take very long to reach a return on investment.

We have not made use of the Committed Spend.

For its use case, I would rate Red Hat Enterprise Linux a ten out of ten.