Office of Information Technology  Boston University
System Support
 About Getting Started News Contact
Administration Tools  Administration Tools Software
Network Installations
Hostname/IP Issues
BU Linux
Solaris
Checklist
Installation Options
Boot Server Guide
Class File
Installation Clusters
Finish Scripts
SGI
Application Server
Patches
Sun Patches
Automate Sun Patches
SGI
Media Loans
Backups
Global Compliance
UID System Guide
Security
Links
FAQ

Finish Scripts

Customizing the Installation Process
The Office of Information Technology realizes that one size does not fit all when it comes to Operating System installations. We have made a number of improvements to our Configuration Server, which is at the heart of Custom-Jumpstart and Webstart, aimed at making the installation process more accessible to the individual administrators around campus.

To facilitate this, we have redesigned the jumpstart customization process to use a 8 layer model. Before beginning this customization, the Operating System is installed as specified in the Custom-Jumpstart Class File or for your host or using the information provided by the administrator during a WebStart installation. The customization then installs the following modules, as numbered.

  1. Package Add Module (required)
  2. Patches Module (required)
  3. Binary Overlay Module (required)
  4. Generic OS Configuration Module (optional, default)
  5. Distributed Computing Module (optional, default)
  6. Subnet Specific Module (optional)
  7. Host Specific Module (optional)
  8. Security Module (required)

Details on each of the modules is provided later on this page.


Configuring the customization path

The Host Configuration File
The configuration instructions for a host are provided in a configuration directory on the bootserver.

Assuming you installed the bootserver in /usr/local, the full local path to this directory in Solaris 2.9 boot server should be:
/usr/local/bootserver/sun4_59/Solaris_9/config

The configuration file for the host to be jumpstart must be called <hostname>.cfg, where <hostname> is the unqualified (no .bu.edu) hostname of the install client. For example, the configuration file to IT.BU.EDU would be it.cfg. A sample configuration file, subnet.cfg.sample, is provided in the config directory when you install the boot server. The file should look similar to this.

The Modules

Package Add Module (required)
  1. As part of the customization process, the install script will check for a configuration script on the bootserver that contains subnet specific configuration instructions. This allows the local administrator the opportunity to specify additional packages that should be installed. Right now, OIT supports the installation of the following packages via this mechanism:
    • OpenGL
    • Gnome Desktop Environment
  2. Once these packages have been installed, the process will look for an executable script called pkgadd.sh on the bootserver in the configuration directory. If found, it will follow instructions from that file as well. A sample version of this file for installing OpenGL is present as pkgadd.sh.SAMPLE. If the file does not exist, then execution continues at the next module.
Patches Module (required)
  1. This module installs all of Sun's recommended and security patches as well as any patches selected by OIT based on their value to campus systems. The script uses the PatchAlert Toolkit and will preconfigure it to automatically exclude patches not relevant to your OS installation in future invocations.
  2. This module cannot be deselected by the administrator.
