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

[Alexander Bokovoy]

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