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

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

@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.

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.

@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.

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!

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 ?

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.)

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.

@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.

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!

@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.

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

@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!

@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

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!

Has Anyone found a fix for :

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

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.

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.

@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.

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)

@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>

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.

@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.

@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.

@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.