Migrating from CentOS7 to RHEL7

There are various reasons why to migrate from CentOS to RHEL. Quicker access to bugfixes and new minor releases as well as having a fully commercially supported system.

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.

In 2012 I wrote an article about Migrating from CentOS6 to RHEL6. Now its time for an update.


Some of the procedures can be destructive for your system and/or your data. I’m not taking any responsibility for any damage casue. Take a full backup of your system before even thinking about trying this procedure!

Also import to note is that such a procedure is not supported by Redhat.


There are only two things you need

  • A valid RHEL subscription obtained from Redhats online store
  • A RHEL7 ISO-Image which corresponds with your current CentOS minor release (or newer) which can be downloaded at Redhat downloads


Be sure you activated your subscription.

Mount the ISO image on your CentOS7 machine:

[root@centos7 ~]# mount /dev/cdrom /mnt -o loop

Go to /mnt/Packages and install the packages we need:

[root@centos7 Packages]# yum -y localinstall subscription-manager-1.15.9-15.el7.x86_64.rpm

(Re)Move your CentOS repos
To avoid conflicts between CentOS and Redhat Repositories you need to get rid of them. Remove them or just keep a copy.

[root@centos7 Packages]# mkdir /etc/yum.repos.d.centos
[root@centos7 Packages]# mv /etc/yum.repos.d/CentOS-* /etc/yum.repos.d.centos

Force-remove the centos-release and yum RPMs

[root@centos7 Packages]# rpm -e yum --nodeps
[root@centos7 Packages]# rpm -ihv yum-3.4.3-132.el7.noarch.rpm
[root@centos7 Packages]# rpm -e centos-release --nodeps
[root@centos7 Packages]# yum localinstall redhat-release-server-7.2-9.el7.x86_64.rpm

Register your system

To get access to RHEL repositories, you need to register your system. The username “example@example.com” must be replaced with your username. The ID is a randomly generated UUID.

[root@centos7 ~]# subscription-manager register
Registering to: subscription.rhn.redhat.com:443/subscription
Username: example@example.com
The system has been registered with ID: e61bd536-854c-4f32-a1fa-7f75c37046a5  
[root@centos7 ~]# 

Attach the system to a subscription

Usually it is just good enough to auto-attach the subscription needed.

[root@centos7 ~]# subscription-manager attach --auto

Installed Product Current Status:
Product Name: Red Hat Enterprise Linux Server
Status:       Subscribed

[root@centos7 ~]# s

Review enabled repositories

Sometimes you dont want to use all the repos provided. The simplest way is just to disable all and re-enable those you need.

[root@centos7 ~]# subscription-manager repos --list
[root@centos7 ~]# subscription-manager repos --disable "*"
[root@centos7 ~]# subscription-manager repos --enable rhel-7-server-rpms --enable rhel-7-server-optional-rpms --enable whatever-else-you-need
[root@centos7 ~]# yum clean all

Changing the Distribution

Now we have all requirements met, lets reinstall the packages.

[root@centos7 ~]# yum reinstall "*" --exclude=filesystem
[ommited output]
 zlib                     x86_64 1.2.7-15.el7           rhel-7-server-rpms  90 k
Not available:
 dhclient                 x86_64 12:4.2.5-42.el7.centos -                  0.0  
 plymouth                 x86_64 0.8.9-0.24.20140113.el7.centos
                                                        -                  0.0  
 curl                     x86_64 7.29.0-25.el7.centos   -                  0.0  
 grub2-tools              x86_64 1:2.02-0.29.el7.centos -                  0.0  
 basesystem               noarch 10.0-7.el7.centos      -                  0.0  
 plymouth-core-libs       x86_64 0.8.9-0.24.20140113.el7.centos
                                                        -                  0.0  
 mariadb-libs             x86_64 1:5.5.44-2.el7.centos  -                  0.0  
 libcurl                  x86_64 7.29.0-25.el7.centos   -                  0.0  
 dhcp-libs                x86_64 12:4.2.5-42.el7.centos -                  0.0  
 plymouth-scripts         x86_64 0.8.9-0.24.20140113.el7.centos
                                                        -                  0.0  
 dhcp-common              x86_64 12:4.2.5-42.el7.centos -                  0.0  
 grub2                    x86_64 1:2.02-0.29.el7.centos -                  0.0  
 centos-logos             noarch 70.0.6-3.el7.centos    -                  0.0  

