[Freeipa-users] In webgui, ID Views slow, to crashingly slow

[Lachlan Musicman]

I concede - FreeIPA is big and hard and I am new. Evidence would suggest
that you know exactly what's going on under the hood. :)

Thanks everyone.

------
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 20 September 2016 at 18:10, Alexander Bokovoy <abokovoy at redhat.com>
wrote:

> On Tue, 20 Sep 2016, Sumit Bose wrote:
>
>> On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote:
>>
>>> On Tue, 20 Sep 2016, Martin Babinsky wrote:
>>> > On 09/20/2016 12:17 AM, Simpson Lachlan wrote:
>>> > > > -----Original Message-----
>>> > > >
>>> > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote:
>>> > > > > Hi
>>> > > > >
>>> > > > > Sometimes when I visit the ID Views page in the webgui, it is
>>> > > > > crushingly slow, and often it times out.
>>> > > > >
>>> > > > > Centos 7, ipa --version
>>> > > > > VERSION: 4.2.0, API_VERSION: 2.156
>>> > > > >
>>> > > > > Is there a reason, can I do something to fix this?
>>> > > > >
>>> > > >
>>> > > > What kind of ID Views do you use? Do you use them to  override AD
>>> users?
>>> > > > Is there any useful info in '/var/log/httpd/error_log'?
>>> > >
>>> > > There is the single ID View Name, Default Trust View, and in that we
>>> have a number of users over riding the AD usernames and home dirs.
>>> > >
>>> > > The httpd error log is relatively large, tbh, but there's nothing in
>>> there that looks like an obvious reason. In fact, for an error log, there
>>> is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the
>>> error log is jsonserver_session...
>>> > >
>>> > > Next time I see it (I only see it intermittently), I'll grab the
>>> logs and have a look.
>>> > >
>>> > > Cheers
>>> > > L.
>>> > >
>>> > >
>>> > >
>>> > > This email (including any attachments or links) may contain
>>> > > confidential and/or legally privileged information and is
>>> > > intended only to be read or used by the addressee.  If you
>>> > > are not the intended addressee, any use, distribution,
>>> > > disclosure or copying of this email is strictly
>>> > > prohibited.
>>> > > Confidentiality and legal privilege attached to this email
>>> > > (including any attachments) are not waived or lost by
>>> > > reason of its mistaken delivery to you.
>>> > > If you have received this email in error, please delete it
>>> > > and notify us immediately by telephone or email.  Peter
>>> > > MacCallum Cancer Centre provides no guarantee that this
>>> > > transmission is free of virus or that it has not been
>>> > > intercepted or altered and will not be liable for any delay
>>> > > in its receipt.
>>> > >
>>> >
>>> > One thing that crossed my mind is to check the connectivity to the AD
>>> > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to
>>> > contact AD DCs to do the username -> SID translation. If there is some
>>> > problem contacting them, then there may be hangs/timeouts when
>>> resolving
>>> > override anchors.
>>> Internally IPA framework attempts to resolve ID override anchors. We can
>>> actually optimize this code as ipaOriginalUID attribute contains
>>> normalized name already, written their when the override is created and
>>> never changed afterwards. This should speed up the resolution of large
>>> overrides.
>>>
>>> Martin, can you file a ticket for that? The code in question is
>>> baseidoverride.convert_anchor_to_human_readable_form() which could
>>> benefit from passing in entry_attrs and checking ipaoriginaluid there.
>>> If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
>>> done now.
>>>
>>
>> As an alternative I wonder if the WebUI can be made asynchronous in the
>> sense that it displays the raw data (the SID in this case) first and run
>> the lookups in the background and replace the SID when the name is
>> available. I've seen some Windows tools behaving this when looking up
>> large numbers of SIDs.
>>
> We have that for external group members already.
>
> However, in the ID overrides there is no SID as it is. The RDN of the ID
> override is 'ipaAnchorUUID' attribute which is an encoding of a target
> reference. We don't need to resolve it because we already have it
> resolved in 'ipaOriginalUid' attribute -- this was done to help Schema
> Compatibility and SASL mapping plugins which cannot resolve
> ipaAnchorUUID value. We just need to make its use consistent across the
> IPA framework.
>
>
> --
> / Alexander Bokovoy
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160920/37c8afc6/attachment.htm>