Configure your Linux system

Software Collections on RHEL6/CentOS6

Some months ago Red Hat introduced Red Hat Software Collections 1.0 Beta (which was later released) which is essentially a software suite that as of the first release 1.0 introduces newer versions of programming languages such as Python 2.7 and 3.3, PHP 5.4, Perl 5.6.13 and databases MariaDB / MySQL 5.5 and PostgreSQL 9.2. The beauty part of this collection is that it allows installing multiple versions of the same software on the same machine, each in its own separate environment, so there are no conflicts and the OS package stack remains unchanged (SCL applications are installed outside of standard system directories e.g. /opt/rh and their names differ from the ones shipped with the OS e.g. httpd24 vs httpd) .

Red Hat Software Collections 1.0 is only available to customers with an active subscription, but luckily there are alternatives for the Red Hat derivatives:


The Software Collections Fedora community


The project offers distinct repositories for each package. While not as convenient as the RedHat official channel where all packages are provided within the same repository, the Fedora community packages are basically the same thing as the original, although not supported and distributed via so-called testing repositories. Each package is available through its own repo, so one has to install quite a few repos in order to get all packages from the RedHat SCL which may seem a bit excessive but it gets the job done.

Tagged with either EL or RHEL followed by the release version 5 or 6, the packages should work fairly well on most RedHat clones. I tried installing a few on CentOS 6 and didn’t have any issues whatsoever.

wget -P /etc/yum.repos.d/
yum install perl516
wget -P /etc/yum.repos.d/
yum install python33




This is in fact very similar to the Red Hat release as the CentOS developers rebuilt the RPMs from the same source code. Unlike the Fedora-hosted versions, this software collection is available within the same repository (same as RedHat)  so installation and maintenance is much easier.

yum install centos-release-SCL
yum install perl516 python33

The first command installs the CentOS SCL repository (CentOS-SCL.repo) that hosts all packages. To find available RPMs, simply query the repository:

yum --disablerepo=* --enablerepo=scl list available




Having more than one version of the same software installed on a machine is beneficial, but how do we go about using them? The packages in the SCL are different by design (JavaScript runtime, programming languages, databases), but using them is essentially the same as each one has its own unique name and path. The scl utility (part of the scl-utils RPM) is used to execute commands from the software collections.

#perl -v
This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi
#scl enable perl516 'perl -v'
This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi
# scl enable perl516 bash
# perl -v
This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi
# exit
# perl -v
This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi
# source /opt/rh/perl516/enable
# perl -v
This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi


Final thoughts


The advantage of using software collections is obvious as different versions of the same software can co-exist on the same machine independently of each other. SCLs also facilitate the use of newer software on older Operating Systems (such as Enterprise Linux distros) which is really important as upgrading the OS is not always an option. Looking forward to the next release!

Red Hat Software Collections

CentOS Software Collections

How to enable Java console on RPM-based Linux systems

