MOSX username/password login from the icon view

Here's one that's simple - and then you forget, since you don't use it that often -- and then you can never find the sequence for doing it again!

You're at a standard iconic login screen and you want a username/password login instead - from which you can use ">console", ">restart", or log in as a user not otherwise shown.

Press an arrow key; it doesn't matter which. One of the icons highlights - but doesn't bring you to the next screen, where it asks for that user's password.

NOW press Option-Enter - bingo; the username/password login window.

ARD Admin "screen sharing available" - and nothing else

Strange ARD Admin behavior recently; some machines starting showing a status of "Screen sharing available" - and that's it; other functions (ex: "Send UNIX command", "Upgrade Client Software", etc.) do not work.

Probably something to do with the new "Screen Sharing" feature standard on Leopard, though I don't know exactly how.

Deleting that node (all occurrences) in ARD Admin, and then re-adding did not work. Nor did running the latest ARD Client upgrade on the target machine. Nor kickstart, nor...

Then I noticed the same machines worked properly from another machine's ARD Admin, so I started looking at its config on mine. Interesting, though no smoking gun.

So I re-ran the installer for ARD Client 3.2.0 (which is actually 3.2.1) and ARD Admin 3.2.0 - all's well again. And I don't have to rebuild all my carefully-crafted lists of machines - nice!

Xsan 1.4.2

Unfortunately, another vote for sticking with Xsan 1.4.1 - I just downgraded and my Xsan is _much_ happier and much less flaky. Luckily a fairly simple process.

A few random Xsan tips and tricks

• Make absolutely certainly DNS works and is configured properly. Absolutely.
  
  
• Be really careful doing anything that might interrupt the Xsan volumes. Especially if those volumes are shares; that can get ugly, maybe requiring a forced power down. Best policy is to dismount the volumes from all Xsan clients, stop the Xsan volumes, and _then_ do whatever you need.
  
  
• Anything at all; some XSR (Xserve RAID) operations cause _both_ controllers to restart (ex: firmware upgrade) - including the other one, that's part of the Xsan, that you thought wouldn't be affected.
  
  
• When copying files with extended attributes (ex: ACLs or resource forks) to an Xsan volume, the extended attributes are automagically copied to an "AppleDouble Header" file that's named the same as the original file, except with "._" prepended. (Transparent to the user and/or application; slick.) Interestingly, the mod date on the AppleDouble Header file is the date of the copy. Also, if you want to sanity-check the copy, good luck - most tools (ex: diff and cmp) simply ignore the AppleDouble Header file and if you attempt to compare the extended attributes directly, you'll see that their order is not guaranteed, so you must compare attribute-by-attribute.
  
  
• How to decommission a Controller? I don't know, however if you demote it to a Client first, at least the logs won't fill up with messages about how the Controller can't be found. I say "first" because I believe it's necessary to do it while the machine is still live on the Xsan.
  
  
• It's critical for all Controllers to agree - and can be ugly if you perform operations on a Controller that's lost sync with the rest - so sanity-check by adding the following (single line) to the periodic/daily (presuming you read the results, maybe by email) on each:

  if [ -d /Library/Filesystems/Xsan ] ; then echo ""; echo "Xsan status:"; cvadmin -e select | grep -F '>'; fi

  
  
