Slipstreaming Post Service-Pack Patches into a Service Pack Build on NetWare

Abstract: This article describes procedures for including patches released after a service pack into a service pack. Some patches are very simple, and others require knowledge of obscure Novell scripting. This can reduce (sometimes greatly) the number of reboots required during the application process of a NetWare service pack. Especially if the Service Pack has been out a while and there are a number of post-SP patches. In larger environments it can be used to help unify server patch-levels by providing a custom build.

Introduction

The longer you wait after a Service Pack comes out, the more post Service Pack patches you generally need to apply. Also, some Service Packs ship with flaws that will hurt you significantly, and the post patches fix the flaws. It would be nice to be able to include the patches in the Service Pack (SP) build itself.

This can be done, but it takes understanding of how Service Packs are constructed. It also can require the ability to read install scripts. But when done right, it can provide a way to get all of your post-SP patches included into the SP build itself and minimize the steps required to get it all in.

Generally speaking, patches come in two flavors:

Patches where the install process is, "Read the readme, copy the files where it tells you to."

Patches where the install process is, "Launch NWCONFIG, and Install New Product."

The first type is the easiest to include in a SP build. The second requires some reading, but for all but the most complex of patches (such as eDirectory updates, or anything that updates by way of RPM such as BASH) it can be done. This article will walk you through getting both types included.

Service Pack Build Structure

Before you can start including patches into a Service Pack, you need to understand how the SP is organized.

The directories most immediately useful to the slipstream process are the STARTUP, SYS, PRODUCTS, and SP directories. STARTUP and SYS contain the base operating system updates and are copied to C:\NWSERVER (or wherever your SERVER.EXE lives) and SYS:\ respectively. PRODUCTS includes everything that is an installable product, such as NDPS/iPrint, eDir, NetStorage, SMS, and Apache. The SP directory contains the scripts that actually drive the Service Pack install process itself.

Files in the STARTUP and SYS directories will get copied to every single NetWare server that Service Pack build is installed on. Once that file copy is completed, the Service Pack process then starts applying updates from the PRODUCTS directory depending on what it finds installed on the server. When you are putting updated files into the SP build, you need to make sure that you are copying over the old file in the build tree. Most of the files in the PRODUCTS directory are kept in compressed archives, so it can take some poking to find where the updated files need to go.

Including Simple Patches

Simple patches are the ones where you do the file copying based on what the attached documentation tells you to do. Generally they are pretty simple and include only a few files. For larger operations Novell is pretty good about making install scripts to handle the copying process.

For this example, I'm going to use the patch titled, "iPrint Updates to NetWare Support Pack 5 (iprntnw65sp5d.exe)", which you can obtain here.

This is an iPrint patch, not a base OS patch, so the area we will be working in is the PRODUCTS directory. We'll be leaving the STARTUP and SYS areas for another patch. Looking inside the PRODUCTS directory we see PRODUCTS\NDPS. Inside the NDPS directory we see three files, titled APACHE2.ZSP, GATEWAYS.ZSP, and IPRINT.ZSP.

These are ZIP-formatted files, but the base Windows ZIP editor can't handle them. Use a third party tool such as WinZip or 7-zip to open them. Once you open them, you can see the files included. This is where we will be updating files.

If you crack open the APACHE2.ZSP file you will see a directory at the top level titled, "apache2". This will ultimately install to SYS:\APACHE2\. Drill down again and you get a pair of directories, "htdocs," and, "iprint." Reference the Readme that came with the patch, and you will see this directive:

5. Copy the updated NDPSM.NLM, IPPSRVR.NLM, and NIPPED.NLM to the
server's SYS:\SYSTEM directory and MOD_IPP to SYS:\Apache2\iprint

This tells us that we need to look into the apache2\iprint directory, where we do indeed find the MOD_IPP.NLM. Copy the updated MOD_IPP.NLM from the patch to this sub-directory in this archive. Since this is the only file going into the Apache2 directory structure, close the archive.

Since none of the remaining update files are gateways, we can skip the GATEWAYS.ZSP file and go right to IPRINT.ZSP. As with the APACHE2.ZSP file, this contains the file structure as if it were at the root of SYS:. Since the instructions told us to go to SYSTEM, go into that sub-directory. All three of the remaining files are in this sub-directory, so copy in the three files from the patch over the files in the archive.

