Configure your Linux system

Desura on CentOS7

After a lot of time the Desura client for Linux finally received an update. It wasn’t without issues, many users complained about not being able to install it properly due to unresolved library dependencies. The latest release (build 120.26, as of today) still doesn’t work out of the box on CentOS 7, so here’s how to fix it.

I tested this on two separate instances of the 64-bit CentOS, so this applies to the 64-bit release of Desura (the 32-bit version doesn’t seem to be supported any more).


1. Desura is not installed


After downloading and extracting the latest installer to $HOME/Downloads/desura, the following error is displayed when attempting to start the client:

/home/lsc/Downloads/desura/lib/desura: error while loading shared libraries: cannot open shared object file: No such file or directory

To fix it we need to create a symlink to the required library after verifying it is installed:

rpm -qf /usr/lib64/
cd /home/lsc/Downloads/desura/lib
ln -s /usr/lib64/

Doing this allows desura to launch properly and perform an auto-update. After that everything works fine except for the application shortcut which is not added automatically to the start menu. To add it manually:

cp ~/Downloads/desura/desura.desktop /usr/share/applications


2. Desura is installed


If an older client was previously installed and updated, the above trick doesn’t seem to work. Forcing the desura update also failed on me. The fix was to download the latest client and extract it to the same installation path in order to overwrite existing files (this does not delete any game data stored in the common folder):

tar zxv --overwrite --overwrite-dir -f desura-x86_64.tar.gz -C /home/lsc/Downloads
ln -s /usr/lib64/ ~/Downloads/desura/lib/

Inplace migration from Oracle Linux 7 to CentOS 7

This is my 2nd attempt to migrate from Oracle Linux to CentOS; a while ago I tested it with success on OL6.4. This time I’m using an OL7 VM instance with a default desktop installation. Having 3rd party repositories installed on OL7 should not cause any issues when switching to CentOS as the RPMs from the EL7 repos are usually compatible with most EL7 clones, except for maybe drivers compiled against specific kernel versions such as Nvidia. I only had the EPEL repo configured with 1 or 2 packages installed, so I didn’t have any problems.


1. Make kernel-uek default and update the OS


Changing the default kernel (from kernel to kernel-uek) in /etc/sysconfig/kernel is not mandatory, as one can choose to boot a specific kernel while in the Grub2 menu. However, changing the file will automatically configure any new kernel-uek as default, which is what we need.

sed -i 's/DEFAULTKERNEL=kernel/DEFAULTKERNEL=kernel-uek/' /etc/sysconfig/kernel
yum update


2. Confirm kernel-uek is the default or otherwise select it manually


If the above yum command didn’t find any updates to the kernel RPMs, the Grub2 configuration hasn’t changed. In this case we can change the default kernel manually. The following tool returns the current default kernel:

grub2-editenv list

My OL 7 installation was using the Red Hat Compatible Kernel as default, so I changed it:

awk -F "'" '$1=="menuentry " {print $2}' /boot/grub2/grub.cfg
Oracle Linux Server, with Linux 3.10.0-123.el7.x86_64
Oracle Linux Server, with Linux 3.10.0-123.20.1.el7.x86_64
Oracle Linux Server, with Unbreakable Enterprise Kernel 3.8.13-55.1.5.el7uek.x86_64
Oracle Linux Server, with Unbreakable Enterprise Kernel 3.8.13-35.3.1.el7uek.x86_64
Oracle Linux Server, with Linux 0-rescue-f4f6b4c2976d454eade4da24993a1308
grub2-set-default 'Oracle Linux Server, with Unbreakable Enterprise Kernel 3.8.13-55.1.5.el7uek.x86_64'


3. Change the default target (runlevel) and restart


systemctl set-default


4. Install the CentOS repos


After rebooting into Oracle’s kernel UEK3 we are ready to proceed. First, remove Oracle-specific RPMs and install the CentOS repository files.

rpm --import
rpm -e --nodeps `rpm -qa | egrep 'redhat|oracle|rhn|uname26|libdtrace-ctf'`
yum install

[Read the rest of this entry…]

Randomizing cron scheduling across multiple servers

This is not about running cron at random hours every time on each server, but configuring different time schedules for multiple machines. This is especially useful when dealing with many servers as having the same cron entries on all of them might affect LAN / WAN bandwidth or increase load on the master server (yum internal repository, backup server) that all of the machines are trying to reach at the same time.

My approach on this is to write a small script to generate random hours / minutes /etc. and have that script run on each server. This can be done during kickstart installations (%post section) or at any time after the OS is installed (e.g. by installing an RPM package that includes crontab configuration or simply by pushing and triggering the script execution automatically).

Here is a sample shell coding which makes use of the shuf utility:


Generate random hours between 9AM-6PM:
MINS=`/usr/bin/shuf -i 1-59 -n 1`
HRS=`/usr/bin/shuf -i 9-17 -n 1`


Install crontab:


  • for root:
echo "$MINS $HRS * * *    $COMMAND" > /tmp/cronjob
cat /tmp/cronjob | crontab


  • for generic user:
echo "$MINS $HRS * * *    $COMMAND" | crontab -u $USER -

Hope this helps.

Enable verbose boot on RHEL-like distros

This might be a non-issue for most desktop users and also for some system administrators who don’t mind hitting the ESC key to exit the graphical boot when doing maintenance tasks remotely, but it is certainly annoying when having to do it over KVM sessions repeatedly. For some reason the two boot parameters rhgb (Red Hat Graphical Boot) and quiet (used to suppress descriptive boot messages) are always enabled by default with both EL6 and EL7.

I remember these 2 arguments had to be specifically added to the boot loader configuration in Kickstart installations of older RHEL releases, but that doesn’t seem to be the case any more as they are added automatically by anaconda to all non-s390 and non-serial installs:


grep -A1 rhgb /usr/lib/anaconda/
# Only add "rhgb quiet" on non-s390, non-serial installs
if iutil.isConsoleOnVirtualTerminal() and \
(ts.dbMatch('provides', 'rhgb').count() or \
ts.dbMatch('provides', 'plymouth').count()):"rhgb")"quiet")


Remove these arguments to enable verbose text boot


During OS installation using kickstart

Since there is no kickstart option to disable these boot options, we have to do it in the post install section:


  • RHEL6 (grub)
%post --log=/root/postinstall.log
sed -i 's/rhgb\|quiet//g' /boot/grub/grub.conf


  • RHEL7 (grub2)
%post --log=/root/postinstall.log
sed -i 's/rhgb\|quiet//g' /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg


After OS installation

When the OS is already installed, the same sed commands from above can be executed. If this boot configuration change needs to be applied to multiple servers, one can make use of a for / while loop (especially useful when dealing with hundreds of servers) e.g.


  • grub
   ssh $SERVER 'sed -i 's/rhgb\|quiet//g' /boot/grub/grub.conf'


  • grub2
cat $LIST_OF_SERVERS | while read SERVER;
   ssh $SERVER 'sed -i 's/rhgb\|quiet//g' /etc/default/grub ; grub2-mkconfig -o /boot/grub2/grub.cfg'

Hope this helps.