Re: [Freeipa-devel] Reorganization of Web UI navigation items
On Tue, Jun 3, 2014 at 2:16 PM, Dmitri Pal wrote: > Services >>> - Services >>> - SUDO >>> - Automount >>> >> > I do not like "services" on two levels but I can't come up with an > alternative. > Maybe Service Principles or Service Keys as that is what's in there, no? Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] IPAv3.1 and Redhat 6.4
On Fri, May 31, 2013 at 2:13 PM, Dmitri Pal wrote: > On 05/31/2013 04:47 PM, Nicholas MacKenzie wrote: > > Will IPAv3.1 ever come to 6.4 or perhaps 6.5? Are there any rumors > surrounding release dates? > > > ___ > Freeipa-devel mailing > listFreeipa-devel@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel > > 6.4 has SSSD 1.9 and IPA 3.0 > There are no plans to port 3.1+ server versions to RHEL6.x. > There are considerations to backport SSSD and ipa-client to 6.x. Version > is yet TBD but for 6.5 we are focusing on porting selcted fixes for SSSD > 1.9 and IPA 3.0. > With this being the case, will there be an upgrade path to RHEL 7.x and IPA 3.2.x? Since upgrade from RHEL 6.x to 7.x will probably not work, would replication to a higher version work or maybe the backup that Rob was working on? Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Tue, Sep 11, 2012 at 9:17 PM, Stephen Ingram wrote: > On Tue, Sep 11, 2012 at 7:31 PM, Rob Crittenden wrote: >> Stephen Ingram wrote: >>> >>> On Tue, Aug 7, 2012 at 1:53 PM, Simo Sorce wrote: >>>> >>>> On Tue, 2012-08-07 at 13:30 -0700, Stephen Ingram wrote: >>>>> >>>>> On Thu, Aug 2, 2012 at 1:04 PM, Simo Sorce wrote: >>>>>> >>>>>> Quick heads up in this thread, >>>>>> >>>>>> apparently we have isolated the issue to libkrb5 and its selinux >>>>>> integration. >>>>>> I have made the whole delay go away by disabling selinux entirely >>>>>> (which >>>>>> makes libkrb5 stop trying to do some selinux related operations). >>>>>> >>>>>> We will be working on a fix to have libkrb5 not cause this delay (F17 >>>>>> doesn't have it). >>>>>> >>>>>> You can follow progress on this bugzilla: >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=845125 As I'm thinking this might also solve my IPA large memory usage issue, I've been following this bug and see there is now a patch for it. I also see it is in QA along with several other IPA-related (and non-IPA-related) Kerberos fixes. I thought at some point an errata release would happen during the RHEL 6.3 time-frame, but as I'm not too familiar with how this works, so I'm not sure. Is this a possibility, or are these being held back for some reason like additional QA time? Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Tue, Sep 11, 2012 at 7:31 PM, Rob Crittenden wrote: > Stephen Ingram wrote: >> >> On Tue, Aug 7, 2012 at 1:53 PM, Simo Sorce wrote: >>> >>> On Tue, 2012-08-07 at 13:30 -0700, Stephen Ingram wrote: >>>> >>>> On Thu, Aug 2, 2012 at 1:04 PM, Simo Sorce wrote: >>>>> >>>>> Quick heads up in this thread, >>>>> >>>>> apparently we have isolated the issue to libkrb5 and its selinux >>>>> integration. >>>>> I have made the whole delay go away by disabling selinux entirely >>>>> (which >>>>> makes libkrb5 stop trying to do some selinux related operations). >>>>> >>>>> We will be working on a fix to have libkrb5 not cause this delay (F17 >>>>> doesn't have it). >>>>> >>>>> You can follow progress on this bugzilla: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=845125 >>>> >>>> >>>> >>>> I could see this BZ for a couple of days, but now it says that I must >>>> log in to an account first with the appropriate permissions. Has this >>>> been moved or something? >>>> >>>> Steve >>> >>> >>> Sorry Stpehen we have a stupid bot that sometimes decides to flag bugs >>> as internal for reasons I do not understand, I removed the flag, you >>> should be able to see it again now. >> >> >> This must have happened again as I can no longer see the bug. This >> must be a tough one as there seems to still be no update? >> > > Hmm, I can see it without logging into BZ. The short summary is that Nalin > has a patch for it as of yesterday. I can see the bug again now too. Strange. Thanks for the update too. Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Tue, Aug 7, 2012 at 1:53 PM, Simo Sorce wrote: > On Tue, 2012-08-07 at 13:30 -0700, Stephen Ingram wrote: >> On Thu, Aug 2, 2012 at 1:04 PM, Simo Sorce wrote: >> > Quick heads up in this thread, >> > >> > apparently we have isolated the issue to libkrb5 and its selinux >> > integration. >> > I have made the whole delay go away by disabling selinux entirely (which >> > makes libkrb5 stop trying to do some selinux related operations). >> > >> > We will be working on a fix to have libkrb5 not cause this delay (F17 >> > doesn't have it). >> > >> > You can follow progress on this bugzilla: >> > https://bugzilla.redhat.com/show_bug.cgi?id=845125 >> >> >> I could see this BZ for a couple of days, but now it says that I must >> log in to an account first with the appropriate permissions. Has this >> been moved or something? >> >> Steve > > Sorry Stpehen we have a stupid bot that sometimes decides to flag bugs > as internal for reasons I do not understand, I removed the flag, you > should be able to see it again now. This must have happened again as I can no longer see the bug. This must be a tough one as there seems to still be no update? Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Thu, Aug 2, 2012 at 1:04 PM, Simo Sorce wrote: > Quick heads up in this thread, > > apparently we have isolated the issue to libkrb5 and its selinux > integration. > I have made the whole delay go away by disabling selinux entirely (which > makes libkrb5 stop trying to do some selinux related operations). > > We will be working on a fix to have libkrb5 not cause this delay (F17 > doesn't have it). > > You can follow progress on this bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=845125 I could see this BZ for a couple of days, but now it says that I must log in to an account first with the appropriate permissions. Has this been moved or something? Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Thu, Aug 2, 2012 at 10:33 AM, Rich Megginson wrote: > On 08/02/2012 11:29 AM, Stephen Ingram wrote: >> >> On Thu, Aug 2, 2012 at 10:23 AM, Simo Sorce wrote: >>> >>> On Thu, 2012-08-02 at 10:17 -0700, Stephen Ingram wrote: >>>> >>>> On Wed, Aug 1, 2012 at 7:35 AM, Simo Sorce wrote: >>>>> >>>>> On Tue, 2012-07-31 at 08:49 -0700, Stephen Ingram wrote: >>>>>> >>>>>> On Tue, Jul 31, 2012 at 1:39 AM, Petr Spacek >>>>>> wrote: >>>>>>> >>>>>>> On 07/31/2012 12:27 AM, John Dennis wrote: >>>>>>>> >>>>>>>> >>>>>>>> What is taking so long with session bookkeeping? I don't know yet. I >>>>>>>> would >>>>>>>> need more timing instrumentation. I will say when I looked at the >>>>>>>> python-krb5 >>>>>>>> code (which we use to populate the ccache from the session and read >>>>>>>> back >>>>>>>> to >>>>>>>> store in the session) seemed to be remarkably inefficient. We also >>>>>>>> elected >>>>>>>> to >>>>>>>> use file based ccache rather than in-memory ccache (that means there >>>>>>>> is a >>>>>>>> bit >>>>>>>> of file-IO occurring). >>>>>>> >>>>>>> >>>>>>> A note regarding python-krbV: >>>>>>> I used python-krbV extensively in my thesis for KDC stress test. >>>>>>> Python-krbV >>>>>>> can obtain several thousands of TGTs per second (even with ccache in >>>>>>> a >>>>>>> file). AFAIK VFS calls are not done synchronously. But others parts >>>>>>> of >>>>>>> python-krbV were left uncovered, so it can contain some surprises. >>>>>>> >>>>>>> === Wild speculation follows === >>>>>>> 1.5 second is incredibly long time, it sounds like some kind of >>>>>>> timeout. >>>>>>> Krb5 libs have usual timeout = 1 second per request. >>>>>>> >>>>>>> Are all KDCs in /etc/krb5.conf alive and reachable? >>>>>> >>>>>> In this case, as I'm referring to the extreme slowness of the Web UI, >>>>>> the KDC is on the same system (the ipa server) that is making the >>>>>> request, correct? >>>>>> >>>>>>> Is SSSD running on problematic server? >>>>>> >>>>>> Yes. Again, I'm guessing the problematic server is the IPA server >>>>>> itself. >>>>>> >>>>>>> Is proper KDC selected by SSSD KDC auto-locator plugin? >>>>>>> (See /var/lib/sss/pubconf/) >>>>>> >>>>>> Yes, I checked that file and it is the IP address of the IPA server on >>>>>> the same server. Perhaps should this be 127.0.0.1 instead? >>>>>> >>>>>> I also have checked the resolv.conf file, and indeed the IP points to >>>>>> the IPA server itself (same machine) as expected. Both forward and >>>>>> reverse DNS work. I'm not really sure what else could be setup >>>>>> incorrectly to cause any KDC slowness. >>>>>> >>>>>> Due to the extreme UI slowness issue, I have not created any replicas >>>>>> so this system is it. I'm not so sure I would be able to see the 1.5 s >>>>>> delay if it weren't compounded by the overall slowness of the Web UI, >>>>>> however, the KDC seems to perform well for other systems in the realm. >>>>>> I'm certainly not taxing it with a huge load, but tickets seem to be >>>>>> issued without delay. >>>>> >>>>> Stephen, >>>>> another user sent me a wireshark trace for a similar performance issue. >>>>> So far I see a pause when doing the first leg of a SASL authentication. >>>>> This may well explain also your issue. >>>>> >>>>> Can you test connecting to the ldap server using ldapsearch -Y GSSAPI >>>>> (you need a kerberos ticket) and telling me if you experience any >>>>> delay ? >>>>> If you could run a bunch of searches in a loop and take a wireshark >>>>> trace that may help analyzing the timings and seeing if there is a >>>>> correlation. >>>> >>>> I've done this. It looks like this delay has been uncovered already >>>> though? I can still send you the dump privately if you think it would >>>> help. >>> >>> I think we reproduced it, can you confirm you are also running on RHEL ? >>> So far it seem the only platfrom we can reproduce is RHEL 6.3 >> >> >> Yes, I'm running RHEL 6.3. I just ran the command in the BZ and it >> takes 1.542s for me. What are Z-stream packages? > > > They are packages delivered between minor RHEL releases e.g. between RHEL > 6.3 and RHEL 6.4 - the 389-ds-base package released with RHEL 6.3 was > 389-ds-base-1.2.10.2-15.el6 - since RHEL 6.3, we released some bugfix > packages, and the latest is now 389-ds-base-1.2.10.2-20.el6_3 - note the > "_3" at the end - this means it is a bugfix release for RHEL 6.3 - > "Z-stream" is just Red Hat terminology for a package released between minor > RHEL releases - the "Z" stands for the "Z" in the versioning scheme "X.Y.Z" Got it. We are using those packages now. Although this might or might not be the cause of the slow Web UI, the Web UI has been slow since the initial 6.3 release. If this 389 slowness was only introduced in the Z-stream 389ds, then it is likely not, or not the only, cause of the Web UI slowness. Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Thu, Aug 2, 2012 at 10:23 AM, Simo Sorce wrote: > On Thu, 2012-08-02 at 10:17 -0700, Stephen Ingram wrote: >> On Wed, Aug 1, 2012 at 7:35 AM, Simo Sorce wrote: >> > On Tue, 2012-07-31 at 08:49 -0700, Stephen Ingram wrote: >> >> On Tue, Jul 31, 2012 at 1:39 AM, Petr Spacek wrote: >> >> > On 07/31/2012 12:27 AM, John Dennis wrote: >> >> >> >> >> >> >> >> >> What is taking so long with session bookkeeping? I don't know yet. I >> >> >> would >> >> >> need more timing instrumentation. I will say when I looked at the >> >> >> python-krb5 >> >> >> code (which we use to populate the ccache from the session and read >> >> >> back >> >> >> to >> >> >> store in the session) seemed to be remarkably inefficient. We also >> >> >> elected >> >> >> to >> >> >> use file based ccache rather than in-memory ccache (that means there >> >> >> is a >> >> >> bit >> >> >> of file-IO occurring). >> >> > >> >> > >> >> > A note regarding python-krbV: >> >> > I used python-krbV extensively in my thesis for KDC stress test. >> >> > Python-krbV >> >> > can obtain several thousands of TGTs per second (even with ccache in a >> >> > file). AFAIK VFS calls are not done synchronously. But others parts of >> >> > python-krbV were left uncovered, so it can contain some surprises. >> >> > >> >> > === Wild speculation follows === >> >> > 1.5 second is incredibly long time, it sounds like some kind of timeout. >> >> > Krb5 libs have usual timeout = 1 second per request. >> >> > >> >> > Are all KDCs in /etc/krb5.conf alive and reachable? >> >> >> >> In this case, as I'm referring to the extreme slowness of the Web UI, >> >> the KDC is on the same system (the ipa server) that is making the >> >> request, correct? >> >> >> >> > Is SSSD running on problematic server? >> >> >> >> Yes. Again, I'm guessing the problematic server is the IPA server itself. >> >> >> >> > Is proper KDC selected by SSSD KDC auto-locator plugin? >> >> > (See /var/lib/sss/pubconf/) >> >> >> >> Yes, I checked that file and it is the IP address of the IPA server on >> >> the same server. Perhaps should this be 127.0.0.1 instead? >> >> >> >> I also have checked the resolv.conf file, and indeed the IP points to >> >> the IPA server itself (same machine) as expected. Both forward and >> >> reverse DNS work. I'm not really sure what else could be setup >> >> incorrectly to cause any KDC slowness. >> >> >> >> Due to the extreme UI slowness issue, I have not created any replicas >> >> so this system is it. I'm not so sure I would be able to see the 1.5 s >> >> delay if it weren't compounded by the overall slowness of the Web UI, >> >> however, the KDC seems to perform well for other systems in the realm. >> >> I'm certainly not taxing it with a huge load, but tickets seem to be >> >> issued without delay. >> > >> > Stephen, >> > another user sent me a wireshark trace for a similar performance issue. >> > So far I see a pause when doing the first leg of a SASL authentication. >> > This may well explain also your issue. >> > >> > Can you test connecting to the ldap server using ldapsearch -Y GSSAPI >> > (you need a kerberos ticket) and telling me if you experience any >> > delay ? >> > If you could run a bunch of searches in a loop and take a wireshark >> > trace that may help analyzing the timings and seeing if there is a >> > correlation. >> >> I've done this. It looks like this delay has been uncovered already >> though? I can still send you the dump privately if you think it would >> help. > > I think we reproduced it, can you confirm you are also running on RHEL ? > So far it seem the only platfrom we can reproduce is RHEL 6.3 Yes, I'm running RHEL 6.3. I just ran the command in the BZ and it takes 1.542s for me. What are Z-stream packages? Is this new for 389ds? Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Wed, Aug 1, 2012 at 7:35 AM, Simo Sorce wrote: > On Tue, 2012-07-31 at 08:49 -0700, Stephen Ingram wrote: >> On Tue, Jul 31, 2012 at 1:39 AM, Petr Spacek wrote: >> > On 07/31/2012 12:27 AM, John Dennis wrote: >> >> >> >> >> >> What is taking so long with session bookkeeping? I don't know yet. I would >> >> need more timing instrumentation. I will say when I looked at the >> >> python-krb5 >> >> code (which we use to populate the ccache from the session and read back >> >> to >> >> store in the session) seemed to be remarkably inefficient. We also elected >> >> to >> >> use file based ccache rather than in-memory ccache (that means there is a >> >> bit >> >> of file-IO occurring). >> > >> > >> > A note regarding python-krbV: >> > I used python-krbV extensively in my thesis for KDC stress test. >> > Python-krbV >> > can obtain several thousands of TGTs per second (even with ccache in a >> > file). AFAIK VFS calls are not done synchronously. But others parts of >> > python-krbV were left uncovered, so it can contain some surprises. >> > >> > === Wild speculation follows === >> > 1.5 second is incredibly long time, it sounds like some kind of timeout. >> > Krb5 libs have usual timeout = 1 second per request. >> > >> > Are all KDCs in /etc/krb5.conf alive and reachable? >> >> In this case, as I'm referring to the extreme slowness of the Web UI, >> the KDC is on the same system (the ipa server) that is making the >> request, correct? >> >> > Is SSSD running on problematic server? >> >> Yes. Again, I'm guessing the problematic server is the IPA server itself. >> >> > Is proper KDC selected by SSSD KDC auto-locator plugin? >> > (See /var/lib/sss/pubconf/) >> >> Yes, I checked that file and it is the IP address of the IPA server on >> the same server. Perhaps should this be 127.0.0.1 instead? >> >> I also have checked the resolv.conf file, and indeed the IP points to >> the IPA server itself (same machine) as expected. Both forward and >> reverse DNS work. I'm not really sure what else could be setup >> incorrectly to cause any KDC slowness. >> >> Due to the extreme UI slowness issue, I have not created any replicas >> so this system is it. I'm not so sure I would be able to see the 1.5 s >> delay if it weren't compounded by the overall slowness of the Web UI, >> however, the KDC seems to perform well for other systems in the realm. >> I'm certainly not taxing it with a huge load, but tickets seem to be >> issued without delay. > > Stephen, > another user sent me a wireshark trace for a similar performance issue. > So far I see a pause when doing the first leg of a SASL authentication. > This may well explain also your issue. > > Can you test connecting to the ldap server using ldapsearch -Y GSSAPI > (you need a kerberos ticket) and telling me if you experience any > delay ? > If you could run a bunch of searches in a loop and take a wireshark > trace that may help analyzing the timings and seeing if there is a > correlation. I've done this. It looks like this delay has been uncovered already though? I can still send you the dump privately if you think it would help. Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Tue, Jul 31, 2012 at 1:39 AM, Petr Spacek wrote: > On 07/31/2012 12:27 AM, John Dennis wrote: >> >> >> What is taking so long with session bookkeeping? I don't know yet. I would >> need more timing instrumentation. I will say when I looked at the >> python-krb5 >> code (which we use to populate the ccache from the session and read back >> to >> store in the session) seemed to be remarkably inefficient. We also elected >> to >> use file based ccache rather than in-memory ccache (that means there is a >> bit >> of file-IO occurring). > > > A note regarding python-krbV: > I used python-krbV extensively in my thesis for KDC stress test. Python-krbV > can obtain several thousands of TGTs per second (even with ccache in a > file). AFAIK VFS calls are not done synchronously. But others parts of > python-krbV were left uncovered, so it can contain some surprises. > > === Wild speculation follows === > 1.5 second is incredibly long time, it sounds like some kind of timeout. > Krb5 libs have usual timeout = 1 second per request. > > Are all KDCs in /etc/krb5.conf alive and reachable? In this case, as I'm referring to the extreme slowness of the Web UI, the KDC is on the same system (the ipa server) that is making the request, correct? > Is SSSD running on problematic server? Yes. Again, I'm guessing the problematic server is the IPA server itself. > Is proper KDC selected by SSSD KDC auto-locator plugin? > (See /var/lib/sss/pubconf/) Yes, I checked that file and it is the IP address of the IPA server on the same server. Perhaps should this be 127.0.0.1 instead? I also have checked the resolv.conf file, and indeed the IP points to the IPA server itself (same machine) as expected. Both forward and reverse DNS work. I'm not really sure what else could be setup incorrectly to cause any KDC slowness. Due to the extreme UI slowness issue, I have not created any replicas so this system is it. I'm not so sure I would be able to see the 1.5 s delay if it weren't compounded by the overall slowness of the Web UI, however, the KDC seems to perform well for other systems in the realm. I'm certainly not taxing it with a huge load, but tickets seem to be issued without delay. Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Mon, Jul 30, 2012 at 3:27 PM, John Dennis wrote: > Stephen finally got his server patched with my timing instrumentation. He > sent me his log file and I ran my script to parse it. The results are quite > interesting. > > Basically I timed two things > > cmd_duration is the elapsed time to execute the IPA command. > > json_duration is the elapsed time to execute the JSON RPC containing the IPA > command. The difference (delta) between the two is the time we spend doing > "session bookkeeping". In all but the first RPC we were executing from the > session cache. Results are below. > > What is interesting is every command that executes from the session cache > seems to have about a 1.5 second constant overhead. The other interesting > bits are that most commands in the server execute quickly (from under a > tenth of second to .3 second) and on average the server takes 1.5 seconds to > respond to RPC (of which most of it appears to be in session code). > > What is taking so long with session bookkeeping? I don't know yet. I would > need more timing instrumentation. I will say when I looked at the > python-krb5 code (which we use to populate the ccache from the session and > read back to store in the session) seemed to be remarkably inefficient. We > also elected to use file based ccache rather than in-memory ccache (that > means there is a bit of file-IO occurring). Just out of curiosity, were any, or, all of these, changes from the way things were handled in 2.1? > Has anyone used a Python profiler? Would that be better than adding > instrumentation? > > BTW, the actual commands were stripped to protect data anonymity. > > cmd_duration: 0.107673 json_duration: 3.176758 delta: 3.069085 > cmd_duration: 0.020068 json_duration: 1.543135 delta: 1.523067 > cmd_duration: 0.387210 json_duration: 1.802954 delta: 1.415744 > cmd_duration: 0.024086 json_duration: 1.405276 delta: 1.381190 > cmd_duration: 0.342808 json_duration: 1.950365 delta: 1.607557 > cmd_duration: 0.019286 json_duration: 1.398786 delta: 1.379500 > cmd_duration: 0.200895 json_duration: 1.754358 delta: 1.553463 > cmd_duration: 0.020293 json_duration: 1.410701 delta: 1.390408 > cmd_duration: 0.383433 json_duration: 1.819478 delta: 1.436045 > cmd_duration: 0.020350 json_duration: 1.406038 delta: 1.385688 > cmd_duration: 0.346864 json_duration: 1.771281 delta: 1.424417 > cmd_duration: 0.015998 json_duration: 1.707743 delta: 1.691745 > cmd_duration: 0.314527 json_duration: 1.730894 delta: 1.416367 > cmd_duration: 0.025323 json_duration: 1.582828 delta: 1.557505 Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Mon, Jul 30, 2012 at 9:15 AM, John Dennis wrote:
> On 07/30/2012 11:30 AM, Stephen Ingram wrote:
>>
>> On Wed, Jul 25, 2012 at 11:18 PM, Stephen Ingram
>> wrote:
>>>
>>> On Wed, Jul 25, 2012 at 4:31 AM, John Dennis wrote:
>>>>
>>>> On 07/25/2012 02:59 AM, Stephen Ingram wrote:
>>>>>
>>>>>
>>>>> Seeing python2.7, I'm guessing these patches were against Fedora.
>>>>> Since I couldn't get them to apply against RH 6.3 I applied them by
>>>>> hand. I couldn't get the WebUI to load after applying the patches. I'm
>>>>> not sure of the code that caused the problem, but I did see mention of
>>>>> global name datetime not being defined. You wouldn't happen to have
>>>>> patches for RH 6.3?
>>>>
>>>>
>>>>
>>>> Sorry, I thought you had a F17 install. It should be easy to fix the
>>>> datetime issue, just add this add the top of the file:
>>>>
>>>> import time, datetime
>>>>
>>>> If that simple fix doesn't work then let me know the version you've got
>>>> and
>>>> I'll make up a new patch against that version.
>>>
>>>
>>> Yes, please send a patch for 2.20 with RH 6.3. The import time,
>>> datetime did not address all of the errors.
>>
>>
>> Not sure if you missed this one or not, but, yes, I do need a patch
>> for 2.20 on RH 6.3. I added datetime, but there were still other
>> errors that I couldn't resolve.
>
>
> Sorry, I did see it but I was busy with other things. You can try the
> attached patch. However you need to have a clean set of files to patch
> against. The patch command I suggested included the -b option and would have
> created backup files of the original file with a .orig suffix. These are the
> files the patch touches.
>
> ipalib/session.py
> ipaserver/plugins/ldap2.py
> ipaserver/rpcserver.py
>
>
> Find their .orig version and cp it back to the original filename. Then you
> can try applying the patch again.
>
> Caveat: I did not test this against 2.20, I just manually made the same set
> of changes and generated a patch, it's possible in my hurry I made a mistake
> you may need to tweak,
This is pretty much the same thing I applied previously by hand. I
noticed that you placed import datetime on its own line so I followed
suit. Here are the errors I'm receiving:
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.] mod_wsgi
(pid=2634): Exception occurred processing WSGI script
'/usr/share/ipa/wsgi.py'.
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] Traceback (most
recent call last):
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] File
"/usr/share/ipa/wsgi.py", line 49, in application
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] return
api.Backend.wsgi_dispatch(environ, start_response)
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] File
"/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 234,
in __call__
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] return
self.route(environ, start_response)
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] File
"/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 246,
in route
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] return
app(environ, start_response)
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] File
"/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 784,
in __call__
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] session_data =
session_mgr.load_session_data(environ.get('HTTP_COOKIE'))
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] File
"/usr/lib/python2.6/site-packages/ipalib/session.py", line 1004, in
load_session_data
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x]
self.store_session_data(session_data)
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] File
"/usr/lib/python2.6/site-packages/ipalib/session.py", line 1047, in
store_session_data
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x]
fmt_time(session_data['session_start_timestamp']),
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] File
"/usr/lib/python2.6/site-packages/ipalib/session.py", line 634, in
fmt_time
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] return
datetime.fromtimestamp(timestamp).strftime(ISO8601_DATETIME_FMT)
[Mon Jul 30 10:09:09 2012] [error] [client x.x.x.x] AttributeError:
'module' object has no attribute 'fromtimestamp'
There seems to be a problem with the format of the log information
returned? Perhaps the fromtimestamp attribute was added after version
2.20?
Steve
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Wed, Jul 25, 2012 at 11:18 PM, Stephen Ingram wrote: > On Wed, Jul 25, 2012 at 4:31 AM, John Dennis wrote: >> On 07/25/2012 02:59 AM, Stephen Ingram wrote: >>> >>> Seeing python2.7, I'm guessing these patches were against Fedora. >>> Since I couldn't get them to apply against RH 6.3 I applied them by >>> hand. I couldn't get the WebUI to load after applying the patches. I'm >>> not sure of the code that caused the problem, but I did see mention of >>> global name datetime not being defined. You wouldn't happen to have >>> patches for RH 6.3? >> >> >> Sorry, I thought you had a F17 install. It should be easy to fix the >> datetime issue, just add this add the top of the file: >> >> import time, datetime >> >> If that simple fix doesn't work then let me know the version you've got and >> I'll make up a new patch against that version. > > Yes, please send a patch for 2.20 with RH 6.3. The import time, > datetime did not address all of the errors. Not sure if you missed this one or not, but, yes, I do need a patch for 2.20 on RH 6.3. I added datetime, but there were still other errors that I couldn't resolve. Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Wed, Jul 25, 2012 at 4:31 AM, John Dennis wrote: > On 07/25/2012 02:59 AM, Stephen Ingram wrote: >> >> Seeing python2.7, I'm guessing these patches were against Fedora. >> Since I couldn't get them to apply against RH 6.3 I applied them by >> hand. I couldn't get the WebUI to load after applying the patches. I'm >> not sure of the code that caused the problem, but I did see mention of >> global name datetime not being defined. You wouldn't happen to have >> patches for RH 6.3? > > > Sorry, I thought you had a F17 install. It should be easy to fix the > datetime issue, just add this add the top of the file: > > import time, datetime > > If that simple fix doesn't work then let me know the version you've got and > I'll make up a new patch against that version. Yes, please send a patch for 2.20 with RH 6.3. The import time, datetime did not address all of the errors. Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response
On Tue, Jul 24, 2012 at 11:09 AM, John Dennis wrote:
> On 07/24/2012 12:03 PM, Stephen Ingram wrote:
>>
>> On Mon, Jul 23, 2012 at 11:25 AM, John Dennis wrote:
>>>
>>> On 07/23/2012 12:37 PM, John Dennis wrote:
>>>>
>>>>
>>>> Note the timestamps only have 1 second resolution, something
>>>> which would be easy to fix, so bear that in mind when looking at the
>>>> output of the script.
>>>
>>>
>>>
>>> This is partially as a note to myself, but also to others who want to
>>> test.
>>> The following patch should produce timestamps in the debug output with
>>> microsecond resolution.
>>
>>
>> No one seems to be jumping in on this. Should I run the test again
>> with this patch? I'm really interested in getting this resolved as I
>> can't help but think others are experiencing the same problem. I do
>> have a user in the system that is scheduled for deletion. Would it
>> help for you to grab a ticket with those credentials so you could
>> actually see the slowness in action?
>
>
> It would be good to re-run your test with better timing information.
> Attached is a patch that adds more timing information to the debug log
> output. Please apply the patch and re-run your test the same way you did
> before and email me the contents of /var/log/httpd/error_log. In the
> error_log you should see lines with "elapsed_time=", e.g.
>
> INFO: ad...@xxx.xxx.xxx.xxx.xx: batch(({'params': ((), {}), 'method':
> 'ping'},)): SUCCESS elapsed_time=0.001663
>
> To apply the patch you'll need to be root to modify the files, this should
> work:
>
> % su
> % cd /usr/lib/python2.7/site-packages
> % patch -p1 -b < path_to_saved_patch_file
>
> If you don't have patch installed:
>
> % sudo yum install patch
>
> Then restart httpd and re-run the test.
Seeing python2.7, I'm guessing these patches were against Fedora.
Since I couldn't get them to apply against RH 6.3 I applied them by
hand. I couldn't get the WebUI to load after applying the patches. I'm
not sure of the code that caused the problem, but I did see mention of
global name datetime not being defined. You wouldn't happen to have
patches for RH 6.3?
Steve
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] slow response (was: 2.20 dirsrv memory usage)
On Mon, Jul 23, 2012 at 9:37 AM, John Dennis wrote: > Stephen provided Alexander and myself with debug output. I quickly wrote a > little script to parse the output looking for the session timestamps, what > commands were executed for each RPC, and computed the duration of the RPC. > Note the timestamps only have 1 second resolution, something which would be > easy to fix, so bear that in mind when looking at the output of the script. > > The script first lists every command executed in the RPC (including internal > commands), which is then followed by the duration for the RPC. > > From the error_log it appears as if the session cache is being used for all > RPC commands. I see the times all appear to be smaller than what is experienced in the Web UI itself. So what is happening the rest of the 3-4 seconds? Is that taken up by the ticket request? Steve ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RANT] --setattr validation is a minefield.
On Tue, Apr 10, 2012 at 10:25 AM, Petr Viktorin wrote:
> On 04/10/2012 07:07 PM, Martin Kosek wrote:
>>
>> On Tue, 2012-04-10 at 17:03 +0200, Jan Cholasta wrote:
>>>
>>> On 10.4.2012 16:00, Petr Viktorin wrote:
I'm aware that we have backwards compatibility requirements so we have
to stick with unfortunate decisions, but I wanted you to know what I
think. Please tell me I'm wrong!
It is not clear what --{set,add,del}attr and friends should do. On the
one hand they should be powerful -- presumably as powerful as
ldapmodify. On the other hand they should be checked to ensure they
can't be used to break the system. These requirements are contradictory.
And in either case we're doing it wrong:
- If they should be all-powerful, we shouldn't validate them.
- If they shouldn't break the system we can just disable them for
IPA-managed attributes. My understanding is that they were originally
only added for attributes IPA doesn't know about. People can still use
ldapmodify to bypass validation if they want.
- If somewhere in between, we need to clearly define what they should
do, instead of drawing the line ad-hoc based on individual details we
forgot about, as tickets come from QE.
I would hope people won't use --setattr for IPA-managed attributes.
Which would however mean we won't get much community testing for all
this extra code.
Then, there's an unfortunate detail in IPA implementation: attribute
Params need to be cloned to method objects (Create, Update, etc.) to
work properly (e.g. get the `attribute` flag set). If they are marked
no_update, they don't get cloned, so they don't work properly.
Yet --setattr apparently needs to be able to update and validate
attributes marked no_update (this ties to the confusing requirements on
--setattr I already mentioned). This leads to doing the same work again,
slightly differently.
tl;dr: --setattr work on IPA-managed attributes (with validation) is a
mistake. It adds no functionality, only complexity. We don't want people
to use it. It will cost us a lot of maintenance work to support.
Thank you for listening. A patch for the newest regression is coming up.
>>>
>>> I wholeheartedly agree.
>>
>>
>> This is indeed a mine field and we need to make a look from at the issue
>> from all sides before accepting a decision.
>
>
> Yes.
>
>
>>>
>>> Like you said above, we should either not validate --{set,add,del}attr
>>> or don't allow them on known attributes.
>>
>>
>> IMHO, validating attributes we manage in the same way for both --setattr
>> and standard attrs is not that wrong. It is a good precaution, because
>> if we let an unvalidated value in, it can make even a bigger mess later
>> in our pre_callbacks or post_callbacks where we assume that at this
>> point everything is valid.
>
>
> Then we should validate *exactly* the same way, including not allowing
> no_update attributes to be updated.
>
>
>> If somebody wants to modify attributes in an uncontrolled, unvalidated
>> way, he is free to use ldapmodify or other tool to play with raw LDAP
>> values. Without our guarantee of course.
>
>
> That's clear.
>
>
>> But if he chooses to use our --{set,add,del}attr we should at least help
>> him to not shoot himself to the leg and validate/normalize/encode the
>> value. I don't know how many users use this API, but removing a support
>> for all managed attributes seems as a big compatibility break to me.
>
>
> Well, it was broken (see https://fedorahosted.org/freeipa/ticket/2405, 2407,
> 2408), so I don't think many people used it.
>
> Anyway, what's the use case? Why would the user want to use --setattr for
> validated attributes? Is our regular API lacking something?
As a user of the IPA I thought I would throw in our use scenario. Let
me first say that I come to IPA having used Kerberos/LDAP solution
previously so I *really* appreciate what you've been able to do here.
That said, one of the things we are using IPA for is email
configuration. Although the mail attribute is available, we need to
separate by attribute the primary address from the aliases (for
searching the directory) so we need mailAlternateAddress. Luckily, it
is already in the schema. All we have to do is add the mailRecipient
objectclass. It's really nice to be able to add (and hopefully soon
remove) one objectclass without having to go back to ldap commands. I
certainly wouldn't anticipate changing or removing any IPA attributes,
but it sure is nice to have this feature for extra attributes.
Steve
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
