'ports check' supports for multiply IPs

[taurus-forever]

Hi,

First of all thank you for the nice and really fast tool!

I am trying to check ports using goss v0.0.16 and have a problems with multiply IPs identification:

me@host:~# cat goss.json 
{
    "port": {
        "tcp:1443": {
            "listening": true,
            "ip": "10.0.0.169"
        }
    }
}
me@host:~# netstat -anp | grep 1443
tcp        0      0 10.0.0.169:1443       0.0.0.0:*               LISTEN      23894/nginx     
tcp        0      0 10.0.0.136:1443       0.0.0.0:*               LISTEN      23894/nginx     
tcp        0      0 10.0.2.15:1443        0.0.0.0:*               LISTEN      23894/nginx     
tcp        0      0 127.0.0.1:1443        0.0.0.0:*               LISTEN      23894/nginx     
tcp6       0      0 ::1:1443              :::*                    LISTEN      23894/nginx     
me@host:~# goss -g ./goss.json v
.F

Failures:
Port: tcp:1443: ip: doesn't match, expect: [10.0.0.169] found: [127.0.0.1]

Total Duration: 0.009s
Count: 2, Failed: 1
me@host:~# 

In the same time the following config works well:

me@host:~# cat goss.json 
{
    "port": {
        "tcp:1443": {
            "listening": true,
            "ip": "127.0.0.1"
        }
    }
}

I believe goss should check all available IPs and doesn't fail on the first failed match. Isn't it?

BTW, it would be nice to define multiply IPs like:

{
    "port": {
        "tcp:1443": {
            "listening": true,
            "ip": [ "10.0.0.136" , "10.0.0.169" ]
        }
    }
}

Thank you!

[aelsabbahy]

I've attached a compiled copy from that pull request. I don't have a machine with multiple IPs configured and haven't had the time to create a test for this in docker.

Let me know if the attached version works properly for you and I'll cut a release with this feature.

goss-linux-amd64.zip

This new version is not backwards compatible with old goss.json files, run the following on your existing files to migrate them:

sed -ri 's/("ip": )(".*")/\1[\2]/' goss.json

[taurus-forever]

Tested, briefly looks OK. The initial problem 'ip: doesn't match' has gone.

In same same time the new functionality "ip": [ "1.1.1.1" , "1.1.1.2" ] doesn't really work well.
The current logic is: SUCCESS if the first IP is OK, FAIL if the first IP is NOT OK.
While expected logic IMHO: SUCCESS if ALL IPs are OK, FAIL if some IP is NOT OK.

Maybe we need to have ability to specify match criteria ALL or ANY:

{
    "port": {
        "tcp:1443": {
            "listening": true,
            "ip": [ "10.0.0.136" , "10.0.0.169" ],
            "criteria": "ALL"
        }
    }
}

In the same time it is a way for complication the logic, so maybe you just have to dismiss that new feature request. K.I.S.S.

[aelsabbahy]

I've broken my post down into two sections, please let me know if I'm understanding you correctly for both parts.

My understanding of the IP issue

Here's the behavior I'm getting in my contrived test:

{
    "port": {
        "tcp:22": {
            "listening": true,
            "ip": [
                "0.0.0.0",
                "0.0.0.0"
            ]
        }
    }
}

That gives me count: 2 failed: 0

Changing one of the 0.0.0.0 to anything else causes a failure regardless of which one.

That said, if there were 10 IP's listening on that port, and I only list 2 in my goss.json, only those 2 would be tested and I would get success.

This is the way all the other goss tests work, user resource defining groups is "user is a member of X, Y groups" will succeed even if the user is in X, Y AND Z groups.

I'll cut a release later tonight, thank you for your feedback and testing.

My understanding of new feature

The criteria feature is something that I want to implement at some point, but it would have to affect all resources/attributes. The hard part for me is figuring out a good syntax that's easy to read but allows for the flexibility. Also deciding what to support.

Features, that might be useful:

• ALL/ANY for array attributes
• eq, gt, lt, ge, le for numeric. Ex: user.uid ge 1000 (ensuring user doesn't have an id lower than 1000)
• Negation. ex: file.filetype != "file"

I'm guessing ALL/ANY is the most important one for now. I'll create a ticket to brainstorm this further if this is what you meant.

[aelsabbahy]

This is fixed in v0.0.17

[aelsabbahy]

See #31 for enhanced matcher logic.

[aelsabbahy]

As of v0.1.0 you can now do:

{
    "port": {
        "tcp:1443": {
            "listening": true,
            "ip": { "consist-of": [ "10.0.0.136" , "10.0.0.169" ] },
            "criteria": "ALL"
        }
    }
}

[taurus-forever]

Nice tnx! I will try it.

Is there any place for goss release-notes/changelog I can read?
As I can see you have released 0.0.22 (and even 0.1.0), while I am still using 0.0.16 features list only.

UPDATE: Ah I missed it https://github.com/aelsabbahy/goss/releases tnx!