I've been pulling my hair out troubleshooting an issue surrounding my Package resources. I have been using a Windows Server 2008 R2 box with Puppet Agent 1.8.2. When I had all the files on the local hard drive as I created these manifests, the package installations all worked and installed as intended. I then set up my agent services as a domain user, made sure that used had rights to a UNC path, and moved the files there.
After updating the manifests, some packages worked and some did not. Upon further review it appears that its the MSI ones that work, and the EXE ones that do not. This led me to a variety of posts in various places of people having this issue nearly three years ago. Specifically, [here is an example on this site](https://ask.puppet.com/question/3978/are-puppet-urls-still-not-supported-on-windows-for-package/?answer=5459#post-id-5459).
An example of my manifest:
package { 'Microsoft ReportViewer 2010 Redistributable':
ensure => '10.0.30319',
source => "\\\\server.domain.local\\Puppet\\ReportViewer.exe",
install_options => ['/q'],
}
The output I get:
Error: Could not update: The source does not exist: '\\\\server.domain.local\\Puppet\\ReportViewer.exe'
I've tried single quotes with single backslashes, double quotes with escaped backslashes, and even tried forward slashes. The server can browse that path with no problem (ruling out a DNS / network access issue) and that user account can browse to that share when a drive is mapped as that user (ruling out an authentication / access rights issue).
The key is that the one that *does* work is an MSI installer. This leads me to suspect that the puppet agent on Windows still has limitations when trying to run EXE files from UNC paths. Can anyone confirm if this is the case? If it is, are there any clever workarounds? My entire point of using Puppet was to try to automate the state of my Windows servers. If I have to manually copy over executables so that they can run locally it largely defeats the purpose.
↧