FireHaus Network

There are many situations where a rack mounted 1U or 3U server just doesn’t fit into the budget or specific needs of a business. Many of us Apple IT guys have been using and/or recommending the Mac mini with Mac OS X Server installed as a great way to keep within budget while still retaining full network services.In fact I have an earlier post about using Mac minis in a 24/7 environment.

So Apple finally made it official a few weeks ago an now has a Mac mini server. It fits the bill for many business uses, creative uses, as well as even for a simple home network server.

In fact one business makes it their business to use Mac minis almost exclusively as their servers, providing web hosting and other services to their customers.

I received a brand new Apple Xserve a couple of days ago and I took it out of the box and got it ready for testing. I expect a new server to have some usage on it as part of quality control testing but I guess I just never noticed how much usage is on a new server (at least one from Apple).

13.34 hours of which I can account for only 25 to 30 minutes.

Mostly I find it interesting, assuming this usage is typical, that Apple has the time, both in the factory and in the facility in the US where Xserve orders are put together, to run a machine for 12 hours before shipping it. Even a self-proclaimed IT Guru still learns something new everyday.

I have been running a default setup of Apple’s Mac OS X Server as a mail and mailing list server since early March and it has been working well except for some non-critical glitches. The firm I support runs only Mac OS X Server on both Apple Xserve’s as well as on other non-server hardware (Mac Pros and minis).

I found that the Mailman system which is modified by Apple seemed to not be generating any log files. Upon closer inspection I found that the Mailman system was creating logs they were just not where Apple’s server OS was expecting them.

At this point in time I don’t know if this is due to a glitch during the original installation of if this is just the way Apple set it up. Since I have found a few other people with this or a very similar issue I suspect it’s a glitch in Apple’s set up.

I found that the Apple default configs are expecting the logs to be written to

/var/logs/mailman/

but the Mailman* system is configured to write them to

/var/mailman/logs/

I was concerned that a future update/upgrade from Apple might break the logging if I went and changed the Mailman config so instead I set up a symlink for /var/logs/mailman pointing to /var/mailman/logs and this seems to work both from the GUI or the CL. This almost seems like a typo on Apple’s part.

Just thought this might be useful to anyone supporting Apple servers.

* This is not the default Mailman location but Apple’s modified Mailman location

Back in late November I tried to get iCal Server running on some older hardware and this is what happened…

I ran iCal Server + iCal in a test environment on a older Xserve–Dual G4 1GHz 2GB RAM Mac OS X Server 10.5.5–in this test environment with only a couple of test users and I noticed a significant increase in CPU activity due to iCal but it seemed that it wasn’t something the server couldn’t handle. A month later when I rolled out the service to 60+ users the server was brought to its knees. It ramped up to 100% CPU usage as more users logged in and by about 11AM that business day it ceased to be functional. Anyone trying to connect timed out before they received updates.

I have not been able to track down any specifics as far as something I can “fix” to prevent this problem as my iCal Server install is Apple default and other than running the CPU load at 100% there was not a single error reported/logged. I’m going to use brute force to work around the issue but I would like to find a better approach.

I am going to try to roll out this service again but hosted on a brand new Xserve 3.0GHz Quad-Core Intel Xeon 16GB RAM (I’m lucky in that I work for a bunch of lawyers).

Now two months later I think I have finally got it working…

Read more