Hello. We no longer have a Facebook page.

I hated Facebook from the get-go.

Sure, everyone else was using it, and as my Mom was always keen to point out, I may be the kind of person who'd jump off a bridge just because all the other kids were doing it. This, she'd remark, was the sign of a mind unfit for the world at large, but I always harbored the suspicion that there were potential flaws in her argument. After all, what was over the side of the bridge? If it was a matter of plummeting to one's death upon cruel, jagged rocks then I'd be prepared to give her that one, but what - for example - if it was puppies?

So when we fired up Command Prompt we did the whole Facebook/Twitter thing because that was a Thing You Had To Do As A Small Business. And then we never really did anything with Facebook again.

Now, I'm not saying that Facebook is bad per se - I mean, I get that it's valuable for some people. In fact, it's practically become the new AOL in the sense that for some people Facebook is the internet. For a lot of people it's the default way of sharing stories and information about themselves and the causes and issues they're passionate about, and that's great. Unfortunately, there are many other things about it that are... not so great.

This is the point where I should talk about Cambridge Analytica and the current kerfuffle about privacy, rights, and shady practices whereby data we'd all supposed was safe and anonymous was in fact strewn all over the place and commoditized. Yes, this is all shameful, but no, I'm not really surprised. The old adage that if you're using something free on the internet then you're the thing that's for sale applies, and there's little to be gained about piling more... whatever it is you pile on bandwagons. Bands? Let's say bands.

No; that's all ground that's been trodden before by better writers and wiser minds, so I'm going to cast my net wider with what I like to call David Ball's Social Media Maxim. It's a philosophy that I've honed over countless years of careful scrutiny and rigorous academic study, and I think I can defend it against any assault. Here it is in a nutshell:

Social Media Is Bullshit.

Really, it's the worst. While it can be invaluable as a resource for activating and starting movements and fomenting positive things in the world, it's equally (if not more prevalently) a source of bigotry and pettiness; by turning every device into a bully pulpit and giving every pissant an anthill to piss off of it's done little to justify itself as a positive force to promote anything. Seth and I have a saying we're fond of in application to shoddy IT solutions that applies equally well here: "A terrible idea done very badly".

Also? Social media is dying. The demographics are interesting; the current crop of new teenagers are ignoring Facebook and largely eschewing Instagram and Snapchat in favor of other, more traditional analogs. Discord and Slack are chewing up that group while Facebook is rapidly becoming the province of their grandparents. Like, come to think of it, AOL.

So, goodbye Command Prompt Facebook account. We hardly knew ye.

Migrating DNS from macOS Server

Great guide on how to do this from Apple, available here.

In short, it's a pretty simple process. BIND has been the DNS source of choice for macOS for a long time now, and it's a moderately simple process to download the latest build, do the standard ./configure nonsense, create a launchd .plist to fire the thing up on boot, and then configure/edit the zone files found in /Library/Server/named.

Bonus? It's actually a little easier to work with. One of the things that would make me bash my head against a wall was macOS Server's occasional behavior of hanging, or falsely reporting that changes had/hadn't been made. With BIND you make your changes to /Library/Server/named/named.conf then just sudo killall -HUP to reload the service and use the changes instantaneously. It's a trifle more work on the config side, but a boon for reliability...


Sort of.

High Sierra and the latest Server.app saw the removal of File Sharing from the stable of goodies that OS X Server had at its disposal, and there's no getting around the fact that this caused a lot of people in my line of work a lot of... discomfort. Okay, maybe discomfort isn't the word I'm looking for; it was more like this:



Exactly, Liam Neeson. Why?

File Sharing was something that OS X Server did. It was something that it was good at. Reliable. Solid. Secure. Dependable. A large part of the reason why people shelled out good money for nice servers and backups and quality storage. The years rolled by and changes came and went, but File Sharing was always there, always a constant. And now it was gone.

