[PUP-3317] Extend Package Source to include HTTP Urls (Windows) Created: 2014/09/19  Updated: 2020/03/04

Status: Accepted
Project: Puppet
Component/s: Types and Providers
Affects Version/s: PUP 3.7.1
Fix Version/s: None

Type: Improvement Priority: Normal
Reporter: Louis Mayorga Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: package, platform-os, source, type_and_provider, windows
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Windows 7, Windows 2008R2

Issue Links:
relates to PUP-394 Install windows packages from remote ... Accepted
relates to PUP-1098 Package/source should accept puppet:/... Ready for Review
relates to PUP-3691 Windows - Support puppet URLs for pac... Accepted
relates to PUP-3189 Support https, http, other URI scheme... Closed
Team: Night's Watch
CS Priority: Reviewed
QA Contact: Eric Thompson



The package resource type for windows does not include the http url as a valid value.

Windows package management.
This provider supports either MSI or self-extracting executable installers.
This provider requires a source attribute when installing the package. It accepts paths to local files, mapped drives, or UNC paths.
This provider supports the install_options and uninstall_options attributes, which allow command-line flags to be passed to the installer. These options should be specified as a string (e.g. ‘–flag’), a hash (e.g. {‘–flag’ => ‘value’}), or an array where each element is either a string or a hash.
If the executable requires special arguments to perform a silent install or uninstall, then the appropriate arguments should be specified using the install_options or uninstall_options attributes, respectively. Puppet will automatically quote any option that contains spaces.
Default for operatingsystem == windows.
Supported features: install_options, installable, uninstall_options, uninstallable, versionable.

Many windows users that use puppet to install tools with large binaries have the need to install software without downloading the file locally or have a specific UNC path for it.

using file -> package is not an option since i don't really care about the file but i care about the package to be installed.

Comment by Josh Cooper [ 2014/09/19 ]

Louis Mayorga I agree this would be useful and eliminate the need to have a second copy of the installer. There is a related ticket PUP-3189 for supporting this for file resource sources.

Since msiexec already supports URLs, I was thinking would should just pass the URL to it for (MSI packages). For exe-based packages, I think we'd need to download the package to a secure temp location, and execute from there, but only download if we actually need to install or update.


Comment by Louis Mayorga [ 2014/10/02 ]

The way I found to remove the dependency to the File resource type is to use the following architecture.

1. Have a Server Based (WebDav) server used to server package installers (msi,exec)
2. Set the Network Drive on the site.pp. This could work for either EC2, Vagrant and Machines Members of a LAN.
3. Use the Package resource type calling the specified Drive Letter.

There is a lot of software that need to be installed on some of our machines and keeping that data just for the installation process is just not justified.

This worked for me and hopefully i can write a blog post for many hypervisors but with the same code.

Comment by Jeff McCune [ 2016/04/26 ]

Just as an FYI, I ran into this issue this week on site with a large Puppet Enterprise customer. The issue lies here: PUP-398 Patch.

I'm writing a small Puppet Module to monkey patch `msi_package.rb` (hooray!) to allow customers to easily work-around this issue, but it is a bit of a problem.

The impact is that there's no good way to install MSI packages from common HTTP services such as Artifactory or a raw HTTP URL to a file stored in a Bitbucket Git repository. As a result, it's a large PITA for new Puppet users to try and sort out how to do something "easy" like installing a basic package.

What's worse is that there isn't much functionality out of the box on Windows, so adding additional functionality like installing Git to make the vcsrepo module useful becomes difficult because there is no easy way to install an MSI package.

Comment by Jeff McCune [ 2016/04/26 ]

Please note, I published a hotfix module. Please try it out and let me know if it works or if there are any issues.

Comment by Rob Reynolds [ 2016/04/27 ]

Jeff McCune Hi Jeff! This would make a great PR if you wanted to provide it!

Comment by Rob Reynolds [ 2016/04/27 ]

Also please note what you found is a bug and should work. I don't see it as exactly the same issue here. This ticket is meant to extend for exe installers as well and not just MSIs, which already have native URL support (provided the correct x509 certificates are installed).

Comment by Jeff McCune [ 2016/04/27 ]

Rob Reynolds Cool. Do you know if there's an existing ticket for the MSI http bug? If I don't hear back, I'll probably create a new ticket and toss up a pull request in the near future.

Comment by Rob Reynolds [ 2016/04/29 ]

I don't know of one. Creating a new issue and tossing that up seems reasonable!

Comment by Louis Mayorga [ 2017/05/20 ]

Good news.

Generated at Fri Aug 07 08:30:00 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.