#1052 Fix osquery version check and RPM upgrade in the enroll script Pull request opened by javuto Fix osquery version check and RPM upgrade in the enroll script The quick-enroll shell template — the one osctrld fetches to keep osquery installed and current — could never upgrade a node that was behind. The version comparison was inverted if [ "$(echo "$_OSQUERY_VER:$osquery_version" | tr ':' '\n' | sort -rV | head -n 1)" != "$_OSQUERY_VER" ]

sort -rV | head -1

yields the higher of the two versions, so the branch fired only when the installed version was ahead of the required one: | required | installed | old behavior | new behavior | | -------- | --------- | --------------------------------- | ------------------- | | 5.23.1 | 5.19.0 | nothing — stayed behind forever | upgrade | | 5.19.0 | 5.23.1 | downgrade | leave alone, log it | | 5.23.1 | 5.23.1 | nothing | nothing | The decision now lives in a named

osqueryNeedsInstall()

function. A node that is ahead is left alone rather than downgraded — the old code attempted a silent fleet-wide downgrade, which is worse than running newer than asked. Flip one line if exact-version pinning is what you want instead.

rpm -ivh

could not upgrade

rpm -i

fails outright when the package is already installed — exactly the upgrade case — so even with the comparison fixed, RPM hosts would error. Now

rpm -Uvh

(install or upgrade). Debian (

dpkg -i

) and macOS (

installer -pkg

) already handled both. Tests These templates are shell embedded in Go string constants: nothing compiles or lints them, which is how an inverted comparison shipped.

scripts_test.go

extracts

osqueryNeedsInstall

from the shipped template text and runs it under

/bin/sh

— assertions are against what endpoints actually receive, not a copy. Six cases, including

5.9.0

vs

5.10.0

, which lexical comparison gets backwards. Verified failing against the pre-patch template. Not fixed here: Windows The PowerShell template installs only when

osqueryd.exe

is absent (

if (!(Test-Path $osqueryDaemon))

) — it never reads or compares a version, so a Windows node behind the required version stays behind. Same defect by omission. Fixing it means adding version detection and an MSI upgrade path to a ~279-line template that no CI exercises; writing blind upgrade logic into an untested template is how these bugs arrived. It belongs in the native osctrld install path, where

GOOS=windows

code is testable with an injected command runner. jmpsec/osctrl