Posts Tagged ‘CentOS’

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

CentOS6 to be released in the next few weeks

Wednesday, February 16th, 2011

According to an interview with Karanbir Singh – a major contributor to the project – it is just a question of a few weeks until we can expect CentOS6 to be released.

CentOS is extremely important for the RHEL community, it is a playground for trying out new stuff before getting into an engineering phase with the Red Hat supported RHEL.

Lets have fun with it…

IUS Community RPMs for Red Hats RHEL

Sunday, May 16th, 2010

I was criticizing that software in RHEL is too outdated for web servers quite soon after release, see my blog post While this is true for a system fully supported by Red Hat, I learned an alternative from a comment on the post. This alternative is the so called IUS community repository.

About the IUS Community Project
The project was launched in September 2009. In spite of being a young project, it has a history. At Rackspace, a large hosting company which is operating thousands of production (web) servers, it was an internal project since 2006. They decided to build up a community around it, like Fedora is for RHEL, Quote: “IUS is The Fedora of Rackspace RPMS”

Like for other community repositories out there, you cannot expect a “official” support neither from Red Hat nor from IUS or Rackspace. Of course there are the usual support sources for communities such as forums, IRC, bugtracker etc.

The difference to other repositories
While most community repositories such as EPEL, rpmforge etc. are focused on providing missing software, IUS focuses on providing upgrades for web server related software which is included in RHEL. This includes PHP, Python, MySQL and others.

Package conflicts with the stock distribution
One may think replace stock software with newer version is tricky and create conflicts. There is one way to find out: Lets give it a try…

The test
The server is a basic install of the yesterday released Centos 5.5. The following installation turns this machine in a lightweight LAMP server:

yum install httpd php-mysql php php-cli php-common php-pgsql php-dba php-pdo php-gd mysql-server perl-DBD-MySQL.

Now we have the situation like it exists in many companies: An outdated webserver. Now we want to upgrade PHP to 5.3.x. Lets see what happens.

[root@centos5 ~]# rpm -i
warning: /var/tmp/rpm-xfer.o6JH6k: Header V3 DSA signature: NOKEY, key ID 9cd4953f
[root@centos5 ~]# rpm -i
warning: /var/tmp/rpm-xfer.MRnuo8: Header V3 DSA signature: NOKEY, key ID 9cd4953f
package epel-release-5-3.noarch (which is newer than epel-release-1-1.ius.el5.noarch) is already installed
[root@centos5 ~]#

Hmm… no GPG key…
The second output is confusing me. Is the package just a clone of epel-release-5-3.noarch? Lets go forward to see if it is working.

“yum clean-all && yum check-update” did not show any pending updates, so far so good. Now lets try to upgrade php.

root@centos5 ~]# yum install php53
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons:
* base:
* epel:
* extras:
* ius:
* updates:
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package php53.x86_64 0:5.3.2-3.ius.el5 set to be updated
--> Processing Dependency: php53-common = 5.3.2-3.ius.el5 for package: php53
--> Processing Dependency: php53-cli = 5.3.2-3.ius.el5 for package: php53
--> Processing Dependency: php53-pear >= 1:1.8 for package: php53

[omitted output]

--> Processing Conflict: php53 conflicts php < 5.3
--> Finished Dependency Resolution
php53-5.3.2-3.ius.el5.x86_64 from ius has depsolving problems
--> php53 conflicts with php
Error: php53 conflicts with php
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest
The program package-cleanup is found in the yum-utils package.

Correct behaviour, since it is a replacement package. After removing php (and only php) yum was complaining about more conflicts. After removing all php related packages installed to prepare for the test, needed to be removed. So the dependencies has been proper solved. Also the installation of related stock distribution packages such as “php-pgsql” has been successfully prevented.

The IUS community repositories are working as expected. With such a basic test I cannot promise if there are not hidden conflicts with packages between stock RHEL/CentOS packages and those from IUS. The experience on the long term will bring more clarity. I think is is sane to do some real-life tests with servers that are in an early project phase.

