Mac OS X 10.5 (Leopard): Can’t administer Mac OS X 10.3 Server remotely?

Posted by Pierre Igot in: Macintosh
June 18th, 2008 • 3:45 pm

I am afraid it looks like Apple has made a blooper in Mac OS X 10.5 (Leopard).

Regular Betalogue readers might remember that, as part of my job, I manage an Apple Xserve (G4 model) running Mac OS X Server version 10.3.9 (Panther).

It’s an old machine (over five years old), but it’s running fine, and we have no need to upgrade to a newer machine/system at present.

It is also a machine with few problems, which means that I don’t often have to access it remotely. The most frequent problem on it is that FileMaker Server (again, an older version) tends to lock up after a few weeks and requires a machine restart. I usually do this remotely via SSH.

All this is to say that, until today, I had not had to use Apple’s server monitoring/administration utilities (Server Monitor, Server Admin, and Workgroup Manager) in months. The last time I had run them was probably when I was still using Mac OS X 10.4 on my Mac Pro!

A few weeks ago, Apple released newer versions of the Server Monitor, Server Admin, and Workgroup Manager utilities (versions 10.5.3, replacing the older 10.4.7 versions), and I installed them on my Mac Pro, without even bothering to test them to see if they worked fine.

But today there was a problem with the mail server on the Xserve, so I went to launch Server Admin 10.5.3. The first surprise was that the application did not even have the address of my server anymore. This is the only server I manage with this utility, and usually Server Admin remembers it from one time to the next and automatically fills in the address and login information for me. But here there was nothing.

I figured that it was a problem with the Server Admin update to 10.5.3 and just entered the information again. Then I pressed “Connect.” And I got this:

No server available

My first reflex was to check if the web server was still accessible. It was. So clearly the Xserve was still running fine. It was just the mail server on it that was not working properly. But for some reason Server Admin was unable to connect to the server. It couldn’t even find it.

My second thought was that it was a problem with the Server Admin 10.5.3 update. I went to check the application’s preferences, but couldn’t find any strange new setting that might explain the problem.

I then launched Server Monitor (10.5.3), and, unlike Server Admin, it still had the address and login information for my Xserve, and was able to connect to it just fine. Workgroup Manager 10.5.3 also still had the address and login information, and was working fine as well.

The most urgent thing for me was to bring the mail server back to life. I wanted to check the status of the mail service using Server Admin, but obviously this was not possible. So I used SSH in the Terminal to connect to the Xserve remotely. I checked the users’ mail folders to see if any of them was full. (Mac OS X Server 10.3.9 does not handle full mailboxes very gracefully, and it can lead to a breakdown of the mail service.) But they were normal. None of them was full.

I then rebooted the Xserve via SSH. (When in doubt…) Thankfully, after the reboot, the mail server was working fine again. I don’t know what the problem was, but it was gone.

The problem when trying to use Server Admin in Mac OS X 10.5.3 to connect to the Xserve, on the other hand, was not. Even after the Xserve reboot, Server Admin still was not working in Leopard.

My next instinct was to try and reinstall the older version of Server Admin (10.4.7) and see if that version would still work. Unfortunately, I soon discovered that Apple has made it impossible to reinstall that older version of Server Admin, even though it works just fine under Mac OS X 10.5.x. The Server Admin Tools 10.4.7 installer simply fails to recognize the Mac OS X 10.5.3 volume as a valid volume to install the tools, and there is no alternative.

The final test was to reboot my other Mac Pro in Mac OS 10.4.10, which I still had installed on a partition. I then tried to run Server Admin (10.4.7) on that machine, and it was able to connect to my Xserve just fine and to show all the running services, including the mail service, which showed no sign of anything being wrong.

I then copied the Server Admin (10.4.7) application to a USB key and copied it from the USB key to my Mac OS X 10.5.3 system. I launched it there and, as expected, the application launched just fine. Unfortunately, when I tried to connect to my Xserve, I got a similar error message, to the effect that there was no server at the address entered.

My next step was to go to the Apple Discussions forum for Administration Applications for Mac OS X Server. I soon found that I was far from the only one with problems using Server Admin to connect to a remote server running an older version of Mac OS X Server.

It looks like it’s actually not an uncommon problem. Of course, as with all network-related issues, there is a myriad of possible sources for such connection problems. However, I think my own experience clearly demonstrates that there is something in Mac OS X 10.5.3 (Client) that breaks the ability for Server Admin (either 10.5.3 or 10.4.7) to connect to a remote server running an older version of Mac OS X Server (10.3.9 in my case). There really is nothing else that has changed in my own work environment, and I really do not think that there is anything that has changed in the Xserve’s own network environment in recent times, although of course I cannot be 100% sure, because that network is not under my control.

Is this a sneaky marketing ploy used by Apple to try and force us to upgrade our servers to Mac OS X Server 10.5? I seriously hope not. It is more likely that Apple broke something without realizing it. But it is also quite possible that if the problem only affects situations involving a remote server running an older version of Mac OS X Server—I am unable to verify this by trying to connect to a remote server running Mac OS X Server 10.5, because I don’t have one—then it is a bug that does not have a high priority at Apple.

I submitted my bug report, but that’s about all I can do. For now, whenever I need to connect to my Xserve with Server Admin, I will have to switch to my other Mac Pro, reboot it in Mac OS X 10.4.10, and run Server Admin from there. It’s not a huge inconvenience, but it’s an inconvenience just the same.

It certainly won’t be enough to make us switch from Mac OS X Server 10.3.9 to Mac OS X Server 10.5! This would be a costly upgrade, and we simply have no need for it at present. We will probably wait until the Xserve dies before replacing it with a new Xserve that comes with Mac OS X Server 10.5 (or possibly even the next version). But I still hope that my bug report will not go unanswered, and that something will be done to fix this pretty major bug sooner rather than later.

9 Responses to “Mac OS X 10.5 (Leopard): Can’t administer Mac OS X 10.3 Server remotely?”

  1. alangold says:

    Not sure why you are having a problem – I have to monitor 10.3/4 & 5 servers of my MacBook Pro.

    I have a server folder with a sub folder for each of the Admin Tool versions (Panther Server Admin Tools, Tiger Server Admin Tools etc.) and use the appropriate tools for the appropriate server.

    It may be that the fact that I created the sub folders and installed the admin tools in sequence may have let me successfully do it.



  2. Pierre Igot says:

    Thanks for sharing your experience. My understanding is that you shouldn’t have to use the older server admin tools to monitor the older servers. You should be able to monitor any remote OS X Server machine using the latest server admin tools.

    I suspected that, of course, the problem did not affect all users. Like I said in the post, there are so many possible combinations in network-related issues that bugs are always likely to crop up only for certain categories of users.

    But I have no idea what additional factor in my own situation could be causing the problem. All the evidence points towards OS X 10.5.3 itself as the culprit.

  3. danridley says:

    Have you tried installing the 10.3 or 10.4 Server Admin Tools? Apple knowledge base is pretty explicit — the version of the admin tools needs to either match or be one version ahead, and there are still consequences to being off-version (you can admin Tiger Server with Leopard Admin Tools, but not DNS; you can admin Panther Server with Tiger Admin Tools, but it saves data in a way that makes it incompatible with the Panther Admin Tools after that).

  4. Pierre Igot says:

    Thanks for the links, Dan!

    There is something very weird going on here—which is not all that surprising, given the issues involved.

    Based on the Apple KB article you mentioned, I downloaded the 10.4.11 admin tools, thinking that there was maybe something in them that was not in the 10.4.7 admin tools that I had.

    But then when I launched the installer in Mac OS X 10.5.3, it still wouldn’t let me select my Mac OS X system volume as the installation destination. So it looks like Apple wants you to use the 10.4 admin tools in Mac OS X 10.5 when trying to remotely administer a 10.3 Server machine, but does not let you install the 10.4 admin tools in Mac OS X 10.5 to begin with. Nice.

    I then took the 10.4.11 disk image to my Mac Pro running Mac OS X 10.4.10, and I installed it there. But when I looked at the Server Admin application installed by the 10.4.11 package, its version number was… 10.4.7, i.e. the exact same one as the one I already had.

    Still, I copied the applications installed by the 10.4.11 package (including that copy of Server Admin 10.4.7) to my USB key and then to my Mac Pro running Mac OS X 10.5.3.

    I launched that copy of Server Admin, but expected that it would give me the same error message, since it was the same version number as the one that I had tried yesterday.

    But it actually worked!

    And then out of curiosity I quit that one and went to launch the Server Admin 10.4.7 that I had tried yesterday—and it worked too!

    This does not make any sense. All I did was copy the applications installed by the 10.4.11 server admin package, which apparently include the exact same version of Server Admin (10.4.7v157.8, to be exact). The only difference between that Server Admin 10.4.7 and the one installed using the 10.4.7 package is the creation and modification dates (and the file size is also slightly different).

    What I am supposed to conclude here?

    The Apple KB note says that I should use the 10.4 admin tools, but the installer does not work with Mac OS X 10.5.3 (neither with 10.4.7 nor with 10.4.11). And when I copy the application manually after installing it on a Mac running Mac OS X 10.4.10, it then works in Mac OS X 10.5.3, and somehow even makes the previous copy able to work as well, even though it didn’t work yesterday.

    I am completely baffled. I guess all that this confirms is that the situation is very messy, and that remote administration of OS X Server is more an art than a science. Which, as I said earlier, is not all that surprising given the rather unpredictable nature of situations involving complex network connections.

    But still… 

  5. danridley says:

    Looking at it a little more closely, Apple never actually says you can run Server Admin Tools 10.4 on OS X 10.5, just that you need to use Server Admin Tools 10.4. I think they’re implying that you should have a copy of OS X 10.4 around to run the tools from.

    As for the rest of the weirdness (unchanged version number, the old one working after you copied the new one)… I dunno :-)

    I’ve always kept my OS X Server and client versions matched. It’s always worked flawlessly, but one of the reasons I do that is because I have the impression that’s the only case Apple thoroughly QAs.

  6. Pierre Igot says:

    If Apple’s reasoning is that people should keep their server and client OS X installs matched (but they are not saying that explicitly), then it demonstrates a serious lack of real-world perspective. What does the OS version of the client workstation I am using have to do with the OS version of the server machines that I have to monitor? It’s absurd to expect a perfect match, especially when system administrators can be expected to be responsible for monitoring a number of different servers.

    I certainly don’t see myself sticking with Mac OS X 10.3 client on my workstation just because I have to keep an eye on a remote server running Mac OS X Server 10.3. It does not make any sense!

    Besides, the 10.4 server admin tools were always perfectly capable of monitoring 10.3 servers. There was never any indication from Apple that people should not be using the 10.4 server admin tools to monitor 10.3 machines.

    If the decision not to support 10.3 server monitoring from 10.5 is deliberate, then it is highly questionable.

  7. danridley says:

    Well, there’s “deliberate” in the sense of breaking-it-for-the-sake-of-forced-upgrades, and there’s “deliberate” in the sense of “let’s not allocate any resources to supporting the server release that’s two versions behind.” My guess is that it’s the latter.

    I don’t think Apple would expect you to keep your workstations on older versions, I think they would expect you to upgrade your servers :-) Plus, they do explicitly support a single version mismatch (10.5 can monitor 10.4; 10.4 can monitor 10.3). Just not jumping back two versions.

  8. amary says:

    I, too, administer a remote Xserve G4, but unlike you, upgraded to OS X Server 10.4.x, and now 10.5.x. The machine was very stable under 10.3.x, but never was very stable under any release of 10.4. (Authentication services would periodically fail, making it impossible to establish new connections to the machine, and causing most services to fail. The only way to remedy the situation remotely was to power-cycle the machine, which I had to do a lot.) I was hopeful that Server 10.5.x would solve the problems, but I’m now up to 10.5.4 and still have major problems. While I’ve never seen the above problem, I now get very frequent kernel panics (4 times a day or so). Multiple clean re-installs onto wiped, good hard drives makes no difference. It passes hardware tests and extensive RAM tests just fine. I have similar problems trying to run Server 10.5.x on a G4 QuickSilver. When I try running Server 10.5.4 (same hard drive) on a PowerMac G5, I don’t seem to have all the kernel panics, but I’m unable to connect to it remotely with Server Monitor.
    I don’t think Apple is really supporting G4 machines anymore, despite their compatibility claims, and even G5’s are iffy. I almost wish I’d stayed with 10.3.x. Perhaps I’ll switch to Linux, or try an Intel Mac mini as a server. Not sure I want to buy a new Intel Xserve, given the poor OS track record, price, and its power requirements. Can’t wait for the “actually-works” release of the OS (Snow Leopard). Too bad you’ll most likely an Intel machine to run it.

  9. Pierre Igot says:

    I suspect you are right about Apple not supporting G4 machines anymore. But there is a different between “not supporting them” and “cutting them off altogether.” How hard is it for Apple to continue to support remote administration for older machines? You cannot help but suspect that someone deliberately made the cynical decision to cut older systems off in order to force people to upgrade/replace their 5- or 6-year-old machines. And, based on your own experience, I am sure it is quite obvious to you why I am more than reluctant to try and upgrade our older Xserve to 10.4…

    Economically speaking, the most logical thing to do is to wait until the old Xserve dies and then buy a new one, which will be Intel and will include the latest server OS. I work for an educational institution and they can’t just throw money out the window just to please Apple.

Leave a Reply

Comments are closed.