Skip to main content
Question

10.13.2 Supplemental Update Workaround

  • January 8, 2018
  • 40 replies
  • 264 views

Show first post

40 replies

Forum|alt.badge.img+8
  • Valued Contributor
  • January 11, 2018

I also do not have the issue in JSS 9.101.4 running on an internal OS X box and external Windows box.


Forum|alt.badge.img+4
  • New Contributor
  • January 12, 2018

@mhasman [https://support.apple.com/kb/DL1951?viewlocale=en_US&locale=en_US](link URL)


mhasman
Forum|alt.badge.img+22
  • Valued Contributor
  • January 12, 2018

@cecotter Thank you Chris!


sepiemoini
Forum|alt.badge.img+21
  • Employee
  • January 12, 2018

+1 for opening a case with Jamf Support.

I've received the following from Jamf Support as a fix to this issue:

Step 1: Create database backup of the current data using the JSS Database Utility. We can navigate to our JSS Database Utility found in: Mac OSX Server: /Library/JSS/bin/JSSDatabaseUtil.jar Windows Server: C:Program FilesJSSinJSSDatabaseUtil.jar Linux: /usr/local/jss/bin/JSSDatabaseUtil.jar Step 2: We will then want to grab a backup of the current JAMFSoftwareServerDatabaseSchema.xml file by pasting it to the desktop or any other location. macOS - /Library/JSS/Tomcat/webapps/ROOT/WEB-INF/xml/ Windows - C:Program FilesJSSTomcatwebappsROOTWEB-INFxml Linux - /usr/local/jss/tomcat/webapps/ROOT/WEB-INF/xml/ Step 3: We will want to modify that file and replacing what is currently there with the new data. Specifically the <type>varchar</type> value in the <table_name>available_software_updates</table_name> section. Old <name>version</name> <type>varchar</type> <size>31</size> New Data <name>version</name> <type>varchar</type> <size>255</size> Step 4: Once we have saved the changes we will want to restart Tomcat, and that can be done by using the JSS Database Utility again.

I haven't implemented this yet but imagine it'll resolve the issue. Have others received the same steps?


donmontalvo
Forum|alt.badge.img+36
  • Hall of Fame
  • January 12, 2018

Yep that’s the fix.


Forum|alt.badge.img+8
  • Contributor
  • January 12, 2018

@sepiemoini Not trying to be pedantic, but the "New Data" portion of your snippet should really include the <table> and <table_name> tagged lines from the "Old" portion since the fix is to change the value for <size>, without eliminating the <table> and <table_name> lines as your post could be read as to suggest (and I realize you probably just pasted what Jamf support provided).


sepiemoini
Forum|alt.badge.img+21
  • Employee
  • January 12, 2018

Agreed @StoneMagnet and also taken directly from Jamf Support. I've modified it now to be more accurate. Thoughts?

Step 3: We will want to modify that file and replacing what is currently there with the new data. Specifically the <type>varchar</type> value in the <table_name>available_software_updates</table_name> section. Old <name>version</name> <type>varchar</type> <size>31</size> New Data <name>version</name> <type>varchar</type> <size>255</size>

sdagley
Forum|alt.badge.img+25
  • Jamf Heroes
  • January 13, 2018

@sepiemoini Thanks for making that change (wouldn't have wanted someone to stumble on this thread and take the original Step 3 at its word and destroy the table if they didn't realize what was actually the fix in that snippet).

Of course the correct fix would be for Jamf to sanity check the inputs for limited size table fields because assuming a field will never exceed 255 characters (Str255 sound familiar to anyone?) is just as dumb as assuming it will never exceed 31 characters, you're just less likely to get bitten by it.


Forum|alt.badge.img+7
  • Contributor
  • February 15, 2018

For those that applied this workaround please note:
Updating to a new version of JAMF pro will result in your server not starting back up as in: https://www.jamf.com/jamf-nation/articles/349/troubleshooting-the-jss-startup-suspended-issues

Don't panic, the value in the JAMFSoftwareServerDatabaseSchema.xml file was reverted to it's original state. Stop the JAMF service, re-edit the value back to 255 and start JAMF. Use this at your own risk.


Forum|alt.badge.img+8
  • Contributor
  • February 15, 2018

Does the 10.2.0 update fix the root of the problem? Seems that we should not have to manually update database schema. And, if the value is reverted, it would not seem that JAMF resolved the issue.


Forum|alt.badge.img+7
  • Contributor
  • February 15, 2018

The 10.2.0 updated just reverted the database schema for this value to the old state. So for this version it wasn't fixed.

@sepiemoini could you maybe ask for JAMF's view on this by re-opening the supportcase?


sepiemoini
Forum|alt.badge.img+21
  • Employee
  • February 15, 2018

@remyb I’ll do you one better! @scafide Would you be able to weigh in on the schema settings not being rolled out with 10.2.0?


scafide
Forum|alt.badge.img+21
  • Author
  • Community Manager
  • February 15, 2018

Thanks for the tag @sepiemoini!

The fix was done in-code, so this specific change to the JAMFSoftwareServerDatabaseSchema.xml is no longer relevant. If you are having start-up issues after putting your previous JAMFSoftwareServerDatabaseSchema.xml back in place, replace your modified file with the one created by the installer, or contact Jamf Support.

Thanks!


Forum|alt.badge.img+8
  • Contributor
  • February 16, 2018

Good Morning,

So, if I understand completely, the patch inventory issues that were discovered with the 10.13.2 supplemental release have been resolved?

Thanks all for the awesome communication!


scafide
Forum|alt.badge.img+21
  • Author
  • Community Manager
  • February 16, 2018

Hey @acaveny,

Yep, that issue is resolved. There was a manual workaround that could be applied to the database schema file to get around the issue - that workaround is not necessary going forward, as we made a change in the code to accept unexpected naming conventions for available Software Updates.

Thanks!