Developing LSB/FHS Compliant Applications

Darren Davis

Senior Software Engineer

Novell, Inc.

Why are you here?

What is the Linux Standard Base (LSB)?

What is the File Hierarchy Standard (FHS)?

What are the benefits in creating LSB/FHS compliant applications?

How do you create LSB/FHS compliant applications?

What is the Linux Standard Base (LSB)?

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. SLES 9 SP 1 is LSB v2.0 certified)

LSB

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

The Three C's of LSB

“Conformance” requirements are stated in a specification (they are an agreed set of rules defining what it means to meet the requirements of a specification)

“Compliance” is a claim of conformance

“Certification” is proof of compliance (by some agreed measure, sometimes this is not total proof, sometimes there is an attached warranty, sometimes there is a logo or mark that can be used in association with a certified product)

TM: The LSB Certified, and LSB marks are worldwide trademarks or registered trademarks of the Free Standards Group. The LSB Certified logo may only be used on or in relation to products that have been certified under this program and only after the company has entered into the license agreement with the Free Standards Group. The Register of LSB Certified products may be viewed at http://www.opengroup.org/lsb/cert/register.html The Free Standards web site can be viewed at http://www.freestandards.org/

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)

LSB Specified Libraries

The core set of approved LSB libraries revolve around:

Base system functionality (libc, libpthread, . . .)

Graphics (libGL, libX11, . . .)

Utility functions (libutil, libcrypt, libncurses, . . .)

The LSB specification describes the function signatures and associated include files that LSB compliant applications must use

LSB “Allowed”
Generic Shared Libraries

libX11	libX11.so.6

libXt	libXt.so.6

libGL	libGL.so.1

libXext	libXext.so.6

libICE	libICE.so.6

libSM	libSM.so.6

libdl	libdl.so.2

libcrypt	libcrypt.so.1

libz	libz.so.1

libncurses	libncurses.so.5

libutil	libutil.so.1

libpthread	libpthread.so.0

libpam	libpam.so.0

libgcc_s	libgcc_s.so.1

IA32 Architecture Specific
Standard Shared Libraries

libm	libm.so.6

libc	libc.so.6

proginterp	/lib/ld-lsb.so.1

LSB Package Naming Conventions

To avoid naming collisions among application packages and with system packages, LSB uses the following naming conventions:

All LSB compliant packages must begin with “lsb-”

If a package name contains only one hyphen (including the “lsb-”), then the name must be assigned by LANANA*

If the name has more than one hyphen, then the portion of the package name between the first and second hyphens must either be a LANANA assigned provider name or the owners' fully-qualified domain name in lower case (“lsb-www.novell.com-super-whizbang-app”)

The LANANA name must only consist of the ASCII characters [a-z0-9]

* LANANA – Linux Assigned Names and Numbers Authority http://www.lanana.org

Versions of the LSB Specification

Most major Linux distributions are LSB v1.3 certified. LSB version 1.3 was released in January 2003

The LSB version 2.0 specification was released in February 2004. SLES 9 with SP1 is certified 2.0

Version 2.0 adds C++ support and the Single UNIX Specification version 3 specification. Version 2.0 has restructured the documents based on functional area

An application that is LSB v1.3 compliant should (with perhaps minor changes) be compatible with LSB v2.0

2.0

1.3

What is the File Hierarchy Standard (FHS)

What is 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.”

* See: man 7 hier

Adhering to the FHS is required to be LSB compliant

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

By specifying the minimum system files and directories required

By enumerating exceptions to the principles

By enumerating specific cases where there have been historical conflicts

See:“Filesytem Hierarchy Standard version 2.3

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

/user FHS Hierarchy

/usr/bin	- Most user commands

/usr/include	- Header files included by C programs

/usr/lib	- Libraries

/usr/local	- Local hierarchy (empty after main installation)

/usr/sbin	- Non-vital system binaries

/usr/share	- Architecture-independent data

/usr/X11R6	- Xwindow System, version 11 release 6 (optional)

/usr/games	- Games and educational binaries (optional)

