Note that you can always access the ergonomics resource easily from the blog’s main menu.

Digging some more, I came across a post by Dave Christiansen where he points out an obscurely documented switch for openssl req command. That works great for single self signed certs, but what if you’re using an internal CA? The CA cert can be created with “-sha512″ command using “openssl req” (as outlined in Dave’s post), but then when you sign server certs with “openssl ca” – even when you’ve created the CA cert with the “-sha512″ switch – Chrome still throws the same error.

The trick is to specify an equally obscurely documented argument “sha512″ for the “-md” switch with “openssl ca”, like so:

openssl ca -md sha512 -config /etc/ssl/openssl.cnf.internalCA -policy policy_anything -in my.server.name.csr -out my.server.name.pem -keyfile ../private/internalCA.key -days 3650

Now the signed server certificate reflects “sha512RSA” as the Signature algorithm, and the Chrome error is gone.

But they are workable, and human beings adapt. There is an interesting point I just realized, and I thought of sharing it. Kensington’s misleadingly named Expert Mouse works very well in situations where the work surface is low (as it should be for decent ergonomics) so that it is possible to use a third party arm-rest (my preference is “330 000″ series ErgoRest forearm support) with it. When your hand ‘floats’ above the trackball, it is quite pleasant to use for extended periods of time.

However, in many situations the desk height is too high and Expert Mouse suddenly becomes much less pleasant to use. Its own wrist support is not that comfortable, especially when more of your arm’s weight is on it. In such situations Logitech’s wireless M570 (for some reason “M570″ sounds like a model of Mercedes-Benz to me ) works reasonably well. M570 is like a TBE in reverse. For some reason Logitech opted to place the ball at the thumb and button/scroll wheel controls at the forefinger/middle finger. I wish Logitech introduced a model with the controls (trackball/buttons+scroll wheel) reversed and we’d essentially have a new TBE… but even as it is, it works reasonably well. If you haven’t used a thumb-controlled trackball before it will take you a week or two to become fluent with it, and even then the accuracy is not quite as good as it would be with a forefinger-controlled trackball. But it’s close enough for M570 to work well. And M570 is small enough to lug along with your laptop – a lucky co-incidence since I think M570 works better in less-than-optimal ergonomic settings which you are more likely to encounter while on the road.

N.B.
While both manufacturers provide drivers/utilities for their respective devices, be sure to check out X-Mouse Button Control software as it is able to teach your trackball cool new workflow-improving tricks!

ls -latT /var/db/pkg | less

Since various systems can provide cross-mounts via NFS, and they may be started/rebooted at the same time, various shares may or may not be available at each system’s boot time. By utilizing this script the mounts become available soon after the respective share becomes available (simply adjust the run frequency in crontab to the needs of your specific application). Also, by not adding the NFS mount points in fstab the boot process is not delayed by a share that is not [yet] available.

First for CentOS/Linux:

#!/bin/sh

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin

# set mount/remount request flags
mount=false
remount=false

# remote system name
remotesystem="$1"

# rw/ro
if [ "$2" = "rw" ]; then
    mountmode="-w"
else
    mountmode="-r"
fi

# remote share name
remoteshare="$3"

# local mount point
mountpoint="$4"

# file to indicate local mount status
testfile=${mountpoint}/"$5" 

# rw test file
rw_testfile=${mountpoint}/nfs_enforcer_rw_testfile

# command locations
pingcmd=/bin/ping
showmountcmd=/usr/sbin/showmount
grepcmd=/bin/grep
mountcmd=/bin/mount
umountcmd=/bin/umount
statcmd=/usr/bin/stat
touchcmd=/bin/touch
rmcmd=/bin/rm

# --- end variables ---

# make sure the mountpoint is not stale
statresult=`${statcmd} ${mountpoint} 2>&1 | ${grepcmd} "Stale"`

if [ "${statresult}" != "" ]; then
   #result not empty: mountpoint is stale; remove it
   ${umountcmd} -f ${mountpoint}
fi

# ping the remote system (2 sec timeout)
${pingcmd} -w2 -c1 -q ${remotesystem} > /dev/null 2>&1

