Archive for the ‘OS X Server’ Category

Xserve G5 Remote Diagnostics and Bootable CD

Wednesday, April 15th, 2009

The Xserve G5 has a remote diagnostics tool that runs in Open Firmware, similar to the Apple Hardware Test (AHT) found on most OS X installation disks that ship with Macs, or now baked into the EFI on most new Intel based Macs. The depths of testing and detailed results of the Xserve Remote Diagnostics far exceed AHT, but so does the complexity of setting it up.

Normally, this very comprehensive testing suite can require up to 2 additional machines; the first machine to administer the test and the second OS X Server running Netboot. Both administration and Netboot serving can be performed from the same Mac. The fact that I can’t run these tests without additional machines bothers me, but setting up another server just for Netboot is wholly impractical.

Thankfully a set of instructions showing how to create a bootable CD in lieu of Netbooting are available. The process involves creating a disk image from parts of the Xserve Remote Diagnostics software. The resulting image is small and generic to any Xserve G5, so much so that I couldn’t figure out what the point was of telling people how to do it instead of just letting them download the completed image.

To that effect I’ve compiled all the necessary parts here, including the bootable disk, so that it?s easier to perform these tests:

Apple Supplied Documentation (alt)
Xserve Remote Diagnostics 1.0.4 (alt)
Xserve Remote Diagnostics 1.0.4 Boot Disk

The following basic steps should help:

  1. Download and read the Apple documentation.
  2. Download and install the diagnostics software on a Mac that is within the same subnet as the Xserve to be tested.
  3. Download and burn the boot disk image to CD.
  4. Put the burned CD into the Xserve and restart it while holding down the C key. The CD will not appear in the list of bootable devices while holding down the option key, or as an option in Startup Disk. Once booted from the disk you’ll see a gray screen with some text at the top.
  5. Make sure the administrative computer with xrdiags is on the same subnet as the Xserve, you might have to directly connect to its first (lower) Ethernet port and set your subnet to 0.0.0.0 if the Xserve is not detected when running xrdiags -d.
  6. Once the tests are running prepare for a long wait. The documentation says 5 minutes for the Quick test and 15-20 for an Extended one. A Quick test on an Xserve G5 with 8 GB of RAM took 45 minutes; an Extended test took over 3 hours. This was a terrible discovery late at night.

Hopefully this will help someone

Changing IP addresses on OS X Server, and you

Wednesday, May 9th, 2007

When the going gets tough with a computer, we often contemplate whimping out to the nuclear option (AKA reformatting and starting over). But what a relief it was to discover the changeip command found in OS X server. This is quite useful when network changes are made to the network, such as when changing the ip addressing scheme. When running a server and making a network address change, an admistrator may need to do more than to change the IP address in the Network system preference. The original IP address may also be embedded within the configuration settings of some network services such as OS X’s Open Directory.

So in a nutshell, when changing a server’s network settings, make sure that ALL your IP addresses are changed to the new address. It’s the only way to do it on the Interweb.

Read more at http://discussions.apple.com/thread.jspa?messageID=1983848�.

Quick Tip: Removing unwanted .DS_Store Files

Tuesday, April 4th, 2006

.DS_Store files are created by OS X to store information relevant to the Finder, such as window positioning, and Finder comments. For the majority of users they go completely unnoticed because by default they are invisible, as are all other files beginning with a period. The easiest way to see them is to pop open the terminal and type in "ls -la ~". What you’ll see are a list of all the files in your home directory, including the invisible ones.

So why care about the .DS_Store file? They are insignificantly small, hidden, and help the Finder out. That is, unless you’re operating in an environment with PCs, or accessing files from a Mac over and FTP client. Then they can become rather obvious and very confusing.

There are a bunch of little applications that can remove .DS_Store files, among other things, but who wants to download an application for something that can be done with a really simple command. Most of the commands I’ve seen involve find executing rm followed by a few other arguments. For the life of me I can’t understand why people aren’t just using the “-delete” argument in find.

Here is my simplified rendition:
find . -name .DS_Store -delete

Yes folks, it’s that simple. find is a Unix tool for locating files. The period is the path to start at. I could have used “/” if I wanted it to start at the root of the drive. Period means start from my current location in the Terminal (usually represented to left of where you start typing in the Terminal). The “-name” tells find what to look for, in this case the pesky .DS_Store file. Lastly -delete tells find to remove the file when it encounters it. Remember that you might have to use the sudo command depending where you want to remove them from.

A word of caution, this command permanently removes the .DS_Store files. It doesn’t move them to the trash. The Finder will replace the .DS_Store files when it needs to. As with any Unix command, please type carefully and fully understand what is going on, before you hit return. There are no “undos,” that’s why it’s a great idea to backup your computer. While this command, when used right should be harmless, backing up could save you from the mess you get into from someone else’s Unix trick, or enabler. I hope I haven’t scared anyone.

Enjoy.