-
Notifications
You must be signed in to change notification settings - Fork 103
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
build windows msi for arm and amd #1796
Changes from all commits
3b59fd8
0aff250
eca6558
9a49d63
0b736a3
2fbeac3
926987b
5f89750
5dfec02
80c3def
e840e20
5c90381
910cabb
de4544b
832ddf1
2f739af
10314cc
ed806ee
163ca6a
8293631
53ad5c3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -79,6 +79,16 @@ func runMake(args []string) error { | |
env.String("LAUNCHER_VERSION", "stable"), | ||
"What TUF channel to download launcher from. Supports filesystem paths", | ||
) | ||
flLauncherPath = flagset.String( | ||
"launcher_path", | ||
"", | ||
"Path of local launcher binary to use in packaging", | ||
) | ||
flLauncherArmPath = flagset.String( | ||
"launcher_arm_path", | ||
"", | ||
"Path of local launcher arm64 binary to use in packaging", | ||
) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this future-proofing in case we want to do more granular releases for launcher in the future (e.g. "bug in launcher version x.y.z on ARM only, so leave stable at x.y.z for all other arches and x.y.y for launcher ARM")? Or are we adding this flag for another reason? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added this just so that I could specify a local arm build to package. I can't imagine a situation where we would want the arm and amd binaries to have different code. This has me thinking though that maybe we should add in some safe guards to ensure the arm and amd versions are the same. If we some how managed to get into a situation where TUF updated one and not the other, we could end up with a package where different arches are on different versions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can't find a coherent way to verify the versions are the same. However, I set up the flag so that it's default is an empty string and it will just set that flag to what ever There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure there's a good way to validate a launcher version, without invoking it. Maaaybe we can string parse it, but I'm not sure it's worth it. (And given what Zack recently learned about file versions and MSIs, let's not go there...) Maybe this is an argument for being less clever. Command line either takes There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess that's kinda what would happen. So maybe I'm over thinking it. Maybe we validate the versions from tuf, and skip that validation on local paths. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. invoking it could be troublesome since we'll have 2 binaries with to different arches, An arm64 machine will probably emulate the amd64 binary and run it, but the reverse doesn't work. I think just having separate flags for paths is probably good with only a single option for |
||
flExtensionVersion = flagset.String( | ||
"extension_version", | ||
env.String("EXTENSION_VERSION", "stable"), | ||
|
@@ -230,10 +240,14 @@ func runMake(args []string) error { | |
} | ||
|
||
packageOptions := packaging.PackageOptions{ | ||
PackageVersion: *flPackageVersion, | ||
OsqueryVersion: *flOsqueryVersion, | ||
OsqueryFlags: flOsqueryFlags, | ||
LauncherVersion: *flLauncherVersion, | ||
PackageVersion: *flPackageVersion, | ||
OsqueryVersion: *flOsqueryVersion, | ||
OsqueryFlags: flOsqueryFlags, | ||
LauncherVersion: *flLauncherVersion, | ||
LauncherPath: *flLauncherPath, | ||
// LauncherArmPath can be used for windows arm64 packages when you want | ||
// to specify a local path to the launcher binary | ||
LauncherArmPath: *flLauncherArmPath, | ||
ExtensionVersion: *flExtensionVersion, | ||
Hostname: *flHostname, | ||
Secret: *flEnrollSecret, | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -193,3 +193,27 @@ Note that the windows package will only install as `ALLUSERS`. You may | |
need to use elevated privileges to install it. This will likely be | ||
confusing. `msiexec.exe` will either silently fail, or be | ||
inscrutable. But `start` will work. | ||
|
||
###### Windows Multi-Archecture MSI | ||
|
||
Package builder creates an MSI containing both amd64 & arm64 binaries. This is done putting both of binaries and their service installation in to the MSI with mutually exclusive conditions based on processor architecture. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Very clear. |
||
|
||
To accomplish we are using heat to harvest files set up like ... | ||
|
||
``` | ||
└───pkg_root | ||
└───Launcher-kolide-k2 | ||
├───bin | ||
│ ├───amd64 | ||
│ │ launcher.exe | ||
│ │ osqueryd.exe | ||
│ │ | ||
│ └───arm64 | ||
│ launcher.exe | ||
│ osqueryd.exe | ||
│ | ||
└───conf | ||
... | ||
``` | ||
|
||
then post processing the generated xml to remove the amd64 and arm64 directory tags so that all the exe files are in the same directory in the xml, then add the mutually exclusive tags to the binary elements |
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 see this is what we're doing everywhere here, I wonder if we should consolidate and only open it once, instead of the rapid opening and closing. (If we think so, it's fine as a followup)