Java Console is a debugging tool which displays the standard output (System.out) and error (System.err) streams from applications and applets running through Java Web Start (javaws) or the Java Plugin (, respectively. It is particularly used for troubleshooting, but it is not enabled by default so it has to be activated first in the Java control panel. Moreover, the current official instructions to enable it are outdated (they apply to Java 6 only) and slightly different for the latest release Java 7.

The RPM version of the jre plugin installs to /usr/java by default (unless otherwise specified with e.g. rpm -ivh –root) so the following apply to RPM-based systems although it works fairly similar on other Linux distros.


Option 1 (CLI):


As stated in the instructions you can use the ControlPanel command which is in fact a symbolic link to the jcontrol shell script that launches the Java control panel.

$ locate ControlPanel
$ ls -l /usr/java/jre1.7.0_45/bin/ControlPanel
lrwxrwxrwx. 1 root root 8 Dec 22 12:34 /usr/java/jre1.7.0_45/bin/ControlPanel -> jcontrol
$ which jcontrol
$ type jcontrol
jcontrol is hashed (/usr/bin/jcontrol)

The output shows that jcontrol is in the user’s path so you can run it directly without specifying the full path. Either of the following will open up the control panel:



Option 2 (GUI):


The RPM package includes a menu entry for the Java control panel, but it is not installed by default. To install it just copy the following file as root to the applications menu (this works for CentOS 6 and GNOME 2, the destination path may be different for other distros or desktop environments):

cp /usr/java/default/lib/desktop/applications/sun_java.desktop /usr/share/applications/

The above creates an entry in System —> Preferences —> Java. If you’re running a non-standard theme you may have to modify the file to add the full path of the icon in case it doesn’t display.

$ grep Icon /usr/share/applications/sun_java.desktop

Once the control panel is displayed with either method, navigate to the Advanced tab, tick the Show console radio button under the Java console option and then click the Apply button to save the changes. From this point forward, launching a web page that runs Java applets will automatically trigger the Java console startup as a pop-up window. To test that, you can use the Verify Java page.

Nvidia introduces support for 3.11 and newer kernels

A week after releasing a new Beta driver 331.17 which didn’t compile by default on kernels >=3.11 Nvidia finally releases support for latest kernels in form of official patches that can be applied to the existing Nvidia driver installers. As of now the support is limited due to changes introduced by the Linux kernel starting with 3.11 and there are downsides in using these latest drivers on recent kernels running on machines with 128GB+ of RAM memory.

The patches work on all current development branches 304, 319 and 325-331 and they are not needed for the latest release of the legacy driver for Geforce FX series which added compatibility with recent kernels with 173.14.37.

Unlike other unofficial patches that needed to be applied against the unpacked Nvidia installer, the official patches can be passed as arguments to the installer and doing that generates a brand new custom installer. It is not clear to me why hasn’t Nvidia released official installers instead, but as they have stated all future driver installers will incorporate these patches.

I tried compiling both the latest driver from the long-lived branch as well as the beta one and had no issues with either. This is what I had to do on my Fedora 19 x86_64 running kernel 3.11 (the instructions are fairly similar for any Linux OS):


  • download the official Nvidia patches for kernel 3.11+

The patches are available here. Download them to your preferred location e.g. ~/Downloads/NVIDIA/


  • extract the patches from the tar archive

cd ~/Downloads/NVIDIA/
tar xf get_num_physpages_patches.tar


  • download the Nvidia drivers, patch them and run the custom installer


For 319.60 (64-bit):


sudo sh --apply-patch get_num_physpages_319.patch
sudo sh


For 331.17 (64-bit):


sudo sh --apply-patch get_num_physpages_325-331.patch
sudo sh


That’s it, both drivers compile fine and register with dkms without issues.


Running rsyslog v7 on CentOS6

I was inspired by today’s comments on my other rsyslog post and decided to write a small howto about upgrading the rsyslog daemon on CentOS 6 / RHEL 6. As you might know CentOS6 comes with rsyslog v5 by default and it is the only release available within the official repositories. The rsyslog developers however maintain 2 separate branches: v5 and v7. The latter is obviously newer and has a lot of improvements such as enhanced support for plugins and structured logging (main advantages, detailed v7 changelogs).

Upgrading to rsyslog v7 is easy and according to the project website it can be done on both CentOS/RHEL 5 and CentOS/RHEL 6. The developers provide RPM packages that are made available through a yum repository. On my CentOS 6 machine I did the following:


Install the yum repository


wget -O /etc/yum.repos.d/rsyslog.repo


Update rsyslog


yum update rsyslog

There are a few dependencies needed but they are all available in the official CentOS repositories except for json-c which is provided by EPEL. Upon a successful update the new logging daemon is already active, although it is still running the old /etc/rsyslog.conf so some features may be deprecated:

centos6 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="1646" x-info=""] exiting on signal 15.
centos6 rsyslogd: [origin software="rsyslogd" swVersion="7.4.5" x-pid="10370" x-info=""] start
centos6 rsyslogd-2307: warning: ~ action is deprecated, consider using the 'stop' statement instead [try ]
centos6 rsyslogd-2184: action '*' treated as ':omusrmsg:*' - please change syntax, '*' will not be supported in the future [try ]

Despite the old soon-to-be-decommissioned statements in the configuration file, I found that rsyslog v7 works fine on my CentOS 6 machine and I can also get updates through the newly installed repository.


Revert to the default version


That is easy. Considering you’ve tested rsyslog v7 and for whatever reasons you want to switch back to the default CentOS/RHEL version, simply downgrade the package:

yum --disablerepo=rsyslog_v7 downgrade rsyslog

The above command will temporarily disable the rsyslog repo, remove the current package and install the latest one available in the remaining active repositories. To prevent the package from updating to v7 again, either remove the repository completely or disable it permanently:

yum-config-manager --disable rsyslog_v7