# make sure the remote system is reachable
if [ "$?" -eq "0" ]; then

   # query the availability of the remote share; not empty result indicates OK
   offsiteshare=`${showmountcmd} -e ${remotesystem} | ${grepcmd} "${remoteshare}"`
   if [ "${offsiteshare}" != "" ] ; then

      # make sure the local mount point (directory) exists (so that [re-]mount, if necessary, is valid)
      if [ -d ${mountpoint} ] ; then

         localmount=`${mountcmd} | ${grepcmd} "${mountpoint}"`

         # make sure the share test file is _not_ present (to make sure the mountpoint is inactive)
         if [ ! -f ${testfile} ] ; then

            # make sure the local mountpoint is inactive (double checking)
            if [ "${localmount}" = "" ] ; then

               # all set to go; request mount
               mount=true
            fi

         else 

            # make sure the local mountpoint is active (double checking)
            if [ "${localmount}" != "" ] ; then

               # attempt to create a test file..
               ${touchcmd} ${rw_testfile} > /dev/null  2>&1

               # ..and test its existence; first handle RW mounted shares:
               if [ -f ${rw_testfile} ] ; then

                  # share was RO requested
                  if [ "$2" = "ro" ]; then
                     remount=true
                  fi

                  # Delete the testfile
                  ${rmcmd} ${rw_testfile}

               # hanle RO mounted shares:
               else

                  # share was RW requested
                  if [ "$2" = "rw" ]; then
                     remount=true
                  fi
               fi
            fi
         fi
      fi
   fi
fi

# perform remount (unmount, request mount)
if $remount ; then
   ${umountcmd} -f ${mountpoint}
   mount=true
fi

# perform mount when so requested
if $mount ; then
   ${mountcmd} ${mountmode} -t nfs ${remotesystem}:${remoteshare} ${mountpoint}
fi

exit 0

Then for FreeBSD/UNIX:

#!/bin/sh

SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin

# set mount/remount request flags
mount=false
remount=false

# remote system name
remotesystem="$1"

# rw/ro
if [ "$2" = "rw" ]; then
    mountmode="-w"
else
    mountmode="-r"
fi

# remote share name
remoteshare="$3"

# local mount point
mountpoint="$4"

# file to indicate local mount status
testfile=${mountpoint}/"$5" 

# rw test file
rw_testfile=${mountpoint}/nfs_enforcer_rw_testfile

# command locations
pingcmd=/sbin/ping
showmountcmd=/usr/bin/showmount
grepcmd=/usr/bin/grep
mountcmd=/sbin/mount
umountcmd=/sbin/umount
statcmd=stat
touchcmd=/usr/bin/touch
rmcmd=/bin/rm

# --- end variables ---

# make sure the mountpoint is not stale
statresult=`${statcmd} ${mountpoint} 2>&1 | ${grepcmd} "Stale"`

if [ "${statresult}" != "" ]; then
   #result not empty: mountpoint is stale; remove it
   ${umountcmd} -f ${mountpoint}
fi

# ping the remote system (2 sec timeout)
remoteping=`${pingcmd} -c1 -o -q -t2 ${remotesystem} | grep " 0.0%"`

# make sure the remote system is reachable
if [ "${remoteping}" != "" ] ; then

   # query the availability of the remote share; not empty result indicates OK
   offsiteshare=`${showmountcmd} -e ${remotesystem} | ${grepcmd} "${remoteshare}"`
   if [ "${offsiteshare}" != "" ] ; then

      # make sure the local mount point (directory) exists (so that [re-]mount, if necessary, is valid)
      if [ -d ${mountpoint} ] ; then

         localmount=`${mountcmd} | ${grepcmd} "${mountpoint}"`

         # make sure the share test file is _not_ present (to make sure the mountpoint is inactive)
         if [ ! -f ${testfile} ] ; then

            # make sure the local mountpoint is inactive (double checking)
            if [ "${localmount}" = "" ] ; then

               # all set to go; request mount
               mount=true
            fi

         else

            # make sure the local mountpoint is active (double checking)
            if [ "${localmount}" != "" ] ; then

               # attempt to create a test file..
               ${touchcmd} ${rw_testfile} > /dev/null  2>&1

               # ..and test its existence; first handle RW mounted shares:
               if [ -f ${rw_testfile} ] ; then

                  # share was RO requested
                  if [ "$2" = "ro" ]; then
                     remount=true
                  fi

                  # Delete the testfile
                  ${rmcmd} ${rw_testfile}

               # hanle RO mounted shares:
               else

                  # share was RW requested
                  if [ "$2" = "rw" ]; then
                     remount=true
                  fi
               fi
            fi
         fi
      fi
   fi
fi

# perform remount (unmount, request mount)
if $remount ; then
   ${umountcmd} -f ${mountpoint}
   mount=true
fi

