The scenario: I had an OS X Server which I had been accessing via ARD (Apple Remote Desktop). I had recently updated the ARD Client software to v3.1. This morning I needed to install the ARD Admin software on the same server (to use it as a Task server, probably the most useful feature of ARD 3). No joy. The installer complained that the software already installed was a later version than I was trying to install -- 3.1 Client on the server, 3.0 Admin on the install disk.
The reason this happens is that the ARD Admin installer package is actually a metapackage -- a package of packages, if you will. It contains a package for the Admin application and also one for its own version (3.0) of the client software. It's this package that's blocking the install.
The solution is a simple, if not immediately obvious, one. Control-click on the RemoteDesktop.mpkg icon and choose Show Package Contents from the pop-up menu. In the new window that opens, burrow down through Contents -> Installers, and find the RemoteDesktopAdmin.pkg installer. Double-click on that one and ... Presto! one fresh clean installation of ARD Admin.
But it doesn't stop there, sorry. The last thing you must do before launching it is update it with the ARD Admin 3.1 updater. You can use Software Update or download it from Apple's update site.
Managed printers (on managed clients) are convenient, but there are bugs. The problem is the system doesn't clean up after itself. One side effect is the user has old printer configurations that were deleted from the server (this can also result in what appears as duplicate printers, but the config was updated with the same name, or deleted and recreated). Another side effect is with computer list managed printers. For example, computer lab A has printer A managed only. Computer lab B has printer B managed only. The user logs into lab A, logs out, then logs into lab B. They shouldn't see the lab A printer at this point, but they do (because they logged into lab A once upon a time, and this saved in their home folder).
Read the rest for some workarounds to these problems...
There is a problem with managed clients and external displays: The user (a high school student, for example) can change the display to an unsupported resolution/frequency, rendering the display useless. When this happens, it's broken for that user on that machine, because of the By Host preferences folder. (What's with that folder anyways? I mean, why?) I know there is that warning and confirmation that will auto-revert, but sometimes it doesn't warn, when it 'thinks' it will work. Anyways, the kids manage to make the display black.
You can always lock out the Displays prefpane with managed preferences, but they can still switch it with the menu extra. So the simple solution is to take away read access for "others" on the menu extra:
I have seen a network user on a Managed Client logging in hang before the Finder and Dock load, so it just sits there with the desktop picture and only the Spotlight part of the menubar visible. The fix is simple. Delete these folders:
/System/Library/Caches/
/Library/Caches/
That should resolve the issue for the user whose login was hanging.
Like many OS X admins, I inherited a bunch of Macs which all look the same, but serve different functions. Since they all pretty much look the same from my VNC/Timbuktu/Apple Remote Desktop window, it's hard to know where I am when I log in. I can't tell which one is an Xserve, and which is a Mac mini...
I could place a folder with the name of the server in the Dock (along with sub folders or files named with IPs or hostnames for quick reference). Or I could use this hint (shameful plug, I know). The problem is, with all of the monkeys' changes, I have more important things to do than modifying screenshots all the time...
Enter our friend GeekTool. Set it up to read/display a text file of the services on the box, as well as current IP addresses and or hostnames, and you've got a dynamic 'desktop' which displays useful information. Someone who's handy with shell scripting might know how to write the scripts to grab the IPs and/or hostnames on the fly. That'd make for a really nifty and useful hint. Happy administering!
You can obtain the Mac OS X Server serial number (for Tiger) via the command line. At the Terminal on the server itself (or via ssh if you wish), type:
more /etc/systemserialnumbers/xsvr
Press Return, and you should see the serial number displayed. I can't help but think that this could be made more secure rather than being stored as clear text.
I have been running a host monitoring solution (among other things) on an Xserve G5 for about a year now. It has been rock solid stable and has proven to be better than any other solutions I've looked at. It uses Nagios and sendPage, installed on OS X Server.
I've created a fairly detailed writeup covering exactly what I did, in case you'd like to set up the same on your server.
[robg adds: Typically I would ask the author's permission to mirror the actual writeup here. However, in this case, the provided solution is quite lengthy and detailed, and may not be of interest to a huge number of readers, so I think a link to the writeup will suffice.]
I recently transferred data from an old G5 running 10.4.6 Server to a G5 XServe. All was running well until I launched the Server Monitor application to check the hardware status of the server. The Server Monitor application reported "waiting for response from server." I finally found out that the hwmond config needed to be modified. Rather than editing the file, I ran the hwmondSetup tool via Terminal.
Log in with root access (normally via sudo on the main admin account), then run this command:
After installing the Java 2Platform Standard Edition (J2SE) 5.0 Release 4 on my OS X server running QLA 3.5, the QLA server would not open, run or even uninstall. I had to do the following to revert it back to Java 1.4.2:
In Terminal, run the following commands:
$ su root
$ cd /
$ cd System/Library/Frameworks/JavaVM.Framework/Versions/
$ sudo rm -rf CurrentJDK
$ sudo ln -s 1.4.2 CurrentJDK
After executing the above mentioned commands you should be able to install QLA.
[kirkmc adds: I haven't tested this, but there's always a risk in removing anything rather than backing it up first. So at the rm -rf command, I'd suggest making a copy of the directory with a different name.]
When ssh'ing into an OS X client as a user whose home directory is mounted on an AFP server, the following errors can occur. First, during the login process:
/usr/X11R6/bin/xauth: error in locking authority file ~/.XAuthority
Second, if one tries to start an X11 application, the following error occurs:
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).
The problem seems to be that xauth cannot update the .Xauthority file when the ssh session starts up, rendering the user unable to authenticate to the X server connected to their ssh session. A workaround to this problem is to have xauth write the session authnetication cookie info to a file on the local disk, not in the AFP-mounted home directory. One needs to create an /etc/sshrc file to do this.
You can obtain the Mac OS X Server serial number (for Tiger) via the command line. At the Terminal on the server itself (or via ssh if you wish), type:
