[chef] RE: Re: RE: RE: Re: Re: Re: Upgrading chef-client on Windows not supported?

[Adam Edwards < >]

Lamont is correct about the root cause -- the build always produces a new
msi, and there are no upgrade codes in the generated package. And
omnibus-updater doesn't support Windows as you've found out Jeppe. :(

Jeppe, great start on this. So until the scheme for handling productid's /
upgrade logic for the msi across versions is resolved, a version of
omnibus-updater that works for Windows is the way to go.

At the point in omnibus-updated at which we know the package is not
installed and you need to install it, we can create a scheduled task to run
an upgrade script of some sort after the chef-client run completes. A script
like that would do something like the following:

1.  net stop chef-client # so in case the service is running
2. Check to make sure there are no chef-client processes running
        a. slightly tricky, you need to look at all processes, find each 
ruby.exe
process, and make sure the arguments don't contain 'chef-client'. In newer
versions of chef-client, you may be able to look for a process lock file.
3. Find the existing chef-client installed product by name via wmi -- I can
send some examples if it will help
4. Use wmi's msi handler to uninstall all chef-clients that you find
5. Run the installation for the new chef-client package
6.  If the service was originally enabled (easy to find during the
chef-client run and then pass on the cli to the scheduled task), install the
service with chef-service-manager
        a. This will also cause a chef-client run
7. If the service was not enabled, tell it to run chef-client. This step
should run regardless of whether the previous steps succeeded
8. The task should delete itself to keep things clean, alternatively, it
could delete itself only if #7 fails and configure itself to retry.

Since this would need to work on systems without powershell (because prior
to Win2k8R2 powershell is not installed by default :(), it's best to do this
via vbscript / jscript with cscript.exe. Powershell would be much easier
though if your focus is just getting things to work in your scenario.

Note that at the next chef-client run, the correct version should be
detected and then nothing happens.

If anyone else has implemented this, we should consider that as a starting
point for a PR. Otherwise, we can work with you Jeppe to get something
together before we finally get to it in our backlog of work.

Thanks.

-Adam

-----Original Message-----
From: Lamont Granquist 
[mailto:
 
Sent: Thursday, February 27, 2014 6:28 PM
To: 

 
Subject: [chef] Re: RE: RE: Re: Re: Re: Upgrading chef-client on Windows not
supported?


they're built with wix:

https://github.com/opscode/omnibus-chef/blob/master/config/software/chef-client-msi.rb

On 2/27/14 6:09 PM, Kapil Shardha wrote:
> Wondering if the MSI's are being created using Visual Studio installer
> projects or WiX. If that is the case, VS generates a random GUID as
> PRODUCT CODE property.
>
> Perhaps, checking the registry on a system with multiple versions of
> chef-client will tell if the Product Code is different.
>
> -Kapil
>
>
> -----Original Message-----
> From: Lamont Granquist 
> [mailto:
 
> Sent: Thursday, February 27, 2014 8:23 PM
> To: 
> 
 
> Cc: Kapil Shardha
> Subject: Re: [chef] RE: Re: Re: Re: Upgrading chef-client on Windows not
> supported?
>
>
> there's a known problem where i think we're using unique product codes for
> every different chef msi so that you can have multiple chef-client
> packages installed at the same time (even though they overwrite each
> other's files).
>
> https://tickets.opscode.com/browse/CHEF-4657
>
> not sure if that's related, but it probably doesn't help any...
>
> On Thu Feb 27 13:36:45 2014, Kapil Shardha wrote:
>> The MSI installer platform supports "Upgrade" scenario as long as the MSI
>> has an unique "Product Code" and "Version Number" included. I am not sure
>> what chef-client MSI does or how it has been authored but I have authored
>> installers using WiX that support "Upgrade scenario".
>>
> ________________________________
>
> This email and any accompanying documents may contain privileged or
> otherwise confidential information of, and/or is the property of Education
> Management Solutions, Inc. If you are not the intended recipient, please
> immediately advise the sender by reply email & delete the message & any
> attachments without using, copying or disclosing the contents. Thank you.