package resource on windows: ensure version doesn't work

79 views
Skip to first unread message

Tomer Paz

unread,
May 27, 2014, 6:55:04 AM5/27/14
to puppet...@googlegroups.com
Hi.
I have an issue with puppet package resource not verifying Version well for MSI packages on windows.
I tried both puppet 3.4 and latest 3.6, the matters remains the same.
When using
  ensure => "installed"
it works fine and puppet skip running the msiexec /i...

I made sure I am using MSI DisplayVersion (double verified with add/remove programs and using MS VB scripts and registry to check the package DisplayVersion) including some very common globally distributed MSIs and executables like MS products (VC2xxx for to name a few).
The behavior is: Puppet re-runs msiexec /i as if it is not found.
The expected behavior: Puppet to skip installation by verifying version equals.

Only one exception note, I have also in-house created MSIs which are Not registered to add/remove programs list (ARPSYSTEMCOMPONENT=1) but I don't think that matters either (as also MS MSIs/Execs are not checked by version correctly).

Here is a sample of how my package resource looks like, including hiera configuration:

class framework_app_server_env::install () inherits framework_app_server {
    $gavarr = split($gav, ':')
    $version = $gavarr[2]

    artifactory::artifact { 'FrameworkAppServerEnvironment.msi':
        gav        => "${gav}",
        ensure     => present,
        packaging  => 'msi',
        repository => "${artifactory_repo}",
        output     => "${install_dir}\\FrameworkAppServerEnvironment-${version}.msi",
        require    => Class['artifactory']
    }

    package { 'Framework App Server Environment':
        ensure           => "${version}",
        source            => "${install_dir}\\FrameworkAppServerEnvironment-${version}.msi",
        install_options => [ 'ARPSYSTEMCOMPONENT=1', "INSTALLDIR=${software_dir}", '/log', "${log_dir}\\framework_app_server_env.log" ],
        require            => [ Artifactory::Artifact['FrameworkAppServerEnvironment.msi'], File["${install_dir}"], File["${software_dir}"] ]
    }
}

and in hiera file:
framework_app_server_env::artifact::gav : 'shared-components:FrameworkAppServerEnvironment:11.2.0.0186'

I tried using notify to print ${version} while running agent -t on the agent windows machine and it printed the version perfectly.

Puzzled.

Tom

Rob Reynolds

unread,
May 27, 2014, 12:34:00 PM5/27/14
to puppet...@googlegroups.com
On Tue, May 27, 2014 at 5:55 AM, Tomer Paz <tome...@gmail.com> wrote:
Hi.
I have an issue with puppet package resource not verifying Version well for MSI packages on windows.
I tried both puppet 3.4 and latest 3.6, the matters remains the same.
When using
  ensure => "installed"
it works fine and puppet skip running the msiexec /i...

I made sure I am using MSI DisplayVersion (double verified with add/remove programs and using MS VB scripts and registry to check the package DisplayVersion) including some very common globally distributed MSIs and executables like MS products (VC2xxx for to name a few).
The behavior is: Puppet re-runs msiexec /i as if it is not found.
The expected behavior: Puppet to skip installation by verifying version equals.

Only one exception note, I have also in-house created MSIs which are Not registered to add/remove programs list (ARPSYSTEMCOMPONENT=1) but I don't think that matters either (as also MS MSIs/Execs are not checked by version correctly).


If you run puppet resource package and your packages do not show up, then it is not going to work with puppet. You should probably register them to the add/remove programs to see if that fixes things before trying to opt it out. I'm guessing this one thing is likely causing your behavior. The issue you are seeing with others is likely due to what I've covered in the next section.
 

Here is a sample of how my package resource looks like, including hiera configuration:

class framework_app_server_env::install () inherits framework_app_server {
    $gavarr = split($gav, ':')
    $version = $gavarr[2]

    artifactory::artifact { 'FrameworkAppServerEnvironment.msi':
        gav        => "${gav}",
        ensure     => present,
        packaging  => 'msi',
        repository => "${artifactory_repo}",
        output     => "${install_dir}\\FrameworkAppServerEnvironment-${version}.msi",
        require    => Class['artifactory']
    }

    package { 'Framework App Server Environment':

The package name must mach exactly with what you get back from calling 'puppet resource package', including any versions in the name. See http://docs.puppetlabs.com/windows/writing.html#packagepackage for more details.
 
        ensure           => "${version}",
        source            => "${install_dir}\\FrameworkAppServerEnvironment-${version}.msi",
        install_options => [ 'ARPSYSTEMCOMPONENT=1', "INSTALLDIR=${software_dir}", '/log', "${log_dir}\\framework_app_server_env.log" ],
        require            => [ Artifactory::Artifact['FrameworkAppServerEnvironment.msi'], File["${install_dir}"], File["${software_dir}"] ]
    }
}

and in hiera file:
framework_app_server_env::artifact::gav : 'shared-components:FrameworkAppServerEnvironment:11.2.0.0186'

I tried using notify to print ${version} while running agent -t on the agent windows machine and it printed the version perfectly.

Puzzled.

Tom

--
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/ae6edc0b-6f50-42d1-bdc1-b16eca147534%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Rob Reynolds
Developer, Puppet Labs

Join us at PuppetConf 2014September 23-24 in San Francisco
Register by May 30th to take advantage of the Early Adopter discount save $349!

Rob Reynolds

unread,
May 27, 2014, 12:42:29 PM5/27/14
to puppet...@googlegroups.com
Also this feature just came out with 3.4.0 - see https://tickets.puppetlabs.com/browse/PUP-272 

Note that there is some upcoming work with the Windows Package Provider - https://tickets.puppetlabs.com/browse/PUP-393 , notably you may want to explore https://tickets.puppetlabs.com/browse/PUP-400 (and the linked redmine issue).

Tomer Paz

unread,
May 27, 2014, 1:08:26 PM5/27/14
to puppet...@googlegroups.com
Thank you Rob for the quick revert.

I did check if  the name is exactly what shows up with "puppet resource package" and then I found out that only the MS (and few other 3rd-party SW) were listed by the puppet command, while our in-house MSIs aren't listed, sorry I forgot to mention that in the original question.

I have mentioned the reason our in-house MSIs aren't shown in add/remove programs (ARP...=1 parameter), but the fact they aren't shown by "puppet resource package" raised the question how exactly puppet windows provider checks if MSI is 'registered' with windows installer. That's where I'm puzzled,
since if I am running MS tools like this simple VBScript: http://msdn.microsoft.com/en-us/library/aa369767%28v=vs.85%29.aspx
It does show All our in-house MSIs with all their details (name, version, guid etc) as any other MSI.

That's why I became suspicious about how puppet's windows package provider checks Version and thought it might be bug.
It is a fact that "ensure => installed" did work, so it can't be that it doesn't find the package at all...

Spot on regarding some of the links you mentioned, I think it is either the "hidden packages" bug or PUP-399 "Warn if DisplayName or DisplayVersion is wrong "
which could be my case.

Thanks again

Tomer Paz

unread,
May 27, 2014, 1:26:40 PM5/27/14
to puppet...@googlegroups.com
oh I see now that the 'bug' was reported as redime of the 'feature' https://projects.puppetlabs.com/issues/21415
WAD (work as designed) :)
And the status is still "Unresolved" hence that's definitely my issue!

Thanks Ron, saved me lots of time... I will convince people to use a 'readonly' feature of add/remove programs in MSIs rather than hidden...
Reply all
Reply to author
Forward
0 new messages