Auto-Update Magic! Keep Mac Apps Current with the Casper Suite and AutoPkgr

[elliotjordan]

For those of you who weren't at JNUC this year, here are the notes and slides for my presentation, Auto-Update Magic:
https://github.com/homebysix/auto-update-magic

Here's the link to the latest version of AutoPkgr, which now supports direct JSS integration:
https://github.com/lindegroup/autopkgr/releases/latest

If you find a reproducible bug with AutoPkgr, please open or update an issue on GitHub:
https://github.com/lindegroup/autopkgr/issues

If you have feedback or questions, I'd love to hear from you here!

[gregneagle]

Tycho:

You could use recipe overrides for this.

https://github.com/autopkg/autopkg/wiki/Recipe-Overrides

autopkg make-override Firefox.jss -n Firefox_self-service.jss
autopkg make-override Firefox.jss -n Firefox_auto-update.jss

Then edit the Firefox_self-service.jss and Firefox_auto-update.jss recipes to do whatever is specific for the different policies.

(This is far easier with Munki, and I don't know all the gotchas with Casper, but hopefully that's a start)

[tycho]

Thanks Greg,
Sorry I didn't take the time to read the documentation...

[donmontalvo]

@gregneagle wrote:

This is far easier with Munki

I'm guessing not for too much longer... ;)

[gregneagle]

Keep hoping Don!

[sirkyle]

Munki is great for small shops and academic environments that can afford to experiment. But without support and a roadmap for growth, munki will continue to be a side note in enterprise.

[loceee]

Hardly. The community support and growth / improvement is great. There are massive Munki installs enterprise, you've heard of Google right?

I know some places get hung up on not spending money for things (my workplace included).

... But it's not like these tools (autopkg(r)/autoNBI/Patchoo) that augment Casper come with anymore support than Munki does.

[donmontalvo]

Community support != support contract

[loceee]

Agreed, but if your workflow relies on any of these extra tools you are in the same boat. And with Casper's current gaps (at least for me) I need some extra bits and pieces.

[sirkyle]

No one is saying casper can and should handle it all. The point is, if you retire and I step into your hacked environment, I'm going to have to dismantle and rebuild it from the ground up in order to convince your CTO that we have a stable architecture that is supported, documented and trained admins can be hired to plug and play. The "well Google uses it" argument does not apply so don't even go there.

[donmontalvo]

IT will always be a service to the business. With that said, there is risk and hidden cost to implementing unsupported tools. Its easy for IT folks to fabricate need, its up to the business to make sure that IT doesn't crawl down a rabbit hole they may regret later.

That high school science project might be cool in the beginning, but the novelty wears off soon after you find yourself on the ##osx-server IRC every day/night/weekend, on your company's dime, sneaking away from your family, doing what your company would be better off paying an established company to do - develop and support industry standard tools.

A cab driver shouldn't care what car they drive; he/she just needs to get the passenger safely to their destination. A mechanic might disagree, insisting that Hennessey Venom GT is the right car to get the job done. It's a good thing the mechanic isn't the one calling the shots.

Happy Thanksgiving!

Don

[loceee]

I understand some points and concerns and they are somewhat justified. But I guarantee almost everyone that has a Casper instance is scripting or doing something custom to make it meet their org requirements.

What's worse? Using an open source published tool that many from the community understand and use to fill the gap, or letting a rouge admin write an undocumented first boot script that only they understand?

Thats why I got Patchoo open sourced, and why I even built some functionality that I don't use myself into it. The more people that use and understand it the better for all parties.

I am quite sure a couple of small companies like Nike & Cisco were advertising for Mac admins with Munki experience just recently. It's out there... because it is the best tool for the job.

Apple drag everyone into the future kicking and screaming, like it or not. Quite often requiring massive paradigm changes. Enterprise IT must become more agile and adapt faster than they have before. I can't wait to see where things end up in 10 years! If you wait for everything to have extensive training courses, most of the time things have moved on. Apples cert courses come out months after the OS X release (which is also only months before the next release).

I say invest in good talent that is passionate about doing excellent work, willing share and train and inhouse. Respect good talent when you get it. It will set your organisation apart and you'll all thrive. IT is more than plumbing. Giving your users the best tools and experience should be your priority.

Anyway, this is so off topic now. If you want to package everything manually with Composer and image yours Macs, go for it. I'll be using AutoPkg. :)

[calumhunter]

