Why is my windows_package source attribute getting mucked up?

Chef Infra (archive)
1

I have the following resource

windows_package “Install App1” do
source "{node.cookbook.package_url}"
action :install
end

In my case, node.cookbook.package_url = http://file-server.domain.com/path/app1.msi

Chef chef-client run fails, and error message shows the source attribute as
"C:\http:\file-server-domain.com\path\app1.msi"

If I remove the windows_package and just use the log resource, I see the correct format. That is

log “{node.cookbook.package_url}”

I see

INFO: http://file-server.domain.com/path/app1.msi

What am I missing?

Chris

2

source needs to be a path to a local file. Since you're instead giving it
a URL, the resource provider interprets the URL as a path, which is (of
course) wrong. You could use remote_file to download the URL to a
temporary location beforehand.

On Fri, Feb 6, 2015 at 12:29 PM, Fouts, Chris Chris.Fouts@sensus.com
wrote:

I have the following resource

windows_package “Install App1” do

source “{node.cookbook.package_url}”

action :install

end

In my case, node.cookbook.package_url =
http://file-server.domain.com/path/app1.msi

Chef chef-client run fails, and error message shows the source attribute
as

“C:\http:\file-server-domain.com\path\app1.msi”

If I remove the windows_package and just use the log resource, I see the
correct format. That is

log “{node.cookbook.package_url}”

I see

INFO: http://file-server.domain.com/path/app1.msi

What am I missing?

Chris

--
Justin Dossey
Practice Owner
New Context Services, Inc

3

More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.

Chris

From: Justin Dossey [mailto:justin.dossey@newcontext.com]
Sent: Friday, February 06, 2015 6:41 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Why is my windows_package source attribute getting mucked up?

source needs to be a path to a local file. Since you’re instead giving it a URL, the resource provider interprets the URL as a path, which is (of course) wrong. You could use remote_file to download the URL to a temporary location beforehand.

On Fri, Feb 6, 2015 at 12:29 PM, Fouts, Chris <Chris.Fouts@sensus.commailto:Chris.Fouts@sensus.com> wrote:
I have the following resource

windows_package “Install App1” do
source “{node.cookbook.package_url}”
action :install
end

In my case, node.cookbook.package_url = http://file-server.domain.com/path/app1.msi

Chef chef-client run fails, and error message shows the source attribute as
“C:\http:\file-server-domain.comhttp://file-server-domain.com\path\app1.msi”

If I remove the windows_package and just use the log resource, I see the correct format. That is

log “{node.cookbook.package_url}”

I see

INFO: http://file-server.domain.com/path/app1.msi

What am I missing?

Chris

–
Justin Dossey
Practice Owner
New Context Services, Inc

4

On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:

More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.

Chris

I agree there are a lot of areas where Windows functionality needs to catch up, but this isn’t one of them. On Linux when you install a package that doesn’t come from a centralized package repo, you have to use a separate remote file to fetch it as well. The difference is that most Linux distros come with a centralized package repo, which provides most of the packages you want. The only way Chef could make windows behave similarly is to force you to install Chocolatey when you install Chef. FWIW I had the exact same experience on Solaris a few years back where the only centralized package repos are (were?) 3rd party so you had to do a bit of extra work to fetch everything.

--
Daniel DeLeo

5

I disagree.

