Improve Agent Install/Uninstall/Upgrade

[aleksmaus]

Disclaimer: This is based on some work I had to do digging in the install/upgrade/uninstall code paths and it’s possible that there are some things that are already in the works or I might have missed.

Problem statement

The current Agent install/uninstall/upgrade code paths are in different places depending on distribution RPM/DEB/TAR.GZ or the way the agent install/upgrade is managed. This makes it difficult adding the new features that require initial setup before the agent runs for the first time, leading to updating the code in different places (upgrade handle vs post install script vs on agent start up).
The uninstall code paths are different depending on distribution and the way it is invoked, for example, fleet managed vs RPM/DEP, leading to the different results (more files left behind for RPM/DEB uninstall)

Problem details

Presently, when you add new features that require set up before the agent runs, you would have to possibly update 3 different places:
The agent upgrade handler code (that is fleet use only)
The agent start up code (if this is something the older agent doesn’t know about)
Possibly update the RPM/DEB post-install script (as another code path for upgrade)

There are agent files left behind after RPM/DEB uninstall. This poses two possible issues: the disk space is never reclaimed, and there is a possibility these left over files could affect the future installs (no clean install after the system was “contaminated”).

Possible improvements

Consolidate multiple code paths for installing/upgrading/uninstalling the agent.The agent binary could potentially implement the command handlers for install/upgrade/uninstall that are called from both the action upgrade handler and the installer package.
There are already commands for "install" and "upgrade" but they are serving different use cases and not all the cases in case of "upgrade" command as example. Maybe pick the different command names.
This would lead to consistent behavior across all the distributions that is easy to maintain, change and test, would simplify adding the features that might need to be migrated/installed once during the install, and would allow us to handle the uninstall clean up consistently.

Open questions for discussion

• Should we revisit the agent directories structures for DEB/RPM? The install with the agent/fleet results in the files installed in different locations from the install from RPM. Would it be useful to be able to upgrade the agent with the fleet that was originally installed with RPM?
• Should we have the standard signed installer for Windows (MSI) and for Mac (PKG)? Looking at osquery as example of the distros they support: https://osquery.io/downloads/official/5.4.0

Thoughts?

[ph]

@pierrehilbert I would consider this as tech deb we might want to propriotize maybe after @narph changes goes in?

[ruckc]

Just my two cents here, as a human who has to wrangle hundreds of COTS/OSS software installations across multiple platforms.

Don't let fleet upgrade existing rpm/deb installs. This will break things security utilities such as rpmverify that are often used to perform checks for intrusion detection.

Please leverage MSI installs. They are trivial to automate.

[GeorgeGkinis]

We would also be interested with an MSI package so that the agent can be deployed using Group Poicies across our windows hosts.

[rsdrakh]

We would also be interested with an MSI package so that the agent can be deployed using Group Poicies across our windows hosts.

This is actually something I would expect from a software vendor that targets Enterprises. We are looking at 4000+ target systems atm with Windows to roll out Elastic Defend as Endpoint Security.

[mbudge]

Is there a git ticket to track the MSI installer?

This is required for deployment to enterprise networks with standard operating system build processes.

[pierrehilbert]

We have one open PR for the MSI installer here: elastic/elastic-stack-installers#212

[amitkanfer]

MSI installer is now available in 8.13:
https://www.elastic.co/downloads/elastic-agent

@aleksmaus what's more pending in this issue?

[aleksmaus]

@aleksmaus what's more pending in this issue?

Sorry, I barely remember what this was about, since this issue was opened in Aug 2, 2022 😂

The MSI installer checks one of the checkboxes as far as I understand.

Don't know how much work lately was done to improve/refactor/consolidate the upgrade the agent code paths for the different distributions. Probably worth double checking with Agent team before closing it.
@cmacknz @pierrehilbert

[pierrehilbert]

We still have different Agent installation path if we are installing through package managers but I don't think we have files remaining on disk after uninstallation anymore.

[aleksmaus]

We still have different Agent installation path if we are installing through package managers but I don't think we have files remaining on disk after uninstallation anymore.

Maybe worth closing this ticket and splitting off what is left regarding upgrades into the new tracker if anything.

[lucabelluccini]

I think this issue should be split into:

• 1 issue per package / installation type
• ensure each issue covers install/upgrade/uninstall (via Fleet & CLI + docs) in the considered as done statement

E.g. MSI seems fully covered as per https://www.elastic.co/guide/en/fleet/current/install-agent-msi.html#:~:text=Upgrades%20are%20not%20supported%20and%20are%20prevented%20by%20the%20MSI%20itself.%20Instead%2C%20all%20of%20your%20Elastic%20Agent%20upgrades%20can%20be%20managed%20in%20Fleet