Imagr 101: Web Service

Hi All, and welcome back to our series on configuring Imagr. Last time, we introduced you to Imagr and ran through the setup of the NetBoot / NetInstall service.

This ‘part 2’ looks to cover the configuration of the OS X web service to host the Imagr data. ‘Part 3’ will cover the creation of the Netboot set using AutoImagrNBI. ‘Part 4’ will cover populating the Imagr repo with content and building a workflow. ‘Part 5’ will look at some possible use cases for Imagr with the current popular management tools.

Key Facts

OS Used:                              OS X El Capitan (10.11.1)

Server App Used:                 5.0.15

Imagr Used:                           0.0.4

Recommended knowledge (but not required):

  • Apple NetBoot server configuration
  • AutoDMG
  • Auto[X]NBI (such as AutoCasperNBI or AutoImagrNBI)
  • Editing XML files (or OS X plist files)

I’m also assuming you’ve got a fully working Mac OS X server setup and running.

I will often be using “Repo” as shorthand for “Repository” throughout this series.

Step-By-Step: The Repo Web Server

One of the reasons that Imagr can easily be used cross-platform is its use of a standard web server to host both the configuration files, and the data used (such as OS images, installer packages and scripts). In a similar way to the Munki blog, we will configure the built in version of Apache that Apple uses with their server offering.

Additionally, new with OS X Yosemite, Apple introduced a default rule on the built in webserver to redirect HTTP requested websites to HTTPS. As part of this series, I will leave this in place, as it is good practice. If you need to use HTTP, you will need to disable the redirect in the options of the HTTP website.

Please Note: In this guide, we will be using the basic self-signed certificate generated by the If you wish to use a similar setup in production, ensure to replace this with a ‘proper’ signed SSL certificate. See Ben Toms’ great JNUC talk on certificates here: Let’s talk about certs.

Lets get to it!

1. Fire up the Terminal application. I’ve added this to my Dock for quick access, but it can be found in the Utilities folder (in /Applications/Utilities/).

Imagr 101 blog - part 2 - blog pic 1

2. Navigate to your ‘service data’ storage location using the `cd` command. In my example, I am using a secondary non-boot volume called “Data HD”. I’d consider this good practice, as it’ll stop any services filling up the server’s boot drive, causing performance, crashing and booting issues.


cd /Volumes/Data HD

Imagr 101 blog - part 2 - blog pic 2

3. In this top-level area, I’m going to create a specific and dedicated folder for the Imagr data (using the `mkdir` command). This isn’t required and quiet often, Administrator’s will utilise existing locations, such as an existing Munki repo. I then use the `ls` command to check that the folder has been created.


mkdir ./Imagr
ls -al

Imagr 101 blog - part 2 - blog pic 3

4. I will now create four folders, inside this ‘Imagr’ folder to organise the data I will be using. Again, this is not required but I find it is easier to find items for other team members you maybe sharing the administration with. These folders are specifically:

a) ‘workflow’ – To store the main Imagr configuration plist detailing each Workflow and the tasks to carry out.

b) ‘images’ – To store the OS images that will be deployed using Imagr.

c) ‘packages’ – To store the installer packages that will be deployed using Imagr.

d) ‘scripts’ – To store the scripts that will be run using Imagr.


mkdir ./Imagr/workflow
mkdir ./Imagr/images
mkdir ./Imagr/packages
mkdir ./Imagr/scripts

Imagr 101 blog - part 2 - blog pic 4

5. Again, we’ll use the `ls` command to confirm these folders have been created.


ls -al ./Imagr/

Imagr 101 blog - part 2 - blog pic 5

6. Now we need to make sure all these directories we’ve created have the correct permissions. We need to use the `chmod` command to add the ‘read’ and ‘execute’ permissions to the Imagr folder and downwards.


chmod -R a+rX ./Imagr

Imagr 101 blog - part 2 - blog pic 6

7. That’s most of the groundwork done. Next, leave the Terminal window open and launch the

Imagr 101 blog - part 2 - blog pic 7

8. Go to the ‘Websites’ section on the left hand side.

Imagr 101 blog - part 2 - blog pic 8

9. Click to highlight the “Server Website (SSL)” text and click the ‘pencil’ / edit button. Alternatively, double-click the “Server Website (SSL)” text to open the same edit window.

Imagr 101 blog - part 2 - blog pic 9

10. This will show you the options set for the HTTPS side of the web service. Much like setting up the Munki web server, we need to redirect the web site storage to the ‘service data’ drive. Click the arrow next to the “Store Site Files in” box.

Imagr 101 blog - part 2 - blog pic 10

11. This will show the location of this storage area in a new Finder window. Hold down the Apple / ‘cmd’ key and click the folder name in the top of the window to see the path to this folder. Make a note of this.

For my example, the path would be:


Imagr 101 blog - part 2 - blog pic 11

Imagr 101 blog - part 2 - blog pic 12