Yeah i don't buy the unsupported/hacked environment @sirkyle. Pretty much as soon as you start writing any kind of script outside of the popups and checkboxes of the JSS you are now into unsupported territory.
Its about documentation. If the solution, whether it be a firstboot script or a munki installation, is very well documented then there is much less risk should the engineer retire / be hit by a bus etc etc. The Google argument for Munki is extremely valid and should not be discounted, it should also be noted just how many very large education environments use it. If it wasn't a good solution or there was little community support these places would not be using it. The fact is you might just have to hire quality admins/engineers rather than button pushers who when they get in a bind just log a support call and go back to playing COD

[donmontalvo]

@loceee wrote:

I am quite sure a couple of small companies like Nike & Cisco were advertising for Mac admins with Munki experience just recently.

I think most (if not all) shops fill in gaps with alternate tools if/when necessary, but both Cisco and Nike are Casper shops:

Recent article on Cisco:

5 lessons from Cisco’s 35,000 Mac deployment
http://www.jamfsoftware.com/news/5-lessons-from-ciscos-35000-mac-deployment/

Recent JNUC presentation by Nike (and a couple others):

Scaling the JSS: Going Beyond the Small Enterprise Environment
external image link

@calumhunter wrote:

Pretty much as soon as you start writing any kind of script outside of the popups and checkboxes of the JSS you are now into unsupported territory.

True, I don't think anyone questions the value of these alternative tools if/when they are necessary, it's more a matter of determining whether its a nice-to-have or must-have.

[grahamgilbert]

Not to take this thread any further off topic than it already is, there are several companies who would gladly offer a support contract for Munki - my own included.

[elliotjordan]

@jennifer_unger - We have a new release 1.1.2 out today, and we've updated the documentation on configuring proxies in the readme. Skim through that and see if the new proxy improvements help eliminate that error you were seeing. If that still doesn't help, then head over to our GitHub page and open an issue. Eldon or I will help you troubleshoot.

@calumhunter said:

Its about documentation

Exactly. Whether you're using Casper, Munki, AutoPkg, AutoPkgr, DeployStudio, System Image Utility, rsync, or a bunch of AppleScripts, your job as the caretaker is to make sure everything is well documented — if not for yourself, then for your successor.

[jennifer]

Thanks @elliotjordan, Eldon helped me out with some troubleshooting around a week ago and everything has been working wonderfully since. You guys have an awesome app. Thanks for all the help!

[May]

Really excited about getting this set up and tested, thank you for all the hard work!!

A quick question re AutoPkgr and adding a JDS as the distribution point, i'm a bit confused whether we should have the password for the WebDAV Read-Only Account and WebDAV Read/Write Account as i thought they were created during the jump start with a randomly created password.

If we should have the password is there any issue with recreating a new password for the JDS instance ?

[elliotjordan]

You'll want to use the credentials specified in your JSS settings > Computer Management > JDS Instances > [your JDS] > Distribution tab.

If you don't already know this password, it is my understanding that changing it at the location above will automatically update the JDS password to match. (Somebody please correct me if that's not accurate.)

[stevewood]

You should be able to copy and paste the user and password info from the JSS web page into AutoPkgr. At least that's how I did it.

[mscottblake]

@May @elliotjordan It is my understanding that it doesn't currently matter what password you enter anymore. A semi-recent update to one of the underlying technologies was changed and the only information it now needs is that the type is JDS.

[May]

Thanks @elliotjordan @stevewood @msblake for the responses!

As Scott @msblake said it doesn't need the correct password, i tried entering a random password when adding the JDS distribution point, it let me use it and added the JDS, i've just tested an autopkgr self service policy and it completed like a dream (a work based dream that is!)

Thanks again for the help, really looking forward to getting this out there!

[elliotjordan]

@May and @msblake, you're right — although AutoPkgr still includes username/password UI, JSSImporter no longer requires those items (and just ignores them if entered).

We'll be updating AutoPkgr again soon, and that UI will be updated to match the new behavior.

[anamosa]

I am getting these errors (although it is picking up some new packages):

The following software is now available for testing:
install: Version not detected
install: Version not detected

The following error occured:

