12.2 Setting Up the Sample Implementation
The LSB-si can be run in one of three different modes: the chroot LSB-si, the UML LSB-si, and the bootable Knoppix LSB-si. Software for each mode can be downloaded from the LSB Download Web site. 
12.2.1 Sample Implementation Using chroot(1)
The chroot LSB-si is distributed as a compressed tarball that should simply be unpacked by the superuser (Example 12.1). Later, other pieces can be layered on top of it, and packages for additional functionality can be installed inside it. For illustrative purposes, the IA32 (x86) architecture will be used in the following examples. For your situation, you may need to substitute the appropriate LSB architecture and version.
Example 12.1. Installing LSB-si on IA32 (x86) Architecture
# mkdir /opt/lsbsi-ia32 # cd /opt # tar jxvf /tmp/lsbsi-ia32-2.0.1.tar.bz2
The LSB-si can be started by running the /sbin/chroot command (Example 12.2; some distributions place this command in /usr/sbin).
Example 12.2. Starting LSB-si by the /sbin/chroot Command
# /sbin/chroot /opt/lsbsi-ia32
To simulate a login session, use this command as shown in Example 12.3.
Example 12.3. Login Session
# /sbin/chroot /opt/lsbsi-ia32 /bin/bash -l
When working in the chroot, only files inside the chroot tree will be accessible. Since this limits the usefulness of the environment, some steps should be taken ahead of time to make the necessary files available. One approach is to simply copy files from the chroot into a suitable location. If another window or terminal session is available on the host system, it is also possible to copy files into the chroot tree the same way, whenever they are needed (Example 12.4).
Example 12.4. Copying Files into chroot
# cp mypackage.rpm /opt/lsbsi-ia32/tmp
Another approach is to establish bind mounts before starting the chroot. These bind mounts enable portions of the filesystem of the host to appear to be inside of the chroot. Bind-mounting a user's home directory to the same location in the chroot will make that user's files appear in the same path inside the chroot as on the host system. Example 12.5 shows setting up access to the files in the home directory of username.
Example 12.5. Bind Mounts
# mkdir /opt/lsbsi-ia32/home/username # mount -o bind /home/username /opt/lsbsi-ia32/home/username
This does not cause the user account itself to exist in the chroot. The useradd command should be used to add the account. The account should be given the same userid as it has on the host system.
The LSB-si limits itself to commands and features required by the LSB Written Specification, which is a set chosen to be able to minimally install, configure, and administer installed software. This has some testing benefits, but this also means there likely are a few missed components. These are not hard to work around, but the LSB-si philosophy leaves them out; by having to install them specifically, you become aware of these areas that are actually not standard across systems.
The rpm tool needs access to /proc to calculate disk space (the mounted filesystem table is found through /proc). However, /proc is not part of the LSB Written Specification. The simplest workaround is to add a line describing it to the /etc/fstab of the LSB-si so that you can simply say mount /proc. Example 12.6 shows such a line, through it is best to simply copy the line from /etc/fstab on the host system.
Example 12.6. Adding /proc to fstab
none /proc proc defaults 0 0
Depending on your requirements, you may also need to perform similar steps for other pseudo filesystems such as /dev/shm and /dev/pts.
Some of the commands you may be accustomed to may be missing, including editors and development tools. Many 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 as necessary.
Example 12.7 illustrates copying an installable package into the chroot tree, starting the chroot, installing the package, and running it. As this example will utilize the X Server on the host system, an additional setup step to enable access to this server is included before the chroot is started.
Example 12.7. Installing a Package on chroot
# cp lsb-xpaint-2.6.2-3.i486.rpm /opt/lsbsi-ia32/tmp # xhost +localhost # /sbin/chroot /opt/lsbsi-ia32 # cd /tmp # rpm -i lsb-xpaint-2.6.2-3.i486.rpm # rpm -qa # export DISPLAY=localhost:0 # /opt/lsb-xpaint/bin/xpaint
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 it over from the host system.
Also, if a server (daemon) is to be tested, it will first need to be set up to listen on the appropriate port; secondly, 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 the inetd or xinetd servers, so by default these cannot be used to listen for service requests. The lsbsi-archtest package can be installed to provide inetd. Example 12.8 shows a normal run of lsb-runtime-test to validate the LSB-si. The lsb-test package is previously installed. One part of testing requires the syslog daemon, so the syslogd from the host system is shut down first. The test setup requires a true login, so inetd is started to watch over a telnet daemon.
Example 12.8. Using the lsb-test Package to Run inetd
# sh /etc/init.d/syslog stop # /usr/sbin/chroot /opt/lsbsi-ia32 # mount /proc # /sbin/syslogd -m 0 # /usr/sbin/inetd
Now connect to the LSB-si chroot using telnet, and log in as a user defined inside the LSB-si (Example 12.9).
Example 12.9. Connecting to chroot
$ telnet localhost
12.2.2 Sample Implementation Using 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 hostfs, in which case the filesystem tree of the host can be mounted and accessed. This is the easiest way to get files, such as packages, to be installed into the UML LSB-si.
It is also possible to copy files into the root_fs (root filesystem file) of the UML LSB-si. This is a little tricky, so proceed carefully (Example 12.10).
Example 12.10. Copy Files into root_fs
# 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
The UML LSB-si is started by running the User-Mode Linux kernel; a script is provided by the installable (RPM or Debian) packages to do this with appropriate arguments. If it has not been run previously, the Configure script will be run now to set up important parts of the hosted UML Sample Implementation (Example 12.11).
Example 12.11. Running the Configure Script
An advantage of using the UML is that it allows the whole system, kernel and all, to be run in user space. This enables the testing and debugging of an LSB-supporting kernel without actually installing a new kernel on the host system. In addition, UML more stringently isolates the LSB-si from the hosting system.
12.2.3 Using a Bootable Sample Implementation
The base tarball plus the lsbsi-arch-boot tarball are nearly enough for a complete standalone bootable system. The two missing pieces are a Linux kernel and a bootloader setup, plus some final configuration needs to be done manually. Example 12.12 to Example 12.15 show the steps to build a bootable LSB-si partition on an already-bootable system. You will need to augment further to put these on a "fresh" system with no existing Linux installation.
Locate an unused partition, such as /dev/sda9, and make an appropriate filesystem on it (the -j option to mke2fs is used to create a journaling (ext3) filesystem). This partition will now contain most of a runnable system. There are a few more things that need to be done to it, such as building the correct filesystem mount table and setting up a kernel that works appropriately for this system.
Example 12.12. Creating a Journaling Filesystem
# mke2fs -j /dev/sda9 # mkdir /mnt/lsbsi # mount empty-partition /mnt/lsbsi # cd /mnt # tar -xvjf /tmp/lsbsi-ia32-2.0.0.tar.bz2 # cd lsbsi # tar -xvjf /tmp/lsbsi-test-ia32-2.0.0.tar.bz2
Handcraft an appropriate /etc/fstab that describes the root filesystem, swap (if any), and any additional mounts, including special filesystems such as /proc, /dev/pts, and so on.
Copy over the modules directory matching a bootable kernel that already works on this system (Example 12.13).
Example 12.13. Copying the modules Directory
# cp -r /lib/modules/2.4.18-24.8.0 /mnt/lsbsi/lib/modules # cp /boot/vmlinuz-2.4.18-24.8.0 /mnt/lsbsi/boot
Copy over a working /etc/modules.conf or similar, as appropriate for the system you will be running (Example 12.14).
Example 12.14. Copying /etc/modules.conf
# cp /etc/modules.conf /mnt/lsbsi/etc
Add instructions to boot the kernel of your choice using the appropriate partition to boot to. For example, to boot using lilo, you might add the contents of Example 12.15 to /etc/lilo.conf.
Example 12.15. /etc/lilo.conf Instructions to Boot to lilo
image=/boot/vmlinuz-2.4.18-24.8.0 label=lsbsi-boot root=/dev/sda9 initrd=/boot/initrd-2.4.18-24.8.0.img read-only
If you're using a bootloader such as lilo that requires running a command to install the new configuration, don't forget to do so!
12.2.4 Sample Implementation Using Knoppix
Knoppix  is a bootable CD that runs GNU/Linux in memory without disturbing the operating system installed on the hard disk. The LSB has a version of Knoppix with the LSB-si configured on it. This disk is useful for demonstrating the LSB-si or for a tutorial lab use. When used for a demo or in a tutorial lab, there should be no concerns about what kernel, compiler, or glibc libraries are installed. Almost everyone can simply insert the disk into their computer and reboot to run Knoppix LSB-si.