Alexander,
Thanks for your reply!
If you are not using cn=compat tree anywhere, it is probably better
to
disable it.
We do appear to be using it, so this doesn't seem to be an option;
there were entries listed as
cn=groupname,cn=groups,cn=compat,dc=ipa,dc=domain.
What helps is to get the same groups looked up locally on IPA master
to
cache them in SSSD cache. Then on restart of LDAP server and Schema
Compatibility tree requests, SSSD would serve most of those from cache.
>Has anyone else run into this issue? Can the messages be ignored? Are
>there any steps to take to resolve the issue?
These can be ignored, mostly. It is something we cannot currently
address well due to chicken/egg problem at startup of LDAP server.
So, these entries did get logged well after dirsrv had started.
If they can mostly be ignored, when should they not be ignored?
Thanks!
John DeSantis
Il giorno gio 8 apr 2021 alle ore 16:14 Alexander Bokovoy
<abokovoy(a)redhat.com> ha scritto:
>
> On to, 08 huhti 2021, John Desantis via FreeIPA-users wrote:
> >Hello!
> >
> >Today we successfully upgraded our FreeIPA servers from 4.6.4 to 4.6.8
> >via `yum`.
> >
> >Other than the upgrade process taking what seemed to be a long time,
> >it completed without an issue and everything is intact, including the
> >AD Trust (as stated). We use a naming convention posix-group and
> >posix-group_external for mapping purposes.
> >
> >After adding an AD user to an external group, I noticed the following
> >messages logged in the dirsrv error log:
> >
> >[08/Apr/2021:13:54:45.582168432 -0400] - ERR - schema-compat-plugin -
> >group "posix-group(a)ipa.domain" does not exist because SSSD is offline.
> >
> >The SSSD logs do show that there was a crash:
> >
> >(2021-04-08 13:54:35): [be[ipa.domain]] [dp_get_account_info_handler]
> >(0x0200): Got request for
> >[0x2][BE_REQ_GROUP][name=posix-group(a)ipa.domain]
> >(2021-04-08 13:54:38): [be[ipa.domain]] [dp_get_account_info_handler]
> >(0x0200): Got request for [0x1][BE_REQ_USER][name=idm-user(a)ipa.domain]
> >(2021-04-08 13:54:41): [be[ipa.domain]] [generic_ext_search_handler]
> >(0x0040): sdap_get_generic_ext_recv failed [110]: Connection timed out
>
> It is not a crash but rather a timeout due to a logical lockup: Schema
> Compatibility plugin in IPA LDAP is trying to reconstruct membership
> information for external members of IPA groups at LDAP server startup
> after upgrade and it needs to talk to SSSD for that. SSSD, in its turn,
> needs to talk to IPA LDAP to look up external membership details. Schema
> compatibility plugin used to handle this request with non-cancellable
> system API, now it does it with a specific SSSD API that allows to
> cancel requests under 10 seconds so it will recover without that
> information. SSSD, in its turn, cancels LDAP request after own timeout.
>
> >The messages appear to be harmless in the sense that the AD user is
> >associated with their groups correctly and are able to access group
> >protected resources without an issue.
>
If you are not using cn=compat tree anywhere, it is probably better
to
disable it.
>
> >Searching for the same dirsrv error message via Google and the mailing
> >list only produces the following URL's, and I didn't experience any
> >crashes during the upgrade process. Other than it taking about ~25
> >minutes per server (maybe due to SSSD running during the upgrade?),
> >everything restarted as expected:
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=1346735
>
>https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/7YNTBRSRJKU2IXQH5CEVZQPDEKOCKHDV/#7YNTBRSRJKU2IXQH5CEVZQPDEKOCKHDV
> >
> >The nsslapd-pluginEnabled has been enabled this entire time.
> >
> >Looking a little deeper now, I did rename a group post upgrade and
> >there was a similar set of logs:
> >
> >[08/Apr/2021:12:03:18.692100370 -0400] - ERR - schema-compat-plugin -
> >group "pi_posix-group-originalname(a)ipa.domain" does not exist because
> >SSSD is offline.
> >[08/Apr/2021:12:03:36.825433630 -0400] - ERR - schema-compat-plugin -
> >group "pi_posix-group-newname(a)ipa.domain" does not exist because SSSD
> >is offline.
>
What helps is to get the same groups looked up locally on IPA master
to
cache them in SSSD cache. Then on restart of LDAP server and Schema
Compatibility tree requests, SSSD would serve most of those from cache.
>Has anyone else run into this issue? Can the messages be ignored? Are
>there any steps to take to resolve the issue?
These can be ignored, mostly. It is something we cannot currently
address well due to chicken/egg problem at startup of LDAP server.
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>