Error running recipes
/Library/Python/2.7/site-packages/python_jss-0.5.4-py2.7.egg/jss/contrib/requests/packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName, falling back to check for a commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SecurityWarning /Library/Python/2.7/site-packages/python_jss-0.5.4-py2.7.egg/jss/contrib/requests/packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName, falling back to check for a commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SecurityWarning /Library/Python/2.7/site-packages/python_jss-0.5.4-py2.7.egg/jss/contrib/requests/packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName, falling back to check for a commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SecurityWarning /Library/Python/2.7/site-packages/python_jss-0.5.4-py2.7.egg/jss/contrib/requests/packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName, falling back to check for a commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SecurityWarning Could not find parent recipe for MicrosoftRemoteDesktop.jss No valid recipe found for MicrosoftRemoteDesktop.jss /Library/Python/2.7/site-packages/python_jss-0.5.4-py2.7.egg/jss/contrib/requests/packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName, falling back to check for a commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SecurityWarning /Library/Python/2.7/site-packages/python_jss-0.5.4-py2.7.egg/jss/contrib/requests/packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName, falling back to check for a commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SecurityWarning /Library/Python/2.7/site-packages/python_jss-0.5.4-py2.7.egg/jss/contrib/requests/packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName, falling back to check for a commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SecurityWarning Could not find parent recipe for iPhoto.jss No valid recipe found for iPhoto.jss Could not find parent recipe for iMovie.jss No valid recipe found for iMovie.jss /Library/Python/2.7/site-packages/python_jss-0.5.4-py2.7.egg/jss/contrib/requests/packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName, falling back to check for a commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SecurityWarning Could not find parent recipe for Pages.jss No valid recipe found for Pages.jss /Library/Python/2.7/site-packages/python_jss-0.5.4-py2.7.egg/jss/contrib/requests/packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName, falling back to check for a commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SecurityWarning

[elliotjordan]

@anamosa I see three main errors there:

1) "SecurityWarning: Certificate has no `subjectAltName, falling back to check for a commonName` for now"

I believe this one is just a warning and can be ignored, unless you find that it's actually preventing packages from being downloaded. As JSSImporter and urllib3 are updated, this type of warning will probably get fixed.

2) "Could not find parent recipe for MicrosoftRemoteDesktop.jss" and 3) "No valid recipe found for MicrosoftRemoteDesktop.jss"

You may want to inspect this .jss recipe (and others generating this error) and see if it requires a parent recipe. If so, be sure to add the repo that contains that parent recipe.

You'll also want to make sure, if you haven't already, that you have the latest version of JSSImporter, AutoPkg, and AutoPkgr.

Hope that helps!

[adamcodega]

@elliotjordan][/url is very responsive but best place to post issues is the [AutoPkgr GItHub](github.com/lindegroup/autopkgr/issues). Unless the rest of us get post notifications for the rest of time. :-D

[clifhirtle]

Late to this post party but just wanted to chime in quickly and say how great an effort @elliotjordan and others have done with AutoPkg and various recipe ecosystem here. Been nearly a year since I was last toying around and the its wonderful to see how the solution has grown. Just discovered some of the thin imaging recipes posted in the various repos and just wow. Great work from all involved!

[esantiago]

Has Anyone found a fix for :

Error getting distribution points
"The Casper server's response could not be correctly interpreted."
?
"/

[elliotjordan]

Hi @esantiago — if you're having AutoPkgr-related issues, I'd encourage you to submit them here.

That being said, you might discover additional detail by running your .jss recipes manually in the Terminal, like this:

autopkg run Firefox.jss -v

Once you've isolated and resolved the error that way, you can let AutoPkgr do its thing.

[leoos]

I'm wondering if its possible to make Self Service and Auto recipes using overrides but to scope them to different groups. In my case I want student computers in my college to get some updates such as Firefox and the like automatically through Auto Update Magic and already have this running. On the other hand I want my staff to have the option to install via Self Service.

[elliotjordan]

@O'Sullivan - yes, that's possible. You'll want to use a variant of the instructions I recently updated here.

In the RecipeOverrides folder, you would have two overrides for the Firefox.jss recipe, and two PolicyTemplate.xml files, and two SmartGroupTemplate.xml files. One set of each of these files would serve the latest version of Firefox automatically to the student computers, and the other set would put the latest version of Firefox in Self Service for the staff.

It doesn't matter what you name these files, so I'd suggest something that will be easy to parse 6-12 months from now when you're making changes. Just make sure both the Firefox (student) jss recipe and the Firefox (staff) jss recipe are checked in AutoPkgr, and that inside each recipe they're pointing to their respective xml template.

[leoos]

Thanks for that. I've got that up and running in a test there now.

Can I also make a modified Smart Group Template so that I can have smart groups for staff so that an application will only show up in their Self Service if the app they are currently using is out of date.

for example a

Firefox-SelfService-smart (for my staff) similar to the Firefox-update-smart (for my students)

[elliotjordan]

@O'Sullivan yes, also possible. Just make sure that the SmartGroupTemplate.xml file in use by your staff-specific Firefox.jss recipe override includes the two necessary criteria (in addition to whatever criterion you're using to determine what defines a "staff" computer):

        <criterion>
            <name>Application Title</name>
            <priority>0</priority>
            <and_or>and</and_or>
            <search_type>is</search_type>
            <value>%JSS_INVENTORY_NAME%</value>
        </criterion>
        <criterion>
            <name>Application Version</name>
            <priority>1</priority>
            <and_or>and</and_or>
            <search_type>is not</search_type>
            <value>%VERSION%</value>
        </criterion>

