Porting Red Hat Applications to SUSE® LINUX

Paul MacKay

Software Engineer

Novell, Inc.

Why are you here?

What are the main differences between Red Hat Linux and SUSE LINUX?

How do you port/migrate Red Hat applications to SUSE LINUX?

Differences
Between Red Hat and SUSE LINUX

Major Differences

Filesystem Hierarchy and Installation

init Scripts

RPM Macro scripts

Compilers and Libraries

Filesystem Hierarchy

SUSE LINUX adheres strictly to the Filesystem Hierarchy Standard (FHS)

The FHS:

“Consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended so support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems.”

Filesystem Hierarchy Conventions

Software packages should be installed in:

“/opt/<package>” or “/opt/<provider>” directory not in “/usr/local” or in system directories (“/bin”, “/usr/bin” etc.)

Host-specific configuration files must be installed in:

“/etc/opt/” not in “/etc”

Package files that are variable must be installed in:

“/var/opt” not in “/var”

Services data must reside in:

“/srv” e.g “/srv/ftp/”, “/srv/www” not in ”/etc/httpd”

init Scripts

Installed in “/etc/init.d” not in “/etc/rc.d/init.d”

Not adhering to the LSB standard for init scripts

Should use Required-Start, Required-Stop, Provides in the INIT INFO comment area instead of relying only on chkconfig and symbolic links in “/etc/rc.d/rc[012345].d”

RPM Macros

Differences in where and what RPM Macros are provided

For SUSE: “/usr/lib/rpm”

For Red Hat: “/usr/lib/rpm/macros”

“/usr/lib/rpm/redhat/macros”

Compilers and Libraries

Red Hat uses gcc version 2.96

This is not an officially released version of gcc

Red Hat has made changes that may create incompatible code on other systems

Compiled code using Red Hat's gcc 2.96 version may not run on SUSE (or other Linux distros)

Using the NPTL in kernel version 2.4 may not exist on target system (SUSE version 8 and lower)

*Since RedHat 7.0 until RedHat Advance Server 3.0 where they now use gcc version 3.2

How to Port/Migrate Red Hat Applications
to SUSE LINUX

How to Port/Migrate Applications

Write Portable Code

See:“Filesytem Hierarchy Standard version 2.3

1

2

3

4

5

Take Advantage of SUSE Enhancements

Use SUSE Build Tool to Create RPMs

Create SUSE Compatible RPMs

Be LSB/FHS Compliant

Write Portable Code

Writing Portable Code

Make your code “clean and portable”

Be aware of “little endian and big endian” issues

Store data in text format (i.e. XML) or in network binary format

Do not assume “char” is signed or unsigned

Never assume the size of a structure (always use sizeof() )

Floats do not have the same size as doubles

Use POSIX interfaces and data types

Use standard, non-distribution specific tool chain (gcc, make, binutils etc.)

Do not limit your code to 32bit architectures

Be LSB/FHS Compliant

LSB's Mission Statement

* See http://www.linuxbase.org

Mission Statement*:

To develop and promote a set of standards that will increase compatibility among Linux distributions

To enable software applications to run on any LSB compliant system

To help coordinate efforts to recruit software vendors to port and write software products for Linux

What is the LSB?

The LSB is a workgroup of the Free Standards Group

Often, the LSB is referred to as a written specification to which applications and distributions must adhere to be LSB compliant/certified

The LSB provides a sample implementation, a test suite, and a development environment

Systems can be LSB certified via conformance to the LSB Test Suite and by paying money (e.g. SUSE 9.1 is LSB v1.3 certified)

LSB

What is the LSB Specification?

The LSB specification is a collection of several industry standard specifications (FHS, various ABIs, System V Interface definition, Single Unix Specification, OpenGL, X11, etc.)

The specification consists of a common (generic) standard for all LSB implementations and architecture-specific specifications for various processor architectures

The LSB specification describes how packages must be named and the package format (RPM version 3.0)

FHS Goals

To enable software to predict the location of installed files and directories

To enable users to predict the location of installed files and directories

How Does The FHS Achieve Its Goals?

By specifying guiding principles for placement of files and directories

See:“Filesytem Hierarchy Standard version 2.3

By enumerating specific cases where there have been historical conflicts

By enumerating exceptions to the principles

By specifying the minimum system files and directories required

1

2

3

4

/ (root) FHS Hierarchy

/bin	- Essential command binaries

/boot	- Static files of the boot loader

/dev	- Device files

/etc	- Host-specific system configuration

/home	- User home directories (optional)

/lib	- Essential shared libraries and kernel modules

/lib32	- 32-bit architecture dependent libraries (optional)

