gerritdewitt / munki-enrollment-server

The Munki Enrollment Server (MES) is a web application written in Python. It is the server compliment to the Munki Enrollment Client (MEC).

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

About

The Munki Enrollment Server (MES) is a web application written in Python. It is the server compliment to the Munki Enrollment Client (MEC), providing a method of enrolling Mac systems with Munki for certificate-based communication thereafter.

Communication between the MEC and the MES is encrypted in transit with HTTPS. Based on input from the Munki Enrollment Client (MEC), it handles:

  • creating a computer manifest for an enrolling computer if necessary,
  • generating client PKI materials (private keys, certificates) from its local CA and returning them to the client,
  • associating computer manifests with group manifests by modifying their included_manifests keys,
  • providing clients with their manifest data and a list of available group manifests.

A concept of a server like this appears to have originated around 2012 with Cody Eding's munki-enroll web app.

The MES is written in Python and distributed with its own virtual environments. The MES is designed to be hosted on Linux, with all of its dependencies in a single container. It could be ported to run in other environments; for example, in a Docker environment on another platform.

Certificate Authority Requirement

The MES requires access to a local CA (its private key and certificate). Refer to the Munki_CA_ReadMe.md file in the Documentation folder for more details.

Building

Steps

Run the build-script.sh on a Linux system. For example, we build on RHEL. The build-script.sh needs Internet access. It grabs current versions of the open source items it needs from the Internet.

This script is interactive. When building, the script requests the following parameters:

  • A version number. This is an arbitrary string for your own internal versioning purposes.
  • Details for the system account under which the MES will run. It is possible to run the MES as root, but that's not the best idea. We run the MES with the privileges of another account whose details you specify at build time:
    • An account name for the system user; we recommend munki-enrollment-server.
    • The UNIX UID number for this system account. For example, 502. Pick a UID for a user not already used by the system.

The build script produces a “package root” tarball for installation. Refer to the Installing section for how-to.

Special Build Considerations

  • If hosting the Munki repository on a mounted NFS volume from another server, take special care to make sure that a user with the same UID is present on that server with appropriate access:
    • Example: munki-enrollment-server with UID 502 is configured on the MES server. The repository server needs a user with UID 502 having access to the Munki repository:
      • read-only access to the entire Munki repository
      • read and write access to the computers subdirectory of the manifests folder in the Munki repository
  • The system user name and UID are embedded in the installable “package root” tarball. If those need to be changed, the easiest thing to do is rebuild the MES.
  • For the sake of clarity, the build script does not create the system user account on the box where you build. It simply updates the init-script-template.sh so that the init-script.sh creates that account on the server on which you install the MES.

Installing

  1. Copy the package root tarball to the target server and expand it in a directory of your choosing.
  2. Edit or restore these configuration files for the MES. Notes for each config file are in XML comments in each file.
    • <container>/mes_virtualenv/mes/configuration.plist: Overall server config
    • <container>/mes_virtualenv/mes/munki_client_prefs.plist: ManagedInstalls.plist for clients
  3. Run the init-script.sh with the install argument as root; for example:
tar -xvf munki-enrollment-server-2016.09.tgz
sudo ./munki-enrollment-server/init-script.sh install
  1. When installing, the script will pause and give you an opportunity to edit or restore the configuration files described in step 2 if you haven't done so already.

To upgrade or install a new version of the package, simpy repeat the installation steps.

Security Notes

The Munki Enrollment Server could run as root, but we run it with a designed user account called munki-enrollment-server for added security.

The munki-enrollment-server user account needs to have access to the Munki repository as specified here. Note access can be granted by virtue of it being a member of a group, and regular POSIX permissions or POSIX ACLs may be set on the Munki repository:

  • Munki Repository: The MES should have read and execute permissions to the top-level of the munki repository.
    • Manifests Directory: The MES should have read, write, and execute permissions to the manifests repository therein.
  • Private key for the CA: The MES needs to have read permission to the CA's private key. This key is used to sign the certificates that it dispenses to clients.

