Sys Admins: Developers Asking for Unsupported ToolChains?

If you have ever worked as a system administrator, you are familiar with developers constantly wanting to use the latest toolchains even to the point of wanting to roll their own packages. Of course, the challenge is, if you are running a production environment, introducing change is always risky. If the change being introduced is from an unknown source, the risk is even higher. As a result, many admins rely on companies like Red Hat to provide them some assurances regarding the quality of the components underpinning the applications. However, a company like Red Hat also has an interest in only supporting tools that are known to be stable and fault-free (as much as anything can be). Sometimes this doesn’t meet the developers’ needs. As a result, Red Hat has introduced (currently in Beta) the Red Hat Software Collections bundle to try to find a happy medium.

All that being said, and arguably said before in press releases and the like :), there is another interesting use case for the software collections concept. Specifically, what about when the developers and the business have essentially abandoned an application? In other words, the application delivers on its promises to customers already, and, at this point in time, there is no desire to invest further resources in the application. Well, what does that mean for you System Admins? Well, generally, it means you get caught holding the bag having to maintain an older toolchain just to support the application.

Continue reading “Sys Admins: Developers Asking for Unsupported ToolChains?”


Software Collections Quickstart

As I discussed in an article entitled Red Enterprise Linux Release Speed, developers sometimes have a problem with how slow Red Hat’s Enterprise Linux releases new versions of software. Well, the good news is, Software Collections are here. Software Collections provide Red Hat Enterprise Linux users with newer versions of programming languages and server daemons like python, perl, ruby, php, mysql, mariadb, etc.

This is a quick start guide to help you get comfortable with both programming languages and server daemons provided as software collections.


First, add the right channel to your system

rhn-channel -u fatherlinux --add --channel=rhel-x86_64-server-6-rhscl-1-beta

To discover what packages are available, do a quick list, and grep for rhscl.

yum list available | grep rhscl
mariadb55.x86_64                      1-6.el6               rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb.x86_64              5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb-bench.x86_64        5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb-devel.x86_64        5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb-libs.x86_64         5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb-server.x86_64       5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta
mariadb55-mariadb-test.x86_64         5.5.30-9.el6          rhel-x86_64-server-6-rhscl-1-beta

Now, let’s install a few interesting packages

Continue reading “Software Collections Quickstart”


Drupal 7, PHP 5.4 and MySQL via Software Collections

In order to test out the new Red Hat Software Collections (RHSCL, announcement) version of PHP 5.4, I decided to build out a Drupal 7 install using the php54 collection and the mysql55 collection.

Overall, the activity was pretty much like a normal Drupal install. However, to use software collections you have to do a few things differently. Also, if you haven’t used a software collection for a “service” (e.g. MySQL) before, the service setup is also a little different than the native versions.

First and foremost, add the channels for RHSCL either via subscription manager or rhn. The name of the channel (for the beta) is rhel-server-rhscl-6-beta-rpms. After that, you need to install the software collections. So, something like:

#yum install php54 mysql55

You could also just install all the dependencies in the same line, but I wanted to pull them out to be able to comment on them a little bit more. I also tend to install some of the semi-optional components because I think Drupal works better that way.

First off, the easiest thing to install, which is also not really related to software collections, is gd (not called “GIF Draw” 🙂 ). Very simple, just install gd from the normal RHEL repositories.

#yum install gd

Next, we need the “driver” libraries for php to various other things. All the ones we need are included in the “php54 Software Collection” but are not installed by the simple install of the php54 package as they are not required for basic php. php54-php-gd is the connection from php to the gd library. php54-php-mbstring is a library for unicode, technically not a “driver” but an optional library. Finally, we need to connect to mysql so we install php54-php-mysqlnd.

#yum install php54-php-gd php54-php-mbstring php54-php-mysqlnd

Last but not least, we need to install the php “driver” for httpd. Now, I call this one out

Continue reading “Drupal 7, PHP 5.4 and MySQL via Software Collections”


PHP 5.4 on RHEL-6 using RHSCL

Official announcement : Red Hat Software Collections 1.0 Beta Now Available

More information on Software Collections

Stability addicts can keep quiet, PHP 5.3.3 is still the standard version provided with RHEL-6.

We’ll soon have an official and supported way to install PHP version 5.4, beside the system version, without any effect on installed components. The announcement tells us the life cycle will be 3 years.

