@adamcodega, Here is how i have it setup and it will not connect, Everything looks correct in the JSS according to the steps on the doc.

external image link
external image link

@Shawn.Waller Whoops! I forgot us JAMF Clouders need to run the AutoPkgr beta released after discussing JAMF Cloud with Eldon. You can find the link here.

Awesome thanks!

As you can see in my discussion I still don't have it working 100% but I'm excited to help contribute to the project. Let us know how it works for for you too.

For sure! Will do.

For all with the ssl handshake issue, see this post https://github.com/sheagcraig/jss-autopkg-addon/issues/9#issuecomment-61490994

@bauer.cole, glad you were able to get it to work!

@jlejeune, you'll want to learn more about @nmcspadden's AppStoreApp recipe. This isn't something I've used yet, but his readme seems like a good primer.

@Gabriel.Duff @lashomb @emilykausalik You're right, we don't yet support cloud-hosted JSS. We'd like to release an update soon that will address this. If any developers want to help, find us on GitHub.

@Shawn.Waller try using

https://sirva.jamfcloud.com

instead of

https://jss.jamfcloud.com/sirva

@eahrold never knew that url! Thanks!! I will give it a shot.

@Shawn.Waller, no problem.

Actually I just realized that may not work for everyone, that's the way we have it set up for the AutoPkgr dev team, where it redirects from

https://jss.jamfcloud.com/autopkgr --> https://autopkgr.jamfcloud.com

And the API won't work with the first.

But in some other tests I found it's not redirected, but it's worth a shot if you're still not able get it going with the build on my fork's page https://github.com/eahrold/autopkgr/releases/tag/1.1.1-bugfix

Is there a version requirement on the JSS? Its working on my test machine but not on production (which is out of date).

Thanks!

I've tested on 9.30 through 9.51. I understand there were some problems with 9.6 because SSLv3 had been disabled, but there's a fix circulating.

Further testing is giving me two different issues:

First, regardless of the JSS version, Autopkgr is giving me url errors, even though I've saved the proxy information to the plist.

Can't open URL http://update.videolan.org/vlc/sparkle/vlc-intel64.xml Failed.

and

Couldn't download https://dl.google.com/chrome/mac/stable/GGRO/googlechrome.dmg: <urlopen error Tunnel connection failed: 407 Proxy Authentication Required> Failed.

Then second, I went to terminal to run a recipe on the 9.25 version of the JSS and get the following. (There is no such error on the 9.6 JSS)

PkgCreator: Package already exists at path /Users/username/Library/AutoPkg/Cache/local.jss.Firefox/Firefox-33.1.pkg.
PkgCreator: Existing package matches version and identifier, not building.
JSSImporter
Traceback (most recent call last):
  File "/usr/local/bin/autopkg", line 1334, in <module>
    sys.exit(main(sys.argv))
  File "/usr/local/bin/autopkg", line 1328, in main
    exit(subcommands[verb]['function'](argv))
  File "/usr/local/bin/autopkg", line 1152, in run_recipes
    autopackager.process(recipe)
  File "/Library/AutoPkg/autopkglib/__init__.py", line 466, in process
    self.env = processor.process()
  File "/Library/AutoPkg/autopkglib/__init__.py", line 295, in process
    self.main()
  File "/Library/AutoPkg/autopkglib/JSSImporter.py", line 571, in main
    ssl_verify=sslVerify, repo_prefs=repos)
  File "/Library/Python/2.7/site-packages/jss/jss.py", line 166, in __init__
    self.distribution_points = distribution_points.DistributionPoints(self)
  File "/Library/Python/2.7/site-packages/jss/distribution_points.py", line 75, in __init__
    dp = AFPDistributionPoint(URL=URL, port=port, share_name=share_name, mount_point=mount_point, username=username, password=password)
UnboundLocalError: local variable 'password' referenced before assignment

Any suggestions are appreciated.

Just set up a test. Looks really good. Thanks a lot.
Being new to autopkg; What would be the easiest way to make two polices for the same application?
Say that I'd like to have a fresh Firefox as a self-service policy for everyone (no problem with that) and an auto-update policy for Firefox (no problem with that either). What I'm looking for is the easiest way to clone the Firefox.jss recipe so I can use it for dual purposes. Or would it be possible to have both policies done with the same recipe?

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)

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

@gregneagle wrote:

This is far easier with Munki

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

Keep hoping Don!

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.

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.

Community support != support contract

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.

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.

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

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