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 10000 and /usr/xpg4/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.

Solaris features another interesting tool.

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?

The package format used by SunOS 5.9 is called "pkg Datastream (SVR4)" by a recent file(1). Relevant information is stored as a set of text files in directory /var/sadm. For each installed package there is a sub directory in /var/sadm/pkg that includes a description.

The first half of a query does a linear search trough text file /var/sadm/install/contents. The tricky part is to find the canonical name of a file. A lot of tools are provided in two different variations. The POSIX confirming ones are located in directory /usr/xpg4/bin/, as described by xpg4(5). The classic tools are installed in /usr/bin. But since /bin is a symbolic link to /usr/bin, a naive which(1) can give unexpected results.

The second part of the query works on a single file, /var/sadm/pkg/*/pkginfo:

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.

SunOS uses checksums based on sum(1). pkgchk(1) lets you verify everything, complete packages or a list of files specified with option -i listfile. Diagnostics are written to stderr and no news is good news.

Command: pre/sparc-sunos5.9/packages/SunOS/verify.sh
#!/usr/xpg4/bin/sh
pkg=$( /usr/sbin/pkgchk -l -p /etc/profile \
| /usr/xpg4/bin/grep -v '^[A-Z]' )
/usr/bin/echo pkg=[${pkg}]
/usr/sbin/pkgchk ${pkg} 2>&1 | /usr/xpg4/bin/sed 11q
/usr/bin/echo status=$?

Output: out/sparc-sunos5.9/packages/verify
pkg=[ SUNWcsr ]
ERROR: /etc/.login
    modtime <04/07/02 01:00:15 AM> expected <01/27/03 08:32:35 PM> actual
ERROR: /etc/cron.d/at.deny
    modtime <04/07/02 12:44:24 AM> expected <01/27/03 08:32:35 PM> actual
ERROR: /etc/cron.d/cron.deny
    modtime <04/07/02 12:44:24 AM> expected <01/27/03 08:32:36 PM> actual
ERROR: /etc/default/cron
    modtime <04/07/02 12:48:55 AM> expected <01/27/03 08:32:36 PM> actual
ERROR: /etc/default/devfsadm
    modtime <04/07/02 12:51:00 AM> expected <01/27/03 08:32:36 PM> actual
ERROR: /etc/default/dhcpagent
status=0

Option -n is advertised as "Do not check volatile or editable files". With option -d package_file you can verify against the checksums included in a package file, e.g. on the installation CD.