Transaction Summary
Reinstall      291 Packages
Not available   13 Packages

Total download size: 154 M
Installed size: 577 M
Is this ok [y/d/N]:

Here you can see the Centos specific packages, we need to take care about them later. Proceed and acknowledge with Y.


No we need to manually clean up the CentOS specific packages with are named [package-name-and-version]-centos.

[root@centos7 ~]# rpm -qa --queryformat "%{NAME} %{VENDOR}\n" | grep -i centos | cut -d' ' -f1
[root@centos7 ~]#

With some of the packages you need to proceed very careful, the i.e. filesystem package is awful. If you remove it, you will reinstall your system.

Luckily there is the rpm parameter –justdb which only does changes to the RPM-Database but not on the actual file system.

Some more critical packages need to be replaced as well.

[root@centos7 Packages]# rpm -e centos-logos plymouth plymouth-scripts plymouth-core-libs grub2 grub2-tools dhcp-common dhclient dhcp-libs curl libcurl --nodeps
[root@centos7 Packages]# rpm -i curl-7.29.0-25.el7.x86_64.rpm libcurl-7.29.0-25.el7.x86_64.rpm
[root@centos7 Packages]#  yum -y install plymouth plymouth-scripts plymouth-core-libs grub2 grub2-tools dhcp-common dhclient dhcp-libs
[root@centos7 ~]# yum remove basesystem
[root@centos7 ~]# yum -y install basesystem

Dirty Hardcore Hack, please be careful, use the –justdb parameter

[root@centos7 Packages]# rpm -e filesystem --nodeps --justdb
[root@centos7 Packages]# cp filesystem-3.2-20.el7.x86_64.rpm /root/
[root@centos7 Packages]# cd
[root@centos7 ~]# umount /mnt
[root@centos7 ~]# rpm -ihv filesystem-3.2-20.el7.x86_64.rpm 


Now update your system, reboot and check if all is working as expected. There may be more cleanup work to do.

[root@centos7 ~]# umount /mnt
[root@centos7 ~]# yum -y update && reboot


Check if there are still RPMs of vendor “Centos” installed:

[root@centos7 ~]# rpm -qa --queryformat "%{NAME} %{VENDOR}\n" | grep -i centos | cut -d' ' -f1

This should return nothing, almost all is now RHEL7. The only traces left are the previously install Kernels. They will get deleted over time when installing (updating) new Kernels.

In my case I just used CentOS7 minimal installation. The CentOS distribution comes with a total of 231 packages which need to be manually replaced if installed. If you plan to go down this road, please clone the system first for testing before migrating the actual system.

Support by Redhat

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

Better install RHEL in the first place ๐Ÿ™‚

Using (Free)IPA ID-Views with LDAP for your legacy servers

Having pain with user authentication on your old legacy Unix servers? Here comes the solution: ID-Views via LDAP.

If you need to preserve UID/GID or other stuff like shell on some legacy servers but want to have the benefits of a centrally managed identity management, then ID-Views is the answer. Since legacy servers usually do not have SSSD on board, such as traditional Unix Systems, you can also use LDAP to authenticate such users.

Use cases

You have different users with the same login ID but with different UID, GID shell, password etc. you can create User ID overrides and map them to your legacy users.

You can override the Shell. I.e. in AIX the Bash is in /usr/bin/bash and not like in Linux /bin/bash. Or you can set the Shell to /bin/ksh for AIX servers.

Be aware

On the long term you should clean up messy old environments as ID-views adds some complexity to your identity management. As those old kind of servers tend to be replaced with newer Linux distributions, they will die over the next years. At the end, ID-views can greatly help you during a transition period.

Test lab setup

  • Your IPA server is called ipa1.example.com
  • The example client is called ldap-view.example.com
  • The ID-View is called oldstuff
  • Example is named jdoe

What are ID-Views

