Skip to content
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

Per Machine install? #2685

Closed
Jhacker9 opened this issue Feb 28, 2023 · 11 comments · Fixed by #2686
Closed

Per Machine install? #2685

Jhacker9 opened this issue Feb 28, 2023 · 11 comments · Fixed by #2686
Assignees

Comments

@Jhacker9
Copy link

Is there a way to install per-machine? In our environment per-user installs are discouraged. We need a silent per machine install in MECM/SCCM. I note that in your ARP in registry the uninstall is /currentuser /S. So wondering if there is something like /machine /S? Alternatively, if I create an MSI with all the installed files and install that to say C:\Program Files (x86)\Brim with matching shortcut, would the product work?

@philrz
Copy link
Contributor

philrz commented Mar 1, 2023

@Jhacker9: Interesting question! I must admit, we've not considered that one before. But based on the wording of your question, it sounds like your Windows admin skills exceed ours. Therefore I'll first share what I know and perhaps add your knowledge onto that. 😉

Per the contributing doc, Brim is an Electron-based app, and it's packaged with electron-builder. Per these docs, it looks like we're using the default package type of NSIS, so I guess these NSIS docs become relevant. Knowing I'm not going to be an instant expert in NSIS, I instead just read through the options here and it confirmed that we've been relying on its default of a one-click, per-user install. And this all results in things landing in the paths described in https://github.com/brimdata/brim/wiki/Filesystem-Paths, which has the app binaries in one location and the user data in another.

Today in a PR #2686 I played around and confirmed that it did indeed pop up its "assisted" installer so I could pick the per-machine install option and that did what I expected. Now, I see above that you said your ultimate need is for a silent per-machine install, so I guess this doesn't get you all the way there. While it would be feasible for us to use these same options to flip over to doing a one-click (i.e., silent), per-machine install, since we've been shipping Brim for years now with a per-user install and this is the first time the topic has come up, I'm a little hesitant to toggle the behavior-when-silent and maybe upset some users. But I think you could likely make your MSI idea work. I did a smoke test by doing a single-user install and then copying the app binaries folder out from under %USERPROFILE%\AppData\Local\Programs and into %ProgramFiles% and made a shortcuts on the desktops of multiple users to the .exe app binary in that folder and indeed both could launch it successfully and their unique per-user data still landed in the each one's "user data" path under %APPDATA%. While this was just a smoke test and not a battle-hardened config, FWIW I seem to recall another community user at one point reporting that they put the app binaries on a network drive for reasons similar to yours and that also worked for them, so I think you'd do ok.

As for your mention of /CurrentUser, I see at https://nsis.sourceforge.io/Docs/MultiUser/Readme.html that NSIS also has an /AllUsers option, so you might have some luck fiddling with that as well.

I'll also mention that per this blog post we're about to put out a major release where Brim's name will change to Zui and a bunch more functionality will be added. Depending on how desperately you need to roll out the app in your environment, I'd probably advise waiting until we've made that transition.

@Jhacker9
Copy link
Author

Jhacker9 commented Mar 1, 2023 via email

@philrz philrz reopened this Mar 2, 2023
@philrz philrz self-assigned this Mar 8, 2023
@philrz
Copy link
Contributor

philrz commented Mar 8, 2023

@Jhacker9: Responding to the items in your last comment:

I’m not sure if our end users want to wait till the release of Zui (is there a date for that?).

Zui v1.0.0 was actually released yesterday. It did include the changes from #2686 so it now offers the option to select per-machine installation. Based on what you said, I assume that means the /AllUsers option you were looking for would be available at the lower levels where you were looking for it. Please do give a look and let me know what you find.

While you are working on all that also look into a logging option for your installer. Those help us with debugging on occasion

I did look into this and have opened a new issue #2713 to pursue that. I did some initial hacking based on the issue & PR linked from there, but it seems the functionality in electron-builder is a little under-documented so it wasn't the quick change I was hoping for. Feel free to keep an eye on that issue and hopefully we'll get it working before too long.

