1. Variables and packages

 

Once it hits the fan, the only rational choice is to sweep it up, package it, and sell it as fertilizer.

 anonymous

This document tries to cover multiple platforms through conditional compilation. There is a configure.pl that determines the host type and sets up a config.sh containing environment variable definitions. There also are equivalent config.csh, config.h, config.mak, config.sed, and config.xml. The Makefile then uses individual sub-directories for each platform. The name of these directories (and some other platform specific values) is retrieved through environment variables. The directory structure is not without meaning.

1.1. Variables prefixed with TEVWH_

The files in src/ are obfuscated with obscene amounts of variable references like ${TEVWH_ELF_BASE} or even ${TEVWH_PATH_LS}. I admit that using variables instead of plain program names makes shell scripts harder to read. But this is necessary to maintain a minimum level of reproducibility on SunOS. Anyway, directory pre/ makes that 8048000 and /bin/ls. You will encounter this syntax nightmare only in a few places. An almost complete list of used variables is given below.

Note that hexadecimal shell variables actually miss the leading 0x to simplify calculations with bc. These values are also available to C code through corresponding #define statements after #include <config.h>. Values are not quoted, but hexadecimal values are correctly prefixed by 0x.

1.2. Variables prefixed with TEVWH_PATH_

1.3. The name of the X

The value of LANG is not directly related. But some tools create strange output for en_US.UTF-8.

While most Linux distributions ship with slightly modified kernels, no vendor has ever dared to mess with the values returned by uname(2). Instead the tradition of distribution dependent text files in directory /etc was established.

1.4. The owner of files

One of the lesser known features of package management is self-reflection. How do we determine the package owning a file if we have the canonical path name?

Red Hat Linux release 8.0 (Psyche) uses rpm for package management. It maintains an extensive database in /var/lib/rpm/ in binary form. Query operations are quite fast, but disk space usage is rather high.

The query is straightforward:

Output format is customizable. A list of available tag names is output by rpm --querytags.

1.5. The source of man-pages

Option -a of man returns all matching entries, not just the lowest section. This behavior is identical between platforms.

Requesting a specific section requires option -s section on SunOS, while Linux and FreeBSD prefer a plain section.

1.6. Verifying installed packages

This chapter is not about checking the integrity of package files. See Intrusion detection systems (i) for a general introduction.

rpm(1) lets you verify everything or complete packages. A package can be specified indirectly through a file owned by it, though.

Command: pre/i386-redhat8.0-linux/packages/rpm/verify.sh
#!/bin/bash
/bin/rpm -qf /etc/profile
/bin/rpm --verify bash
/bin/echo status=$?
/bin/rpm --verify -f /etc/profile
/bin/echo status=$?

Output: out/i386-redhat8.0-linux/packages/verify
setup-2.5.20-1
status=0
S.5....T c /etc/csh.cshrc
missing  c /etc/csh.login
S.5....T c /etc/printcap
..?..... c /etc/securetty
status=1

A quick fix to lower the noise is to ignore all files flagged as " c ". Take the following as inspiration for a cron-based script.

Command: pre/i386-redhat8.0-linux/packages/rpm/verify-all.sh
#!/bin/bash
/bin/nice -n 19 /bin/rpm --verify --all \
| /bin/grep -v '........ c'

With option -p package_file you can verify against the checksums included in a package file, e.g. on the installation CD.