Basically ID-Views are mappings of user credentials stored in a different LDAP base DN. This is: cn=myview,cn=views,cn=compat,dc=example,dc=com
where myview is replaced by the particular ID-View in this example “oldstuff”.

Underneath there are users and groups, so a complete ID-View DN for users would be cn=users,cn=oldstuff,cn=views,cn=compat,dc=example,dc=com.

Creating an ID-View

Log in to you IPA server and ensure you have a valid Kerberos Ticket for the admin user.

[root@ipa1 ~]# ipa idview-add --desc="Our old Unix Servers" oldstuff
Added ID View "oldstuff"
  ID View Name: oldstuff
  Description: Our old Unix Servers
[root@ipa1 ~]#

Next lets map a user. Lets assume that user jdoe need to have a login name of joe, a Korn shell, must be in the group with GIG 1002, has the UID of 1001 and has a home directory of /export/home instead of the standard values.

[root@ipa1 ~]# ipa idoverrideuser-add --desc="Overrides for Joe Doe" --shell=/bin/ksh --homedir=/export/home --uid=1001 --gidnumber=1002 oldstuff jdoe
Added User ID override "jdoe"
  Anchor to override: jdoe
  Description: Overrides for Joe Doe
  UID: 1001
  GID: 1002
  Home directory: /export/home
  Login shell: /bin/ksh
[root@ipa1 ~]# 

If you want to use this ID-view with SSSD and ipa-client enabled machines, you can assign hosts and host groups to the ID-view. As this article is just taking care of legacy LDAP clients, this is out-of-scope.

Client Configuration

This varies from Linux distribution to another, traditional Unix servers are even more different. If in doubt, please consult your vendors manual.

For some Linux distributions, IPA can give you some hints how to configure your client.

[root@ipa1 ~]# ipa-advise 
List of available advices
    config-fedora-authconfig             : Authconfig instructions for
                                           configuring Fedora 18/19 client with
                                           IPA server without use of SSSD.
    config-freebsd-nss-pam-ldapd         : Instructions for configuring a
                                           FreeBSD system with nss-pam-ldapd.
    config-generic-linux-nss-pam-ldapd   : Instructions for configuring a system
                                           with nss-pam-ldapd. This set of
                                           instructions is targeted for linux
                                           systems that do not include the
                                           authconfig utility.

<More output omitted>

Select the systems that match best for your system to configure. In my example I’ll use config-redhat-nss-pam-ldapd

[root@ipa1 ~]# ipa-advise config-redhat-nss-pam-ldapd
# ----------------------------------------------------------------------
# Instructions for configuring a system with nss-pam-ldapd as a IPA
# client. This set of instructions is targeted for platforms that
# include the authconfig utility, which are all Red Hat based platforms.
# ----------------------------------------------------------------------
# Schema Compatibility plugin has not been configured on this server. To
# configure it, run "ipa-adtrust-install --enable-compat"
# Install required packages via yum
yum install -y wget openssl nss-pam-ldapd pam_ldap authconfig

# NOTE: IPA certificate uses the SHA-256 hash function. SHA-256 was
# introduced in RHEL5.2. Therefore, clients older than RHEL5.2 will not
# be able to interoperate with IPA server 3.x.
# Please note that this script assumes /etc/openldap/cacerts as the
# default CA certificate location. If this value is different on your
# system the script needs to be modified accordingly.
# Download the CA certificate of the IPA server
mkdir -p -m 755 /etc/openldap/cacerts
wget http://ipa1.example.com/ipa/config/ca.crt -O /etc/openldap/cacerts/ipa.crt

# Generate hashes for the openldap library
command -v cacertdir_rehash
if [ $? -ne 0 ] ; then
 wget "https://fedorahosted.org/authconfig/browser/cacertdir_rehash?format=txt" -O cacertdir_rehash ;
 chmod 755 ./cacertdir_rehash ;
 ./cacertdir_rehash /etc/openldap/cacerts/ ;
 cacertdir_rehash /etc/openldap/cacerts/ ;

# Use the authconfig to configure nsswitch.conf and the PAM stack
authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=compat,dc=example,dc=com

