| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| | |
Update acceptance Gemfile.lock.
|
| |/
|
|
|
|
|
|
| |
Update the Gemfile.lock for chef-acceptance to pull in the latest
test-kitchen version which includes the following fix:
https://github.com/test-kitchen/test-kitchen/commit/53a0eaf452985fa3facdc8f9059cdad012696144
Signed-off-by: Ryan Hass <rhass@users.noreply.github.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`Chef::ReservedNames::Win32::Security::SID.current_user` throws an error when `chef-solo` is being
run as a `SYSTEM` user:
```
================================================================================
Chef encountered an error attempting to load the node data for "WIN-00P0BGAA4IV"
================================================================================
Unknown Server Error:
---------------------
The server had a fatal error attempting to load the node data.
Server Response:
----------------
Exception raised! #<Chef::Exceptions::Win32APIError: No mapping between account names and security IDs was done.
---- Begin Win32 API output ----
System Error Code: 1332
System Error Message: No mapping between account names and security IDs was done.
---- End Win32 API output ----
>
c:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44-universal-mingw32/lib/chef/win32/error.rb:81:in `raise!'
c:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44-universal-mingw32/lib/chef/win32/security.rb:383:in `lookup_account_name'
c:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44-universal-mingw32/lib/chef/win32/security/sid.rb:44:in `from_account'
c:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44-universal-mingw32/lib/chef/win32/security/sid.rb:241:in `current_user'
c:/opscode/chefdk/embedded/lib/ruby/gems/2.3.0/gems/chef-12.17.44-universal-mingw32/lib/chef/chef_fs/file_system/repository/nodes_dir.rb:41:in `create_child'
```
This commit modfies these calls to use `SID.default_security_object_owner` instead which will return
`SID.Administrators` for users such as `SYSTEM` and then returns `SID.current_user` for everyone else.
Signed-off-by: Scott Christopherson <scott@chef.io>
|
| | |
|
| |\
| |
| | |
Report a blank resource if sensitive is enabled
|
| | |
| |
| |
| | |
Signed-off-by: Salim Afiune <afiune@chef.io>
|
| | |
| |
| |
| | |
Signed-off-by: Salim Afiune <afiune@chef.io>
|
| | |
| |
| |
| | |
Signed-off-by: Salim Afiune <afiune@chef.io>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
COOL-642/ZD 12936 - Chef Manage Run History compromises sensitive data
Before this commit we were sending sensitive resource information to
Reporting and therefor you were able to see the sensitive data on the
Run History in the Chef Manage Console.
This commit is fixing this problem and now it is transforming any
sensitive resource to display the word `*sensitive*` instead of the
actual data. As we are inserting this values directly to the data base,
it means that this change will cascade all the way to the front-end.
Catch: Old data that was already reported and is displaying sensitive
data will contineu to be displayed. Apologize.
Signed-off-by: Salim Afiune <afiune@chef.io>
|
| | | |
|
| |\ \
| | |
| | | |
fix dscl group provider func breakage from #5673
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
i didn't fully grok the way the dscl providers were written and
only half fixed the group dscl provider, but later did a better
job fixing the user one.
fixes the breakage caught in the dscl group func tests.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
fix aix breakage from #5673
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
cleanup of ifconfig and route providers
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* run_command elimination
* shell_out array usage
* other misc cleanup
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |/ / |
|
| |\ \
| |/
|/| |
user provider cleanup
|
| | |
| |
| |
| |
| |
| |
| |
| | |
* removes more run_command
* converts to shell_out_compact
* some other misc style cleanup
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |\ \
| |/
|/| |
Wipe the 12.17 release notes and start 12.18 release notes
|
| | |
| |
| |
| |
| |
| |
| | |
I added a section for the deprecations. Let me know if that format makes
sense. This process was defined in RFC-082
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
|
| |\ \
| | |
| | | |
cleanup of group provider
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- consistent use of shell_out_compact!
- remove more uses of run_command
- some other code cleanup
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Use the same task name used by the chef-client cookbook so that the task can be managed by its task recipie
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
be managed by its task recipie
Signed-off-by: Matt Wrock <matt@mattwrock.com>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
fix master breakage
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
pressed merged too fast
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
bump ruby versions in travis
|
| | | |/ /
| |/| |
| | | |
| | | | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | | |
Style/NumericPredicate comparison style
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
formally deprecate run_command
|
| | | | |
| | | |
| | | |
| | | | |
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>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
remove chef-provisioning-aws from travis
|
