Revision

  $Id: webjob-update-client.base,v 1.2 2007/09/12 04:35:06 klm Exp $

Purpose

  This recipe demonstrates a technique for updating WebJob clients
  using WebJob. In particular, this recipe focuses on the client-side
  binary.

Motivation

  This recipe grew out of the need to find a cleaner and more robust
  way to update the WebJob client on Solaris systems. In particular,
  Solaris has been problematic because WebJob will dump core if it
  tries to update itself while it's running. While this problem has
  only affected Solaris platforms to date, this recipe was written to
  support several popular UNIX-based platforms, and extending it to
  support additional platforms should be fairly straight forward.

Requirements

  Cooking with this recipe requires an operational WebJob server.
  If you do not have one of those, refer to the instructions provided
  in the README.INSTALL file that comes with the source distribution.
  The latest source distribution is available here:

    http://sourceforge.net/project/showfiles.php?group_id=40788

  Each client must be running UNIX and have basic system utilities
  and WebJob (1.6.0 or higher) installed.

  The server must be running UNIX and have basic system utilities,
  Apache, and WebJob (1.6.0 or higher) installed.

  The commands presented throughout this recipe were designed to
  be executed within a Bourne shell (i.e., sh or bash).

  This recipe assumes that you have read and implemented the following
  recipe:

    http://webjob.sourceforge.net/Files/Recipes/webjob-run-periodic.txt

Time to Implement

  Assuming that you have satisfied all the requirements/prerequisites,
  this recipe should take less than one hour to implement.

Solution

  The solution is to schedule a job to run webjob-update-client.  To
  keep things simple, this recipe assumes that you are already using
  the hourly and/or daily scripts.

  1. Download webjob-update-client from the following location, and
     install it in the common/commands tree.

       http://webjob.cvs.sourceforge.net/webjob/webjob/tools/webjob-update-client

       # WEBJOB_CLIENT=common
       # WEBJOB_COMMANDS=/var/webjob/profiles/${WEBJOB_CLIENT}/commands
       # cp webjob-update-client ${WEBJOB_COMMANDS}
       # chown root:wheel ${WEBJOB_COMMANDS}/webjob-update-client
       # chmod 644 ${WEBJOB_COMMANDS}/webjob-update-client

     Next create a slave script using a symbolic link.

       # cd ${WEBJOB_COMMANDS}
       # ln -s webjob-update-client webjob-update-client.slave

     Note: If you are using DSV, don't forget to sign these scripts.

  2. If you want to pool all the output from each client into one
     place, create two custom config file overrides, and populate them
     with the controls shown below. Otherwise, you may skip this step.

       # WEBJOB_BASE_DIR=/var/webjob
       # cd ${WEBJOB_BASE_DIR}/config/nph-webjob/commands
       # mkdir webjob-update-client webjob-update-client.slave
       # vi webjob-update-client/nph-webjob.cfg
       Add content shown below...

       --- webjob-update-client/nph-webjob.cfg ---
       OverwriteExistingFiles=N
       PutNameFormat=custom/webjob-update-client/%Y-%m-%d/%H/fg_%cid_%Y-%m-%d_%H.%M.%S.%pid
       --- webjob-update-client/nph-webjob.cfg ---

       # vi webjob-update-client.slave/nph-webjob.cfg
       Add content shown below...

       --- webjob-update-client.slave/nph-webjob.cfg ---
       OverwriteExistingFiles=N
       PutNameFormat=custom/webjob-update-client/%Y-%m-%d/%H/bg_%cid_%Y-%m-%d_%H.%M.%S.%pid
       --- webjob-update-client.slave/nph-webjob.cfg ---

     Note: Making both config files write to the same custom
     directory. This is just a convenient way to store the data for
     two different, but related, jobs.

  3. Compile WebJob (see README.INSTALL), and turn the binary into a
     PaD file. Here, we'll assume that you are upgrading to 1.7.0.

       # pad-make-script -c webjob > ${WEBJOB_COMMANDS}/webjob-1.7.0-<os>.pad

     where <os> must be one of 'freebsd', 'linux', 'macosx', or
     'solaris'.

     Note: If you are using DSV, don't forget to sign this PaD file.

     Note: If you have a small number of systems that require a custom
     binary, the easiest thing to do is to put a custom PaD file in
     the commands tree for each particular client. For example,
     suppose a particular client (client_host1) needed a 64-bit
     version of the binary and all the other clients only needed the
     32-bit version. To handle this special case, create two PaD
     files as shown here:

       # pad-make-script -c webjob-32-bit > ${WEBJOB_BASE_DIR}/profiles/common/webjob-1.7.0-<os>.pad
       # pad-make-script -c webjob-64-bit > ${WEBJOB_BASE_DIR}/profiles/client_host1/webjob-1.7.0-<os>.pad

  4. Schedule the following oneshot job to test the new binary.

       ${WEBJOB_HOME}/bin/webjob -e -f ${WEBJOB_HOME}/etc/upload.cfg webjob-update-client -H ${WEBJOB_HOME} -v 1.7.0 -t

     Then, review the uploads to see if there were any issues.

  5. Schedule the following oneshot job to deploy the new binary.

       ${WEBJOB_HOME}/bin/webjob -e -f ${WEBJOB_HOME}/etc/upload.cfg webjob-update-client -H ${WEBJOB_HOME} -v 1.7.0

     Then, review the uploads to see if there were any issues.

Closing Remarks

  This recipe is a work in progress.

Credits

  This recipe was brought to you by Klayton Monroe.

References

  None.