Since this ipa-advice command is normally used for “standard” LDAP authentication, not for ID-Views. So we need to adjust the base DN to match the DN for the ID-View in question. The correct base DN for the example created above is cn=oldstuff,cn=views,cn=compat,dc=example,dc=com.

[root@ldap-view ~]# authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=oldstuff,cn=views,cn=compat,dc=example,dc=com -disablesssd --disablesssdauth
[root@ldap-view ~]# 

Optionally, you can also enable Kerberos:

[root@ldap-view ~]# authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=oldstuff,cn=views,cn=compat,dc=example,dc=com --disablesssd --disablesssdauth --enablekrb5 --enablekrb5kdcdns --enablekrb5realmdns
[root@ldap-view ~]# 

The script configures /etc/openldap/ldap.conf and /etc/nslcd.conf (and optionally /etc/krb5.conf) with the correct LDAP URI and base DN. On other systems, please consult your vendors manual on how to set those parameters.

Check the result

There are basically two methods to look up the user credentials: id and getent.

[root@ldap-view ~]# getent passwd jdoe
jdoe:*:1001:1002:John Doe:/export/home:/bin/ksh
[root@ldap-view ~]# 

Lets switch to that user

[root@ldap-view ~]# su - jdoe
Last login: Mon Nov 16 19:47:04 CET 2015 on pts/0
-ksh-4.2$ id
uid=1001(jdoe) gid=1002 groups=1002 context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023


UID and GID Ranges

A decade ago it was the fashion that numeric UIDs begin with 500. Modern Linux systems start at 1000 and this is also a restriction in PAM. Check every file in /etc/pam.d/ for uid >= 1000 and uid < 1000. Change them to the value you need for your legacy system.

HBAC (Host Based Access Control)

There is one problematic issue with Non-SSSD authentication: There is no centrally managed HBAC possible. You can achieve this in two ways: LDAP filtering and sshd configuration.

If you are using PAM only fro ssh access, then configuring sshd is less complex. Just add AllowGroups oldstuff
to /etc/ssh/sshd_config and restart the daemon.

However, there is pam_hbac which is currently being developed. PLease have a look at https://github.com/jhrozek/pam_hbac for more information.

Have fun? No, definitively not with old stuff dinosaur style computing. But at least its less painful ๐Ÿ˜‰

Integrate IPA in your Web application i.e. WordPress

