Archive for the ‘Uncategorized’ Category

Upgrading RHN Satellite 5.6 to 5.7

Sunday, February 8th, 2015

This post guides you trough the upgrade procedure for a Satellite 5.6 using the embedded database on RHEL6-x86_64. Further it guides you to setup of Kerberos authentication of Satellite users with IPA.

Recently Redhat released Satellite Server 5.7. Despite Satellite 5.x will be outphased in the next few years, there are plenty of new features. The most significant new features are:

  • Upgraded PostgreSQL to 9.2
  • Authentication via IPA/SSSD/Kerberos
  • IPMI support
  • Renewed WebUI
  • Readonly API users

And finally… drum roll…. formal support for spacecmd :-)

As always when you plan to upgrade your Satellite server to the latest version, you need to do some preparations first.

Download the ISO
As usual, visit the Download site and make sure you select 5.7 and the architecture fitting you system (x86_64 or S390)

Get a new Satellite Certificate
Satellite 5.7 needs a new certificate to get it activated. You can create it by your own at the Subscription Management Application site, ensure you attach enough subscriptions to your Satellite server(s). Alternatively open a support case.

Usually an upgrade runs smooth, but just in case… it is recommended practice to have a recent backup ready. If your Satellite is running on a virtual machine, power off, snapshot and power on to have a consistent backup ready. For physical systems, db-control and the choice of your backup software need to be visited.

Backup the rest of your Satellite:

Create a copy of your rhn configuration directory as we need some information from the old files after the upgrade.

[root@rhnsat ~]# cp -rp /etc/rhn/ /etc/rhn-$(date +"%F")

Update your OS and Satellite
First step is to update the operating system and the Satellite 5.6 and apply the latest database schema updates as well.

yum -y update && reboot

To update the database schema, run the following command. Ideally it looks as follows:

root@rhnsat ~]# spacewalk-schema-upgrade 

You are about to perform upgrade of your satellite-schema.

For general instructions on Red Hat Satellite schema upgrade, please consult
the following article:

Hit Enter to continue or Ctrl+C to interrupt: 
Schema upgrade: [satellite-schema-] -> [satellite-schema-]
Your database schema already matches the schema package version [satellite-schema-].
[root@rhnsat ~]# 

Functionality Check
It is recommended to restart and check a softwares functionality before upgrading to be able to pinpoint problems if there are some.

[root@rhnsat ~]# rhn-satellite restart

Its a good idea to review the software channels in use and delete unused channels as this can free up quite some diskspace and reduces the size of the database significantly.

[root@rhnsat ~]# spacewalk-remove-channel -c rhel-i386-rhev-agent-6-server
Deleting package metadata (20):
Removing:         ######################################## - complete
[root@rhnsat ~]#

Delete old system snapshots not used anymore. The following example deletes all snapshots which are older than one month:

[root@rhnsat ~]# sw-system-snapshot --delete --all --start-date 200001010000 --end-date $(date -d "-1 months" "+%Y%m%d0000" 

Remove spacecmd from EPEL
Most Satellite users have spacecmd installed from EPEL. Its a good idea to remove it to avoid conflicts. It is also important to disable the EPEL repositories on Satellite servers as a simple yum update can bring your Satellite server into trouble.

If not done yet, install the rhn-upgrade package which contains the instructions how to proceed.

yum -y install rhn-upgrade

The package contains not only SQL- and other useful scripts needed for the upgrade but also important documents to read. The are located in /etc/sysconfig/rhn/satellite-upgrade/doc.

For most users, the document satellite-upgrade-postgresql.txt applies.

Do not forget to read the updated product documentation as well:

Changing your file system layout
As there will be an updated PostgreSQL version needed which is part of the Software Collection and not installable from the base channel, you need to add a new file system in /opt/rh.
The new database is about the same size as before. Check your used disk space at /var/lib/pgsql

[root@rhnsat ~]# lvcreate /dev/vg_data -n lv_opt_rh -L 17G 
[root@rhnsat ~]# mkfs.ext4 /dev/vg_data/lv_opt_rh
[root@rhnsat ~]# tune2fs -c0 -i0  /dev/vg_data/lv_opt_rh

Exit your /etc/fstab accordingly and mount the file system with mount -a to check if it working as expected.

Lets do it
Mount the ISO image and run the installer.

[root@rhnsat ~]# mount satellite-5.7.0-20150108-rhel-6-x86_64.iso /mnt -o loop
[root@rhnsat ~]# cd /mnt
[root@rhnsat mnt]# 

If you are using a proxy to sync your satellite, provide the --diconnected flag.

