Deployment,OS X,Third Party Applications December 5, 2013 at 2:28 pm

Deploying MinecraftEDU

Minecraft is of course a huge thing. It’s hugely popular at our school, and has become a valuable educational tool. Minecraft allows structured but almost unrestrained creativity, giving students a change to realize the unlimited nature of their imagination and persistence when building worlds and creating narratives. Minecraft’s multiplayer options allow for teamwork, teambuilding, and the potential for students to take on leadership roles. We already see this happening regularly with kids getting together on weekends to play on their own hosted Minecraft servers – and there’s no reason we can’t incorporate this into the classroom as an important aspect of both play and learning.

Minecraft itself, however, doesn’t have very much structure to it. Generally speaking, the server host has all the control and power. In a classroom setting, we’d like to see more management and gentle nudging from the teacher, who can direct students to follow tasks and instructions. This is where MinecraftEdu comes in, and it’s been an incredibly useful tool. It’s a custom wrapper/mod around Minecraft that has its own server tool, its own launcher, and user management. It gives us exactly the kind of support and control that we want teachers to have, without doing anything to impede the creative potential of Minecraft itself.

The only problem with MinecraftEdu is that it’s not very fun to install en masse in an enterprise/edu infrastructure.

It comes in a jar file, which installs it for the current user at the location you specify. This is already problematic, as it means we can’t install it at the Login Window or with Munki. The preference is to install Minecraft’s data files into ~/Library/Application Support/minecraftedu. This is fine if you’re a logged in user on your own home device, but this is obviously not ideal for any situation in which the device is used by many people, as they won’t be able to access the files in another user’s library. The obvious choice is to install MinecraftEdu into /Library/Application Support/minecraftedu. However, telling the installer to do that results in a straightforward problem:

InstallFail

Because the installer isn’t running administratively, it doesn’t have write permission to /Library/Application Support/. We could fix this by changing permissions there so that it will install – in other words, make it writable by all users, but that isn’t an ideal solution. We can’t change it temporarily, install, and then change it back, because MinecraftEdu needs to read and write to/from that location constantly in order to function.

So clearly MinecraftEdu wants to live in each user’s Application Support directory. However, the installer provided with MinecraftEdu doesn’t do a good job handling this. After installing it to ~/Library/Application Support/minecraftedu, the installer generates an .app shortcut in /Applications that triggers the startlauncher.jar (which is the pre-launcher for MinecraftEdu itself). That “MinecraftEdu Launcher.app” hardcodes the path to the data files that generated it, which makes it useless on multi-user systems. If you install MinecraftEdu this way in the “admin” account, no other account will be able to successfully launch the .app – because the .app is trying to launch /Users/admin/Library/Application Support/minecraftedu/startlauncher.jar, which obviously isn’t accessible by any other users. Not good.

Another solution is necessary to successfully allow the use of startlauncher.jar for each user. We don’t want to require users to navigate to their Library, which is hidden by default, in order to launch an application. We could place the generated launcher application in the local ~/Applications/ directory, but that goes against common user defaults – users generally don’t look for software to run outside of the /Applications folder, nor should they have to. The idea behind the /Applications folder is that there’s software there available for everyone to use, which is what we want from MinecraftEdu. If you’re managing the Dock for your users, you could just place the appropriate file in the Dock – but that’s ugly if your Docks aren’t already being managed, and dramatically increases the complexity and workload, especially if you ever have to make changes to the location or path.

The scope of the problem is pretty clear:

  1. MinecraftEdu’s installer doesn’t work with multi-user environments.
  2. Installing into /Library/Application Support/ produces myriad permissions issues.
  3. Installing into ~/Library/Application Support/ means you can’t use the provided “MinecraftEdu Launcher.app” with more than one account.
  4. We don’t want to require users to go somewhere other than /Applications or go against the common methods for launching software that users are already used to.

