-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Agent MSI support #206
Agent MSI support #206
Conversation
Extremely excited to see this work, thank you! |
➕ Thank you @amitkanfer! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for raising this @amitkanfer !
Took a first look at the Buildkite failure, left a question that might help us understand the problem.
Is it possible to enroll Agent using this MSI, or is a subsequent command required to enroll Agent? |
Working on it right now, should be possible. |
I have a working version now.
So for example, this works: After the MSI finished copying all the files, it'll run the install command for the newly deployed elastic-agent.exe file. The installer will wait for the install command to finish and only then will exit. Logic can be found here. Worth noting that the process is ran w/o the command prompt window in the background. What's missing:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple of comments
public class AgentCustomAction | ||
{ | ||
[CustomAction] | ||
public static ActionResult MyAction(Session session) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My guess is we also need a custom action for uninstall?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes we do. on it... not as straightforward as it seems, unfortunately.
var textInfo = new CultureInfo("en-US", false).TextInfo; | ||
var serviceDisplayName = $"{companyName} {textInfo.ToTitleCase(ap.TargetName)} {ap.SemVer}"; | ||
var beatsInstallPath = | ||
$"[ProgramFiles{(ap.Is64Bit ? "64" : string.Empty)}Folder]" + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we only support 64-bit windows so this check is likely unnecessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct we only support 64-bit Windows.
Elastic Agent is not supported on 32-bit operating systems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i can change this ofcourse... but note it's the original code that is also shared with the beats MSI, i tried not to change any logic for the beats MSI.
Make sure you can install Elastic Defend for an agent that was installed with this MSI. |
A few more:
|
Would installation in a different directory path be something we need to test also? |
Updated the description with what's left to be implemented. |
Do we need to support that on Windows? It adds complexity and risk. For example, if we allow users to install to user-writable directories, then our [un]install processes can end up writing/deleting user-controlled paths and we might unintentionally create LPEs and DoS. |
funny you mention this. I was just implementing the uninstall flow, and nothing in the MSI package has information about the final destination of the |
The MSI way to change the directory is TARGETDIR https://learn.microsoft.com/en-us/windows/win32/msi/targetdir not sure if our current method bypasses that but refactoring around targetdir is probably the right way to get customizable install destination |
@strawgate i believe Nima was referring to where agent installs itself (which is a different path than where the MSI unpacks its contents). TARGETDIR is probably the right thing to change 99% of the time, however, as i explained here, the MSI unpacks the CAB files to TARGETDIR, but then calls btw, the latest version of the MSI cleans up the TARGETDIR folder after it successfully runs the |
Another approach we could have taken is to unpack the contents of the MSI to the final folder ( |
To change the target install path, we added the --base-path option to the install command. We could have the MSI set the value of that flag. It is slightly more complex than just unpacking agent in the new directory, some symlinks need to be set up and this is all encapsulated inside the install command today. We disallowed changing the install path when using Elastic Defend, so at least in cases where someone is actively trying to use us for endpoint protection they aren't vulnerable to the arbitrary file deletion attacks Gabriel mentioned. |
Closing this PR in favor of: #212 |
agent install
from the target folder)agent install
and fail execution if code is different than 0agent install
is executed successfully