12. Another method to make it easier is to enable “Show Path Bar” in Finder. Click the “View” menu, followed by “Show Path Bar”. This will then show the full path to the current item in the bottom of the Finder Window.

Imagr 101 blog - part 2 - blog pic 13

Imagr 101 blog - part 2 - blog pic 14

13. Right, now we’re going to use the `ln` command, as root (sudo), to create a sym-link from inside this folder, to our Imagr folder. Go back to the Terminal window and enter the following, substituting [path to Imagr folder] for the full path to your Imagr folder created in step 3, and [path to web service folder] with the full path as found in step 11:

Please Note: All spaces must be ‘escaped’ for this to work. The simplest method is to wrap the entire path in double quotes. This must not be ‘curly’ double quotes as seen in word processors, but should be the straight ones as seen in scripts. If in doubt, manually write out (not copy) the example texts.

sudo ln -s "[path to Imagr folder]" "[path to web service folder]"

In my example, it would be:

sudo ln -s "/Volumes/Data HD/Imagr" "/Library/Server/Web/Data/Sites/Default/"

Imagr 101 blog - part 2 - blog pic 15

14. Enter your administration password when requested.

15. Once complete, you should be able to switch back to the Finder window showing the web server data folder and see a new ‘Imagr’ shortcut icon.

Imagr 101 blog - part 2 - blog pic 16

16. Double click this and, if step 13 worked fine, you should get taken to your Imagr data folder.

Imagr 101 blog - part 2 - blog pic 17

17. We are now going to test that the sym-link works from a web-browser. This will involve temporarily enabling the folder listing option.

18. Go back to the and, on the SSL site, click the “Edit Advanced Settings…” button.

Imagr 101 blog - part 2 - blog pic 18

19. On the new popup screen, tick the “Allow folder listing” box, and click “OK” to close the window.

Imagr 101 blog - part 2 - blog pic 19

20. Click “OK” again to close the settings window.

Imagr 101 blog - part 2 - blog pic 20

21. Once back on the main Websites section, click the “Off” button to turn the service on.

Imagr 101 blog - part 2 - blog pic 21

22. Give this a minute to turn to complete its enabling steps, then launch Safari.

23. Navigate to, dismissing the SSL certificate area (this will popup as you are accessing the server as ‘’ and the SSL certificate that is provided is for a full hostname).

Imagr 101 blog - part 2 - blog pic 22

24. You should see the default Apple web browser homepage.

Imagr 101 blog - part 2 - blog pic 23

25. If this loads successfully, click back into the address bar and add “/Imagr” to the URL ( and attempt to load this.

Imagr 101 blog - part 2 - blog pic 24

26. You should now be able to see all the folder directories we created in step 4.

Imagr 101 blog - part 2 - blog pic 25

27. Quit Safari, go back to the, repeat steps 18 – 20 and use the ‘On / Off’ switch to restart the service. This will disable the folder listing option on the HTTPS site, stopping users (or anyone else) from browsing your Imagr repo and helping themselves to the contents.

There you go; that’s the web service configured and ready for content. If you are using a self-signed SSL certificate for this lab (as I am with these examples) there’s one more step we need to complete to obtain the certificate, ready to add into the client NetBoot Image.

Step-By-Step: Obtaining the SSL Certificate 

These steps are only required if your Web server SSL certificate is not trusted by default by the NetBoot’d client OS.

28. Grab a second Mac / Virtual Mac OS and launch Safari.

29. Navigate to the HTTPS site for your Imagr web server repo.

e.g. https://amsys-imagr-blog-server.local

Imagr 101 blog - part 2 - blog pic 26

30. When the SSL certificate warning message appears, click “Show Certificate”

Imagr 101 blog - part 2 - blog pic 27

31. Tick the “Always trust…” box and click “Continue”

Imagr 101 blog - part 2 - blog pic 28

32. Enter the local administration username and password when requested.

Imagr 101 blog - part 2 - blog pic 29

33. Once the webpage is loaded, quit Safari.

34. Launch the Keychain Access application. This is found in the Utilities folder (/Applications/Utilities/).

Imagr 101 blog - part 2 - blog pic 30

35. Once launched, find the certificate we saved in steps 31 and 32. Click to highlight it.

Imagr 101 blog - part 2 - blog pic 31

36. Go to “File” > “Export Items” to export the certificate.

Imagr 101 blog - part 2 - blog pic 32

37. You’ll be asked where you’d like to save this. I’d suggest to your desktop and ensure that the type is “Certificate (.cer)”. Click “Save”.

Imagr 101 blog - part 2 - blog pic 33

38. Quit Keychain Access and keep a copy of that SSL cert to hand for next time!

And that’s pretty much it. Congratulations you now have your web server up and running ready to add some content

Next time, we look at configuring a NetBoot set to work with your Imagr solution using Ben Toms’ AutoImagrNBI.


As always, if you have any questions, queries or comments, let us know below and I’ll try to respond to and delve into as many as I can. I’m especially eager to hear any feedback on this new series.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. Amsys will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept the Privacy Policy