chef 11.14.0.alpha.3-x86-mingw32 → 11.14.0.alpha.4-x86-mingw32
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/CONTRIBUTING.md +140 -99
- data/lib/chef/application.rb +80 -2
- data/lib/chef/application/apply.rb +1 -0
- data/lib/chef/application/client.rb +5 -0
- data/lib/chef/application/knife.rb +4 -0
- data/lib/chef/application/windows_service.rb +1 -0
- data/lib/chef/chef_fs/parallelizer/parallel_enumerable.rb +6 -4
- data/lib/chef/config.rb +5 -3
- data/lib/chef/exceptions.rb +2 -0
- data/lib/chef/http/basic_client.rb +1 -0
- data/lib/chef/knife.rb +1 -0
- data/lib/chef/platform/provider_mapping.rb +7 -0
- data/lib/chef/provider/env/windows.rb +2 -0
- data/lib/chef/provider/group/usermod.rb +1 -1
- data/lib/chef/provider/mount/solaris.rb +233 -0
- data/lib/chef/provider/package/apt.rb +9 -0
- data/lib/chef/provider/package/windows.rb +3 -0
- data/lib/chef/providers.rb +1 -0
- data/lib/chef/resource/mount.rb +6 -1
- data/lib/chef/util/path_helper.rb +94 -0
- data/lib/chef/version.rb +1 -1
- data/spec/functional/application_spec.rb +58 -0
- data/spec/functional/resource/mount_spec.rb +14 -11
- data/spec/integration/client/client_spec.rb +11 -0
- data/spec/integration/knife/common_options_spec.rb +9 -0
- data/spec/unit/application_spec.rb +157 -0
- data/spec/unit/http/basic_client_spec.rb +42 -0
- data/spec/unit/provider/env/windows_spec.rb +67 -0
- data/spec/unit/provider/group/usermod_spec.rb +2 -1
- data/spec/unit/provider/mount/mount_spec.rb +3 -3
- data/spec/unit/provider/mount/solaris_spec.rb +646 -0
- data/spec/unit/provider/package/apt_spec.rb +5 -0
- data/spec/unit/provider/package/windows_spec.rb +6 -0
- data/spec/unit/resource_reporter_spec.rb +2 -2
- data/spec/unit/util/path_helper_spec.rb +136 -0
- metadata +23 -16
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA1:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: e14e6256e2c3851ad67c73606b57a2065089de87
|
|
4
|
+
data.tar.gz: 6a038c007d22e0d4cecf9adccff780db287c5df4
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 6c6ae21ff2c7eac8a2ecc77db39ca49d24286a18093dc093ca98cb407d1a0c2b0449c0c4a1febe0c79a9136c2516d9d1f80967f458a61e2161b58e10329d7694
|
|
7
|
+
data.tar.gz: e804b056db1b0048378fd66d3b2c95967b4d6649d926d0b1022bff45b615d1be9c55ef339b3641ea89c237ec6f2810d9203db56e5c99f4c72660c9dd603465e4
|
data/CONTRIBUTING.md
CHANGED
|
@@ -1,155 +1,196 @@
|
|
|
1
1
|
# Contributing to Chef
|
|
2
2
|
|
|
3
|
-
We are glad you want to contribute to Chef!
|
|
3
|
+
We are glad you want to contribute to Chef!
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
We utilize **Github Issues** for issue tracking and contributions. You can contribute in two ways:
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
1. Reporting an issue or making a feature request [here](#issues).
|
|
8
|
+
2. Adding features or fixing bugs yourself and contributing your code to Chef.
|
|
8
9
|
|
|
9
|
-
|
|
10
|
-
* Sign our contributor agreement (CLA) [
|
|
11
|
-
online](https://secure.echosign.com/public/hostedForm?formid=PJIF5694K6L)
|
|
12
|
-
(keep reading if you're contributing on behalf of your employer)
|
|
13
|
-
* Create a ticket for your change on the [bug tracker](http://tickets.opscode.com)
|
|
14
|
-
* Link to your patch as a rebased git branch or pull request from the ticket
|
|
15
|
-
* Resolve the ticket as fixed
|
|
10
|
+
## Contribution Process
|
|
16
11
|
|
|
17
|
-
We
|
|
12
|
+
We have a 3 step process that utilizes **Github Issues**:
|
|
18
13
|
|
|
19
|
-
|
|
14
|
+
1. Sign our
|
|
15
|
+
[Individual Contributor License Agreement (CLA)](https://secure.echosign.com/public/hostedForm?formid=PJIF5694K6L)
|
|
16
|
+
or [Corporate CLA](https://secure.echosign.com/public/hostedForm?formid=PIE6C7AX856) online once.
|
|
17
|
+
2. Create a Github Pull Request.
|
|
18
|
+
3. Do [Code Review](#cr) with the **Chef Engineering Team** or **Chef Core Committers** on the pull request.
|
|
20
19
|
|
|
21
|
-
|
|
22
|
-
Chef uses the Apache 2.0 license to strike a balance between open contribution and allowing you to use the software however you would like to.
|
|
20
|
+
### <a name="pulls"></a> Chef Pull Requests
|
|
23
21
|
|
|
24
|
-
|
|
25
|
-
|
|
22
|
+
Chef is built to last. We strive to ensure high quality throughout the Chef experience. In order to ensure
|
|
23
|
+
this, we require a couple of things for all pull requests to Chef:
|
|
26
24
|
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
25
|
+
1. **Tests:** To ensure high quality code and protect against future regressions, we require all the
|
|
26
|
+
code in Chef to have at least unit test coverage. See the [spec/unit](https://github.com/opscode/chef/tree/master/spec/unit)
|
|
27
|
+
directory for the existing tests and use ```bundle exec rake spec``` to run them.
|
|
28
|
+
2. **Green Travis Run:** We use [Travis CI](https://travis-ci.org/) in order to run our tests
|
|
29
|
+
continuously on all the pull requests. We require the Travis runs to succeed on every pull
|
|
30
|
+
request before being merged.
|
|
30
31
|
|
|
31
|
-
|
|
32
|
+
In addition to this it would be nice to include the description of the problem you are solving
|
|
33
|
+
with your change. You can use [Chef Issue Template](#issuetemplate) in the description section
|
|
34
|
+
of the pull request.
|
|
35
|
+
|
|
36
|
+
### <a name="cr"></a> Chef Code Review Process
|
|
37
|
+
|
|
38
|
+
The Chef Code Review process happens on Github pull requests. See
|
|
39
|
+
[this article](https://help.github.com/articles/using-pull-requests) if you're not
|
|
40
|
+
familiar with Github Pull Requests.
|
|
32
41
|
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
your employer fill out our [Corporate CLA](https://secure.echosign.com/public/hostedForm?formid=PIE6C7AX856) instead.
|
|
42
|
+
Once you a pull request, the **Chef Engineering Team** or **Chef Core Committers** will review your code
|
|
43
|
+
and respond to you with any feedback they might have. The process at this point is as follows:
|
|
36
44
|
|
|
37
|
-
|
|
45
|
+
1. 2 thumbs-ups are required from the **Chef Engineering Team** or **Chef Core Committers** for all merges.
|
|
46
|
+
2. When ready, your pull request will be tagged with label `Ready For Merge`.
|
|
47
|
+
3. Your patch will be merged into `master` including necessary documentation updates
|
|
48
|
+
and you will be included in `CHANGELOG.md`. Our goal is to have patches merged in 2 weeks
|
|
49
|
+
after they are marked to be merged.
|
|
38
50
|
|
|
39
|
-
|
|
40
|
-
|
|
51
|
+
If you would like to learn about when your code will be available in a release of Chef, read more about
|
|
52
|
+
[Chef Release Process](#release).
|
|
41
53
|
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
54
|
+
### Contributor License Agreement (CLA)
|
|
55
|
+
Licensing is very important to open source projects. It helps ensure the
|
|
56
|
+
software continues to be available under the terms that the author desired.
|
|
45
57
|
|
|
46
|
-
|
|
58
|
+
Chef uses [the Apache 2.0 license](https://github.com/opscode/chef/blob/master/LICENSE)
|
|
59
|
+
to strike a balance between open contribution and allowing you to use the
|
|
60
|
+
software however you would like to.
|
|
47
61
|
|
|
48
|
-
|
|
62
|
+
The license tells you what rights you have that are provided by the copyright holder.
|
|
63
|
+
It is important that the contributor fully understands what rights they are
|
|
64
|
+
licensing and agrees to them. Sometimes the copyright holder isn't the contributor,
|
|
65
|
+
most often when the contributor is doing work for a company.
|
|
66
|
+
|
|
67
|
+
To make a good faith effort to ensure these criteria are met, Chef requires an Individual CLA
|
|
68
|
+
or a Corporate CLA for contributions. This agreement helps ensure you are aware of the
|
|
69
|
+
terms of the license you are contributing your copyrighted works under, which helps to
|
|
70
|
+
prevent the inclusion of works in the projects that the contributor does not hold the rights
|
|
71
|
+
to share.
|
|
72
|
+
|
|
73
|
+
It only takes a few minutes to complete a CLA, and you retain the copyright to your contribution.
|
|
49
74
|
|
|
50
|
-
You can
|
|
75
|
+
You can complete our
|
|
76
|
+
[Individual CLA](https://secure.echosign.com/public/hostedForm?formid=PJIF5694K6L) online.
|
|
77
|
+
If you're contributing on behalf of your employer and they retain the copyright for your works,
|
|
78
|
+
have your employer fill out our
|
|
79
|
+
[Corporate CLA](https://secure.echosign.com/public/hostedForm?formid=PIE6C7AX856) instead.
|
|
51
80
|
|
|
52
|
-
|
|
53
|
-
Once you do this you will be able to push your changes to your Github repository for others to see and use.
|
|
81
|
+
### Chef Obvious Fix Policy
|
|
54
82
|
|
|
55
|
-
|
|
83
|
+
Small contributions such as fixing spelling errors, where the content is small enough
|
|
84
|
+
to not be considered intellectual property, can be submitted by a contributor as a patch,
|
|
85
|
+
without a CLA.
|
|
56
86
|
|
|
57
|
-
|
|
58
|
-
|
|
87
|
+
As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality
|
|
88
|
+
or creative thinking. As long as the change does not affect functionality, some likely
|
|
89
|
+
examples include the following:
|
|
59
90
|
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
91
|
+
* Spelling / grammar fixes
|
|
92
|
+
* Typo correction, white space and formatting changes
|
|
93
|
+
* Comment clean up
|
|
94
|
+
* Bug fixes that change default return values or error codes stored in constants
|
|
95
|
+
* Adding logging messages or debugging output
|
|
96
|
+
* Changes to ‘metadata’ files like Gemfile, .gitignore, build scripts, etc.
|
|
97
|
+
* Moving source files from one directory or package to another
|
|
63
98
|
|
|
64
|
-
|
|
99
|
+
**Whenever you invoke the “obvious fix” rule, please say so in your commit message:**
|
|
65
100
|
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
101
|
+
```
|
|
102
|
+
------------------------------------------------------------------------
|
|
103
|
+
commit 370adb3f82d55d912b0cf9c1d1e99b132a8ed3b5
|
|
104
|
+
Author: danielsdeleo <dan@opscode.com>
|
|
105
|
+
Date: Wed Sep 18 11:44:40 2013 -0700
|
|
71
106
|
|
|
72
|
-
|
|
73
|
-
helpful to be clear about your use case and change so they can understand it even when it doesn't apply to them.
|
|
107
|
+
Fix typo in config file docs.
|
|
74
108
|
|
|
75
|
-
|
|
109
|
+
Obvious fix.
|
|
76
110
|
|
|
77
|
-
|
|
111
|
+
------------------------------------------------------------------------
|
|
112
|
+
```
|
|
78
113
|
|
|
79
|
-
|
|
80
|
-
However Github has a lot of convenient features, such as being able to see a diff of changes between a
|
|
81
|
-
pull request and the main repository quickly without downloading the branch.
|
|
114
|
+
## <a name="issues"></a> Chef Issue Tracking
|
|
82
115
|
|
|
83
|
-
|
|
84
|
-
a link to the ticket from the pull request. Because pull requests only have two states, open and closed,
|
|
85
|
-
we can't easily filter pull requests that are waiting for a reply from the author for various reasons.
|
|
116
|
+
Chef Issue Tracking is handled using Github Issues.
|
|
86
117
|
|
|
87
|
-
|
|
118
|
+
If you are familiar with Chef and know the component that is causing you a problem or if you
|
|
119
|
+
have a feature request on a specific component you can file an issue in the corresponding
|
|
120
|
+
Github project. All of our Open Source Software can be found in our
|
|
121
|
+
[Github organization](https://github.com/opscode/).
|
|
88
122
|
|
|
89
|
-
|
|
123
|
+
Otherwise you can file your issue in the [Chef project](https://github.com/opscode/chef/issues)
|
|
124
|
+
and we will make sure it gets filed against the appropriate project.
|
|
90
125
|
|
|
91
|
-
|
|
126
|
+
In order to decrease the back and forth an issues and help us get to the bottom of them quickly
|
|
127
|
+
we use below issue template. You can copy paste this code into the issue you are opening and
|
|
128
|
+
edit it accordingly.
|
|
92
129
|
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
130
|
+
<a name="issuetemplate"></a>
|
|
131
|
+
```
|
|
132
|
+
### Version:
|
|
133
|
+
[Version of the project installed]
|
|
97
134
|
|
|
98
|
-
|
|
99
|
-
once on your system before you get started to ensure they all pass so you have a valid baseline. After you write your patch,
|
|
100
|
-
run the tests again to see if they all pass.
|
|
135
|
+
### Environment: [Details about the environment such as the Operating System, cookbook details, etc...]
|
|
101
136
|
|
|
102
|
-
|
|
137
|
+
### Scenario:
|
|
138
|
+
[What you are trying to achieve and you can't?]
|
|
103
139
|
|
|
104
|
-
These tests don't modify your system, and sometimes tests fail because a command that would be run has changed because of your
|
|
105
|
-
patch. This should be a simple fix. Other times the failure can show you that an important feature no longer works because of
|
|
106
|
-
your change.
|
|
107
140
|
|
|
108
|
-
Any new feature should have unit tests included with the patch with good code coverage to help protect it from future changes.
|
|
109
|
-
Similarly, patches that fix a bug or regression should have a _regression test_. Simply put, this is a test that would fail
|
|
110
|
-
without your patch but passes with it. The goal is to ensure this bug doesn't regress in the future. Consider a regular
|
|
111
|
-
expression that doesn't match a certain pattern that it should, so you provide a patch and a test to ensure that the part
|
|
112
|
-
of the code that uses this regular expression works as expected. Later another contributor may modify this regular expression
|
|
113
|
-
in a way that breaks your use cases. The test you wrote will fail, signalling to them to research your ticket and use case
|
|
114
|
-
and accounting for it.
|
|
115
141
|
|
|
116
|
-
|
|
142
|
+
### Steps to Reproduce:
|
|
143
|
+
[If you are filing an issue what are the things we need to do in order to repro your problem?]
|
|
117
144
|
|
|
118
|
-
Chef regularly reviews code contributions and provides suggestions for improvement in the code itself or the implementation.
|
|
119
145
|
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
the patch is ready to be merged, we update the status to _Fix Reviewed_.
|
|
146
|
+
### Expected Result:
|
|
147
|
+
[What are you expecting to happen as the consequence of above reproduction steps?]
|
|
123
148
|
|
|
124
|
-
Depending on the project, these tickets are then merged within a week or two, depending on the current release cycle. At this
|
|
125
|
-
point the ticket status will be updated to _Fix Committed_ or _Closed_.
|
|
126
149
|
|
|
127
|
-
|
|
150
|
+
### Actual Result:
|
|
151
|
+
[What actually happens after the reproduction steps?]
|
|
152
|
+
```
|
|
128
153
|
|
|
129
|
-
## Release
|
|
154
|
+
## <a name="release"></a> Chef Release Cycles
|
|
130
155
|
|
|
131
|
-
|
|
156
|
+
Our primary shipping vehicle is operating system specific packages that includes
|
|
157
|
+
all the requirements of Chef. We call these [Omnibus packages](https://github.com/opscode/omnibus-ruby)
|
|
158
|
+
|
|
159
|
+
We also release our software as gems to [Rubygems](http://rubygems.org/) but we strongly
|
|
160
|
+
recommend using Chef packages since they are the only combination of native libraries &
|
|
161
|
+
gems required by Chef that we test throughly.
|
|
162
|
+
|
|
163
|
+
Our version numbering closely follows [Semantic Versioning](http://semver.org/) standard. Our
|
|
164
|
+
standard version numbers look like X.Y.Z which mean:
|
|
132
165
|
|
|
133
166
|
* X is a major release, which may not be fully compatible with prior major releases
|
|
134
167
|
* Y is a minor release, which adds both new features and bug fixes
|
|
135
168
|
* Z is a patch release, which adds just bug fixes
|
|
136
169
|
|
|
137
|
-
|
|
170
|
+
We frequently make `alpha` and `beta` releases with version numbers that look like
|
|
171
|
+
`X.Y.Z.alpha.0` or `X.Y.Z.beta.1`. These releases are still well tested but not as
|
|
172
|
+
throughly as **Minor** or **Patch** releases.
|
|
173
|
+
|
|
174
|
+
We do a `Minor` release approximately every 3 months and `Patch` releases on a when-needed
|
|
175
|
+
basis for regressions, significant bugs, and security issues.
|
|
138
176
|
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
days to allow for testing for regressions before the final release. If a blocking regression is found then another RC is made containing
|
|
142
|
-
the fix and the timer is reset.
|
|
177
|
+
Announcements of releases are available on [Chef Blog](http://www.getchef.com/blog) when they are
|
|
178
|
+
available.
|
|
143
179
|
|
|
144
|
-
|
|
180
|
+
**TODO**: Can I sign up for a mailing list to get notification of releases?
|
|
145
181
|
|
|
146
|
-
##
|
|
182
|
+
## Chef Community
|
|
147
183
|
|
|
148
|
-
|
|
184
|
+
Chef is made possible by a strong community of developers and system administrators. If you have
|
|
185
|
+
any questions or if you would like to get involved in the Chef community you can check out:
|
|
149
186
|
|
|
150
187
|
* [chef](http://lists.opscode.com/sympa/info/chef) and [chef-dev](http://lists.opscode.com/sympa/info/chef-dev) mailing lists
|
|
151
|
-
*
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
188
|
+
* [\#chef](https://botbot.me/freenode/chef) and [\#chef-hacking](https://botbot.me/freenode/chef-hacking) IRC channels on irc.freenode.net
|
|
189
|
+
|
|
190
|
+
Also here are some additional pointers to some awesome Chef content:
|
|
191
|
+
|
|
192
|
+
**TODO**: Any blogs of community folks that we would like to put in here?
|
|
155
193
|
|
|
194
|
+
* [Chef Docs](http://docs.opscode.com/)
|
|
195
|
+
* [Learn Chef](https://learnchef.opscode.com/)
|
|
196
|
+
* [Chef Inc](http://www.getchef.com/)
|
data/lib/chef/application.rb
CHANGED
|
@@ -44,6 +44,7 @@ class Chef::Application
|
|
|
44
44
|
def reconfigure
|
|
45
45
|
configure_chef
|
|
46
46
|
configure_logging
|
|
47
|
+
configure_proxy_environment_variables
|
|
47
48
|
end
|
|
48
49
|
|
|
49
50
|
# Get this party started
|
|
@@ -165,6 +166,14 @@ class Chef::Application
|
|
|
165
166
|
end
|
|
166
167
|
end
|
|
167
168
|
|
|
169
|
+
# Configure and set any proxy environment variables according to the config.
|
|
170
|
+
def configure_proxy_environment_variables
|
|
171
|
+
configure_http_proxy
|
|
172
|
+
configure_https_proxy
|
|
173
|
+
configure_ftp_proxy
|
|
174
|
+
configure_no_proxy
|
|
175
|
+
end
|
|
176
|
+
|
|
168
177
|
# Called prior to starting the application, by the run method
|
|
169
178
|
def setup_application
|
|
170
179
|
raise Chef::Exceptions::Application, "#{self.to_s}: you must override setup_application"
|
|
@@ -189,9 +198,9 @@ class Chef::Application
|
|
|
189
198
|
server_options = {}
|
|
190
199
|
server_options[:data_store] = data_store
|
|
191
200
|
server_options[:log_level] = Chef::Log.level
|
|
192
|
-
server_options[:port] = Chef::Config.chef_zero.port
|
|
193
201
|
server_options[:host] = Chef::Config.chef_zero.host
|
|
194
|
-
|
|
202
|
+
server_options[:port] = Chef::Config.chef_zero.port
|
|
203
|
+
Chef::Log.info("Starting chef-zero on host #{Chef::Config.chef_zero.host}, port #{Chef::Config.chef_zero.port} with repository at #{chef_fs.fs_description}")
|
|
195
204
|
@chef_zero_server = ChefZero::Server.new(server_options)
|
|
196
205
|
@chef_zero_server.start_background
|
|
197
206
|
Chef::Config.chef_server_url = @chef_zero_server.url
|
|
@@ -242,6 +251,75 @@ class Chef::Application
|
|
|
242
251
|
Chef::Application.fatal!("Aborting due to error in '#{config_file_path}'", 2)
|
|
243
252
|
end
|
|
244
253
|
|
|
254
|
+
# Set ENV['http_proxy']
|
|
255
|
+
def configure_http_proxy
|
|
256
|
+
if http_proxy = Chef::Config[:http_proxy]
|
|
257
|
+
env['http_proxy'] = configure_proxy("http", http_proxy,
|
|
258
|
+
Chef::Config[:http_proxy_user], Chef::Config[:http_proxy_pass])
|
|
259
|
+
end
|
|
260
|
+
end
|
|
261
|
+
|
|
262
|
+
# Set ENV['https_proxy']
|
|
263
|
+
def configure_https_proxy
|
|
264
|
+
if https_proxy = Chef::Config[:https_proxy]
|
|
265
|
+
env['https_proxy'] = configure_proxy("https", https_proxy,
|
|
266
|
+
Chef::Config[:https_proxy_user], Chef::Config[:https_proxy_pass])
|
|
267
|
+
end
|
|
268
|
+
end
|
|
269
|
+
|
|
270
|
+
# Set ENV['ftp_proxy']
|
|
271
|
+
def configure_ftp_proxy
|
|
272
|
+
if ftp_proxy = Chef::Config[:ftp_proxy]
|
|
273
|
+
env['ftp_proxy'] = configure_proxy("ftp", ftp_proxy,
|
|
274
|
+
Chef::Config[:ftp_proxy_user], Chef::Config[:ftp_proxy_pass])
|
|
275
|
+
end
|
|
276
|
+
end
|
|
277
|
+
|
|
278
|
+
# Set ENV['no_proxy']
|
|
279
|
+
def configure_no_proxy
|
|
280
|
+
env['no_proxy'] = Chef::Config[:no_proxy] if Chef::Config[:no_proxy]
|
|
281
|
+
end
|
|
282
|
+
|
|
283
|
+
# Builds a proxy uri. Examples:
|
|
284
|
+
# http://username:password@hostname:port
|
|
285
|
+
# https://username@hostname:port
|
|
286
|
+
# ftp://hostname:port
|
|
287
|
+
# when
|
|
288
|
+
# scheme = "http", "https", or "ftp"
|
|
289
|
+
# hostport = hostname:port
|
|
290
|
+
# user = username
|
|
291
|
+
# pass = password
|
|
292
|
+
def configure_proxy(scheme, path, user, pass)
|
|
293
|
+
begin
|
|
294
|
+
path = "#{scheme}://#{path}" unless path.start_with?(scheme)
|
|
295
|
+
# URI.split returns the following parts:
|
|
296
|
+
# [scheme, userinfo, host, port, registry, path, opaque, query, fragment]
|
|
297
|
+
parts = URI.split(URI.encode(path))
|
|
298
|
+
# URI::Generic.build requires an integer for the port, but URI::split gives
|
|
299
|
+
# returns a string for the port.
|
|
300
|
+
parts[3] = parts[3].to_i if parts[3]
|
|
301
|
+
if user
|
|
302
|
+
userinfo = URI.encode(URI.encode(user), '@:')
|
|
303
|
+
if pass
|
|
304
|
+
userinfo << ":#{URI.encode(URI.encode(pass), '@:')}"
|
|
305
|
+
end
|
|
306
|
+
parts[1] = userinfo
|
|
307
|
+
end
|
|
308
|
+
|
|
309
|
+
return URI::Generic.build(parts).to_s
|
|
310
|
+
rescue URI::Error => e
|
|
311
|
+
# URI::Error messages generally include the offending string. Including a message
|
|
312
|
+
# for which proxy config item has the issue should help deduce the issue when
|
|
313
|
+
# the URI::Error message is vague.
|
|
314
|
+
raise Chef::Exceptions::BadProxyURI, "Cannot configure #{scheme} proxy. Does not comply with URI scheme. #{e.message}"
|
|
315
|
+
end
|
|
316
|
+
end
|
|
317
|
+
|
|
318
|
+
# This is a hook for testing
|
|
319
|
+
def env
|
|
320
|
+
ENV
|
|
321
|
+
end
|
|
322
|
+
|
|
245
323
|
class << self
|
|
246
324
|
def debug_stacktrace(e)
|
|
247
325
|
message = "#{e.class}: #{e}\n#{e.backtrace.join("\n")}"
|
|
@@ -211,6 +211,10 @@ class Chef::Application::Client < Chef::Application
|
|
|
211
211
|
:description => "Point chef-client at local repository",
|
|
212
212
|
:boolean => true
|
|
213
213
|
|
|
214
|
+
option :chef_zero_host,
|
|
215
|
+
:long => "--chef-zero-host HOST",
|
|
216
|
+
:description => "Host to start chef-zero on"
|
|
217
|
+
|
|
214
218
|
option :chef_zero_port,
|
|
215
219
|
:long => "--chef-zero-port PORT",
|
|
216
220
|
:description => "Port to start chef-zero on"
|
|
@@ -250,6 +254,7 @@ class Chef::Application::Client < Chef::Application
|
|
|
250
254
|
if Chef::Config.local_mode && !Chef::Config.has_key?(:cookbook_path) && !Chef::Config.has_key?(:chef_repo_path)
|
|
251
255
|
Chef::Config.chef_repo_path = Chef::Config.find_chef_repo_path(Dir.pwd)
|
|
252
256
|
end
|
|
257
|
+
Chef::Config.chef_zero.host = config[:chef_zero_host] if config[:chef_zero_host]
|
|
253
258
|
Chef::Config.chef_zero.port = config[:chef_zero_port] if config[:chef_zero_port]
|
|
254
259
|
|
|
255
260
|
if Chef::Config[:daemonize]
|
|
@@ -114,6 +114,10 @@ class Chef::Application::Knife < Chef::Application
|
|
|
114
114
|
:description => "Point knife commands at local repository instead of server",
|
|
115
115
|
:boolean => true
|
|
116
116
|
|
|
117
|
+
option :chef_zero_host,
|
|
118
|
+
:long => "--chef-zero-host HOST",
|
|
119
|
+
:description => "Host to start chef-zero on"
|
|
120
|
+
|
|
117
121
|
option :chef_zero_port,
|
|
118
122
|
:long => "--chef-zero-port PORT",
|
|
119
123
|
:description => "Port to start chef-zero on"
|