The SMF manifest:

<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
<service_bundle type='manifest' name='export'>
  <service name='application/monitoring/nrpe' type='service' version='0'>
    <single_instance/>
    <dependency name='fs-local' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/system/filesystem/local'/>
    </dependency>
    <dependency name='network-service' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/network/service'/>
    </dependency>
    <dependency name='name-service' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/milestone/name-services'/>
    </dependency>
    <instance name='default' enabled='true'>
      <dependency name='config-file' grouping='require_all' restart_on='refresh' type='path'>
        <service_fmri value='file://localhost/usr/local/etc/nrpe/nrpe.cfg'/>
      </dependency>
      <exec_method name='start' type='method' exec='/local/lib/svc/method/nrpectl start' timeout_seconds='30'>
        <method_context working_directory='/var/tmp'>
          <method_credential user='nrpe' group='nrpe' privileges='basic,sys_resource,!proc_info,!file_link_any' limit_privileges='basic,sys_resource,!proc_info,!file_link_any'/>
        </method_context>
      </exec_method>
      <exec_method name='stop' type='method' exec=':kill' timeout_seconds='60'/>
      <exec_method name='refresh' type='method' exec='/local/lib/svc/method/nrpectl refresh' timeout_seconds='60'/>
      <property_group name='nrpectl' type='application'>
        <propval name='NRPE_CFG' type='astring' value='/usr/local/etc/nrpe/nrpe.cfg'/>
        <propval name='NRPE_FQB' type='astring' value='/usr/local/sbin/nrpe'/>
      </property_group>
    </instance>
    <template>
      <common_name>
        <loctext xml:lang='C'>NRPE</loctext>
      </common_name>
      <documentation>
        <doc_link name='nagios.org' uri='http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf'/>
      </documentation>
    </template>
  </service>
</service_bundle>

The associated method:

#!/bin/sh

. /lib/svc/share/smf_include.sh

NRPE_FQB=`svcprop -p nrpectl/NRPE_FQB $SMF_FMRI`
NRPE_BIN=`basename $NRPE_FQB`
NRPE_CFG=`svcprop -p nrpectl/NRPE_CFG $SMF_FMRI`

pid=`pgrep -x -d " " $NRPE_BIN`

case $1 in
   'start')   if [ -z "$pid" ]; then
                 smf_clear_env
                 $NRPE_FQB -c $NRPE_CFG -d >&2
                 if pgrep -x -d " " $NRPE_BIN >/dev/null 2>&1; then
                    :
                 else
                    echo "NRPE failed to start" >&2
                    exit $SMF_EXIT_ERR_FATAL
                 fi
              else
                 echo "NRPE already running (pid=$pid)" >&2
                 exit $SMF_EXIT_ERR_OTHER
              fi
              ;;
   'refresh') if [ -z "$pid" ]; then
                 echo "NRPE not running; nothing to refresh" >&2
                 exit $SMF_EXIT_ERR_OTHER
              else
                 pkill -x $NRPE_BIN
              fi
              ;;
esac
exit $SMF_EXIT_OK

Season to taste.

It turns out that this is normal behavior, as the system unmounts all external volumes when a user logs out, including TimeMachine volumes (this does not apply to network volumes, just volumes physically attached to the system). There are some edge cases that affect somewhat this behavior (such us when FileVault is in use), but it can be completely disabled:

defaults write /Library/Preferences/SystemConfiguration/autodiskmount \
     AutomountDisksWithoutUserLogin -bool true

I went ahead and rebooted the system. TimeMachine now works even when users are not logged in.

A few months ago the aging Early 2009 Mac Mini in the living room was replaced with a 2010 model. The old one was having a hard time keeping up with HD content (mainly in terms of performance but also flat out refusing to display iTunes HD content after the upgrade to Snow Leopard) and the 1080p display over the DVI to HDMI adapter over-scanning issues were rather tiresome. The 2010 model did away with all that: faster CPU, more memory and native HDMI took care of those issues, which left a perfectly functional Macmini3,1 searching for a mission in life, a mission I had found even before I pulled the trigger on the new model.

Thus, the mission is defined: the Mac Mini needs to take over the services that run continuously so the other system can be powered off at will.

The migration is nearly complete: mail is flowing and the software repository is up to date. The wiki bits are still a work in progress, but those are not as critical, primarily because Evernote has largely replaced (and enhanced) the wiki use. None of this would have been possible without the MacPorts Project community, at least not as fast and seamlessly as it has been. So there is happiness in the living room and there is happiness in the office.

Our first entry in this regard, at pierre‘s suggestion, is a Nagios plugin for Tableau servers, check_tableau_systeminfo, which is currently a little rough around the edges but quite usable. There is a new version right around the corner with some polish applied to said edges, and we are preparing a host of other tools for release that we currently use every day in our production environment.

Our production environment is currently comprised of 2000+ nodes, which makes it a relatively large environment that provides a fair amount of interesting operational problems to solve. And problems solvers is something we are actively looking for, i.e., we are hiring! Ning is the largest platform in the world for creating custom social networks, currently hosting 70,000 paid subscribers (up from 15,000 before we transitioned from the prior “freemium” model), and serving over 80 million unique visitors monthly. This makes us one of the top 100 sites in the US, and, according to CNBC.com, one cool company to work for (indeed!).

Check out the openings, check out the code, and come play in our playground.

defaults write com.apple.NetworkBrowser EnableODiskBrowsing -bool true
defaults write com.apple.NetworkBrowser ODSSupported -bool true

Context: we have an older MacBook with what appears to be a busted DVD-ROM drive, preventing a clean install of the newly arrived cat. After enabling CD/DVD Sharing on the “server”, nothing would show up on the “client”. After tweaking the above properties and restarting the Finder, it’s all good now. Install in progress.

In prior lives, Nagios has been one of the primary fault monitoring systems in use. It has a relatively long history as the monitoring workhorse in a large number of production environments, and with reason: high quality, open source, and free has meant easy adoption, especially in cash-conscious startups. It compiles on essentially all contemporary Unix-based platforms, and there is a significant knowledge base on and off the Intertron. It gets the job done. Add some good design to its configuration files and its management tools, and it’s top-notch. Minus, of course, its archaic web-based GUI. Details, details, details. Hyperic HQ is one of the monitoring tools I have been involved with most recently. Installation is relatively painless on both on the server and the client (and admittedly faster than that of getting Nagios up and running), it is pretty, sporting a modern, somewhat configurable interface, and offering features like autodiscovery out of the box.

A notable section in the Hyperic documentation is related to Nagios (Nagios Data), and the Hyperic HQ Tour also offers some comparative notes (PDF, page 5: “Hyperic HQ Compared to Nagios”). This is no coincidence: Nagios boasts a large installed base, and that makes it a tasty target to aim for (a seach for “Zenoss”, for instance, yields no results). The comparison is, by all accounts, fair. There is nothing misleading or dishonest in it, and Hyperic HQ is indeed superior to Nagios in many respects (particularly in terms of presentation). There are some points, however, where I am not quite synched up with the Hyperic story, but these are generally small (but by no means insignificant) details. For instance, I’m quite happy to have configuration data stored in plain text files when its complexity does not merit a RDBMS.

The one significant sticky point (which is not mentioned in the tour but that is prominently highlighted in the documentation) is the apparent lack of any passive-like monitoring in Hyperic (no NSCA or NCSA-like support). Personally, I am a big fan of passive monitoring: components perform self-monitoring duties and report back to central command as necessary. I have used it quite successfully to monitor scripts that run periodically and are unpokeable (think all those wonderful tools you’ve written that ship logs back and forth), NetApp filers (by proxy), and almost any kind of custom software. Nagios documentation does not do true justice to passive monitoring: it is mostly described as a way to build distributed monitoring or reach components behind firewalls. And yet, it is an incredibly elegant methodology to monitor components and to do so from within the components themselves asynchronously; by definition, it is highly distributed, making each component (or proxies on their behalf) responsible for its own health, and yielding Nagios a great alert, escalation and notification manager. Add powerful inheritance and the resulting monitoring setup is scalable, efficient, and straightforward to automate. It is still (no point in hiding it) ugly, but hard to beat.

While Hyperic HQ has a home for performance monitoring, my money is still on Nagios for fault monitoring. I will be learning a lot more about Hyperic HQ over the next few weeks, so I will likely have more details to report in future posts (I am seriously exploring what it would take to feed passive test results to Hyperic so they can be available in the Hyperic dashboard, for instance). Stay tuned.

Very sweet indeed.