# perform mount when so requested
if $mount ; then
   ${mountcmd} ${mountmode} -t nfs ${remotesystem}:${remoteshare} ${mountpoint}
fi

exit 0

You should run the automount script from a runfile, like so:

#!/bin/sh

NFS_ENFORCE=/usr/local/sbin/nfs_enforcer

# Separate the following parameters with spaces:
#
# - nfs enforcer command (set above)
# - remote system name (must be resolvable)
# - read/write (rw) or read-only (ro); NOTE: share may be read-only regardless of how this is set
# - remote share name (from remote's /etc/exports)
# - local mount point (existing local directory)
# - share test file (an immutable file on the share)

# e.g.
# $NFS_ENFORCE dbsysvm rw /nfs4shares/conduit /mnt/dbsys_conduit .conduit@dbsysvm
# or (for local remount read-only)
# $NFS_ENFORCE localhost ro /var/web/projects/repository /mnt/rorepo .repository@localhost

$NFS_ENFORCE localhost ro /var/web/projects/repository /mnt/rorepo .repository@localhost

exit 0

..and call the the above runfile from crontab:

*/10  *  *  *  *  root  /usr/local/sbin/nfs_enforcer.batch > /dev/null

There are several hosted email solutions available – such as Rackspace Webmail or BlueTie Business Email. From time to time I’ve reviewed Rackspace’s features, and among other things they still did not support user-by-user adjustment of spam filter aggressiveness, or the ability to alias users and domains to actual accounts. Especially for the latter reason using Rackspace would be prohibitively expensive for me, so the search had to continue.

I think I have now found a workable solution: an in-house Postfix+Dovecot server with Google Postini as the edge (MX) service. Postfix is an incredibly robust and infinitely configurable mail server that I have only had positive experiences with. But I would rather not have to deal with spam filtering, and I also would rather not have to stress about “high availability” of the in-house server. Yes, the server will generally be up and receiving email, but should there be a hardware failure, I would want the inbound mail to be both cached and accessible while the server is repaired. Postini Message Continuity system provides this at $25/year/user (including spam/virus filtering), which roughly equals the annual cost of Fusemail service. If the receiving email server becomes unavailable, the arrived messages are cached, and are accessible via Gmail. Once the in-house service is then restored, the cached emails are quickly delivered.

However, one issue remained: in my configuration several of the aliased domains have ‘forward’ addresses that don’t have an associated user account at Fusemail, but that Fusemail has allowed to be forwarded to external destinations without an extra fee (or a separate account). I would not want to have to set up individual accounts at $25/year each to take care of these external forwards. But there is a way! Information about the aliased users and domains is retained in the messages as they’re forwarded by Postini. So by setting up one generic – or a “forwarder” – account at Postini, and then aliasing any such external forward accounts to it, it is possible to separate and correctly forward the emails to their intended recipients using Postfix’s rewriting rules.

Note that the in-house email server will need to be set to receive unauthenticated emails only from Postini’s IP range; that way spammers can’t bypass Postini filtering should they discover your SMTP server via port scan (and they will discover it, sooner or later). Also note that while Postini Message Continuity homepage mentions Exchange Server as the in-house mail server, they also provide instructions for how to integrate Postfix (more info can be found on the web).

While this solution does require familiarity with Postfix/Dovecot, it should offer an extremely stable email setup – and maximum amount of control over how email is routed – at a very reasonable cost.

When I get around to implementing this configuration I’ll write an article or series of articles of the process. Meanwhile I welcome any feedback, as well as suggestions for other comparable services. If a stable/high quality, reasonably priced, outsourced solution with good amount of control (equal or better than Fusemail) exists, I would consider it. But for now it seems that currently the only/best solution that won’t miss a beat while not breaking the bank is the one I’ve outlined above.

perl vihostupdate.pl -server x.x.x.x -username root -password “xxxxxxx” -b c:\AMCC_2.26.08.035vm40-offline_bundle-179560.zip -i

I recalled I had in the past renamed the lengthy bundle file to ‘offline_bundle.zip’, and did so this time, too, to make it easier to type the command. Executing the command (with the driver bundle named as c:\offline_bundle.zip), I got an error message: “No matching bulletin or VIB was found in the metadata.” Some more Googling, and I found a mention: »After shorting [sic] the name of the original file to offline-bundle.zip and re-running the command, I did get positive feedback in the form of this message: The update completed successfully.» So the name has something to do with it!

Interestingly my experience was exactly the opposite than that I found in a blog post from 2009: the driver bundle only worked with its original name (so the above command—which can also be found in the instructions—is the correct one). So not only should one read the instructions, but follow them, too!