Further readings:

Have fun!

CentOS 5.5 released

Sunday, May 16th, 2010

On May 15, the CentOS project released version 5.5 of its enterprise Linux. It is based on the sources of RHEL5.5 which was released on March, 31.

Unfortunately they – like always – removed the rhn-client-tools and friends from upstream. This is a pity, since it takes more efforts to manage CentOS-installation in Spacewalk.

For the full release notes have a look at

Have fun!

Spacewalk 1.0 released

Sunday, May 2nd, 2010


Spacewalk 1.0 has been released

Spacewalk is the upstream project for Red Hat’s RHN Satellite software, one of the best systems management software available for Linux Systems.

In the past few weeks one could see a lot of git commits on the source repository of spacewalk. There is no changelog available yet. The road map mentioned compatibility with Apache Tomcat 6.0.x to be able to install spacewalk on Fedora12 and RHEL6.

There should have also been several enhancements in the phyton API and long awaited feature enhancements such as host-renaming (confirmed). Further repository synchronization should be much faster now (Announced in a earlier feature note).

Sorry folks, a lot of “should”, “maybe” etc. I just have been reading the git commit logs and the announcement of the 1.0 release. As long as there is not official changelog available we only can speculate on the precise enhancements.

I’ll install this on my test system soon. If something really uncommon happens or an astonishing new feature appeared, I’ll let you know,

Have fun!

Set up a Red Hat Directory Server and Kerberos Part I

Thursday, November 5th, 2009

Kerberos and LDAP are today’s way of single sign on. It is platform independent and supported by a wide range of applications.

Together with the Red Hat Directory Server (also available as CentOS Directory Server and 389 Directory Server from Fedora) you can build a neat identity management infrastructure.

Setting up the Directory Server
However there are some pitfalls when installing such a integrated solution. Installing redhat-ds is quite easy, just ensure you define your planned LDAP Namespace and default LDAP Suffix before running If you plan to setup a replica, run the script with the -k parameter: -k. The servers configuration will be saved as /tmp/setup*.inf and can be used to setup the replica after changing the FullMachineName and ServerIdentifier.

In my example I used the DN “cn=Directory Manager. As base I used dc=ldap,dc=example,dc=com. This is the Internet Domain Suffix style of naming an LDAP space. The older X500 style should not be used anymore.

Have a look to man openldap.conf to see how to shorten your CLI entries such as ldapsearch -x.

Setting up Kerberos
After setting the right configurations in your /etc/krb5.conf (the sample content is self-explanatory) and its distribution, you need to initialize your key store database. This is to be done with kdb_util as follows:

[root@server]# kdb5_util create -r EXAMPLE.COM -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

Keep in mind! Kerberos Realms are all uppercase to distinguish them from DNS names!

In the config file for the Key Distribution Center /var/kerberos/krb5kd/kdc.conf add the following in Realm Stanza: default_principal_flags =+ preauth. This will enhance security or your Kerberos Infrastructure. Also change the example Realm to what you are going to plan to use. In /var/kerberos/krb5kd/ kadm5.acl you can define the ACLs for e.g. admins or service desk employees etc. Also check the correctness of the Realm.

Feed the keystore

Now it is time to feed the database with the first principal: root. We also can create our first host principal at the same time.
Fire up kadmin.local. The kadmin.local app accesses directly the DB files on the server. Its should only be used on initial setup. Later on you will have kadmin which also works on the net, of course with Kerberos authentication.

[root@server ~]# kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local:  addprinc root/admin
WARNING: no policy specified for root/admin@EXAMPLE.COM; defaulting to no policy
Enter password for principal "root/admin@EXAMPLE.COM":
Re-enter password for principal "root/admin@EXAMPLE.COM":
Principal "root/admin@EXAMPLE.COM" created.
kadmin.local:  addprinc -randkey host/
WARNING: no policy specified for host/; defaulting to no policy
Principal "host/" created.
kadmin.local:  q
[root@server ~]#