Well, not really. macOS has always been good about sharing and generally playing nice with other people, and one of the reasons that File Sharing was a thing at all was because essentially it was built into the OS and not just into the Server product. Sure, there were more tools available if you had the Server.app, but you could always duck into the Sharing prefpane on clients, check a few boxes and presto, you were sharing files (albeit in a basic way). That's still there, although now with some extra tricks up its sleeve (which is welcome), but it's moved out of the Server.app to get there (which isn't).

It annoys me, but on the other hand it's not much of an inconvenience. In the old Server.app you'd configure the shares you wanted to make in the File Sharing portion of Server and then - often as not - noodle on over to the Storage tab in the Server.app to tweak and fine tune, so in a very real sense you're still likely to want to go to two different places to set up and tweak your shares, so really all is well. 

Except that the Sharing prefpane is awful. It takes an eternity to make a share, longer to delete on, and if you want to use FTP or WebDAV then you might as well turn off your computer, open a window, take a deep breath of cleansing spring air, and then throw yourself out of it. Okay, that might be going a little far - particularly as there are solutions to cure a lot of those problems.

The first - and biggest - problem out of the gate is setting up shares. It is often abysmally slow, but thanks to the sharing command you can do a lot of the work very quickly and simply from the command line. It's super-simple - give the sharing command a protocol to work with (AFP, SMB and... wait for it... FTP), a path and a share name and you're off to the races. For example:

sharing -a /Volumes/MyServer/Shared\ Items/ -A My_New_AFP_Share

sharing -a /Volumes/MyServer/Shared\ Items/ -S My_New_SMB_Share

sharing -a /Volumes/MyServer/Shared\ Items/ -F My_New_FTP_Share

You can then tweak users, groups and permissions as needed through the Storage tab in the Server.app

Fixing WebDAV is a little trickier, and it's worth checking that your DNS/hostname setup are in good working order before going forward. Assuming that they are, then you can fire up the wfsctl command thus:

wfsctl start

...and add a share simply by feeding the command a path, like so:

wfsctl share /Volumes/MyServer/Shared\ Items My_WebDAV_Share

The real sin here is that there was - at least as far as I can see - no tangible reason for Apple to pull this functionality out of OS X Server. Sure, FTP and its assorted permutations are pretty dusty, but now and again you run into a circumstance that makes them suddenly very important. WebDAV is even more puzzling; as something that was a value-add to Apple's push to get iOS into the workplace it did stalwart service, and its sudden and unheralded removal from the Server.app has been a cause of head-scratching consternation. We can only hope that the new and improved Server product they've hinted at this Spring will cure some of what ails...

Saying Goodbye to the OS X Server Mail Service

Of all the services hosted by OS X Server that are apparently going away, none fills me with greater joy on the occasion of its demise than the Mail service. I mean, it was fine if you liked that sort of thing. If you liked your email basic IMAP and POP and you liked it flexible but slow, and if you enjoyed the delightful frisson of high-wire horror whenever hardware failure knocked a server out and rendered an enormous client dead in the water then this was your cup of tea.

Seth and I could probably sit down and talk for upwards of an hour solid about the nightmares this misbegotten monstrosity has foisted on us over the years. The time that we went in after hours on a Friday night to set up a server, and the brand spanking new mail server RAID died two hours into it's short life and turned the plan of being home by 9pm into being home at 4am. The time that a weird postfix error ate every user account the day before the company was due to present their multi-million dollar proposal to the Department of Agriculture. Its propensity of greylisting emails on the basis that timely communication was an aberration, or at least an amusing foible. I can feel my arteries scarring just writing these words.

Thankfully, hosted Exchange and Gsuite have quietly gone from strength to strength and recent release of iOS and macOS client have essentially become transparent platforms for those services, and most organizations have moved away from hosting mail internally to the point that the ones that do are anachronisms. Still, there are a few out there. Lurking.

But no more. On the off-chance that you are one of those holdouts (and if you are you should feel nothing but deep, abiding shame) or ever have to deal with one then you'll need a way to migrate those accounts to something new pretty sharpish. Enter imapsync - which you can download and install from the package manager of your choice. I like Homebrew, so if you don't have that on your Mac already then you can download it from http://brew.sh or just paste the following into the Terminal:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Once that's installed, type the following into the Terminal:

brew install imapsync

...then sit back and wait a minute or two for it to install.

Once that's installed you'll need to figure out the mail domains and the accounts on the server. Luckily - if you've installed the Server.app on that Mac - you'll be able to use the serveradmin tool to figure that out for you thus:

sudo serveradmin settings mail:postfix:domains:_array_index:

Digging out the accounts is pretty straightforward too - just take a look at the virtual_users file here:

cat /Library/Server/Mail/Config/postfix/virtual_users

The next part can get a little tricky - particularly if you're moving domains - and requires establishing a good time to cut over mail to the new host. Change the MX records for the domain (let's call it madeupname.com) over to point mail to the new server then use imapsync to push the old mail to the new account thus:

