| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
net/https just calls openssl and net/http. We can just do that ourselves
and avoid the extra layer
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
| |
We generally always do protocol negotiation on the get of the node
object and the Chef::Node is an unversioned API, so we need to
test that we backoff the API version to the highest version the server
offers and then retry again.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Pete Higgins <pete@peterhiggins.org>
|
|
|
|
| |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
|
|
| |
Autocorrected from RuboCop Performance which is now smart enough to detect when you use the match and when you don't. Using match? does not create any objects so it's slightly faster and uses less memory.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So it turns out the `berkshelf` has been passing it's entire `options`
hash into `Chef::HTTP` this whole time, which, we should probably fix.
However, one of those options was `:ssl_verify_mode`. We ignore entries
in the `options` hash we don't recognize so this was fine, but suddenly
we recognize it. But we expected it to be class, and they're passing
in symbols. Whoops!
This makes that all work and puts the symbol->class conversion inside
of `Chef::HTTP`.
Signed-off-by: Phil Dibowitz <phil@ipom.com>
|
|\
| |
| | |
Add ssl_verify option for remote_file
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Different servers have different https requirements and enforcing
the API policy on all `remote_file` resources isn't reasonable.
The logic around the HTTP clients and policies in Chef is... complex.
This approach seemed like the best one, but I'm open to others.
By default here if the user specifies nothing, `remote_file`'s http
clients will fall back to the API policy, otherwise, it'll use whatever
the specify.
This fixes #8897
Signed-off-by: Phil Dibowitz <phil@ipom.com>
|
|/
|
|
| |
Signed-off-by: Pete Higgins <pete@peterhiggins.org>
|
|
|
|
|
|
|
|
| |
Legally incredibly dubious, particularly since we don't follow it
strictly as policy, and we have git history instead, which does it right.
This is just a waste of time and a cargo cult.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the implementation of [RFC-087](https://github.com/chef-boneyard/chef-rfc/blob/master/rfc087-distro-sugar-helpers.md)
although some of the specifics have been iterated on and changed.
The documentation will be in the [README.md](https://github.com/chef/chef/tree/master/chef-utils/README.md) once this is merged.
While this PR mostly moves chef-sugar utilities into core-chef via this chef-utils gem, the scope of the chef-utils gem
should be considered larger than just that. As an example this PR moves the Mash class into this gem for reuse in ohai
as well.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
| |
enforce pretzels.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
| |
convert kind_of? to is_a?
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
| |
given how many regexps we have with /'s in the match this seems like
a very good one.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
| |
start enforcing using %i{} instead of arrays of symbols
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
| |
i like this one, gives visual priority to returns or raises that are
buried in the middle of things.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
| |
Stops the kernel from scanning through all the activated gems every time in order
to resolve names into pathnames.
See rubygems/rubygems#2762
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
| |
This gives a speed boost since rubygems does not have to scan through
every gem in the gemset in order to find the file.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
| |
includes backcompat for 2.5
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|\
| |
| | |
Stripping Authorization header upon redirects (second try)
|
| |
| |
| |
| | |
Signed-off-by: Noam Lerner <noamler@fb.com>
|
|/
|
|
| |
Signed-off-by: Thom May <thom@chef.io>
|
|
|
|
| |
This reverts commit 08b31872bf4094bbef474cae6de6c90fb4245a99.
|
|
|
|
| |
Signed-off-by: Noam Lerner <noamler@fb.com>
|
|
|
|
|
|
|
|
|
|
| |
For the truncated downloads the tiny server needs to hit its
RequestTimeout in order to terminate the truncated request, so that
is set to 1 second. Then also drop down the retries and the
rest_timeout on the client side (but keep the rest_timeout to 2 to
keep it above the tiny_server timeout)
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
| |
use this to inject the tempfile from
Chef::FileContentManagement::Tempfile
closes #2401
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on the first pass through the JSON middleware it encodes the
body. if there's a retry, it re-encodes the body as a string
with all its metacharacters escaped.
this is a particular issue when doing a first request that is
a POST that requires negotiating the API version. when doing a
GET it isn't a problem because there's no body payload -- but a
POST or a PUT which requires a retry will get garbled and will
cause a 500.
this happens on hosted right now if trying to POST with a v2
API since hosted is only v1, so there's a retry to downgrade.
i also made the same kind of changes to the streaming download
requests, but since they're GETs its unclear to me if there was
any impact there -- but middleware could have been double-mangling
headers on a retry.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
| |
Signed-off-by: Thom May <thom@chef.io>
|
|
|
|
|
|
| |
I think this happened when we merged the Opscode and Chef copyrights
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Depending on how you configure your Chef client, it's possible that a
later retry would have an authentication timestamp header
(`X-OPS-TIMESTAMP`) that was more than 900 seconds old. Since the Chef
server treats timestamps older than this threshold as unauthorized
requests, you would potentially get seemingly spurious "401
Unauthorized" responses from the server.
A solution is to generate the headers on each retry so that we have a
new authentication timestamp for each retried request.
Signed-off-by: Shane da Silva <shane@dasilva.io>
|
|
|
|
| |
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 mildly awful, but works around the String-vs-URI crap
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
| |
turn on only for the cookbook synchronizer
|
| |
|
| |
|
| |
|
|\
| |
| | |
Remote file download progress
|
| |
| |
| |
| | |
Add tests around progress output and tidy up
|
| |\
| | |
| | |
| | | |
https://github.com/brandocorp/chef into tm/remote_file_download_progress
|
| | | |
|
| | | |
|
| | | |
|