I'll hold this issue open while we wait to hear if you've got success doing what you need with Zui v1.0.0.

@philrz
Copy link
Contributor

philrz commented Mar 8, 2023

@Jhacker9: Circling back with one more update. A bug specific to per-machine install on Windows just surfaced yesterday (#2715), so if your user base is doing security work with pcaps you might want to hold off on rolling out Zui v1.0.0 until that's been addressed. Of course, there's no harm in testing in the meantime.

@Jhacker9
Copy link
Author

Jhacker9 commented Mar 8, 2023 via email

@Jhacker9
Copy link
Author

Jhacker9 commented Mar 10, 2023 via email

@philrz
Copy link
Contributor

philrz commented Mar 10, 2023

@Jhacker9: We certainly understand your concerns and can respond to the specific issues you've raised. However, I sense that it might work best if you could join a call with our team to do some Q&A and talk through the details and see what's the best way forward. Could you email us at support@brimdata.io with your contact info and let us know if there might be day/time ranges in the latter half of next week when you might be available for such a chat? FYI we're in the U.S. Pacific time zone. Thanks!

@Jhacker9
Copy link
Author

Jhacker9 commented Mar 13, 2023 via email

@philrz
Copy link
Contributor

philrz commented Mar 13, 2023

@Jhacker9: Thanks for sharing the windows of availability. I suspect a firewall or email proxy on your end keeps scrubbing out the screen captures and email addresses from your updates, as lots of stuff is blanked out with ****** by the time it makes it into GitHub. In any case, your policies make sense and I understand how they're out of sync with how Brim/Zui currently behave. Could you drop an email to support@brimdata.io so we could send an invite for a possible meeting slot? Thanks.

@Jhacker9
Copy link
Author

Jhacker9 commented Mar 13, 2023 via email

@philrz
Copy link
Contributor

philrz commented Mar 15, 2023

@Jhacker9: Glad to hear you've got a likely path forward for Zui when your user base requests it. I'll go ahead and close this particular issue since per-machine install is now at least possible. Your findings did spawn several other issues that we'll pursue over time to improve our Windows installation experience. I'll summarize below in the event you'd like to keep an eye on those other issues. Feel free to chime in with comments if you have additional input/problems.

Maybe [Zui] wont auto-update or install a completely new/different product??

Just to provide a little background here, we did provide several months of notice to our user base of the coming name change for the app, such as this blog post and this Tweet. We've also had an issue #1211 open for for 2+ years now tracking interest in disabling auto-update but were surprised that nobody's expressed it as a requirement until now. But thanks to the issue you've raised, we've now boosted the priority on adding that. If left to our own, the way we would have initially implemented it would have been as a user preference, i.e., a user would have the ability to enable/disable the auto-update. But based on your policies you've described, I've made the assumption that your environment would need to be able to disable auto-update as a feature entirely at install time such that users would not even have the option to re-enable it.

If Zui/Zed are running the uninstall will remove the ARP from Control Panel - Programs and Features, but keep all files on the C: Drive (C:\Program Files\Zui )

I tried to reproduce this so we could pursue it as a bug but I was unable. The first video attached below shows the manual uninstall that most users use. If Zui is running, the user is prompted to close it, and if they click Ok, it does close the app, the uninstall proceeds, and all the files in C:\Program Files\Zui are removed. If they clicked Cancel, the uninstall is aborted. Knowing that your wrapper is doing a silent uninstall, though, I thought that if that command was invoked directly while the app was running, maybe it would somehow stomp past that prompt and skip deleting the files. However, in the second attached video I grab that silent uninstall command line and run it while the app is open, and it still shows the app being closed & all the files being deleted. So, if you can think of what I might need to do differently to trigger the problem as you saw it, I'd welcome that so I could dig into the problem.

Manual.Uninstall.mp4
Silent.Uninstall.mp4

...the empty folder C:\Program Files\Zui remains on the system.

This I was able to reproduce, so I've opened #2725 to pursue getting that cleaned up along with some registry entries I also see are left behind.

Beyond those, #2713 and #2715 are the others that we've opened along the way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants