linuxsysconfig

Configure your Linux system

Inplace upgrade from OL6.5 to OL7

Oracle Linux 7 was released yesterday and I was keen to test the new upgrade feature after trying it on CentOS. As far as I know the CentOS inplace upgrade is still work in progress, so I expected Oracle Linux to perform better since they advertised it in the release notes and they also provide official instructions. Unfortunately I didn’t have the chance to test on Red Hat since I don’t own a customer subscription, but I can assume it will do fine, after all they were the ones who developed the upgrade tool in the first place.

Anyway, Oracle has published specific requirements for the upgrade like having the UEK3 (their Unbreakable Enterprise Kernel Release 3) set as the default kernel, the minimum package set installed for OL 6.5 (according to /usr/lib/anaconda/installclasses/enterprise.py that means the core package group) and also no running Oracle applications. I did my testing on a VM running Oracle Linux 6.5 under VirtualBox. Again, please note the following is just of proof of concept, don’t do this on production machines!

 

Add the addon repo

 

First thing after updating the OL 6.5 instance was to add the ol6_addons repository. For some reason, it wasn’t available in /etc/yum.repos.d/public-yum-ol6.repo so I had to edit the file and add it manually:

[ol6_addons]
name=Oracle Linux $releasever Add ons ($basearch)
baseurl=http://public-yum.oracle.com/repo/OracleLinux/OL6/addons/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1

Another option is to download the packages from the repo URL http://public-yum.oracle.com/repo/OracleLinux/OL6/addons/x86_64/ and install them manually with yum localinstall $package_name.

 

Install the rpms

 

yum install openscap preupgrade-assistant-contents redhat-upgrade-tool

 

Run preupgrade

 

preupg

The command completed successfully but it reported critical errors. Additional information is available in /root/preupgrade/result.html which is an html file that can be viewed in a web browser.

First warning:

We found some critical issues. In-place upgrade is not advised.

Since this was just a test I decided to ignore the warning and proceed. This time I used the OS DVD as the installation source, so the upgrade command is slightly different. The debug redirection is optional but useful to troubleshoot errors.

 

Run the upgrade tool

 

redhat-upgrade-tool-cli --device=/dev/sr0 --debuglog=/tmp/upgrade.log

Second warning:

preupgrade-assistant risk check found EXTREME risks for this upgrade.
Run preupg –riskcheck –verbose to view these risks.
Continuing with this upgrade is not recommended.

Again (and same as on CentOS) the command doesn’t run because of the failed preupgrade output. In my case I had GNOME installed and upgrade from GNOME 2 to GNOME 3 is not officially supported. I chose to force the upgrade anyway for the sake of testing.

redhat-upgrade-tool-cli --force --device=/dev/sr0 --debuglog=/tmp/upgrade.log

Forcing it did the trick so the pre-upgrade process completed successfully. Rebooting the machine entered the upgrade state by default and the whole process went through without glitches (there was no database environment version mismatch error). As expected, after reboot the OS didn’t boot to X, so I had to modify GRUB to enter runlevel 3 by default. Nonetheless it was a successful testing in my opinion, but I would have expected more from Oracle (at least some partial support for Oracle application stack).

As a side note, I don’t understand why Oracle still uses that garish red background for the default boot menu, it really hurts the eye and it doesn’t look enterprise at all.

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 http://dl.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.2.noarch.rpm

 

Install RPMForge repo

 

- same as EPEL

yum install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

 

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
[steam_fedora19]
name=Steam RPM packages (and dependencies) for Fedora
baseurl=http://negativo17.org/repos/steam/fedora-19/x86_64/
enabled=0
skip_if_unavailable=1
gpgcheck=0

 

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 http://download1.rpmfusion.org/free/fedora/releases/19/Everything/i386/os/libtxc_dxtn-1.0.0-3.fc19.i686.rpm

 

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
wget  http://dev.centos.org/centos/6/upg/x86_64/Packages/preupgrade-assistant-1.0.2-33.el6.x86_64.rpm http://dev.centos.org/centos/6/upg/x86_64/Packages/preupgrade-assistant-contents-0.5.13-1.el6.noarch.rpm http://dev.centos.org/centos/6/upg/x86_64/Packages/preupgrade-assistant-ui-1.0.2-33.el6.x86_64.rpm http://dev.centos.org/centos/6/upg/x86_64/Packages/python-rhsm-1.9.7-1.el6.x86_64.rpm http://dev.centos.org/centos/6/upg/x86_64/Packages/redhat-upgrade-tool-0.7.22-1.el6.noarch.rpm

 

Install preupgrade assistant

 

yum localinstall preupgrade-assistant-*

 

Run preupgrade assistant

 

preupg

 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 http://ftp.plusline.de/centos/7.0.1406/os/x86_64/RPM-GPG-KEY-CentOS-7

 

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 http://ftp.plusline.de/centos/7.0.1406/os/x86_64/

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 http://ftp.plusline.de/centos/7.0.1406/os/x86_64/ --force

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

 

Reboot

 

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/ http://jplesnik.fedorapeople.org/repository/perl516-collection.repo
yum install perl516
wget -P /etc/yum.repos.d/ http://people.redhat.com/bkabrda/scl_python33.repo
yum install python33

 

CentOS SCL

 

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

 

Usage

 

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
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