Organizations is an interesting concept in Spacewalk or Redhat satellite that gives you the ability to completely separate the management of different environments into their own organization. Each organization has it's own set of users and configuration within spacewalk. In fact the only thing that can actually be shared between organizations are software channels. These can be made publicly available to organizations which have a thrust relationship with each other.

With the advent of enterprise iSCSI solutions it has become popular alternative to FC. The benefits of iSCSI are apparent. No longer do you need expensive FC switches and HBA cards, nor do you need Richmond to maintain it.

In my previous article I already talked about one of my favorite new features in RHEL 6: Upstart. Another useful new feature is the ability to do advanced resource scheduling. Older redhat versions had fairly limited mechanisms to do resource scheduling. This was mainly done through limiting the user environment with ulimit, but you would soon run into troubles if you wanted more granular control. With control groups in RHEL 6 you finally have this control.

With RHEL6 having been released last November, half a year of aging has given me the opportunity to let some of its new features sink in. Definitely my 2 favorites are the introduction of upstart, to replace the aging Sysv init startup mechanism, and the introduction of advanced resource management with Cgroups.

Since 2008 Redhat has released their system deployment/management suite Redhat Satellite Server as an open source project called spacewalk. The functionality of Redhat satellite and spacewalk is basically the same but the ability to connect directly to RHN to synchronize software repositories and errata's has been disabled. You can however implement a few tricks to circumvent this limitation. Note however, that you will need a Redhat license for each instance of Redhat that you install. Also note that this solution is not supported by Redhat.

With the increasing use of Linux in business critical applications, the need for ensuring system availability has become an important part of architectural design. Ensuring system availability is however more than choosing the right technologies. Each component that interacts with your application is equally important for its overall availability and it is usually the 'human factor' that will bring your system down. So how do you go about designing such a system? In this article I would like to shed some light on this.