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:
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:
- MinecraftEdu’s installer doesn’t work with multi-user environments.
- Installing into /Library/Application Support/ produces myriad permissions issues.
- Installing into ~/Library/Application Support/ means you can’t use the provided “MinecraftEdu Launcher.app” with more than one account.
- 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:
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:
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:
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).
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.