Month: March 2014

One of the things that many system administrators encounter in the quest for maintaining up-to-date servers is the need to apply regular maintenance releases.  With some operating systems, Mac OS X for instance, the patches are released in two forms:

• a delta update, which contains only the changes necessary to bring the system up-to-date from the current running release level
• a combo (cumulative, full, etc.) update, which contains all changes for the current release branch

If you are lucky enough to be using an OS that gives you delta updates then you may not ever run into an issue where you don’t have enough internal drive space to update the OS.  However, if you are running an OS, like Solaris, that uses cumulative clusters then this becomes more interesting.

One situation I recently encountered was a need to patch a Solaris 10 Sparc system that did not have sufficient internal drive space to store the unzipped patch cluster for patching the system in single-user mode.  (You are patching in single-user mode right?)

The most obvious question would be: why not add another drive?  Another obvious question might be: why not patch from cd/dvd?  Well, adding a new drive to this system was not a viable solution since there were no available drives to install.  Installing from DVD would have been a possible solution, if the patches had been unzipped and burned to disc prior to the maintenance window.

The next available option was to install the patches over the network.  When patching a machine in single-user mode this becomes a little more problematic, since network resources and services are not generally available unless the server has been brought up in a multi-user mode.

After bringing the server up in single-user mode the next step was to start SSH and NFS so that the patch cluster could be installed over the NFS share.  Generally with Solaris 10 all you would need to do is execute the following command for both SSH and NFS client:

svcadm enable 

Unfortunately with single-user mode this will fail to work, since the dependent services are not auto-started.  To accomplish this in single-user mode you need to add the -r flag which instructs svcadm to start the service and recursively start the dependent services.  If you want a little more checking, also add the -s flag which tells svcadm to wait for each service to enter an online or degraded state before returning.  Below are the commands for starting SSH and NFS along with the output of a service check to show the state after the command was executed.

SSH

# svcadm enable -rs svc:/network/ssh:default
Reading ZFS config: done.
# svcs -a | grep ssh
online         15:49:26 svc:/network/ssh:default

NFS

# svcadm enable -rs svc:/network/nfs/client:default
# svcs -a | grep nfs
disabled       15:11:34 svc:/network/nfs/cbd:default
disabled       15:11:34 svc:/network/nfs/mapid:default
disabled       15:11:35 svc:/network/nfs/server:default
online         15:50:35 svc:/network/nfs/status:default
online         15:50:35 svc:/network/nfs/nlockmgr:default
online         15:50:35 svc:/network/nfs/client:default
uninitialized  15:11:37 svc:/network/nfs/rquota:default

After this was done all that was left was to mount the exported file system and run the patch cluster installation script.  Since the cluster was not local to the system it took a little longer to install the cluster, but other than that everything went smoothly.

My last two posts, Starting NRPE via launchd and Nagios NRPE on OS X Server 10.5, concerned getting NRPE to run on OS X Server 10.5 and having it startup at system boot.

However, this is only part of the battle.  Once you have Nagios monitoring setup on your server you also need to have some nice options for checking the availability of your running services.

Tim Wilson from the Savvy Technologist, wrote an NRPE plugin that helps out with this.  The plugin check_osx_services does an excellent job of checking on the status for many services running on 10.5 Server.

The documentation on the plugin at the NagiosExchange site is pretty thorough.  One thing that is not mentioned is that you will need to run the check_osx_services script as superuser since it calls the system level command serveradmin which must be run as root.

As with any project, there are always users that want a particular feature that either doesn’t exist or the feature exists but doesn’t meet their needs.

In the deployment of the Adobe Contribute Publishing system at my current job this was the case. The library staff desired a way to insert Dublin Core Metadata Initiative tags into their documents.

The Adobe Contribute client already gives the user the ability to insert keyword and description metatags, but this was not sufficient for their needs.

Turns out that the Contribute client is extensible through the same sort of command files that you can build to create custom commands and behaviors for Dreamweaver. After reading through the relevant sections of the Macromedia manual Extending Dreamweaver MX (publication number ZDW60M200) that I had gotten with my Studio MX purchase some time ago, I began to develop a custom plugin to do what the library staff wanted.

The result is my Dublin Core Metadata Plugin.

To-Do

1. Change it so that the values are stored separately with regards to content and format.
2. Add drop-down menus for the selection of the scheme (a.k.a. format).
3. Add mechanism for multiple authors and contributors.
4. Add mechanism for handling date.modified tags.
5. Build a Windows Installer
6. Test the installer on Mac OS X 10.5.

Downloads