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 <aboko...@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 >
-- 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