On 7/28/20 10:37 PM, Winstanley, Anthony wrote:
I expect the errors are rather benign... Like:
Jul 27 08:19:37 eldaph22 ns-slapd: [27/Jul/2020:08:19:37.743355076 -0700] - WARN - NSACLPlugin - acl_parse - The ACL target cn=blah,dc=ubc,dc=ca does not exist
"Fix" was to either create cn=blah,dc=ubc,dc=ca or delete the ACI.
The message could rather be logged as INFO, it is not a failure just a
heads up that at the moment of the ACI parsing, the targetdn does not
exist and that the ACI is useless. The aci remains and if later the
target entry is created, the aci will be enforced.
thierry
Thank you for the instructions on how to turn on ACI logging. I've stashed them for when we might need them. 😊
Cheers,
Anthony
-----Original Message-----
From: Mark Reynolds <mreynolds@xxxxxxxxxx>
Sent: July 28, 2020 10:48 AM
To: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx>; Winstanley, Anthony <winstan@xxxxxxxxx>
Subject: Re: [389-users] Re: Limitations with large numbers of ACIs?
On 7/28/20 12:30 PM, Winstanley, Anthony wrote:
We're running with 458 ACIs right now (verified the same number on all nodes), running on RHEL 7 with:
389-admin-1.1.46-1.el7.x86_64
389-admin-console-1.1.12-1.el7.noarch
389-admin-console-doc-1.1.12-1.el7.noarch
389-adminutil-1.1.22-2.el7.x86_64
389-adminutil-devel-1.1.22-2.el7.x86_64
389-console-1.1.19-6.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-ds-base-1.3.10.1-9.el7_8.x86_64
389-ds-base-devel-1.3.10.1-9.el7_8.x86_64
389-ds-base-libs-1.3.10.1-9.el7_8.x86_64
389-ds-base-snmp-1.3.10.1-9.el7_8.x86_64
389-ds-console-1.2.16-1.el7.noarch
389-ds-console-doc-1.2.16-1.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64
nsslapd-aclpb-max-selected-acl is set to 2000. (And I'm sure I set it long ago where my memory is fuzzy; thanks for the reminder. I'll put a note somewhere I'll find it for next time...)
So really, we should not be experiencing any ACI-related issue given that 2000 > 458.
I'll note that daemon restarts of the affected nodes cleared up any issues.
I'm feeling better about this now... One final question:
What about ACL failures, where a single ACI fails (say what it targets has been removed). Is there any chance that the failure of the ACL plugin to load one ACI would affect the loading of other valid ACIs?
(I took the opportunity to fix that sort of issue reported in the logs by the ACL plugin and have no idea if that affected anything but the actual failed ACIs themselves. Again, a restart fixed things, but the restart was after my cleanup...)
First, there is an ACI cache that could be corrupted, which explains why
a restart fixes the issue. Second, you are saying you "cleaned" some
things up. What exactly did you do? And what were the exact errors
messages you saw that led you to the "clean up"?
If the ACI's start failing again then there is a good chance you found a
bug in the ACL cache. What would be interesting to see would be the
error log with ACI logging enabled [1], where you have the output when
it works, and then you have the output once it starts failing. Then we
would have something to compare. With so many aci's this is going to be
tedious, but it might be the only option besides identifying a
reproducible test case.
[1]
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/core_server_configuration_reference#cnconfig-nsslapd_errorlog_level_Error_Log_Level
Use ldapmodify and set the level to "128" - this will impact server
performance so only enable it for brief tests, then set it back to "0".
Mark
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