#!/bin/sh

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin

# remote system name
remotesystem=sunrise.externalized.net

# remote share name
remoteshare=/nfs4exports/minecraft-backups

# local mount point
mountpoint=/bak/remote

# file to indicate local mount status
testfile=$mountpoint/.minecraftbackups

# command locations
pingcmd=/bin/ping
showmountcmd=/usr/sbin/showmount
grepcmd=/bin/grep
mountcmd=/bin/mount
umountcmd=/bin/umount
statcmd=/usr/bin/stat

# --- end variables ---

# make sure the mountpoint is not stale
testvar=`${statcmd} ${mountpoint} 2>&1 | ${grepcmd} "Stale"`

if [ "${testvar}" != "" ]; then
   #result not empty: mountpoint is stale; remove it
   ${umountcmd} -f ${mountpoint}
fi

# ping the remote system (2 sec timeout)
${pingcmd} -w2 -c1 -q ${remotesystem} > /dev/null 2>&1

if [ "$?" -eq "0" ]; then

   # server is available so query availability of the remote share; not empty is OK
   offsiteshare=`${showmountcmd} -e ${remotesystem} | ${grepcmd} "${remoteshare}"`

   # make sure the local mountpoint is not active
   localmount=`${mountcmd} | ${grepcmd} "${mountpoint}"`

   if [ "${offsiteshare}" != "" ] ; then
      if [ ! -e ${testfile} ] ; then
         if [ "${localmount}" = "" ] ; then
            ${mountcmd} -w -t nfs ${remotesystem}:${remoteshare} ${mountpoint}
         fi
      fi
   fi
fi

exit 0

There are several pages that discuss the issue extensively, and have a lot of good information on them. Yet another page has a quick low down on how to get the driver properly installed.

However, having not worked on ESXi CLI for some time I had forgotten, for example, that busybox that ESXi uses wipes the root files on every reboot. After a while I recalled (from an old note) that to save changes to the /etc/vmware/simple.map I would need to execute /sbin/backup.sh 0 /bootbank/ after making the edits. But even that was unecessary.

One sentence on the brief recap page, would have saved me couple of hours tonight. So here it is: »Just upload the attached oem.tgz into /bootbank folder with scp, then reboot, and you’re done!» And when you do that, you are done – the pre-prepared oem.tgz works perfectly!

Yes, had I known, I would’ve known, but I didn’t. Hopefully this saves time for someone else!

After looking around for the solution for a few moments I downloaded the free Parted Magic Live CD that includes GParted, Clonezilla and number of other utilities in an easy to use package. In the end extending the CentOS partition was a snap. After shutting down the CentOS VM, I first extended the VM disk in Workstation 7.1 VM settings from 10Gb to 20Gb in VM settings > Hard Disk > Utilities > Expand.

Then I edited the VM’s .vmx file by adding the following statement:

bios.bootDelay = “10000″

This slows down the VM’s boot sequence by adding a 10 second delay so that it’s easier to focus the VM screen (with a click of a mouse) and hit F2 before the VM startup commences. Note that you need to click the area of the VM screen where POST (boot) info is being displayed to give it focus; clicking on the similarly colored (black) area closer to the edges of the VM display is at ths point (during the boot) actually outside of the VM “screen”, hence it will not focus the VM, and without focus clicking on F2 does nothing. The other alternative (to ensure that VM enters its virtual BIOS settings) is to add a statement:

bios.forceSetupOnce = “TRUE”

.. in the .vmx file.

Once in VM BIOS settings I changed the boot order so that the CD/DVD drive is now the first boot device. I then popped the Parted Magic CD in the drive and rebooted the VM. With Parted Magic up and running I started Partition Editor (GParted), and moved the 1.4Gb linux-swap partition to the end of the newly expanded 20Gb disk space. Next I expanded the third partition (“/home”) to total of 6.8Gb, and moved it also to the right, back to back with the swap partition. Finally I gave the root partition (“/”) the rest of the free space giving it total size of 11.7Gb. Once the operations had been applied (requested changes written to the disk) I exited GParted and shut down Parted Magic choosing “reboot system” on exit.

Once the CentOS finished boothing, I checked the partition sizes with ‘df -h’ to confirm that root and home partitions reflect the extra space assigned to them. You might also want to restore the hard drive as the primary boot device for the VM in the VM BIOS settings so that a CD/DVD you might later forget in the CD/DVD drive won’t try to boot instead of the VM.