PatchManagementTemplate.xml?

[shawnhonsberger]

Hi there everyone! What would you think of something like this to standardize package upload for use with Jamf's new Patch Management? If we want to stop building Policies and Smart Groups, I understand that we can delete the templates from our overrides. I was just wondering if this might be a cleaner type of method to use going forward? I don’t know and wanted to hear everyone's thoughts. Thanks! :)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <package>
        <name>%JSS_INVENTORY_NAME%</name>
        <category>%CATEGORY%</category>
        <filename>%NAME%</filename>
        <package_info></package_info>
        <package_notes></package_notes>
        <priority></priority>
        <parameters></parameters>
        <package_configuration></package_configuration>
        <os_requirements></os_requirements>
        <self_service_icon></self_service_icon>
    </package>
</plist>

[grahampugh]

I'm not sure how this would work yet. There seem to be many unknowns.

1. How do we automate the acceptance of the patch management waiver agreement via API?

2. How do we add a new Patch Software Title by API?

3. How do we attach a package to a software_version entry using the API? I just manually added a couple of versions of Chrome to patch titles, and I can't see any difference in the patches API objects. Where does that information get recorded?

4. How could we scope software to devices that don't currently have it installed? I know that the standard JSS recipe format is to only scope to devices that already have a title installed, but I override the SmartGroupTemplate.xml for all recipes so that members of the Testing group without the software title also get the title in Self Service, so I don't have to manually create policies. This would be a problem if we only used Patch Policies, which don't (currently) have the option to scope to computers without a version of the title already installed.

5. How do we attach scripts, extension attributes and so on to recipes? Although patch policies will do away with the scripts and extension attributes that determine version numbers, what about scripts that provide configuration? Without AutoPkg/JSSImporter I would have to create a different mechanism for creating these policies.

I do think there will be an opportunity to add a further processor to JSSImporter which (somehow) attaches a package name entry to a patch software_version, once it's figured out how you do that, and once you can create your own patch policies beyond the 40 current titles available, but I don't think patch is (yet) a replacement for policies. There still seems to be a lot of work to do, and it currently seems to be that you need a completely separate server from which to serve the version inventory of titles not provided by Jamf. I've no idea how that could integrate with JSSImporter at this point.

In any case, I think that JSSImporter would have to continue to provide the ability to make a testing policy with an appropriate smart group, script and extension attribute as required, with the option to attach a package to a patch title version, and then patch can potentially simplify the update workflow for production machines.

[shawnhonsberger]

Hi @grahampugh Thanks for your thoughts. I totally agree, here are the answers to the best of my abilities.

1. This part needs to stay manual so that admins can accept their own risk.
2. This part also needs to stay manual because the titles need to be added before Definitions or Policies can be made.
3. I get the version from the download or pkg recipe usually, if they don't have it I build it into the jss recipe override. I haven't noticed any need to change it. The packages built by the current recipe overrides have thus far matched the versions supplied in Patch Policies, it has been easy to select these in Definitions. Please let me know if I'm misunderstanding your question(s).
   4 & 5. I think that normal recipe overrides that use Policy and Smart Group Templates will still be relevant for a long time. This was just an idea that would only pertain to Patch Policies, on top of an environment where Policy and Smart Group Templates are still in use. I may not be thinking about it correctly.

Please let me know if that makes sense. Thank you.

[shawnhonsberger]

@sheagcraig @grahampugh I'm looking into the API and I'm a little confused with what I see. Here is an example of a Patch Policy and a Patch Management Software Title:

Patch Policy:
<patch_policy>
  <general>
    <id></id>
    <name></name>
    <enabled>true</enabled>
    <target_version></target_version>
    <release_date></release_date>
    <incremental_update></incremental_update>
    <reboot></reboot>
    <minimum_os></minimum_os>
    <kill_apps>
      <kill_app>
        <kill_app_name></kill_app_name>
        <kill_app_bundle_id></kill_app_bundle_id>
      </kill_app>
    </kill_apps>
    <distribution_method>selfservice</distribution_method>
    <allow_downgrade>false</allow_downgrade>
    <patch_unknown>false</patch_unknown>
  </general>
  <scope>
    <all_computers>true</all_computers>
    <computers/>
    <computer_groups/>
    <users/>
    <buildings/>
    <departments/>
    <limitations>
      <network_segments/>
      <ibeacons/>
    </limitations>
    <exclusions>
      <computers/>
      <computer_groups/>
      <users/>
      <buildings/>
      <departments/>
      <network_segments/>
      <ibeacons/>
    </exclusions>
  </scope>
  <user_interaction>
    <install_button_text>Update</install_button_text>
    <self_service_description/>
    <self_service_icon/>
    <notifications>
      <notification_enabled>true</notification_enabled>
      <notification_type>Self Service</notification_type>
      <notification_subject> update available</notification_subject>
      <notification_message/>
      <reminders>
        <notification_reminders_enabled>true</notification_reminders_enabled>
        <notification_reminder_frequency>1</notification_reminder_frequency>
      </reminders>
    </notifications>
    <deadlines>
      <deadline_enabled>true</deadline_enabled>
      <deadline_period>7</deadline_period>
    </deadlines>
    <grace_period>
      <grace_period_duration>15</grace_period_duration>
      <notification_center_subject>Important</notification_center_subject>
      <message>$APP_NAMES will quit in $DELAY_MINUTES minutes so that $SOFTWARE_TITLE can be updated. Save anything you are working on and quit the app(s).</message>
    </grace_period>
  </user_interaction>
  <software_title_configuration_id></software_title_configuration_id>
</patch_policy>

Patch Management Software Title:
<patch_management_software_titles>
  <size></size>
  <patch_management_software_title>
    <id></id>
    <name></name>
    <name_id></name_id>
  </patch_management_software_title>
</patch_management_software_titles>

[aarondavidpolley]

Hey Guys,

Just adding some thoughts to this thread. The best way to add patch management support to autopkg/jss-importer I believe would be through automating how to put definitions into a 3rd party patch server. The options of 3rd party patch servers at this point in time are:

https://github.com/mondada/kinobi/
https://github.com/brysontyrrell/PatchServer

The latter has the addition of an API ready to take some automation, with this as example of whats possible:

https://github.com/brysontyrrell/Patch-Starter-Script

I'm no python coder, but thinking someone could write in some code add the definitions to the 3rd party patch server while making the patches ready in the DP.

Last piece of the puzzle would be adding the definition to patch management via API and then linking the package (would could be phase 2 or 3 of the implementation). It think just getting the autopkg runs to create the definitions in the patch server would be a great start

Thoughts welcome :)

[aarondavidpolley]

Just reviving this thread, found this:

https://gitlab.nbi.de/itsm-public/itsm-recipes

[homebysix]

Closing issue due to repo deprecation and archive.