Apple released Mac OS X Server 10.4.3 a couple days ago. The full details about the improvements are detailed in Apple KB#302089, but there’s a few really nice bells and whistles in this update that might just make it the reason to upgrade your 10.3 servers. You can think of this article as a sort of “greatest hits” of the KB article.
Read on for more…After looking at that long list from Apple’s knowledge base on the updates in this release, it should be no surprise that this is Mac OS X Server’s biggest update ever. This of course brings us to looking at some of the specific upgrades:
I’m sure to the delight of many readers, sieve has been addressed and now works right out of the box, as pointed out by Olivier Ducrot. Be aware that you need a /usr/sieve directory that belongs to cyrusimap user and add a sieve 2000/tcp # timsieved entry to /etc/services
One of the biggest things in 10.4.3 is that lookupd should be fixed now. If you were having system hangs under heavy SMB or rsync operations you should give 10.4.3 a try.
Managed client preferences now work on nested groups. This means that you can apply them to Active Directory groups for easy magic triangle deployments.
Unified file locking is working now. This is great to see, as it enables your Mac clients to connect to your server over AFP, your Windows clients to connect over SMB, and the file locking to work both cross-platform and cross-protocol.
Server Admin is now supposed to let you create a DNS entry for your domain. We haven’t had a chance to test this one, so let us know in the comments if it’s true.
There’s been some reports of performance increases with Xsan 1.2 on this update for both client and server. We’ve not tested this yet either, so your millage may vary.
On the deployment front, Apple Software Restore’s multicast client can now ask the server for missing blocks at the end of the first imaging pass. Previously if any blocks were missed that inline error correction could not correct, the client would need to loop through the entire image n times until it get’s all the data. While it worked, it wasn’t necessarily the fastest way of doing things! ASR also allows you to have a client side time out if it hasn’t received any data from the stream in a number of seconds, and a server side reset that allows you to have the server stop streaming if there are no clients receiving data. This is cool as it will let you leave a mulitcast ASR server running without flooding your network with multicast traffic. There’s more detail on implementing these features in the man pages, and a few more details on the macenterprise.org mailing list, with thanks to Mike Bombich for getting the word out.
And now for some really cool stuff. The login window has recieved some nice enhancements. If you weren’t already aware, the Login Window already displayed the System Build, System Version, Host Name, Serial Number and Time – simply click on the Host Name (which is shown by default) and you can circle through these options – new to 10.4.3 are the IP Address (of the primary interface) and Network Account Status. The Network Account Status is the exciting part here, and provides the following information:
In addition to this, instead of having the Host Name as the default field on the login screen, you can now state your preference with a simple defaults write command:
<code> defaults write /Library/Preferences/com.apple.loginwindow AdminHostInfo <desired field> </code>
Where the “desired field” is one of the following: HostName, SystemVersion, SystemBuild, SerialNumber, IPAddress, DSStatus, or Time.
Yet another feature now added onto the Login Window is the ability to set up a startup delay – many of us have found either startup items in 10.3.x or modified rc.boot for this in the past when we’ve needed to allow the system time to finish obtaining an IP Address via DHCP and for DS to bind to the servers. This is also done with defaults write:
<code> defaults write /Library/Preferences/com.apple.loginwindow StartupDelay -int <number of seconds to delay> </code>
If the Login Window UI detects that the network servers are available when it starts, it will skip the delay, also if network servers become available before the delay expires, the Login Window UI cancels the delay and displays. Thanks to Scott Barber for posting information on the macenterprise.org mailing list.
Another spiffy upgrade is that the Weblog server can now publish podcasts, and Apple has a document on how to publish them for iTMS consideration here.
All in all, this is one update that all of us here are really pleased to see come out, and are very excited to deploy and continue to work with. Let us know in the comments below what it fixes, or doesn’t fix, for you.
by 
Does this resolve any of the Mailman issues many of us saw? (the Server Admin would botch things up and not allow us to do anything- or rather erase any changes made).
Hmmm… I never use Server Admin to do anything with the mailing lists beyond
turning them on, so I don’t know…
Anyone?
—
Breaking my server to save yours.
Josh Wisenbaker
http://www.afp548.com
An Xsan 1.2 build is available on the developer site for anyone with an
appropriate account to download and test. It has not been released yet.
Check DHCP.
I’ve had two servers now that 10.4.3 hosed DHCP with an error that there was no
network interfaces. Going into the DHCP and clicking on the interfaces popup,
then selecting the same interface solved the problem.
Also, it appears best to do a rebuild of the mail database after you finish.
Hopefully this is the last one for a while, but I’m skeptical.
I updated to 10.4.3 on my test server today and my DHCP scopes survived just
fine.
Just FYI,
Josh
—
Breaking my server to save yours.
Josh Wisenbaker
http://www.afp548.com
Has anyone seen if mobile home directories are syncing ~/Library? Part of what I
read in the update indicated that ~/Library syncing had been improved, but I
haven’t noticed it working on my own test setup.
There has been changes made in that area yes – taking a quick look, they are
syncing most of the ~/Library directory now, but are skipping things like
caches, logs ByHost preferences and the likes.
I agree – after what seemed like hundreds of attempts to link aggregate my dual port IBM gigabit card I’m now able to! I couldn’t do it for the life of me on my old faithful 1Ghz G4 Xserve without kernel panics. It had even corrupt my boot voluem so bad I had to re-store to a back-up a few times.
Only problem is that now I have one less reason to use to convince the money man I need a G5 upgrade…
I’ve got a mix of 10.4.1 and 10.4.2 servers and have been burned enough with
PasswordServer replication to be scared of applying the patch without having
time to rebuild the whole network. What is the word on fixes to password
server overflows that have been such a problem, and to the runaway processes
on replication?
Lately, I haven’t had a lot of overflow files in /var/db/authserver, but still have
plenty of overflows shown in the database by a mkpassdb -dump.
the guys at apple included the updates to server tools as part of the 10.4.3
server upgrade and not as a seperate upgrade. seesh!
No sign of an update here:
http://www.apple.com/support/downloads/serveradmintools104.html
A 10.4.3 Server has Server Admin 10.4.3 (157.5)
My 10.4.3 powerbook has 10.4 (156)
Damn, looks like you’re right.
Finally 10.4.3 introduces a way to select which "zone" is to be used for the
reverse lookup. Previously 10.4.2 (and earlier) seemed to use the last domain
entered as the reverse, which is utterly useless… I cursed when the
configuration of reverse IPs was disapeared in the transition from Panther to
Tiger.
Anyway, to select your desired zone for reverse lookups:
1) Select the "DNS" service
2) Select the "Zones" tab
3) Edit the zone you want to use for reverse lookups
4) Select the "Machines" tab
5) Edit the machine entry you want to use for reverse lookups
6) Select the "Use This Zone" button (located below the machine "Name:"
field)
7) Select "Ok" to commit this
8) Don’t forget to "Save"
Now you’ll have the correct zone set for reverse lookups without needing to
hand edit the zone files.
Have you tried disabling ssh, saving, and re-enabling?
10.4.3 Server seems to have reset my Squirrel config to factory.
Reconfigured IMAP to use CRAM-MD5 and added my plugins back in,
works fine.
Also see above thread about Server Admin Tools update.
I updated my XServe (duo G4 1.33 Ghz) from OS X Server 10.4.2 to 10.4.3 via Software update, on November 3. In checking the log files, I notice that the daily.out log reported that the daily periodic maintenance script ran once the morning after the update, but has not run since then. I checked to see if any of my client Macs (11 total which include G4 and G5 iMacs, eMacs, G4 PowerBooks and G4 and G5 PowerMacs) were doing this (updated to standard 10.4.3), and found that all were doing the daily maintenance without issue. However, I asked some colleagues who have OS X Server about their logs, and two responded that they also observe that the daily periodic maintenance script ran once the morning after the 10.4.3 update and not after that. Both also have G4 XServes updated to Server 10.4.3. Another colleague running OS X Server on a G5 PowerMac is not observing this issue after updating from 10.4.2 to 10.4.3.
I can get the daily maintenance script to run manually by issuing a ‘sudo periodic daily’ line command in terminal. However, it is no longer occurring automatically on my XServe.
The weekly maintenance was run on schedule early last Saturday morning (Nov 5). However, looking at my weekly.out log today, I can see that it did not run as scheduled this morning (Nov 12). The weekly maintenance continues to run without issue on all my client Macs.
I recall that there was a general problem like this in the initial release of Tiger (that affected client as well as server Macs). However, that was fixed in the 10.4.2 update. The periodic scripts ran fine on both Server and Client Macs under 10.4.2.
So, it appears that the launchd problem (or something very similar) that existed in the early versions of Tiger, but was fixed in 10.4.2, is back again. However, it is only affecting certain setups (e.g., 10.4.3 Server on an XServe duo G4 1.33 MHz, at least three cases that I know of including mine). It doesn’t appear to be affecting any client Macs (running standard 10.4.3) or at least one G5 PowerMac running 10.4.3 Server.
I did the update to the latest version of WebObjects (5.3.1) on Saturday. This involved a reboot our XServe. As predicted, the daily maintenance script ran on Sunday morning. Surprisingly, the script also ran this morning. So, it looks like either the installation of WebObjects 5.3.1 or simply rebooting our XServe may have fixed the problem. I’ll keep my eye on the logs to confirm this.