Novell Home

Migrating Red Hat applications to SUSE --Technical Overview

Novell Cool Solutions: Feature
By Paul MacKay

Digg This - Slashdot This

Posted: 16 Nov 2004
 

Abstract

This document is a technical overview of the process of migrating Red Hat applications to SUSE Linux. Specific references are mentioned for detailed information.

Introduction

Linux is Linux, so applications written for Linux should work on any distribution. Right? Well, almost. Although the core components of Linux are the same across distributions, for technical, philosophical, and business reasons there are differences that developers need to understand in order to "migrate" an existing application from one Linux distribution to another (in our case Red Hat to SUSE).

An application written and supported on Red Hat may run on SUSE (if the application follows industry standards), but there are other areas to understand to fully support SUSE Linux.

This article takes you through the paths of migrating a Red Hat application to support SUSE Linux with references to detailed information along the way.

Getting Ready to Go: Writing Portable Code

Before describing specific areas regarding how you can migrate your application from Red Hat to SUSE, it is first important to ensure your code is "clean and portable". This is important for several reasons.

First, SUSE (and recently Red Hat) supports many different computer architectures (32bit, 64bit, i386, PowerPC, Mainframe etc.). If possible, you should not limit your application to just a subset of SUSE supported architectures unless there are good technical and business reasons.

Second, because heterogeneous systems are the reality of today in our computing environments, having applications that store/produce data which can only be written/read on a single type of architecture is limiting.

Third, SUSE uses a single source tree to build Linux for all supported architectures. By doing so, many quality and stability issues are resolved by having portable code that compiles and runs on various architectures. Now it may not be practical for you to have all SUSE supported architectures to build and test on, but compiling and testing on at least one other architecture is still beneficial.

There are many books and articles written about writing portable code (see resources). Some key points (mainly for C and C++ programmers) to remember are:

  1. Be aware of "little endian and big endian" issues.
  2. Don't assume "char" is signed or unsigned.
  3. Never assume the size of a structure (always use sizeof() ).
  4. Floats do not have the same size as doubles.
  5. Always create function prototypes. Use option -Wstrict-prototypes with gcc. This will warn you about missing function prototypes, or prototypes that are not being obeyed.
  6. Avoid #ifdef it is problematic.
  7. Avoid absolute addresses and don't assume a high-order bit (i.e. 31-bit mode systems).
  8. Use POSIX interfaces and data types.
  9. Store data in text format (i.e. XML) or network binary format.
  10. Use standard, non-distribution specific tools (gcc, make, etc.)

First Stop: LSB/FHS

In migrating an application from Red Hat to SUSE Linux another major area to look at is whether or not the application follows the Linux Standard Base (LSB) and Filesystem Hierarchy Standard (FHS) specifications.

What are the LSB and FHS specifications? They are a set of industry specifications adopted by the Linux community to help ensure application binary and installation compatibility across distributions.

The goal of LSB is:

To develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system ...

Some of the main goals of FHS are:

  • Protect OS vendor files from being overwritten by 3rd party applications.
  • Protect 3rd party applications from being overwritten by OS vendor updates.
  • Promote organization and consistency for end users.
  • Keep static data separate from variable data so that directories containing static data can be read-only.

Applications that follow the LSB and FHS specifications ensure binary compatibility between Red Hat and SUSE Linux distributions. Applications also are assured that they are installable on the distributions (assuming the environment is LSB compliant -- which SUSE is by default).

IBM and others have created an excellent guide that outlines the steps necessary for developing LSB compliant applications.

Getting as close to being LSB/FHS compliant as possible is a major step to migrating Red Hat applications to SUSE.

On the Road Again: Packaging Applications

Continuing the journey of migrating Red Hat applications to SUSE requires some changes in how your applications are packaged.

The rpm format for application packaging was created by Red Hat and is considered the 'standard' by most Linux distributions. SUSE is one of those distributions that has standardized on rpm for application packaging.