Warning:  it’s a beta version, published for evaluation purposes.


Activation of the distribution channel (requires a valid subscription) from the RHN web interface or from command line:

Continue reading “PHP 5.4 on RHEL-6 using RHSCL”


Managing OpenStack with The Foreman

OpenStack is picking up a lot of steam these days, but getting it installed can be a hassle. Lots of puppet-based installers have popped up to automate this arduous task. Using Foreman, however, administrators can not only configure and install OpenStack using puppet, but provision & add new compute nodes at their fancy.

The Foreman is a Ruby on Rails application that does configuration management with puppet and provisioning. We’ll use both of these features to make using & administering OpenStack easier. Our installer leverages PackStack, which includes great puppet modules for setting up OpenStack. Combining these to setup and manage OpenStack Grizzly is a breeze!


  1. At least three machines running RHEL 6.4 with an active subscription to RHEL OpenStack Platform or Red Hat Cloud Infrastructure.. We recommend your OpenStack Compute & Controller nodes run on bare metal.
  2. Each machine needs to have a resolvable FQDN
  3. Each machine needs to be subscribed to a proper RHEL subscription
  4. The Foreman server should have its firewall configured to allow inbound network traffic on TCP ports 80, 443 and 8140 for Foreman and Puppet to function correctly
  5. The host running Foreman may be running selinux in Enforcing mode, but you must first install the ruby193-foreman-selinux package. Both the OpenStack controller and compute nodes can also run in enforcing mode if you install the openstack-selinux package. You must also manually set a boolean on the controller node: setsebool -P httpd_can_network_connect on

Continue reading “Managing OpenStack with The Foreman”


Red Hat Software Collections 1.0 Beta Now Available

You may have seen references to “software collections” in this blog, but this is different.  “Red Hat Software Collections”, now in beta for the first time, is a collection of refreshed and supported web/dynamic languages and databases for Red Hat Enterprise Linux.   Now you can have two versions of software on one OS, or refresh these languages and databases more frequently.  See this list below!

Continue reading Red Hat Software Collections 1.0 Beta Now Available


Dive deeper in NUMA systems

A common performance related issue we are seeing is how certain instructions
are causing bottlenecks.  Sometimes it just doesn’t make sense.  Especially
when it involves lots of threads or shared memory on NUMA systems.

For quite awhile a bunch of us have been writing tools to help exploit features
of the CPU to provide us insight to not only the instruction of the bottleneck
but the data address too.

See, the instruction is only half the picture.  Having the data address allows
you to see two distinct functions operating on what looks like distinct data,
but yet are intertwined on a cache-line.  Thus these functions are tugging
memory back and forth causing huge latency spikes.

Sometimes the answer is to separate the data onto different cache-lines, other
times (in the case of locks) perhaps change the granularity to reduce

Intel CPUs have support for providing data addresses for load and stores (along
with latency times for loads) through its performance counters.  Userspace
exploits this feature with a tool called ‘perf’.

Latest perf can be run with:

Continue reading “Dive deeper in NUMA systems”


How Long Does It Take to …

One common idiom in performance monitoring is how long did it take for a program to do something. For example you may want to know the time taken for database queries in PostgreSQL or just-in-time translations in a Java Virtual Machine. SystemTap and user-space markers in Linux packages make it much easier to determine the duration of those operations.

The user-space markers compiled into Linux packages mark key points in the code where particular actions occur. The user-space markers also provide arguments that provide additional information about the action. For example, the markers and the available arguments in PostgreSQL can be listed using using the SystemTap command:

$ stap -L 'process("postgres").mark("*")'

The two user-space markers related to the start and completion of a query are:

Continue reading “How Long Does It Take to …”


Red Hat at the ISO C++ Standards Meeting, Bristol, UK

Red Hat has actively participated in the ISO group defining the C++ standard for many years, and continues to make a significant contribution. The Red Hat toolchain team was well-represented at the spring meeting of the standardization committee (technically JTC1/SC22/WG21) in Bristol, UK, last month: we had three people there for the full week, with one other visiting a couple of times during the week. In this article, Jason Merrill summarizes the main highlights and developments of interest to Red Hat’s customers and partners:

Continue reading Red Hat at the ISO C++ Standards Meeting, Bristol, UK