[orbit/packaging] delay restart for in-band pkg upgrade on Linux - #31286
Conversation
📝 WalkthroughWalkthroughThis update changes how the DEB and RPM packages for Orbit handle upgrades. It adds logic to safely restart the Orbit service during in-band upgrades and improves the uninstall scripts to avoid stopping the service unnecessarily during upgrades. Documentation is updated to explain the new upgrade process. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🧰 Additional context used🧠 Learnings (2)orbit/changes/31286-package-upgrade-fix (1)Learnt from: getvictor orbit/pkg/packaging/linux_shared.go (2)Learnt from: sgress454 Learnt from: sgress454 🔇 Additional comments (6)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
6726ab6 to
8ac2fbb
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #31286 +/- ##
==========================================
- Coverage 62.04% 62.04% -0.01%
==========================================
Files 1912 1912
Lines 188280 188303 +23
Branches 5548 5548
==========================================
+ Hits 116827 116840 +13
- Misses 62117 62125 +8
- Partials 9336 9338 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Admins _should_ be upgrading orbit/osqueryd/fleet-desktop using TUF, but there's no official path for pushing updates to the orbit environment file (`/etc/default/orbit`). Knowing that this file is installed by fleet-osquery, I naively pushed a new fleet-osquery package to a user's machine, thinking that would be fine installing over the existing package. Instead it actually broke orbit entirely on the host, rendering it unreachable until the user manually reinstalled the package. This is because the pre-removal script unconditionally stops orbit even if it's being upgraded, and when orbit is stopped it terminates any processes underneath it, including the ongoing package installation. To workaround this, we replace the simple `systemctl restart orbit.service` with a check for the `INSTALLER_PATH` environment variable that orbit sets during software installations. If the variable is present, `systemd-run` is used to schedule the service restart 60 seconds in the future, which is assumed to be more than enough time for the package manager to finish and exit. Unfortunately, this bugfix cannot be made retroactive, because the broken version of the prerm script is called before the new package starts to be unpacked/installed. Although there are other ways of doing anything an administrator might be trying to accomplish by pushing a new fleet-osquery package, bricking an endpoint simply by pushing this package through the Software page seems like a pretty massive footgun that is easy to protect against. Signed-Off-By: Dan Fuhry <dan@fuhry.com>
8ac2fbb to
935afc7
Compare
|
Thanks for the contribution @fuhry ! Assigning to @sharon-fdm as the g-orchestration EM. |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
|
Also, since this is a |
Moved #31286 changes since this is a packaging change (part of fleet/fleetctl release) and not part of orbit release.
3 participants
Admins should be upgrading orbit/osqueryd/fleet-desktop using TUF, but there's no official path for pushing updates to the orbit environment file (
/etc/default/orbit).Knowing that this file is installed by fleet-osquery, I naively pushed a new fleet-osquery package to a user's machine, thinking that would be fine installing over the existing package. Instead it actually broke orbit entirely on the host, rendering it unreachable until the user manually reinstalled the package. This is because the pre-removal script unconditionally stops orbit even if it's being upgraded, and when orbit is stopped it terminates any processes underneath it, including the ongoing package installation.
To workaround this, we replace the simple
systemctl restart orbit.servicewith a check for theINSTALLER_PATHenvironment variable that orbit sets during software installations. If the variable is present,systemd-runis used to schedule the service restart 60 seconds in the future, which is assumed to be more than enough time for the package manager to finish and exit. Unfortunately, this bugfix cannot be made retroactive, because the broken version of the prerm script is called before the new package starts to be unpacked/installed.Although there are other ways of doing anything an administrator might be trying to accomplish by pushing a new fleet-osquery package, bricking an endpoint simply by pushing this package through the Software page seems like a pretty massive footgun that is easy to protect against.
Summary by CodeRabbit
New Features
fleetctl packagecommand via the Software page, after an initial manual update.Documentation
Bug Fixes