An easy way to list the installed ports in FreeBSD in chronological order (most recent first):
ls -latT /var/db/pkg | less
An easy way to list the installed ports in FreeBSD in chronological order (most recent first):
ls -latT /var/db/pkg | less
I’ve updated the NFS automount script that provides “self-healing” NFS mounts. The script now allows a mount to be defined as read-write or read-only, and then subsequently monitors that the share is mounted as R/W or R/O (of course, it can’t mount a share that has been shared as R/O as R/W). Both Linux (tested on CentOS 6.1) and FreeBSD versions are provided.
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
Couple of years ago I wrote about the initial troubles with Fusemail service not long after having switched to it. The grade for the service level during last couple of years is “fair” – the service is usable, and has many good features, but its stability is not stellar. For this reason it is in my plans to move the email service out of Fusemail.. but where to?
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.
I needed to reinstall dev ESXi 4.1. The system has LSI (AMCC, 3Ware..) 9650SE on it, and after a fresh ESXi install the array was nowhere to be found. Oh yes, the drivers are not part of the ESXi installation package (it had been a while since I did the initial install..)! A quick tour around the web quickly produced the patch command:
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!
Last summer I posted a script that would repeatedly (via cron) check on a availability and status of a NFS mount, and attempt to keep it mounted if possible. That script was written for (Free)BSD. Below is a slightly modified version that runs on Linux (in this case, CentOS).
#!/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