Windows Issue: Package ensure: change from absent to present failed

Josh D

unread,

Jul 17, 2013, 12:19:27 PM7/17/13

to puppet...@googlegroups.com

Master: RHEL6 running Puppet 3.2.2

Node: Windows 7 x64 Running Puppet 3.2.3

I have the following rule defined on my Puppet master to push Python to client workstations:

package { 'Python 2.7.5 (64-bit)':

ensure => installed,

source => '\\server\share\Puppet\win64\Python\python-2.7.5.amd64.msi',

install_options => [{ 'INSTALLDIR' => 'C:\Python27' },],

require => [Package['MinGW-W64 version 4.5.3'], Package['Cygwin version 1.7.15']],

}

On the client, Python has already been installed via a run of: "puppet agent --test". Here is the output of a manual agent execution on the Windows 7 node in question:

C:\Program Files (x86)\Puppet Labs\Puppet\bin>puppet agent --test --trace

Info: Retrieving plugin

Info: Caching catalog for <hostname>

Info: Applying configuration version '1374075302'

Notice: /Stage[main]/Win7_user::Restart/Exec[restart_agent_flag]/returns: executed successfully

Notice: Finished catalog run in 6.51 seconds

As you can see, it's up-to-date. 'Python 2.7.5 (64-bit)' is in my list of installed programs. Where I run into problems is when the Puppet service kicks off. For some reason it tried to install Python again, and then fails with the mysterious INT 24 error. In previous reports of INT 24 that I've seen, it had to do with invalid declaration of the source attribute, which doesn't appear to be a problem here. Anyways, here is what is in Windows Event Viewer for the Puppet service:

MsiInstaller - Information 1040:

Beginning a Windows Installer transaction: \\<server>\share\Puppet\win64\Python\python-2.7.5.amd64.msi. Client Process Id: 7896.

MsiInstaller - Information 1042

Ending a Windows Installer transaction: \\astdfs.ast.lmco.com\Data\ses\GOESR_SW_ENG\goesr01\Tools\Puppet\win64\Python\python-2.7.5.amd64.msi. Client Process Id: 7896.

Puppet - Error 3

Failed to install: Fail on INT 24.

/Stage[main]/Win7_user/Package[Python 2.7.5 (64-bit)]/ensure: change from absent to present failed: Failed to install: Fail on INT 24.

What's not clear to me, is why is it trying to install again? It's already in the list of installed programs, and manual invocations of the agent, detect it's there. I've tried rebooting the machine, but it makes no difference.

Rob Reynolds

unread,

Jul 17, 2013, 12:24:15 PM7/17/13

to puppet...@googlegroups.com

Perhaps this could be a permissions error?

Can you validate that the user the service runs under can access the c:\Python27 folder and that it can see the registry settings?

--

Rob Reynolds

Join us at PuppetConf 2013, August 22-23 in San Francisco -

http://bit.ly/pupconf13

--
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.

Josh Cooper

unread,

Jul 17, 2013, 12:39:51 PM7/17/13

to puppet...@googlegroups.com

On Wednesday, July 17, 2013 9:19:27 AM UTC-7, Josh D wrote:

Master: RHEL6 running Puppet 3.2.2
Node: Windows 7 x64 Running Puppet 3.2.3

I have the following rule defined on my Puppet master to push Python to client workstations:
package { 'Python 2.7.5 (64-bit)':
ensure => installed,
source => '\\server\share\Puppet\win64\Python\python-2.7.5.amd64.msi',
install_options => [{ 'INSTALLDIR' => 'C:\Python27' },],
require => [Package['MinGW-W64 version 4.5.3'], Package['Cygwin version 1.7.15']],
}

