Then we got AWS.
While AWS works really well once itās all set up, getting it to that point is often cumbersome. There are gaps in the documentation. Web Console servicable, but has a ton of glaring UX issues. Iāve never had a stronger love/hate relationship with any person, place or thing than I have with AWS. The other developer I work with tells me that he's happy that I handle this end of things.
All of this came to mind about two months ago while I was pulling my beard hair out while working on getting AWS Code Deploy set up for deploys to an on-premises server from a completely new AWS network. I wondered, What if AWS Web Console was more like the old macOS X Server Server Admin tool?
I used to love clicking through Server Admin and looking at the services and options. It was so quick, clear and concise, it practically guided you through setting up some tough infrastructure.
What Wasā¦
For those of you who donāt remember, Server Admin was an application that came with macOS X Server. It allowed an actual server administrator to configure the services bundled with the OS using a GUI interface. No one had done anything before like what Apple did with Server Admin, Workgroup Manager and the rest. UNIX and UNIX-like OSes make for great server OSes, but usually the services are configured by hand using the CLI or by editing config files scattered all over the system.
Server Admin wrapped the configuration options and configuration files in a shiny Aqua interface. For some reason, this was always inspiring to me. The macOS X Server utilities might be my favorite platformers of that era of the Mac.
In 2010, Apple announced the end of the Xserve line of hardware which left the future of the macOS X Server software uncertain. Apple's PR department was silent (which was pretty usual, but also kind of abnormal given the gravity of this decision).
Concerned customers emailed Steve Jobs
Drastic changes came a few months later.
Instead of packaging the Server software up as an individual server OS as they had been doing, Apple decided instead to app-ify the solution and ship Server.app on the Mac App Store. Server.app could be installed right on top of the consumer OS. Priced at $50, any hobbyist (yours truly) in addition to enterprise pros, could download a new Server Admin-like application. The installer also added extra services and components to the base macOS X software.
It did not go over well. Server.app was buggy, as were some of the services it ran. The professional enterprise crowd (many of whom were die-hard Apple fans) got the message and started to begrudgingly migrate to Windows Server and Linux. Even so, Server.app hung around until 2018 when the app was gutted of all of its services outside of identity services (Open Directory and Profiles).
- macOS Server deprecating loads of features in upcoming update as focus changes - 9to5Mac
- Changes introduced in macOS Server 5.7.1 - Apple
With it, the end of an era.
What Isā¦
Well, here we are. Itās almost 2020. macOS X Server is dead and gone as far as most are concerned. AWS and Azure and a trillion VC-funded consumer cloud services are here and no one likes to host their own servers anymore. And yet I still canāt help but remember how cool macOS X Server used to be, especially in my darkest moments of trying to orchestrate stuff on AWS. I still wonder what it would be like if macOS X Server had made the leap into the modern world.
Over the course of the last month or so, I have recreated Server Admin as a web application. You can visit it and click through it right in your browser.
Without further ado:
https://www.classicmacfinder.com/server-admin/
Itās important to note that this web application does not configure any services on the server itās hosted onā¦ or any server anywhere. At this point, itās no further along than as demo-ware.
There is also some unfinished/rough edges. For example, table views arenāt included in the web framework I selected (more on this in a minute), so I need to figure out how Iām going to implement those. For now, youāll see just empty white boxes. Iām super excited to make this project public anyway.
How did I do this?
First, I sourced a copy of macOS X Server. I found a copy of 10.3 Server on eBay for < $50 shipped. Unlimited client license and never even opened. (If you do this yourself, check to make sure the software will ship with the serial key.)
Second, I source hardware. I needed hardware old enough, but competent enough to run 10.3 Server, so I checked my favorite site, shopgoodwill.com. I found and bought a 466 MHz PowerMac G4 Digital Audio box for about $30. I drove into New York/Queens to pick it up myself as shipping was going to be crazy. Although I did this on the Friday of Labor Day weekend and trying to get out of the city afterward was also crazy. It took me over three hours to travel 30 miles.
I installed the 10.3 Server and got everything up and running, though not without some trials, due to a bum optical drive.
I spent some time clicking through the OS and through the Server Admin application and thought _'Woah, is this software primitive!'
As cool as it was back in the day, I can now see glaring UI/UX issues that I never noticed when 10.3 was new. It would be difficult to go back to this, even though it is much prettier than current macOS.
I also found the whole suite to be very well organized. Even if primitive, this is some of the best of Apple of that time. If any of the engineers and designers and PMs who worked on this app ever see this, hats off to you all!
Third, I chose a web framework to do this in. With everything that's going on in the native frameworks today, I didn't want to end up with a project that wouldn't compile in ten months. I thought about React, I thought about Vue. I considered Ember. Then I remembered SproutCore and Cappucino, both of which have UI controls/widgets built-in.
SproutCore is a 2008-2010 era web framework that Apple uses for its MobileMe/iCloud web applications. SproutCore is a front-end framework for creating SPA (single page application) web apps. Itās written primarily in JavaScript and provides a good number of UI controls/widgets that you simply instantiate and place in views. It also brings bindings and state charts to control the flow of the application.
I was torn then between these two. But really, it was a pretty simple decision to make in the end. I wrote my Server Admin re-write using SproutCore.
While Cappuccino has all of this great stuff in it, the demo page seems like many of the controls are broken and laggy. SproutCore seems like itās less broken today, and the fact that it also uses more standard web languages and markup makes it a little safer going into the future. Plus Apple themselves is still using SproutCore (likely a heavily modified and better maintained internal fork, though).
Working with SproutCore was challenging at first. The learning curve is kind of high and the documentation is outdated and missing some pieces, though it all still works. It took me a few weeks to really get the handle of how it works as a framework. Though once I did, I was off. It was beyond easy and so productive to work with once you have a handle on the idioms and patterns. Itās kind of beautiful, actually.
Hereās this outdated framework thatās considered laughably passĆØ by likely almost all web developers today, but honestly I like it. Iād absolutely use it for another project.
What Could Beā¦
I'm sure some are wondering if I would ever make this web version of Server Admin actually functional. Iām considering it, but to do it right is a tall order. It'd sure be a lot more fun to work with than AWS Web Console or the Azure control panel (though admittedly, Server Admin is focused on maintaining servers and not clouds)ā¦ or CPanel, heaven forbid you are still having to use THAT hot mess.
Finally
So yes, this web app does not do anything. But keep in mind that really what Iām trying to do here is reminisce over one of my favorite Mac OS X apps. Hopefully there are some who like to click through and reminisce over how cool Mac OS X Server was too.