« CrashPlan Pro Server restore metrics, estimates | Main | AFP stops logging after indicated period »

Server Monitor.app stupidity

This confounded me until it I sorted it out. Once done so, it made sense, but it doesn't help that, in this case, the user interface is unhelpful and unintuitive, and the behavior is different than other configurations for similar machines. (Note: I haven't regressively seen is this is the case pre-Mac OS X Server 10.5.7 Update or pre-Server Admin Tools 10.5.7.)

On this Xserve (Late 2006), Server Monitor.app on the local machine has the LOM feature configured for Network 1 (which corresponds to en0 aka the port labeled Ethernet 1 on the machine and by default the Network preference pane). This LOM interface has its own MAC address distinct from the physical port. I've registered this address for convenience's sake.

To configure this server for monitoring, launch Server Monitor --> Server --> Configure Local Machine. Give it an IP (again, distinct from the physical Ethernet ports), give it a username and password. This is the only step that's the same on this and the Xserve (Early 2008) model.

Here's where it gets unintuitive.

If you want to add the server in Server Monitor application on the server itself, you'd think you could enter the IP associated with the LOM address you just entered in the step above. That will likely fail with "can't connect to server". Instead, you need to enter the loopback address, And instead of entering the username and password entered a moment ago, you need to enter any old administrator's username and password instead. Any member in the local admin group, including those added from external directories, will suffice.

You'll know if you did this incorrectly if you see a CANNOT_LOAD_ BUNDLE_ERR or "Software is not installed proper on server" message.

However, if you want to configure Server Monitor on a different, remote machine, the process is different, even though the user interface is the same. Here, you will need to enter the LOM-specific address and enter the LOM-specific username and password.

I suppose this makes some sense, but the consequence means you have to disclose this LOM username and password to others if you want to delegate monitoring; you can't just add that person to the server's local admin account and call it a day.

And unfortunately, there are no SACLs for this privilege, which would be most welcome. Perhaps allowing one group to monitor while another, more privileged group can shutdown or startup the server and configure the email notifications.

Over on this Xserve (Early 2008) model, the process is different, though the user interface is the same. Here, there is still a discrete LOM-associated MAC address; and you still give it a different IP address than the built-in Ethernet port(s). However when you configure Server Monitor.app on the server itself, it's done oppositely as the example above — do this the same way as you would from a remote monitoring machine. You use the LOM-specific FQDN or IP, and the LOM username and password, not a local admin account. The remote monitoring machine is done the same way.


TrackBack URL for this entry:

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


This page contains a single entry from the blog posted on June 5, 2009 10:56 AM.

The previous post in this blog was CrashPlan Pro Server restore metrics, estimates.

The next post in this blog is AFP stops logging after indicated period.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.
Traffic analyzed by Google Analytics. Site powered by Movable Type 4.32-en