Tired of log in to your favorite Web application? Integrate it with IPA, kerberize it! This blog post will guide you trough the kerberization of WordPress running on RHEL7 or Fedora. The magic is done by mod_intercept_form_submit and mod_auth_gssapi


  • You have a running IPA or FreeIPA infrastructure
  • Your Kerberos REALM is EXAMPLE.COM
  • The hostname where your WordPress instance is running is wptest.example.com
  • WordPress is installed in /var/www/html and ready to run
  • You are using a Linux Workstation with Kerberos, other client OS may or may not work
    • Result

      You can log in to your WordPress instance with a Kerberos enabled Web Browser and username/password with Browser not enabled. The access is restricted by HBAC (Host Base Access Control)

      Install the required software

      root@wptest ~]# yum -y install ipa-client mod_intercept_form_submit mod_auth_gssapi
      root@wptest ~]# setsebool -P allow_httpd_mod_auth_pam 1
      root@wptest ~]# wget https://downloads.wordpress.org/plugin/http-authentication.4.5.zip

      Ensure the modules are loaded by Apache, please check the files in /etc/httpd/conf.modules.d/. The WordPress plugin is needed to enable WordPress to make use of the REMOTE_USER server environment. Unzip and place it in /var/www/html/wp-content/plugins/ and run restorecon to relabel the content to be able to use SELinux in enforcing mode.

      root@wptest ~]# unzip http-authentication.4.5.zip
      root@wptest ~]# mv http-authentication /var/www/html/wp-content/plugins/
      root@wptest ~]# restorecon -v -R /var/www/html/

      Enroll your Linux server

      Of course your server must be enrolled with IPA.

      root@wptest ~]# ipa-client-install

      Get your Kerberos Keytab

      First the Kerberos service principal must be created. Go to one of your IPA servers and add the principal.

      root@ipa1 ~]# kinit admin
      root@ipa1 ~]# ipa service-add HTTP/wptest.example.com

      Go to the client, fetch the Kerberos Keytab and make it available for Apache

      root@wptest ~]# kinit admin
      root@wptest ~]# ipa-getkeytab -s ipa1.example.com -p HTTP/wptest.example.com -k /etc/httpd/conf/http.keytab
      root@wptest ~]# chown apache /etc/httpd/conf/http.keytab
      root@wptest ~]# chmod 600 /etc/httpd/conf/http.keytab

      Configure PAM

      We are going to create a PAM config file called “wordpress” as a requirement for the authentication method used. Remember, you need to use SSSD because want to make use of HBAC.

      cat << EOF >> /etc/pam.d/wordpress
      auth    required   pam_sss.so
      account required   pam_sss.so

      Hacking WordPress

      After the configuration of Apache, non-kerberized logins would not work anymore. This is probably not a scenario you want. You will still be able to log in with your IPA credentials, HBAC still works.

      The trick is that if Kerberos authentication fails, you will be redirected to a non-kerberized login page.

      [root@wptest ~]# cp /var/www/html/wp-login.php /var/www/html/wp-login2.php
      [root@wptest ~]# sed -i s/wp-login.php/wp-login.php /var/www/html/wp-login2.php
      [root@wptest ~]# restorecon -v /var/www/html/wp-login2.php

      Configure Apache

      The two different modules must be configured to get ready to use.

      Important to know: the parameters InterceptFormLogin and InterceptFormPassword are containing the name of the user and password input field name of the form, as defined in the HTML code. I.e. <input type=”text” name=”log” id=”user_login” …

      cat << EOF >> /etc/httpd/conf.d/intercept_form_submit.conf
      <LocationMatch ^/wp-login.php>
        InterceptFormPAMService wordpress
        InterceptFormLogin log
        InterceptFormPassword pwd
      <LocationMatch ^/wp-login2.php>
        InterceptFormPAMService wordpress
        InterceptFormLogin log
        InterceptFormPassword pwd

      The next configuration files is for the mod_auth_gssapi

      The interesting part is the ErrorDocument where you tell the browser to redirect to the previously created wp-login2.php form. Since that form is only protected by mod_intercept_form_submit there will be no Kerbros authentification and prompting the user for the username and password.

      cat << EOF >> /etc/httpd/conf.d/auth_gssapi.conf
      <Location "/wp-login.php">
        AuthType GSSAPI
        AuthName "Kerberos Login"
        GssapiCredStore keytab:/etc/httpd/conf/http.keytab
        GssapiCredStore client_keytab:/etc/httpd/conf/http.keytab
        GssapiDelegCcacheDir /var/run/httpd/clientcaches
        GssapiUseS4U2Proxy on
        Require pam-account wordpress
        ErrorDocument 401 '<html><meta http-equiv="refresh" content="5; URL=/wp-login2.php"><body><h1>Kerberos authentication did not pass</h1><h2>Make sure your browser is configured correctly and you got a Kerberos Ticket.</h2></body></html>'

      Configure the WordPress plugin

      Point your Browser to https://wptest.example.com/wp-admin/options-general.php?page=http-authentication%2Fhttp-authentication.php and set the following Parameters:

      • Allow WordPress authentication -> Enabled
      • Automatically create accounts -> Enabled
      • Email address domain -> Whatever the users domain is

      Now point your browser to http://wptest.example.com/wp-admin/options-general.php And select the default role of the users being created when logging in the first time.

      Create a HBAC rule

      Usually you want to create a HBAC rule to i.e. allow only certain users or group(s) of users to log in.
      Some time ago I wrote an article on how to do so.

      Restarting Apache

      Now it is time to restart your Apache Server to activate the settings.

      [root@wptest ~]# systemctl restart httpd.service

      Configure Firefox

      To be able to use Kerberos with Firefox, you need to set a few options. Please point your browser to one of your IPA repliacas, i.e. http://ipa1.example.com/ipa/config/browserconfig.html”

      Useful Links

      Have fun ๐Ÿ™‚ Feedback welcome..