/lib64	- 64-bit architecture dependent libraries (optional)

/media	- Mount point for removable media

/mnt	- Mount point for mounting a filesystem temporarily

/opt	- Add-on application software packages

/proc	- Linux filesystem for handling process and system info

/root	- Home directory for the root user (optional)

/sbin	- Essential system binaries

/srv	- Data for services provided by this system

/tmp	- Temporary files

/usr	- Secondary hierarchy

/var	- Variable data

root

How to Create
LSB/FHS Compliant Applications

Creating applications that are LSB/FHS compliant is achieved by*:

Coding to the portability layer

Using the correct ABI's

Testing with the LSB application checker

Following the LSB packaging guidelines

Following the FHS specification for placement and management of files and directories

Seeking LSB certification if so desired

* See:“http://lsbbook.gforge.freestandards.org

Benefits of Being LSB/FHS Compliant

Applications that are LSB/FHS compliant have the advantage of:

Targeting multiple Linux distributions with a single binary (one for each supported hardware architecture)

Insulating applications from system and library upgrade issues

Reducing the time and effort of application development and testing

Allowing greater flexibility for system deployment

Reducing the learning curve when going between Linux distributions

Create SUSE Compatible RPMs

Compatible RPM Spec File

Use standard RPM macros in your RPM's spec file

If you are not sure:

Run “rpm –-showrc” on a RedHat system and then on a SUSE system and compare what macros are different between the systems

Determine what macros are being used and which (if any) need to be changed to migrate to SUSE

Use the SUSE Build Tool
To Create RPMs

SUSE's Build Tool

build is a tool used to create RPMs in an isolated environment

build will install a minimal SUSE Linux environment into a given directory, chroot to this created Linux environment, and compile the package

SUSE's Build Tool (cont.)

build searches the spec file for an extra line “BuildRequires: ”

If such a line is found, all specified RPMs after the “BuildRequires: ” tag are installed into the temporary Linux environment*. Otherwise a default set of packages will be installed

*Note: build does not automatically resolve missing dependencies. The specified rpms on the “BuildRequires:” line must be sufficient for the build to succeed

Adding the BuildRequires Section

The “ buildRequires: ” section is a list RPM package names separated by a space all on a single line

BuildRequires: aaa_base acl attr bash bind-utils bison bzip2 coreutils cpio cpp cracklib cvs cyrus-sasl db devs diffutils e2fsprogs file filesystem fillup findutils flex gawk gdbm-devel glibc glibc-devel glibc-locale gpm grep groff gzip info insserv kbd less libacl libattr libgcc libselinux libstdc++ libxcrypt m4 make man mktemp module-init-tools ncurses ncurses-devel net-tools netcfg openldap2-client openssl pam pam-modules patch permissions popt procinfo procps

For example:

Advantages in Using build

Building packages with build:

Ensures a consistent process for creating RPMs

Isolates a build environment from the current system (chroot)

Specifies a convention for what is required to build your package

Installs required RPMs in the chroot'ed environment automatically

Take Advantage
of the SUSE Enhancements

YaST Integration

YaST (Yet another System Tool) provides a central environment for administration and configuration

Create YaST modules for applications that require some type of configuration or administration

YaST automatically uses a graphical front-end in a windowing environment (KDE, gnome etc.) or ncurses when not

SuSEconfig Integration

SuSEconfig is used to configure the system based on configuration options found in “/etc/sysconfig” and applying the scripts found in “/sbin/conf.d/SuSEconfig.*”

SuSEconfig activates the configuration changes made by YaST modules

Porting/Migration CheckList

Checklist

Make sure your code is “lint-free”

Cleanup any non-portable code

Use standard tools (make, autotools, etc.)

Use “ldd” to analyze what libraries and versions are required for your application

Ensure SUSE versions of the required libraries are installed on your SUSE system

Programmatically check for check library versions

Statically link or bundle unique libraries

Compile on SUSE using official versions of gcc (3.2, 3.3 etc.)

Checklist (cont.)

Make your existing Red Hat RPM relocatable (if it is not already)

Use “rpm –-prefix” or/and “rpm –-relocate” to install the package in a temporary area

Make the appropriate changes to your application's installation to be LSB/FHS compliant

Applications with init scripts that are installed/removed RPM spec files should use:

“/usr/lib/lsb/install_initd” in “%post” section

“/usr/lib/lsb/remove_initd” in “%preun” section

Checklist (cont.)

Use only bash functions specified in the LSB in init scripts to ensure they exist on SUSE

Be aware of which threading model your application uses (NPTL or not) and understand what level of support is available (NPTL is not in SUSE version 8 but it in SUSE 9)