imapsync --host1 oldmail.madeupname.com --user1 dave_ball --password1 myoldemailpassword --host2 newhostedmail.madeupname.com --user2 dave_ball --password2 mynewemail password

This can take a long time. If you have a lot of accounts then it's worth exploring importing mail directly (both Gsuite and Exchange have assorted ways to accomplish that), but if you're just dealing with a small number of accounts then imapsync is pretty simple and easy.


Changes to macOS Server

macOS Server has - for the past few years - increasingly become the least-favored child in the Apple lineup. In the last half-dozen or so releases Mac admins have seen the finer points of granular control over services and users stripped away. We gnashed our teeth when they took Server Admin and Workgroup Manager from our cold, dead hands, and screamed defiantly at the angry, stormy night when other services became deprecated or disappeared completely (I'm looking at you, FTP and WebDAV).

And now, to add insult to injury, Apple blithely announced that they're removing the following from Server.app: Calendar, Contacts, DHCP, DNS, Mail, Messages, NetInstall, VPN, Websites and Wiki. And I couldn't be happier.

Let's face it; OS X Server has - for the great bulk of users and admins (and for a long time) - been kind of a relic. Sure, if you jump in your Time Machine (and incidentally, the Time Machine service has also been dumped in its most meaningful sense) back a decade or so then it seemed like a very good idea to be hosting your own email, websites and collaborative services on your own server. External web hosting was a thing, but if you polled businesses and organizations then a decent chunk of them hosted their own email rather than negotiate with (usually dreadful and restrictive) email hosts, and hosted their own contacts and calendars simply because there was no other option.

Network-centric services (DNS, DHCP, VPN) were handy to have too; the appeal of having your own dedicated toolbox was compelling once you considered that you were hosting your own mail, web, and contacts - if only because OS X Server made those things easy and quick to configure. In a world where you often had to make a phone call and sit on hold for twenty minutes in order to dictate a DNS entry to the nice lady at your ISP, this was a critical advantage. (Side note: the nice lady I'm thinking of was Kristin at SeaNet. I had to call her so often that we ended up trading Christmas cards for a couple of years.)

But it's the nature of things that they change, and almost everything on that list of disappearing services is hopelessly underpowered and outdated, and easily available in a better form in the cloud. Mail/Contacts/Calendar? Hello, Gsuite. DHCP/DNS/VPN? Lots of inexpensive and good quality routers and appliances out there. Messages? Slack, or Discord. Some people will mourn the passage of Wikis, but let's face it - Wiki Server was never exactly what you'd call full-featured or easily/fully customizable, and there are third party options if you really need to go that route.


So, what does that leave? Pretty much just Profile managements, file sharing and Open Directory. Apple has doubled down hard on iOS and profile management, and it's a move that is either puzzling or has yet to pay off. Sure, the Device Enrollment Program is super neat (after all there's nothing quite like having your devices set up automatically the moment you take them out of the box), but for ongoing management third party solutions like Jamf do a better job and offer cross platform options to boot. File Sharing has been rolled into the client OS, and I get that - it's a fairly simple thing to set up and being able to set up your Mac to share files dates all the way back to the System 6/7 days - but there's still value in being able to do granular configuration from the command line or the Server.app.

All in all then? There's a lot of smoke but very little fire in this new position. Open Directory is still an incredibly flexible and powerful way of handling authentication and services on a Mac network and there are excellent third party solutions that you can bolt into macOS server that are as good (or in many cases better) than the aging built in ones.  There's already a certain amount of vitriol being bandied about the Mac admin community about this upcoming change, but IT admin is a constantly changing pursuit; sometimes you have to throw away your old tools if they don't work and just learn to use new ones that do.

SSL, TLS and Alarmism.

Excerpt from an email I received this morning from Harbortouch, entitled "POS Systems Are Now Useless":

"Considerable changes are being made to PCI requirements in order to address a vulnerability with SSL encryption called POODLE. In short, SSL encryption, which has been the standard encryption method for decades, is no longer PCI compliant due to vulnerabilities in this protocol."

Ugh. The one thing more damaging to security than a breach is the perception of a breach. Now while that might seem a naive way of thinking about it, I'll make arguments to my dying day that it is, nonetheless, accurate. Fear-mongering in IT (where the stakes are often high) is a fast way to make a buck out of folks who are bent on staving off incursions. It's akin to yelling "Fire" in a crowded movie house and then trying to sell people buckets of water on their way out to the lobby. Yes, breaches happen from time to time and nobody is downplaying that or saying that they're a good thing, but nothing good ever comes of spamming out something designed to deliberately misinform and panic both vendors and end users.

Here's the real scoop. SSLv.2 & 3 and early versions of TLS (SSL's successor) are vulnerable to POODLE. This issue was discovered in 2015 and most reputable POS vendors looked at it, upgraded to TLS 1.2, and never looked back. End of story. But wait; there's more:

