Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port resource returns arrays #256

Closed
chris-rock opened this issue Nov 24, 2015 · 2 comments
Closed

Port resource returns arrays #256

chris-rock opened this issue Nov 24, 2015 · 2 comments
Labels
Type: Bug Feature not working as expected
Milestone

Comments

@chris-rock
Copy link
Contributor

process, pid and protocol for port all get compared to an array instead of string/number causing weirdness like this

Port  22 pid should eq "957"
    Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }

      expected: "957"
           got: [957]

Thanks for reporting Thomas Cate

@chris-rock chris-rock added the Type: Bug Feature not working as expected label Nov 24, 2015
thomascate pushed a commit to thomascate/openstack-model-t that referenced this issue Nov 30, 2015
You might want to hold off on merging this until inspec goes 1.0. Currently several of the port tests will fail due to inspec/inspec#256.
@chris-rock
Copy link
Contributor Author

I reviewed the implementation and the documentation. The challenge with the port resource is that is applies to all available ip addresses on the machine. From my point of view we should change the tests to reflect this behavior. This would look like the following:

# test port 22 on all IP addresses
describe port(22) do
    it { should be_listening }
    its('protocol') { should include('tcp') }
 end

In addition, we may think to extend the port variable with an IP parameter. This would enable us to just return one value instead of an array. e.g.

# test port 22 for a specific IP address
describe port('0.0.0.0', 22) do
    it { should be_listening }
    its('protocol') { should eq 'tcp' }
 end

@thomascate @jjasghar @arlimus What do you think?

@thomascate
Copy link
Contributor

I like this change. Thinking about this, people are going to be concerned about what IP things are listening on. So this would solve for "Make sure MySQL is only listening on localhost" etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Feature not working as expected
Projects
None yet
Development

No branches or pull requests

2 participants