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

Deprecated: preg_replace() error when beeing assigned to many roles #5164

Open
robertkrenn opened this issue Dec 14, 2023 · 3 comments
Open

Comments

@robertkrenn
Copy link

After updating to php 8.1 users who have more than ~70 roles assigned, get the following message

Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /usr/share/icinga-php/vendor/vendor/shardj/zf1-future/library/Zend/Db/Statement.php on line 212

It's really on the amount of assigned roles. We already assigned role by role without getting the error. Also assigning 60 roles and less doesn't shows it. We have many business processes and one role for each bp, so the responsible collegue only sees his own hosts and services. But his teamleader sees all objects below while beeing assigned to all roles.

Expected behavior

not throwing an Deprecated Error when beeing assigned to many roles.

Screenshots

If applicable, add screenshots to help explain your problem.
grafik

Your Environment

Include as many relevant details about the environment you experienced the problem in

  • Icinga Web 2 version and modules (System - About): 2.12.1
  • Web browser used: firefox / Microsoft Edge
  • Icinga 2 version used (icinga2 --version): 2.14.0
  • PHP version used (php --version): 8.1
  • Server operating system and version: SLES 15 SP5

Additional context

@nilmerg
Copy link
Member

nilmerg commented Dec 18, 2023

Hi,

the error you get is only a symptom. Since the user's in question, which get the error, are members of so many roles, I guess most if not all roles define a restriction? Then queries get pretty large due to a large filter. The part of the code which is the actual reason, seems to have a problem with that.

Try increasing the PCRE backtrack or recursion limit.

Please report back where you've changed these directives if it doesn't have the desired effect.

@nilmerg nilmerg added the needs-feedback We'll only proceed once we hear from you again label Dec 18, 2023
@robertkrenn
Copy link
Author

Hi,
well, it doesn't have any effect. I changed the directives in /etc/php8/apache2/php.ini and /etc/php8/cli/php.ini
Yes, every role has filters on the monitoring and icingadb module to view only selected hosts and services. This way we ensure that our application consultants don't see notifications they are not responnsible for.

@nilmerg nilmerg removed the needs-feedback We'll only proceed once we hear from you again label Dec 19, 2023
@nilmerg
Copy link
Member

nilmerg commented Dec 19, 2023

Then you should think about changing the role configuration. It may be possible to reduce the number of roles to one, by optimizing the restrictions.

Say, you have three roles, each with a restriction:

hostgroup_name=a
hostgroup_name=b
hostgroup_name=c

They can be combined like this:

hostgroup_name=(a|b|c)

The goal is to reduce the number of conditions. To minimize the size of the resulting expressions in the queries. You can see the size of the filter in the audit view. Navigate to Configuration -> Access Control -> Audit (Tab) and enter the name of the affected user. Then scroll to the monitoring module's restrictions and click on the right.

I know, this is probably not an easy task. But given such a high number of roles, and the problem being limited to users with that much roles, I think this is a safe bet that it would solve the issue. (and enhance future maintainability?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants