Configure your Linux system

How to install Steam on CentOS 7

CentOS 7 is out and it will likely prove to be a great alternative for Fedora. CentOS 6 was also a good choice, but it lacked many features of a modern desktop since its core was based on Fedora 12-13. The latest CentOS 7 derives from RHEL 7 which is primarily based on Fedora 19 “with several changes from 20 and later” and that gives it a great advantage over its predecessor.

I wanted to test the Steam native client as I never managed to install it properly on CentOS 6. It was one of the few reasons I still use Fedora on my PC (I’m not much into running the “latest and greatest” apps and features), but I am happy to say the new CentOS works flawlessly so I am seriously considering the switch.

My test was done on a machine which was recently installed with CentOS 7 using the GNOME desktop installation option. To install the Steam client I used the Fedora 19 official repository for Steam which is binary compatible with CentOS 7.

Here’s the detailed steps:


Install EPEL repo


- this is not mandatory but could prove beneficial for other package installations

yum install


Install RPMForge repo


- same as EPEL

yum install


Configure the official Steam repo


- output is for 64bit, for 32bit replace x86_64 in baseurl with i386 (you can browse all other repos here)

cat /etc/yum.repos.d/steam_fedora19.repo
name=Steam RPM packages (and dependencies) for Fedora


Install a dependency


- This is the only dependency not yet available via the standard or compatible repositories. Note that Steam on Linux is only 32-bit at the moment so install this even if you’re running a 64-bit OS

yum install


Install Steam


yum --enablerepo=steam_fedora19 install steam

Done, the Steam client installs successfully! To launch it either use the start entry in Applications –> Games or run it in the terminal with steam. Enjoy!

more on Steam under Linux

Upgrade to CentOS 7

Last month Red Hat released RHEL 7 and few days ago CentOS announced the GA of CentOS 7. As you may know, starting RHEL 7 Red Hat introduces support for upgrading to major releases (RHEL 6.5 –> RHEL 7) via a tool called redhat-upgrade-tool. Not sure if this is 100% supported by CentOS at this time, but I found the CentOS rpm packages on their development site and thought of giving them a try and luckily it turned out OK.

Of course this is only a proof of concept, it may possibly not work by default on production environments, so use with care. For my test I used a fully updated base installation of CentOS 6.5 VM running on VirtualBox.


Download required packages


mkdir -p /root/upgrade
cd /root/upgrade


Install preupgrade assistant


yum localinstall preupgrade-assistant-*


Run preupgrade assistant



 This does a check on the installed system and tries to identify potential issues after the upgrade. It should be run until all tests pass successfully. Not sure it did anything on my VM as all tests returned “not applicable”. I haven’t used the original tool (for RHEL7) but I suspect the CentOS equivalent is still work in progress, so I decided to skip it. More info on the preupgrade assistant is available in the RedHat official documentation.


Install redhat-upgrade-tool


yum localinstall redhat-upgrade-tool-0.7.22-1.el6.noarch.rpm python-rhsm-1.9.7-1.el6.x86_64.rpm


Import the CentOS 7 rpm gpg key


rpm --import


Run the upgrade tool


The tool can use a local ISO, the local media drive or a network URL to perform the upgrade. The network command argument needs to be followed by a release version (rawhide is also supported) and a valid installation repository (at the time of this writing not all repositories were updated or reachable, so I did some trial and error until I found a working repo) which can be defined as a standard URL or a mirror (full mirror list is available here).

redhat-upgrade-tool --network 7.0 --instrepo

Should this warn you that you didn’t run the upgrade assistant, you can force its execution by adding the extra option:

redhat-upgrade-tool --network 7.0 --instrepo --force

A successful run ends with this message: “Finished. Reboot to start upgrade.




After restarting the machine, the OS will boot a new grub entry called System Upgrade which is supposed to upgrade all packages previously downloaded by the upgrade tool. I ran into a small problem here “Database environment version mismatch” likely caused by the rpm tool itself (rpm version is 4.11 in CentOS 7 and 4.8 in CentOS 6).

cd /mnt/var/lib/rpm
rm __*
init 6

Removing the rpm database files and rebooting worked for me (CTRL+D or exiting the shell should also work as that would exit the emergency mode and continue from the last step before the error occurred) and the upgrade went through without other issues.

cat /etc/centos-release
CentOS Linux release 7.0.1406 (Core)


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.