There have been countless advances in technology in the last few years; both in general and at Red Hat. To list just the ones specific to Red Hat could actually boggle the mind. Arguably, some of the biggest advances have come more in the form of “soft” skills. Namely, Red Hat has become really good at listening – not only to our own customers but to our competitors’ customers as well. This is no more apparent than in our approach to applying a self-service catalog to virtualization. Specifically, pairing Red Hat Enterprise Virtualization (RHEV) with CloudForms for the purpose of streamlining and automation of virtual machine provisioning.
Red Hat engineers have been working to more securely distribute container images. In this post we look at where we’ve come from, where we need to go, and how we hope to get there.
When the Docker image specification was introduced it did not have a cryptographic verification model. The most significant reason (for not having one) was the lack of a reliable checksum hash of image content. Two otherwise identical images could have different checksum values. Without a consistent tarsum mechanism, cryptographic verification would be very challenging. With Docker version 1.10, checksums are more consistent and could be used as a stable reference for
As the number of production deployments of Identity Management (IdM) grows and as many more pilots and proof of concepts come into being, it becomes (more and more) important to talk about best practices. Every production deployment needs to deal with things like failover, scalability, and performance. In turn, there are a few practical questions that need to be answered, namely:
- How many replicas do I need?
- How should these replicas be distributed between my datacenters?
- How should these replicas be connected to each other?
There are two supported protocols in Red Hat Enterprise Linux for synchronization of computer clocks over a network. The older and more well-known protocol is the Network Time Protocol (NTP). In its fourth version, NTP is defined by IETF in RFC 5905. The newer protocol is the Precision Time Protocol (PTP), which is defined in the IEEE 1588-2008 standard.
The reference implementation of NTP is provided in the ntp package. Starting with Red Hat Enterprise Linux 7.0 (and now in Red Hat Enterprise Linux 6.8) a more versatile NTP implementation is also provided via the chrony package, which can usually synchronize the clock with better accuracy and has other advantages over the reference implementation. PTP is implemented in the linuxptp package.
Paradoxically, there has never been a better or more confusing time to discuss which platform is most appropriate for a given workload. As we seek to solve problems around automation, continuous integration / continuous delivery, ease of upgrades, operational complexity, uptime, compliance, and many other complex issues – it quickly becomes clear that there are more than a few viable options. Making matters worse – there is too much focus on the “how” (to adopt a given platform) and not enough focus onthe “why”. To this end, I’d like to address more of the “why” in an attempt to better influence the “how”.
Hello again! In this post I will be sharing some ideas about what you can do to solve a complex identity management challenge.
As the adoption of Identity Management (IdM) grows and especially in the case of heterogeneous environments where some systems are running Linux and user accounts are in the Active Directory (AD) – the question of renaming hosts becomes more and more relevant. Here is a set of requirements that we often hear from customers
In our first post defending the pet container, we looked at the challenge of complexity facing modern software stacks and one way that containers address this challenge through aggregation. In essence, the Docker “wrapper” consolidates the next level of the stack, much like RPM did at the component level, but aggregation is just the beginning of what the project provides.
If we take a step back and look at the Docker project in context, there are four aspects that contribute to its exceptional popularity:
- it simplifies the way users interact with the kernel, for features we have come to call Linux containers;
- it’s a tool and format for aggregate packaging of software stacks to be deployed into containers;
- it is a model for layering generations of changes on top of each other in a single inheritance model;
- it adds a transport for these aggregate packages.
It’s been a busy few weeks for us on the Atomic Host team, and we’re excited to announce the release of Red Hat Enterprise Linux Atomic Host 7.2.5! This is a big one too. For those not familiar with our release cadence, we release a new version of Atomic Host every six weeks. This enables us to balance the reliability of Red Hat Enterprise Linux with exciting new features and capabilities from our Project Atomic upstream community in a production ready, supportable manor.
Now, let’s walk through some key new features in Atomic Host:
In November 2015, I blogged about the announcement to bring .NET to RHEL from the .NET Core upstream project to enterprise customers and developers, both as an RPM and as a Linux container. That was quite a moment for the industry and, quite frankly, for me as well, having participated in the discussions that led to the significant announcement with Microsoft. Since then, we have been in tight collaboration to make sure this day would actually arrive. Despite the usual challenges with a relatively new open source project, the project was
As a Solutions Architect, I enjoy creating and adding custom configurations to my Red Hat Enterprise Virtualization(RHEV) environment using a feature called hooks. A hook is a custom script that executes at a certain point during a RHEV event. You can attach scripts to several events. To see the full list of RHEV hooks, do a directory listing of “/usr/libexec/vdsm/hooks” on a RHEV hypervisor and you will see the below list.