There has been recent interest here in Mac OS X Server, its capabilities and interface. This is an extended tutorial-review that I wrote for MacUser magazine (the UK original) in 2012-13.

Apple’s Compass Swings

Apple’s early A/UX powered a privileged few Classic Macs over the period 1988-1995, but never really went commercial. Network Server (1996-7) was its first dedicated server system, sharing features with IBM’s RS/6000 and running IBM’s AIX implementation of Unix. Although much praised, it was the downmarket AppleShare IP (ASIP) file sharing software that became widely used in businesses.

Acquisition of NeXT brought a hybrid based on Mac System 8.5 and NeXTStep, the first Mac OS X Server release in 1999, before even public beta release of the client. With a better reception in corporate and educational markets than previous products, Apple launched its rack-mounted Xserve server in 2002. For a while this sold to universities and businesses, and started to fill server suites with Apple systems. Some large computer clusters, supported by Xgrid in Server 10.4, made headlines, and Server 10.6 marked the pinnacle of aspirations in these tough markets.

Recently the decline of OS X Server in traditional settings has coincided with amazing success in consumer markets. Apple pulled the plug on the Xserve, which is unlikely to have repaid its development costs, in February 2011, and five months later threw Lion Server towards the lower end of the market. Offering systems based on the ageing Mac Pro and a much more attractive dual-disk version of the Mac mini, Apple looks to have abandoned professional system administrators to filling their racks with cheaper non-Mac hardware, and aims now to create a new consumer server market.

For a decade, Server Admin has been the key application for administrators. Although accessible, Apple deemed it too complex for consumers.

One app to serve them all. In Mountain Lion, Server.app is both server and administrator rolled into one.

Apple’s Server software has, more than any other product, acted as a compass revealing its aspirations. As Apple has retreated from trying to woo the corporate market with Xserves, clusters, and heavyweight services, OS X Server has downsized to the Mac mini and humbler intent. Since it started selling Lion Server through the Mac App Store in the summer of 2011, Apple’s compass has been pointing squarely in the direction of smaller companies, workgroups, even geeky families. The consumer server has arrived.

Lion Server was something of an unfinished hybrid. It had three different interfaces in the traditional Server Admin app, Terminal’s command line for wizards, and its new and simplified Server.app, left incomplete even in 10.7.4. As with the regular version of Mountain Lion, OS X Server 2.2 – as Mountain Lion Server is officially called – continues the trend in Lion Server (OS X Server 1.0) and almost finishes the job. It is also ridiculously cheap: its cost has tumbled from £399 per Snow Leopard server to just £27.98 (including Mountain Lion itself) for all the Macs that you own.

Installation is easy provided that you have high-speed broadband and have hooked your Mac up to a display, keyboard, and mouse. Given the number of servers that run headless (without those peripherals), this will prove very inconvenient for many. However the process requires you to purchase, download, and install Mountain Lion client first, before the App Store allows you to obtain the small Server.app download. Apple claims that you can purchase Server before Mountain Lion is installed, but we could not get that to work, and had to let the full Mountain Lion upgrade complete, severing screen sharing. You could of course copy Server.app to the system that you will configure as a server (or to those you will use for remote administration), but that will only work when it is installed on a Mountain Lion system. Maybe someone will work out the precise choreography required to perform a headless server upgrade, but it is far from straightforward, and Knowledgebase article HT5390 needs to be corrected.

What you then get is a single application: OS X Server 2.2 is the Server.app application, which is also used to configure and administer it both locally and remotely. You cannot of course install or run this on older versions of OS X, but the latest release of Screen Sharing for Lion does allow you to connect to a networked Mountain Lion server, from which you can control its local copy of Server.app. You can also use Lion’s Workgroup Manager 10.7 to edit managed preferences in Open Directory, but old copies of Server Admin are dead and buried. It is just as well that Server.app is so cheap; being both the server and the admin tool you will need to install it on each server and every Mac that you want to use for remote administration.

This underlines the paradox within OS X Server 2.2: the app is both server and admin tool. Traditional server operating systems are just not built that way, although you could argue that Linux and Unix systems being used simultaneously as clients and servers live a similar double life.

Delivering what used to be a complex install in a single application is not new, though. Apple recently accomplished this with its Xcode software development kit, which used to fill its own top-level Developer folder with a labyrinth of different apps and sub-folders. Reorganising them into one application bundle makes them better suited to the App Store’s delivery model, and much cleaner for users to handle. However it also makes them more complex to customise, another strong indication that this aimed at the consumer rather than those who like to tinker.

