It’s been a Salmon Day. That wonderful occurrence in IT where the information superhighway becomes a super river instead, because you’ve swum against the current all day and got screwed at the end of it.
The name of my pain today is macOS developer tools.
It’s generally well known inside Apple IT circles that if you do things the “Apple Way” ™ then things “Just Work” ™. If you do things sideways or against the Apple way, then pain lies within your near future. Occasionally it causes pain for others instead.
We admins like Apple technologies such as pkgs. We can place files inside them to deploy in the right places, with the right permissions. We can craft custom scripts to run before files are placed as well as after. It’s a flexible way of deploying software, that can allow for temporary privileges if required. It’s a standard, usually makes your software easy for users to install and easy for admins like myself to deploy via whichever management tool we happen to be using at the time.
So I’m going to single out Homebrew. You install it as a standard user with this:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
And this is the part where I’m WTF because they’ve coded it so it can ONLY be installed as a standard user, but later on requires an admin level account before proceeding. You run this as root, it fails hard. It also downloads a LOT of files from places that aren’t obvious.
Firstly it will (quite cleverly actually) get the latest Xcode Command Line tools from Apple and install those, THEN it’ll drag a bunch of files from the GitHub that hosts it. Leaving that part aside, that means you can never have a consistent deployment of a specific version ever.
It prompts continually throughout the process, so there’s no real convenient way of installing this unattended .. like say, in an enterprise deployment.
It also does horrid things to your OS filesystem permissions. Part of the code reworks the permissions on /usr/local so that it’s owned by the user that installs it! That blocks anything else from using that folder! It also means that Homebrew is forever locked to that specific user account that installed it too.
Now there are clever projects out there, notably from Tim Sutton about capturing various tools that are installed to deployable pkg files. Sadly this doesn’t capture Homebrew itself which is most of my current battle.
But while that’s a well known badly behaved bit of software, there’s one more that’s really been annoying.
Fastlane. This is yet another command line install as a standard user tool:
[sudo] gem install fastlane -NV
This one has an added sting in the tail: it won’t work with Apple’s supplied version of Ruby.
So what this means is you then have to install either homebrew above, or some developers prefer tools like rvm or the ruby version manager. Which incidentally is YET ANOTHER command line drag everything from online and installer, and if you go down this particular rabbit hole it installs homebrew …
To clarify: to install Fastlane you must install a better version of ruby which mandates at least the installation of one other tool, possibly two depending on what your developers like using. You’ll have zero choice in the matter.
And all of this is highly irritating because they’re actually really good tools that developers want to use. Equally they are the biggest monumental pains in the backside to deal with in an enterprise. They’ve been designed and written so one user with local admin rights can use and install them but trying to capture and deploy them from any management tool is an exercise in pain.
In the last few days, I’ve ended up writing this … thing, which I am totally not proud of and is an example of how deep the rabbit hole can go.
# Download and install Ruby Manager. Add current user to rvm group.
curl -sSL https://get.rvm.io | bash -s stable
dseditgroup -o edit -a $currentUser -t user rvm
# Install latest Ruby version
expect << EOD
set timeout -1
spawn su -l "$currentUser" -c "/usr/local/rvm/bin/rvm install ruby --latest"
expect -- "(the path needs to be writable for user)\r\n: " { sleep 1; send "\r" }
expect -- "Press RETURN to continue or any other key to abort" { sleep 1; send "\r" }
expect -- "Password:" { sleep 1; send "$password\r" }
expect eof
EODThis is just to install ruby! Run with admin privileges, this curls down the latest rvm, runs that script in it’s own bash shell. We run a command to add the current user to the rvm group so it can use the tool without needing admin rights.
Next we have to get it to install the latest ruby version available. However the script when run prompts for user input three times, so to trap that we have to use expect to run the script as the current user … this is the point where I just want taken out the back and shot. Anything but bloody expect. Damn thing can work, but often it just fails with zero bloody clue as to why. Exercise in being beaten over the head with a 12lb lump hammer.
Anyway what this is doing is pressing enter at the first two prompts to continue, then later on we’re prompted for admin privileges for the account we’re running this under so we’re using expect to pass the account password along.
That last sentence should have me tearing up my geek card and leaving IT for good. In fact I’m considering it. Make the pain stop, it’ll all be peaceful … it’ll all go away …
*cough* so yeah this is a HORRIBLE solution to the issue of a non deployable internet install only package that our friendly app devs need to do their job and it simply isn’t good enough.
We admins should not be placed in a situation where deploying essential software becomes a giant battle against the people who made it in the first place. There are other software packages out there with particularly difficult processes to follow but I think these are the extreme example.
Developers out there please note: not every environment can be free like yours. I keep ending up in high security environments that demand specific version deployment of software, that doesn’t interfere massively with filesystem permissions and doesn’t insist on dragging files off the internet. I mean this whole thing fails hard if you’re behind an authenticated proxy that blocks GitHub.
Don’t get me started on the lack of admin rights. I’m more than sure every place I’ve worked in the last decade removes local administrator from it’s users. Very rare that users can ever have them too.
So guys and gals out there, please follow the standards and package your apps accordingly in a pkg. For macOS, what works for single users also works for large scale enterprises too. Stop the internet download to install. Stop the hacking for the sake of it, if only for my own sanity sake. I dislike having to create technologically fragile things that rely on very bad practices so corporations can use your damn products.
In short, STOP IT AND FIX IT.
I’m sure someone will suggest that I change how where I work operates to accommodate them. I say, you’ve never worked in a large organisation and it’s the height of arrogance to suggest such a thing. To you sir, good day.