So let’s not try to fight MinecraftEdu. Let’s instead work around the limitations. Obviously it wants to be used per-user, which means each user account needs to have a copy of the minecraftedu folder placed inside ~/Library/Application Support/. The most effective way to guarantee that would be to place the folder in /Library/Application Support/ and then copy it out to each user account at login. Having scripts run at login is well-documented, so we’ll create a LaunchAgent to be placed in /Library/LaunchAgents that will run for all users:

https://gist.github.com/nmcspadden/7810536

The script that needs to run is pretty simple. Check to see if the source exists in /Library/Application Support/, and then copy it to ~/Library/Application Support/, and change appropriate ownership. This script here isn’t terribly robust and doesn’t do any error-checking, but here it is:

https://gist.github.com/nmcspadden/7810521

There’s one last piece of the puzzle that needs to be solved – how does the user invoke MinecraftEdu? We already determined that the Launcher.app isn’t going to help, so let’s throw it away and make our own. Enter Platypus, which can make simple .apps out of scripts. All we need is a script that runs ~/Library/Application Support/minecraftedu/startlauncher.jar, and that’s easy:

https://gist.github.com/nmcspadden/7810489

I did have to make one change after generating the .app version of the script, which is to give execute permission to all others for the actual script and app binaries. Otherwise, users outside the group couldn’t launch the app.
chmod o+x MinecraftEDU.app/Contents/Resources/script
chmod o+x MinecraftEDU.app/Contents/MacOS/MinecraftEDU

All the pieces are now complete, time to assemble. I built the package using Packages, which makes this process nice and easy. Drop the actual minecraftedu folder produced by the installer into /Library/Application Support/, place the Launch Agent plist in /Library/LaunchAgents/, place the the actual copy script into /usr/libexec/, and finally place the Platypus app we created into /Applications. Set the package to require Logout after installation (although this isn’t strictly necessary, it does mean that the Platypus app we created will fail for any logged in users who try to use it until they’ve logged out and back in, so we might as well avoid that).

Package

It’s a little unfortunate that there’s so much effort involved in repackaging MinecraftEdu. Much of this could be mitigated if the actual provided MinecraftEdu Launcher.app used sensible defaults – such as checking default locations like ~/Library/Application Support/ for minecraftedu first. Like a lot of cross-platform software that educational institutions use, the brilliance of the software is marred by its lack of functional enterprise support.

Nick McSpadden

I'm Client Systems Manager for Schools of the Sacred Heart, San Francisco. I'm in charge of all OS X and iOS deployments to our faculty, staff, and students.

More Posts

Tags:

3 Comments

  • What about installing it to /Users/Shared? Everybody can read/write to that and the link in /Applications should work. Every user will have access to the same set of files so unless everyone needs their own unique copy of the data it should work.

    • That would allow users who have write permission to the MinecraftEdu folder to also potentially delete data from it.

      MCEdu stores the world data in each user’s account, so this would also mean each user would share the same local world. If you’re going to do this, you might as well setup a real Minecraft server somewhere that allows you to actually manage the multi-user environment. If you’re using MCedu at all, it’s generally because you want to use the server tool.

      The nice thing about having a LaunchAgent do it on login is that it doesn’t matter if a user breaks it or deletes it because a fresh copy will be restored on next log-in. They might lose any single-player worlds they’ve saved, but since the Library is hidden by default, the likelihood of users poking around is low.

      I don’t want to rely on /Users/Shared to install software that’s meant to be used by all users, because that’s not what it was intended for. Multi-user software should be able to accommodate system-wide support files in /Library/Application Support/.

  • Hi,

    So we have just purchased MinecraftEdu, and have been looking for the best solution to deploying the client to the media suite for the students to be able to play during their gaming after school club.

    I come across your post about deploying and have gone through the steps you have highlighted in the article.

    The issue i am having is that the launcher is still not being launched when logged in as a student user.

    I have ran the chmod command as shown above but that doesn’t appear to have done anything. I was wondering if you could maybe provide any extra information on running this setup.

    Cheers

Leave a reply

You must be logged in to post a comment.