Create and maintain good test scripts/programs that can validate application behavior on both systems

If possible, compile your application on a 64-bit architecture (if it does not already run on it)

Get your application Novell YES Certified

Conclusion

Porting/migrating a Red Hat application to SUSE is not difficult

It may already work untouched on SUSE

Good coding practices are still good

Adhering to standards (LSB/FHS) makes the process much easier

Take advantage of what SUSE has to offer

Questions and Answers

Resources

Novell overview to porting Red Hat applications to SUSE Linux

http://www.novell.com/coolsolutions/cooldev/features 

/a_red_hat_migration_cdev.html

LSB's main web site:

http://www.linuxbase.org

A good guide on building LSB applications:

http://lsbbook.gforge.freestandards.org

IBM's Linux site for various LSB articles:

http://www.ibm.com/linux

Novell's guide for LSB/FHS application compliance:

http://developer.novell.com/yespgm/linux/suse/standard.html

Resources (cont.)

Another article on building LSB applications:

http://www.linuxjournal.com/print.php?sid=7067

Guide to writing portable code:

http://www.linuxgazette.com/node/view/397

GNU/GCC's Response to distributions using gcc 2.96:

http://gcc.gnu.org/gcc-2.96.html

Applications that are targeted to Red Hat may or may not run on SUSE LINUX. This session discusses porting and migration issues involved in taking applications written specifically for Red Hat to run and install properly on SUSE LINUX.

The FHS is limited in its scope that it does not determine the placement of local files. This is left up to the system administrator.

Also, the FHS addresses issues where file placements need to be coordinated between multiple parties such as local sites, distributions, applications, documentation, etc.

The LSB is a work-group of the Free Standards Group. The LSB also refers to a specification developed by the LSB to help ensure Linux inter-compatibility.

Some guiding principles that the LSB tries to adhere to is 1) not to step on the distributions. They want to be different from one another but there should be at least some commonality for developers and end-users. 2)The LSB takes a minimalist approach to solving problems. 3)They don't want to “break” old system but they do what to advance to solve current and future problems.

The key to the LSB is its goal and means of achieving binary compatibility across Linux distributions.

The LSB was created in 1998 and it is supported by all of the major hardware and Linux distribution vendors.

From the freestandard.org site “Only products that have been LSB Certified are permitted to use the "LSB Certified" trademark. The "LSB Certified" mark assures users and customers that the software they are using has the highest-possible run-time adherence to our standards -- and that the software they are using will work with other LSB Certified products.”

The LSB specification is a collection of several industry standard specification (FHS, various ABIs, System V Interface definition, Single Unix Specification, OpenGL, X11 etc.)

The specification has generice standards for binary portability and for specific architecture ABI's. There are defined ABI specifications:

Generic ABI

X86 ABI

PPC32 ABI

PPC64 ABI

IA64 ABI

S390 ABI

S390X ABI

The LSB doen't define new specifications but it documents in a single specification existing standards that apply to Linux.

Triggers are not allowed in RPM packages as well as the guarantee of execution order of the pre-install and pr-uninstall scripts. There are specified commands and scripts that can be used in the RPM. The RPM files can be installed via some other mechanism (alien on debian).

These goals are not Linux specific (wouldn't it be nice if it were the case across all operating systems!!)

The FHS is limited in its scope that it does not determine the placement of local files. This is left up to the system administrator.

Also, the FHS addresses issues where file placements need to be coordinated between multiple parties such as local sites, distributions, applications, documentation, etc.

The root filesystem must contain all files and directories to boot, restore, recover, and/or repair the system. The goal is to keep the root hierarchy as minimal as possible, containing only the essentials to meet the afore mentioned purposes.

Applications must never create or require special files or subdirectories in the root directory.

Expanding an applications market availability is a good idea! If users can use your application on multiple Linux distributions this gives them the choice to decide what Linux distribution they want to use. This ensures they won't be locked out of using your application because it may not be supported on their chosen Linux distro.

System upgrades, patches and installing other applicaitons should not destroy your application's viability. Remember DLL inferno?

Developing to a common set of APIs reduces development time and testing time. Binary compatibility across Linux distributions greatly reduces the testing complexity and support costs.

Because the FHS specifies sharable, unsharable, static, and variable files and directories, administrators have a high degree of flexibility for mounting systems (local and remote) – smaller desktop storage requirements, simplify backup processes – only writable filesystems need consideration for backup, facilitate security processes by limiting the need of writable areas etc.

If distributions are LSB compliant the cost of training is reduced going between LSB compliant distributions – administrators and end-users.

You can see what the default packages that will be installed by looking at

/usr/lib/build/init_buildsystem

2004-01-28T12:03:58