Sal is split into Business Units, and then subdivided into Groups. Each customer would be a Business Unit, and then the machines can be divided into Machine Groups.
##Server installation/upgrade
The recommended (and easiest) way of getting running on your own hardware is using Docker.
If you aren't comfortable with Linux, it's recommended that your first installation is on Heroku which will handle the server configuration for you.
If you plan on installing on your own hardware, see Installation on Ubuntu 12 (or CentOS or Ubuntu 14) for server installation docs. If you are installing on a different operating system, please ensure you have Python 2.7 installed.
See Upgrading on Ubuntu 12 for upgrade docs.
If you are running a manual installation and would like to migrate to Docker, please see the migration document written by Nick McSpadden.
You will need to have the server component of Sal setup before continuing to the following steps. Log in with the username and password you set when performing the server setup. You will need to create a Business Unit and Machine Group to get started.
There are currently three User Levels used by Sal. To set these, log into the admin page (link at the top of the Sal screen), and choose User Profile from the menu.
1. Global Administrator
A Global Administrator (GA) has access to everything - they can get into all Business Units, they can create new Business Units and Machine Groups. They cannot get to the admin interface though. To do this, they need to be added to the staff group (in the Users section of the admin interface).
2. Read / Write, Read Only
These users are limited to the Business Units they are given access to. Read/Write users can create new Machine Groups within their Business Units, Read Only users are only able to view the information.
3. Stats Only
The Stats Only user level is not used at this time, and should not be assigned to a user.
The sal postflight script needs to be deployed in the /usr/local/munki directory, and the yaml directory should be deployed in /usr/local/sal/yaml (a luggage makefile is included). Alternately, you can use the published package to deploy the necessary client files.
If you have an existing postflight script (for example, Munki Web Admin), you will need to rename the sal postflight script (for example, sal-submit) and add a reference in your existing postflight like this:
if [ -f /usr/local/munki/sal-submit ]
then
/usr/local/munki/sal-submit
fiThe configuration of the Server Address, and the Machine Group key is from /Library/Preferences/com.salsoftware.sal. Plists, MCX (untested, but should work) and Profiles can be used.
If you wish to set the Server Address and Machine Group Key via defaults you can do so with the following examples (root is needed):
defaults write /Library/Preferences/com.salsoftware.sal ServerURL http://sal.somewhere.com
defaults write /Library/Preferences/com.salsoftware.sal key e4up7l5pzaq7w4x12en3c0d5y3neiutlezvd73z9qeac7zwybv3jj5tghhmlseorzy5kb4zkc7rnc2sffgir4uw79esdd60pfzfwszkukruop0mmyn5gnhark9n8lmx9
If you are using Puppet to manage your Macs, you can deploy custom Facts in the usual manner using pluginsync. If you're not using Puppet, you can still utilise custom Facts. You should deploy the .rb files to /usr/local/sal/facter. If you want to use external Facts, you can deploy them to the usual location (/etc/facter/facts.d/).