/usr/lib<qual>	- Alternate Format Libraries (optional)

/usr/src	- Source code (optional)

/var FHS Hierarchy

/var/cache	- Application cache data

/var/lib	- Variable state information

/var/local	- Variable data for /usr/local

/var/lock	- Lock files

/var/log	- Log files and directories

/var/opt	- Variable data for /opt

/var/run	- Data relevant to running processes

/var/spool	- Application spool data

/var/tmp	- Temporary files preserved between system reboots

Why Should Your Applications Be LSB/FHS Compliant?

Why Do We Need The LSB?

Do you remember the Unix wars?

Unix version 7

Unix System V

Xenix

BSD

Solaris

HP-UX

AIX

...

UNIX

UNIX

UNIX

UNIX

UNIX

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

How Do You Create LSB/FHS Compliant Applications?

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

LSB/POSIX Layer

Linux Kernel

LSB (ABI)

POSIX (API)

Applications

LSB Application Binary Interfaces

Some of the types of following ABI specifications the LSB references are:

System V Application Binary Interface

OpenGL® Application Binary Interface

IEEE Standard for Binary Floating-Point Arithmetic

Architecture specific System V ABI

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

LSB Development Environment

The LSB provides a development environment for building and testing LSB compliant applications:

See: ftp://ftp.freestandards.org/pub/lsb/lsbdev/

lsbdev-base(lsb-build-base)	- header files and stub	libraries

lsbdev-cc(lsb-build-cc)	- compiler wrapper tools

lsbdev-chroot(lsb-build-chroot)	- chroot-based environment

lsbdev-c++(lsb-build-cc)	- LSB compliant static libstdc++

lsbcc – ABI Compliance

LSB provides a wrapper to gcc (lsbcc) that enforces compliance with the LSB ABI

If an application uses non-LSB ABIs, the tool will not link the application successfully due to unresolved references

Applications compiled with the 'native' gcc can be analyzed for LSB-ABI compliance via*:

* See: ftp://ftp.freestandards.org/pub/lsb/test_suites/released-1.3.0/binary/application/

lsbcc -o app app.c

lsbappchk app

Demonstration of lsbgcc and lsbappchk

Linux Standard Base (Using)

#include <stdio.h>

#include <unistd.h>

main()

{

printf(“Hello world: %d\n”, getpid());

}

Example “Hello World”

Linux Standard Base (Using)

$ lsbcc -o hw_good helloworld.c

$ lsbappchk hw_good

lsbappchk for LSB Specification 2.0

Checking binary hw_good

$

Checking for LSB Compliance

Linux Standard Base (Using)

#include <stdio.h>

#include <unistd.h>

main()

{

printf(“Hello world: %d\n”, _getpid());

}

Example Bad “Hello World”

Linux Standard Base (Using)

$ lsbcc -o hw_bad helloworld.c

/tmp/cc5CITzio.o: In function 'main':

/tmp/cc5CITzio.o(.text_0xd): undefined ref..

collect2: ld returned 1 exit status

$

Command lsbcc fails

LSB Environment

lsbchroot Environment

lsbchroot provides an chroot environment to help isolate LSB application creation and testing. It provides:

A compiler independent environment

A way to use build environments that must use absolute paths etc.

An environment that mimics a “real system” for testing package installation

An isolated environment that does not “disturb” the currents system's installation and configuration

What Not To Do
When Creating LSB Compliant Applications

The LSB only allows an application to use “/proc/cpuinfo” file and its keys. Applications should not use any other data from “/proc”

Only use system interfaces specified by LSB. Do not use private system interfaces

Be careful about what thread interfaces an application uses (NPTL, hybrid threading model, etc.)

Use “fgets(3)” instead of “gets(3)”

Use “curses.h” instead of “ncurses.h”

Use “stdlib.h” instead of “malloc.h” when using “malloc(3)”

Do not use hardware specific interfaces

Why Do We Need The LSB?

Do you remember the Unix wars?

Unix version 7

Unix System V

Xenix

BSD

Solaris

HP-UX

AIX

...

LSB Compliant Application Constraints

LSB compliant applications are specific to a given processor architecture

Processor specific optimizations are not possible (MMX, 3DNow, etc.)

Limited number of library interfaces (can only use the specified libraries without statically linking or bundling extra libraries)

Potential licensing issues when statically linking to certain libraries (LGPL)

Cannot use distro-specific macros in RPM spec files

Why Do We Need The LSB?

Do you remember the Unix wars?

Unix version 7

Unix System V

Xenix

BSD

Solaris

HP-UX

AIX

...

LSB/FHS Installation Conventions

All static data must reside under

All host-specific configuration data must be stored under

All variable data must be stored under

Why Do We Need The LSB?

Do you remember the Unix wars?

Unix version 7

Unix System V

Xenix

BSD

Solaris

HP-UX

AIX

...

“/opt/<provider-name>/”

“/etc/opt/<provider-name>/”

“/var/opt/<provider-name>/”

Examples

/opt/novell/bin/ndsstat

Since this command might be executed by end-users, it resides in: “/opt/<provide-name>/bin”

/opt/novell/eDirectory/bin/ndsd

dsd is not executed directly by end users. It is typically invoked by an init script instead.

/etc/init.d/novell-ndsd

Init scripts should be prefixed by “<provider-name>-”

/opt/novell/include/libldap_c/ldap.h

Header files that are product specific are placed in: ”/opt/<provider-name>/include/<package>”

/opt/novell/lib/libldapsdk.so

This is a shared library used by multiple products. It could also be part of an SDK.

Why Do We Need The LSB?

Do you remember the Unix wars?

Unix version 7

Unix System V

Xenix

BSD

Solaris

HP-UX

AIX

...

Examples (cont.)

/etc/opt/novell/ifolder/httpd_linux_ifolder.conf

Host-specific configuration file

/var/opt/novell/ifolderdata/

Data that changes as part of normal run-time operations

/opt/novell/man/en_US/man8/ifolder.8.gz

Localized man page

/opt/novell/local/de/LC_MESSAGES/ldap.mo

Localized message file

Why Do We Need The LSB?

Do you remember the Unix wars?

Unix version 7

Unix System V

Xenix

BSD

Solaris

HP-UX

AIX

...

LSB/FHS Installation Exceptions

Some files must reside outside of “/opt/<provider-name>”, “/etc/opt/<provider-name>”, and “/var/opt/<provider-name>” in order for applications to function properly. Some examples are init scripts, which reside in “/etc/init.d”, and cron scripts which must be in “/etc/cron.d”. These files should be prefixed by “<provider-name>-“.

Why Do We Need The LSB?

Do you remember the Unix wars?

Unix version 7

Unix System V

Xenix

BSD

Solaris

HP-UX

AIX

...

Some file or directory names may not be able to conform to these rules. For instance, PAM modules are encouraged to use a provider name as a suffix, instead of a prefix. These situations should be the exception, not the rule.

Novell/SUSE Commitment to LSB/FHS

“As an active LSB member, SUSE LINUX is committed both to providing customers with standardized Linux technology and to simplifying ISVs and IHVs Linux certification efforts. The availability of common standards plays a decisive role in the proliferation of Linux operating systems and applications on server and client systems worldwide, and we appreciate the LSB project's work in developing and promoting these standards.”

- Markus Rex, General Manager of SUSE LINUX for Novell

Why Do We Need The LSB?

Do you remember the Unix wars?

Unix version 7

Unix System V

Xenix

BSD

Solaris

HP-UX

AIX

...

Questions and Anwsers

Resources

LSB's main web site:

http://www.linuxbase.org

The Free Standards Group web site:

http://www.freestandards.org

How to get LSB certified:

https://www.opengroup.org/lsb/cert

Where to register you LSB provider name:

http://www.lanana.org

A good guide on building LSB applications:

http://lsbbook.gforge.freestandards.org

Resources (cont.)

Another article on building LSB applications:

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

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

The LSB mailing list:

http://freestandards.org/mailman/listinfo/lsb-build

The IRC channel for LSB:

irc.freestandards.org/#lsb

The Linux Standard Base (LSB) and the File Hierarchy Standard (FHS) are industry specifications for the Linux developer community to enable application binary, installation and configuration compatibility among Linux distributions. This session is designed to help developers understand the LSB and FHS specifications, the benefits of creating LSB/FHS compliant applications and the basic steps in creating LSB/FHS compliant applications.

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 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 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 generic 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 pre-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).

As you can see the libraries cover a small amount of the possible libraries that an application could need.. But over time as demand increases, more libraries will be added.

Any other library that is not mentioned in the list above must be linked statically into the application. In LSB 2.0 they have included libstdcxx version libstdc++.so.5)

The list of libraries will grow as the LSB spec evolves.

For each architecture there are other LSB relevant libraires

The FHS was created before LSB to help reduce the inconsistency of file and directory placement and naming across Unix-like systems.

It has been adopted by the LSB as a core component. Binary compatibility is a great leap forward and so is common placement and naming of files and directories.

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.

The /usr hierarchy conains shareable and read-only data. To be FHS compliant systems and applications must not write date into this hierarchy.

Large applications must not use a direct subdirectory under /usr hierarchy.

The /var hierarchy contains variable data files. It only contains transient and temporary files. Some portions of /var are not shareable between different systems (/var/mail, /var/cache/man, /var/lock, /var/log etc.)

/var makes it possible for /usr to be read-only.

Applications must not generally add subdirectories to /var

Unix started out to be very simple and consistent across systems (at least at the interface level). As Unix became accessible outside of AT&T Bell Labs, and through various licensees of Unix, Unix began to be fragmented.

Today, it is very unlikely that applications can run on different Unix implementations on the same hardware architecture. If by chance an application runs on the various systems, the “proper” installation of the application on the systems would be different for each system.

We have a chance with Linux to prevent the fragmentation among distributions that we have seen with Unix.

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.

The LSB builds upon the POSIX standard and specifies those interface/libraries that can be used. LSB has its own runtime linker (ld-lsb.so.1) and ABI using ELF and other standards.

The latest version for the 1.3 spec is 1.3.4. Always check the posted ftp site for the latest release.

The 2.0 version of the development environment is not yet officially released. However, the names of the packages and there installation directories are different in 2.0 from 1.3. They follow the FHS standard by placing the files under /opt/lsb/ rather than /opt/lsbappchk, /opt/lsbdev-cc etc.

The lsbcc will use the stub libraries intalled via lsbdev/lsb-build packages and force the compiler to only link to the appropriate ABI.

The lsbappchk version 1.3.3 or 1.3.4 has some - warnings that are not failures on SUSE, just annoyances. If you get:

section .note.SuSE is not in the LSB

If you get:

Section .eh_frame: sh_flags is wrong, expecting 3, got 2

This is a “bug” that has been fixed in the 2.0 release of lsbappchk.

Header [ 7] type 6474e551 Not checked

Is a warning that should be ignored (it too has gone away in 2.0).

In LSB 2.0 this is called lsb-build-chroot.

It takes more to configure but it does isolate the environment.

Threads are a sticky subject. SUSE SLES 8 supports a portion of the POSIX thread implementation. RedHat back ported a version of NPTL to the 2.4 kernel for 2.1 and 3.0. In SLES 9 full NPTL (Native Posix Threads Library).Consult the LSB specification for more specific information.

Curses.h and ncurses.h are the same on most systems.

The stdlib.h contains some debugging aids when used in conjunction with gcc -lmalloc option.

If an application needs to statically link or bundle additional libraries, those libraries must be LSB compliant and only use the specified LSB interfaces.

“At SUSE we have been 100% conforming to the LSB/FHS for a long time . If there is any doubt in where applications should be installed or how the system should be setup, we conform to the LSB/FHS.”

DL103 - Creating LSB/FHS Compliant Applications

2004-07-27T10:16:17