Since 2014, I have been managing a classroom at FIT Apple designed to teach the development of applications for Apple platforms. The project is covered by my bachelor’s thesis CTU FIT Apple Classroom Case Study and my diploma thesis Operation of the Apple Laboratory for FIT CTU.

Due to the lack of support for macOS Big Sur on the Mac mini 2012, the life of the original classroom is coming to an end. However, there is an interest in continuing teaching iOS development courses. The classroom may continue with the Apple Silicon Mac. For now let’s see how it came to life.


In addition to programming for iOS, other subjects are taught in the classroom. Taking care of the classroom means to deploy macOS system and various applications. Both need to be updated from time to time. We need to adapt the configuration to the classroom environment and prevent users from doing ugly things. Ideally, solve everything from central location in a automated fashion. How about other operating systems? Not a problem. When you start your Mac mini, you choose between macOS, Linux and Windows. How did I solve it?

macOS management

Xcode v AppleLab

A new version of macOS is released once a year in the autumn. Soon after, I deploy it in the Apple classroom. Using AutoDMG, I create an image from the macOS installer. Image contains a never booted system and add bulky software such as Mathematica or MATLAB. All computers in the classroom boot macOS over the network using NetBoot. DeployStudio automates the deployment. All clients receive the macOS image from ASR multicast transmission.

Manually managing 40 pieces of software is not something you want to do. Thankfully there is a solution for that. AutoPkg downloads newly released versions from developers’ websites and import them into the Munki repository. Munki client downloads and installs all the necessary programs on each Mac. It can also install system updates. To control availability of Apple updates, we use Reposado. In addition to the classic software, we install many of our own packages created through luggage. Not to be missed are a number of other shell and Ruby scripts along with git versioned documentation.

macOS is connected to several faculty services. Users log in on any Mac with their school account obtained from an LDAP server. Automount mounts their home folder over an NFSv3 network. They can access the data from any classroom and any operating system. If the system crashes, heats up too much, or runs out of disk space, we’ll find out in Nagios, where Macs send status information.

Classroom Server

There is one Mac mini sitting in the server room, on which we run VMware ESXi. This solution allows us to run multiple instances of macOS at the same time without too much overhead. In addition to the production virtual machines, we can turn on several others for testing purposes. Once a day, the backup is performed automatically by the ghettoVCB script.

The main virtual machine contains macOS with the Server module installed. It runs the already mentioned NetBoot and Profile Manager for client configuration. The administrator has at his disposal tools for service management such as DeployStudio Admin, MunkAdmin, AutoPkgr or Margarita.

Support for multiple operating systems

The first thing the user sees after starting a Mac in the classroom is the EFI boot manager rEFInd. In addition to macOS, Linux or Windows, you can also boot into the classroom installation environment commonly used on school PCs. We achieve this by using the iPXE program to substitute the missing PXE support in the Mac firmware. Therefore, it can boot a diskless system over a network and deploy Windows and Linux to computer’s disk.


I thank the ICT department for cooperation in the implementation of the classroom. Especially Tomáš Kadlec, Marin Bílý, Milan Václavík and Lukáš Kudrna. I also thank Rudolf Blažek PhD and Tomáš Zahradnický PhD, without whom the classroom would not have been established..