| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This works exactly like with an underscore, but is a bit more user-friendly sometimes (e.g. `get_config` vs `get-config`).
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
| |
absolutely hard requirement on the fixes that went into chef-config 2.2.11, so the
floor of that gem is bumped up.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
|
|
| |
We already know the plugin name so there's no need to use find in order to return the plugin name.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
|
|
|
|
| |
Remove the mention of Chef .10
Remove terremark and bluebox
Add more modern plugins
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
|
|
|
| |
ensure that trace level is selectable if necessary via -VVV
Pass the correct object to net/ssh
Signed-off-by: Thom May <thom@chef.io>
|
|
|
|
| |
chef server API"
|
|\
| |
| | |
Knife should give a useful error when the chef_server_url isn't a chef server API
|
| |
| |
| |
| | |
Signed-off-by: Jose Asuncion <jeunito@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Jose Asuncion <jeunito@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The pre-14 precedence level is:
1. mixlib-cli setting
2. mixlib-cli default
3. mixlib-config setting
4. mixlib-config default
This means that if an option has a mixlib-cli default that it cannot
ever be set in the config file.
This PR swaps 2+3 around:
1. mixlib-cli setting
2. mixlib-config setting
3. mixlib-cli default
4. mixlib-config default
Now the mixlib-cli defaults still take precedence over mixlib-config
defaults, but it is possible to set a value in config.rb if there's
a mixlib-cli default setting (which creeps into the settings in hidden
ways if you just use `boolean: true` in mixlib-cli).
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
| |
| |
| |
| |
| | |
This is a pretty common first error message to experience with Chef. Let's point the users to a helpful location so they can quickly get up and running. Add some YARD comments while I was in the config class
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|\ \
| | |
| | | |
implement credential management
|
| |/
| |
| |
| | |
Signed-off-by: Thom May <thom@chef.io>
|
|/
|
|
| |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
| |
Signed-off-by: nimisha <nimisha.sharad@msystechnologies.com>
|
|
|
|
| |
Signed-off-by: nimisha <nimisha.sharad@msystechnologies.com>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
| |
department of redundancy department
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently rubocop thinks the default behavior should be that we have to
rewrite every use of `foo == 0` into `foo.zero?` which is a big pile of
NOPE for me. After discovering that `.zero?` is actually slower, I'd
prefer to go the other direction. Same for `positive?` and
`negative?`.
These are the only uses of `zero?` in the chef/chef codebase, while I'm
pretty sure the inverse rule would touch nearly every file.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|\
| |
| | |
[Knife] Fix deprecation warning when creating data bag items
|
| |
| |
| |
| |
| |
| | |
Fixes chef/chef-vault#215
Signed-off-by: Thom May <thom@may.lt>
|
|/
|
|
|
|
|
|
|
|
|
| |
The `--config-option` CLI option allows setting any `Chef::Config`
setting on the command line, which allows applications to be used
without a configuration file even if a desired config option does not
have a corresponding CLI option. This CLI option was present in the help
output for knife but was not actually implemented. Moving the behavior
into chef-config allows us to use it for both `chef-client` and `knife`.
Signed-off-by: Daniel DeLeo <dan@chef.io>
|
|
|
|
|
|
| |
this was not supposed to be private
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
| |
this is part of our informal style guide, lets make it formal since
clearly its not getting followed very well.
|
|\
| |
| | |
Autofixing new Perf cops in 0.37.2
|
| |
| |
| |
| | |
added some FIXMEs because trying to sort out types for random undocumented code was making me completely aggro
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6 Performance/Casecmp
18 Performance/Detect
1 Performance/RangeInclude
27 Performance/RedundantBlockCall
6 Performance/RedundantMatch
5 Performance/RedundantMerge
18 Performance/StringReplacement
|
|/
|
|
| |
instead of using the hash file
|
|
|
|
|
|
|
| |
This just codifies the behaviour we're actually using - that we're
passing a json string and expecting a hash back.
Also adds a deprecation warning to the use of Chef::JSONCompat.from_json
|
|
|
|
| |
this looks nicer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
4174 Style/SpaceInsideHashLiteralBraces
1860 Style/SpaceAroundOperators
1336 Style/SpaceInsideBlockBraces
1292 Style/AlignHash
997 Style/SpaceAfterComma
860 Style/SpaceAroundEqualsInParameterDefault
310 Style/EmptyLines
294 Style/IndentationConsistency
267 Style/TrailingWhitespace
238 Style/ExtraSpacing
212 Style/SpaceBeforeBlockBraces
166 Style/MultilineOperationIndentation
144 Style/TrailingBlankLines
120 Style/EmptyLineBetweenDefs
101 Style/IndentationWidth
82 Style/SpaceAroundBlockParameters
40 Style/EmptyLinesAroundMethodBody
29 Style/EmptyLinesAroundAccessModifier
1 Style/RescueEnsureAlignment
|
|\
| |
| | |
Allow use of command line fips switch for knife
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This somewhat worked before. However, it was just for knife bootstrap.
It also didn't support --no-fips in the case where it was in your
knife.rb and you decided that you didn't want to use fips for
that one call.
The assumption here is fips mode you run knife with is the fips
mode the node will get. This has the nice property that validatorless
bootstraps will talk to the chef server in fips mode if the node
is requested to be in fips mode.
|
| |
| |
| | |
Generated via git ls-files | xargs perl -pi -e "s/(Author.*?<[^@]+@)(?:opscode\\.com|getchef\\.com)(>)/\\1chef.io\\2/gi"
|
| |
| |
| | |
Created via git ls-files | xargs perl -pi -e "s/(Copyright.*?), Opscode(,)? Inc(\.)?/\\1, Chef Software Inc./gi"
|
|/
|
| |
Generated via git ls-files | xargs perl -pi -e "s/[Cc]opyright (?:\([Cc]\) )?((?\!$(date +%Y))\\d{4})(-\\d{4})?([, ][ \d]+)*(,|(?= ))/Copyright \\1-$(date +%Y),/g"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some notes:
* Add module overrides for fips
We need to use the SHA1 module under OpenSSL because the openssl
functions called by Digest::SHA1 cause openssl to crash the process.
We use the Digest::MD5 over the OpenSSL::MD5 module because md5
is not allowed when in fips mode and causes the process to crash.
While we work through these issues, we're going to allow it to
pass by compiling the ruby md5 implementation.
* Use OpenSSL::Digest::SHA256 instead of Digest::SHA256
Digest::SHA256 is broken in fips mode because it uses
unapproved APIs. They cause the process to terminate.
|
|
|
|
|
|
| |
See chef/chefstyle#11 for analysis and discussion. We select '{}' since
audit of our source code shows that is the most common, and that used to
be the dominant learning paradigm (e.g. in ruby 1.9 pickaxe book.
|
|
|
|
|
|
|
| |
This is an entirely mechanically generated (chefstyle -a) change, to go
along with chef/chefstyle#5 . We should pick something and use it
consistently, and my opinion is that double quotes are the appropriate
thing.
|
|
|
|
|
|
|
| |
In the process, stop auto-expanding JSON in the HTTP client, and let
individual classes control that themselves.
Fixes #2737, Fixes #3518
|
|\
| |
| | |
Use signing protocol 1.1 by default
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All supported Chef servers support the 1.1 signing protocol.
There is no reason to continue using 1.0, and removing it
as the default allows us to remove a bunch of code that tries
to upgrade 1.0 to 1.1 when the node name is too long.
If the user specifies 1.0 as the auth protocol version from
this point on, they will have to guarantee that the node
name is not too long.
|