On the client, Python has already been installed via a run of: "puppet agent --test". Here is the output of a manual agent execution on the Windows 7 node in question:
C:\Program Files (x86)\Puppet Labs\Puppet\bin>puppet agent --test --trace
Info: Retrieving plugin
Info: Caching catalog for <hostname>
Info: Applying configuration version '1374075302'
Notice: /Stage[main]/Win7_user::Restart/Exec[restart_agent_flag]/returns: executed successfully
Notice: Finished catalog run in 6.51 seconds

As you can see, it's up-to-date. 'Python 2.7.5 (64-bit)' is in my list of installed programs.

Based on http://www.python.org/download/releases/2.5/msi/ I think python is only being installed for the current user, not all users. You'll have to specify ALLUSERS=1 to get that behavior. I don't see this explicitly called out in our docs http://docs.puppetlabs.com/windows/writing.html#packagepackage but it should be. Could you file a ticket?

Where I run into problems is when the Puppet service kicks off. For some reason it tried to install Python again, and then fails with the mysterious INT 24 error. In previous reports of INT 24 that I've seen, it had to do with invalid declaration of the source attribute, which doesn't appear to be a problem here. Anyways, here is what is in Windows Event Viewer for the Puppet service:

MsiInstaller - Information 1040:
Beginning a Windows Installer transaction: \\<server>\share\Puppet\win64\Python\python-2.7.5.amd64.msi. Client Process Id: 7896.

MsiInstaller - Information 1042
Ending a Windows Installer transaction: \\astdfs.ast.lmco.com\Data\ses\GOESR_SW_ENG\goesr01\Tools\Puppet\win64\Python\python-2.7.5.amd64.msi. Client Process Id: 7896.

Puppet - Error 3
Failed to install: Fail on INT 24.
/Stage[main]/Win7_user/Package[Python 2.7.5 (64-bit)]/ensure: change from absent to present failed: Failed to install: Fail on INT 24.

What's not clear to me, is why is it trying to install again? It's already in the list of installed programs, and manual invocations of the agent, detect it's there. I've tried rebooting the machine, but it makes no difference.

This is one area where puppet and Add/Remove Programs differ. ARP will manage per-user packages for the current user, but puppet does not, since typically it's running as LocalSystem.

Josh

Rob Reynolds

unread,

Jul 17, 2013, 12:43:19 PM7/17/13

to puppet...@googlegroups.com

Thanks Josh. I wasn't thinking the install for only one user would be a problem so I didn't mention it. I guess it falls into a different part of the registry (HKCU) as well so it wouldn't show up as installed at all for the other accounts.

--

Rob Reynolds

Puppet Labs

Join us at PuppetConf 2013, August 22-23 in San Francisco -

http://bit.ly/pupconf13
Register now and take advantage of the Final Countdown discount - save 15%!

--

Josh D

unread,

Jul 17, 2013, 12:57:02 PM7/17/13

to puppet...@googlegroups.com

On Wednesday, July 17, 2013 10:24:15 AM UTC-6, Rob Reynolds wrote:

Perhaps this could be a permissions error?

Can you validate that the user the service runs under can access the c:\Python27 folder and that it can see the registry settings?

It is running as the SYSTEM account. so it should be able to. I tested trying to read the reg as system using psexec:

C:\Users\davidsj2\Downloads>psexec -i -s regedit /e c:\temp\sys.reg "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{DBDD570E-0952-475F-9453-AB88F3DD565A}"

PsExec v1.98 - Execute processes remotely

Sysinternals - www.sysinternals.com

regedit exited on <hos>with error code 0.

It exported correctly. I then restarted the service with the debug and trace flags and got a bit more detail in the INT 24 error:

Failed to install: Fail on INT 24.

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/provider/package/windows.rb:99:in `check_result'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/provider/package/windows.rb:64:in `install'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/type/package.rb:67:in `block (3 levels) in <module:Puppet>'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/property.rb:197:in `call_valuemethod'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/property.rb:498:in `set'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/property.rb:581:in `sync'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:114:in `apply_parameter'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:56:in `perform_changes'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:139:in `evaluate'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/transaction.rb:48:in `apply'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/transaction.rb:83:in `eval_resource'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/transaction.rb:103:in `block (2 levels) in evaluate'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:351:in `block in thinmark'

C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:350:in `thinmark'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/transaction.rb:103:in `block in evaluate'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/transaction.rb:382:in `traverse'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/transaction.rb:98:in `evaluate'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/resource/catalog.rb:146:in `apply'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer.rb:122:in `block in apply_catalog'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:179:in `block in benchmark'