[root@rhnsat mnt]# ./ --upgrade --disconnected
* Starting Red Hat Satellite installer.
* Performing pre-install checks.
* Pre-install checks complete.  Beginning installation.
* RHN Registration.
** Registration: Disconnected mode.  Not registering with RHN.
* Upgrade flag passed.  Stopping necessary services.
* Purging conflicting packages.
* Checking for uninstalled prerequisites.
** Checking if yum is available ...
There are some packages from Red Hat Enterprise Linux that are not part
of the @base group that Satellite will require to be installed on this
system. The installer will try resolve the dependencies automatically.
However, you may want to install these prerequisites manually.
Do you want the installer to resolve dependencies [y/N]? y
* Installing RHN packages.
* Now running spacewalk-setup.
* Setting up SELinux..
** Database: Setting up database connection for PostgreSQL backend.
*** Upgrading embedded database.
** Database: Populating database.
** Database: Skipping database population.
* Setting up users and groups.
** GPG: Initializing GPG and importing key.
* Performing initial configuration.
* Activating Red Hat Satellite.
** Certificate not activated.
** Upgrade process requires the certificate to be activated after the schema is upgraded.
* Enabling Monitoring.
* Configuring apache SSL virtual host.
Should setup configure apache's default ssl server for you (saves original ssl.conf) [Y]? y
* Configuring tomcat.
* Configuring jabberd.
* Creating SSL certificates.
** Skipping SSL certificate generation.
* Deploying configuration files.
* Update configuration in database.
* Setting up Cobbler..
task started: 2015-02-08_154708_sync
task started (id=Sync, time=Sun Feb  8 15:47:08 2015)
running pre-sync triggers
cleaning trees
removing: /var/www/cobbler/images/ks-rhel-x86_64-es-4-u6
running shell triggers from /var/lib/cobbler/triggers/change/*
Cobbler requires tftp and xinetd services be turned on for PXE provisioning functionality. Enable these services [Y]? y
This portion of the Red Hat Satellite upgrade process has successfully completed.
Please refer to appropriate upgrade document in /etc/sysconfig/rhn/satellite-upgrade
for any remaining steps in the process.
[root@rhnsat mnt]#

The next step is having a look at diff /etc/rhn/rhn.conf /etc/rhn-$(date +”%F”)/rhn.conf
and edit /etc/rhn/rhn.conf accordingly. You will probably see missing things such as proxy, server.satellite.rhn_parent etc. Also change the setting disconnected to 0.

Activate the updated Satellite server
To subscribe the Satellite server to the appropriate software channels, it must be activated. Since it was activated before, the --ignore-version-mismatch parameter must be provided.

[root@rhnsat ~]# rhn-satellite-activate --rhn-cert=rhn-satellite57-2015-02-08.xml --ignore-version-mismatch

Initial Update of Software and database schema
There is a good chance that there are updates available for the Satellite Server as the ISO image will not be updated that often.

[root@rhnsat ~]# yum -y update

Even if no update was installed, there is a schema update available:

[root@rhnsat ~]# spacewalk-schema-upgrade 
Schema upgrade: [satellite-schema-] -> [satellite-schema-]
Searching for upgrade path: [satellite-schema-] -> [satellite-schema-]
Searching for upgrade path: [satellite-schema-] -> [satellite-schema-]
Searching for upgrade path: [satellite-schema-5.6.0] -> [satellite-schema-5.7.0]
Searching for upgrade path: [satellite-schema-5.6] -> [satellite-schema-5.7]
The path: [satellite-schema-5.6] -> [satellite-schema-5.7]
Planning to run spacewalk-sql with [/var/log/spacewalk/schema-upgrade/20150208-155657-script.sql]

Plase make sure you have a valid backup of your database before continuing.

Hit Enter to continue or Ctrl+C to interrupt: 
Executing spacewalk-sql, the log is in [/var/log/spacewalk/schema-upgrade/20150208-155657-to-satellite-schema-5.7.log].
The database schema was upgraded to version [satellite-schema-].
[root@rhnsat ~]# 

After startarting the Satellite Server, the package meta data should be automatically recreated. If not, run
/etc/sysconfig/rhn/satellite-upgrade/scriptsregenerate-repodata manually.

Rebuild the search index:

[root@rhnsat ~]# service rhn-search cleanindex

You don’t need to remove the old PostgreSQL version, this is done automatically.

Using IPA and Kerberos for authentication
Before configure the Satellite Server to use IPA, make sure it is enrolled and the HTTP service principal exists. If not, add it with the following command:

[root@ipa1 ~]# ipa-addservice HTTP/

Next will be getting a Kerbros Ticket of a user allowed to create Keytabs. In this example it is the user admin.

[root@rhnsat ~]# kinit admin
Password for admin@EXAMPLE.COM: 
[root@rhnsat ~]# 

Afterwards, run the setup script:

[root@rhnsat ~]# spacewalk-setup-ipa-authentication
Enabling authentication against [].
Retrieving HTTP/ service keytab into [/etc/httpd/conf/http.keytab] ...
Keytab successfully retrieved and stored in: /etc/httpd/conf/http.keytab
changed ownership of `/etc/httpd/conf/http.keytab' to apache
Configuring PAM service [spacewalk].
Will install additional packages ...
Loaded plugins: product-id, rhnplugin, security, subscription-manager
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package mod_auth_kerb.x86_64 0:5.4-13.el6 will be installed
---> Package mod_authnz_pam.x86_64 0:0.9.2-1.el6 will be installed
---> Package mod_intercept_form_submit.x86_64 0:0.9.7-1.el6 will be installed
---> Package mod_lookup_identity.x86_64 0:0.9.2-1.el6 will be installed
---> Package sssd-dbus.x86_64 0:1.11.6-30.el6_6.3 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

 Package                                      Arch                      Version                               Repository                               Size
 mod_auth_kerb                                x86_64                    5.4-13.el6                            rhel-x86_64-server-6                     30 k
 mod_authnz_pam                               x86_64                    0.9.2-1.el6                           rhel-x86_64-server-6                     13 k
 mod_intercept_form_submit                    x86_64                    0.9.7-1.el6                           rhel-x86_64-server-6                     17 k
 mod_lookup_identity                          x86_64                    0.9.2-1.el6                           rhel-x86_64-server-6                     19 k
 sssd-dbus                                    x86_64                    1.11.6-30.el6_6.3                     rhel-x86_64-server-6                    122 k

Transaction Summary
Install       5 Package(s)

Total download size: 201 k
Installed size: 0  
Downloading Packages:
(1/5): mod_auth_kerb-5.4-13.el6.x86_64.rpm                                                                                           |  30 kB     00:00     
(2/5): mod_authnz_pam-0.9.2-1.el6.x86_64.rpm                                                                                         |  13 kB     00:00     
(3/5): mod_intercept_form_submit-0.9.7-1.el6.x86_64.rpm                                                                              |  17 kB     00:00     
(4/5): mod_lookup_identity-0.9.2-1.el6.x86_64.rpm                                                                                    |  19 kB     00:00     
(5/5): sssd-dbus-1.11.6-30.el6_6.3.x86_64.rpm                                                                                        | 122 kB     00:00     
Total                                                                                                                        41 kB/s | 201 kB     00:04     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : mod_authnz_pam-0.9.2-1.el6.x86_64                                                                                                        1/5 
  Installing : mod_intercept_form_submit-0.9.7-1.el6.x86_64                                                                                             2/5 
  Installing : mod_auth_kerb-5.4-13.el6.x86_64                                                                                                          3/5 
  Installing : mod_lookup_identity-0.9.2-1.el6.x86_64                                                                                                   4/5 
  Installing : sssd-dbus-1.11.6-30.el6_6.3.x86_64                                                                                                       5/5 
  Verifying  : mod_intercept_form_submit-0.9.7-1.el6.x86_64                                                                                             1/5 
  Verifying  : sssd-dbus-1.11.6-30.el6_6.3.x86_64                                                                                                       2/5 
  Verifying  : mod_lookup_identity-0.9.2-1.el6.x86_64                                                                                                   3/5 
  Verifying  : mod_authnz_pam-0.9.2-1.el6.x86_64                                                                                                        4/5 
  Verifying  : mod_auth_kerb-5.4-13.el6.x86_64                                                                                                          5/5 

  mod_auth_kerb.x86_64 0:5.4-13.el6                  mod_authnz_pam.x86_64 0:0.9.2-1.el6            mod_intercept_form_submit.x86_64 0:0.9.7-1.el6          
  mod_lookup_identity.x86_64 0:0.9.2-1.el6           sssd-dbus.x86_64 0:1.11.6-30.el6_6.3          

** /etc/sssd/sssd.conf has been backed up to sssd.conf-swsave
Updated sssd configuration.
Turning SELinux boolean [httpd_dbus_sssd] on ...
        ... done.
Turning SELinux boolean [allow_httpd_mod_auth_pam] on ...

        ... done.
Configuring Apache modules.
** /etc/tomcat6/server.xml has been backed up to server.xml-swsave.ipa
Stopping sssd:                                             [  OK  ]
Starting sssd:                                             [  OK  ]
Stopping tomcat6:                                          [  OK  ]
Starting tomcat6:                                          [  OK  ]
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]
Waiting for tomcat to be ready ...
Authentication against [] sucessfully enabled.
As admin, at Admin > Users > External Authentication, select
          Default organization to autopopulate new users into.
[root@rhnsat ~]# 

Next, point your browser to to finalize the setup.

Configure your browser for Kerberos
If you did not yet configured your browser to use Kerberos authentication, do so. Assuming you are using an IPA invironment, follow the instructions provided on the IPA servers.

I take no responsibility about damaged Satellites, lost of data etc. in doubt, stick on the official product documentation at

Why journalctl is cool and syslog will survive for another decade

Wednesday, July 24th, 2013

There was a recent discussion going on if Fedora 20 should drop rsyslog and just using systemd journal. A lot of people are afraid of systemd and its journal, this a pity.

Well, there are pros and cons about this kind of logging. For System administrators daily use, journalctl is a powerful tool simplifying the hunt for log file entries.

On the other hand, there are AFAIK no monitoring tools (yet) that can work with journalctl. Those first need to be developed. A Nagios plug-in should be implemented quite quickly.

Why makes journalctl the life easier?
Instead of grepping trough thousands of lines in /var/log/messages you simply can filter the messages and work on them.

journalctl has auto completion (just hit the tab key) showing you the options to use. I.e.

fedora:~# journalctl  < TAB > 
_AUDIT_SESSION=              _PID=
_BOOT_ID=                    PRIORITY=
_CMDLINE=                    __REALTIME_TIMESTAMP=
CODE_FILE=                   _SELINUX_CONTEXT=
CODE_LINE=                   SYSLOG_FACILITY=
_COMM=                       SYSLOG_IDENTIFIER=
COREDUMP_EXE=                SYSLOG_PID=
__CURSOR=                    _SYSTEMD_CGROUP=
ERRNO=                       _SYSTEMD_OWNER_UID=
_EXE=                        _SYSTEMD_SESSION=
_GID=                        _SYSTEMD_UNIT=
_HOSTNAME=                   _TRANSPORT=
_MACHINE_ID=                 _UDEV_SYSNAME=
MESSAGE=                     _UID=
fedora:~# journalctl 

Quite some filtering options available here. Most of this options are self-explanatory.

If you just want to see the entries made by a particular command, issue journalctl _COMM= and the TAB key.

fedora:~# journalctl _COMM=
abrtd            dnsmasq          mtp-probe        sh               tgtd
anacron          gnome-keyring-d  network          smartd           udisksd
avahi-daemon     hddtemp          polkit-agent-he  smbd             umount
bash             journal2gelf     polkitd          sshd             userhelper
blueman-mechani  kdumpctl         pulseaudio       sssd_be          yum
chronyd          krb5_child       qemu-system-x86  su               
colord           libvirtd         sealert          sudo             
crond            logger           sendmail         systemd          
dbus-daemon      mcelog           setroubleshootd  systemd-journal  
fedora:~# journalctl _COMM=

If you enter journalctl _COMM=sshd you will just see the messages created by sshd.

fedora:~# journalctl _COMM=sshd 
-- Logs begin at Tue 2013-07-23 08:46:28 CEST, end at Wed 2013-07-24 11:10:01 CEST. --
Jul 23 09:48:45 sshd[2172]: Server listening on port 22.
Jul 23 09:48:45 sshd[2172]: Server listening on :: port 22.

Usually one is just interested in messages within a particular time range.

fedora:~# journalctl _COMM=crond --since "10:00" --until "11:00"
-- Logs begin at Tue 2013-07-23 08:46:28 CEST, end at Wed 2013-07-24 11:23:25 CEST. --
Jul 24 10:20:01 CROND[28305]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jul 24 10:50:01 CROND[28684]: (root) CMD (/usr/lib64/sa/sa1 1 1)

And why will rsyslog stay another decade or even longer?

There are a lot of tools and scripts which are in place since a long time, some of them even come from a time before Linux was born.

Most of those scripts must be rewritten or at least change its behaviour. I.e taking input from STDIN instead of a log file, so those tools can digest the output from journalctl|

For log digesting tools that are needed to be compatible between different Unix and Linux Systems they probably wont be changed. In this case syslogd will survive until the last of those systems is decommissioned.

Further reading

Creating a PHP application on Openshift

Saturday, June 8th, 2013

What is OpenShift? It is a cloud, it is from Red Hat. More precisely: A PaaS (Platform As A Service).

It is available since quite some time now and I finally found some time to test it. Conclusion: It is very simple to use. This will guide you how to create a PHP application which just prints “this is a test”. More to come in future postings.

The following steps are needed:

  • Create an account
  • Installing the CLI and setting up your environment
  • Create an application
  • Initialize a git repository
  • Put some content into your git repository
  • Push/publish your application

It is a good idea to start reading”.

Create an account
Simply head to and fill in the form. The captcha can be a hassle, you may need to try reading it correctly several times.

Setting up your environment
before being able to use your account, you need to install and set up some software on your developer workstation. Of course you also can go for the “Wimp Way” and using the web-UI, but real men use the CLI for higher productivity.

The following steps I used on my Fedora 18 box:

f18:~# yum install rubygems git

Next, install the CLI tool. The simplest way to do so is using gem.

f18:~# gem install rhc
Fetching: net-ssh-2.6.7.gem (100%)
Fetching: archive-tar-minitar-0.5.2.gem (100%)
Fetching: highline-1.6.19.gem (100%)
Fetching: commander-4.1.3.gem (100%)
Fetching: httpclient-2.3.3.gem (100%)
Fetching: open4-1.3.0.gem (100%)
Fetching: rhc-1.9.6.gem (100%)

If this is your first time installing the RHC tools, please run 'rhc setup'

Successfully installed net-ssh-2.6.7
Successfully installed archive-tar-minitar-0.5.2
Successfully installed highline-1.6.19
Successfully installed commander-4.1.3
Successfully installed httpclient-2.3.3
Successfully installed open4-1.3.0
Successfully installed rhc-1.9.6
7 gems installed
Installing ri documentation for net-ssh-2.6.7...
Installing ri documentation for archive-tar-minitar-0.5.2...
Installing ri documentation for highline-1.6.19...
Installing ri documentation for commander-4.1.3...
Installing ri documentation for httpclient-2.3.3...
Installing ri documentation for open4-1.3.0...
Installing ri documentation for rhc-1.9.6...
Installing RDoc documentation for net-ssh-2.6.7...
Installing RDoc documentation for archive-tar-minitar-0.5.2...
Installing RDoc documentation for highline-1.6.19...
Installing RDoc documentation for commander-4.1.3...
Installing RDoc documentation for httpclient-2.3.3...
Installing RDoc documentation for open4-1.3.0...
Installing RDoc documentation for rhc-1.9.6...

Just to be sure there are not updates available:

f18:~# gem update rhc
Updating installed gems
Nothing to update

Next on the list is to set up your credentials and evironment. It is wizard style and will guide you trough the process.

[luc@f18 ~]$ rhc setup
OpenShift Client Tools (RHC) Setup Wizard

This wizard will help you upload your SSH keys, set your application namespace, and check that other programs like Git are properly

Login to
Password: **********

OpenShift can create and store a token on disk which allows to you to access the server without using your password. The key is stored
in your home directory and should be kept secret.  You can delete the key at any time by running 'rhc logout'.
Generate a token now? (yes|no) yes
Generating an authorization token for this client ... lasts about 1 day

Saving configuration to /home/luc/.openshift/express.conf ... done

Your public SSH key must be uploaded to the OpenShift server to access code.  Upload now? (yes|no) yes

Since you do not have any keys associated with your OpenShift account, your new key will be uploaded as the 'default' key.

Uploading key 'default' ... done

Checking for git ... found git version

Checking common problems .. done

Checking your namespace ... none

Your namespace is unique to your account and is the suffix of the public URLs we assign to your applications. You may configure your
namespace here or leave it blank and use 'rhc create-domain' to create a namespace later.  You will not be able to create applications
without first creating a namespace.

Please enter a namespace (letters and numbers only) ||: ldelouw
Your domain name 'ldelouw' has been successfully created

Checking for applications ... none

Run 'rhc create-app' to create your first application.
Your client tools are now configured.

Create an application
Now as your environment is nearly finished setting up you can create your application instance on OpenShift.

[luc@f18 ~]$ rhc create-app test zend-5.6
Application Options
  Namespace:  ldelouw
  Cartridges: zend-5.6
  Gear Size:  default
  Scaling:    no

Creating application 'test' ... done

Waiting for your DNS name to be available ... done

Downloading the application Git repository ...
Cloning into 'test'...
The authenticity of host ' ()' can't be established.
RSA key fingerprint is a-finger-print.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.

Your application code is now in 'test'

test @ (uuid: a-uuid)
  Created: 5:22 PM
  Gears:   1 (defaults to small)
  Git URL: ssh://

  zend-5.6 (Zend Server 5.6)
    Gears: 1 small

Application test was created.
Note: You should set password for the Zend Server Console at:
Zend Server 5.6 started successfully

As mentioned in the output, you shoud proceed to

Initialize a git repository

This is not very clear in Red Hats documentation. When creating an application on OpenShift, a git repository is created to you. In order to push your app, you need to clone that repository locally or adding an upstream git master. Lets do it locally for now:

[luc@f18 ~]$ cd ~/your-project-directory

[luc@f18 your-project-directory]$ git clone ssh://
Cloning into 'test'...
remote: Counting objects: 26, done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 26 (delta 2), reused 20 (delta 0)
Receiving objects: 100% (26/26), 6.99 KiB, done.
Resolving deltas: 100% (2/2), done.

Put some content into your git repository
What a git repository and an application instance without some content? Nothing, so lets change that.

[luc@f18 your-project-directory]$ cat <<EOF>test/php/test.php
print "this is a test";

Adding your project file to the git repository:

git add test.php

Commit it:

git commit

And push it:

[luc@f18 your-project-directory]$ git push
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 398 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: CLIENT_MESSAGE: Stopping Zend Server Console
remote: Stopping Zend Server GUI [Lighttpd] [OK]
remote: CLIENT_MESSAGE: Stopping Zend Server JobQueue daemon
remote: Stopping JobQueue [OK]
remote: CLIENT_MESSAGE: Stopping Apache
remote: CLIENT_MESSAGE: Stopping Zend Server Monitor node
remote: Stopping Zend Server Monitor node [OK]
remote: CLIENT_MESSAGE: Stopping Zend Server Deployment daemon
remote: Stopping Deployment [OK]
remote: CLIENT_RESULT: Zend Server 5.6 stopped successfully
remote: TODO
remote: CLIENT_MESSAGE: Starting Zend Server Deployment daemon
remote: Starting Deployment [OK]
remote: [08.06.2013 11:36:30 SYSTEM] watchdog for zdd is running. 
remote: [08.06.2013 11:36:30 SYSTEM] zdd is running. 
remote: CLIENT_MESSAGE: Starting Zend Server Monitor node
remote: Starting Zend Server Monitor node [OK]
remote: [08.06.2013 11:36:31 SYSTEM] watchdog for monitor is running. 
remote: [08.06.2013 11:36:31 SYSTEM] monitor is running. 
remote: CLIENT_MESSAGE: Starting Apache
remote: CLIENT_MESSAGE: Starting Zend Server JobQueue daemon
remote: Starting JobQueue [OK]
remote: [08.06.2013 11:36:34 SYSTEM] watchdog for jqd is running. 
remote: [08.06.2013 11:36:34 SYSTEM] jqd is running. 
remote: CLIENT_MESSAGE: Starting Zend Server Console
remote: spawn-fcgi: child spawned successfully: PID: 1433
remote: Starting Zend Server GUI [Lighttpd] [OK]
remote: [08.06.2013 11:36:36 SYSTEM] watchdog for lighttpd is running. 
remote: [08.06.2013 11:36:36 SYSTEM] lighttpd is running. 
remote: CLIENT_RESULT: Zend Server 5.6 started successfully
To ssh://
   xxxxx..yyyy  master -> master
[luc@f18 your-project-directory]$

Did it all worked?

Lets try…

[luc@bond test]$ wget --quiet -O -|grep test
this is a test
[luc@bond test]$ 


RHEV 3.1 – an overview about the new features

Sunday, December 9th, 2012


Recently Red Hat announced the public availability of RHEV 3.1.

Finally, no more Windows needed for the whole software stack :-)

In 3.0, the new webadmin interface was already inncluded, as a tech preview and had its problems. Now with 3.1 its working great and looks neat. In contrary to 3.0, it is now listening on the standard ports 80 and 443. This will probably help users in organizations with strict proxy policies and setting.

So what else is new?

The supported number of virtual CPUs in a guest is now ridiculous 160, and RAM per guest is at ridiculous two Terabytes. But this are the least import updates.

Especially on the storage side, a lot of effort has been done and long missing features integrated.

From my point of view, the most important new feature is the possibility to have disks from more than one Storage Domain attached to a virtual machine. This would allow to install the Operating system to cheap SATA storage while data disks are super fast SSDs.

There is also support for live snapshots, but snapshots are (as on other platforms) kind of problematic because they are COW (Copy-On-Write). This can lead to I/O performance problems. Snapshots are a cool feature for i.e. taking a snapshot before updating software etc. Be sure you remove the snapshot afterwards if you want to keep a good I/O performance.

You now can use DirectLUN directly from the GUI without the usage of hooks. DirectLUN allows to attach FibreChannel and iSCSI LUNs directly to a Virtual Machine. This is great when you want to use shared filesystems such as GFS.

Another nice feature is Live Storage Migration which is a technical preview, means: Unsupported for the moment. It probably will be supported in a later version. Storage live migration is a nice feature when you need to free up some space on a storage domain and you can not shut down a VM. Be sure to power-cycle the VM in question as soon as your SLA allows it, to get rid of the Snapshot (COW here again).

If you want to script stuff or you are too lazy to open a brower, there is now a CLI available. Have a look to the documentation.

If you want to integrate RHEV deeper into your existing infrastructure, such as RHN Satellite, Cobbler, Your-super-duper-CMDB or IaaS/PaaS broker, there are two different APIs available. For the XML lovers, there is the previously known RestAPI which has some performance improvements. For the XML haters, there is now a native Python API which allows to to access RHEV entities directly as objects in your Python code. For both APIs, have a look to the Documentation.

I personally like the Python API, because a lot of other Red Hat infrastructure products come with Python APIs. So it is very easy to integrate those software pieces.

Under the hood, it is now powered by JBoss EAP6 instead of version 5. To be able to connect to standard ports 80 and 443, there is an Apache httpd with mod_proxy_ajp.

Have fun :-)

How to recover from a lost Kerberos password for admin

Saturday, December 8th, 2012

Ever lost your password for the admin principle on your Linux Kerberos server? It is quite easy to recover by just setting a new one.

You just need to log in to your KDC and proceed as follows:

[root@ipa1 ~]# kadmin.local
Authenticating as principal admin/admin@EXAMPLE.COM with password.
kadmin.local:  change_password admin@EXAMPLE.COM
Enter password for principal "admin@EXAMPLE.COM": 
Re-enter password for principal "admin@EXAMPLE.COM": 
Password for "admin@EXAMPLE.COM" changed.
kadmin.local: q
[root@ipa1 ~]#

Now enter kinit to get a Kerberos ticket.

Have fun :-)

Migrating from CentOS6 to RHEL6

Saturday, December 8th, 2012

There are different tutorial on the net how to migrate from RHEL to CentOS but almost no information about the other way round. It is quite simple and at the end of the day you have only Red Hat Packages installed.

you need to copy the following packages from a Red Hat medium and install them:

yum localinstall \
rhn-check-1.0.0-87.el6.noarch.rpm \
rhn-client-tools-1.0.0-87.el6.noarch.rpm \
rhnlib-2.5.22-12.el6.noarch.rpm \
rhnsd-4.9.3-2.el6.x86_64.rpm \
rhn-setup-1.0.0-87.el6.noarch.rpm \
yum-3.2.29-30.el6.noarch.rpm \
yum-metadata-parser-1.1.2-16.el6.x86_64.rpm \
yum-rhn-plugin-0.9.1-40.el6.noarch.rpm \
yum-utils-1.1.30-14.el6.noarch.rpm \
sos-2.2-29.el6.noarch.rpm \

Then you need to remove the centos release package and install the Red Hat release package:

rpm -e centos-release-6-3.el6.centos.9.x86_64 --nodeps
yum localinstall redhat-release-server-6Server-

Now it is time to register your system at RHN with rhn_register

After the successful registration you need to replace all CentOS packages by the RPMs provided by Red Hat:

yum reinstall "*"

To be sure there are no new configuration files to take care of run the following:

yum install mlocate.x86_64
locate rpmnew

Go through the list and check if there is some configuration work to do

Update your machine to the latest and greatest versions of packages and reboot your machine

yum -y update && reboot

Query the RPM database for leftovers from CentOS:

rpm -qa --queryformat "%{NAME} %{VENDOR}\n" | grep -i centos | cut -d' ' -f1

There are some problematic packages which has “centos” in its name, i.e yum and dhcp

rpm -e yum --nodeps
rpm -ihv yum-3.2.29-30.el6.noarch.rpm

At the end, you have the previously installed kernel packages left. Keep them as a backup, they will be automatically uninstalled after two more kernel updates.

Is the procedure supported by Red Hat? No it is not supported.

Will the converted machine be supported after this procedure? Well, officially it is not supported, but if there are no traces of CentOS on the machine…

Have fun :-)

How to get a RTL2832U based DVB-T stick working on Fedora 17

Sunday, September 16th, 2012

This week I bought a no-name DVB-T stick with the risk to not getting it working with Linux. The device contains a RTL2832u chip which seems to be quite common according to this list. The price tag was just €14, so I was taking the risk.

First experiments shown that there is no chance to get it running on Fedora 17. After digging deeper I figured out that someone wrote a driver and published it on github.

Later on, I figured out that there is a driver also available in upstreams 3.6rc Kernel. Unfortunately the Kernel shipped with Fedora 17 does not support the device yet.

Steps to do

Ensure you have installed the kernel headers package that match your running kernel version. If not, run yum -y install kernel-headers. The package dvb-apps will help you to set up the channels later on, install it with yum -y install dvb-apps

Getting and compiling the kernel module

git clone
cd DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0/RTL2832-2.2.2_kernel-3.0.0/
make && make install

Afterwards you need to scan your DVB-T stick for stations and put it into mplayers channels file. In /usr/share/dvb/dvb-t/ you will find the right setting the region you are living. For me de-Berlin is the right one.

scandvb /usr/share/dvb/dvb-t/de-Berlin -o zap >> ~/.mplayer/channels.conf

Now you are ready to watch digital terrestrial TV on you Fedora box. mplayer "dvb://Das Erste" does the job.

A more comfortable player is kaffeine which has features like EPG (electronic Program Guide), recording facilities etc. It comes with KDE.

Have fun!

Identity Management with IPA Part II – Kerberized NFS service

Sunday, December 25th, 2011

In part one I was writing how to set up an IPA server for basic user authentication.

One reason NFSv4 is not that widespreaded yet, is it needs Kerberos for proper operation. Of course this is now much easier thanks to IPA.

Goal for the part of the guide

  • Configure IPA to serve the NFS principle
  • Configure NFS to use IPA
  • Configure some IPA clients to use Kerberos for the NFS service


  • A runing IPA service like discussed in Part I of this guide.
  • A NFS server based on RHEL6.2
  • One or more IPA-Client

Lets doit
First you need to add the NFS server and its service principal to the IPA server. On run:

[root@ipa1 ~]# ipa host-add
[root@ipa1 ~]# ipa service-add nfs/

Next, log on to you NFS server, lets call it and install the needed additional software packages:

[root@nfs ~]# yum -y install ipa-client nfs-utils

You need to enroll you NFS-server on the IPA domain. Run the following on

[root@nfs ~]# ipa-client-install -p admin

The next step is to get a Kerberos ticket and fetch the entries needed to be added in the krb5.keytab

[root@nfs ~]# kinit admin
[root@nfs ~]# ipa-getkeytab -s -p nfs/ -k /etc/krb5.keytab

Before you proceed to your clients, you need to enable secure NFS, create an export and restart NFS:

[root@nfs ~]# perl -npe 's/#SECURE_NFS="yes"/SECURE_NFS="yes"/g' -i /etc/sysconfig/nfs
[root@nfs ~]# echo "/home  *(rw,sec=sys:krb5:krb5i:krb5p)" >> /etc/exports
[root@nfs ~]# mkdir /home/tester1 && cp /etc/skel/.bash* /home/tester && chmod 700 /home/tester1 && chown -R tester1:ipausers /home/tester1
[root@nfs ~]# service nfs restart

Assuming you already have set up one or more IPA-client(s), it is stright forward to enable kerberized NFS on your systems. Log in to a client and run the following:

[root@ipaclient1 ~]# yum -y install nfs-utils
[root@ipaclient1 ~]# perl -npe 's/#SECURE_NFS="yes"/SECURE_NFS="yes"/g' -i /etc/sysconfig/nfs
[root@ipaclient1 ~]# 

Lets have a look if you have been successful. First look up the users UID.

[root@ipaclient1 ~]# getent passwd tester1
tester1:*:1037700500:1037700500:Hans Tester:/home/tester1:/bin/bash
[root@ipaclient1 ~]# 

Lets mount that users home directory manually on a client:

mount -t nfs4 /home/tester1

To check if is working as expected, issue

[root@ipaclient1 ~]# su - tester1

Fire ls -lan and see if the UID matches the UID you got from getent. If you see UID 4294967294, then something went wrong, this is the UID for the user “nobody” when using NFSv4 on 64 bit machines.

Whats next?
You will figure out when I post part III of this guide :-)

Have fun!

I got employed by Red Hat

Thursday, April 21st, 2011

This is pretty cool: End of March I signed a contract with Red Hat as a senior Linux consultant. It is not just “another new job”. It is cool for (at least) two reasons: First reason is that Red Hat is not “just another company”, it is Red Hat which is not very comparable to other employers, it is THE Linux and open source company, for me as a open source guy, this is perfect. The second reason is: I’m moving from Zurich in Switzerland to Berlin in Germany.

So, two major changes in my life at the same time. I’m looking forward to the challenges that are waiting for me.

I’ll continue to work at Siemens IT Solutions and Services AG until approx. mid of June and start working at Red Hat at 1st of July.

From May, 09 to May 15. I’ll be the first time in Berlin to have a look at the city and its different suburbs. I’ll also be there to organize some stuff required to settle in Berlin. In the same time, Europe’s biggest Linux conference will be held in Berlin, the “Linux Tag”. I guess I’ll have a lot of fun, and maybe meet some of my future workmates.

It is hard for me to leave my country, I have a lot of friends here. On the other hand, Berlin is just about 1.5h away by plane. As a consultant, I’m travelling a lot. Because of that, it would not be that easy to build up a social network (I mean real-life-stuff, not Facebook) in Berlin.

It also is not easy for me to leave Siemens, I’m involved in a very cool project with the Swiss government (all Systems will be RHEL6) and I also have friends and nice workmates at work which I’m going to leave.

I already know quite some people at Red Hat, they are all nice and I guess some of them will get good friends over the time.

Having fun?

Absolutely guaranteed!

I voted for beefy miracle

Thursday, April 7th, 2011

Beefy miracle


There is a open poll on voting for a name for Fedora 16. I gave my vote to Beefy Miracle. Why I voted for Beefy Miracle? Because it is cool, geeky, freaky, I’m loving hot dogs and it is something new.

The Fedora distribution is geeky, freaky and open to new stuff.

Having fun? Of course!