After starting the kadmin and kdc services you can access the admin server with the normal kamin tool.

service kadmin start
chkconfig kadmin on
service krb5kdc start
chkconfig krb5kdc on

Now we need to create a host principal for each to be kerberized host and store it in its keytab.

End of Part I

What comes in Part II?

  • LDAP Service Principal
  • Getting Kerberos and LDAP working together
  • Migrating users from /etc/passwd to LDAP
  • Playing with PAM

Have fun!

Managing CentOS with Spacewalk

Monday, November 2nd, 2009


Red Hat RHN Satellite

In 2003 Red Hat released its RHN Satellite server as a closed source management tool for RHEL and only for RHEL (okay, a legacy support for managing Solaris is available). The satellite is very useful tool for managing systems. Unfortunately it has a quite expensive price tag on it. According to the Red Hats RHN FAQ the bill is USD 13,500/year.

Additionally to the RHN satellite subscription fee you need at least a subscription for the management module which costs another USD 96/year and system. Assume you have a farm of 100 RHEL boxes it costs you about USD 23,100 every year. All prices are list prices.

RHN Satellite comes with an embedded Oracle Database which is from my point of view completely overkill and the driver for the high cost of the subscription. If Red Hat witches to PostgreSQL, I see some chances for lower price tags…

The alternative

In 2008 Red Hat open-sourced the RHN Satellite and named itĀ  “Spacewalk” (a pretty cool name :-) ). Since then the development team already released six versions. The release cycle is quite short in a fast pace.

Release 0.6 is PostgreSQL “ready” whatever that means, I do not know how reliable it is. Full support for PostgreSQL is scheduled with version 1.0 due in Q1/2010. However, for a smaller farm of CentOS systems the free Oracle express edition is good enough.


The installation is straight forward: Just follow the Instructions how to set up Oracle XE and spacewalk. After the a little tricky installation and configuration of Oracle, you just need to add some yum repositories and run the set up script.

Uploading packages

There are basically to methods to put your RPMs to the Spacewalk server. Either trough yum repository synchronization or via rhnpush. The first method is great if you want to pull a CentOS repository, the second for additional own packages.

Bootstrapping clients

After you installed a new system, you need to add the rhn-client packages to your CentOS system. Unfortunately CentOS removes those packages from the upstream RHEL versions. I hope they will rethink about this.

If you set up your systems by provisioning with Spacewalk, you can automate this task. However I did not got the time yet to test the provisioning stuff with cobbler and kickstart files, its on the to-do list.

Manual bootstrapping works similar to the method like you bootstrap RHEL clients to a RHN Satellite.

Updates and Errata

At the moment this is the tricky part. How to get the upstream errata into Spacewalk? You can use Script that imports digests from the centos-annouce mailing list. Afterwards applying erratas to your systems works fine.

Integrate Spacewalk with other applications

Spacewalk, like RHN Satellite comes with a XML-RPC API which allows you to trigger actions from scrips or (web-)applications. I think about reporting an similar to-be-automated stuff.


If you do not need support from Red Hat, Spacewalk and CentOS can be an alternative for your server farm. If you like more up-to-date systems (e.g. for desktops), Fedora is also supported as a client platform.

Since Red Hat does not provide some kind of Test-Licenses of its products, Spacewalk and CentOSĀ  are also a very nice playground for people managing RHEL systems on a daily base either to familiarize them self with the Satellite or doing some tests without bringing the production Satellite into danger.

Further readings

Unfortunately, beside of Red Hats documentations and the Spacewalk Wiki no books and other resources are available. Maybe I should start writing a book? ;-)

Spacewalk Wiki:

Red Hats Spacewalk homepage:

Red Hat RHN Satellite documentations:

Have fun!