Congratulations, you've just slipstreamed your first patch into a Service Pack build.

Unfortunately, it isn't always obvious what directory under PRODUCTS you need to go into. In this case the iPrint files were in the NDPS directory. This is because when IP Print was integrated into NDPS, Novell renamed NDPS to iPrint. Novell just kept the name in the Service Packs for their own reasons. Another example is NetStorage, which is kept in the "ISTORAGE" directory. Sometimes it can take a lot of poking to find where you're looking for.

Including NWCONFIG installed Patches

These are significantly more complex to install, but it can be done for all but the most complex of patches. NWCONFIG uses a script included in the patch directory to tell it what to do. To understand what to do with the update files, you either need to be able to read the supplied script and integrate it into the full Service Pack build (aie!), or read the key bits and do a bit of twiddling. The second is much easier, and what I cover.

Most, but sadly not all, NWCONFIG installed patches copy files to many directories and update the products database. They also usually include NetWare version checking and sometimes product version checking as well. Some even include schema updates as part of the process, which is why we leave those for their own installs and don't try to slipstream them.

For a lot more detail about how these scripts work, the documentation is contained within the NetWare 6 manual set.

For this example I'm going to use the patch titled, "Post SP5 NSS Modules for NetWare 6.5 (n65nss5a)", which you can obtain here.

Download and explode the patch. At the root of the "N65NSS5A" directory is a file called "nss.ips". This is the script that NWCONFIG will use to install the patch. Open this file in Notepad, and follow along.

This is the version checking that NWCONFIG does to make sure this patch can be applied. It is looking for NetWare 6.5 SP5, which we're installing right now. So we still don't care. But nice to know at any rate. Following this section are the messages NWCONFIG displays when the checks fail. For what we are doing, it doesn't matter.

This section sets certain variables it uses during the file copy operations. %{NWBOOT} is a built-in variable for where SERVER.EXE lives, and can change from the default of C:\NWSERVER\. "NWSRC" is the patch source directory.

This sets more variables, and also sets up the file backup process. Since the Service Pack includes NSS updates already, we can safely assume that the existing SP install process will back these up. So we can safely ignore all the bits of this script that involve backing up files.

This section erases files that are in the wrong spot. Past NSS versions had things in different places so this step is needed. However, since the SP build already includes an NSS update, it is safe to assume that this step is already being taken. Therefore, we can ignore this section as well.

This, after all this time, is the actual update process itself. It says to copy the contents of "startup" to C:\NWSERVER, and "system" to SYS:SYSTEM. Very simple in the end, but the script had to be sure the environment was correct before it got this far.

Because this is an OS patch, these files will go into the STARTUP and SYS\SYSTEM directories in the SP build.

That's a lot of checking, and a very few lines that actually perform the update. In our case the Service Pack already includes NSS updates, so we don't have to worry about including the version checking logic. The most complex task will be to get the Product Database updated.

First and foremost, the CopyFile lines that actually do the update. That tells us that the contents of N65NSS5A\System\*.* need to be copied to SYS\SYSTEM in the SP build. The same for N65NSS5A\STARTUP\*.*.

Next we need to get the product records into the database. To do that, we need to edit the file SP\INSTALL\STARTUP.ICS. This particular file is what drives the majority of the service-pack install and is therefore quite large. Happily, the section we need is right at the bottom.

This will tell the script to update the product records for these patches as the very last thing it does.

By doing it here it more closely resembles doing patches after the SP has been applied. The ProductRecord updates for PRODUCTS are done during those installations. This way 'installation order' as far as the Product Database is concerned is maintained. Later patches that may require a post-SP patch will then be able to see the correct product versions in the database.

Second Example: Complex Script

For this example I'm going to use the patch titled, "Updated LIBC & DSAPI libraries (nwlib6h.exe)", which you can obtain here.

As with the first example, download and explode the patch. At the root of the patch directory you will find a file named 'install.ips'. This is what NWCONFIG uses to install this patch. Unlike the first example, this particular patch has selectable options permitting the installation of pieces of the patch. This adds complexity to the IPS file.