C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:178:in `benchmark'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer.rb:121:in `apply_catalog'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/configurer.rb:179:in `run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in `block (4 levels) in run'

C:/Program Files (x86)/Puppet Labs/Puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in `block (3 levels) in run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:119:in `with_client'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:42:in `block (2 levels) in run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:84:in `run_in_fork'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:41:in `block in run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:179:in `call'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:39:in `run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application/agent.rb:353:in `onetime'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application/agent.rb:327:in `run_command'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:364:in `block (2 levels) in run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:456:in `plugin_hook'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:364:in `block in run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:504:in `exit_on_fail'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/application.rb:364:in `run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line.rb:132:in `run'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util/command_line.rb:86:in `execute'

C:/Program Files (x86)/Puppet Labs/Puppet/puppet/bin/puppet:4:in `<main>'

Josh D

unread,

Jul 17, 2013, 2:33:51 PM7/17/13

to puppet...@googlegroups.com

On Wednesday, July 17, 2013 10:39:51 AM UTC-6, Josh Cooper wrote:

Based on http://www.python.org/download/releases/2.5/msi/ I think python is only being installed for the current user, not all users. You'll have to specify ALLUSERS=1 to get that behavior. I don't see this explicitly called out in our docs http://docs.puppetlabs.com/windows/writing.html#packagepackage but it should be. Could you file a ticket?

Ok, I changed the rule to:

package { 'Python 2.7.5 (64-bit)':

ensure => installed,

source => '\\<server>\<share>\Tools\Puppet\win64\Python\python-2.7.5.amd64.msi',

install_options => [{ 'TARGETDIR' => 'C:\Python27' }, {'ALLUSERS' => '1' }],

require => [Package['MinGW-W64 version 4.5.3'], Package['Cygwin version 1.7.15']],

}

I also removed the existing install, so Python is not on my machine. After restarting the service, I got the same exact error and stack trace. I verified that ALLUSERS=1 was passed in.

Puppet - Information 1

Executing 'msiexec.exe /qn /norestart /i \\<server>\<share>\Python\python-2.7.5.amd64.msi TARGETDIR=C:\Python27 ALLUSERS=1'

Puppet - Error 3

Failed to install: Fail on INT 24.

Josh Cooper

unread,

Jul 17, 2013, 3:56:42 PM7/17/13

to puppet...@googlegroups.com

Are you sure that puppet when running as LocalSystem has permission to access the share[1]? Can puppet running as LocalSystem install the package from a local filesystem?

Another user had to modify the NTFS and Share permissions for 'Domain Computers' to access the share (map the drive)[2]. This is because LocalSystem doesn't have any credentials with which to access the network.

Josh

[1] https://groups.google.com/d/msg/puppet-users/86dBOxvirK0/I6CtTH_BGEgJ

[2] https://groups.google.com/d/topic/puppet-users/xoJpt6ARe0Y/discussion

Josh D

unread,

Jul 17, 2013, 4:29:32 PM7/17/13

to puppet...@googlegroups.com

On Wednesday, July 17, 2013 1:56:42 PM UTC-6, Josh Cooper wrote:

Another user had to modify the NTFS and Share permissions for 'Domain Computers' to access the share (map the drive)[2]. This is because LocalSystem doesn't have any credentials with which to access the network.

Josh

[1] https://groups.google.com/d/msg/puppet-users/86dBOxvirK0/I6CtTH_BGEgJ
[2] https://groups.google.com/d/topic/puppet-users/xoJpt6ARe0Y/discussion

I think that's the issue:

G:\Tools\Puppet\win64\Python>psexec -i -s msiexec.exe /qn /norestart /i \\<server>\<share>\Puppet\win64\Python\python-2.7.5.amd64.msi TARGETDIR=C:\Python27 ALLUSERS=1

PsExec v1.98 - Execute processes remotely

Sysinternals - www.sysinternals.com

msiexec.exe exited on SSCLD134G82G with error code 1619.

Side note, I think the error code (1619) isn't getting picked up by Puppet correctly. So I'm trying to weigh my options. I'm a lowly developer and can't muck with domain users, nor can I change the security permissions on any of the CIFS network shares. Running puppet agent manually, works on my test machine because I'm local admin, but won't work for other users who aren't. I think I've tried copying installers using a File resource and then requiring and installing from said file in a package, but I recall that causing issues.

Josh Cooper

unread,

Jul 17, 2013, 11:49:40 PM7/17/13

to puppet...@googlegroups.com

On Wed, Jul 17, 2013 at 1:29 PM, Josh D <joshuad...@gmail.com> wrote:

On Wednesday, July 17, 2013 1:56:42 PM UTC-6, Josh Cooper wrote:

Another user had to modify the NTFS and Share permissions for 'Domain Computers' to access the share (map the drive)[2]. This is because LocalSystem doesn't have any credentials with which to access the network.

Josh

[1] https://groups.google.com/d/msg/puppet-users/86dBOxvirK0/I6CtTH_BGEgJ

[2] https://groups.google.com/d/topic/puppet-users/xoJpt6ARe0Y/discussion

I think that's the issue:
G:\Tools\Puppet\win64\Python>psexec -i -s msiexec.exe /qn /norestart /i \\<server>\<share>\Puppet\win64\Python\python-2.7.5.amd64.msi TARGETDIR=C:\Python27 ALLUSERS=1

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

msiexec.exe exited on SSCLD134G82G with error code 1619.

This exit code means "This installation package could not be opened. Verify that the package exists and that you can access it."[1]

Side note, I think the error code (1619) isn't getting picked up by Puppet correctly.

Yes, ruby truncates windows exit codes to a single byte[2]

C:\work\puppet>ruby --version

ruby 1.9.3p374 (2013-01-15) [i386-mingw32]

C:\work\puppet>ruby -e "%x{cmd.exe /c exit 1619}; puts $?.exitstatus

83

where 1619 = 0x653 and 83 = 0x53

A fellow puppet user has tried to work around this in the dism module[3]. I would hate to see this proliferate across modules, surely ruby will fix this, though I can't understand why the ticket is marked as a feature.

So I'm trying to weigh my options. I'm a lowly developer and can't muck with domain users, nor can I change the security permissions on any of the CIFS network shares. Running puppet agent manually, works on my test machine because I'm local admin, but won't work for other users who aren't. I think I've tried copying installers using a File resource and then requiring and installing from said file in a package, but I recall that causing issues.

In the windows world, you'll either need to modify the network shares (which you can't do), configure the puppet agent service to run as a domain user that does have permission (not sure if that's an option for you), or serve the packages through some other means, e.g. puppet master file server[4], apache, etc.

Josh

[1] http://support.microsoft.com/kb/290158

[2] https://bugs.ruby-lang.org/issues/8083

[3] https://github.com/puppetlabs/puppetlabs-dism/pull/14

[4] http://docs.puppetlabs.com/guides/file_serving.html

--

Josh Cooper

Developer, Puppet Labs

Michael Lück

unread,

Aug 7, 2013, 4:44:15 AM8/7/13

to puppet...@googlegroups.com

Hi,

don't know if it helps you too, but this post

https://groups.google.com/forum/#!topic/puppet-users/Ll1VIWSbmO8

helped me when i got that error.

I just replaced the forward-slashes in the source attribute by double backslashes and i could install the msi.