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


Chronological Thread 
  • From: Jeppe Nejsum Madsen < >
  • To: " " < >
  • Subject: [chef] Re: RE: Re: RE: RE: Re: Re: Re: Upgrading chef-client on Windows not supported?
  • Date: Mon, 3 Mar 2014 11:13:21 +0100

Adam,

Thanks for the heads up and recipe. Any idea where this ends up in the back log given the focus on supporting Windows in chef?

The amount of windows hackery needed here probably exceeds my capabilities. And while I have some colleagues that might be able to get the job done, I think we'll cop out and upgrade chef-client manually (and note we are using hosted chef, so we are actually paying for the product which buys us a limited amount of whining imo :-)

/Jeppe



On Fri, Feb 28, 2014 at 6:28 PM, Adam Edwards < " target="_blank"> > wrote:
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.



  • [chef] Re: RE: Re: RE: RE: Re: Re: Re: Upgrading chef-client on Windows not supported?, Jeppe Nejsum Madsen, 03/03/2014

Archive powered by MHonArc 2.6.16.

§