The selectable options are between the @FileSet and @EndFileSet lines. This patch has three selectable options:

Backup current Library files

NetWare LIBC Update

NetWare CLIB / DSAPI Update

The script between the @FileSet and @EndFileSet lines describes to NWCONFIG how to install the patch. We can ignore the first set since the Service Pack handles that function for us already. Now lets look at the NetWare LIBC Update section.

This is the second SGotoIfEqual. It checks to see if the SP Rev is new enough for Bash to be installed by default, and if so, updates (CopyFile) NWTERMIO.NLM.

Update Product Database.

This is the ProductRecord pair of lines.

The three CopyFile lines tell us where updated files live, and where they're intended to go. The first two install files into NWBOOT (usually C:\NWSERVER), and the associated NLS files (usually C:\NWSERVER\NLS). The second one copies NWTERMIO.NLM to SYS:\BIN. Looking in the Service Pack build, we find that the update files exist in STARTUP, not in PRODUCTS. Therefore we copy the update files there.

The BASH update is another story. That file is in PRODUCTS\BASH. The full path of where to drop the file is:
\PRODUCTS\BASH\BASH.RPM\BASH.cpio.gz\BASH.cpio\.\bin\
This means you need to have a decompression utility that can open and modify RPM files. As of Service Pack 5 (OES SP2) this particular file hadn't been included in a Service Pack yet, so the file doesn't exist in the Service Pack. You will have to add it.

As of this writing, the state of RPM modification tools for Windows is nearly nonexistent. If you don't know how to modify RPMs, mark this one file for post-update attention. In this specific case, since the file doesn't yet exist in the Service Pack we can get away with putting it into SYS\BIN\ in the SP build tree. But later service-packs will have this file, and this trick won't work as well. See Gotchas section for details as to why.

Now we need to put in the ProductRecord lines into the SP\INSTALL\STARTUP.ICS file. As with the first example we will insert the ProductRecord lines right before "GotoIfEqual":

This will tell the script to update the product records for these patches as the very last thing it does. By doing it here it more closely resembles doing patches after the SP has been applied. The ProductRecord updates for PRODUCTS are done during those installations. This way 'installation order' as far as the Product Database is concerned is maintained. Later patches that may require a post-SP patch will then be able to see the correct product versions in the database.

This script checks for if we're running NetWare5 or NetWare6. Since this is a NetWare 6.5 Service Pack, we'll follow the NetWare65 flow after the Label VERSION65_IS_CORRECT line. This tells us that we copy the contents of \65\system to SYS:\SYSTEM, and \65\STARTUP to C:\NWSERVER. Looking inside the SP Build, we find these files in SYS\SYSTEM and STARTUP. Copy these files over the existing ones.

Then we need to update the Product Database. We place that line right below the ones we did for the previous section:

Summary

If all it is doing is checking versions and environment and then copying files, it is a good candidate for slipstreaming.

As with the 'simple' patch process, copy the updated files where the script tells you to. It may be in PRODUCTS, or in either of STARTUP or SYS.

Modify the SP\INSTALL\STARTUP.ICS file to include the correct ProductRecord lines.

Gotchas

Resist as long as you can the temptation to put the updated files in SYS and STARTUP instead of there they belong in PRODUCTS. Because of how the install process works, you will almost definitely end up with problems during the service pack installation process. The files in those two directory trees are copied first, and then the PRODUCTS tree is installed later. If you had copied MOD_IPP.NLM into SYS\APACHE2\IPRINT in the SP build, it would get copied. But when the APACHE2.ZSP file expanded you would be met with a dialog like this one:

File MOD_IPP.NLM being copied is older than the current file. What do you want to do?

And that dialog box would appear for every file like that. If you can't find where the file goes in PRODUCTS, you can get away with putting it into SYS or STARTUP. Doing it that way makes the SP build less clean, as well as potentially generating errors.

Conclusion

As time passes after a Service Pack is released, post-SP patches accumulate. These fix problems introduced by the SP, and fix problems the SP didn't fix. If it has been a while since the SP came out, there are going to be a few post-SP patches to apply. With this method you can include those patches inside the Service Pack build itself and apply them all in one reboot.