Check script for managed_updates manifest items always produces actionNeeded of false

[serrc-techops]

When utilizing a check script for items in the managed_updates manifest key, actionNeeded is always going to be false. This is happening because installType == "update" is not included in the pkg > status > status.go > checkScript > actionNeeded If statement. A fix is:

// Application not installed if exit 0
if installType == "uninstall" {
	actionNeeded = !cmdSuccess
} else if installType == "install" || installType == "update" {
	actionNeeded = cmdSuccess
}
return actionNeeded, checkErr```

[danhutchings]

Hi @serrc-techops !

Based on the nature of how managed_updates are intended to work, those items are to only update if they are installed. So, I'm curious why a file or registry check will not work for an item that is supposed to be installed already.

Does the item/app you are intending to manage the update on not provide a lot of good options for those two checks?

That said, I think you've raised an interesting issue nonetheless.

[serrc-techops]

Through Gorilla, I use Chocolatey to install and update some basic applications (i.e. Chrome, VLC, etc) using the community repository. Some of those applications are managed installs, and some are managed updates. In the checkinstall scripts, first choco is used to determine the current installed version of an application and if that fails then the registry is referenced to see if an application has been manually installed and if so extracts that version number. That checkinstall script also retrieves the current version of the application available in the Chocolatey community repository and then compares that to the version installed on the client. So in this case since I'm using choco to somewhat automate things, I don't actually have a file or registry to check. If I were specifying which version of the application that choco should install then I could use the registry check but I'm not necessarily worried about the version control on some of these basic applications. This method makes managing the software updates pretty simple on my end since I don't have to worry about importing new versions, gathering the hash values, etc.

…

On Mon, Oct 24, 2022 at 4:33 PM danhutchings ***@***.***> wrote: Hi @serrc-techops <https://github.com/serrc-techops> ! Based on the nature of how managed_updates are intended to work, those items are to only update if they are installed. So, I'm curious why a file or registry check will not work for an item that is supposed to be installed already. Does the item/app you are intending to manage the update on not provide a lot of good options for those two checks? That said, I think you've raised an interesting issue nonetheless. — Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4ENG2G46EKFVXIE67EVM3WE4THBANCNFSM6AAAAAAQZLHBII> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[danhutchings]

I appreciate your thorough explanation here. Thank you for that.

It sounds like a good path forward for your use case would potentially be this. For a managed_update or managed_install item, use a file check to check for the existence of a file on the system, including the hash or version. Then use a ps1 installer to carry out the Chocolatey install/update. I have yet to see any application that did not store at least some kind of binary on the file system. That is why I'm suggesting a file check.

Here's an example yaml config:
Manifest yaml:

managed_installs:
  - Slack
managed_updates:
  - Firefox

Catalog yaml:

Slack:
  item_name: Slack
  check:
    file:
      - path: C:\Program Files\Slack\slack.exe
        version: 4.27.154.0
  display_name: Slack
  installer:
    location: packages/slack/slack-choco-updater.ps1
    hash: cb3be42f1e17b50ca9eba8fc64a8b2a5530fecf2ed57a1021b52ae612a276a47
    type: ps1
  version: 4.27.154.0
Firefox:
  item_name: Firefox
  check:
    file:
      - path: C:\Program Files\Mozilla Firefox\firefox.exe
        version: 103.0.1.0
  display_name: Firefox
  installer:
    location: packages/slack/firefox-choco-updater.ps1
    hash: d0877e030bb400c9642027e279c7faad3633f4d49cada2ad94577253ab3711db
    type: ps1
  version: 103.0.1.0

[serrc-techops]

Thanks for the response. Doing a file check would definitely work if I were to know what the latest version of an application is that exists in the choco community repository or what that hash value would be. Ideally I'm wanting to not have to make a change to the catalog each time a new application version is added to the Chocolaty community repository. The choco app makes that easy to accomplish in an installcheck_script because it is able to query the repository for the version number of the latest software. Is there a disadvantage to using an installcheck_script to determine if managed_updates are in need of installing?

…

On Tue, Oct 25, 2022 at 1:26 PM danhutchings ***@***.***> wrote: I appreciate your thorough explanation here. Thank you for that. It sounds like a good path forward for your use case would potentially be this. For a managed_update or managed_install item, use a file check to check for the existence of a file on the system, including the hash or version. Then use a ps1 installer to carry out the Chocolatey install/update. I have yet to see any application that did not store at least some kind of binary on the file system. That is why I'm suggesting a file check. Here's an example yaml config: Manifest yaml: managed_installs: - Slack managed_updates: - Firefox Catalog yaml: Slack: item_name: Slack check: file: - path: C:\Program Files\Slack\slack.exe version: 4.27.154.0 display_name: Slack installer: location: packages/slack/slack-choco-updater.ps1 hash: cb3be42f1e17b50ca9eba8fc64a8b2a5530fecf2ed57a1021b52ae612a276a47 type: ps1 version: 4.27.154.0 Firefox: item_name: Firefox check: file: - path: C:\Program Files\Mozilla Firefox\firefox.exe version: 103.0.1.0 display_name: Firefox installer: location: packages/slack/firefox-choco-updater.ps1 hash: d0877e030bb400c9642027e279c7faad3633f4d49cada2ad94577253ab3711db type: ps1 version: 103.0.1.0 — Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE4ENG4QB24XVDQXAUVLZRDWFBGBPANCNFSM6AAAAAAQZLHBII> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[danhutchings]

Thanks for the additional context here. Gorilla catalogs are intended to be used as a desired state of items. You'll need to specify a version or hash so that Gorilla knows that a desired state is reached.

One thing Gorilla does via its file and registry checks is do a comparison to see if the installed version is newer than what is configured in the catalog(s). If the installed version is newer, it doesn't take any action. With that in mind, you could probably write up a separate script that polls the Chocolatey community for the most recent versions of the applications you are trying to manage, and then update the catalog(s). This will make it so that your catalog has up to date version information, and you can still use your Chocolatey script to install the app(s). This also accomplishes your goal of not wanting to maintain a Gorilla repo full of packages.

I hope this helps!