I was recently asked to defend my decision to run OS X Client on my Xserve and I thought others might like to know why as well.
- Changing the IP. I have written about this before. I have a mission critical web server. I want to upgrade the OS or the hardware, so for maximum up time, I configure my new server with a temporary IP, then when everything is ready and tested, I shutdown the mission critical server, change the IP on the new server, and everything and everyone is happy. Less than a minute of downtime. I am sure OS X Server is nice for people who do not have mission critical servers, but look in the mac-osx-server listserv archives, and you will see changing the IP is not as easy as Apple would like to think. (No, not even the changeip command works correctly. How am I supposed to upgrade any hardware or software when I need to test it first before I put it in production when I cannot use a temporary IP? I have tried changing the IP in Mac OS X Server 10, 10.1, 10.2, and 10.3 without success. Come on.
- Industrial Strength Web Serving. (also known as web service without a smile) After reading Apache, The Definitive Guide, I had to wonder if Apple had ever heard of it. Apache is great, but the configuration on Mac OS X Server was a mess. (Mac OS X Server 10.3 made great strides to clean it up, but it still left more to desire).
- Industrial Strength Performance Cache. Apple includes something called a “performance cache” but if you use the performance cache, it breaks some auth directives. (the ability to allow or deny by IP) Why would I ever need to do that for an intranet web site? I could live without the performance cache, but if you advertise something, and that you follow standards, don’t tell me I have to choose between the hyped up performance cache and Apache standards.
- SSL certificates. Apple has a great GUI for adding SSL certificates, I will give them that, but please…why can I not change the file name of the SSL certificates, private key, etc without changing the SSL file names in every single vhost file…especially when 9/10 sites do not even use SSL? Yes, all the SSL directives are in each vhost conf file even though they do not use SSL. So I am telling you, if you decide to name your SSL cert file something other than what Apple has programmed (and Apple gives you an option to save the SSL cert anywhere) that Apache will not start because of syntax errors in each vhost conf? Yes. Should I be mad? Yes, I think so.
- ErrorDocument. If you are like me, I have a script that depending on the error, an error specific page is created to let the users know exactly what the problem is. Slick, yes. Works in Mac OS X Server? No. What, but being able to define multiple error documents is very common and supported in Apache’s generic config. In the Server Admin GUI, Apple only put one field: Error Page. Perhaps that is acceptable for little web sites or for people who do nt care to differentiate errors to users, but I need it. I thought this would be easy, just add in the lines: ErrorDocument 404 error.php?404, ErrorDocument 500 error.php?500, etc right in the conf file that Server Admin creates for each vhost. Well, one slight change in the GUI to something completely unrelated (I changed the frequency of my log rolling) and my four or five ErrorDocument lines in the conf disappeared. What? My solution? Create another conf file that had the ErrorDocument directves in them for each site. Not acceptable. How many conf files must I have? A work around for a work around for a work around. This did not make me happy, especially when I went to the Apache Con 2003 and one of the speakers warned about performance hits when using multiple conf files.
- Firewall GUI. What was not worthy of my complaints in Mac OS X Server 10.0-10.2 is worthy of a complaint in Mac OS X Server 10.3. There are many preset options to configure…the standard port 80 and 443 for web, port 22 for ssh, etc, but wow, try creating a rule for something like Retrospect (and why Retrospect was not included but Timbuktu was…). The ease of use really went south in Mac OS X Server 10.3. The old Firewall GUI was much easier to use. On principle, I have to complain about this because Apple should be trying to simply GUIs, not making them more complicated. (in my opinion) The Firewall GUI does not make me extremely upset like the web serving woes, but it adds to the fire.
In conclusion, the Xserve, is a really great piece of hardware and I am really excited about it, but the operating system that Apple has chosen to put on it and call “Industrial Strength” is not industrial strength for my mission critcal servers. If I have to give up my ability to use hwmond and watchdog (which I almost have working) I will. I have never had a rack mounted server with SMART drives, and fancy notification abilities so I will live. I am tired of hearing “but it is fixed in the next update” because I have wasted so much time reinstalling the next version of Mac OS X Server only to find other major errors which just create work arounds. I like Mac OS X Client as my web serving OS because Apple has left the conf files alone. No GUIs to mess with them. All my Apache directives work, and I can change my IP on the fly. I have sent Apple feedback, but as you can see, I am using Mac OS X Client on my Xserve for my web serving needs.
