Upgrading a .msi package through Puppet

[Lorenzo Jesús Cubero]

Hey! I would like to be able of upgrade a windows application just copying the .msi file into a ../module/files directory, without having to modify any manifest.
Something like:

        file { 'C:\\files\\packages\\Package.msi':
          ensure          => present,
          source          => 'puppet:///modules/SOME-MODULE/packages/Package.msi',
        }

        package { 'Package':
              ensure          => installed,
              provider        => 'windows',
              source    => 'C:\\files\\packages\\Package.msi',
        }

The main problem I'm facing is to tell Puppet to install the latest version, without defining the specific package. I would like to do something like "version => latest".

Any ideas on where to begin?

[Rob Reynolds]

Take a look at https://projects.puppetlabs.com/issues/21133. I'm not sure if there is an ensure => latest yet or not.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

--

Rob Reynolds

Developer, Puppet Labs

Join us at PuppetConf 2014, September 23-24 in San Francisco

[Lorenzo Jesús Cubero]

Thanks Rob for guiding me.

The ensure => latest feature is not ready yet, because it requires an upgradeable provider.

What seems to be solved is ensure => '0.0.1'.

At the link you provide they made the windows provider versionable. (That requires facter version => 1.7.3-rc1)

I managed to apply it to Puppet, so I can do something like:

    
package { 'App':
          ensure          => '0.1.1',
          provider        => 'windows',
          source    => 'C:\\files\\packages\\App.msi',
    }

Which installs a specific package without uninstalling any previous version already installed... wierd :(

Any hint?

[Rob Reynolds]

I am curious if you have also looked at the other package providers that are out there - http://forge.puppetlabs.com/modules?q=windows+package 

I can tell you that the chocolatey provider does allow ensure => latest. Also the version on github is being improved to add source in addition to other things and will be updated sometime in the future.

To answer your question about the uninstall with the windows package built-in provider, are you seeing this with all MSIs or just a specific one (perhaps that was custom built)?  MSIs should upgrade themselves, unless there is an error in the MSI installer logic. Or if the logic allowed side by side installs, in which case I don't think the provider takes that into account.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/958adf6c-b9ce-453c-a24c-c92db2ac5ac8%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Josh Cooper]

Hi Lorenzo,

On Wed, Oct 30, 2013 at 11:54 AM, Rob Reynolds <r...@puppetlabs.com> wrote:

I am curious if you have also looked at the other package providers that are out there - http://forge.puppetlabs.com/modules?q=windows+package 

I can tell you that the chocolatey provider does allow ensure => latest. Also the version on github is being improved to add source in addition to other things and will be updated sometime in the future.

To answer your question about the uninstall with the windows package built-in provider, are you seeing this with all MSIs or just a specific one (perhaps that was custom built)?  MSIs should upgrade themselves, unless there is an error in the MSI installer logic. Or if the logic allowed side by side installs, in which case I don't think the provider takes that into account.

I agree with Rob, it sounds like the MSI is not authored correctly. Typically, each version of an MSI for a given product should have the same UpgradeCode, so that Windows recognizes that you are installing a new version of an existing product. If on the other hand, the product can co-exist with older versions, then you'll need to treat them as independent `package` resources in your manifests.

Josh

--

Josh Cooper

Developer, Puppet Labs

[Lorenzo Jesús Cubero]

Dear Rob and Josh,

Indeed it was all about a custom build msi being unable to upgrade himself. All the packages have the same UpgradeCode, so I will keep investigating.

Thank you both for your time.

Lorenzo

[Mike Gaboury]

I am trying to update Puppet itself and the new version is not installing. It appears that the UpgradeCode between Puppet 3.2.3 and 3.4.2 are identical {2AD3D11C-61B3-4710-B106-B4FDEC5FA358}.  Is this expected or an oversight?  If it is expected, how is the best way to upgrade Puppet with Puppet?

Manifest snippet:

class puppet::windows() {

   package { 'Puppet':

      ensure   => 'present',

      provider => 'windows',

      source   => '\\share\dir\puppet-3.4.2.msi',

[Klavs Klavsen]

I use:
if ( $puppetversion != "3.3.1" ) {
  package { "Puppet 3.3.1":
     source =>  "\\\\software01\\autorepo\$\\Puppet\\puppet-3.3.1.msi",
     install_options => [ '/quiet', '/norestart','PUPPET_MASTER_SERVER=puppet.example.dk']
  }
}

to ensure a specific version on all windows hosts.

[Mike Gaboury]

That helped.  Thanks.  The key was to have the version in the title.  I had 'Puppet' and needed 'Puppet 3.4.2'.

So this appears to be an inconsistency or, more likely, a lack of understanding on Windows packages and versioning (I'm a Linux guy).  I have a module to deploy Java.  To get that to work, I had to have 'Java 7 Update 45' in the title which corresponds to the Name field in the Control Panel Uninstall dialog.  However, Puppet's entry just has 'Puppet' in the Name field.  Using just 'Puppet' in the package definition would not trigger the install/upgrade.  What is the proper method for this in Windows?

[Josh Cooper]

On Tue, Jan 14, 2014 at 10:22 AM, Mike Gaboury <mike.g...@gmail.com> wrote:

That helped.  Thanks.  The key was to have the version in the title.  I had 'Puppet' and needed 'Puppet 3.4.2'.

This works because when puppet is installed, its DisplayName property in the registry is "Puppet". So when you specify "Puppet 3.4.2", puppet will determine that there is no such package installed. It will then install the package from the specified source parameter, and in the process upgrade puppet, as they share the same UpgradeCode.

 

So this appears to be an inconsistency or, more likely, a lack of understanding on Windows packages and versioning (I'm a Linux guy).  I have a module to deploy Java.  To get that to work, I had to have 'Java 7 Update 45' in the title which corresponds to the Name field in the Control Panel Uninstall dialog.  However, Puppet's entry just has 'Puppet' in the Name field.  Using just 'Puppet' in the package definition would not trigger the install/upgrade.  What is the proper method for this in Windows?

Prior to 3.4, puppet could only ensure that a package with a given name was installed or absent. To ensure that a particular version of a package was installed, you could use the PackageCode (from the MSI). Search the puppet-users list for information about that.

In 3.4 and up, the puppet windows package provider is "versionable"[1] This means you can tell puppet to install a particular version, e.g.

package { "Puppet":

  ensure => "3.4.2",

  source => 'https://downloads.puppetlabs.com/windows/puppet-3.4.2.msi'

}

Of course, you will need to update puppet to at least 3.4 to be able to use this feature.

Another option is to use the chocolatey package provider[2], which is both versionable and upgradeable (so you can say ensure => latest).

On Tuesday, January 14, 2014 9:38:55 AM UTC-6, Klavs Klavsen wrote:

I use:
if ( $puppetversion != "3.3.1" ) {
  package { "Puppet 3.3.1":
     source =>  "\\\\software01\\autorepo\$\\Puppet\\puppet-3.3.1.msi",
     install_options => [ '/quiet', '/norestart','PUPPET_MASTER_SERVER=puppet.example.dk']
  }
}

to ensure a specific version on all windows hosts.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1b781bd3-ad74-403f-858d-a8fbeaec5cd1%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

Josh

[1] http://projects.puppetlabs.com/issues/21133

[2] https://github.com/chocolatey/puppet-chocolatey

--

Josh Cooper

Developer, Puppet Labs

Join us at PuppetConf 2014, September 23-24 in San Francisco - http://bit.ly/pupconf14

Register now and save 40%! Offer expires January 31st.