Server.app is designed to be concise but rich in function, and sports the same interface that is does in Lion. Select in the left hand pane to manage users and groups, monitor your server, control its services, manage hardware, and control system, network and storage settings. Below that the Next Steps button provides access to help topics and useful suggestions. The main pane on the right then contains the detailed information for the function selected on the left. From its menus you can launch ancillaries, including Directory Utility to manage Directory Servers, Screen Sharing for remote management, System Image Utility to create and manage NetBoot/NetInstall/NetRestore images, and Xsan Admin if you still have an Xsan. All bar the last of these are accessible separately in the /System/Library/CoreServices folder.

Inside Server.app is a complete server file system, with conventionally-named directories such as etc, var, and usr. Those services that are specific to OS X Server are also contained within, with an abundance of remaining shell scripts, new property list files containing most service settings, but still quite a few classical config files. Apple’s trend is to use XML property lists in place of Unix text config files, which would be good news if Server.app contained a suitable editor for them. This is confounded by the fact that Xcode, which used to contain its own separate editor app, has integrated that in its current release. OS X Server also keeps service data, another spattering of property lists and more, in the /Library/Server folder; there is an option to park the latter elsewhere if you prefer.

What has gone

With aspirations for high-end markets abandoned, it is unsurprising although disappointing that Xgrid, which supported clustering and ‘farms’ of Mac servers, has gone. Unless you have been quietly building clusters of Mac minis, you will not notice, and those wanting this functionality should seek third-party solutions such as Dauger’s Pooch (daugerresearch.com/pooch/top.shtml). Podcast Producer is another casualty that is presumably being left to others to replace. As in Lion Server, there is also no print service, a feature that has fallen out of vogue in lower-end server systems.

The software firewall ipfilter (here in Tiger Server) is a more significant casualty. Whilst the vast majority of Server users will have superior firewalls in their Internet routers, this loss may require some – such as those who park their servers in the ‘DMZ’ to provide Internet services, as well as serving clients – to reconfigure their networks.

What has been hidden

Server.app has expanded its powers greatly since Lion Server, but may still not be ideal for administering users and groups. For those struggling with it, Apple has compromised in Workgroup Manager 10.8, but hidden access to it in support.apple.com/kb/DL1567. This edits records in Open and Active Directory, which are server-based, thus rooted in the classical static network model as managed preferences. Take that Mac or iOS device away and join it to a different network and it may be given completely different managed preferences. Profile Manager edits XML property lists that are configuration profiles, with the .mobileconfig extension. Those are installed on your devices, and can be controlled locally through System Preferences, letting you change profiles according to where you are and what you are doing.

Profiles can be pushed out to clients using a range of different methods, and are thoroughly decentralised. This makes them much better suited to laptops, iPhones, and iPads which may spend little time connected to the local network. Although few third-party products currently work with configuration profiles, AirWatch (www.air-watch.com/solutions/macosx), MobileIron (www.mobileiron.com/en/multi-os-management/os-x-management) and others are moving in quickly. Having the option of local managed preferences via Workgroup Manager and Open Directory, and mobile configuration profiles via Profile Manager in Server.app, is probably an ideal combination at the moment.

Apple fumbled badly with DHCP. The initial 2.0 release required you to manually enable DHCP by editing /etc/bootpd.plist, not a task that those running small or home networks would relish. This serious omission was compounded by odd interactions with Internet Sharing and NetInstall. Although the DHCP service has been opened up into its own pane in Server.app from version 2.1.1 onwards, you still cannot run DHCP and operate Internet Sharing at the same time, and merely turning on Internet Sharing wipes any existing DHCP configuration. Not that you will find these detailed in either Server’s online documentation or its Advanced Administration guide, which seem to lag updates badly, and are far below the quality and coverage you need to administer a server.

What has stayed

Mail, together with File Sharing, Profile Manager, Time Machine, and VPN, remains essentially the same in Server 2.2. This is a very facile interface to what is in fact a complex array of services, including Dovecot (providing IMAP and POP), Postfix (SMTP mail transfer agent), Amavis (virus scanner), ClamAV (another virus scanner), SpamAssassin (anti-spam filter), and Postmaster (webmail option). The Mailman mailing list manager has gone, but can be installed using instructions at http://www.livetime.com/mountain-lion-mailman-mailing-list/. Losing Server Admin’s finer-grained control over these components means that those needing more detail than that in Server.app have to access them through Terminal’s command line; the command ‘sudo serveradmin settings mail’ will reveal how extensive these are. If you can, keep to Server.app’s simple interface.

