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

First (the reason for the reinstall), if there is plenty of hard drive space available, it’s good idea not to deplete it all for the sytem installations. I split a 1.3Tb RAID 5 array between the two operating systems until I realized that 1) you can’t shrink vmfs partitions and 2) by consuming all hard drive space one limits the flexibility of the system down the line. Let’s say you want to install a newer version of an operating system and decide to do a fresh install. You need space for it while you want to keep the old version around at least long enough to migrate settings and data over.

Second, while I was aware of that ESXi doesn’t offer console access beyond the “yellow and grey” terminal, I didn’t realize you have no access to the VM consoles, either. So, with CentOS or FreeBSD installed, the only way to access their consoles is via the vSphere client (someone correct me if I’m wrong — I wish I were as I’d like to have local console access to the guest OS’es).

Finally, VMware Go “doesn’t currently support ESXi servers with multiple datastores”. So if you have, say, a 3ware/LSI/AMCC RAID controller which isn’t currently supported under ESXi as a boot device but which you likely still want to use as a datastore, you’ll end up with at least two datastores. So vSphere is really the only way to go for VM management also for this reason (since LSI provides a vmware-specific driver, one may also be able to direct-connect the LSI RAID array to the VM without it being an ESXi datastore, but that’s not the configuration I’m looking for—the boot device is small and houses just ESXi while the VMs and their associated datastores are located on the array).

In the end everything’s working quite well. I like the flexibility virtualization offers.. and consolidation is useful even in a small environment (one dev machine is less than two or three dev machines ).

From time to time – usually when I’ve been getting ready to upgrade to the next major revision of FreeBSD – I’ve taken some time to research what the current pros and cons are for FreeBSD vs. some Linux distro. Always, in the end, FreeBSD has won. However, a development project I’m starting to work on will utilize Zend Server, which is only supported on handful of common Linux distros and on Windows (which is, by default, not an option as I strongly maintain that Windows is not suitable as a web server platform). There is, of course, Linux compatibility layer in FreeBSD, but as Zend doesn’t currently support it as a platform for Zend Server, I wouldn’t feel comfortable using it in a production environment.

So even though I find FreeBSD superior to Linux in many ways, I’ve now spent some time getting acquainted with Linux. I first started with Red Hat, then moved to CentOS which is the Linux distribution I’m currently testing. Now it’s not bad, per se, but I frequently come back to the thought: “Why would someone, anyone prefer THIS over a BSD system?!” The package management with yum, rpm, and the GUI overlays is easy enough, but it’s chaotic! Having to enable and disable repos, set their priorities, etc. seems unnecessarily complicated. On the FreeBSD side there is the ports collection which provides most of the software that one can imagine ever needing. The odd few items that either aren’t available in ports, or whose configuration is somehow not complete enough through ports can be easily compiled from the source tarball. Everything’s quite easy to keep track of, and to duplicate if one’s building a new system.

I’m sure some of this feeling stems from the fact that I have been using a BSD system for so long, and from the fact that I probably don’t yet know Linux well enough (say, to build the system from a scratch..). But as far as I can tell, package management is done with yum and rpm (on CentOS, say), by adjusting repository priorities, and enabling/disabling repositories. That is messy!

Well, I now have a functional development server running Zend Server with Apache, Subversion, and MySQL, and as the vendor (Zend) dictates the rules, I must continue development on Linux. Perhaps in six months time I’ll have more favorable comments about it as compared to FreeBSD… but I sort of doubt it. My guess is I’ll just learn to live with it, every now and then wistfully glancing to the direction of the BSD server.

ifconfig | grep “0xffffffff” | awk ‘{ print $2 }’ | xargs -n 1 ifconfig em0 delete

For this to work, the netmasks of the aliases and the master IP for the inteface must differ. The netmasks of the aliases are usually set to 255.255.255.255 (hence “0xffffffff”) while the netmask of the master IP is usually something different, specific to your network, e.g. 255.255.255.128 (“0xffffff80″).

Once the above command has been run, /etc/netstart can then be executed to load the remaining or reconfigured aliases (if any) from /etc/rc.conf.

Here’s my version of the script. While it bears some resemblance to Vivek’s script, it is largely rewritten. Read the script header for more information.