[McAwesome]

Do you happen to know if there is a good way to force a naming scheme on the packages? I'd love to make sure all autopkg packages start with "AUTO-" to make organizing much easier. I have that working on most recipes by altering the NAME key via overrides(so NAME = AUTO-Mozilla-Firefox instead of Firefox), but some don't actually build a new package so they never change their name. A good example would be any of the Java, Silverlight, or Office recipes.

[elliotjordan]

@McAwesome you may need to override an upstream recipe (Silverlight.pkg, for example) if you want to change the name of the file itself. Then set your Silverlight.jss recipe override to use your Silverlight.pkg override as its parent.

YMMV. I've not had any need to do this myself.

[McAwesome]

@elliotjordan That's unfortunate. I was really hoping it'd support having different values in NAME and FILENAME like Casper in general does. I couldn't get an override to affect one and not the other. JSSImporter seems to always set NAME to FILENAME. I guess that's because there's not really a PackageTemplate like there is a SmartGroupTemplate and PolicyTemplate.

[elliotjordan]

@McAwesome - Overriding the default Firefox.pkg recipe and changing the pkgname key should get you what you want:

                <key>pkgname</key>
                <string>AUTO-%NAME%-%version%</string>

Note the identifier of the Firefox.pkg override:

    <key>Identifier</key>
    <string>local.pkg.AUTO-Firefox</string>

And specify that identifier as your Firefox.jss override's parent:

        <key>ParentRecipe</key>
        <string>local.pkg.AUTO-Firefox</string>

The result of running autopkg run AUTO-Firefox.jss should be this:

And you can run these special "AUTO-" overrides side by side with your regular .pkg and .jss recipes, if so desired.

[McAwesome]

@elliotjordan Yes, that's close to what we do currently. We've modified the NAME in the INPUT fields in the jss recipe's override to be what we want. It works for many, but not all, recipes. I tried your above method on the packages that our current method doesn't work on. For those pkgs, they already exist and the recipe is just downloading them. Nothing gets built, so no name from the recipe is entered. So the OracleJava8-1.8.45.14.pkg already existed and will not have its name changed by AutoPKG. Neither of our approaches fix that issue.

The NAME variable(as JAMF sees it) would just be useful for these admittedly niche situations. I guess it joins things like PRIORITY, BOOT_VOLUME_REQUIRED, INFO, and NOTES on the list of fields that aren't yet available or essential but would make handy additions in future builds.

[karlmikaeloskar]

I have an issue where the upload to the JSS fails. I do not have a smb/afp share so I need to upload directly to the JSS. Autopkg creates scripts, attributes etc but it fails to upload the package file. I'm testing with the Chrome pkg but others have failed as well.
The package is reported as "Missing" in Casper admin.
I've added this to my settings but no luck. (according to https://github.com/sheagcraig/JSSImporter#jds-jamf-distribution-servers)

<key>JSS_REPOS</key>
    <array>
        <dict>
            <key>type</key>
            <string>JDS</string>
        </dict>
    </array>

Do you suggest trying to get this to work or is it easier set up a smb share for this purpose only?

[McAwesome]

@karlmikaeloskar I ran into the same issue. Basically, even if you're running auto-pkg on the same machine as the JSS, you need to configure distribution points or it won't actually work. It's a weird quirk but at least it is an easy one to resolve.

If you are using AutoPkgr, they have a really handy interface that will prompt you for the needed information. Also having a GUI is always helpful.

(Edit) I believe the reasoning is that it send the info(policy, group, etc) on it over the API, but needs to mount the share to actually move the file.

[monosodium]

@elliotjordan I am getting a weird error when trying to just run AutoPKG:

[ERROR] socket.gaierror: [Errno 8] nodename nor servname provided, or not known

I have already configured the Distribution Points, setup the API user in the JSS and checked permissions there. Any suggestions would be appreciated as I am getting really excited to use this.

Thanks!