Binary Overlay Module (required)
  1. This module will installed some basic binaries on your system that everyone should have. These binaries include:
    • local configuration files
      • /.cshrc, /.login, /.xinitrc
      • /etc/notrouter (to disable routing on multihomed machines)
      • /etc/nsswitch.conf
      • /etc/printers.conf (for public printers)
      • /etc/resolv.conf (appropriate for the BU domain)
      • /etc/inetd.conf (improved security over Sun's version)
      • /etc/services (adds a few things local to BU)
      • /usr/local/skel (Skeleton dot files for new user accounts with good paths, etc.)
    • system administration tools
      • PatchAlert
    • system security tools
      • tcp_wrappers
      • sudo
      • /etc/ftpd/ftpusers to restrict ftp access
    • useful binaries
      • Berkeley sendmail
      • ssh (including sshd, which is not enabled unless specified in the subnet configuration file)
  2. This layer will installed the useradm toolkit by default or if the subnet configuration specifies it.
  3. This layer will configure sendmail according to the subnet configuration file, or turn it on by default.
  4. This layer will set a default root password that should be changed by the local administrator. If you fail to change the password you should contact an OIT Support Staff member to help you access your machine.
  5. IMPORTANT SOLARIS 2.9 NOTES:
    1. Solaris 2.9, as installed in the BU clusters, includes bash, tcsh, zsh, bzip, gzip, patch, less, and zip, all of which were previously OIT supported packages. If you do not select a BU cluster for the install you may not get these packages (unless you add them specifically). This may cause problems after your installation is complete, as many OIT tools may expect them to be present.
    2. Solaris 2.9 includes Perl v5, so this is no longer installed as part of the configuration process. If you do not use a BU cluster, you may not have this installed. Again, this may cause problems after installation as many OIT tools may expect Perl to be installed.
  6. This module cannot be deselected by the administrator.
Generic OS Configuration Module (optional, default)
  1. This module will perform some basic system configuration, including configuring syslog and installing log rotation and reporting scripts. It will also rebuild the man pages, and disable the SNMP, PPP and NIS services that are turned on by default by the OS. It also configures CDE to allow a user to select an OpenWindows Desktop (using the twm window manager).
  2. This module will also add the proper entry in the hosts file for your machine and configure the defaultrouter file for your subnet
  3. The installation of this module is optional, but will be installed by default.
Distributed Computing Module (optional, default)
  1. Installing this module gives you access to the campus wide Application Server environment. The application server provides a workstation with scores of compiled binaries such as emacs, enscript, netscape, and LaTex. It also provides access to a copy of the Workshop Compilers (C, Fortran, Pascal, ADA) without requiring the large amount of disk space that is normally required for the installation.
  2. In order to provide this service effectively, the local system must perform some caching operations to reduce the network overhead. This caching is done in /usr/vice/cache. If you plan to use this module, you should allow 100MB for your /usr/vice/cache directory. You can either make this a separate partition (recommended), part of /usr, or a symlink to space in another partition.
  3. Binaries may be slow to load the first time you use them under this type of scheme. Once the binary has been loaded once, however, subsequent invocations should make use of the cache, reducing the load time to approximately the same the speed as having the binary on the local disk.
  4. This module is optional, but will be installed by default.
Subnet Specific Module (optional)
  1. As part of the customization process, the install script will check for a configuration script on the bootserver that contains subnet specific configuration instructions. This allows the local administrator the opportunity to specify what configuration should be done by default. If no script is found then the customization will skip to the next level.
  2. Since it is conceivable that you might have machines that should not use the subnet configuration option, it is possible to force the customization process to skip this script even if it is present.
  3. Instructions for writing this script are contained later in this document.
Host Specific Module (optional)
  1. As part of the customization process, the install script will check for a configuration script on the bootserver that contains host specific configuration instructions. This allows the local administrator the opportunity to specify what configuration should be done by default. If no script is found then the customization will skip to the next level.
  2. Since it is conceivable that you might have machines that should not use a configuration file even though it is specifically for the given host, it is possible to force the customization process to skip this script even if it is present. This might be useful for troubleshooting problems.
  3. Instructions for writing this script are contained later in this document.
Security Module (required)
  1. The security module will perform configuration of your host as the last step before rebooting to the new operating system. The changes made by this script are intended to be generic and widely applicable. They will include changes recommended by CERT, AUSCERT and other security organization and lists, as well as the installation of security monitoring software such as Baseline and COPS. Services that are enabled by default by Sun are often disabled at this layer to prevent systems administrators from running things they don't need or even want.
  2. The installation of this module is not optional.

Writing a Host or Subnet Specific Module

When reaching layers 5 and 6, the customization script will look at the bootserver for the presence of files named subnet.sh and <hostname>.sh respectively in the config directory. If the appropriate scripts is present, it will be executed.

The local administrator should make full use of this scripting to configure the host as desired. Some examples for use are:

  • Installing binaries specific to the subnet or host.
  • Loading host or subnet specific configuration files, such as /etc/mail/sendmail.cf, /etc/printers.conf
  • Configuring NIS to bind to the appropriate domain.

There are some guidelines that you should be aware of, however, when writing these scripts.

  • The filesystems that make up your new system are mounted on /a during the installation. So, if you want to create a symbolic link called /var/pubspool to a real directory called /var/spool, the link should be created in your script as:
ln -s /var/spool /a/var/pubspool
Attempting to call the link /var/pubspool will fail, and linking to /a/var/pubspool will be
incorrect following the reboot.
  • The base configuration directory, the directory specified by the install_config bootparams directive, is almost always /tmp/install_config. However, the best way to be sure that it won't move on you is to use $SI_CONFIG_DIR, which is set at the start of the installation to the mount point of the configuration directory. In the case of WebStart, the /tmp/install_config is used for other purposes, so $SI_CONFIG_DIR is reset when calling the MASTER_FINISH script. If you use $SI_CONFIG_DIR in your scripts it will work no matter which network installation client you use.
  • If you should decide to mount a directory to do an overlay or something to that effect, always specify the server from which you will be mounting the directory by its IP address. It is often an incorrect to assume that the install client will be able to resolve a host name.
  • The scripts should be written in sh, as other shells may not be available to you in the jumpstart environment.
  • For commands (such as catman) that should be run in a real environment, make use of chroot /a <cmd> to simulate that environment. A trick OIT employed in the Solaris 2.5.x jumpstarts was to write out a script to /a/var/tmp, then chroot to /a and execute the script.
  • Not all commands are available in the jumpstart environment so keep your scripts simple and use full pathnames. You may be able to specify commands using /a/<path to command> in some cases, but this will fail in others. In those cases where it fails, if the command is not available as part of the jumpstart environment, it may be necessary to use the chroot method described above.
  • Make sure you make the script executable when you are done writing it. A script that is not executable will be skipped during the installation.
  • Trial and Error is the rule of thumb for writing jumpstart scripts. Be prepared to repeat the installation and finish scripts, and keep trying. Also feel free to ask questions of the OIT Support Staff as we have a lot of experience writing these scripts.



An example of the Subnet Configuration Module
The following module is used by OIT Support to configure workstations used by OIT staff. It is installed on every Sun workstation used by OIT. A copy of this file is provided when you install the Boot Server. The file is called subnet.sh and is located in:

/usr/local/bootserver/sun4_59/Solaris_9/config/


#! /bin/sh

PATH=/sbin:/bin:/usr/sbin:/usr/bin; export PATH

JUMPSTART_ROOT=${SI_CONFIG_DIR}

BASE_PATH=$JUMPSTART_ROOT/template
TARGET_PATH=/a

echo " Installing ITnet specific customizations"
( cd $BASE_PATH; tar cf - . ) | ( cd $TARGET_PATH; tar xvpf - )

# Fix the man pages...

echo " Building man pages database "

if [ ! -x /a/bin/catman ] ; then
echo " - FAILED: Installation did not provide catman tool."
else
if [ -d /a/usr/local/man ] ; then
echo " - Building /usr/local/man/windex"
chroot /a /bin/catman -w -M /usr/local/man
fi

if [ -d /a/usr/share/man ] ; then
echo " - Building /usr/share/man/windex"
chroot /a /bin/catman -w -M /usr/share/man
fi
fi

 

The template area contains configuration files specific to the IT subnet, such as printers.conf, sendmail.cf, mail aliases, domain configurations, etc.

 

Office of Information Technology
Boston University