Closed homebysix closed 4 years ago
Hit me with the verbose output.
But yes-you're probably right. In the handle_icon
method there's a single FileUpload call. Why does it 404 the first time and not after that? I guess you could check the tomcat logs to see if there's any further ideas there.
Also, here's another question: So you get a 404... Is the icon there? Ignore the status code for a second-set up a situation where an icon is going to have to be uploaded "the first time" as per your initial description. Run the recipe the first time, get the 404, and then see if the icon shows up in the web interface. It may be that it's responding with a 404 even though it works!
Any update on this weird behavior @homebysix ?
Here's some verbosity:
First run:
JSSImporter
JSSImporter: Category type: category-'Digital Media' already exists according to JSS, moving on...
JSSImporter: Category type: policy_category-'Testing' already exists according to JSS, moving on...
JSSImporter: Package upload and object update skipped. If this is a mistake, ensure you have JSS_REPOS configured.
JSSImporter: Found file: jss-recipes/Silverlight/SilverlightExtensionAttribute.xml
JSSImporter: ComputerExtensionAttribute: SilverlightVersion created.
JSSImporter: Found file: jss-recipes/Silverlight/SilverlightSmartGroupTemplate.xml
JSSImporter: ComputerGroup: Silverlight-update-smart updated.
JSSImporter: Found file: jss-recipes/PolicyTemplate.xml
JSSImporter: Policy: Install Latest Silverlight created.
JSSImporter: Found file: jss-recipes/Silverlight/Silverlight.png
Response Code: 404 Response: Not Found. The server has not found anything matching the request URI
Failed.
Subsequent run:
JSSImporter
JSSImporter: Category type: category-'Digital Media' already exists according to JSS, moving on...
JSSImporter: Category type: policy_category-'Testing' already exists according to JSS, moving on...
JSSImporter: Package upload and object update skipped. If this is a mistake, ensure you have JSS_REPOS configured.
JSSImporter: Found file: jss-recipes/Silverlight/SilverlightExtensionAttribute.xml
JSSImporter: ComputerExtensionAttribute: SilverlightVersion updated.
JSSImporter: Found file: jss-recipes/Silverlight/SilverlightSmartGroupTemplate.xml
JSSImporter: ComputerGroup: Silverlight-update-smart updated.
JSSImporter: Found file: jss-recipes/PolicyTemplate.xml
JSSImporter: Policy: Install Latest Silverlight updated.
JSSImporter: Found file: jss-recipes/Silverlight/Silverlight.png
JSSImporter: Icon uploaded to JSS.
Receipt written to /Users/elliot/Library/AutoPkg/Cache/com.github.jss-recipes.jss.Silverlight/receipts/Silverlight.jss-receipt-20160527-132041.plist
I've also found that it's not simply a matter of running it "again," it's more likely a matter of running it "later." If the second run happens within about 20 seconds of the first run, the second run also fails. If I just wait longer and try again, success.
I'm convinced that the JSS does some server-side processing on uploaded icons, which causes a short delay before the icon officially "exists."
FWIW, I'm noticing this behavior as well.
@kitzy @homebysix any recommendations? Upload an icon, and wait for awhile, then upload again? Do icon at the beginning of the run, and then again at the end?
Also, we're working over great distances of time and space here; it's the FUTURE already.
Let me ask again, if you run a recipe that has no icon on the JSS and it gives you the 404 error, check and see if the icon exists anyway. It's quite possible that the server-side actually accepts it and starts working on it or whatever, but still returns a 404.
I'm not sure, but every time you do FileUpload
it creates a duplicate in the icons list right? So if you set up this situation, after the second "successful" (according to JSSImporters guesswork) run, are there two icons? This would make sense because the policy wouldn't get updated and saved with the icon name, so the code flow would hit the icon.save()
again.
I've been experiencing this 404 error constantly. Even when a Self Service icon exists and I believe it's to do with trying to upload the package in my instance. JSS Importer will go so far as to create the record in the database for the package but will not upload it to S3 so shows as Missing in Jamf Admin
@smithjw I now you have much pain with Icons! I'm not familiar with what the public feature request situation is like; can we pressure Jamf to improve icon handling? It would be nice to be able to just interact with Icons in a modern way. And you know, delete them.
Are you sure it's just icons?
I see 404 on creation of a groups, policies, icons, categories, package. Basically anything jss-importer is creating in the jss.
If I flush the cache for the recipie, and re-run the recipie, jss-importer sees whatever 404 out is now there and moves onto the next step. For an established policy, ushally that just means one 404 on the package. But for a new policy, you could have to run the recipie many times to get everything to create.
@AllWorkAndNoPlay this issue is for icons, so if you're seeing that across all objects, let's start another issue I guess? Unless you think it's the same issue.
I'm interested to know what kind of repository, which version of JSSImporter, and which version of Jamf you're using.
@sheagcraig it could be releated, if for instance it's a genreal connection time out issue. Or a genreal change to how the jss creates objects.
autopkg 1.0.4, git 2.10.1, jssimporter 1.0.0, JSS 10.3.1, jamfcloud
I'm using a custom instance of Jamfcloud, the issue described there happens everytime I created an object. So I had a pause in the built in python jss. You just need to had a time.sleep() at the line 550 in jssobject.py @sheagcraig how can I fork this python-jss version?
@sebtomasi if you still have this issue and are using a fork, I'd be glad to take a PR. I added a similar check in JSSImporter.py but specifically for package objects.
Wait loop is now built in to JSSImporter.
When running a JSS recipe for the first time, I almost always get a 404 error during the process of uploading a PNG icon. Running the recipe a second time almost always results in success, and the issue resolves itself.
I suspect this is an issue with the JSS API, not with JSSImporter, but I wanted a record of this behavior I can point people to, thus this issue.