Several services have been renamed: what was called Address Book in Lion Server is now known as Contacts, and uses the CardDAV service together with LDAP information. What was called iCal is now Calendar, continuing to use Apple’s standard CalDAV service, with very little in the way of configuration or service options. However you can establish network-wide locations and resources that users can then allocate in calendars, a simple but eminently practical way of managing shared resources. Most of the real work in setting up and managing accounts is then performed by each Mountain Lion client, in the Calendar app.

Websites has also been renamed from Web, and remains based on the industry-standard Apache 2 web server, gaining an informative Python Web App demo. Whilst this ships with version 1.8.7 of Ruby, Perl remains stuck back at version 5.12.4, albeit with patches, rather than the current 5.16.2. This remains a surprising decision on Apple’s part, and because of Server 2.2’s new package architecture is very hard to rectify yourself. If you are looking to deliver content out to the Internet from your server, you may prefer to go with a server package incorporating the latest version of Perl, although fine for those accessed only within local networks.

What has moved

Among the several services that have been rescued from Server Admin and added to Server.app, FTP is probably going to be the least used. With AFP available for Macs, SMB/CIFS for Windows systems, WebDAV for iPads, and NFS for Unix/Linux, FTP is likely to be a last resort for moving files around a network. This has though been a valuable reserve when there have been problems with SMB, which have troubled some previous versions of OS X Server. Controls in Server.app are straightforward and complete.

Messages is similar to the iChat service provided previously, and uses jabber. What is slightly confusing here is that the Messages service is not the same as (iCloud) Messages on a client. When delivered by Server 2.2, the Messages service keeps a transcript, and cannot currently cross over into iCloud, but works on local and remote systems that are recognised by its jabber service. iCloud Messages do not appear in any transcripts, and work between systems that are connected to iCloud accounts, via iCloud, and independently of local jabber. It might have been better to have stuck with the original iChat name.

DNS may prove the most controversial, despite being based on the standard bind 9.8.3-P1. Professional sysadmins have been less than enthusiastic at Apple’s efforts to fit DNS management into a friendly interface. In the past settings generated in the GUI have trampled over those crafted manually, and vice versa. Although Server.app’s interface seems simple, and should normally initialise to a safe and functional default, a little patience will reveal it is quite capable of handling common setups. Most should be content with serving only systems on the local network, to ensure that other services work properly.

NetInstall includes services for starting up from a served image (NetBoot), for restoring clients to a fixed state (NetRestore), and its own for making multiple installs easier. Server.app leaves most of the hard work here to System Image Utility, the tool used to create the disk images that it serves. These have not changed a great deal since Lion Server, although Server.app does not yet seem to offer diskless NetBoot directly, for which administrators may need to follow the workaround offered by Charles Edge at krypted.com/mac-os-x-server/allow-diskless-netboot-from-the-command-line/. Once again that requires use of the command line, so may be added here in future.

Software Update promises great savings in downloads, but has not always made the administrator’s life better. Earlier implementations have been all-or-nothing: you either keep local copies of every update provided by Apple, or none at all. There is now an intermediate option that lets you choose which updates to store and provide, which could be an ideal compromise. Integration with Mountain Lion’s new reliance on the App Store for all Apple updates is managed by configuring the Software Update pane to point at your local server, which in Server 2.2 can now act as a caching service for updates to purchased apps as well as regular Apple products.

Whilst Open Directory has proved an important service in medium-size and larger networks, Apple seems to be testing the water to see how popular it will prove to the typical Server 2.2 network. Thus Server.app provides another minimalist interface that simply assigns which server does what. If you want to do anything more, you will need to turn to Directory Utility and Workgroup Manager. With the latter being steadily supplanted by configuration profiles and Profile Manager, at least for mobile devices, it may well be that Open Directory is on the decline, and will eventually be abandoned.

What has improved

Server.app has greatly improved the range of server events that it will alert you about, now including hardware problems such as changes in S.M.A.R.T. status of hard disks, detection of malware, and changes to network configuration. These can be delivered by conventional email, or pushed – the latter being ideally suited to monitoring by iPhone or iPad, and part of the general trend in Server 2.2 towards push notification. The only downside is that if you want finer control over the thresholds at which alerts are triggered, you will have to use Terminal’s command line, with a listing of the configurable options resulting from ‘sudo serveradmin settings info:notifications’.

Hardware settings in Server.app remain similar to Lion Server. However Apple claims that Server 2.2 can control port mapping in AirPort devices, but that appears true only of the most recent base stations (or maybe has yet to be enabled). Another puzzling disparity with documentation is the server setting to ‘Dedicate system resources to server services’, available in Lion Server, but missing for now. For those with Apple’s Xsan, this now merits its own entry, and chains to an app hidden within. Whilst comforting that Apple is maintaining support for Xsan, only a tiny minority of potential customers are likely to have suitable Fibre Channel storage systems. Could this support Thunderbolt disk arrays in future?

Having taken on new services, and with no alternative of Server Admin to fall back on, Server.app now provides access to an appropriately complete range of system and service logs. Logs are perhaps a dull topic, but the wise system administrator keeps a careful watch on their contents, and goes straight to them at the first signs of trouble. With its logs carefully secreted away from the eyes of Mountain Lion’s Console, which lacks any inherent facility to browse them remotely, this is an important feature to get right. Apple has.

Although unchanged from Lion Server, Server.app’s graphical presentation of three key areas in your server’s performance is excellent, allowing you to keep an eye on processor load, memory use, and network transfers. Seasoned system administrators make periodic checks on these, as they reveal performance bottlenecks and how you can address them, and can alert you to unintended activity on your network. For instance if your mail server has been subverted to relay spam, you will see unusual peaks in activity, particularly in network transfers, which should lead you to identify the problem.

Server.app’s controls over its wiki service remain clean and simple, and wikis can now store and manage user documents. This will be most useful to those supporting iOS devices, with iPads seeing each wiki as a stack, from which the user can open and save documents. QuickLook previews are also available. Users can again choose personal colour schemes, slightly over-hyped as full ‘themes’, and can create custom banners; for some these were the greatest omissions in Lion Server’s otherwise excellent wiki. Sadly an option to index content remains tucked away, only accessible from the command line, but may see the light of the GUI later.

Secure or suspect?

The only simple answer to whether Server 2.2 is secure is that it can be very secure, or could leave you as a sitting duck, depending on configuration. In principle, an application that provides services and administers them should be less secure that an operating system that separates the two functions. Applications generally run in ‘userland’ rather than somewhere more sheltered and protected, but Server.app 2.2’s services are not run as just regular applications. Similarly server resources are locked away in standard directories accessible only with root privileges, although that makes them obvious targets for the intruder.

If you are foolhardy enough to sit your system facing out to the Internet without firewall protection, then it should not be long before it is found and mutilated. Perhaps that led Apple to remove the ipfilter firewall, which was hardly suited to the innocent consumer. The pf firewall remains accessible from the command line, and alternatives such as IceFloor (www.hanynet.com/icefloor/index.html) are better than previous Server interfaces.

Otherwise Apple provides the same protection as in Mountain Lion: Gatekeeper to block malware, the application sandbox to keep userland code away from critical services, and the proven foundation of permissions and authentication. There is nothing in Server.app to encourage reckless behaviour or inadvertent errors, which may account for some the changes described here. If OS X Server 2.2 does sell strongly into consumer and small networks, it will not be long before we learn how robust it is in the face of the determined intruder.

Server.app encourages robust password policies, but as with other security measures it is up to you to determine how secure you want to be.

Conclusions

At the end of its installation, OS X Server 2.2 congratulates you. Broadly speaking, Apple merits congratulation in delivering a real, undiluted server operating system for the rest of us. Despite the 2.1.1 and 2.2 updates, a few areas need further work and above all proper documentation. But features such as the new caching App Store service show that Apple is making worthwhile progress. Another odd example of a feature still omitted from this new take on servers is the wonderful database, PostgreSQL. No doubt vendors are already lining up to fill that and other gaps, and perhaps Apple will work out how servers can integrate with iCloud.

If you are a Unix wizard looking to make your living from supporting Server 2.2, you are in for hard times. If you are a business that is looking for a server to put to work straight from the App Store and grow with your business, then it is shaping up very well indeed. Time will tell whether it sets the consumer server market on fire, but for this price it has to be the most astonishing bargain Apple has ever offered.