Restricting by servicegroup_name not only hides services, but also hosts

[aanriot]

Update: (by @nilmerg)

This is related to #3349 and is avoidable the same way: By custom variables.

Instead of restricting on servicegroup_name, use a custom variable: _service_adminonly!=yes

Original: Hello,

I performed an upgrade of icingaweb2 and it appears that the Hosts Overview becomes empty when using the following filter:

monitoring/filter/objects = "servicegroup_name!=adminonly"

The /monitoring/list/hosts view displays:

No hosts found matching the filter.

Here is the content of the whole roles.ini file:

[Administrators]
users = "admin"
permissions = "*"
groups = "Administrators"

[Techs]
groups = "Techs"
permissions = "module/monitoring, monitoring/command/*, monitoring/command/schedule-check, monitoring/command/acknowledge-problem, monitoring/command/remove-acknowledgement, monitoring/command/comment/*, monitoring/command/comment/add, monitoring/command/comment/delete, monitoring/command/downtime/*, monitoring/command/downtime/schedule, monitoring/command/downtime/delete, monitoring/command/process-check-result, monitoring/command/feature/instance, monitoring/command/feature/object/*, monitoring/command/feature/object/active-checks, monitoring/command/feature/object/passive-checks, monitoring/command/feature/object/notifications, monitoring/command/feature/object/event-handler, monitoring/command/feature/object/flap-detection, monitoring/command/send-custom-notification, module/grafana"
monitoring/filter/objects = "servicegroup_name!=adminonly"

Previously, only the services being in the adminonly servicegroup where hidden, but all Hosts were displayed correctly in the overview page.

All hosts become visible when I remove this setting.

I'm using:

• Icinga Web 2 in version 2.6.1 (enabled modules: monitoring generictts grafana) ;
• Icinga2 in version 2.9.1-1 (enabled features: api checker command graphite ido-mysql mainlog notification) ;
• Debian Stretch (amd64).

I haven't seen any item in the changelog that could explain this behaviour change, but I may have missed something.

Thanks a lot.

Best regards,

[lippserd]

Hi,

Thanks for the report. I'll have a look asap.

Cheers, Eric

[aanriot]

Hello @lippserd ,

By any chance, did you find the time to look at the issue?

Thanks a lot.

Cheers,

[lippserd]

Hi,

I'll have a look at this one for our 2.6.2 release next week.

Best, Eric

[nilmerg]

That's a direct result of #2934 introduced with v2.6.0.

pre 2.6: Any amount of unequal comparisons to linked objects (e.g. list/hosts?hostgroup_name!=foo as well as list/hosts?hostgroup_name!=foo&service_description!=bar) return unwanted/wrong results. post 2.6: Such a comparison returns less results. (i.e. No hosts which are a member of any hostgroup besides foo (while being a member of foo) and no hosts which have any other service other than bar (while having one named bar))

It's also related to #3349. Though here we want to still see hosts (and probably hostgroups) despite the fact they have services (or are related to servicegroups) which match the restriction. As I see it, both requests want to specifically apply restrictions to specific objects. #3349 to hosts and this here to services.

So while this clearly changed with v2.6.0 I'd consider this a feature the same way as #3349. @lippserd Agreed?

[lippserd]

3349 is the same for servicegroup_name filters in the service group view. But we're talking about all other views here. The negation filters with our new subquery filter implementation produce invalid results. If I use a negated filter for a service group which actually exists, I don't see any host in the hosts view. Same for the hostgroup view. I'll have a look.

[pknutti]

Hi @lippserd,

what's the current status? Is there a workaround or do you know when the bug occurs? Currently I could have the same problem with filtering objects. The strange thing is that I don't know why it works with a filter like "monitoring/filter/objects:" "hostgroup_name=datascience" but not with "monitoring/filter/objects:" "hostgroup_name=webservices". Futhermore I had a curios behavior by filtering the same things for director but exaclty the other way around :/

I have updated my version if icingaweb2 to 2.6.3. Hopefully you can give me a hint how to resolve this phenomenon

[ghost]

Hello, Here is a proposal for a solution: The change in the filter was made by a request. Then it will be needed as well. But the old filter function (do not show only the filtered services) is also still needed, because status of individual services should be hidden for some user groups. The easiest way is to implement another filter in Icingaweb2 with exactly the same old function. Best Regards

[widhalmt]

ref/NC/626507

[peteeckel]

Just for the record: I just fell victim to exactly the same issue.

To make things worse, filters like "hostgroup_name!=hostgroup & servicegroup_name!=servicegroup" don't work either in monitoring/filter/objects -- while I can click them together in the GUI (which works) pasting the resulting filter in the filter entry field does not work either, the expression is not parsed correctly.

