Apple Server: Your one stop shop for....user management and backups?

I'm still trying to figure this one out. Apple is now saying that they're going to remove the services like DHCP, DNS, Mail, Contacts, Calendar, VPN, and Websites. First they are hiding them, then they are removing them outright at a later date. I find myself wondering exactly why. They aren't developing most of these services themselves, websites are apache, mail is a postfix base, DNS is running the bind daemon in the background. The is a nice control front-end to these things and handles a lot of the nasty configs that people don't want to fool with. For a small business that has NO idea what they're doing, it's perfect. Grab a Mac, grab the app, google a little bit about firewalls, and boom you're in business. It feels more and more like the power-user market is being left father afield each time an update is brought about. I wonder what the point of having a Mac server will be at that point though, you won't be able to install an imaged OS on networked Macs from it anymore, you won't be able to offer many of the controlling services (DHCP, DNS) that those machines would need, and machine management was supposed to happen through Remote Desktop and Profile Manager . This gives you an OpenDirectory box, with app caching for the App Store installs, and centralized backups. I suppose a central user management service has its uses, but frankly if you're at that point then I would expect you to need some of those other services and whatever box is doing that can also take on LDAP. It seems like an odd move since for limited effort the company can keep solid ecosystems of Apple products in businesses. A few Mac minis or pros for the servers, iMacs/books for the users, iOS devices for the field. Companies pay big money for seamless interaction with their equipment, it equates into less downtime and more savings. "But you can just install these services back on the Mac…" Eh, you can, but it's more hassle than grabbing a cheaper box, throwing linux on it and tossing the packages in place. Or worse, outsourcing all of your needs to a SaaS. The subscription model is hard on smaller shops. Many of these packages require some kind of separate wrapper piece to install and there's no guarantee that it's the latest version. Instructions for updating and managing them are non-existent to not useful. I understand that not a lot of large companies have Macs in any kind of server role, but then, they also don't use any of the "advanced' services that Apple is keeping. Frankly If they are going to kill it because it's too hard and no one is using it then they should just kill it. Drop server, drop the management stuff that they're keeping (because I can assure you, if there are things that no one uses, it's the stuff that is being left in), dump the Mac mini and call it a day. Apple is trying to let admins down gently by slowly pissing them off. Brilliant.

Hosting Multiple Instances of Rocket.Chat

When setting up Rocket Chat for a site running Ubuntu I ran across an interesting problem. The default method for running the service from 16.04+ is to use a Snap. This amounts to basically a docker component, or for the uninitiated a self-contained application. It's a nice setup, you install the snap management service and then install rocket chat from that, it automatically self-updates periodically and you're pretty much hands-free. The issue comes when you need to run multiple rocket chat services for different domains as they did. There is no easy way to get the snap service to fork into multiple running instances. What's worse is the database and everything else is contained within the walled garden of the snap. So I did what any self-respecting admin did: I read 2 pages of the manual, got frustrated with it, tossed it out, googled "multiple snap instances", got nothing useful, and then had a drink. When I returned to the actual problem it occurred to me that I only needed to find out how to activate the service normally from a non-snap environment and then explicitly reference each of those elements from within the snap. From there it became rather easy. The service uses a mongo database to store everything so I needed to copy that as well. Here are the step-by-step instructions to accomplish this if you feel the need:

Log into MongoDB and copy parties database to another new database
You will need to be within the Snap
#>cd /snap/rocketchat-server/current/bin
#>sudo ./mongo

Now copy the database
db.copyDatabase("parties", "parties2", “")

This will take a second, wait for the prompt to come back. I swear, I thought it locked up or I forgot a semi-colon. Once that’s done do an “exit”.

Ok, so you have your data ready for a new instance.

Head to your home directory and make a new bash script to start the thing up:
#>Cd ~
#>Nano startRocket

export DEPLOY_METHOD=snap
export NODE_ENV=production
export BABEL_CACHE_DIR=/tmp
export ROOT_URL=
export PORT=3001
export MONGO_URL=mongodb://localhost:27017/parties2
export MONGO_OPLOG_URL=mongodb://localhost:27017/local
export Accounts_AvatarStorePath=/var/snap/rocketchat-server/common/uploads2

/snap/rocketchat-server/current/bin/node /snap/rocketchat-server/current/main.js

This does the heavy lifting. If you’re doing more than two, you can keep doing this process, just make sure you update the first mongodb line, root url, the port, and the avatar path.

Now make it executable:
#>Chmod 775 startRocket

Copy it into the /usr/bin directory
#>sudo cp startRocket /usr/bin

Now build a system service for it
#>nano rocketService.service

Description=Rocket Chat Service



Now you can move that over to /etc/systemd/system/
#>sudo cp rocketService.service /etc/systemd/system

And finally, turn it on!
#>sudo systemctl start rocketService.service

If you want it to start automatically then do this as well:
#>sudo systemctl enable rocketService.service

You may also want to adjust the firewall
#>sudo ufw allow 3001
#>sudo ufw disable
#>sudo ufw enable

This ensures that it’ll have full access.

Happy chatting!