REST API - Creating host and applying template does not create all ACL for services

[littlejawa]

Centreon Web version: found on 2.8.9. Reproduced on 2.8.26

Centreon Engine version: 1.7.2

Centreon Broker version: 3.0.7

OS: found on CentOS (installed from packages). Reproduced on Debian Jessie (installed from sources)

Description:

Using the API, if you create a HOST with template services attached then apply the template, the ACLs for the services are not all created, preventing users from seeing the associated services. This is happening if the "centACL.php" script has been executed between the ADD operation, and the APPLYTPL operation. If centACL.php is executed after the two operations are passed, the problem does not occur.

Since centACL.php is executed as a cron task, we can't control when it operates, and then the problem seems to occur randomly, depending on how the scheduling occurs.

Using the Web Interface, things are working as expected.

Steps to reproduce the issue:

1. Create a new host using the REST api, using a host template linked to services

curl 'http://centreonSRV/centreon/api/index.php?action=action&object=centreon_clapi' -H 'Content-Type: application/json' -H 'centreon-auth-token:[VALID TOCKEN]' --data '{"action":"ADD", "object":"HOST", "values": "TOTO;TOTO;toto.mydomain.lan;HostTemplate;Central;"}'

2. Wait for the scheduled centAcl.php script to be run

3. Apply the template on this new host

curl 'http://centreonSRV/centreon/api/index.php?action=action&object=centreon_clapi' -H 'Content-Type: application/json' -H 'centreon-auth-token:[VALID TOCKEN]' --data '{"action":"APPLYTPL", "object":"HOST", "values": "TOTO"}'

4. Wait for the scheduled centAcl.php script to be run

Result:

The table centreon.host_service_relation contains the expected services for the new host. But the table centreon_storage.centreon_acl contains only the ACL entries for the host, not for the associated services

Expected result:

All services ACL should be created. This is what happens if you do the same from the web interface, or if both ADD and APPLYTPL are passed before the centACL.php execution.

Notes:

If you open the newly created host's page in the web interface and just click "Save" without changing anything, the services ACL will be created after next run of centAcl.php.

[littlejawa]

I've looked at the centAcl.php script and I think I understand why the problem occurs.

The script is divided into two parts : the first one determines whether the ACLs need to be updated, and if it is positive the second will rewrite them. The second part is not at fault: when it is run, it will find the services and create the ACLs for them. The problem is that when you create new services (with the APPLYTPL command for instance), the first part of centAcl.php doesn't detect it.

It seems to focus on Hosts, HostGroups and ServiceGroups modifications - but doesnt look at individual services. Then if a host is added and services for it created soon enough, the host creation triggers the ACL update, and the services ACLs are created. Now if the host is created and the centAcl.php script runs before the services are created, then only the host's ACLs are created - the services creation won't trigger a new run.

One way to show it is to create a second new host - this will trigger the ACL update, and the services ACLs for the first host will be created.

I've made a change to the script to check for services without ACLs, and it seems to solve the problem. I'm not sure this is the right way to fix it though.

Can someone review and comment my change ? I'd be happy to do it differently if needed.

[lpinsivy]

Hi @littlejawa

Thank you for your feedback. The best way should be to add a flag for centACL.php when the command APPLYTPL is called.

[littlejawa]

Hi @lpinsivy ,

Sorry for the long time without answer. Since I worked on the 2.8 version, I wanted to look at the latest code before answering.

I am not sure I understand your suggestion: the current implementation of centACL.php is looking at various tables in the database (hosts, hostgroups and servicegroups) to check if changes have been made to them. If that's the case, it will update the ACLs. The code I am adding is performing the same tasks: it looks at the Services table, and verifies that no new service have been added with no ACL set for it. If there is one, it will trigger the same mechanism to update the ACLs.

If I modify the APPLYTPL code in the API to add a flag, I see some complications:

• first, it would add a form of communication between the API and the centACL script which doesn't exist today. I'm not sure this dependency is needed/wanted?

• second, it would make the "services" check in the centACL script run in a different way, relying on a different trigger than the rest of the code. In general, it is a good thing to keep some consistency in the code for maintenance purposes.

  Since there is no such flag used between the API and centAcl.php, even in 18.10, it looks like a big change compared to the (small) bug I'm trying to fix. Unless the goal is to put a flag in place that will ultimately be used also for hosts, hostgroups and servicegroups changes, as part of a more global refactoring effort?

  Could you give me more details on what you meant to do?

[realitix]

Hello, This problem stills occur on 19.10 version and should be fixed. Could you accept the patch of litteljawa ? @lpinsivy

Thanks

[realitix]

Hello, I sent a pull request for the master branch. I updated the @littlejawa patch with the new conventions.

Thanks