• Do run multiple MDCs; even if you never have an unplanned event, you _will_ have a planned event (ex: software upgrade) that multiple MDCs will render trivial.
  
  
• Check all the docs (PDFs, "ReadMe"s, KB articles, AFP548, Xsanity...) carefully - and consult with someone else before performing anything dramatic. Like, just for the sake of example, "cvfsck -j" and "cvfsck -wv".
  
  
• Sometimes it's the simple stuff that gets you: For example, check _both_ Ethernet interfaces; the one used by the Xsan MDCs and the one used to talk to the rest of the world; just because you can ping out, doesn't mean the Xsan Ethernet cable didn't come loose.
  
  
• Sharing an Xsan volume out? Watch out for the 16TB limit; I believe this applies to SMB as well as AFP; not sure about NFS.
  
  
• Do use hot spares; the performance you lose is rarely missed - though your weekend might be, without them.
  
  
• Do configure the Xsan email warnings; it should be quite infrequent and you will want to know, even if its "just" switching Controllers and none of the users noticed.
  
  
• Same goes for battery backup modules; it's "penny wise, pound foolish" to skip them.
  
  
• No, you can't shrink a volume and re-allocate a LUN; only grow. (BTW: It's possible to grow an XSR LUN - though there's no Apple volume format yet capable of surviving this; you must back up before and restore after.)
  
  
• Yes; you can configure multiple LUNs on a single XSR side. Not optimal, though a reasonable tradeoff for some situations.
  
  
• Just because it's so big, makes it difficult to back up - and, critically, that much more important to back up.
  
  
• Make any modifications using Xsan Admin logged into to the Xsan via the Xsan Ethernet interface of the Primary (active) Controller. Maybe not strictly necessary, but safer.
  
  
• Be aware of the power config; if one XSR is on a UPS that's loaded, and it runs out of power before the MDCs shut down, it'll be ugly. (BTW: Take advantage of the redundant power supplies on the XSRs; plug each into separate UPS units.)
  
  
• Make notes as you go; you never know what you might need later, in a rather frantic time.
  

Leopard keyboard problem (solved?)

Interesting; Now and then, since upgrading the Leopard, the keyboard becomes unresponsive - no reaction at all.

Update 2 (prev in comments): Apple released MacBook, MacBook Pro Software Update 1.1 today; just installed so confirmation to come...

No idea what the problem is (and 10.5.1 does not solve it) though here are some workarounds I've found:

- Sleep, wait at least 30 seconds, wake.
- Press the option key five times in a row. Or the shift key. Then try a key. If not yet, try again.

Pressing the option or shift key, five times in a row may be total voodoo, though it does appear to work; it occurred to me by accident, though those are actually defined key sequences: the shift variation turns on "Sticky Keys"; option is for "Mouse Keys". (See the Universal Access preference pane for more info.)

And since they can change how the keyboard input is interpreted, it may indeed kick something back into gear.

Also: Here's a hint to tell if the keyboard is responding: Press "Caps Lock"; you'll either see its light go on or not; immediate feedback, without wondering.

(I've also seen, though only a few times, the mouse cursor get _very_ confused; maybe a strange USB gremlin has crept in.)

BTW: Fire up the "International" preference pane, click the "Input Menu" tab and check "Keyboard Viewer". (Or if it is already checked, check the "Show input menu in menu bar" item at the bottom.) Now select "Keyboard Viewer" from the international menu (which uses an icon of the flag of the localization you're using) and you've got keyboard input by way of the mouse/trackpad; handy when the keyboard isn't working. :)

smarter ping

while true ; do echo "`date`: `ping -qc1 domain-name | grep round-trip`"; sleep 5; done

A one-liner that does, in order:

• show the date/time
  
• show the *results* of a single ping (or nothing), on the same line
  
• wait 5 seconds
  
• do it all over again

And it simply does this til you kill it.

Why? Simply ping'ing doesn't give you any info on *when* things are happening - like when the server that you're waiting to reboot, did; or when the node you're testing stopped responding.

ID a card/port pair, given a simple serial jack number

We recently installed a really nice Foundry switch (highly recommended) and its admin (as is generally the case) requires addressing ports by the combination of card and port number. However the cables jacking into it are numbered serially; from 1 to whatever.

So when you need to find which cart/port corresponds to which jack, it can get messy - here's a simple script (easily adapted to other scenarios) to simplify:

#!/bin/bash

# simple script to calc the card/port pair, given the patch cable #
# - result is returned as an integer, in format: port + (100 * card#)

# History:
#
# 20070523 mvgfr: incep

# minimal error trapping:
if [ -z "$1" ] ; then exit 0; fi
if [ "$1" -le 0 ] ; then exit 0; fi

patch=$1
# fudge for discountinuity; jump from card #8 to #13 (since there are no port cards in slots 9-12)
if [ "$patch" -gt 192 ] ; then let patch+=96 ; fi

card=$(( ( ( $patch * 100 / 24 ) + 99 ) / 100 ))
port=$(( $patch - ( ( $card - 1 ) * 24 ) ))

echo "$card, $port"

result=$(( ( $card * 100 ) + $port))
echo $result

exit $result #send the result back as the exit code, for potential further processing...

#end

MOSXS 10.4.11 & Xsan 1.4.2

Haven't seen much discussion of this, so here's a "vote":

Just upgraded a three-node Xsan to MOSXS 10.4.11 and Xsan 1.4.2; worked like a champ on all three: dual G4 (800MHz) desktop, dual G5 desktop and dual G5 Xserve. (FWIW: It's attached to four XSRs of widely-varying ages, via a QLogic SANbox 5200.)

The volume stayed online, as designed, the whole time, including four reboots - I missed the 10.4.10 update (required for Xsan 1.4.2) on one of the nodes, so had to install 10.4.11, reboot, then Xsan 1.4.2 and reboot on that one.

Apple changed the specs since the 1.4(.0) release (of Xsan) to exclude G4 desktops, so I'll probably replace it with another G5 desktop/Xserve at some point soon, though I don't see any need for urgency.

find the mdns name for an IP addr

This seemed like it might be useful and then after I dug through to finally solve the problem, it may be for only a very limited set of circumstances. :)

And interesting script anyway: Given an IP address, find the mdns (AKA ZeroConf or Bonjour; formerly Rendezvous) name - which might help give you a better idea who's there):

#!/bin/bash

# use mdns (local subnet only) to show machine name for a given host IP addr
# (ex: for machines w/ DHCP addrs and therefore unintersting domain names)

if [ -z "$1" ] ; then echo "must supply a host as 1st/only arg"; exit; fi

if [ -n "$2" ] ; then echo "must supply only one arg"; exit; fi

# is it necessary to ping it first, to make sure it's in the ARP table?
#if ! $(ping -c1 "$1") ; then echo "error pinging host"; exit; fi

if ! arpOutput=$(arp "$1") ; then echo "error in arp host"; exit; fi

arpMAC=$(echo "$arpOutput" | sed 's/.*\([a-zA-Z0-9]\{1,2\}:[a-zA-Z0-9]\{1,2\}:[a-zA-Z0-9]\{1,2\}:[a-zA-Z0-9]\{1,2\}:[a-zA-Z0-9]\{1,2
\}:[a-zA-Z0-9]\{1,2\}\).*/\1/g')
arpMAC=$(echo "$arpMAC" | sed 's/^\(.\):/0\1:/' | sed 's/:\(.\):/:0\1:/g' | sed 's/:\(.\):/:0\1:/g')

echo "starting mdns browse; you'll have to hit ^C to get control back..."

dns-sd -B _workstation._tcp | grep "$arpMAC"

# end

Script to notify if any outdated MacPorts

Updated version here.

-----

Add the script below as a cron job and it'll notify* you if you have any outdated MacPorts.

*Presuming you're configured to have cron job output emailed to you, it'll notify by email. If you have growl installed, it growl at you too. Lastly, it logs to /var/log (which probably requires creating that log file first).

(Updated for recent tweaks.)

#!/bin/bash

# 20071110 mvgfr: check for outdated macports & notify if any - via growl & stdout (emailed when cron'd)
# 20080209 mvgfr: must run sync before, so it can learn about updates!
#                 also added "-H localhost" workaround for growl Leopard bug (ignores some)

# may take awhile; is this an issue?
/opt/local/bin/port sync

potentialOutput=`/opt/local/bin/port outdated`

if [ "$potentialOutput" != "No installed ports are outdated." ] ; then
    echo "$potentialOutput"
    if [ -f /usr/local/bin/growlnotify ]; then
        /usr/local/bin/growlnotify -H localhost -s -m "macports: $potentialOutput"
    fi
fi

echo "`date "+%Y%m%d-%H%M%S"`: $potentialOutput" >> /var/log/port-outdated.log

#end