[nilmerg]

@peteeckel This sounds more like #3886. Are you using v2.7.0? If so, does #3903 fix your issue?

[peteeckel]

@nilmerg I don't see the connection with #3886, to be honest. There are no wildcards whatsoever involved.

I am seeing two problems, both with 2.6.3 as well as with 2.7.0. The first is exactly the one described in this issue. Example:

I have some hosts in host group test-hosts and some services in service group test-services and want to limit access for certain roles to services and groups not in either of these groups.

The simple filter

monitoring/filter/objects="hostgroup_name!=test-hosts&servicegroup_name!=test-services"

does not work. The user can now see all services not in the test-services group (which is fine), but no hosts at all. Which is a bit strange, as both the first and the second term yield the expected results:

monitoring/filter/objects="hostgroup_name!=test-hosts"
monitoring/filter/objects="servicegroup_name!=test-services"

Both work fine, in the first case the user sees all hosts but the ones in test-hosts, in the second case all services except the ones in test-services. In the conjugative term, the first part does not work at all (excluding all hosts), the second one works fine. This is not a matter of order though, as

monitoring/filter/objects="servicegroup_name!=test-services&hostgroup_name!=test-hosts"

leads to exactly the same behaviour (no hosts at all can be seen while services are filtered correctly).

The second problem that I see (quite possibly connected) is that while it's possible to click the correct filter together in the GUI and its text representation is exactly as expected (servicegroup_name!=test-services & hostgroup_name!=test-hosts), pasting this into the text entry field for a filter parses incorrectly and results in the nonsensical filter (copied from the GUI filter display)

Hostgroup Name != test-hosts & servicegroup_name!

Again, clicking this together in the GUI filter edior works perfectly and yields exactly the correct result.

I suspect that the filter expression parser somehow messes this up.

[nilmerg]

@peteeckel I see, thanks for the feedback. Though, please open a new issue for the parsing (second) issue.

[nilmerg]

To sum this finally up: This has definitely changed with v2.6, though in a positive way since the previous behavior was wrong. (As detailed in https://github.com/Icinga/icingaweb2/issues/2934#issuecomment-387350025)

What this issue is about is that the object restriction of the monitoring module has now (rightly so) an effect on all objects. If you restrict a role to objects not related to host-group prod-hosts, you won't see any host that is related to it. Nor any service which is related to the same host. This gets especially obvious by restricting on a service-group, since a host has many services which all may be part (or not) of this service-group. So the chance of not seeing the host is even more greater.

Currently there is no way to define a filter the way you get the results you desire as described in this issue. This will change with #3349, by which we add support for a new filter operator (or a similar thing)

[peteeckel]

@nilmerg While I see what you're aiming at, I tend to disagree at least insofar as the current behaviour is a) unexpected and b) inconsistent.

When I create a filter, say, for the Service Grid in the GUI filter editor and filter for the two criteria I described above, I get quite exactly the behaviour I expect:

AND
|- Hostgroup Name != test-hosts
|- Servicegroup Name !- test-services

Now the service grid shows all but the services in the test-service group and services on hosts in the test-host group, which is precisely what I would expect and what I intended.

But there is no way to get the same result with filters in the monitoring/filter/objects setting, which is at the very least surprising, as the syntax for the filters and their general purpose is the same. I don't think it's a good idea to surprise users.

Given the inconsistency in the behaviour and the fact that parsing complex expressions in general does not seem to work correctly #3910 I still regard this is a bug.

[nilmerg]

@peteeckel If there's any inconsistency, that's an entirely different issue. If you get the desired results with the filter editor but not with the restriction then please open a new issue. If you do so, please attach a detailed example so that we can reproduce this.

[peteeckel]

Will do - I'll create a minimal setup demonstrating the inconsistency later on.

[Foxeronie]

Hey, I think my problem is the same as yours. I try to filter some services for a role by adding them to a Servicegroup and hide this group via monitoring/filter/objects

My rule: "servicegroup_name!=im Leitstand verborgen"

When another service of a host is critical AND has a service within this service_group I can click the critical service, but as soon as I click the Host or Services tab I get the error message "Host not found"

Service is viewable (not in the servicegroup):

When I click "Host" or "Services":

Icinga Web 2 Version 2.7.1 Git commit c3603c991df2ae2e0e5d03968f54216f4086f198

Do you need some other informations that help you to find the problem?

Best regards, Patrick

[nilmerg]

@Foxeronie It's not a problem. Although I understand (in your case) why you'd think it is one. :laughing: But it clearly shows what this issue is about. :+1:

By using custom variables in restrictions this doesn't occur, though. I'll update the OP as well, since this doesn't seem to be very well known.