"SSL has been the standard encryption protocol for decades, so virtually every POS system older than a few months will likely require a costly security upgrade no later than June 2018 (with some deadlines as soon as this summer) or face a complete shutdown of credit card processing capabilities."

Yes, SSL has been the standard protocol since the mid-nineties, but the versions that are vulnerable to POODLE have been largely deprecated. They were outdated in 2015, and even further back responsible folks in the IT field were moving away from SSL and toward TLS 1.2. None of this is in anyway new news. The PCI bit is true as far as it goes; a few years ago PCI 3.1 was subsetted, with PCI 3.2 rolling up in June of 2018, but there's no "costly upgrade" involved at all; your POS vendor will simply implement TLS 1.2, which is functionally interchangeable with the older SSL technology. They both use certificates, and you don't need new or special certificates to use TLS.

Here's the most telling bit: "That means that this is the time for you to go on the offensive and capture more business!"

Pft. And there we have it, ladies and gentlemen. It never hurts to stay up-to-date with your PCI/security obligations, but it never hurts to take this kind of thing with an ounce of investigation and a liberal pinch of salt...




Hi. This is Dave. Pleasedtameetcha.


I'm spending a lot more time doing behind the scenes, big-picture IT these days, and it's an odd change of pace compared to the more traditional, I'll-jump-in-the-car-and-fix-things approach. Not a bad change of pace, but an odd one. I seem to spend less time frowning at things while onsite with clients and a lot more time frowning at things remotely on a little screen, which is fundamentally the same experience with the notable exception that I can use saltier oaths now and mutter more.


A big part of what I'm doing could be categorized as future-proofing. It's an interesting time in the whole macOS/iOS ecosystem, and while the changes at foot aren't entirely sea changes they're nonetheless significant ones of a degree not dissimilar to the move from classic MacOS to Mac OS X. iOS 11 has peeked over the horizon and is approaching rapidly, and while High Sierra isn't on the surface a massive upgrade over Sierra there's a lot of stuff going on there that makes it prospectively challenging.


I like the look of iOS 11. I've always maintained that there's a clarity in reduction - doing less with more. I use a 2015 MacBook as my main computer because it's the smallest laptop I could get with a decent screen and battery life, and because I don't mind just having the one USB-C port. Hell, if I could get by with just using my iPhone as my work machine then I'd go with that, but failing that option I've always thought that an iPad would be an excellent laptop replacement.


Except that iOS, well, sucks. Okay, that's not fair: iOS is great for what it does, but my frustration with it is that it's historically walked right up to the line of being a true replacement for a work laptop and just sort of stopped there, toes on the edge, looking over into the abyss with a diffident expression. The approach of sandboxing each app is outstanding from a mobility and security point of view, but I hated the fact that you couldn't make elements from different apps interact (well, that and the lack of a native shell - but that's rather a lot to hope for and I've given up on that). I watched the WWDC keynote just like everyone else, saw what they'd done with the Files app and the *very* macOS-like dock, and then looked at my laptop as if it were some old, incontinent-yet-faithful dog. Maybe I could lose a pound out of my work bag, vastly increase battery life, and put Old Yeller out to chase rabbits. Which is how the book ends in my world.


But the really interesting thing to come out of WWDC was APFS. I'm playing around with it now and there's a lot to dig into; this is the first shift to a fundamentally new file system since 1998 brought us HFS+ and yes, that's nineteen years ago which makes me feel very old. It's in some ways a product indicative of where Apple is right now, and that's kind of interesting.

Back when the Mac first hove into view in 1984 it ran on the creatively named Macintosh File System (MFS), which was functional but limited enough that it was replaced with Hierarchical File System (HFS) a year or so later. HFS was a media-based upgrade over MFS in that MFS was designed to work great when you were running it from a floppy but didn't scale to larger storage like hard drives. Apple intelligently enough came up with a system of replacing the flat catalog of what-file-is-where (which worked well when you were dealing with a small storage device) with the vastly more effective approach of using a B-tree  structure to allow the fast storage and retrieval of file location data, making it massively easier to search files on a larger drive.

In the same mold, HFS+ was largely in response to increased data storage sizes. When HFS was put into commission it would work with the unimaginably vast amounts of storage offered by a twenty-megabyte external SCSI drive, but when you scaled up to volumes in the multiple-gigabyte range then it became almost untenably slow and the approach of having files occupy a logical block meant that even very tiny files could use up a disproportionate amount of space. HFS+ tore that all down by replacing those logical blocks with much smaller 32-bit sectors, as well as increasing the amount of characters you could name a file and offering support to an exponential degree. Later on we got Journaling tacked on top, and all was right with the world.

So, why move to APFS? Lots of small reasons and a few big ones. Based on the reading and poking around with the thing I think they can be reasonably divided up via the magic of bullet points.

• It's a media-driven update. Now that almost all (if not all) Desktop and Laptop Macs come from the factory with some kind of Flash/SSD/Fusion Drive bolted inside, it makes sense to accommodate that by replacing HFS+ with something that can accommodate the specifics of that new technology. APFS supports the TRIM command right out of the box, and it's approach of writing changes to files as opposed to physically copying files leverages the speed of the newer, non-rotational-disk technology to deliver a lot of speed and security.

• Getting Fusion Drives to work in prior versions of macOS was something handled by CoreStorage. HFS+ had no idea what the heck a Fusion Drive was, so CoreStorage stepped in to make it all nice; but now APFS understands all about Fusion Drives. This is a good thing, but I wonder how that will effect the old break-the-fusion-drive-to-get-two-mirrorable-devices trick. Time will tell.

• Time Machine is great in theory but in practice slow and beastly. Not that there's anything fundamentally wrong with Time Machine itself; rather that the process of writing out vast amounts of data and keeping track of the versioning and snapshots put a lot of overhead on a system - overhead that APFS will *drastically* reduce.

• APFS volumes will be shareable on a network via SMB and NFS. AFP over TCP is done, period. It's due for retirement, and I hope it gets a gold watch and a hearty handshake and enjoys its twilight years. It's earned it. Of course, that now means that if you're implementing a new Mac Server then you should probably give a lot of careful thought about your client machines and what OS they should be running; doubling down on SMB is great, but history has shown that differences in the implementation of the SMB stack between client and server machines has occasionally proven problematic - which is a nice way of saying that it can be slow and broken and hateful.


Those are (so far) my major takeaways from APFS. It's an update that I think is likely to change a lot of important professional/prosumer system designs in a lot of unglamorous but pretty essential ways - but it's way overdue and absolutely worth embracing...