We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

From NSIS to MSI: Deploying the ownCloud Client on Windows

00:00

Formal Metadata

Title
From NSIS to MSI: Deploying the ownCloud Client on Windows
Title of Series
Number of Parts
34
Author
Contributors
License
CC Attribution - ShareAlike 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Shed some light on the change to MSI. Show usage of the .msi and ask for feedback. ownCloud is switching to MSI for packaging on Windows. This talk shows a few of the reasons and consequences. Live demos included. After the talk there's going to be enough time for questions.
24
Client (computing)Cloud computingEnterprise architectureLecture/Conference
Client (computing)Plug-in (computing)Installation artPhysical systemWinAmpMultiplication signPoint cloudCloud computingPlug-in (computing)Installation artScripting languageWinAmpWindowWordClient (computing)Formal languagePhysical systemComputer animation
Plug-in (computing)Computer fileRevision controlProgram flowchart
SoftwareImperative programmingStandard deviationMassParameter (computer programming)Client (computing)Formal languageCompilerExtension (kinesiology)Visual systemGastropod shellComputer programmingRevision controlGastropod shellParameter (computer programming)Binary codeWindowComputer fileSign (mathematics)Latent heatMedical imagingStandard deviationUniform resource locatorBuildingNatural numberDifferenz <Mathematik>String (computer science)SoftwareVisualization (computer graphics)CompilerClient (computing)Category of beingState of matterExtension (kinesiology)MereologyFile formatScripting languageMassService (economics)MathematicsChainPersonal digital assistantNeuroinformatikComputer animation
MaizeComputer configurationStandard deviationWindowInstallation artVideoconferencingMultiplication signProper mapComputer animation
Client (computing)Server (computing)Client (computing)Installation artInteractive televisionSystem administratorDirectory serviceComputer fileFile formatRevision controlArithmetic progressionPay televisionStandard deviationServer (computing)Extension (kinesiology)WindowBootingCategory of beingUniform resource locatorScripting languageTouchscreenYouTubeGame theoryScreensaverMathematicsFreewareDocument management systemDescriptive statisticsInformation retrievalNon-standard analysisHypermediaState of matterMSXParameter (computer programming)Computer animation
Wave packetSoftware developerBuildingInstallation artComputer animation
BootingCodeNumberRight angleFerry CorstenComputer clusterCategory of beingScheduling (computing)Software testingFeedbackArithmetic progressionComputer animation
Arithmetic progressionMereologyInteractive televisionComputer animation
Computer iconMusical ensembleNeuroinformatikComputer animation
Inclusion mapInstallation artInstallation artCuboidSource codeXML
Type theoryComputer animation
Slide ruleComputer animation
2 (number)BootingFeedbackTheoryComputer animation
Data storage deviceNon-standard analysisRevision controlInstallation artTotal S.A.Lecture/Conference
Client (computing)Slide ruleCurve fittingVideoconferencingHypermediaComputer animation
Transcript: English(auto-generated)
Please give a warm welcome to Dominic Schmitz, he has done tremendous work on making the own cloud clients actually enterprise ready from a deployment perspective.
It's great work and I just hand over the microphone to him and thank you. Thank you John. Hello everybody, welcome to my talk. As John already said, we're talking about deployment of the young cloud client on Windows.
To begin with I would like to ask you to raise your hand and ask a question at any point in time. You don't have to wait till the end of the talk or anything, just ask. It's way more fun for everybody.
At first a few words about myself. My name is Dominic Schmitz, I'm D. Schmitz on GitHub. I've worked on a lot of stuff. The first thing I did for on cloud was the LDAP plugin.
I ported the client to Windows, to Mac OS and lots of other stuff. Up until now we were using Ensys for the installer of the client, which stands for Nullsoft Scriptable System because it was written by the company Nullsoft for Winamp
back in the 90s I think. It's cool because it supports cross builds from Linux and you get an executable for Windows. It's kind of cool and we used that up until now, but it has a lot of issues.
It has a really fragmented ecosystem. It uses a kind of strange scripting language that no one else uses. It's their own proprietary language and it's really hard to use. And we had a lot of issues with it. A lot of issues were hard to fix because of the fragmented ecosystem.
A lot of plugins aren't properly versioned or anything. They are hosted in a wiki, in a zip file and there's no way to know if they uploaded a new version or what's supposed to work together.
So we had a lot of issues. One issue we couldn't fix at all, which you can see at the top, it's the uninstaller which is generated by Ensys itself and you can't sign it. So that was something that a lot of people complained about.
So what are we going to do instead? We're using the Microsoft software installer, which is also known simply as MSI. It's a more standardized approach to software deployment on Windows. It's not the standard. There are a lot of standards, but it's one of the standards
and it has a really declarative nature. So instead of saying I'm creating a program that installs a file here and installs a file there and does this and this and this, MSI declares the state that it wants to achieve in the end.
So you declare that you want a file in a specific location and Windows can take care of achieving that. So what we gain by that automatically is that we can remove a DLL from the onCloud client folder
and Windows will know how to restore it just without doing anything special. So because it's a standard, it's used by all the tools that can be used for mass deployment. Microsoft tools and other third-party tools use it.
You have a standardized way of passing arguments to MSI packages. They are called properties and you will see them later in the talk, how to use them. You can also create transforms for MSI packages, which means you can apply changes.
It's kind of a diff. So you can replace strings or replace images or you can preset properties on the MSI package and you basically are free to do a lot of things.
The downside is that you currently can't build MSI packages on Linux. We use a tool called Wix toolset, which used to be able to compile an MSI in Wine,
but that doesn't work anymore with recent versions of Wix toolset. So we decided against keeping our cross toolchain and switch to a native... I'll get to that in a bit.
So we have ANSYS on the one side, which we can still build, but it's deprecated. So if you have issues with our new release, you still have the chance to use the old binaries with the old compiler and the old package format.
But we really discourage it and it's not really supported. So what we did back then, we had an OpenSUSE VM and we used this MinGW compiler with our custom toolset, custom packages for Qt.
And because it's still on Qt 5.6, we don't have HTTP 2 support. We had to use pre-built binaries for the shell extensions, which made it really hard to develop them. And as I said, this rather weird ANSYS script language.
Then on the other side, our new solution is based on MSI. It's supported and we have a completely new build infrastructure. We are using Docker for Windows, we are using MS Visual C++ as compiler, we have the latest Qt version, we can build the shell extension as part of the client,
and as I said, we use Wix toolset, which uses XML specification for the package it creates. What does it look like if you install the MSI? This is the standard install wizard.
As you can see on the right side, you can select individual features and it's a standard Windows feature. Unlike the ANSYS installer, which had kind of handcrafted options to also disable certain features,
this is now implemented as proper Windows features. So, you can have tools that show you what features the package provides and you can just use the standard tools and you don't have to learn a new API for the installer.
Of course, when we change the format for the installer, we also need to take care that users get the new package. So, what we had to do, we had to add support for MSI, obviously,
and we needed to implement a different invocation of the package. And that wasn't in the client version 2.4.1, I think. So, we couldn't just add a new package to our updater server and expect the client to install it.
So, we had to go to an intermediate update that is now capable of installing the new MSI. So, this has a rather inconvenient consequence.
You have to install 2.4.3 via the auto updater and only then you can get 2.5. So, if you get asked by the client to update to 2.4.3, you should do it, because otherwise you won't receive updates in the future anymore.
This is a bit unfortunate, but there's no really good solution to this other than keeping to always building the old package, which is obviously a lot of work for not much gain.
For this, of course, customers with a branding subscription will also get support for the MSI in the client updater server. It's currently a work in progress. It's basically done. It's just waiting for review and final QA.
But it will be there soon enough when the branded release is ready. So, probably most interesting for admins in the room might be now how you can actually install the MSI.
The standard tool, at least for local installation, is MSI EXEC. You can just invoke it MSI EXEC and the name of slash I and then the name of the MSI package, the file name, and it will just launch the installer that you just saw.
If you want to script it, you usually don't want any user interaction to be necessary, so you can pass the passive argument, which is also a standard MSI EXEC flag, nothing that we came up with, and also the reboot equals release suppress,
which is a standard property, which I mentioned earlier, which you need to specify if you want to avoid a reboot in the end, which we need to enable the Explorer extension after installation.
This kind of installation still shows a window with a progress bar but requires no interaction. If you want to completely hide the window, there's also a silent installation with slash quiet or slash QN or simply slash Q, I think.
You can also change the installation directory with the so-called install the property. You can simply specify any folder that you want, just as you expected. You can find all of this in the documentation, which can be found under this URL.
And yeah, I can simply show you what it looks like. I need to see how it works with the second screen.
As you see, OnCloud is not installed right now.
If it's running here, it's just a development build but no package installed. And we can now go to PowerShell and, for example, just, let's see, nope, nope, nope, nope, where is it, here is it.
So there's also another feature, which I was just testing here.
A customer who was really, really helpful in testing the MSI with us and giving a lot of feedback, requested that when you just suppressed the reboot, the exit code of the MSI is set to a certain number that says that a reboot is still required.
And for the tool they were using, this was interpreted as an error. So we added another property that says, oh, yeah, please don't schedule a reboot at all. So it doesn't need to be suppressed. But it's not so interesting right now.
So as I said, if you just use passive, you should see, yes, it's signed. You should just see a probe. Oh, I forgot, no restart. Yeah, so if you just pass passive, then you will see a progress bar, but you won't require interaction, as I said.
If you use quiet, you don't see anything at all and it's completely silent. Let's see one more thing.
We go to this again. What we should see now is that the size is correctly computed and the icon is correctly set. And those are all issues that we had with the old ANSYS installer that would have been possible to fix, but that meant work.
And we just get that out of the box with MSI without further problems. So far it seems like a way more robust solution and less brittle solution like ANSYS was.
So what you can also do in here is if you pass X for uninstallation.
I don't know where the X is in that word, but yeah, you can use that. And then if you don't forget to type no restart, which is the same as suppress reboot, then it will just remove it again.
So yeah. Okay, I think that's all I wanted to show you. I need to go back to my slides.
Thank you for your attention and questions or feedback. Yes, yes, no to the first question, yes to the second.
So they will eventually appear. It's not necessary to make an immediate reboot.
It's just needed to restart the Explorer. So in theory you could also just kill Explorer X, restart it. Yes, exactly. Go ahead.
Okay, so I'm repeating the question now, which I forgot for the first question. The question is what happens if the user doesn't install 2.4.3, can the user still go to 2.5 without issues?
Yes, totally. So the MSI automatically uninstalls the old version and then installs the new one.
So that's all the automatic updater does too. So the automatic updater just downloads the MSI and installs it. It doesn't even invoke the old uninstaller itself. Further questions?
Then once again, thank you for your attention. I think those are the most important things to take home with you. So thanks and bye.