NOTE! In his comment James pointed out a possible bug in the script. The displayed script indeed had a problem: it was missing a backslash in front of the first dollar sign at:

eval “local fspath=\$${fsname}path”

This was caused by the script display plugin in WordPress that treated the backslash as an escape character (this has now been fixed). To be on the safe side, please download the script as a tarball. To further validate the integrity of the tarball, it should produce a md5 hash of 732ac44f11ba4484be4568e84929bb6a.

#!/bin/sh

# Autodump 1.5a (released 01 August 2009)
# Copyright (c) 2009 Ville Walveranta
#
# A FreeBSD shell script to dump filesystems with full, and automatically
# incremented incremental backups to a given directory location; this script
# was written with the intent of saving the filesystem dumps not onto a tape
# device but on another hard drive such as a different filesystem on the same
# computer. The resulting dump files can be copied offsite with a separate
# cron job.
#
# This script creates the necessary directory structure below the defined
# 'BASEDIR' as well as the necessary log file. This script also ensures that
# the level 0 dump exists before creating an incremental dump; if it doesn't
# the script automatically erases the incremental files for the current week
# (if any exist) and starts over with a level 0 dump. This way you can start
# using the script on any day of the week and level 0 dump is automatically
# created on the first run.
#
# When ran daily (such as from a cron job), the script creates level 0 dump
# on every Monday (beginning the ISO week), or Sunday (beginning of the U.S.
# week) and an incremental dump on all the other days of each week. The dumps
# are compressed with gzip and saved below the 'BASEDIR' to an automatically
# created directory whose name is derived from the list given in 'FSNAMES'.
# Each week's dumps are organized into subfolders with name YYYY-WW ('WW'
# being the current week). By default three most recent weekly dumps
# (level 0 + incrementals) are retained.
#
# The script maintains each weekly folder's date at the _beginning_ date
# of the dump (i.e. Monday or Sunday of the current week) at 00:00, not
# at the most recent incremental's date/time.
#
# By default the root (/) and usr (/usr) filesystems are dumped. To add more
# add a "friendly name" to the 'FSNAMES' list (it is used for the weekly folder
# names, for dump filenames, and to reference the corresponding mount point
# variable); then add the corresponding mount point variable (i.e. if you
# add "var" to 'FSNAMES', then add a variable varpath=/var). The "path"
# ending of the mount point variable name is required.
#
# Since the number of incremental dumps is limited to nine (level 0 +
# incremental levels 1-9), the script will allow maximum of one dump
# to be created per day. However, since the level incrementing is dynamic
# you can start the script on any day of the week, and run it on any
# number of days during the rest of the week and you'll always get
# level 0 plus the incremental dumps in sequential order. However, The
# new weekly folder is always created on Monday or Sunday (as chosen by
# you). Note that the script determines whether "today's" dump exists
# based on the modification date stamp of the most recent dump. Hence
# it is a good idea to run this script in the early hours of each day
# rather than in the very end of each day. Running the script, for
# example, at 23:50 has the potential to push longer dump processes
# over the midnight and so potentially cause the next day's dump to
# be skipped.
#
# Written for FreeBSD 7.2 but should work on most BSD and *NIX systems with
# minor modifications.
# -------------------------------------------------------------------------
# Copyright (c) 2009 Ville Walveranta
# <http://my.galagzee.com/2009/07/17/freebsd-dump-filesystem-shell-script>
# This script is licensed under GNU GPL version 2.0 or above, and is provided
# 'as-is' with no warranty which is to say that I'm not liable if it wipes out
# your hard drive clean or doesn't back up your precious data. However, to the
# best or my knowledge it is working as expected -- I'm using it myself. 
# -------------------------------------------------------------------------
# This script was inspired by
# FreeBSD Full / Incremental Tape Backup Shell Script
# by nixCraft project / Vivek Gite
# at <http://bash.cyberciti.biz/backup/freebsd-dump-filesystem-shell-script/>
# -------------------------------------------------------------------------

#### GLOBAL VARIABLES ###############################################

WEEKSTARTS=Mon      # Accepted values are "Mon" (ISO standard) or "Sun" (U.S.)
KEEPDUMPS=30        # in days; this is evaluated on the weekly level per start
                    # of the week, so '30' keeps 3-4 weekly dumps
BASEDIR=/bak/dumps
GLOBALDUMPOPTS=Lua  # add 'n' for wall notifications
LOGFILE=/var/log/dump.log

# to add more filesystems to be dumped add the dump name in 'FSNAMES'
# and add the corresponding mount point variable (dumpname+path=mountpoint)
FSNAMES="root usr"  # this is used for dump directory name
                    # and to ID the path from a variable below
rootpath=/
usrpath=/usr

#####################################################################

DUMP=/sbin/dump
GZIP=/usr/bin/gzip
LOGGER=/usr/bin/logger

WEEKDAY=$(date +"%a")
DATE=$(date +"%Y%m%d")
HUMANDATE=$(date +"%d-%b-%Y")
HUMANDATE=`echo $HUMANDATE | tr '[:lower:]' '[:upper:]'`
HUMANTIME=$(date +"%H:%M (%Z)")
TODAYYR=$(date +"%Y")
TODAYMO=$(date +"%m")
TODAYDT=$(date +"%d")

# datestamp at midnight today
TODAYSTARTSTAMP=$(date -j +%s "${TODAYYR}${TODAYMO}${TODAYDT}0000")

# default lastdump to midnight today; it will be checked
# and and adjusted later
LASTDUMP=$TODAYSTARTSTAMP

# do not crete world-readable dumps!
umask 117

# make sure the logfile exists
if [ ! -e $LOGFILE ] ; then
   touch $LOGFILE
   chmod 660 $LOGFILE
fi

# make sure that entire week's incremental dumps are deposted
# in the same directory, even when a week spans new year
# NOTE: When the ending year has a partial 53rd week, there
# won't be a dump folder for the first week of the new year.
# The incremental dumps instead complete the 53rd week folder,
# even when the 1st week of the new year begins mid-week.
# However, the dates of the incremental dump files in the
# 53rd week folder correctly reflect the dates of the
# beginning year.
adjust_date(){
   local dateoffset=$1
   local epochnow=$(date +%s)
   local offsetsecs=`expr $dateoffset "*" 86400`
   local newepoch=`expr $epochnow "-" $offsetsecs`
   local year=`date -r $newepoch +"%Y"`

   if [ "$WEEKSTARTS" = "Mon" ] ; then
      local week=`date -r $newepoch +"%W"`
   else
      local week=`date -r $newepoch +"%U"`
   fi
   NEWEPOCHISO=`date -r $newepoch +"%Y%m%d0000"`

   #system week starts from `0', there is no calendar week `0'
   week=`expr $week "+" 1`
   YWEEK=${year}-${week}
}

# determines the 'distance' from the level 0 dump in days
if [ "$WEEKSTARTS" = "Mon" ] ; then
   case $WEEKDAY in
      Mon) adjust_date 0;;
      Tue) adjust_date 1;;
      Wed) adjust_date 2;;
      Thu) adjust_date 3;;
      Fri) adjust_date 4;;
      Sat) adjust_date 5;;
      Sun) adjust_date 6;;
      *) ;;
   esac
else
   case $WEEKDAY in
      Sun) adjust_date 0;;
      Mon) adjust_date 1;;
      Tue) adjust_date 2;;
      Wed) adjust_date 3;;
      Thu) adjust_date 4;;
      Fri) adjust_date 5;;
      Sat) adjust_date 6;;
      *) ;;
   esac
fi

