search

jssimporter / JSSImporter

JSSImporter is deprecated. Please see the wiki for alternatives
Apache License 2.0
145 stars 38 forks source link

Corrected typo and added link to Bryson's PatchServer in comments #129

Closed krypted closed 3 years ago

krypted commented 6 years ago

Corrected typo in line 696 and added link to Bryson's PatchServer in comments when we kick off the patch server post to json

sheagcraig commented 6 years ago

Hello sir, I pulled this down and made some changes; most of which were style.

The big ones were removing the hardcoded Google Chrome data and rewriting stuff to use curl since we can't easily add requests (back) as a dependency to this project.

A few questions I had:

  1. What does a response, both successful and failed, look like from the patch server?
  2. As it stands, there's no auth or SSL going on with these posts. I'm guessing that's not how this would work in actual use. So we'll need that in as well.
  3. AutoPkg may not necessarily always have BundleID available; or other data like Publisher, minimum operating system, etc. JSS recipes can be updated to extract this data, but then we would need to have a codified way for stashing that information in the AutoPkg environment dictionary. I think this is where the most work is going to have to happen.

I think you should be able to rebase off of my krypted-master branch to get this one up to date with my changes.

yuresko commented 6 years ago

Hello @sheagcraig ,

I am working with Charles on implementing these changes and testing on my servers. Do you anticipate the Patch Server URL to be hardcoded where you would normally put in your Jamf API creds? Or somewhere in the script? And too, Bundle ID is not an imminent need, just a nice to have on the Patch Server.

Let me know your thoughts, thanks!

sheagcraig commented 6 years ago

Hi @yuresko, So my expectation would be that the Patch Server URL would be stored in the same preferences file that JSSImporter uses for all of its other settings..

grahampugh commented 5 years ago

@yuresko Would it be realistic to think that each patch recipe might point to a different patch server? For instance, many recipes might point to Bryson’s community patch server, but one might need an internal or separate patch server for in-house apps. If so, we will need to specify the URL in the recipe itself.

Also, can this process work without the preamble associated with patch? For example, does it ensure that the patch user agreement has been agreed via the UAPI? Does it create a fresh patch definition object (forgive me if I’m getting the terminology wrong) or does it already need to exist? It would be nice if it worked “out of the box”.

grahampugh commented 3 years ago

I suspect this is dead but will leave it here in case and of the authors wish to pursue it,

grahampugh commented 3 years ago

Fair to say that this is dead.