Integrating AutoPkg and the Casper Suite
with JSSImporterLive the Dream
What are we Trying to Do
Keep software up-to-date on client machines.
Test software before deployment.
Minimize IT involvement, mistakes, and time.
Prioritize important software.
Virtuous Behavior
Laziness as a virtue.
Trading one kind of labor for another.
The path is not easy, but it's not hard either.
Creating a safe space to iterate.
It's all in the reflexes.
How does Casper install Software? 1. Package up software (Composer)
2. Package is uploaded to distribution points.
3. Policy is created. Scoped to desired machines/groups.
4. Targets check-in periodically, and run any queued policies. Once. (Even if it fails).
and when software is updated?1. Download new version.
2. Test it out?
3. Package it up.
4. Upload it to distribution points.
5. Edit Policy to install new version.
6. Flush the logs!
Two Points of Pain1. Almost all software must be
repackaged.
2. Clicking on a bunch of web forms to deploy.
If you don't mind repetition, I have the cure...
Hasselhoff Infinite Recursion
Our Perception Our Sad Reality
Quality Control
*Especially in small organizations
Solving Point of Pain #1
AutoPkg
It's a black box
Solving Pain #2
Take a cue from Munki and automate.
What does Munki do?"Munki is a set of tools that... can be used by OS X administrators to manage software installs (and in many cases removals) on OS X client machines."
Manages multiple versions of software in Catalogs.
Manifests gather together groupings of software to install, and Catalogs from which to pull.
Clients check for updates to their available software, and install any that are available, on a schedule.
Development Testing Production
AutoPkg + Munki
Already built in.
Most major software already cooked up.
What exactly does a Munki recipe do?Extends a download or pkg recipe.
Specifies metadata about product.
Adds product to Catalog: (testing)
Copies files to Munki repo.
All of the deployment is handled elsewhere.
So basically it just copies software to a fileshare. Is this enough for Casper admins?
i.e., what happens if you simply upload a package with Casper Admin?
JSSImporter & python-jss
* Not the actual Allister Banks
Making it happen on Casper
Policies should not install more than one product.
Each product deployed by two policies:
Testing (self service)
Production (automated)
Deploy to ProductionProbably Automated
Can and should be bulk created (python-jss/jss_helper)
OR duplicated to remove the risk of error.
Variance as Documentation: Policies should only differ in installation-dependent ways.
(Extra scripting, reboots, etc)
Naming Convention: Install NetHack-3.4.3
Deploy to Testing"Official" Workflow Overview
1. Upload package to all configured distribution points.
2. Self-service policy offers new package to testing computers.
3. Test software.
4. Promote to production.
The Testing Group
Details of Self-Service
Scoped to Smart Group: NetHack-update-smart Frequency: Ongoing
Installs package, then recons.
Client drops out of Smart Group.
*No true version comparisons
RelaxThis is all you need to know. But.
Going Further
Setting things up.
Writing Recipes.
Alternate Workflows.
Mad Skills.
Installation & Configuration
https://github.com/sheagcraig/JSSImporter/releases/latest
Settings
API_USERNAME & API_PASSWORD
JSS_URL
JSS_VERIFY_SSL
JSS_REPOS
Create an API User
System Settings
JSS User Accounts and Groups
Needs Create, Read, and Update privileges for:
• Categories
• Smart Computer Groups
• Static Computer Groups
• Distribution Points
• (only needs "Read")
• Extension Attributes
• Packages
• Policies
• Scripts
*Permissions required even if not using!
defaults write com.github.autopkg JSS_URL https://test.jss.private:8443 defaults write com.github.autopkg API_USERNAME <apiUser> defaults write com.github.autopkg API_PASSWORD <apiPassword> defaults write com.github.autopkg JSS_VERIFY_SSL -bool <true or false>
Warning for Crazy Password People:
Bash shell escaping and XML escaping are not the same!
defaults write ./test.plist Password -string "L33tP@$$w0rd!" bash: !": event not found
Defaults will handle the XML encoding for you. Just editing the plist will not. defaults write ./test.plist Password -string '!@#$%^&*()<>?'
Configuring Distribution Points (JSS_REPOS)
JSS_REPOS is an array of dicts!
Two kinds of distribution points settings:
• Automatically Configured FileShare Distribution Point
• JDS
Check the documentation for in-depth instructions on how to PlistBuddy this, OR
you can edit it in your favorite text editor (which is vim)...
but you probably have to plutil -convert xml1 ~/Library/Preferences/com.github.autopkg.plist
first, and make sure to defaults read com.github.autopkg
afterwards.
Basic Usage
JSS Recipes Repo: https://github.com/autopkg/jss-recipes
autopkg repo-add jss-recipes
autopkg search <product>
Ensure you have recipe's parentautopkg info <Recipe>
Run the recipeautopkg run <Product>.jss
What HappensFirst Run 1. Create categories. 2. Copy package to
distribution points. 3. Create extension
attributes. 4. Create static and smart
groups. 5. Create scripts. 6. Create policy. 7. Attach icon to policy.
Subsequent Runs 1. Update package if new. 2. Update extension
attributes. 3. Update groups. 4. Update scripts 5. Update policy
*Update means manual UI changes are lost: "Declarative".
Test Packages
Promote Package to Production
Manual Edit production policy: • Name • Package • Flush logs • But no.
Automagical jss_helper promote -u
https://github.com/sheagcraig/jss_helper
Flush
Other Cool Stuff with jss_helper
computer and mobile device groups computers and mobile devices policies configuration profiles (computer & md) categories imaging configurations packages
Research Objects
There's also: https://yourjss.company.org:8443/api (If you're still into clicking... Remember the Hoff)
jss_helper installs
jss_helper scoped
Writing JSS RecipesWriting JSS recipes is primarily about applying your already-designed workflow to a new product.
Workflow is described in PolicyTemplate and SmartGroupTemplate.
Text Substitution
Autopkg and JSSImporter attempt to replace any string value wrapped in %'s with the value of a variable.
E.g. %version% is replaced with 18.0.0.194.
Applies to recipes as well as xml templates.
PolicyTemplate.xml
Design a policy in web UI, then edit out unnecessary elements.
PolicyTemplate.xml
Or start with standard and edit in changes.
PolicyTemplate.xml
Or start with standard and edit in changes.
SmartGroupTemplate.xml
Writing the JSS Recipe
Copy an existing recipe, make edits, diff.
Writing the recipeOnce Policy and SmartGroup are designed, most recipes differ only in a few ways. To reuse:• Edit the description.
• Edit the identifier
• Edit the NAME
• Edit the SELF_SERVICE_ICON
• Edit the SELF_SERVICE_DESCRIPTION
• Edit the Category
• Edit the ParentRecipe
Standard jss-recipes
Filename is <Product>.jss.recipe
Identifier is com.github.jss-recipes.jss.<Product>
Argument Doubling (*only edit the Input)
Extra Arguments
os_requirements: 10.10.x, 10.9.5, 10.9.6
site_name / site_id
jss_inventory_name: Microsoft OneNote vs. MSOneNote
scripts
extension_attributes
JSSRecipeCreatorhttps://github.com/sheagcraig/JSSRecipeCreator
Takes a parent recipe as input.
Will prompt for every important value OR -a for full-auto ease.
JSSRecipeCreator -a ~/Library/RecipeRepos/com.github.autopkg.sheagcraig-recipes/OpenEmu/OpenEmu.pkg.recipe
• Standard Mode prompts for: • Recipe Filename • Identifier • NAME • PolicyTemplate • Package Category • Policy Category • Scope • Self Service Icon • Self Service Description
Overriding JSS Recipes
Copy templates, icons to: ~/Library/AutoPkg/RecipeOverrides/
...if you want different ones.
Remove things you don't need to change, edit things you do.
autopkg make-override NetHack.jss
AppStoreApphttps://github.com/autopkg/nmcspadden-recipes
Requires pyasn1: sudo easy_install -U pyasn1
Create a JSS Recipe for each app.
• Name: (App's name)
• ParentRecipe: com.github.nmcspadden.pkg.appstore
App must be present!
* Not the actual Nick McSpadden
Alternate Workflows• Automatically deploy packages to testing computers.
• Add packages to distribution points only.
• Multiple JSSImporter steps create multiple policies:
• Install policy
• Notification policy
• Bad Idea: Use JSSImporter to automatically deploy software to all computers.
Alternate Workflows• Automatically deploy packages to testing computers.
• Add packages to distribution points only.
• Multiple JSSImporter steps create multiple policies:
• Install policy
• Notification policy
• Bad Idea: Use JSSImporter to automatically deploy software to all computers.
Alternate Workflows• Automatically deploy packages to testing computers.
• Add packages to distribution points only.
• Multiple JSSImporter steps create multiple policies:
• Install policy
• Notification policy
• Bad Idea: Use JSSImporter to automatically deploy software to all computers.
Add 2nd JSSImporter
NotificationPolicy
Other Stuff
Automate your AutoPkg with AutoPkgr
http://www.lindegroup.com/autopkgr/
LaunchDaemon and autopkg -l <my_list>
My JSS has 90 Google Chrome packages......and there's no room for my emergency security updates to Adobe Flash!
Spruce
https://github.com/sheagcraig/spruce
Audit unused packages, scripts.
And more coming!
JSSImporter as a Management ToolCan be configured to populate:
Extension attributes
Example: Computer Information Fields
XProtect State
Scripts
SavingThrow