The design goals for rpm are:

  1. Make it easy to get packages on and off the system.
  2. Make it easy to verify that a package was installed correctly.
  3. Make it easy for the package builder.
  4. Make the build process start with the original source code.
  5. Make it work on different computer architectures.

There are many "How-to's" and tutorials on creating rpms (see Resources). Be sure to also consult the LSB specification which describes how to create rpms that will run and install properly on LSB compliant systems. Having LSB compliant rpms should be a mandatory requirement for your application.

By default Red Hat does not pre-install the required LSB components necessary for LSB compliant rpms. If you cannot require lsb.rpm to be pre-installed on Red Hat you will need to support both Red Hat specific conventions and LSB specifications. To create rpms that will work in this situation, consult the Novell article: How To Create RPMs and Init Scripts That Are Compatible On Both SUSE Linux and Red Hat Linux.

Next Stop: Creating SUSE "Friendly" Source RPMs

Binary rpms should be created from source rpms. This seems logical but this is not always the case. SUSE provides a utility called build that streamlines the rpm creation process and ensures configuration and system uniformity. It does this in a chroot environment.

The key in creating an rpm spec file that build can use is to add one extra line to the spec file. The line BuildRequires specifies all of the package dependencies, i.e. all rpms that are required to be installed into the build environment in order for the source package to compile.

To use build you must first install the build.rpm. You invoke build (as root since we need to do a chroot) with the package's BuildRequires enhanced rpm spec file as the argument. The build command then initializes the build environment by installing all of the required packages necessary to compile the given rpm package. build then copies all of the source files, patch files and the rpm spec file into a build area. The new build area becomes the "new" root in which build will operate. The patches are then applied to the original source files and then the package is compiled. The successful result of executing build is the binary rpm (and a repackage source rpm is also generated).

Enabling your application to be built using build ensures a reproducible build environment that doesn't get corrupted by the host's environment and vice versa.

A Nice Souvenir Along The Way: YaST

After building your rpm (hopefully in an LSB compliant way and using build), you have the option of making your software "Yet another Setup Tool" (YaST) enabled. On SUSE Linux, YaST is used to install and manage rpms and administer, monitor, manage and configure the overall SUSE environment.

The goal of YaST is to make administration and management of SUSE Linux as easy as possible. YaST manages all of the system configuration data behind the scenes and yet allows the user the freedom of manual configuration and editing of the system data if they so desire.

If your application requires some type of configuration and/or administration, being YaST enabled allows users to benefit from YaST's uniform interface for such activities.

YaST is, by design, modular. You can create YaST modules for you application using YaST API's. YaST modules are written in the YaST Control Language (YCP) and Perl.

To create a YaST module you need the yast2-devel package which contains developer documentation. The documentation on how to write a YaST module is found in the ?/usr/share/doc/packages/yast2-core? directory. Another helpful package is yast2-devtools. All of these packages are available on the SUSE Linux SDK.

A good way to start creating a YaST module is by looking at existing system YaST modules. A ?best practice? to follow is to separate a module's user interface and logic code. A YaST module's user interface is placed in the ?/usr/share/YaST2/include/<MODULE_NAME>? directory. The module's logic code is placed in ?/usr/share/yast2/modules? directory which contains the YCP code and compiled byte code. Some useful user interface widget examples are found in ?/usr/share/doc/packages/yas2-core/libyui/examples?.

Sundry Items Along The Way: Version Checking, Configuration, etc.

Version Checking

At times like during installation or execution an application needs to know the currently installed SUSE Linux product and version. The file /etc/SUSE-release contains such information. For example:

/etc/SUSE-release
SUSE Linux Server 9 (i586)    

VERSION = 9

Journey's End: Turning Red (Red Hat) into Green (SUSE)

An application written for Red Hat Linux can be migrated to run on SUSE Linux. The path to accomplish this doesn't have too many "hills to climb". Writing portable code and being LSB/FHS compliant are the first major steps to be taken. Other integration points (such as YaST) can be implemented to make the application more integrated with the SUSE Linux environment.

Have a lot of fun!

Resources


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell