Testing an LSB Application using the Sample Implementation

The LSB Sample Implelmentation (LSB-si) is a minimal LSB-conforming runtime environment which runs inside a chroot on a hosting platform. The LSB Certification program requires an application to be cross-checked in the LSB-si. The benefit is that the LSB-si is very clean and there's less chance that a non-LSB component which might accidentally have snuck into the application will work - thus catching problems early.

Installing the LSB-si

Setting up and configuring the LSB-si is now described in a separate paper.

Preparing to run the LSB-si chroot

Since the LSB-si is started by running the chroot command, only files inside the chroot tree will be accessible. Since the package to be tested will need to be available to install it, steps must be taken ahead of time to set this up.

Copying files

Files may simply be copied to an appropriate path inside the LSB-si, for example:

  # cp lsb-lynx-2.8.4-1.i486.rpm /opt/lsbsi/tmp

Bind mounts

Another approach is to set up bind mounts before starting the chroot. For example, to set up access to the files in the home directory of "username":

  # mkdir /opt/lsbsi/home/username
  # mount -o bind /home/username /opt/lsbsi/home/username

Entering the LSB-si chroot

The LSB-si is started by running the /sbin/chroot command. (Some distributions may place it in /usr/sbin).

  # /sbin/chroot /opt/lsbsi

To simulate a login session, try:

  # /sbin/chroot /opt/lsbsi /bin/bash -l

Preparing to run the LSB-si UML

The UML LSB-si runs off a "root filesystem" that is encapsulated in a file. The LSB-si will not be able to "see" outside this filesystem except if running the hostfs, in which case the host's filesystem tree can be mounted and accessed. This is the easiest way to get files, such as packages to be installed, into the LSB-si. See Setting up and configuring the LSB-si for more details on this.

Copying files into the root_fs

It is also possible to copy files into the the UML LSB-si's root_fs (root filesystem file). This is a little tricky, so proceed carefully:

  # mkdir /mnt/lsbsi
  # losetup /dev/loop0 /opt/lsb-umlsi/lib/root_fs
  # mount /dev/loop0 /mnt/lsbsi
  # cp lsb-lynx-2.8.4-1.i486.rpm /mnt/lsbsi/tmp
  # umount /mnt/lsbsi
  # losetup -d /dev/loop0

Entering the LSB-si UML

The LSB-si UML is started by running the user-mode Linux kernel; a script is provided by the installable (rpm or deb) packages to do this with appropriate arguments. If it has not run previously, the Configure script will be run now to set up important parts of the UML sample implementation.

  # /opt/lsb-umlsi/bin/umlsi

Installing and testing the application

The LSB-si is equipped with a copy of rpm, to meet the requirement that a conforming platform be able to install rpm packages of the specified format. Note that rpm itself is not required by the LSB spec. The rpm database in the LSB-si is populated with a minimal set of provides. As required by the spec, it provides the lsb dependency, versioned. For the 1.2 packages, version 1.2; for the 1.3 packages at both 1.2 and 1.3; that is, it should accept packages that "require" lsb, lsb=1.2, or lsb=1.3.

The LSB project has developed a package verification tool (lsbpkgchk). This tool should be run and the output examined carefully. At this writing there were still some false negatives - warnings or errors that would not prevent a package from installing correctly (it appears that there is no version of rpm that 100% follows the rules set out, and from which the LSB specification and test tool were derived). See the lsbpkgchk release notes for more information.

Packages need to be installed with normal dependecy checking. Do not resort to installing with rpm --nodeps, as one of the objectives of testing in the LSB-si is to show that that package can properly be installed by a strictly conforming implementation, and bending the rules by bypassing rpm's dependency checking may weaken this test.

Please report any issues back to the LSB team, preferably by filing a bug in the LSB project bugtracker.

Continuing with our example:

  # rpm -i /tmp/lsb-lynx-2.8.4-1.i486.rpm

The package should now be ready to test in the normal way.

Special considerations for the chroot

The pure chroot is missing many useful things since it limits itself to items required by the LSB spec. While this has some benefits, it also means there are likely to be some surprising or problematic areas. Here are a few that might come up:

Mounts

The rpm tool needs access to /proc to calculate disk space (the mounted file system table is found through /proc). However, /proc is not part of the LSB spec. The simplest workaround is to add a line describing it to the LSB-si's /etc/fstab so that you can simply say mount /proc. This is an example line, it's probably best to simply copy the line from /etc/fstab on the host system:

  none  /proc  proc  defaults  0 0

Depending on your requirements, you may also need to do similar things for other pseudo-filesystems such as /dev/shm and /dev/pts.

Missing tools

Lots of commands you may be used to will be missing, including editors. The developers have found it useful to work in a windowed environment, with one window running the LSB-si chroot and others set up to be able to edit and otherwise modify files, should it be necessary.

Networking

For networked applications, some additional support is probably needed. For example, the /etc/services file is not described by the LSB, and thus is not present in the chroot. If needed, simply copy over from the host system.

Also, if a server (daemon) is to be tested, it will need to be set up to (a) listen on the appropriate port and (b) any conflicting service on the host system must be disabled so the connection actually reaches the daemon in the LSB-si chroot.

The base LSB-si does not have an inetd or xinetd, so these cannot be used to set up listening for the service requests. The lsb-test package can be installed to provide inetd.

If tests need to be performed as a non-root user, you can run su in the chroot session to substitute users. See Other Considerations for more on user accounts.

Another approach is to telnet into the LSB-si from another window, or from another computer. To do this, install the lsb-test additions which also provide a telnet server. The considerations described in networking above apply if the telnet server is to be used. The lsb-test package is configured with a copy of inetd which will start a telnet server on demand.

  # inetd

You would connect to this by doing

  $ telnet localhost

and logging in as a user defined inside the LSB-si.

Other Considerations

Users

Packages should not count on any specific usernames being present in the LSB-si unless they are specifically required by the LSB. In general, a package that requires a special username should create that user as part of the install process, using the LSB-specified tools for doing so.

Augmenting the LSB-si with lsb-test

A supplementary package is available that primarily provides support for running the LSB Runtime Test Suite; however, it may be useful for other purposes. For more details, see here.