winodow_package "could" have been written such that when the source is a URL (http://), it would do a remote_file first, and then execute the local package, all underneath the covers. Then its behavior is in-line with the package resource.

Chris

-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Wednesday, February 11, 2015 12:08 PM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: Why is my windows_package source attribute getting mucked up?

On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:

More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.

Chris

I agree there are a lot of areas where Windows functionality needs to catch up, but this isn’t one of them. On Linux when you install a package that doesn’t come from a centralized package repo, you have to use a separate remote file to fetch it as well. The difference is that most Linux distros come with a centralized package repo, which provides most of the packages you want. The only way Chef could make windows behave similarly is to force you to install Chocolatey when you install Chef. FWIW I had the exact same experience on Solaris a few years back where the only centralized package repos are (were?) 3rd party so you had to do a bit of extra work to fetch everything.

--
Daniel DeLeo

6

On 2/12/15 7:47 AM, Fouts, Chris wrote:

On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:

More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.

Chris
I agree there are a lot of areas where Windows functionality needs to catch up, but this isn’t one of them. On Linux when you install a package that doesn’t come from a centralized package repo, you have to use a separate remote file to fetch it as well. The difference is that most Linux distros come with a centralized package repo, which provides most of the packages you want. The only way Chef could make windows behave similarly is to force you to install Chocolatey when you install Chef. FWIW I had the exact same experience on Solaris a few years back where the only centralized package repos are (were?) 3rd party so you had to do a bit of extra work to fetch everything.
Also on par with AIX which has RPM package, but lacks yum support. We do
better support distros that make things easier. There's also a ton of
contributed code in the yum and apt providers that is user contributed.

7

After looking around a little bit, I actually can’t see any evidence that
any of the _package resources can take an http “source” with the exception
of “gem_package”. The standard way to go about this if you can’t use the
OS’s built-in package manager is to retrieve the file with remote_file and
then install it. You’re pretty-much just running up against “Linux, BSD,
and Mac (sort of) have a package management system, Windows doesn’t”.

That being said, it does seem like a reasonable feature to have and it
probably wouldn’t be too hard for you to implement if it’s very important
to you. I’m sure others would appreciate the contribution.

Matt Moretti
​

On Thu, Feb 12, 2015 at 10:47 AM, Fouts, Chris Chris.Fouts@sensus.com
wrote:

I disagree.

winodow_package "could" have been written such that when the source is a
URL (http://), it would do a remote_file first, and then execute the
local package, all underneath the covers. Then its behavior is in-line with
the package resource.

Chris

-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Wednesday, February 11, 2015 12:08 PM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: Why is my windows_package source attribute
getting mucked up?

On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:

More (annoying) inconsistencies (in expectations) between Windows and
Linux based nodes.

Chris

I agree there are a lot of areas where Windows functionality needs to
catch up, but this isn’t one of them. On Linux when you install a package
that doesn’t come from a centralized package repo, you have to use a
separate remote file to fetch it as well. The difference is that most Linux
distros come with a centralized package repo, which provides most of the
packages you want. The only way Chef could make windows behave similarly is
to force you to install Chocolatey when you install Chef. FWIW I had the
exact same experience on Solaris a few years back where the only
centralized package repos are (were?) 3rd party so you had to do a bit of
extra work to fetch everything.

--
Daniel DeLeo

8

windows_package can use URLs. I use them everyday.

Attribute

default['tool']['url'] = "
Download 7z920-x64.msi (7-Zip)"

Recipe

windows_package "7-Zip 9.20 (x64 version)" do
source node['tool']['url']
action :install
not_if {::File.exists?(node['tool']['file'])}
not_if {reboot_pending?}
end

On Thu, Feb 12, 2015 at 11:42 AM, Matthew Moretti werebus@gmail.com wrote:

After looking around a little bit, I actually can’t see any evidence that
any of the _package resources can take an http “source” with the
exception of “gem_package”. The standard way to go about this if you can’t
use the OS’s built-in package manager is to retrieve the file with
remote_file and then install it. You’re pretty-much just running up
against “Linux, BSD, and Mac (sort of) have a package management system,
Windows doesn’t”.

That being said, it does seem like a reasonable feature to have and it
probably wouldn’t be too hard for you to implement if it’s very important
to you. I’m sure others would appreciate the contribution.

Matt Moretti
​

On Thu, Feb 12, 2015 at 10:47 AM, Fouts, Chris Chris.Fouts@sensus.com
wrote:

I disagree.

winodow_package "could" have been written such that when the source is a
URL (http://), it would do a remote_file first, and then execute the
local package, all underneath the covers. Then its behavior is in-line with
the package resource.

Chris

-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel
DeLeo
Sent: Wednesday, February 11, 2015 12:08 PM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: Why is my windows_package source attribute
getting mucked up?

On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:

More (annoying) inconsistencies (in expectations) between Windows and
Linux based nodes.

Chris

I agree there are a lot of areas where Windows functionality needs to
catch up, but this isn’t one of them. On Linux when you install a package
that doesn’t come from a centralized package repo, you have to use a
separate remote file to fetch it as well. The difference is that most Linux
distros come with a centralized package repo, which provides most of the
packages you want. The only way Chef could make windows behave similarly is
to force you to install Chocolatey when you install Chef. FWIW I had the
exact same experience on Solaris a few years back where the only
centralized package repos are (were?) 3rd party so you had to do a bit of
extra work to fetch everything.

--
Daniel DeLeo

--

Todd Pigram

www.linkedin.com/in/toddpigram/
@pigram86 on twitter

Mobile - 216-224-5769

9

I get the error reported here, and I have Windows Server 2012 R2

http://lists.opscode.com/sympa/arc/chef/2014-05/msg00328.html

Chris

From: Todd Pigram [mailto:todd@toddpigram.com]
Sent: Thursday, February 12, 2015 12:22 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: RE: Re: RE: Re: Why is my windows_package source attribute getting mucked up?

windows_package can use URLs. I use them everyday.

Attribute

default['tool']['url'] = "Download 7z920-x64.msi (7-Zip)"

Recipe

windows_package "7-Zip 9.20 (x64 version)" do
source node['tool']['url']
action :install
not_if {::File.exists?(node['tool']['file'])}
not_if {reboot_pending?}
end

On Thu, Feb 12, 2015 at 11:42 AM, Matthew Moretti <werebus@gmail.commailto:werebus@gmail.com> wrote:

After looking around a little bit, I actually can’t see any evidence that any of the _package resources can take an http “source” with the exception of “gem_package”. The standard way to go about this if you can’t use the OS’s built-in package manager is to retrieve the file with remote_file and then install it. You’re pretty-much just running up against “Linux, BSD, and Mac (sort of) have a package management system, Windows doesn’t”.

That being said, it does seem like a reasonable feature to have and it probably wouldn’t be too hard for you to implement if it’s very important to you. I’m sure others would appreciate the contribution.

Matt Moretti
​

On Thu, Feb 12, 2015 at 10:47 AM, Fouts, Chris <Chris.Fouts@sensus.commailto:Chris.Fouts@sensus.com> wrote:
I disagree.

winodow_package "could" have been written such that when the source is a URL (http://), it would do a remote_file first, and then execute the local package, all underneath the covers. Then its behavior is in-line with the package resource.

Chris

-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.commailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Wednesday, February 11, 2015 12:08 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Re: RE: Re: Why is my windows_package source attribute getting mucked up?

On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:

More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.

Chris

I agree there are a lot of areas where Windows functionality needs to catch up, but this isn’t one of them. On Linux when you install a package that doesn’t come from a centralized package repo, you have to use a separate remote file to fetch it as well. The difference is that most Linux distros come with a centralized package repo, which provides most of the packages you want. The only way Chef could make windows behave similarly is to force you to install Chocolatey when you install Chef. FWIW I had the exact same experience on Solaris a few years back where the only centralized package repos are (were?) 3rd party so you had to do a bit of extra work to fetch everything.

--
Daniel DeLeo

--

Todd Pigram

www.linkedin.com/in/toddpigram/http://www.linkedin.com/in/toddpigram/
@pigram86 on twitter
Google Workspace Updates: New community features for Google Chat and an update on Currents
Mobile - 216-224-5769

10

The windows cookbook supports downloading from a url, the resource in core
does not...yet

On Thu, Feb 12, 2015 at 11:36 AM, Fouts, Chris Chris.Fouts@sensus.com
wrote:

I get the error reported here, and I have Windows Server 2012 R2

chef - [chef] Re: windows_package source problems in windows 2008 and not in 2012

Chris

From: Todd Pigram [mailto:todd@toddpigram.com]
Sent: Thursday, February 12, 2015 12:22 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: RE: Re: RE: Re: Why is my windows_package
source attribute getting mucked up?

windows_package can use URLs. I use them everyday.

Attribute

default['tool']['url'] = "
Download 7z920-x64.msi (7-Zip)"

Recipe

windows_package "7-Zip 9.20 (x64 version)" do

source node['tool']['url']

action :install

not_if {::File.exists?(node['tool']['file'])}

not_if {reboot_pending?}

end

On Thu, Feb 12, 2015 at 11:42 AM, Matthew Moretti werebus@gmail.com
wrote:

After looking around a little bit, I actually can’t see any evidence that
any of the _package resources can take an http “source” with the
exception of “gem_package”. The standard way to go about this if you can’t
use the OS’s built-in package manager is to retrieve the file with
remote_file and then install it. You’re pretty-much just running up
against “Linux, BSD, and Mac (sort of) have a package management system,
Windows doesn’t”.

That being said, it does seem like a reasonable feature to have and it
probably wouldn’t be too hard for you to implement if it’s very important
to you. I’m sure others would appreciate the contribution.

Matt Moretti

​

On Thu, Feb 12, 2015 at 10:47 AM, Fouts, Chris Chris.Fouts@sensus.com
wrote:

I disagree.

winodow_package "could" have been written such that when the source is a
URL (http://), it would do a remote_file first, and then execute the
local package, all underneath the covers. Then its behavior is in-line with
the package resource.

Chris

-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Wednesday, February 11, 2015 12:08 PM
To: chef@lists.opscode.com

Subject: [chef] Re: RE: Re: Why is my windows_package source attribute
getting mucked up?

On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:

More (annoying) inconsistencies (in expectations) between Windows and
Linux based nodes.

Chris

I agree there are a lot of areas where Windows functionality needs to
catch up, but this isn’t one of them. On Linux when you install a package
that doesn’t come from a centralized package repo, you have to use a
separate remote file to fetch it as well. The difference is that most Linux
distros come with a centralized package repo, which provides most of the
packages you want. The only way Chef could make windows behave similarly is
to force you to install Chocolatey when you install Chef. FWIW I had the
exact same experience on Solaris a few years back where the only
centralized package repos are (were?) 3rd party so you had to do a bit of
extra work to fetch everything.

--
Daniel DeLeo

--

Todd Pigram
Todd Pigram - United States, Inversion6, RETS Electronic Institute, Saint Xavier High School - Louisville KY | about.me
www.linkedin.com/in/toddpigram/

@pigram86 on twitter
Google Workspace Updates: New community features for Google Chat and an update on Currents

Mobile - 216-224-5769

11

On Thu, Feb 12, 2015 at 12:39 PM, Jay Mundrawala jdm@getchef.com wrote:

The windows cookbook supports downloading from a url, the resource in core
does not...yet

Right. I migrated the windows package provider from the windows
cookbook into core Chef. The version is core does not support URLs in
the source, the cookbook still does.

As Matthew and Dan noted, it's not common behavior for the other
resources to take URLs because it means embedding (or worse,
duplicating) another resource. There's one super hairy place that we
do this, and it's the deploy resource -> git/svn resource. Based on
the principle of resources primitives each performing a single task
(i.e. the Unix philosophy) I don't think we really designed resources
to be used this way and it leads to a silly hack of adding all the
attributes from the embedded resource (remote_file) into the one
you're using (windows_package). We're in a better place now than a few
years ago because we can more easily build provider specific resources
(e.g. the windows_package provider uses the windows_package resource,
not the package resource). But still, I wondered if we need to work
through on RFC for a standard way of embeddeding resources and passing
their attributes.

Bryan