MOSX: video mode wedged?

OK; this finally bit me one time too many - took me way too long to figure it out, but here it is, since I don't see it anywhere else:

For some reason, the video mode gets stuck (ex: 640 x 480 only) and you can't change it - here's how to fix it:

The info is stored in several files:

• /Library/Preferences/.GlobalPreferences.plist
  
• /Library/Preferences/com.apple.windowserver.plist
  
• /Users/⟨short-name⟩/Library/Preferences/ByHost/.GlobalPreferences.⟨MAC-addr⟩.plist
  
• /Users/⟨short-name⟩/Library/Preferences/ByHost/com.apple.preference.displays.⟨MAC-addr⟩.plist
  
• /Users/⟨short-name⟩/Library/Preferences/ByHost/com.apple.windowserver.⟨MAC-addr⟩.plist

And there may be some in PRAM though that doesn't seem to be the case on recent systems.

To reset the video mode:

• defaults delete /Library/Preferences/.GlobalPreferences ColorSyncDevices
  
• defaults delete /Users/⟨short-name⟩/Library/Preferences/ByHost/.GlobalPreferences.⟨MAC-addr⟩ ColorSyncDevices

(Each of the above on its own line; the first requires admin.)

(Simply removing the windowserver plists has never done it for me - even from single-user mode, immediately followed by a restart and PRAM reset (multiple times). And FWIW, those files have still not reappeared on my system; perhaps they're no longer used.)

Why might this happen? It's probably related (at least in my case) to moving a boot volume from one system to another - that has a different video card. Which means this might be of some help for moving from one machine to another (ex: upgrade) or deploying an image to multiple machines.

NB: The above info is from a Mac OS X Server 10.4.11 system, though at least most of this should apply to Mac OS X (Client) as well, and other releases.

Trouble joining a domain? (MSWin)

Strange; this has happened more than a few times now, so time to expose my ignorance:

• We have a Citrix server running on Win2K3 Server.
  
• It's configured to bind to a domain in order to allow use of the accounts there.
  
• The PDC is on a Mac OS X Server box (10.4.11).
  

The initial bind is fine and authentication works great - until it breaks.

When it breaks, simply re-entering the info yields a 1326 error; it thinks the credentials are wrong. It seems there may be some caching of credentials, though I haven't found where or how to flush; rebooting the Citrix server doesn't help.

It also doesn't help to re-bind to a workgroup, reboot, and then attempt to re-bind to the domain - same error.

What does seem to fix it is this:

• On the PDC, rename the domain & save.
  
• On the domain client, confirm a bind to new/different domain.
  Rename the domain back to the original. (On the PDC.)
  
• Confirm a bind to the original domain. (On the domain client.)
  

Theory: Caching is forced to flush by temporarily binding to another domain - we've only got one, hence the rename; it's probably not necessary if you've another domain to temporarily bind to.

(Update: If it's an option in your situation, a simple restart of the PDC may suffice.)

Leopard: Periodic scripts don't email results (postfix)

I've been round-and-round on this one and can't find the break; hopefully someone will jump in and point out my error!

I configure /etc/aliases so that postfix knows where to send stuff addressed to root. I use "mail root" to test and it works.

Here's the first strangeness: Postfix no longer logs the send, as it did by default in Tiger. And I can't find where to bump the logging level.

I then configure /etc/periodic.conf.local to send output of the periodic scripts to both root and /var/log. The scripts run (both interactively via "periodic daily" and timed, via launchd) and logs are written in /var/log, but no email.

The behavior is consistent across every Leopard machine I've configured.

So both pieces of the puzzle seem to be working properly, though not the combination - what's missing?

AHA! After a false start, simply trying to explain it, did indeed bring on the solution, and it's painfully easy: Update to 10.5.2. :)

I had forgotten two factors:

1) Running "periodic " interactively did indeed email the results properly.

2) One of my Leopard installs "strangely" did, when kicked off by launchd, email the periodics' results properly - the one updated to 10.5.2. :))

(Credit to an Apple Discussion for the final kick to put all the pieces together.)

Update #2: It's not quite so easy (as updating to 10.5.2); the default config on a Mac OS X *Server* box is somewhat different: Comment out the references to Cyrus in both master.cf & main.cf (in /etc/postfix); for those of us simply wanting to email cron/launchd results out, it's just getting in the way.

BTW: Increasing the postfix logging level is so simple it's embarrassing: Edit /etc/syslog.conf. :)

Enumerate "shares"

Handy to place into the periodic/daily script, to keep track of shares and/or similar sub-folders. (For example, you can watch how usage changes over time, to notice patterns of usage before they become a problem.)

# display usage of sharepoints
# (whereis enables it to be run on non-MOSXS system w/o err)
# ((anyone know of a call available on MOSX (client) system?))
if [ `whereis sharing` ] ; then sharing -l | grep path | awk '{print $2}' | xargs -n1 du -ks; fi

# OR

# show usage of dirs in /shares - if it and they exist
if [ -d /shares ] ; then if [ "`find /shares -type d -mindepth 1 -maxdepth 1`" ] ; then { find /shares -type d -mindepth 1 -maxdepth 1 -print0 | xargs -0n1 du -ks; } ; fi; fi

(NB: Both are single lines and must be run as root.)

The nice thing about the second variation is: If you config your servers so that all "shares" are in the "/shares" directory (or maybe the "shares" directory at the root of each mounted volume), it shows the status even if they're not shared at the moment, which can be handy.

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.