send feedback to webmaster @ schapiro . orglast modified 2007-09-18 09:27:42
| The Schapiro Center | Personal Schlomo Nadia Boris | Other Sites RKM Links |
| Introduction | Overview | Installation | Usage | How it works |
Extending | Support |
The build process used by OGB is very simple and straightforward:
Packages basically extend this basic build process by adding a package skeleton, extending the lists of programs, libraries and files to copy and by calling 2 scripts, one before copying and one after. This is to provide hooks to both change the configuration files (used by the ssh module to generate the host keys) and to modifiy the OGB system in the build directory (used by most packages to add /etc/inittab entries for their function).
The most problematic part of OGB are probably the dependancy walkers that resolve the binary and module dependancies to include the needed libraries and modules. This code has been taken from SuSE's mkinitrd script and might have to be adapted to newer kernel versions or other changes. Till now it was always sufficient to copy over the respective code segments from the most current SuSE system. The code has also been verified to perform satisfactory on Debian and Red Hat systems.
ISOLINUX is used to boot the OGB system from CD. A stable version is included in the OGB distribution as there is no standard on installing SYSLINUX/ISOLINUX under Linux and almost each Linux distribution does it differently. In any case, the ISOLINUX binary is not run in the OGB system, but rather use to start it.
The OGB Linux runs off an INITRAMFS ramdisk which is initialized by the boot loader. Thus there is no need in OGB to deal with block devices of any kind like hard disks, CD-ROM drives etc. Consequently, the build process does not copy any block device drivers to the OGB system and the OGB system cannot access any data on hard disks.
After booting the kernel, the normal System V init process starts, but there are no /etc/init
scripts that run but rather a simple boot script /etc/boot which has to setup all the system. This
boot script also calls /etc/network.sh which should setup the network stuff.
After the inital boot, init starts (and monitors) any application listed in /etc/inittab which is
also the recommended place for other additions. Unfortunately some programs alway fork into background, so that
init cannot monitor them. Otherwise init is the most simply monitoring tool and sufficient for most purposes.
The build process writes a log to log/ogb-<config>.log (and keeps the previous log, too).
Upon experiencing problems of any kind, it is always worthwhile to check that log file for errors, though someimes
there are spurious errors from some subsystems that are "just normal" (for example about modules without depancies).
However, serious errors will abort the build process with an error message.
In debug mode (enabled with the debug package), a shell is started on tty2 (reachable with ALT-F2)
which allows some simple in-system debugging. Additionally the package installs and starts an SSH server to allow
remote debugging. The package also copies a lot more tools and utilities to the OGB system, as it is otherwise
very hard do debug it (e.g. without ls and other standard commands). In production mode there is
no interactive access to the OGB system at all, as a security precaution
OGB uses syslog-ng for logging because it is more flexible and reliable than standard syslogd. In tests we found out that the large amount of logging that can be created by OGB during startup is oftenly partially lost when using remote syslog via UDP. syslog-ng TCP logging reliably solved this problem and even should allow logging to the remote end of a VPN tunnel (because messages are buffered to a certain extent).
Locally on the OGB system no logs are written to the filesystems, tty12 shows the current log instead. To keep the logs permanently, one must use remote logging via one of the many syslog-ng logging facilities. It is recommended to have a central loghost for this purpose.
In most cases the log output generated is sufficient to pinpoint any sudden trouble, though to debug boot and network or driver problems one usually will have to use a debug build and debug it directly at the OGB console.
Finally, SNMP support can be included via the snmp package which includes the snmp daemon. It has
been tested on our build systems and can be used to monitor many different parameters of a running OGB system.
Furthermore, custom scripts can be included at specific OIDs, please refer to the standard
NET-SNMP documentation for more information about
SNMP monitoring.
send feedback to webmaster @ schapiro . org
