Good Morning Citizens,
I recently had the pleasure of attending the JAMF CJA (highly recommended) and while largely enlightening it occurred to me that the vast majority of configuration tasks required to bring up the JSS could be automated. Being a huge fan of Puppet I set to work developing a module that would ease the deployment of the JSS and enable more efficient testing.
To a large extent this module scratches my own itch. I run JSS services for my team at UC Berkeley and consider any hands-on interaction with my servers or services to be a legitimate bug. Employing a modern toolset (config management [pupppet], revision control [git], continuous integration [jenkins], local development [vagrant]) allows for an entirely congruent configuration and deployment process when developing locally or deploying in production. If there’s interest in our configuration and deployment methodology I’d be more than happy to delve deeper into it.
The initial goal was to create a module that could pass CJA certification. I haven’t quite hit the mark but I’ve made significant progress. At present the puppet-jss module is capable of…
What It Does
- Deploy the JSS webapp in multi-context, clustered or multi-context clustered mode.
- Deploy, configure, and secure(ish) MySQL, create the necessary databases, restricted grants, and users.
- Deploy MySQL and JSS to the same or different hosts and maintain firewalls on all systems.
- Configure the majority of JSS configuration values (full list below).
- Determine as many JSS configuration values dyamically or in accordance with “best practices.”
What It Doesn’t (yet)
- Distribution Points
- Gracefully handle HTTPS
- Allow activation code*
- Technically the module allows the operator to pass in an activation code however I haven’t yet divined how JAMF populates the user table, leaving you in a running state with no locally configured users. I could scrape and parrot back some static values but that seems hacky and I think I can do better. If anyone can provide guidance here I’d be infinitely appreciative.
In developing this puppet module I’ve also created a development environment and workflow that anyone can check out and use. A single command will result in a locally running JSS (by default @ ${ip}:8080/production) patiently awaiting activation key.
For example:
git clone git@github.com:tscopp/puppet-jss.git
unzip JSSInstallationX.X.zip
cp JSSInstallation/JSS Components/ROOT.war puppet-jss/modules/jss/files/
cd puppet-jss
All in one, multicontext — http://${ip}:8080/production, http://${ip}/development
vagrant up default
Separate hosts — http://${ip}:8081/development
vagrant up db
vagrant up jss
Clustered — http://${ip}:8082/production, http://${ip}:8083/production
vagrant up db
vagrant up jss01
vagrant up jss02
More information about the project and vagrant development environment can be found @ https://github.com/tscopp/puppet-jss/ and the puppet module can be downloaded directly @ https://forge.puppetlabs.com/tscopp/jss/.
Parameters and Defaults
jss::context{'all_the_values':
activation_code='',
api=true,
context='',
db_addr='localhost',
db_min_pool='5',
db_max_pool='90',
db_port='3306',
db_passwd='${context}passwd',
db_user='${context}user',
http=true,
https=false,
http_port='8080',
http_proxy_port='8443',
institution_name='',
keystore_path='/var/lib/tomcat7/keystore.jks',
keystore_pass='',
log_path='/var/lib/tomcat7/logs',
tomcat_dir='/var/lib/tomcat7',
tomcat_max_threads='450',
user_enrollment=true,
war='ROOT.war',
war_url=''){ }
jss::db('all_the_values':
context='',
db_addr='localhost',
db_name=$context,
db_user=${context}user,
db_passwd=${context}pw,
db_port='3306',
db_root_password='supersecure',
jss_addr='localhost',
tomcat_dir='/var/lib/tomcat7') { }
Thanks for reading, hopefully this will prove useful to someone out there.
Tim Scoppetta
tscopp.com
github.com/tscopp
forge.puppet.com/tscopp
