Redirecting the home page URL

[Big Job ]

You want to use client-side redirects? For the home page URL? With Zeus? And NSAPI? Are you mad??! Not yet...

Due to a - ahem - oversight in the development process, our friendly neighbourhood webslingers recently delivered a web application whose home page was located not under / but under /public. No problem, I confidently thought. I'll use the frontend Zeus web server to alias the home page URL to the actual one...

First of all, forget the URL mapping feature. This maps URLs to physical directory paths in the filesystem. In this case, /public was a virtual URL handled by the application (via an NSAPI call). And URL mapping occurs after NSAPI calls.

We'll use client-side redirects in the global htaccess file instead. But after several days spent trying every conceivable form of redirect command, including one sweaty morning two days before go-live (when an email highlighting a "potential showstopper" received a deafening silence from the culprits), there was almost blood on the keyboard. It seemed like every time I got it working, a minor tweak to the document root contents or the NSAPI handler config would break it again. Of course, this is a recipe for unstructured, panicked testing and unverified results so I apologise if some of the following is inaccurate.

For the record, this method works (because it's working now on a corporate site):

1. Create a dummy (empty) index.html file in the document root on the web server.
2. In the htaccess file (remember to enable them in ZWS), use the following:
   

   redirect permanent /index.html /public/
   

This will cause clients requesting http://website.com/ to be redirected to http://website.com/public/ (from where the request will be picked up by the NSAPI handler).

From this, I deduce that, because the NSAPI handler ignores '/' as a URI, Zeus looks in the document root and finds a suitable default file (the dummy index). It then consults the htaccess file, which causes a 301 redirect and new Location: header to be returned to the client. The subsequent request is successfully processed by the NSAPI handler. The downside is, the user now sees (and bookmarks) a URL that doesn't match the original one.

The following definitely don't work:

• Using / instead of /index.html in the Redirect directive - causes a redirection loop;
• Using Location section directives to limit the redirected URL to / (either standard or a regex in LocationMatch) and thus avoid a loop - I don't know why not;
• Removing the dummy index file - causes a 403 access denied (if directory indexing is disabled);
• Using the NSAPI redirect function - don't go there.

Note: for Apache, the following will work:

<LocationMatch ^/$>
        Redirect / http://website.com/public/
</LocationMatch>

It looks like this processing takes place before the other modules are called.

Alternative approach: Use a META refresh tag in the dummy index file.

Installing large SunFreeware packages

[Big Job ]

Problem: some of the larger SunFreeware packages won't install because they run out of space.

This particularly affects GCC. SunFreeware packages are supplied in datastream (single file) format. When pkgadd installs one, it first tries to translate it to file system format using the spool area in /var. I installed on a host with 195Mb free space in /var and I still ran out of space (because the GCC 3.2.2 pkg is 280Mb uncompressed).

To workaround this, simply do the package translation yourself prior to installing. Choose a filesystem with lots of space, move the downloaded package there and run:

$ gzip -d gcc-3.2.2-sol8-sparc-local.gz
$ pkgtrans gcc-3.2.2-sol8-sparc-local . all
(become root)
# pkgadd -d .

For future use, you may wish to tar and compress the directory created from this procedure, then delete the original datastream pkg.

The Solaris Security Toolkit (JASS)

[Big Job ]

(No. 1 in an uncharacteristic and occasional series of potentially useful tech notes. :-)

If you're installing the JASS toolkit on Solaris, there are a few extras that the docs don't clearly mention.

Solaris has had JumpStart automated installation for years (since 2.2 if I remember correctly - and it worked too, as I discovered when I built a teaching lab of twenty Classics simply by booting them :-). It's only recently that they've begun to capitalise on this feature by providing tools and support that make use of it. The Security Toolkit, as well as providing an automated method of hardening your systems, also forms a ready-rolled JumpStart server setup.

However, there are some additional tools available from the tools section of Sun Blueprints that you should also install. Fetch the following:

• FixModes.tar.Z
• md5.tar.Z

Move them into the Packages/ subdirectory of your JASS/JumpStart install directory. If they're present, then the JASS scripts will automatically install them and run fix-modes to tighten the default file permissions. (Also, if you copy the original SUNWjass package into this directory then it too will be installed on the client should you wish to run it again later. But see below for reasons why you mght not want to do this.)

The standard secure.driver script is too restrictive for desktop systems; use desktop-secure.driver instead. Be warned though that this leaves telnet & FTP enabled. You can edit the driver scripts to fix this, but this becomes messy:

The SUNWjass package installs into /opt/SUNWjass. However, this is unlikely to be your chosen JumpStart directory so you'll probably copy it elsewhere as the docs show. Then you'll make changes, such as to the user.init file or those listed above. Now, to keep your local package version in sync, you'll have to replicate those changes back to it. But if you've been installing JASS locally on your JumpStart clients, you'll also need to replicate the changes to those. And if you install a new version of JASS, you may overwrite your changes.

Sack it. I suggest you use JASS to perform consistent, baseline secure installs and then use Cfengine to perform any post-installation tweaks and ensure that each system continues to conform to the baseline. Don't bother installing JASS anywhere other than your JumpStart server.

JASS is a great package, but the administrative requirements haven't been thought out - which is not unusual from a vendor. Ideally, user-specific changes or overrides should be maintained outside the standard install tree and included separately on execution. And it's arguable whether the package model (with no obvious relocation mechanism) suits a package that needs to be identical in two locations on the server and on every client.

A leader of Venezuela's general strike...

[Big Words ]
"... was seized by gunmen identifying themselves as secret police agents, it was claimed today."

"Freeze, we're secret police agents ... DOH!!"

The US military has developed a strap-on kit...

[Big Words ]
"...that makes 'dumb' bombs smart."

...Rejects claims that prototype testing on the President proves it doesn't work. "We said 'bombs', not 'bombers'", clarifies top general.

Welsh war memorial

[Big Picture ]

For Douglas, who came back.

Water over rocks II

[Big Picture ]

Simple but effective.