mk_auto_dump(){

   local fsname=$1

   # get the current filesystem's path
   # as defined in the corresponding variable
   eval "local fspath=\$${fsname}path"

   # composite the dump path
   local dumppath=${BASEDIR}/${fsname}/${YWEEK}

   # make sure the dump directory for this week exists;
   # this automatically creates a new dump directory on
   # every Monday or Sunday (as selected by 'WEEKSTARTS')
   [ ! -d $dumppath ] && mkdir -p $dumppath

   # get name of the last file in the current dump directory
   local lastfile=`ls -ltr $dumppath | grep -v "^d" | tail -n 1 | awk '{ print $9 }'`

   # assume that the 'lastfile', if it exists, was not created today
   local dumped_today=false

   # if a file exists, check its modification date;
   # if it is at or after 00:00 today, set a flag to skip the dump
   if [ "$lastfile" != "" ] ; then
      local fq_lastfile=${dumppath}/$lastfile
      if [ -e $fq_lastfile ] ; then
         # get the last modification time for the most recently created dumpfile
         LASTDUMP=`stat -f %m $fq_lastfile`
         if [ $LASTDUMP -ge $TODAYSTARTSTAMP ] ; then
            local dumped_today=true
         fi
      fi

      # get the first and the last dump level for this directory
      local levelcommand="ls $dumppath | sed -e 's/^[[:digit:]]*\_//' | sed -e 's/\..*$//'"
      local firstlevel=`eval $levelcommand | head -n 1`
      local lastlevel=`eval $levelcommand | tail -n 1`

      # make sure level zero dump exists;
      # if it doesn't, start over
      if [ "$firstlevel" != "0" ] ; then
         # it doesn't matter if a previous dump exists from today
         # since we're starting over as level 0 dump is missing
         local dumped_today=false
         local dumplevel=0
         rm -f $dumppath/*.gz
      else
         # otherwise just increment the dump level
         # for levels 1-6, i.e. normally Tuesday thru Sunday
         local dumplevel=`expr $lastlevel "+" 1`
      fi
   else
      # no dump exists in this week's folder; reset level to '0'
      local dumplevel=0
   fi

   # skip the entire dump process if a dumpfile has
   # already been created for this filesystem today
   if [ "$dumped_today" = "false" ] ; then  

      # define the dump filename
      local dumpfn=${DATE}_${dumplevel}

      echo ---------------- >> $LOGFILE
      echo >> $LOGFILE
      echo BEGINNING LEVEL $dumplevel DUMP OF \'$fsname\' \(${fspath}\) FILESYSTEM ON $HUMANDATE AT $HUMANTIME >> $LOGFILE
      echo >> $LOGFILE
      echo Creating a snapshot of \'$fspath\'.. >> $LOGFILE
      # execute the dump
      $DUMP -$dumplevel -$GLOBALDUMPOPTS -f ${dumppath}/${dumpfn} $fspath >> $LOGFILE 2>&1
      local dumpresult=$?

      if [ "$dumpresult" != "0" ] ; then
         # log the dump result to syslog
         $LOGGER "$DUMP LEVEL $dumplevel DUMP OF $fsname (${fspath}) FAILED!"

         echo "*** DUMP FAILED - LEVEL $dumplevel DUMP of $fsname (${fspath}) ***" >> $LOGFILE
         echo >> $LOGFILE
      else
         # log the dump result to syslog
         $LOGGER "LEVEL $dumplevel DUMP of $fsname (${fspath}) COMPLETED SUCCESSFULLY!"

         echo >> $LOGFILE
         # compress the dump
         echo Compressing the dumpfile \'${dumpfn}\'.. >> $LOGFILE
         $GZIP -v ${dumppath}/${dumpfn} >> $LOGFILE 2>&1
         echo DONE >> $LOGFILE
         echo >> $LOGFILE

         # make sure dumps are not world readable (security risk!)
         echo Updating dumpfile \'${dumpfn}.gz\' permissions.. >> $LOGFILE
         chmod -v -v 440 ${dumppath}/${dumpfn}.gz >> $LOGFILE 2>&1
         echo DONE >> $LOGFILE
         echo >> $LOGFILE

         # reset current dump dir's timestamp to that of the level 0 dump
         touch -t ${NEWEPOCHISO} ${dumppath}

         # delete old dumps
         echo Deleting old \'$fsname\' dumpfiles.. >> $LOGFILE
         find $BASEDIR/$fsname -mtime +$KEEPDUMPS -maxdepth 1 -print -exec rm -rf {} \; >> $LOGFILE 2>&1
         echo DONE >> $LOGFILE
         echo >> $LOGFILE
      fi
   else
      local lastdump_readable=`date -j -r $LASTDUMP +"%H:%M"`
      local lastdump_readableZ=`date -j -r $LASTDUMP +"%Z"`
      local lastdumpmsg="Autodump for filesystem '$fsname' ($fspath) has already been executed today at $lastdump_readable ($lastdump_readableZ)."
      echo $lastdumpmsg
      $LOGGER $lastdumpmsg
   fi
}

# Dump filesystems defined in 'FSNAMES'
#
# Monday or Sunday (as selected by 'WEEKSTARTS') starts with
# the level 0 dump, with incrementals created through the rest of
# the week (autoincremented). If the level 0 dump is missing in
# the current week's folder for filesystem currently being backed
# up, it is created automatically instead of an incremental dump,
# no matter what day of the week it is.
for f in $FSNAMES
do
   mk_auto_dump $f
done

Here’re couple of useful sites for those wondering which OS to choose:

Polishlinux.org – Compare distros: FreeBSD vs. Debian – Comparison data is up to date and there are a lot of good user comments to sift through. You can also choose other distros to compare to.

Wikipedia – Comparison of BSD operating systems

And lastly, a good example of why the sheer number of Linux distros is disorienting: DistroWatch lists at least a few hundred Linux distros (plus couple of BSD derivatives).

This is bcron, a new cron system designed with secure operations in mind. To do this, the system is divided into several seperate programs, each responsible for a seperate task, with strictly controlled communications between them. The user interface is a drop-in replacement for similar systems (such as vixie-cron), but the internals differ greatly.

As of writing of this bcron can not be found in the FreeBSD 7.0 ports system. Fortunately its installation is fairly straightforward.  Yet the included documentation is rather spartan so I provide a more complete outline below.

1. Install latest bglibs if not yet installed** bglibs is best to install from a downloaded tarball rather than from the ports (while the ports version installs the libs in a more logical location at /usr/local/lib/bglibs/ the programs that utilize the library (bcron, ucspi-unix, etc.) have difficulty locating it.

   ** few symlinks are required (these refer to the locations bglibs installs itself when compiled from the tarball rather than from the ports):

   /usr/local/bglibs -> /usr/local/lib/bglibs
   /usr/local/bglibs/lib/libbg-sysdeps.so.2 -> /usr/local/lib/libbg-sysdeps.so.2
   /usr/local/bglibs/lib/libbg.so.2 -> /usr/local/lib/libbg.so.2

2. Install ucspi-unix if not yet installed as bcron components communicate via UNIX sockets. This requires bglibs and also compiles and installs well using a downloaded tarball (it’s also available in ports at /usr/ports/sysutils/ucspi-unix, but I prefer to compile it from the downloaded tarball).
3. Make sure /var has been moved off the root to /usr/var before proceeding. See an older post for details.
4. Make sure daemontools (and hence supervise) has been installed and is operational as bcron will be started with it.
5. Create a system user “cron” (for example by using vipw command) and group “cron” (by editing /etc/group). This user/group will own all the crontab files (though not /etc/crontab as it’s system crontab and needs to be owned by root:wheel).
   
   user:
   cron:*:50:50::0:0:BCron Sandbox:/nonexistent:/usr/sbin/nologin

   group:
   cron:*:50:

6. Create the spool & tmp directories:
   mkdir -p /var/spool/cron/crontabs /var/spool/cron/tmp
   mkfifo /var/spool/cron/trigger
   sh
   for i in crontabs tmp trigger; do
   chown cron:cron /var/spool/cron/$i
   chmod go-rwx /var/spool/cron/$i
   done
7. Create the configuration directory /usr/local/etc/bcron:mkdir -p /usr/local/etc/bcron** You can put any common configuration settings into this directory (it is an “ENVDIR”), like alternate spool directories in BCRON_SPOOL.
8. Create the bcron service directories (there are three services) and add the scripts below it:

   mkdir -p /var/bcron/supervise/bcron-sched/log
   mkdir /var/bcron/supervise/bcron-spool
   mkdir /var/bcron/supervise/bcron-update

   Set their permissions to 1750 for security purposes (no world access, sticky bit):

   chmod 1750 /var/bcron/supervise/bcron-sched
   chmod 1750 /var/bcron/supervise/bcron-spool
   chmod 1750 /var/bcron/supervise/bcron-update

   Make all the run and log/run scripts executable by root, readable by group:

   chmod 740 /var/bcron/supervise/bcron-sched/run
   chmod 740 /var/bcron/supervise/bcron-sched/log/run
   chmod 740 /var/bcron/supervise/bcron-spool/run
   chmod 740 /var/bcron/supervise/bcron-update/run

   and make log bcron-sched subdir accessible by root, group:

   chmod 750 /var/bcron/supervise/bcron-sched/log

   RUN SCRIPTS:
   /var/bcron/supervise/bcron-sched/run:

   #!/bin/sh
   exec 2>&1
   exec envdir /usr/local/etc/bcron bcron-start | multilog t /var/log/bcron

   /var/bcron/supervise/bcron-sched/log/run:

   #!/bin/sh
   exec >/dev/null 2>&1
   exec \
   multilog t /var/log/bcron

   /var/bcron/supervise/bcron-spool/run:

   #!/bin/sh
   exec >/dev/null 2>&1
   exec \
   envdir /usr/local/etc/bcron \
   envuidgid cron \
   sh -c ‘
   exec \
   unixserver -U ${BCRON_SOCKET:-/var/run/bcron-spool} \
   bcron-spool
   ‘

   /var/bcron/supervise/bcron-update/run:

   #!/bin/sh
   exec >/dev/null 2>&1
   exec \
   bcron-update /etc/crontab

9. Kill the deafult cron daemon and add the following to rc.conf so it won’t restart on reboot:

   #disable default cron; bcron is used instead (started by supervise)
   cron_enable=”NO”

10. Symlink bcron services’ primary supervise directories to under /var/service to start bcron services (you can also use svc-add command if you have installed supervise-scripts):
    ln -s /var/bcron/supervise/bcron-sched /var/service/bcron-sched
    ln -s /var/bcron/supervise/bcron-spool /var/service/bcron-spool
    ln -s /var/bcron/supervise/bcron-update /var/service/bcron-update
11. Set /etc/crontab permissions to 600, and make sure it’s owned by the root.
    chmod 600 /etc/crontab
    chown root:wheel /etc/crontab

    ** For other users the owner of the crontab file in their respective home folders would be cron:cron.

12. Edit /etc/crontab and test that it gets updated. Note that there is a brief delay, perhaps one minute or so, after you save the crontab until the change becomes effective. Also note that the default shell for the crontab is /bin/sh. You might want to change it to something more powerful like c-shell (/bin/csh) or bash (/bin/bash) that you’re familiar with. You may also want to augment the default path, for example, by including /usr/local/bin for user-installed commands.

Below is a simple procedure to move the /var to /usr/var and /tmp to /usr/var/tmp. This is best to do early on in a new system installation since many services tend to hook into /tmp and/or /var, and may thus lock files in those directories making the move more difficult. If you’re making this move on an established system, at least stop all the services that might interfere with the process (such as database services). It might even be a good idea to boot into a single user mode (if you do so, remember to correctly mount your disks before proceeding). I usually do this early in a new system install, before installing any major services, or at least before scripting them to run.

1. Move /var to /usr/var
   
mkdir /usr/var
cd /var
tar cvf - . | (cd /usr/var; tar xvf - )
cd /
chflags -R noschg /var
rm -rf /var
ln -s /usr/var /var

2. Move /tmp to /usr/var/tmp
   
mkdir /usr/var/tmp
cd /tmp
tar cvf - . | (cd /usr/var/tmp; tar xvf - )
cd /
chflags -R noschg /tmp
rm -rf /tmp
ln -s /usr/var/tmp /tmp
chmod -h 777 /tmp
chmod 1777 /usr/var/tmp


#
# INERTIA -- Inertia kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#    http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# Based on
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.2.2.1 2008/02/06 03:24:28 scottl Exp $

ident		INERTIA
machine		i386
cpu		I686_CPU

options		SMP 			# Symmetric MultiProcessor Kernel (`device apic' is also required for multiprocessor use)
options 	SCHED_4BSD		# 4BSD scheduler
options 	PREEMPTION		# Enable kernel thread preemption
options 	INET			# InterNETworking
#options 	INET6			# IPv6 communications protocols
options 	FFS			# Berkeley Fast Filesystem
options 	SOFTUPDATES		# Enable FFS soft updates support
options 	UFS_ACL			# Support for access control lists
options 	UFS_DIRHASH		# Improve performance on big dirs
options 	CD9660			# ISO 9660 Filesystem
options 	PROCFS			# Process filesystem (requires PSEUDOFS)
options 	PSEUDOFS		# Pseudo-filesystem framework
options		MSDOSFS			# MSDOS filesystem support (for floppies)
options 	COMPAT_43		# Compatible with BSD 4.3 (required)
options 	COMPAT_FREEBSD4		# Compatible with FreeBSD4
options 	COMPAT_FREEBSD5		# Compatible with FreeBSD5
options 	COMPAT_FREEBSD6		# Compatible with FreeBSD6
options 	SCSI_DELAY=15000	# Delay (in ms) before probing SCSI (TWA/TWE issue)
options 	KTRACE			# ktrace(1) support
options 	SYSVSHM			# SYSV-style shared memory
options 	SYSVMSG			# SYSV-style message queues
options 	SYSVSEM			# SYSV-style semaphores
options 	_KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
options 	KBD_INSTALL_CDEV	# install a CDEV entry in /dev, may be needed to hot-plug USB keyboards
options 	AHC_REG_PRETTY_PRINT	# Print register bitfields in debug output
options 	AHD_REG_PRETTY_PRINT	# Print register bitfields in debug output
options 	ADAPTIVE_GIANT		# Giant mutex is adaptive
options		ACCEPT_FILTER_HTTP	# Must be here or AcceptFilter won't work w/Apache2
options		SC_DISABLE_REBOOT	# Disable Ctrl-Alt-Del reboot (this is a server)

device		apic			# I/O APIC (required)
device		npx   			# The Numeric Processing eXtension driver (required)

device		pci
device		isa			# Required by npx

device		fdc			# Floppy drives

device		ata			# ATA and ATAPI devices
device		atadisk			# ATA disk drives
device		ataraid			# ATA RAID drives [OPTION]
device		atapicd			# ATAPI CDROM drives
options 	ATA_STATIC_ID		# Static device numbering

device		scbus			# SCSI bus (required for SCSI, ALSO REQ'D FOR SATA-RAID, USB/umass)
device		da			# Direct Access (disks)
device		pass			# Passthrough device (direct SCSI access)

#device		twe			# 3ware ATA RAID [OPTION]
#device		twa			# 3ware 9000 series PATA/SATA RAID [OPTION]
#options	TWA_DEBUG		# 0-10; 10 prints the most messages; enable for twa debug only

device		atkbdc			# AT keyboard controller
device		atkbd			# AT keyboard
device		kbdmux			# keyboard multiplexer

device		vga			# VGA video card driver
device		sc			# syscons, the default console driver
device		sio			# 8250, 16[45]50 based serial ports

device		ppc			# Parallel port
device		ppbus			# Parallel port bus (required)
device		lpt			# Printer
device		ppi			# Parallel port interface device

#device		miibus			# MII bus support (required by some NICs) [OPTION]
#device		fxp			# Intel EtherExpress PRO/100B (82557, 82558); requires miibus [OPTION]
device		em			# Intel PRO/1000 adapter Gigabit Ethernet Card [OPTION]

options		DEVICE_POLLING		# Imporoves network driver performance

device		coretemp		# On-die temperature sensor on Intel Core and newer CPUs [OPTION]

device		loop			# Network loopback
device		random			# Entropy device
device		ether			# Ethernet support
device		pty			# Pseudo-ttys (telnet etc)
#device		gif			# IPv6 and IPv4 tunneling
#device		faith			# IPv6-to-IPv4 relaying (translation)
device		bpf			# Berkeley packet filter

# USB support [OPTION]
device		uhci			# USB support / UHCI PCI->USB interface
device		ohci			# USB support / OHCI PCI->USB interface
device		ehci			# USB support / EHCI PCI->USB interface (USB 2.0)
device		usb			# USB support / USB Bus (required)
device		ugen			# USB support / Generic
device		uhid			# USB support / "Human Interface Devices"
device		ukbd			# USB support / Keyboard
device		umass			# USB support / Disks/Mass storage - Requires scbus and da

options		COMPAT_LINUX		# Linux compat / Enable Linux ABI emulation
options		COMPAT_AOUT		# Linux compat / Enable i386 a.out binary support
options		LINPROCFS		# Linux compat / Enable procfs support (COMPAT_LINUX / PSEUDOFS)