Unless running in DEBUG mode, the MES only binds to 127.0.0.1:3000. Thus, requests from clients must go through a “front end” reverse proxy web server, where you can perform authentication if desired.

Authors & Sources

By GSU

  • The following items were created by Gerrit DeWitt (gdewitt@gsu.edu).
    • This file, ReadMe.md
    • Other notes in the Documentation directory
    • The build-script.sh
    • The init-script-template.sh (and, consequently, the init-script.sh as generated by the build-script.sh)
    • The various Python scripts that compose the MES (in src-mes).
      • The MEC and MES were created by Gerrit DeWitt (gdewitt@gsu.edu), but the overall idea for the project is not novel. For example, a project called “Munki Manifest Selector” (noted in Sources) captures the overall design goal.
    • The various property list examples included with the MES (in src-mes).
  • This container was compiled by Gerrit DeWitt (gdewitt@gsu.edu) using other open source items. For license terms, authors, and references, refer to the Sources section.
  • Special thanks to Jane Eason (jeason@gsu.edu) for pointers and assistance with managing process PIDs on Linux.

General Reference Notes and Public How-To

Omitting items that are obviously in the public domain or for which more than a few references can be found, the following publicly documented methods and how-to were consulted during the creation of the Munki Enrollment Server.

  1. Conceptual Inspiration:

  2. Munki:

  3. Creating init Scripts

  4. Configuration Profile Reference

  5. Python:

  6. Misc

Software

  1. PyPy Runtime: Created by various authors
  2. Flask: Written and maintained by Armin Ronacher and various contributors.
  3. Werkzeug: Written and maintained by Armin Ronacher et. al.
  4. Jinja2: Written and maintained by Armin Ronacher et. al.
  5. MarkupSafe: Written and maintained by Armin Ronacher and contributors.
  6. itsdangerous: Written and maintained by Armin Ronacher and the Django Software Foundation
  7. pyOpenSSL: Created by Martin Sjögren, Jean-Paul Calderone, et. al; maintained by Hynek Schlawack
  8. cryptography: Created by many individual contributors
  9. six: Created by Benjamin Peterson
  10. ipaddress: Created by Philipp Hagemeister
  1. enum34: Created by Ethan Furman
  1. idna: Created by Kim Davies
  1. pyasn1: Created by Ilya Etingof. Copyright holder Schneider Electric Buildings AB. Maintained by SNMP Laboratories.
  1. nginx: Written and maintained by Igor Sysoev and Nginx, Inc.

Organization

Top level items in this repository are:

  • build-script.sh: A shell script that builds a “container” for deployment to a server. It needs Internet access to download the various components.
  • init-script-template.sh: A shell script that serves as a template for the init-script.sh included in the container that's produced.
  • ReadMe.md and Documentation: This file and other documentation.
  • src-mes: A directory containing Python scripts and configuration files that compose the MES. These are moved into a Python virtual environment by the build-script.sh.

When built, the NetBoot server container has the following layout:

  • build.log: The build log created by the build-script.sh.
  • init-script.sh: The shell script responsible for loading and installing the software. Created by the build-script.sh from init-script-template.sh.
  • mes_virtualenv: Portable pypy virtual environment for BSDPy and its dependencies.
    • mes: Code and configuration files for the MES. Some configuration plist files are stored here, too:
      • configuration.plist
      • munki_client_prefs.plist

Methods

Python Dependencies

Python dependencies are those modules not included with the pypy runtime by default are sourced and added when the build-script.sh runs. It downloads and installs the necessary dependencies in the virtual environment it creates. This virtual environment is created using tools included with pypy; pip is the method for obtaining the dependencies.

About

The Munki Enrollment Server (MES) is a web application written in Python. It is the server compliment to the Munki Enrollment Client (MEC).

License:Other


Languages

Language:Python 75.4%Language:Shell 24.6%