shards mvgfr: geek: 2007

2007/12/23

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.

2007/12/21

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!

2007/12/20

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.

2007/12/19

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.

2007/12/15

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. :)

2007/12/05

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.

2007/12/04

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.

2007/12/01

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

timestamp bash history entries

Wow; bash3 has a terrific feature; the shell variable HISTTIMEFORMAT will timestamp entries in your history - so you can get a *much* better idea of what happened, especially since it's so easy to have multiple sessions going at the same time, so that commands in the history get somewhat interleaved.

Add

HISTTIMEFORMAT='%Y%m%d-%H%M%S: '

to (for example) your .bash_profile.

And Leopard (MOSX 10.5) has bash3 by default; nice.

MOSX: My $PS1

PS1='\[\e]0;\u@\h\a\]\D{%Y%m%d-%H%M%S} \u@\h \W [\j]\n$ '

This sets the Terminal title bar to:

user@node - current-command

Which is dynamic; it changes as you issue commands. (Slick.)

And it sets the prompt to:

date-time user@node working-dir [jobs]
$

It's an awfully long prompt, so it wraps, and puts the familiar "$" at the start of the *second* line.

Why? It's sometimes *very* handy to have the prompt indicate when that command was issued.

(BTW: Bracketing the window title bar potion in "\[" and "\]" is critical; otherwise (since it doesn't print those char in the prompt itself) readline will miscalculate where you are on the line and things get ugly.)

Show ALL recently-modified prefs

Search 'full-path' for plist (pref) files that were modified more recently than 'ttt' (ex: '5 minutes ago') and dump them in human-readable format:

find 'full-path' -iname '*.plist' -newermt 'ttt' -print | xargs -n1 | sed 's/.plist$//' | xargs -n1 defaults read

(Note: It is important to specify a *full* path.)

Issue a sequence of commands, and walk away

You're ssh'd into a server and need to issue a sequence of commands that'll take awhile - and your connection might drop, terminating those commands. Try this:

nohup bash -c "cmd1; cmd2; cmd3" &

Which starts the sequence and sends it immediately to the background (the trailing ampersand) - and also sets it so that even if the controlling terminal goes away, it continues to run (via "nohup"). If you really do need to kill it, use the -KILL signal.

Caveats: Watch your stdin/stdout/etc - this is generally most useful for commands that require no input and generate no output, since, for example, you just disconnected stdin and stdout by sending it to the background.

The above is handy to know if you need to sudo the commands - since you will: a) not see the "Password:" prompt, and b) not be able to respond to it. Here's the cheat: As long as you're in a default ssh config, there's a timeout; sudo commands issued within the timeout don't prompt. So if you need to sudo the above, issue an innocuous "sudo ls" (or some such) just before, to authenticate and get the timer running.

To find out what background jobs there are:

jobs -l

Which also shows the process ID, so you can watch it via top or some such.

Want a little more feedback? How about:

nohup time bash -c "date; cmd1; cmd2; cmd3" &

Which will display the date the inner commands started and then some stats about the time the other commands took, after they're all done.

Need to make sure they each work, before going to the next? Try this:

nohup bash -c "cmd1 && cmd2 && cmd3" &

The double ampersand tells bash to execute following commands ONLY if the previous one succeeded. (More specifically, if it's exit code was zero.)

And you can get more fancy by putting some "echo" commands in there, piping the output to mail, etc.

Validate/verify MD5 or SHA1 hashes

Want to confirm that download hasn't been altered?

MD5:

if [ $(md5 -q pathHere) == 'md5-hash' ] ; then echo "OK"; else echo 'md5 hash mismatch!'; fi

SHA1:

if [ $(/usr/bin/openssl sha1 pathHere | awk '{print $NF}') == 'sha1-hash' ] ; then echo "OK"; else echo 'sha1 hash mismatch!'; fi

Substitute the path of the file to validate for "pathHere" above; similarly, the published hash for "md5-hash" or "sha1-hash".

Sure you could wrap it in a script, by why bother, when you have QuickSilver?

MOSX: Open a subfolder on a share, whether the share is already mounted or not

Mac OS X's "open" shell command is powerful - though strangely dependent on the mount state of shares.

Executing

open afp://server.example.com/share/top-folder/sub1/sub2

Will open the share - and, if the share was already mounted, ignore the rest of the path.

So, here's a quick command (make sure it's all one one line) that will open the subfolder, whether the share is already mounted or not:

if [ -d /Volumes/share ]; then open /Volumes/share/top-folder/sub1/sub2 ; else open afp://server.example.com/share/top-folder/sub1/sub2 ; fi

Adaptation for other protocols (ex: SMB), other mountpoints and error-checking are left as an exercise for the reader. :)

Help! (PX502 and Retrospect)

I've got a Quantum PX502 tape library on Fibre Channel that I'm *attempting* to use with the EMC (formerly Dantz) Retrospect backup application (running under Mac OS X Server 10.4.10) - and it's giving me fits!

It won't complete a backup; each time, Retrospect loses contact with the PX502 before it completes; usually *well* before it completes. At this stage, it's usually an error 205 (from Retrospect) and "Bad reply received" from the PX502.

Quantum has sent NCR techs out to work on it, though it's actually gotten worse since they started. :/

EMC says the detailed SCSI log shows activity they're not familiar with - and they *just* got a PX502 to test (!) -- even though the EMC compatibility DB specifically shows this config as supported. (Quantum's DB also shows this is a supported config.)

Is there *anyone* out there using a PX502 with Retrospect? I'd appreciate *any* feedback at all!

Kerio, Palm, VersaMail & ActiveSync

Interesting mix of several technologies that looks pretty useful.

Had some trouble putting all the pieces together, so here are some clues for anyone else in a similar boat:

Check the Kerio config; what ports is it using? Are the services you want (ex: https) on?
Triple-check the firewall config. (It's the *really* silly things that get you...)
Yes, you probably do need the magical EAS SP2 update though check the Palm Support site for some model/service -specific info first.
VersaMail apparently allows only a single account to be configured for ActiveSync; the choice simply does not appear if another account is already using it.
If you're using a self-signed cert, there are some pitfalls; see info in links below.
If you're using a wildcard, it likely will not work. If you're a DigiCert customer, they've got you covered: They issue a credit to your account to cover a single domain name cert which will be fine. And if you need to change the server name, they've got a handy (and fast) "Reissue" button for you. Well done, folks!
And the key my boss found: Specify the server address (in VersaMail) via IP address instead of domain name; strange.

Some other refs that may be helpful:

shards mvgfr: geek