* Un-deprecate plural properties on shadow; deprecate the singular versions
* Update filtertable interface to current
* A weak attempt at making the docs coherent
* Doc feedback per Jerry
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
* Add tests for method chained shadow resource with readable and
unreadable shadow files.
Ensure @params always has a safe value, otherwise we may stacktrace when
unable to read /etc/shadow and invoked with method chaining.
* Wrap deprecation notices with a proc/must_output to clean up test
output.
Added some missing newlines.
Catch deprecation notice on `lines`.
* Resolve the majority of the issues pointed out by @tbramble.
Deprecate `lines`; its really only used internally but it was 'exposed'
through tests and who knows if there is external use. `lines` is not
documented as a property at least..
`#set_params` is much better now =)
Signed-off-by: Miah Johnson <miah@chia-pet.org>
* Create file-check functionality into utility file
There are the similar issues as PR #2302. Almost resources return false
positives when a file does not exist or is not read.
* Replace to file-check functionality
* Fix dh_params and x509_certificate resources
If a file is empty, OpenSSL::PKey::DH and OpenSSL::X509::Certificate have
raised an exception and have skipped the inspection. Thus x509_certificate
and dh_params resources are not allowed to read a empty file.
* to_s of shadow expects filters is not nil
* Remove workaround of sshd_config
Removes the workaround of sshd_config since Travis CI fails due to a bug
of dev-sec/ssh-baseline and the PR #100 will fix it.
* Use init block variable in methods
Signed-off-by: ERAMOTO Masaya <eramoto.masaya@jp.fujitsu.com>
shadow file.
After much thought the deprecations from #2642 were for the wrong methods.
Plural method names feel much more natural when working with this
resource because you can have more than a single result.
Consider a match like `shadow.user(/^www/)`, this could return multiple
users, so `shadow.users` feels more natural here.
The problem is that the fields we're matching in the shadow file itself
are singular. Each entry is for a user, which has a password, and some
other fields. A user never has `passwords` in the shadow file, only a
`password`.
This is made more obvious when you use the `filter` method.
When we use this filter: `shadow.filter(min_days: 20, max_days: 30)` we
are matching fields in the shadow file and not using our matcher
methods. This means that if there is a discrepancy between our matcher
methods, and the shadow fields the user could end up confused. Like I did =)
This PR changes:
Changed matchers to match shadow fields.
Updated documentation to reflect changes.
Updated tests to reflect changes.
Re-add `filter` method, and add a test for it.
Renamed variable for FilterTable to be less confusing.
Renamed query argument for methods to be consistent.
Cleanup docs based on comments from @jerryaldrichiii
Make Rubocop happy <3
Signed-off-by: Miah Johnson <miah@chia-pet.org>
Removes skip_resource and raise .. if InSpec.os stuff from initialize as this is covered by platform support.
Signed-off-by: Miah Johnson <miah@chia-pet.org>
* Change shadow resource to use FilterTable rather than custom filter
implementation.
Add tests for singluar aliased methods and other minor changes to work
with FilterTable output.
Coverage is at 100%
Signed-off-by: Miah Johnson <miah@chia-pet.org>
* merge master
Signed-off-by: Miah Johnson <miah@chia-pet.org>
* Add correct `supports platform` to resources.
Signed-off-by: Miah Johnson <miah@chia-pet.org>
* Remove 'os_family' and update platforms to specify what they did.
Signed-off-by: Miah Johnson <miah@chia-pet.org>
* Add esx and cisco to generic resources.
Signed-off-by: Jared Quick <jquick@chef.io>
When used in combination: `shadow[.filter(...)].entries.each { |entry| ... }`, these entries would not be very descriptive at all. You would basically only retrieve the full filter chain e.g. 20 times, without any information about what entry you are currently looking at. This fixes it, by providing the entry identified by the user name
Many of the resources are named as a top-level class with a fairly generic class name, such as "OS". This causes an issue specifically with kitchen-google which depends on a gem which depends on the "os" gem which itself defines an OS class with a different superclass. This prevents users from using TK, Google Compute, and Inspec without this fix.
Some mocked commands had their digest changed as well due to the new indentation, specifically in the User and RegistryKey classes.
I strongly recommend viewing this diff with `git diff --ignore-space-change`
to see the *real* changes. :)
