Wrangling Unity in a lab environment

It’s time for another one of these “how do you suppress all the stuff you don’t want students to see and get the thing working the way you want the first time it runs” posts. In the red corner, it’s me, Neil. And in the blue corner, it’s Unity – a popular game development platform! Ding ding!

  • Round 1: Get the packages.
  • Round 2: Get the application licensed on your Macs.
  • Round 3: Suppress automatic updates and make sure Unity doesn’t sign in to your license holding account (because that’s really bad!!!).

Get the packages

That’s easy enough – just grab the Download Assistant from the website. Run it, then when you hit the Destination Select part, click Advanced and you can specify the folder where the packages for the components you chose will go. In that folder you’ll also get a handy script that can install them all at once, which may be useful. They have some documentation to support this too, here.

The packages don’t contain any nasty surprises and deploy straightforwardly with management tools like Munki and Jamf. They’ll also cleanly upgrade previous versions of Unity.

Get the application licensed on your Macs

This gets a bit more interesting. Unity recently started offering free licenses for education, which is awesome for my institution. The documentation reveals some promising command line arguments to license Unity programatically. Alas, the application crashes if you run it in batch mode without a user logged in, or not in their context (i.e. as root triggered by a Jamf policy). Here’s a script I wrangled to firstly check for the license file, then run Unity as the logged in user if said file isn’t there:

This is supposed to be run by a Jamf Policy (triggered at login). The parameters $4, $5 and $6 are your Unity serial number, license account username and password, respectively. You could easily wrangle this into Outset by getting rid of the sudo -u “$loggedInUser” part and putting the actual credentials in place of the parameters – but then make sure you delete that script after it’s run as you don’t want that stuff on disk in your labs!

Suppress automatic updates and make sure Unity doesn’t sign in to your license holding account

So if you open Unity after licensing it, you’ll notice it’s signed in as the account that holds your licenses! That means whoever’s using Unity can get into your account and do naughty things like change your email/password etc. If anyone from Unity is reading this, please stop that behaviour, pretty please!

It also prompts when updates are available. We like keeping our labs up to date too, but we don’t want to bug our users with that stuff, especially as they’re not admins and can’t update anyway. Sometimes, our teaching staff need to stick with a specific version as the changes updates bring can disrupt the courses they’re halfway though teaching.

To get around this, we need to set some preferences as the logged in user. Unity does use the com.unity3d.UnityEditor5.x preference domain, but seems to ignore Configuration Profiles and anything in the machine-wide /Library/Preferences.

The keys you’d to set to manage updates away and stop Unity signing in with your license account are EditorUpdateShowAtStartup (integer 0) and UnityConnectWorkOffline (integer 1). Here’s the script I use, again, designed to be run by Jamf at user login:

Advertisements

Author: n.martin

Managing 450-odd Macs at a university, innit.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s