From ayoung at redhat.com Fri Apr 1 02:20:14 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 31 Mar 2011 22:20:14 -0400 Subject: [Freeipa-devel] [PATCH] Initial Selenium test cases. In-Reply-To: <4D94C345.3090304@redhat.com> References: <4D94B4B1.50808@redhat.com> <4D94C345.3090304@redhat.com> Message-ID: <4D95365E.9010005@redhat.com> On 03/31/2011 02:09 PM, Endi Sukma Dewata wrote: > On 3/31/2011 12:06 PM, Endi Sukma Dewata wrote: >> http://www.freeipa.org/page/Selenium > > Patch included. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. Pushed to master. Note that I did not review each test in depth, but just spot checked. If we find that we have regular breakages on certain tests, we will investigate those tests more. Please update the wiki page. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Apr 1 10:06:39 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Apr 2011 12:06:39 +0200 Subject: [Freeipa-devel] [PATCH] 046 Improve DNS PTR record validation Message-ID: <1301652399.1997.0.camel@dhcp-25-52.brq.redhat.com> Current PTR validation is unclear and may misled the user. This patch improves the validation process so that the eventual exception is clearer. New check that the PTR record is fully qualified has been added to ensure that the reverse zone resolution behaves as expected. Additionally, several strings in the DNS plugin were prepared for localization. https://fedorahosted.org/freeipa/ticket/1129 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-046-improve-dns-ptr-record-validation.patch Type: text/x-patch Size: 4012 bytes Desc: not available URL: From jhrozek at redhat.com Fri Apr 1 11:20:11 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 01 Apr 2011 13:20:11 +0200 Subject: [Freeipa-devel] [PATCH] 045 Add DNS record modification command In-Reply-To: <1301563645.25947.15.camel@dhcp-25-52.brq.redhat.com> References: <1301498000.28351.11.camel@dhcp-25-52.brq.redhat.com> <4D93981C.6010403@redhat.com> <1301563645.25947.15.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4D95B4EB.5070705@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/31/2011 11:27 AM, Martin Kosek wrote: > On Wed, 2011-03-30 at 16:52 -0400, Adam Young wrote: >> On 03/30/2011 11:13 AM, Martin Kosek wrote: >>> Since this is a new-feature type patch it should be pushed only to master. >>> ------- >>> The DNS record plugin does not support modification of a record. One >>> can only add A type addresses to a DNS record or remove the current >>> ones. To actually change a DNS record value it has to be removed and >>> then added with a desired value. >>> >>> This patch adds a new DNS plugin command "dnsrecord-mod" which enables >>> user to: >>> - modify a DNS record value (note than DNS record can hold multiple values >>> and those will be overwritten) >>> - remove a DNS record when an empty value is passed >>> >>> New tests for this new command have been added to the CLI test suite. >>> >>> https://fedorahosted.org/freeipa/ticket/1137 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> >> NACK, >> >> The problem is that if there are 10 A records, and I only want to >> modify one, I have no way to specify which one. >> >> The API should be something like: >> >> ipa dnsrecord-mod ayoung.boston.devel.redhat.com testa 10.10.2.3 >> --a-rec=,10.11.12.13 >> >> >> Alternatively, we can decide that we are not going to do mod, and have >> the WebUI do a delete and an add: > > Hm, that may be a valid use-case. We should discuss how we want the DNS > record modification to behave. > > The proposed API is not what we want, since we can modify multiple > attributes at once, e.g.: > > ipa dnsrecord-mod DNSZONE DNSRECORD --a-rec=10.0.0.1 --aaaa-rec=::1 > > I can introduce new option --old--rec for each DNS record type > available, e.g. --old-a-rec, --old-aaaa-rec, --old-srv-rec etc. You > would be able to do: > > ipa dnsrecord-mod DNSZONE DNSRECORD --old-a-rec=10.10.2.3 > --a-rec=10.11.12.13 > > This would of course increase the size of this patch. I tried to find > how we treat other multi-value LDAP attributes. In most cases the > behavior is the same like in my first patch (user mail, mobile...) or > the modification is not supported at all (list of privilege > permissions). > I think that this is kinda hard to do in CLI..in GUI the user can easily pick a record to mod, but for CLI case I would actually lean towards the approach Martin took in his original patch..that is, a -mod replaces the entries altogether. For GUI I guess we can provide an internal XML-RPC only command that allows replacing a record. The --old- approach doesn't sound quite right to me, to be honest, I think that would make the whole -mod command difficult to use.. If the user wants to replace one of the records, he can run -del followed by -add. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2VtOsACgkQHsardTLnvCVZ7wCgmwE18qZOTDj4ZOOATv6cVkcs +A4An0FLlik0ykW4v+BaKsEo1uVbYSTe =P0Am -----END PGP SIGNATURE----- From mkosek at redhat.com Fri Apr 1 15:12:38 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Apr 2011 17:12:38 +0200 Subject: [Freeipa-devel] [PATCH] 047 Need force option in DNS zone adder dialog Message-ID: <1301670758.1997.1.camel@dhcp-25-52.brq.redhat.com> When adding a new DNS zone in the WebUI, IPA server will verify whether the nameserver is in DNS. Sometimes it is necessary to skip the verification. This patch adds a --force option already available in CLI which can skip this the verification. https://fedorahosted.org/freeipa/ticket/1105 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-047-need-force-option-in-dns-zone-adder-dialog.patch Type: text/x-patch Size: 4160 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 1 15:47:57 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 01 Apr 2011 11:47:57 -0400 Subject: [Freeipa-devel] [PATCH] 762 Let the framework be able to override the hostname Message-ID: <4D95F3AD.2000707@redhat.com> The hostname is passed in during the server installation. We should use this hostname for the resulting server as well. It was being discarded and we always used the system hostname value. ticket 1052 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-762-host.patch Type: application/mbox Size: 4274 bytes Desc: not available URL: From ayoung at redhat.com Fri Apr 1 15:58:05 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 01 Apr 2011 11:58:05 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0220-update-ipa-init Message-ID: <4D95F60D.3000108@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0220-update-ipa-init.patch Type: text/x-patch Size: 1407 bytes Desc: not available URL: From JR.Aquino at citrix.com Fri Apr 1 16:46:13 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 1 Apr 2011 16:46:13 +0000 Subject: [Freeipa-devel] [PATCH] 22 Add memberHost and memberUser to default indexes In-Reply-To: References: Message-ID: On Mar 30, 2011, at 1:16 PM, JR Aquino wrote: > The plugin architecture makes a great deal of calls to search for memberUser and memberHost. These attributes are missing from the index and are greatly slowing down the CLI and WebUI. > > They should be added as Equality Indexes, as the searches that are performed are meant for enumeration after the exact value is known. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Missed some trailing whitespace. Corrected patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0022-Add-memberHost-and-memberUser-to-default-indexes.patch Type: application/octet-stream Size: 1461 bytes Desc: freeipa-jraquino-0022-Add-memberHost-and-memberUser-to-default-indexes.patch URL: From rcritten at redhat.com Fri Apr 1 17:26:38 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 01 Apr 2011 13:26:38 -0400 Subject: [Freeipa-devel] [PATCH] 22 Add memberHost and memberUser to default indexes In-Reply-To: References: Message-ID: <4D960ACE.6070602@redhat.com> JR Aquino wrote: > On Mar 30, 2011, at 1:16 PM, JR Aquino wrote: > >> The plugin architecture makes a great deal of calls to search for memberUser and memberHost. These attributes are missing from the index and are greatly slowing down the CLI and WebUI. >> >> They should be added as Equality Indexes, as the searches that are performed are meant for enumeration after the exact value is known. >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Missed some trailing whitespace. > > Corrected patch attached. After loading this the 389-ds error logs spit out: [01/Apr/2011:13:26:01 -0400] - The attribute [memberHost] does not have a valid ORDERING matching rule - error 2:s [01/Apr/2011:13:26:01 -0400] - The attribute [memberUser] does not have a valid ORDERING matching rule - error 2:s rob From rcritten at redhat.com Fri Apr 1 17:51:05 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 01 Apr 2011 13:51:05 -0400 Subject: [Freeipa-devel] [PATCH] 042 Password policy commands do not include cospriority In-Reply-To: <1301326584.3592.10.camel@dhcp-25-52.brq.redhat.com> References: <1301326584.3592.10.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4D961089.70701@redhat.com> Martin Kosek wrote: > Target branches: master, ipa-2-0 > --- > > Most of the pwpolicy_* commands do include cospriority in the result > and potentially in the attribute rights (--all --rights). Especially > when --raw output is requested. This patch fixes it for all > pwpolicy commands. > > https://fedorahosted.org/freeipa/ticket/1103 > nack. I see a couple of problems. You should test for rights before doing the cosentry_show(). If rights is False then we won't add the data whatever it is so it is more efficient to exit earlier. Same with pwpolicy_name == global_policy_name. I think you should drop the try/except and make it: if not rights or pwpolicy_name == global_policy_name: return ... It should never be the case that the cosentry is not found so I'd let it fail if that does occur. I think that keys[-1] can be None so be aware. You hardcode rights == False in pwpolicy_find(), a good thing. I think you should add make it explict rights=False and add a comment explaining that you can't get accessrights with a find. rob From rmeggins at redhat.com Fri Apr 1 18:06:27 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 01 Apr 2011 12:06:27 -0600 Subject: [Freeipa-devel] [PATCH] 22 Add memberHost and memberUser to default indexes In-Reply-To: <4D960ACE.6070602@redhat.com> References: <4D960ACE.6070602@redhat.com> Message-ID: <4D961423.7010009@redhat.com> On 04/01/2011 11:26 AM, Rob Crittenden wrote: > JR Aquino wrote: >> On Mar 30, 2011, at 1:16 PM, JR Aquino wrote: >> >>> The plugin architecture makes a great deal of calls to search for >>> memberUser and memberHost. These attributes are missing from the >>> index and are greatly slowing down the CLI and WebUI. >>> >>> They should be added as Equality Indexes, as the searches that are >>> performed are meant for enumeration after the exact value is known. >>> >>> _______________________________________________ >>> >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Missed some trailing whitespace. >> >> Corrected patch attached. > > After loading this the 389-ds error logs spit out: > > [01/Apr/2011:13:26:01 -0400] - The attribute [memberHost] does not > have a valid ORDERING matching rule - error 2:s > [01/Apr/2011:13:26:01 -0400] - The attribute [memberUser] does not > have a valid ORDERING matching rule - error 2:s Looking at the schema in 60basev2.ldif - it looks as though there are many attributes that do not have an ORDERING matching rule specified correctly: attributeTypes: (2.16.840.1.113730.3.8.3.5 NAME 'memberUser' DESC 'Reference to a principal that performs an action (usually user).' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) attributeTypes: (2.16.840.1.113730.3.8.3.7 NAME 'memberHost' DESC 'Reference to a device where the operation takes place (usually host).' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) 1.3.6.1.4.1.1466.115.121.1.12 is DN syntax - there is no ORDERING matching rule for DN syntax - is there some reason you want to be able to do range searches on DN values? attributeTypes: (2.16.840.1.113730.3.8.3.8 NAME 'hostCategory' DESC 'Additional classification for hosts' EQUALITY caseIgnoreMatch ORDERING caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' ) This should be ORDERING caseIgnoreOrderingMatch - looks like there may be more of these too. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From dpal at redhat.com Fri Apr 1 19:54:39 2011 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 01 Apr 2011 15:54:39 -0400 Subject: [Freeipa-devel] [PATCH] 22 Add memberHost and memberUser to default indexes In-Reply-To: <4D961423.7010009@redhat.com> References: <4D960ACE.6070602@redhat.com> <4D961423.7010009@redhat.com> Message-ID: <4D962D7F.6050204@redhat.com> On 04/01/2011 02:06 PM, Rich Megginson wrote: > On 04/01/2011 11:26 AM, Rob Crittenden wrote: >> JR Aquino wrote: >>> On Mar 30, 2011, at 1:16 PM, JR Aquino wrote: >>> >>>> The plugin architecture makes a great deal of calls to search for >>>> memberUser and memberHost. These attributes are missing from the >>>> index and are greatly slowing down the CLI and WebUI. >>>> >>>> They should be added as Equality Indexes, as the searches that are >>>> performed are meant for enumeration after the exact value is known. >>>> >>>> _______________________________________________ >>>> >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Missed some trailing whitespace. >>> >>> Corrected patch attached. >> >> After loading this the 389-ds error logs spit out: >> >> [01/Apr/2011:13:26:01 -0400] - The attribute [memberHost] does not >> have a valid ORDERING matching rule - error 2:s >> [01/Apr/2011:13:26:01 -0400] - The attribute [memberUser] does not >> have a valid ORDERING matching rule - error 2:s > Looking at the schema in 60basev2.ldif - it looks as though there are > many attributes that do not have an ORDERING matching rule specified > correctly: > attributeTypes: (2.16.840.1.113730.3.8.3.5 NAME 'memberUser' DESC > 'Reference to a principal that performs an action (usually user).' SUP > distinguishedName EQUALITY distinguishedNameMatch ORDERING > distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) > attributeTypes: (2.16.840.1.113730.3.8.3.7 NAME 'memberHost' DESC > 'Reference to a device where the operation takes place (usually > host).' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING > distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) > > 1.3.6.1.4.1.1466.115.121.1.12 is DN syntax - there is no ORDERING > matching rule for DN syntax - is there some reason you want to be able > to do range searches on DN values? > I thought that ordering is used for the sorting. If you sort things by an attribute. I suspect that there are cases when it makes sense to sort the result set by DN. I think HBAC is one of those. But if ordering is not something that should be used in this case then what shoud? > attributeTypes: (2.16.840.1.113730.3.8.3.8 NAME 'hostCategory' DESC > 'Additional classification for hosts' EQUALITY caseIgnoreMatch > ORDERING caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' ) > > This should be ORDERING caseIgnoreOrderingMatch - looks like there may > be more of these too. This is probably an artifact of me defineing the schema 2 years ago. Can you please file a BZ and a ticket. IMO we should fix the schema inconsistencies ASAP. Please review the rest of the defined attributes and make sure there are no problems like this. >> >> rob >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Apr 1 19:55:38 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 01 Apr 2011 15:55:38 -0400 Subject: [Freeipa-devel] [PATCH] 763 use full name for gecos Message-ID: <4D962DBA.6080709@redhat.com> Use fullname for gecos instead of uid. ticket 1146 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-763-gecos.patch Type: application/mbox Size: 7319 bytes Desc: not available URL: From sgallagh at redhat.com Fri Apr 1 20:05:27 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 01 Apr 2011 16:05:27 -0400 Subject: [Freeipa-devel] [PATCH] 763 use full name for gecos In-Reply-To: <4D962DBA.6080709@redhat.com> References: <4D962DBA.6080709@redhat.com> Message-ID: <4D963007.1080807@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/01/2011 03:55 PM, Rob Crittenden wrote: > Use fullname for gecos instead of uid. > > ticket 1146 While it probably doesn't actually matter for these tests, I should note that the GECOS attribute in LDAP is IA5String, not UTF8. Otherwise, Ack. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2WMAcACgkQeiVVYja6o6NYDgCcCddPwcHxkmoWe0Q9au18V1Cb GkoAoKe5GNDnK6GEbKRj6/Qlio0XUsIT =fV9L -----END PGP SIGNATURE----- From rcritten at redhat.com Fri Apr 1 20:17:57 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 01 Apr 2011 16:17:57 -0400 Subject: [Freeipa-devel] [PATCH] 763 use full name for gecos In-Reply-To: <4D963007.1080807@redhat.com> References: <4D962DBA.6080709@redhat.com> <4D963007.1080807@redhat.com> Message-ID: <4D9632F5.4070503@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/01/2011 03:55 PM, Rob Crittenden wrote: >> Use fullname for gecos instead of uid. >> >> ticket 1146 > > > While it probably doesn't actually matter for these tests, I should note > that the GECOS attribute in LDAP is IA5String, not UTF8. > > Otherwise, Ack. It is defined using Directory String syntax by 389-ds. According to rfc 2307 it should be an IA5String, not sure why it isn't but we inherit this schema. rob From rmeggins at redhat.com Fri Apr 1 22:14:59 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 01 Apr 2011 16:14:59 -0600 Subject: [Freeipa-devel] [PATCH] 763 use full name for gecos In-Reply-To: <4D9632F5.4070503@redhat.com> References: <4D962DBA.6080709@redhat.com> <4D963007.1080807@redhat.com> <4D9632F5.4070503@redhat.com> Message-ID: <4D964E63.1030109@redhat.com> On 04/01/2011 02:17 PM, Rob Crittenden wrote: > Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 04/01/2011 03:55 PM, Rob Crittenden wrote: >>> Use fullname for gecos instead of uid. >>> >>> ticket 1146 >> >> >> While it probably doesn't actually matter for these tests, I should note >> that the GECOS attribute in LDAP is IA5String, not UTF8. >> >> Otherwise, Ack. > > It is defined using Directory String syntax by 389-ds. According to > rfc 2307 it should be an IA5String, not sure why it isn't but we > inherit this schema. It is defined in the original rfc 2307 as Directory String, but 2307bis redefined it to IA5String. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Mon Apr 4 07:51:12 2011 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 04 Apr 2011 09:51:12 +0200 Subject: [Freeipa-devel] [PATCH] 042 Password policy commands do not include cospriority In-Reply-To: <4D961089.70701@redhat.com> References: <1301326584.3592.10.camel@dhcp-25-52.brq.redhat.com> <4D961089.70701@redhat.com> Message-ID: <1301903472.2932.10.camel@dhcp-25-52.brq.redhat.com> On Fri, 2011-04-01 at 13:51 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > Target branches: master, ipa-2-0 > > --- > > > > Most of the pwpolicy_* commands do include cospriority in the result > > and potentially in the attribute rights (--all --rights). Especially > > when --raw output is requested. This patch fixes it for all > > pwpolicy commands. > > > > https://fedorahosted.org/freeipa/ticket/1103 > > > > nack. I see a couple of problems. > > You should test for rights before doing the cosentry_show(). If rights > is False then we won't add the data whatever it is so it is more > efficient to exit earlier. We have to call cosentry_show every time (except for the case when we pull data for the global policy) because we read cospriority attribute. But the function was indeed not efficient (it called cosentry_show twice), I rewrote it. > > Same with pwpolicy_name == global_policy_name. I think you should drop > the try/except and make it: > > if not rights or pwpolicy_name == global_policy_name: > return > > ... > > It should never be the case that the cosentry is not found so I'd let it > fail if that does occur. Fixed. > > I think that keys[-1] can be None so be aware. Fixed. > > You hardcode rights == False in pwpolicy_find(), a good thing. I think > you should add make it explict rights=False and add a comment explaining > that you can't get accessrights with a find. Fixed. Fixed patch attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-042-2-password-policy-commands-do-not-include-cospriority.patch Type: text/x-patch Size: 5272 bytes Desc: not available URL: From ssorce at redhat.com Mon Apr 4 13:38:23 2011 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 4 Apr 2011 09:38:23 -0400 Subject: [Freeipa-devel] [PATCH] 045 Add DNS record modification command In-Reply-To: <4D95B4EB.5070705@redhat.com> References: <1301498000.28351.11.camel@dhcp-25-52.brq.redhat.com> <4D93981C.6010403@redhat.com> <1301563645.25947.15.camel@dhcp-25-52.brq.redhat.com> <4D95B4EB.5070705@redhat.com> Message-ID: <20110404093823.7becd508@willson.li.ssimo.org> On Fri, 01 Apr 2011 13:20:11 +0200 Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/31/2011 11:27 AM, Martin Kosek wrote: > > On Wed, 2011-03-30 at 16:52 -0400, Adam Young wrote: > >> On 03/30/2011 11:13 AM, Martin Kosek wrote: > >>> Since this is a new-feature type patch it should be pushed only > >>> to master. ------- > >>> The DNS record plugin does not support modification of a record. > >>> One can only add A type addresses to a DNS record or remove the > >>> current ones. To actually change a DNS record value it has to be > >>> removed and then added with a desired value. > >>> > >>> This patch adds a new DNS plugin command "dnsrecord-mod" which > >>> enables user to: > >>> - modify a DNS record value (note than DNS record can hold > >>> multiple values and those will be overwritten) > >>> - remove a DNS record when an empty value is passed > >>> > >>> New tests for this new command have been added to the CLI test > >>> suite. > >>> > >>> https://fedorahosted.org/freeipa/ticket/1137 > >>> > >>> > >>> _______________________________________________ > >>> Freeipa-devel mailing list > >>> Freeipa-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >> > >> > >> > >> NACK, > >> > >> The problem is that if there are 10 A records, and I only want to > >> modify one, I have no way to specify which one. > >> > >> The API should be something like: > >> > >> ipa dnsrecord-mod ayoung.boston.devel.redhat.com testa 10.10.2.3 > >> --a-rec=,10.11.12.13 > >> > >> > >> Alternatively, we can decide that we are not going to do mod, and > >> have the WebUI do a delete and an add: > > > > Hm, that may be a valid use-case. We should discuss how we want the > > DNS record modification to behave. > > > > The proposed API is not what we want, since we can modify multiple > > attributes at once, e.g.: > > > > ipa dnsrecord-mod DNSZONE DNSRECORD --a-rec=10.0.0.1 --aaaa-rec=::1 > > > > I can introduce new option --old--rec for each DNS record > > type available, e.g. --old-a-rec, --old-aaaa-rec, --old-srv-rec > > etc. You would be able to do: > > > > ipa dnsrecord-mod DNSZONE DNSRECORD --old-a-rec=10.10.2.3 > > --a-rec=10.11.12.13 > > > > This would of course increase the size of this patch. I tried to > > find how we treat other multi-value LDAP attributes. In most cases > > the behavior is the same like in my first patch (user mail, > > mobile...) or the modification is not supported at all (list of > > privilege permissions). > > > > I think that this is kinda hard to do in CLI..in GUI the user can > easily pick a record to mod, but for CLI case I would actually lean > towards the approach Martin took in his original patch..that is, a > -mod replaces the entries altogether. Why is it hard ? You just need to provide means to delete and add records in the same command. ipa dnsrecord-mod DNSZONE DNSRECORD --del-a-rec=1.2.3.4 \ --add-a-rec=4.3.2.1 to replace all: ipa dnsrecord-mod DNSZONE DNSRECORD --del-all --add-a-rec=4.3.2.1 > For GUI I guess we can provide an internal XML-RPC only command that > allows replacing a record. better not to do special things valid only in one or the other, that's not how we want to do it. > The --old- approach doesn't sound quite right to me, to be > honest, I think that would make the whole -mod command difficult to > use.. > If the user wants to replace one of the records, he can run -del > followed by -add. Indeed it is just as easy to -del and then -add, perhaps instead of a mod command we need to speed up the creation of batch commands for the CLI so that admins can call -del/-add in a single batch command. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Apr 4 13:47:04 2011 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 4 Apr 2011 09:47:04 -0400 Subject: [Freeipa-devel] [PATCH] Add a new user-add flag param to disable the creation of UPG. In-Reply-To: <4D910B62.4060900@redhat.com> References: <4D90F1C7.1090909@redhat.com> <4D91099F.8070400@redhat.com> <4D910B62.4060900@redhat.com> Message-ID: <20110404094704.62bdc75f@willson.li.ssimo.org> On Mon, 28 Mar 2011 15:27:46 -0700 Nathan Kinder wrote: > On 03/28/2011 03:20 PM, Dmitri Pal wrote: > > On 03/28/2011 04:38 PM, Pavel Z?na wrote: > >> This patch handles the issue in a kind of stupid way, but I > >> couldn't think of anything better. > >> > >> It adds a new flag parameter to user-add (--noprivate). With this > >> flag, the command marks the private group about to be created for > >> deletion and is deleted after the user is created. The only > >> exception is when there is a group, that is named the same way as > >> the user, but isn't a private group - then the group is left there. > >> > >> Private groups are created automatically by the managed entry DS > >> plugin and I didn't find a way to disable its creation for a > >> specific user. > > > > The idea that comes to mind is to define some magical attribute > > that the DS plugin would recognize and skip the creation of the > > managed entry as well as strip the entry of this magic > > attribute/value. I remember that other plugins might take advantage > > of the similar approach. > > > > Is something like this possible? > You are probably thinking of the DNA plug-in and it's use of a magic > value used to tell the plug-in to allocate a value from a range. I > would not like to use this approach here, as it requires additional > coding and complexity that I don't think is needed. > > I would prefer that we use the originFilter to deal with this. We > could have an auxiliary objectclass that IPA usually adds when > creating an IPA user. The originFilter can key off of this > objectclass to create managed groups. When a user is added with the > --noprivate option, this objectclass is not included in the user > entry that is added. Rob and I discussed this approach on IRC > earlier today. Ack, this sounds like a better approach, although it doesn't necessarily need to be an objectclass it can also be an attribute with a specific value that is checked in the filter as (!(attrib=value)) Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Apr 4 13:58:44 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 04 Apr 2011 09:58:44 -0400 Subject: [Freeipa-devel] [PATCH] 763 use full name for gecos In-Reply-To: <4D964E63.1030109@redhat.com> References: <4D962DBA.6080709@redhat.com> <4D963007.1080807@redhat.com> <4D9632F5.4070503@redhat.com> <4D964E63.1030109@redhat.com> Message-ID: <4D99CE94.5080903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/01/2011 06:14 PM, Rich Megginson wrote: > On 04/01/2011 02:17 PM, Rob Crittenden wrote: >> Stephen Gallagher wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 04/01/2011 03:55 PM, Rob Crittenden wrote: >>>> Use fullname for gecos instead of uid. >>>> >>>> ticket 1146 >>> >>> >>> While it probably doesn't actually matter for these tests, I should note >>> that the GECOS attribute in LDAP is IA5String, not UTF8. >>> >>> Otherwise, Ack. >> >> It is defined using Directory String syntax by 389-ds. According to >> rfc 2307 it should be an IA5String, not sure why it isn't but we >> inherit this schema. > It is defined in the original rfc 2307 as Directory String, but 2307bis > redefined it to IA5String. Actually, I just looked at both RFC 2307 and RFC 2307bis. It's defined as IA5String in both. - From http://www.ietf.org/rfc/rfc2307.txt: 3. Attribute definitions This section contains attribute definitions to be implemented by DUAs supporting this schema. ... ( nisSchema.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseIgnoreIA5Match SUBSTRINGS caseIgnoreIA5SubstringsMatch SYNTAX 'IA5String' SINGLE-VALUE ) And from http://www.padl.com/~lukeh/rfc2307bis.txt 3. Attribute definitions This section contains attribute definitions to be implemented by DUAs supporting this schema. ... ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseIgnoreIA5Match SUBSTRINGS caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2ZzpQACgkQeiVVYja6o6NBBgCghFzG3FyVhAJV54TfytAad2K5 auwAnRqIrpk08cwTMdmGNep0tCndi5NM =ZxMd -----END PGP SIGNATURE----- From sgallagh at redhat.com Mon Apr 4 14:01:29 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 04 Apr 2011 10:01:29 -0400 Subject: [Freeipa-devel] [PATCH] 763 use full name for gecos In-Reply-To: <4D99CE94.5080903@redhat.com> References: <4D962DBA.6080709@redhat.com> <4D963007.1080807@redhat.com> <4D9632F5.4070503@redhat.com> <4D964E63.1030109@redhat.com> <4D99CE94.5080903@redhat.com> Message-ID: <4D99CF39.5040307@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2011 09:58 AM, Stephen Gallagher wrote: > On 04/01/2011 06:14 PM, Rich Megginson wrote: >> On 04/01/2011 02:17 PM, Rob Crittenden wrote: >>> Stephen Gallagher wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 04/01/2011 03:55 PM, Rob Crittenden wrote: >>>>> Use fullname for gecos instead of uid. >>>>> >>>>> ticket 1146 >>>> >>>> >>>> While it probably doesn't actually matter for these tests, I should note >>>> that the GECOS attribute in LDAP is IA5String, not UTF8. >>>> >>>> Otherwise, Ack. >>> >>> It is defined using Directory String syntax by 389-ds. According to >>> rfc 2307 it should be an IA5String, not sure why it isn't but we >>> inherit this schema. >> It is defined in the original rfc 2307 as Directory String, but 2307bis >> redefined it to IA5String. > > > Actually, I just looked at both RFC 2307 and RFC 2307bis. It's defined > as IA5String in both. > > From http://www.ietf.org/rfc/rfc2307.txt: > 3. Attribute definitions > > This section contains attribute definitions to be implemented by DUAs > supporting this schema. > ... > ( nisSchema.1.2 NAME 'gecos' > DESC 'The GECOS field; the common name' > EQUALITY caseIgnoreIA5Match > SUBSTRINGS caseIgnoreIA5SubstringsMatch > SYNTAX 'IA5String' SINGLE-VALUE ) > > > And from http://www.padl.com/~lukeh/rfc2307bis.txt > 3. Attribute definitions > > This section contains attribute definitions to be implemented by > DUAs supporting this schema. > ... > ( 1.3.6.1.1.1.1.2 NAME 'gecos' > DESC 'The GECOS field; the common name' > EQUALITY caseIgnoreIA5Match > SUBSTRINGS caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 > SINGLE-VALUE ) > Hmm, strange. http://bgp.potaroo.net/ietf/idref/draft-howard-rfc2307bis/ defines it as DirectoryString. So I have no idea which one is "more correct" for RFC 2307bis. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2ZzzkACgkQeiVVYja6o6NEzQCeN9LxMNSd05Kqj6NHhRxOfXAw wsUAmwVplkWHnsLN/z2DY0RSJL+mbNMZ =gI9S -----END PGP SIGNATURE----- From jhrozek at redhat.com Mon Apr 4 14:26:43 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 04 Apr 2011 16:26:43 +0200 Subject: [Freeipa-devel] [PATCH] 045 Add DNS record modification command In-Reply-To: <20110404093823.7becd508@willson.li.ssimo.org> References: <1301498000.28351.11.camel@dhcp-25-52.brq.redhat.com> <4D93981C.6010403@redhat.com> <1301563645.25947.15.camel@dhcp-25-52.brq.redhat.com> <4D95B4EB.5070705@redhat.com> <20110404093823.7becd508@willson.li.ssimo.org> Message-ID: <4D99D523.5050504@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2011 03:38 PM, Simo Sorce wrote: >> I think that this is kinda hard to do in CLI..in GUI the user can >> > easily pick a record to mod, but for CLI case I would actually lean >> > towards the approach Martin took in his original patch..that is, a >> > -mod replaces the entries altogether. > Why is it hard ? > You just need to provide means to delete and add records in the same > command. > > ipa dnsrecord-mod DNSZONE DNSRECORD --del-a-rec=1.2.3.4 \ > --add-a-rec=4.3.2.1 > > to replace all: > ipa dnsrecord-mod DNSZONE DNSRECORD --del-all --add-a-rec=4.3.2.1 > > I was not trying to say it is not technically doable, but it's hard to use. Imagine how the --help output would look like, if for every RR we would also generate a --del equivalent..even now the output almost doesn't fit on screen. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Z1SIACgkQHsardTLnvCUdNgCg36qiEb3dg9Zio+E/GuF05sTP rTYAoJ0m1S4YMOdaP1vueQxEBtM70Ifs =m8si -----END PGP SIGNATURE----- From ayoung at redhat.com Mon Apr 4 14:45:33 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 04 Apr 2011 10:45:33 -0400 Subject: [Freeipa-devel] [PATCH] 045 Add DNS record modification command In-Reply-To: <4D99D523.5050504@redhat.com> References: <1301498000.28351.11.camel@dhcp-25-52.brq.redhat.com> <4D93981C.6010403@redhat.com> <1301563645.25947.15.camel@dhcp-25-52.brq.redhat.com> <4D95B4EB.5070705@redhat.com> <20110404093823.7becd508@willson.li.ssimo.org> <4D99D523.5050504@redhat.com> Message-ID: <4D99D98D.5050704@redhat.com> On 04/04/2011 10:26 AM, Jakub Hrozek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/04/2011 03:38 PM, Simo Sorce wrote: >>> I think that this is kinda hard to do in CLI..in GUI the user can >>>> easily pick a record to mod, but for CLI case I would actually lean >>>> towards the approach Martin took in his original patch..that is, a >>>> -mod replaces the entries altogether. >> Why is it hard ? >> You just need to provide means to delete and add records in the same >> command. >> >> ipa dnsrecord-mod DNSZONE DNSRECORD --del-a-rec=1.2.3.4 \ >> --add-a-rec=4.3.2.1 >> >> to replace all: >> ipa dnsrecord-mod DNSZONE DNSRECORD --del-all --add-a-rec=4.3.2.1 >> >> > I was not trying to say it is not technically doable, but it's hard to > use. Imagine how the --help output would look like, if for every RR we > would also generate a --del equivalent..even now the output almost > doesn't fit on screen. I agree. I am not a far of the ability to do operations for multiple record types in the same command. It is strangly in consistant to be able to add an A Record, CNAMe, MX and AAAA record all in the same command. I'm starting to think that the dnsrecord should not be a separate entity exposed by the CLI, but instead should be wrapped up into the dnszone entity. That seems to be how the LDAP object is defined. We treat each record type as a multi-value field, and we use a consistant look and feel as email addresses and phone numbers in the user object. Then, modifying an A record is the same as modifing a phone number: us add-attr/set-addr for each valu. Step one would be to modify the dns zone object to have this API, and to mark the dnsrecord object as deprecated. We can leave it for the remainder of the release, and remove it in 3.0 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2Z1SIACgkQHsardTLnvCUdNgCg36qiEb3dg9Zio+E/GuF05sTP > rTYAoJ0m1S4YMOdaP1vueQxEBtM70Ifs > =m8si > -----END PGP SIGNATURE----- > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From sbose at redhat.com Mon Apr 4 14:41:00 2011 From: sbose at redhat.com (Sumit Bose) Date: Mon, 4 Apr 2011 16:41:00 +0200 Subject: [Freeipa-devel] [PATCH] 763 use full name for gecos In-Reply-To: <4D99CF39.5040307@redhat.com> References: <4D962DBA.6080709@redhat.com> <4D963007.1080807@redhat.com> <4D9632F5.4070503@redhat.com> <4D964E63.1030109@redhat.com> <4D99CE94.5080903@redhat.com> <4D99CF39.5040307@redhat.com> Message-ID: <20110404144100.GI16463@localhost.localdomain> On Mon, Apr 04, 2011 at 10:01:29AM -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/04/2011 09:58 AM, Stephen Gallagher wrote: > > On 04/01/2011 06:14 PM, Rich Megginson wrote: > >> On 04/01/2011 02:17 PM, Rob Crittenden wrote: > >>> Stephen Gallagher wrote: > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>> Hash: SHA1 > >>>> > >>>> On 04/01/2011 03:55 PM, Rob Crittenden wrote: > >>>>> Use fullname for gecos instead of uid. > >>>>> > >>>>> ticket 1146 > >>>> > >>>> > >>>> While it probably doesn't actually matter for these tests, I should note > >>>> that the GECOS attribute in LDAP is IA5String, not UTF8. > >>>> > >>>> Otherwise, Ack. > >>> > >>> It is defined using Directory String syntax by 389-ds. According to > >>> rfc 2307 it should be an IA5String, not sure why it isn't but we > >>> inherit this schema. > >> It is defined in the original rfc 2307 as Directory String, but 2307bis > >> redefined it to IA5String. > > > > > > Actually, I just looked at both RFC 2307 and RFC 2307bis. It's defined > > as IA5String in both. > > > > From http://www.ietf.org/rfc/rfc2307.txt: > > 3. Attribute definitions > > > > This section contains attribute definitions to be implemented by DUAs > > supporting this schema. > > ... > > ( nisSchema.1.2 NAME 'gecos' > > DESC 'The GECOS field; the common name' > > EQUALITY caseIgnoreIA5Match > > SUBSTRINGS caseIgnoreIA5SubstringsMatch > > SYNTAX 'IA5String' SINGLE-VALUE ) > > > > > > And from http://www.padl.com/~lukeh/rfc2307bis.txt > > 3. Attribute definitions > > > > This section contains attribute definitions to be implemented by > > DUAs supporting this schema. > > ... > > ( 1.3.6.1.1.1.1.2 NAME 'gecos' > > DESC 'The GECOS field; the common name' > > EQUALITY caseIgnoreIA5Match > > SUBSTRINGS caseIgnoreIA5SubstringsMatch > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 > > SINGLE-VALUE ) > > > > > Hmm, strange. http://bgp.potaroo.net/ietf/idref/draft-howard-rfc2307bis/ > defines it as DirectoryString. > > So I have no idea which one is "more correct" for RFC 2307bis. Look at the diffs in http://bgp.potaroo.net/ietf/idref/draft-howard-rfc2307bis/ There are currently -00, -01 and -02 of the draft. bye, Sumit > > > - -- > Stephen Gallagher > RHCE 804006346421761 > > Delivering value year after year. > Red Hat ranks #1 in value among software vendors. > http://www.redhat.com/promo/vendor/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2ZzzkACgkQeiVVYja6o6NEzQCeN9LxMNSd05Kqj6NHhRxOfXAw > wsUAmwVplkWHnsLN/z2DY0RSJL+mbNMZ > =gI9S > -----END PGP SIGNATURE----- > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From edewata at redhat.com Mon Apr 4 16:37:56 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 04 Apr 2011 11:37:56 -0500 Subject: [Freeipa-devel] [PATCH] 130 Added functional test runner. Message-ID: <4D99F3E4.3080805@redhat.com> The functional.sh runs all or select functional test suites. The selenium-results.js parses and displays the test results. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0130-Added-functional-test-runner.patch Type: text/x-patch Size: 715728 bytes Desc: not available URL: From sgallagh at redhat.com Mon Apr 4 17:38:35 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 04 Apr 2011 13:38:35 -0400 Subject: [Freeipa-devel] [PATCH] 763 use full name for gecos In-Reply-To: <20110404144100.GI16463@localhost.localdomain> References: <4D962DBA.6080709@redhat.com> <4D963007.1080807@redhat.com> <4D9632F5.4070503@redhat.com> <4D964E63.1030109@redhat.com> <4D99CE94.5080903@redhat.com> <4D99CF39.5040307@redhat.com> <20110404144100.GI16463@localhost.localdomain> Message-ID: <4D9A021B.4010705@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2011 10:41 AM, Sumit Bose wrote: > On Mon, Apr 04, 2011 at 10:01:29AM -0400, Stephen Gallagher wrote: > On 04/04/2011 09:58 AM, Stephen Gallagher wrote: >>>> On 04/01/2011 06:14 PM, Rich Megginson wrote: >>>>> On 04/01/2011 02:17 PM, Rob Crittenden wrote: >>>>>> Stephen Gallagher wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> On 04/01/2011 03:55 PM, Rob Crittenden wrote: >>>>>>>> Use fullname for gecos instead of uid. >>>>>>>> >>>>>>>> ticket 1146 >>>>>>> >>>>>>> >>>>>>> While it probably doesn't actually matter for these tests, I should note >>>>>>> that the GECOS attribute in LDAP is IA5String, not UTF8. >>>>>>> >>>>>>> Otherwise, Ack. >>>>>> >>>>>> It is defined using Directory String syntax by 389-ds. According to >>>>>> rfc 2307 it should be an IA5String, not sure why it isn't but we >>>>>> inherit this schema. >>>>> It is defined in the original rfc 2307 as Directory String, but 2307bis >>>>> redefined it to IA5String. >>>> >>>> >>>> Actually, I just looked at both RFC 2307 and RFC 2307bis. It's defined >>>> as IA5String in both. >>>> >>>> From http://www.ietf.org/rfc/rfc2307.txt: >>>> 3. Attribute definitions >>>> >>>> This section contains attribute definitions to be implemented by DUAs >>>> supporting this schema. >>>> ... >>>> ( nisSchema.1.2 NAME 'gecos' >>>> DESC 'The GECOS field; the common name' >>>> EQUALITY caseIgnoreIA5Match >>>> SUBSTRINGS caseIgnoreIA5SubstringsMatch >>>> SYNTAX 'IA5String' SINGLE-VALUE ) >>>> >>>> >>>> And from http://www.padl.com/~lukeh/rfc2307bis.txt >>>> 3. Attribute definitions >>>> >>>> This section contains attribute definitions to be implemented by >>>> DUAs supporting this schema. >>>> ... >>>> ( 1.3.6.1.1.1.1.2 NAME 'gecos' >>>> DESC 'The GECOS field; the common name' >>>> EQUALITY caseIgnoreIA5Match >>>> SUBSTRINGS caseIgnoreIA5SubstringsMatch >>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >>>> SINGLE-VALUE ) >>>> > > > Hmm, strange. http://bgp.potaroo.net/ietf/idref/draft-howard-rfc2307bis/ > defines it as DirectoryString. > > So I have no idea which one is "more correct" for RFC 2307bis. > >> Look at the diffs in >> http://bgp.potaroo.net/ietf/idref/draft-howard-rfc2307bis/ > >> There are currently -00, -01 and -02 of the draft. With that in mind, Ack. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2aAhsACgkQeiVVYja6o6O6vgCfQ3OaAzTfA0d3s/FKKxensJGe ojsAoIaRo5dHTvE6Swio3I8wrmx9NBlA =fRLZ -----END PGP SIGNATURE----- From sgallagh at redhat.com Mon Apr 4 21:02:46 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 04 Apr 2011 17:02:46 -0400 Subject: [Freeipa-devel] [Freeipa-users] 6.1 beta In-Reply-To: <4D9A2D7C.706@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A1DCC.5070709@redhat.com> <4D9A2163.5090903@nixtra.com> <4D9A2645.4030000@redhat.com> <4D9A2827.2020406@nixtra.com> <4D9A29D6.2080003@redhat.com> <4D9A2D7C.706@nixtra.com> Message-ID: <4D9A31F6.8080708@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2011 04:43 PM, Sigbjorn Lie wrote: > On 04/04/2011 10:28 PM, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 04/04/2011 04:20 PM, Sigbjorn Lie wrote: >>> On 04/04/2011 10:12 PM, Stephen Gallagher wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 04/04/2011 03:52 PM, Sigbjorn Lie wrote: >>>>> On 04/04/2011 09:36 PM, Stephen Gallagher wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> On 04/04/2011 03:06 PM, Dmitri Pal wrote: >>>>>>> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >>>>>>>> I also noticed that in /etc/sssd/sssd.conf the ipa server is >>>>>>>> specified >>>>>>>> with: >>>>>>>> ipa_server = _srv_, ipa01.ix.test.com >>>>>>>> >>>>>>>> sssd doesn't resolve anything from IPA until I remove "_srv_," >>>>>>>> >>>>>>> Stephen, was there a recent bug on this matter in SSSD? >>>>>>> >>>>>> The purpose of _srv_ is to check DNS for IPA server addresses first. >>>>>> The >>>>>> idea is that if you have more than one IPA server in service, then >>>>>> you >>>>>> can use DNS to list all of them. Otherwise, the ipa-client-install >>>>>> can >>>>>> only specify a static list of servers at the time of install. This >>>>>> would >>>>>> mean that if the IPA servers changed IP addresses or new ones entered >>>>>> production, it would be necessary to change all of the client >>>>>> configuration files. >>>>>> >>>>>> I'm puzzled why you would need to remove this, unless your DNS >>>>>> server is >>>>>> returning something other than FreeIPA servers for a SRV request >>>>>> directed at _ldap.tcp >>>>>> >>>>> I have verfied that the _ldap._tcp is resolving correctly. DNS was set >>>>> up using "ipa-server-install --setup-dns". I discovered this at the >>>>> IPA >>>>> server. This is a newly installed IPA server at RH 6.1 beta >>>>> installed a >>>>> few hours ago. No IP addresses changed. >>>>> >>>>> >>>>> # host -t srv _ldap._tcp >>>>> _ldap._tcp.ix.test.com has SRV record 0 100 389 ipa01.ix.test.com. >>>> Is the domain part of the client machine also ix.test.com? >>>> >>>> The way we determine which SRV record to use is as follows: >>>> 1) If dns_discovery_domain exists in the config file, it is always >>>> used. >>>> 2) If not, first try the domain part of the machine's hostname (aka >>>> hostname -d) >>>> 3) If that fails, try the name of the SSSD domain (in sssd.conf >>>> [domain/] >>>> >>>> IIRC ipa-client-install should set [domain/] so if >>>> that's not the same as your DNS domain, we could be having problems. >>>> >>>> Can we see your sssd.conf please? (feel free to sanitize as needed) >>>> >>> Please see the requested output below. This is taken from the IPA >>> server, which had the issue. DNS servers in resolv.conf set to the IP of >>> the IPA server. >>> >>> >>> # hostname -d >>> ix.test.com >>> >>> # more sssd.conf >>> [sssd] >>> services = nss, pam >>> config_file_version = 2 >>> >>> domains = ix.test.com >>> [nss] >>> >>> [pam] >>> >>> [domain/ix.test.com] >>> cache_credentials = True >>> ipa_domain = ix.test.com >>> id_provider = ipa >>> auth_provider = ipa >>> access_provider = ipa >>> chpass_provider = ipa >>> #ipa_server = _srv_, ipa01.ix.test.com >>> ipa_server = ipa01.ix.test.com >>> >>> [domain/default] >>> cache_credentials = True >>> krb5_realm = IX.TEST.COM >>> krb5_kdcip = ipa01.ix.test.com:88 >>> auth_provider = krb5 >>> chpass_provider = krb5 >>> krb5_kpasswd = ipa01.ix.test.com:749 >>> >> That's very strange. There should be no issue with using _srv_ in this >> configuration. Would you mind setting 'debug_level = 9' in >> [domain/ix.test.com], turning _srv_ back on, restarting SSSD, trying a >> request and then send me /var/log/sssd/sssd_ix.test.com.log to look at? >> I'd like to know why we're failing to resolve it. >> > Sure, see the attached file. I'm sending private, unscrambeled. > > For some reason it started working now, sluggish, but working. Takes > 0.488s to look up a new user account using "# id username" > > The log file is too much to read for me just now, it's getting late. :) Can you show me the output from 'dig' instead of SRV? The logs you sent seem to be telling me that the TTL is set to something extremely short, because we're marking it as expired pretty much instantly. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2aMfYACgkQeiVVYja6o6PPQACfW6+sTJwQN/sPigJVh7Un6X8m x8EAn1qLk5hJKX11OwJ06dFLewkEUt01 =c9UJ -----END PGP SIGNATURE----- From rcritten at redhat.com Mon Apr 4 21:23:47 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Apr 2011 17:23:47 -0400 Subject: [Freeipa-devel] [PATCH] 764 update ipa-client-install man page Message-ID: <4D9A36E3.5010207@redhat.com> Make it clear that --on-master is for install scripts only. ticket 1050 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-764-man.patch Type: application/mbox Size: 1151 bytes Desc: not available URL: From ayoung at redhat.com Tue Apr 5 01:46:07 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 04 Apr 2011 21:46:07 -0400 Subject: [Freeipa-devel] Automount Documentation Message-ID: <4D9A745F.3080301@redhat.com> OK, Just looked at what we have on Automount: http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/html-single/#sect-Enterprise_Identity_Management_Guide-Configuring_Automount It doesn't have any examples of the ipa commands a user would run. Here's what I'd like to be able to do: 1. Create a new locations: pretty easy, ipa automountlocation-add is pretty easy to figure out, and a location doesn't really need that much in the way of configuring. 2. Create a new map: Ok, direct or indirect? which is the more common, and which is the corner case? I'm guessing that direct is the more common, but the docs are not helpful: automountmap-add AUTOMOUNTLOCATION MAP [options] and no automount specific options are listed, besides description. add indirect map is a little more expressive: --mount=STR Mount point --parentmap=STR Name of parent automount map (default: auto.master). I tried running this command and both of these are required parameters, although they are not annotated as such. Is it true that only an indirect map has a mount point? Moving on to Keys: automountkey-add AUTOMOUNTLOCATION AUTOMOUNTMAP [options] --key=IA5STR Automount key name. --info=IA5STR Mount information Not too bad. That is pretty clear. The step by step here looks better. https://fedoraproject.org/wiki/QA:Testcase_freeipav2_automount Anyone that understands this care to illuminate me? From mkosek at redhat.com Tue Apr 5 10:34:00 2011 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Apr 2011 12:34:00 +0200 Subject: [Freeipa-devel] [PATCH] 764 update ipa-client-install man page In-Reply-To: <4D9A36E3.5010207@redhat.com> References: <4D9A36E3.5010207@redhat.com> Message-ID: <1301999640.20811.5.camel@dhcp-25-52.brq.redhat.com> I don't think it is a good idea to have this option in ipa-client-install --help at all. Since it is not intended to be used by the user and we just use it in our scripts why would we want to have it in ipa-client-install --help or man pages? We could just hide it using help=optparse.SUPPRESS_HELP attribute for the option and document it only in the installation script source. Martin On Mon, 2011-04-04 at 17:23 -0400, Rob Crittenden wrote: > Make it clear that --on-master is for install scripts only. > > ticket 1050 > > rob > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Tue Apr 5 15:59:21 2011 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Apr 2011 17:59:21 +0200 Subject: [Freeipa-devel] [PATCH] 045 Add DNS record modification command In-Reply-To: <4D99D98D.5050704@redhat.com> References: <1301498000.28351.11.camel@dhcp-25-52.brq.redhat.com> <4D93981C.6010403@redhat.com> <1301563645.25947.15.camel@dhcp-25-52.brq.redhat.com> <4D95B4EB.5070705@redhat.com> <20110404093823.7becd508@willson.li.ssimo.org> <4D99D523.5050504@redhat.com> <4D99D98D.5050704@redhat.com> Message-ID: <1302019161.20811.23.camel@dhcp-25-52.brq.redhat.com> On Mon, 2011-04-04 at 10:45 -0400, Adam Young wrote: > On 04/04/2011 10:26 AM, Jakub Hrozek wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 04/04/2011 03:38 PM, Simo Sorce wrote: > >>> I think that this is kinda hard to do in CLI..in GUI the user can > >>>> easily pick a record to mod, but for CLI case I would actually lean > >>>> towards the approach Martin took in his original patch..that is, a > >>>> -mod replaces the entries altogether. > >> Why is it hard ? > >> You just need to provide means to delete and add records in the same > >> command. > >> > >> ipa dnsrecord-mod DNSZONE DNSRECORD --del-a-rec=1.2.3.4 \ > >> --add-a-rec=4.3.2.1 > >> > >> to replace all: > >> ipa dnsrecord-mod DNSZONE DNSRECORD --del-all --add-a-rec=4.3.2.1 > >> > >> > > I was not trying to say it is not technically doable, but it's hard to > > use. Imagine how the --help output would look like, if for every RR we > > would also generate a --del equivalent..even now the output almost > > doesn't fit on screen. > I agree. I am not a far of the ability to do operations for multiple > record types in the same command. It is strangly in consistant to be > able to add an A Record, CNAMe, MX and AAAA record all in the same command. We are modifying one or more attributes of the LDAP DNS record object - I don't find it inconsistent. It is the same like when we edit the user, we can set his email and title using one command. > I'm starting to think that the dnsrecord should not be a separate entity > exposed by the CLI, but instead should be wrapped up into the dnszone > entity. That seems to be how the LDAP object is defined. We treat each > record type as a multi-value field, and we use a consistant look and > feel as email addresses and phone numbers in the user object. Then, > modifying an A record is the same as modifing a phone number: us > add-attr/set-addr for each valu. > > Step one would be to modify the dns zone object to have this API, and to > mark the dnsrecord object as deprecated. We can leave it for the > remainder of the release, and remove it in 3.0 In LDAP, we have an object for the zone with Object Classes idnszone and idnsrecord (e.g. example.com). Then there are LDAP objects representing DNS records (e.g. www) with OC idnsrecord with the DNS zone object as a parent. Both DNS zone and DNS record objects can contain the actual DNS resource records as its attributes (e.g. attribute srvRecord or aRecord). I think the current dns plugin reflects this structure well by having commands for both dnszone and dnsrecords. We need both objects for managing DNS. Martin From ssorce at redhat.com Tue Apr 5 16:05:53 2011 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 5 Apr 2011 12:05:53 -0400 Subject: [Freeipa-devel] [PATCH] 045 Add DNS record modification command In-Reply-To: <1302019161.20811.23.camel@dhcp-25-52.brq.redhat.com> References: <1301498000.28351.11.camel@dhcp-25-52.brq.redhat.com> <4D93981C.6010403@redhat.com> <1301563645.25947.15.camel@dhcp-25-52.brq.redhat.com> <4D95B4EB.5070705@redhat.com> <20110404093823.7becd508@willson.li.ssimo.org> <4D99D523.5050504@redhat.com> <4D99D98D.5050704@redhat.com> <1302019161.20811.23.camel@dhcp-25-52.brq.redhat.com> Message-ID: <20110405120553.347f3abc@willson.li.ssimo.org> On Tue, 05 Apr 2011 17:59:21 +0200 Martin Kosek wrote: > > I'm starting to think that the dnsrecord should not be a separate > > entity exposed by the CLI, but instead should be wrapped up into > > the dnszone entity. That seems to be how the LDAP object is > > defined. We treat each record type as a multi-value field, and we > > use a consistant look and feel as email addresses and phone > > numbers in the user object. Then, modifying an A record is the > > same as modifing a phone number: us add-attr/set-addr for each > > valu. > > > > Step one would be to modify the dns zone object to have this API, > > and to mark the dnsrecord object as deprecated. We can leave it > > for the remainder of the release, and remove it in 3.0 > > In LDAP, we have an object for the zone with Object Classes idnszone > and idnsrecord (e.g. example.com). Then there are LDAP objects > representing DNS records (e.g. www) with OC idnsrecord with the DNS > zone object as a parent. Both DNS zone and DNS record objects can > contain the actual DNS resource records as its attributes (e.g. > attribute srvRecord or aRecord). > > I think the current dns plugin reflects this structure well by having > commands for both dnszone and dnsrecords. We need both objects for > managing DNS. I strongly agree with Martin. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Apr 5 18:21:55 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Apr 2011 14:21:55 -0400 Subject: [Freeipa-devel] [PATCH] 763 use full name for gecos In-Reply-To: <4D9A021B.4010705@redhat.com> References: <4D962DBA.6080709@redhat.com> <4D963007.1080807@redhat.com> <4D9632F5.4070503@redhat.com> <4D964E63.1030109@redhat.com> <4D99CE94.5080903@redhat.com> <4D99CF39.5040307@redhat.com> <20110404144100.GI16463@localhost.localdomain> <4D9A021B.4010705@redhat.com> Message-ID: <4D9B5DC3.8000503@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/04/2011 10:41 AM, Sumit Bose wrote: >> On Mon, Apr 04, 2011 at 10:01:29AM -0400, Stephen Gallagher wrote: >> On 04/04/2011 09:58 AM, Stephen Gallagher wrote: >>>>> On 04/01/2011 06:14 PM, Rich Megginson wrote: >>>>>> On 04/01/2011 02:17 PM, Rob Crittenden wrote: >>>>>>> Stephen Gallagher wrote: >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> Hash: SHA1 >>>>>>>> >>>>>>>> On 04/01/2011 03:55 PM, Rob Crittenden wrote: >>>>>>>>> Use fullname for gecos instead of uid. >>>>>>>>> >>>>>>>>> ticket 1146 >>>>>>>> >>>>>>>> >>>>>>>> While it probably doesn't actually matter for these tests, I should note >>>>>>>> that the GECOS attribute in LDAP is IA5String, not UTF8. >>>>>>>> >>>>>>>> Otherwise, Ack. >>>>>>> >>>>>>> It is defined using Directory String syntax by 389-ds. According to >>>>>>> rfc 2307 it should be an IA5String, not sure why it isn't but we >>>>>>> inherit this schema. >>>>>> It is defined in the original rfc 2307 as Directory String, but 2307bis >>>>>> redefined it to IA5String. >>>>> >>>>> >>>>> Actually, I just looked at both RFC 2307 and RFC 2307bis. It's defined >>>>> as IA5String in both. >>>>> >>>>> From http://www.ietf.org/rfc/rfc2307.txt: >>>>> 3. Attribute definitions >>>>> >>>>> This section contains attribute definitions to be implemented by DUAs >>>>> supporting this schema. >>>>> ... >>>>> ( nisSchema.1.2 NAME 'gecos' >>>>> DESC 'The GECOS field; the common name' >>>>> EQUALITY caseIgnoreIA5Match >>>>> SUBSTRINGS caseIgnoreIA5SubstringsMatch >>>>> SYNTAX 'IA5String' SINGLE-VALUE ) >>>>> >>>>> >>>>> And from http://www.padl.com/~lukeh/rfc2307bis.txt >>>>> 3. Attribute definitions >>>>> >>>>> This section contains attribute definitions to be implemented by >>>>> DUAs supporting this schema. >>>>> ... >>>>> ( 1.3.6.1.1.1.1.2 NAME 'gecos' >>>>> DESC 'The GECOS field; the common name' >>>>> EQUALITY caseIgnoreIA5Match >>>>> SUBSTRINGS caseIgnoreIA5SubstringsMatch >>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >>>>> SINGLE-VALUE ) >>>>> >> >> >> Hmm, strange. http://bgp.potaroo.net/ietf/idref/draft-howard-rfc2307bis/ >> defines it as DirectoryString. >> >> So I have no idea which one is "more correct" for RFC 2307bis. >> >>> Look at the diffs in >>> http://bgp.potaroo.net/ietf/idref/draft-howard-rfc2307bis/ >> >>> There are currently -00, -01 and -02 of the draft. > > > With that in mind, Ack. Pushed to master and ipa-2-0 rob From rcritten at redhat.com Tue Apr 5 20:30:31 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Apr 2011 16:30:31 -0400 Subject: [Freeipa-devel] [PATCH] 765 update schema Message-ID: <4D9B7BE7.6070103@redhat.com> Fix ORDERING in some attributetypes and remove other unnecessary elements. Looking at the schema in 60basev2.ldif there were many attributes that did not have an ORDERING matching rule specified correctly. There were also a number of attributeTypes that should have been just SUP distinguishedName that had a combination of SUP, SYNTAX, ORDERING, etc. This requires 389-ds-base-1.2.8.0-1+ ticket 1153 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-765-schema.patch Type: application/mbox Size: 25451 bytes Desc: not available URL: From ayoung at redhat.com Tue Apr 5 20:35:53 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 05 Apr 2011 16:35:53 -0400 Subject: [Freeipa-devel] [PATCH] 130 Added functional test runner. In-Reply-To: <4D99F3E4.3080805@redhat.com> References: <4D99F3E4.3080805@redhat.com> Message-ID: <4D9B7D29.3090002@redhat.com> On 04/04/2011 12:37 PM, Endi Sukma Dewata wrote: > The functional.sh runs all or select functional test suites. > The selenium-results.js parses and displays the test results. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This is awesome. Minor nit, need to create the results directory. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 5 20:54:12 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Apr 2011 16:54:12 -0400 Subject: [Freeipa-devel] [PATCH] 765 update schema In-Reply-To: <4D9B7BE7.6070103@redhat.com> References: <4D9B7BE7.6070103@redhat.com> Message-ID: <4D9B8174.1040204@redhat.com> Rob Crittenden wrote: > Fix ORDERING in some attributetypes and remove other unnecessary elements. > > Looking at the schema in 60basev2.ldif there were many attributes that > did not have an ORDERING matching rule specified correctly. There were > also a number of attributeTypes that should have been just SUP > distinguishedName that had a combination of SUP, SYNTAX, ORDERING, etc. > > This requires 389-ds-base-1.2.8.0-1+ > > ticket 1153 > > rob I forgot to include 2 changes: - Don't do deletes when modifying schema, it will fail. Doing an ADD will replace existing schema. - Request attributeTypes and objectClasses when retrieving entries. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-765-2-schema.patch Type: application/mbox Size: 27093 bytes Desc: not available URL: From rmeggins at redhat.com Tue Apr 5 21:02:18 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 05 Apr 2011 15:02:18 -0600 Subject: [Freeipa-devel] [PATCH] 765 update schema In-Reply-To: <4D9B8174.1040204@redhat.com> References: <4D9B7BE7.6070103@redhat.com> <4D9B8174.1040204@redhat.com> Message-ID: <4D9B835A.7070207@redhat.com> On 04/05/2011 02:54 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Fix ORDERING in some attributetypes and remove other unnecessary >> elements. >> >> Looking at the schema in 60basev2.ldif there were many attributes that >> did not have an ORDERING matching rule specified correctly. There were >> also a number of attributeTypes that should have been just SUP >> distinguishedName that had a combination of SUP, SYNTAX, ORDERING, etc. >> >> This requires 389-ds-base-1.2.8.0-1+ >> >> ticket 1153 >> >> rob > > I forgot to include 2 changes: > > - Don't do deletes when modifying schema, it will fail. Doing an ADD > will replace existing schema. > - Request attributeTypes and objectClasses when retrieving entries. > > rob ack > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 5 21:20:34 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Apr 2011 17:20:34 -0400 Subject: [Freeipa-devel] Automount Documentation In-Reply-To: <4D9A745F.3080301@redhat.com> References: <4D9A745F.3080301@redhat.com> Message-ID: <4D9B87A2.3090508@redhat.com> Adam Young wrote: > OK, Just looked at what we have on Automount: > > http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/html-single/#sect-Enterprise_Identity_Management_Guide-Configuring_Automount > > > It doesn't have any examples of the ipa commands a user would run. The command help has quite a few examples ipa help automount > > > Here's what I'd like to be able to do: > > 1. Create a new locations: pretty easy, ipa automountlocation-add is > pretty easy to figure out, and a location doesn't really need that much > in the way of configuring. > > 2. Create a new map: Ok, direct or indirect? which is the more common, > and which is the corner case? I'm guessing that direct is the more > common, but the docs are not helpful: It is not a question of common vs uncommon, they are used for different purposes. > > automountmap-add AUTOMOUNTLOCATION MAP [options] > > and no automount specific options are listed, besides description. There are no options. When you add a map you just specify the name and the location: ipa automountlocation-add baltimore ipa automountmap-add baltimore auto.share ipa automountkey-add baltimore auto.share --key=man --info="-ro,soft,rsize=8192,wsize=8192 ipa.example.com:/shared/man" For a direct map: ipa automountkey-add baltimore auto.direct --key=/stuff --info="-ro,soft,rsize=8192,wsize=8192 ipa.example.com:/h/stuff" > > > add indirect map is a little more expressive: > > --mount=STR Mount point > --parentmap=STR Name of parent automount map (default: auto.master). > > > I tried running this command and both of these are required parameters, > although they are not annotated as such. > > Is it true that only an indirect map has a mount point? Both have mount points, they are just specified differently. A direct map lists an exact place to mount the map (/usr/local/bin, /mnt, whatever). An indirect map defines a bucket to drop mounts into. So it might point to /share and all keys for that are relative to that. So you define a key ayoung, the map would be /share/ayoung. > > Moving on to Keys: > > automountkey-add AUTOMOUNTLOCATION AUTOMOUNTMAP [options] > --key=IA5STR Automount key name. > --info=IA5STR Mount information > > Not too bad. That is pretty clear. > > The step by step here looks better. > https://fedoraproject.org/wiki/QA:Testcase_freeipav2_automount > > > Anyone that understands this care to illuminate me? > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From edewata at redhat.com Tue Apr 5 21:27:39 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 05 Apr 2011 16:27:39 -0500 Subject: [Freeipa-devel] [PATCH] 130 Added functional test runner. In-Reply-To: <4D9B7D29.3090002@redhat.com> References: <4D99F3E4.3080805@redhat.com> <4D9B7D29.3090002@redhat.com> Message-ID: <4D9B894B.8090007@redhat.com> On 4/5/2011 3:35 PM, Adam Young wrote: > On 04/04/2011 12:37 PM, Endi Sukma Dewata wrote: >> The functional.sh runs all or select functional test suites. >> The selenium-results.js parses and displays the test results. > This is awesome. Minor nit, need to create the results directory. Thanks. Fixed and pushed to master. -- Endi S. Dewata From ayoung at redhat.com Tue Apr 5 21:33:46 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 05 Apr 2011 17:33:46 -0400 Subject: [Freeipa-devel] Automount Documentation In-Reply-To: <4D9B87A2.3090508@redhat.com> References: <4D9A745F.3080301@redhat.com> <4D9B87A2.3090508@redhat.com> Message-ID: <4D9B8ABA.6040307@redhat.com> Thanks, Rob. That helps a lot. On 04/05/2011 05:20 PM, Rob Crittenden wrote: > Adam Young wrote: >> OK, Just looked at what we have on Automount: >> >> http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/html-single/#sect-Enterprise_Identity_Management_Guide-Configuring_Automount >> >> >> >> It doesn't have any examples of the ipa commands a user would run. > > The command help has quite a few examples > > ipa help automount > >> >> >> Here's what I'd like to be able to do: >> >> 1. Create a new locations: pretty easy, ipa automountlocation-add is >> pretty easy to figure out, and a location doesn't really need that much >> in the way of configuring. >> >> 2. Create a new map: Ok, direct or indirect? which is the more common, >> and which is the corner case? I'm guessing that direct is the more >> common, but the docs are not helpful: > > It is not a question of common vs uncommon, they are used for > different purposes. > >> >> automountmap-add AUTOMOUNTLOCATION MAP [options] >> >> and no automount specific options are listed, besides description. > > There are no options. When you add a map you just specify the name and > the location: > > ipa automountlocation-add baltimore > ipa automountmap-add baltimore auto.share > ipa automountkey-add baltimore auto.share --key=man > --info="-ro,soft,rsize=8192,wsize=8192 ipa.example.com:/shared/man" > > For a direct map: > > ipa automountkey-add baltimore auto.direct --key=/stuff > --info="-ro,soft,rsize=8192,wsize=8192 ipa.example.com:/h/stuff" > >> >> >> add indirect map is a little more expressive: >> >> --mount=STR Mount point >> --parentmap=STR Name of parent automount map (default: auto.master). >> >> >> I tried running this command and both of these are required parameters, >> although they are not annotated as such. >> >> Is it true that only an indirect map has a mount point? > > Both have mount points, they are just specified differently. > > A direct map lists an exact place to mount the map (/usr/local/bin, > /mnt, whatever). An indirect map defines a bucket to drop mounts into. > So it might point to /share and all keys for that are relative to > that. So you define a key ayoung, the map would be /share/ayoung. Then, basically, a direct map is a degerenate case of an indirect map, with an implied 'mount point' of '/' ? It really isn't a mount point, is it, more like "map home dir"? > >> >> Moving on to Keys: >> >> automountkey-add AUTOMOUNTLOCATION AUTOMOUNTMAP [options] >> --key=IA5STR Automount key name. >> --info=IA5STR Mount information >> >> Not too bad. That is pretty clear. >> >> The step by step here looks better. >> https://fedoraproject.org/wiki/QA:Testcase_freeipav2_automount >> >> >> Anyone that understands this care to illuminate me? >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > From rcritten at redhat.com Tue Apr 5 21:31:55 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Apr 2011 17:31:55 -0400 Subject: [Freeipa-devel] [PATCH] 766 make postalcode a string Message-ID: <4D9B8A4B.5080408@redhat.com> postalCode should be a string not an integer. postalCode is defined as an Int. This means you can't define one that has a leading zero nor can you have dashes, letters, etc. This changes the data type on the server. It will still accept an int value if provided and convert it into a string. ticket 1150 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-766-zipcode.patch Type: application/mbox Size: 6541 bytes Desc: not available URL: From ayoung at redhat.com Tue Apr 5 21:56:59 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 05 Apr 2011 17:56:59 -0400 Subject: [Freeipa-devel] [PATCH] 766 make postalcode a string In-Reply-To: <4D9B8A4B.5080408@redhat.com> References: <4D9B8A4B.5080408@redhat.com> Message-ID: <4D9B902B.0@redhat.com> On 04/05/2011 05:31 PM, Rob Crittenden wrote: > postalCode should be a string not an integer. > > postalCode is defined as an Int. This means you can't define one that > has a leading zero nor can you have dashes, letters, etc. > > This changes the data type on the server. It will still accept an int > value if provided and convert it into a string. > > ticket 1150 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. Tested from CLI and WebUI -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 5 22:03:02 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Apr 2011 18:03:02 -0400 Subject: [Freeipa-devel] [PATCH] 766 make postalcode a string In-Reply-To: <4D9B902B.0@redhat.com> References: <4D9B8A4B.5080408@redhat.com> <4D9B902B.0@redhat.com> Message-ID: <4D9B9196.3000908@redhat.com> Adam Young wrote: > On 04/05/2011 05:31 PM, Rob Crittenden wrote: >> postalCode should be a string not an integer. >> >> postalCode is defined as an Int. This means you can't define one that >> has a leading zero nor can you have dashes, letters, etc. >> >> This changes the data type on the server. It will still accept an int >> value if provided and convert it into a string. >> >> ticket 1150 >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK. > > Tested from CLI and WebUI Endi asked that I bump the minor API version so I've done that. A minor version change means it is backwards compatible. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-766-2-zipcode.patch Type: application/mbox Size: 6950 bytes Desc: not available URL: From edewata at redhat.com Tue Apr 5 23:16:47 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 05 Apr 2011 18:16:47 -0500 Subject: [Freeipa-devel] [PATCH] 766 make postalcode a string In-Reply-To: <4D9B9196.3000908@redhat.com> References: <4D9B8A4B.5080408@redhat.com> <4D9B902B.0@redhat.com> <4D9B9196.3000908@redhat.com> Message-ID: <4D9BA2DF.9060009@redhat.com> On 4/5/2011 5:03 PM, Rob Crittenden wrote: >>> postalCode should be a string not an integer. >>> >>> postalCode is defined as an Int. This means you can't define one that >>> has a leading zero nor can you have dashes, letters, etc. >>> >>> This changes the data type on the server. It will still accept an int >>> value if provided and convert it into a string. >>> >>> ticket 1150 >> Tested from CLI and WebUI > > Endi asked that I bump the minor API version so I've done that. A minor > version change means it is backwards compatible. ACK. I verified with an old client (GA build on FC15) against new server on F14 with this patch. The old client will still have the same problem adding the zipcode, but it can see new string zipcode added by new client correctly. New clients won't see this problem. -- Endi S. Dewata From rcritten at redhat.com Wed Apr 6 01:58:38 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Apr 2011 21:58:38 -0400 Subject: [Freeipa-devel] [PATCH] 766 make postalcode a string In-Reply-To: <4D9BA2DF.9060009@redhat.com> References: <4D9B8A4B.5080408@redhat.com> <4D9B902B.0@redhat.com> <4D9B9196.3000908@redhat.com> <4D9BA2DF.9060009@redhat.com> Message-ID: <4D9BC8CE.2040808@redhat.com> Endi Sukma Dewata wrote: > On 4/5/2011 5:03 PM, Rob Crittenden wrote: >>>> postalCode should be a string not an integer. >>>> >>>> postalCode is defined as an Int. This means you can't define one that >>>> has a leading zero nor can you have dashes, letters, etc. >>>> >>>> This changes the data type on the server. It will still accept an int >>>> value if provided and convert it into a string. >>>> >>>> ticket 1150 > >>> Tested from CLI and WebUI >> >> Endi asked that I bump the minor API version so I've done that. A minor >> version change means it is backwards compatible. > > ACK. I verified with an old client (GA build on FC15) against new server > on F14 with this patch. The old client will still have the same problem > adding the zipcode, but it can see new string zipcode added by new > client correctly. New clients won't see this problem. > pushed to master and ipa-2-0 From rcritten at redhat.com Wed Apr 6 01:58:59 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Apr 2011 21:58:59 -0400 Subject: [Freeipa-devel] [PATCH] 765 update schema In-Reply-To: <4D9B835A.7070207@redhat.com> References: <4D9B7BE7.6070103@redhat.com> <4D9B8174.1040204@redhat.com> <4D9B835A.7070207@redhat.com> Message-ID: <4D9BC8E3.3030608@redhat.com> Rich Megginson wrote: > On 04/05/2011 02:54 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Fix ORDERING in some attributetypes and remove other unnecessary >>> elements. >>> >>> Looking at the schema in 60basev2.ldif there were many attributes that >>> did not have an ORDERING matching rule specified correctly. There were >>> also a number of attributeTypes that should have been just SUP >>> distinguishedName that had a combination of SUP, SYNTAX, ORDERING, etc. >>> >>> This requires 389-ds-base-1.2.8.0-1+ >>> >>> ticket 1153 >>> >>> rob >> >> I forgot to include 2 changes: >> >> - Don't do deletes when modifying schema, it will fail. Doing an ADD >> will replace existing schema. >> - Request attributeTypes and objectClasses when retrieving entries. >> >> rob > ack Endi also tested and acked in IRC pushed to master and ipa-2-0 From pzuna at redhat.com Wed Apr 6 15:08:58 2011 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 06 Apr 2011 17:08:58 +0200 Subject: [Freeipa-devel] [PATCH] Validate/Normalize user attributes if set using krbtpolicy set/add-attr. Message-ID: <4D9C820A.4000201@redhat.com> Ticket #744 Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pzuna-89-validatekrbt.patch Type: application/mbox Size: 2575 bytes Desc: not available URL: From pzuna at redhat.com Thu Apr 7 13:43:11 2011 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 07 Apr 2011 15:43:11 +0200 Subject: [Freeipa-devel] [PATCH] Validate/Normalize user attributes if set using krbtpolicy set/add-attr. In-Reply-To: <4D9C820A.4000201@redhat.com> References: <4D9C820A.4000201@redhat.com> Message-ID: <4D9DBF6F.1030702@redhat.com> On 04/06/2011 05:08 PM, Pavel Zuna wrote: > Ticket #744 > > Pavel > New fixed version of patch attached. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pzuna-89-2-validatekrbt.patch Type: text/x-patch Size: 2589 bytes Desc: not available URL: From jcholast at redhat.com Thu Apr 7 15:00:24 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 07 Apr 2011 17:00:24 +0200 Subject: [Freeipa-devel] [PATCH] 6 Add lint script for static code analysis Message-ID: <4D9DD188.6080704@redhat.com> This patch adds a script based on pylint for static code analysis during build. https://fedorahosted.org/freeipa/ticket/867 -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-6-lint-script.patch Type: text/x-patch Size: 6937 bytes Desc: not available URL: From jcholast at redhat.com Thu Apr 7 15:03:38 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 07 Apr 2011 17:03:38 +0200 Subject: [Freeipa-devel] [PATCH] Fix lint false positives Message-ID: <4D9DD24A.6000802@redhat.com> Added changes to the code necesarry for removal of false positives reported by the lint script (see my previous patch). -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-7-lint-false-positives.patch Type: text/x-patch Size: 9067 bytes Desc: not available URL: From jcholast at redhat.com Thu Apr 7 15:28:14 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 07 Apr 2011 17:28:14 +0200 Subject: [Freeipa-devel] [PATCH] 8 Fix typo in ipa-server-install Message-ID: <4D9DD80E.6040701@redhat.com> Fixed typo in ipa-server-install. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-8-ipa-server-install-typo.patch Type: text/x-patch Size: 915 bytes Desc: not available URL: From JR.Aquino at citrix.com Thu Apr 7 22:42:09 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 7 Apr 2011 22:42:09 +0000 Subject: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership In-Reply-To: References: <4D94E88C.2090004@redhat.com> Message-ID: <934AB894-09AC-425A-92BD-9BA0B236A21D@citrixonline.com> On Mar 31, 2011, at 2:16 PM, JR Aquino wrote: > On Mar 31, 2011, at 1:48 PM, Rob Crittenden wrote: > >> JR Aquino wrote: >>> The following patch Removes around 20 lines of code and provides a substantial increase in performance for FreeIPA member/memberof verification searches. >>> >>> The current code base blindly searches static containers for the possible presence of members. >>> >>> This patch provides a method for dynamically identifying the specific objects to verify memberships for. >>> >>> The attached patch addresses ticket: >>> https://fedorahosted.org/freeipa/ticket/1139 >>> >>> >>> >>> ipa hostgroup-find >>> >>> ... >>> >>> ----------------------------- >>> Number of entries returned 52 >>> ----------------------------- >>> >>> real 0m20.054s >>> user 0m0.934s >>> sys 0m0.050s >>> >>> >>> ipa find-hostgroup >>> >>> ... >>> >>> ----------------------------- >>> Number of entries returned 52 >>> ----------------------------- >>> >>> real 0m15.064s >>> user 0m0.945s >>> sys 0m0.057s >>> >>> >>> ------------------------------ >>> Number of entries returned 100 >>> ------------------------------ >>> >>> real 0m16.471s >>> user 0m0.814s >>> sys 0m0.040s >>> >>> >>> ipa host-find >>> >>> ... >>> >>> ------------------------------ >>> Number of entries returned 100 >>> ------------------------------ >>> >>> real 0m41.277s >>> user 0m0.806s >>> sys 0m0.060s >>> >>> >>> ipa host-find >>> >>> ... >>> >>> ------------------------------ >>> Number of entries returned 100 >>> ------------------------------ >>> >>> real 0m16.385s >>> user 0m0.814s >>> sys 0m0.053s >> >> There is a typo in the first block, memeber. >> >> Wouldn't it be clearer to do a negative test to continue: >> >> if not 'member' in r[1]: >> continue >> >> rob > > You're right! > > Corrected patch attached. Self Nack After cli and webui testing, it turned out there was a previous try / except block that was reseting the results value back to [] Corrected and reattaching new patch. Testing cli and webui checks out correctly. Speed AND accuracy are now addressed. It was also discovered during the course of testing that this patch addresses one of the causes for the bug thrown in: https://fedorahosted.org/freeipa/ticket/1133 -JR -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch Type: application/octet-stream Size: 5461 bytes Desc: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch URL: From JR.Aquino at citrix.com Thu Apr 7 23:04:07 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 7 Apr 2011 23:04:07 +0000 Subject: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership In-Reply-To: <934AB894-09AC-425A-92BD-9BA0B236A21D@citrixonline.com> References: <4D94E88C.2090004@redhat.com> <934AB894-09AC-425A-92BD-9BA0B236A21D@citrixonline.com> Message-ID: On Apr 7, 2011, at 3:42 PM, JR Aquino wrote: > On Mar 31, 2011, at 2:16 PM, JR Aquino wrote: > >> On Mar 31, 2011, at 1:48 PM, Rob Crittenden wrote: >> >>> JR Aquino wrote: >>>> The following patch Removes around 20 lines of code and provides a substantial increase in performance for FreeIPA member/memberof verification searches. >>>> >>>> The current code base blindly searches static containers for the possible presence of members. >>>> >>>> This patch provides a method for dynamically identifying the specific objects to verify memberships for. >>>> >>>> The attached patch addresses ticket: >>>> https://fedorahosted.org/freeipa/ticket/1139 >>>> >>>> >>>> >>>> ipa hostgroup-find >>>> >>>> ... >>>> >>>> ----------------------------- >>>> Number of entries returned 52 >>>> ----------------------------- >>>> >>>> real 0m20.054s >>>> user 0m0.934s >>>> sys 0m0.050s >>>> >>>> >>>> ipa find-hostgroup >>>> >>>> ... >>>> >>>> ----------------------------- >>>> Number of entries returned 52 >>>> ----------------------------- >>>> >>>> real 0m15.064s >>>> user 0m0.945s >>>> sys 0m0.057s >>>> >>>> >>>> ------------------------------ >>>> Number of entries returned 100 >>>> ------------------------------ >>>> >>>> real 0m16.471s >>>> user 0m0.814s >>>> sys 0m0.040s >>>> >>>> >>>> ipa host-find >>>> >>>> ... >>>> >>>> ------------------------------ >>>> Number of entries returned 100 >>>> ------------------------------ >>>> >>>> real 0m41.277s >>>> user 0m0.806s >>>> sys 0m0.060s >>>> >>>> >>>> ipa host-find >>>> >>>> ... >>>> >>>> ------------------------------ >>>> Number of entries returned 100 >>>> ------------------------------ >>>> >>>> real 0m16.385s >>>> user 0m0.814s >>>> sys 0m0.053s >>> >>> There is a typo in the first block, memeber. >>> >>> Wouldn't it be clearer to do a negative test to continue: >>> >>> if not 'member' in r[1]: >>> continue >>> >>> rob >> >> You're right! >> >> Corrected patch attached. > > Self Nack > > After cli and webui testing, it turned out there was a previous try / except block that was reseting the results value back to [] > > Corrected and reattaching new patch. > > Testing cli and webui checks out correctly. Speed AND accuracy are now addressed. > > It was also discovered during the course of testing that this patch addresses one of the causes for the bug thrown in: https://fedorahosted.org/freeipa/ticket/1133 > > -JR NACK Looks like there may still need to be work with the indirect / direct functions. Will revisit next week. From JR.Aquino at citrix.com Fri Apr 8 02:08:56 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 8 Apr 2011 02:08:56 +0000 Subject: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership In-Reply-To: References: <4D94E88C.2090004@redhat.com> <934AB894-09AC-425A-92BD-9BA0B236A21D@citrixonline.com> Message-ID: <8CE5CB9F-4C26-416A-88B4-9EF9B5CB321D@citrixonline.com> On Apr 7, 2011, at 4:04 PM, JR Aquino wrote: > On Apr 7, 2011, at 3:42 PM, JR Aquino wrote: > >> On Mar 31, 2011, at 2:16 PM, JR Aquino wrote: >> >>> On Mar 31, 2011, at 1:48 PM, Rob Crittenden wrote: >>> >>>> JR Aquino wrote: >>>>> The following patch Removes around 20 lines of code and provides a substantial increase in performance for FreeIPA member/memberof verification searches. >>>>> >>>>> The current code base blindly searches static containers for the possible presence of members. >>>>> >>>>> This patch provides a method for dynamically identifying the specific objects to verify memberships for. >>>>> >>>>> The attached patch addresses ticket: >>>>> https://fedorahosted.org/freeipa/ticket/1139 >>>>> >>>>> >>>>> >>>>> ipa hostgroup-find >>>>> >>>>> ... >>>>> >>>>> ----------------------------- >>>>> Number of entries returned 52 >>>>> ----------------------------- >>>>> >>>>> real 0m20.054s >>>>> user 0m0.934s >>>>> sys 0m0.050s >>>>> >>>>> >>>>> ipa find-hostgroup >>>>> >>>>> ... >>>>> >>>>> ----------------------------- >>>>> Number of entries returned 52 >>>>> ----------------------------- >>>>> >>>>> real 0m15.064s >>>>> user 0m0.945s >>>>> sys 0m0.057s >>>>> >>>>> >>>>> ------------------------------ >>>>> Number of entries returned 100 >>>>> ------------------------------ >>>>> >>>>> real 0m16.471s >>>>> user 0m0.814s >>>>> sys 0m0.040s >>>>> >>>>> >>>>> ipa host-find >>>>> >>>>> ... >>>>> >>>>> ------------------------------ >>>>> Number of entries returned 100 >>>>> ------------------------------ >>>>> >>>>> real 0m41.277s >>>>> user 0m0.806s >>>>> sys 0m0.060s >>>>> >>>>> >>>>> ipa host-find >>>>> >>>>> ... >>>>> >>>>> ------------------------------ >>>>> Number of entries returned 100 >>>>> ------------------------------ >>>>> >>>>> real 0m16.385s >>>>> user 0m0.814s >>>>> sys 0m0.053s >>>> >>>> There is a typo in the first block, memeber. >>>> >>>> Wouldn't it be clearer to do a negative test to continue: >>>> >>>> if not 'member' in r[1]: >>>> continue >>>> >>>> rob >>> >>> You're right! >>> >>> Corrected patch attached. >> >> Self Nack >> >> After cli and webui testing, it turned out there was a previous try / except block that was reseting the results value back to [] >> >> Corrected and reattaching new patch. >> >> Testing cli and webui checks out correctly. Speed AND accuracy are now addressed. >> >> It was also discovered during the course of testing that this patch addresses one of the causes for the bug thrown in: https://fedorahosted.org/freeipa/ticket/1133 >> >> -JR > > NACK > > Looks like there may still need to be work with the indirect / direct functions. > > Will revisit next week. Ok I finally think I've got it. My for loop was in my try / except block. It has now been corrected. I've tested the searches for: users, groups, sudocmds, sudcmdgroups, sudorules, hosts, hostgroups, hbacrules, hbacsv, hbsvcgroups, and all return as expected. Please make sure that they return for you as well. Please let me know if there is anything else I have missed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch Type: application/octet-stream Size: 5575 bytes Desc: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch URL: From mkosek at redhat.com Fri Apr 8 13:31:47 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 08 Apr 2011 15:31:47 +0200 Subject: [Freeipa-devel] [PATCH] 8 Fix typo in ipa-server-install In-Reply-To: <4D9DD80E.6040701@redhat.com> References: <4D9DD80E.6040701@redhat.com> Message-ID: <1302269507.31677.0.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-07 at 17:28 +0200, Jan Cholasta wrote: > Fixed typo in ipa-server-install. > ACK, pushed to master,ipa-2-0 Martin From rcritten at redhat.com Fri Apr 8 14:22:24 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 10:22:24 -0400 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage Message-ID: <4D9F1A20.30303@redhat.com> ipa-nis-manage was failing because root has very limited capabilities when binding over ldapi because of autobind. So don't use ldapi. Also force this to be run as root since we start/stop and configure/unconfigure services. ticket 1157 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-767-nis.patch Type: application/mbox Size: 2716 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 8 14:24:08 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 10:24:08 -0400 Subject: [Freeipa-devel] [PATCH] 768 fix migration between v2 servers Message-ID: <4D9F1A88.3030204@redhat.com> Migration from a v2 server would fail because of our fake memberofindirect attribute. This isn't in any objectclass so would cause entries to fail to migrate. We can safely just remove it. Also remove any limits on time/size when searching for entries on the remote server. Otherwise only the number of entries configured in the local IPA server can be migrated. ticket 1124 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-768-migrate.patch Type: application/mbox Size: 3545 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 8 14:26:02 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 10:26:02 -0400 Subject: [Freeipa-devel] [PATCH] 3 Add ability to specify netmask with IP addresses during installation In-Reply-To: <4D930AAD.9020209@redhat.com> References: <4D9068E5.6090209@redhat.com> <4D90920E.3080900@redhat.com> <4D91DD15.8020109@redhat.com> <4D91DDA6.2060304@redhat.com> <4D923DCA.1030900@redhat.com> <4D930AAD.9020209@redhat.com> Message-ID: <4D9F1AFA.8000305@redhat.com> Jan Cholasta wrote: > On 29.3.2011 22:15, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Sorry, forgot to attach the patch. >>> >> >> Is this why you have some blind excepts? >> >> installutils._IPAddressWithPrefix('192.168.0.1/33') >> Traceback (most recent call last): >> File "", line 1, in >> File "ipaserver/install/installutils.py", line 167, in __init__ >> net = netaddr.IPNetwork(addr) >> File "/usr/lib/python2.7/site-packages/netaddr/ip/__init__.py", line >> 919, in __init__ >> implicit_prefix, flags) >> File "/usr/lib/python2.7/site-packages/netaddr/ip/__init__.py", line >> 782, in parse_ip_network >> value = ip._value >> UnboundLocalError: local variable 'ip' referenced before assignment >> >> We should get an upstream bug filed on python-netaddr about this. > > https://github.com/drkjam/netaddr/issues/closed#issue/5 > https://github.com/drkjam/netaddr/issues/closed#issue/6 > https://github.com/drkjam/netaddr/issues/closed#issue/8 > > Apparently it's already been fixed for the next release. > > IMHO it's not much of an issue for us, because the exception gets caught > in parse_ip_address and that's currently the only place where > _IPAddressWithPrefix is used. > >> >> Shoudl parse_ip_address() raise an exception on bad data rather than >> returning 0.0.0.0? > > I've been down that road and it would need a rewrite of the fragile IP > address handling logic of ipa-server-install, which is something I'd > rather avoid. > >> >> >>> installutils.parse_ip_address('355.555.3.3') >> _IPAddressWithPrefix('0.0.0.0') >> >> or >> >> >>> installutils.parse_ip_address('192.168.0.1/55') >> _IPAddressWithPrefix('0.0.0.0') >> >> Should it disallow net addresses like 192.168.0.0? > > If you mean network and broadcast addresses, it probably should. It > might be a good idea to disallow localhost, multicast and/or link-local > addresses too. Are you going to resubmit the patch with these added or should we open a separate ticket? rob From rcritten at redhat.com Fri Apr 8 14:29:44 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 10:29:44 -0400 Subject: [Freeipa-devel] [PATCH] 042 Password policy commands do not include cospriority In-Reply-To: <1301903472.2932.10.camel@dhcp-25-52.brq.redhat.com> References: <1301326584.3592.10.camel@dhcp-25-52.brq.redhat.com> <4D961089.70701@redhat.com> <1301903472.2932.10.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4D9F1BD8.5050702@redhat.com> Martin Kosek wrote: > On Fri, 2011-04-01 at 13:51 -0400, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Target branches: master, ipa-2-0 >>> --- >>> >>> Most of the pwpolicy_* commands do include cospriority in the result >>> and potentially in the attribute rights (--all --rights). Especially >>> when --raw output is requested. This patch fixes it for all >>> pwpolicy commands. >>> >>> https://fedorahosted.org/freeipa/ticket/1103 >>> >> >> nack. I see a couple of problems. >> >> You should test for rights before doing the cosentry_show(). If rights >> is False then we won't add the data whatever it is so it is more >> efficient to exit earlier. > > We have to call cosentry_show every time (except for the case when we > pull data for the global policy) because we read cospriority attribute. > But the function was indeed not efficient (it called cosentry_show > twice), I rewrote it. > >> >> Same with pwpolicy_name == global_policy_name. I think you should drop >> the try/except and make it: >> >> if not rights or pwpolicy_name == global_policy_name: >> return >> >> ... >> >> It should never be the case that the cosentry is not found so I'd let it >> fail if that does occur. > > Fixed. > >> >> I think that keys[-1] can be None so be aware. > > Fixed. > >> >> You hardcode rights == False in pwpolicy_find(), a good thing. I think >> you should add make it explict rights=False and add a comment explaining >> that you can't get accessrights with a find. > > Fixed. > > Fixed patch attached. > > Martin Looks great, ack. rob From rcritten at redhat.com Fri Apr 8 14:32:25 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 10:32:25 -0400 Subject: [Freeipa-devel] [PATCH] 760 don't crash when calculating indirect In-Reply-To: <1301570541.25947.25.camel@dhcp-25-52.brq.redhat.com> References: <4D934146.6020706@redhat.com> <4D93423D.4040607@redhat.com> <1301570541.25947.25.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4D9F1C79.6000302@redhat.com> Martin Kosek wrote: > On Wed, 2011-03-30 at 10:46 -0400, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> This prevents an internal error when calculating direct vs indirect >>> membership. >>> >>> ticket 1133 >>> >> >> I accidentally included a change from another patch. Updated patch attached. >> >> rob > > I think it is OK. But I would suggest adding some comment to the code - > a reason why we pass the ValueError exception. It may not be > self-explanatory when we return to this code in the future. > > Martin I'm withdrawing this patch. It seems to be covering up for a real problem. JR is doing further investigation. rob From JR.Aquino at citrix.com Fri Apr 8 14:54:31 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 8 Apr 2011 14:54:31 +0000 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: <4D9F1A20.30303@redhat.com> References: <4D9F1A20.30303@redhat.com> Message-ID: <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> Does this imply the use of ldap with tls now or just standard ldap? There was a previous ticket that changed this and many other tools such that they used ldapi to accommodate FreeIPA with a minssf set. On Apr 8, 2011, at 7:24 AM, "Rob Crittenden" wrote: > ipa-nis-manage was failing because root has very limited capabilities when binding over ldapi because of autobind. So don't use ldapi. > > Also force this to be run as root since we start/stop and configure/unconfigure services. > > ticket 1157 > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Fri Apr 8 15:01:30 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 11:01:30 -0400 Subject: [Freeipa-devel] [PATCH] 22 Add memberHost and memberUser to default indexes In-Reply-To: <4D962D7F.6050204@redhat.com> References: <4D960ACE.6070602@redhat.com> <4D961423.7010009@redhat.com> <4D962D7F.6050204@redhat.com> Message-ID: <4D9F234A.8060702@redhat.com> Dmitri Pal wrote: > On 04/01/2011 02:06 PM, Rich Megginson wrote: >> On 04/01/2011 11:26 AM, Rob Crittenden wrote: >>> JR Aquino wrote: >>>> On Mar 30, 2011, at 1:16 PM, JR Aquino wrote: >>>> >>>>> The plugin architecture makes a great deal of calls to search for >>>>> memberUser and memberHost. These attributes are missing from the >>>>> index and are greatly slowing down the CLI and WebUI. >>>>> >>>>> They should be added as Equality Indexes, as the searches that are >>>>> performed are meant for enumeration after the exact value is known. >>>>> >>>>> _______________________________________________ >>>>> >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> Missed some trailing whitespace. >>>> >>>> Corrected patch attached. >>> >>> After loading this the 389-ds error logs spit out: >>> >>> [01/Apr/2011:13:26:01 -0400] - The attribute [memberHost] does not >>> have a valid ORDERING matching rule - error 2:s >>> [01/Apr/2011:13:26:01 -0400] - The attribute [memberUser] does not >>> have a valid ORDERING matching rule - error 2:s >> Looking at the schema in 60basev2.ldif - it looks as though there are >> many attributes that do not have an ORDERING matching rule specified >> correctly: >> attributeTypes: (2.16.840.1.113730.3.8.3.5 NAME 'memberUser' DESC >> 'Reference to a principal that performs an action (usually user).' SUP >> distinguishedName EQUALITY distinguishedNameMatch ORDERING >> distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX >> 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) >> attributeTypes: (2.16.840.1.113730.3.8.3.7 NAME 'memberHost' DESC >> 'Reference to a device where the operation takes place (usually >> host).' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING >> distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX >> 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' ) >> >> 1.3.6.1.4.1.1466.115.121.1.12 is DN syntax - there is no ORDERING >> matching rule for DN syntax - is there some reason you want to be able >> to do range searches on DN values? >> > I thought that ordering is used for the sorting. If you sort things by > an attribute. > I suspect that there are cases when it makes sense to sort the result > set by DN. > I think HBAC is one of those. But if ordering is not something that > should be used in this case then what shoud? > >> attributeTypes: (2.16.840.1.113730.3.8.3.8 NAME 'hostCategory' DESC >> 'Additional classification for hosts' EQUALITY caseIgnoreMatch >> ORDERING caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX >> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' ) >> >> This should be ORDERING caseIgnoreOrderingMatch - looks like there may >> be more of these too. > > > This is probably an artifact of me defineing the schema 2 years ago. > Can you please file a BZ and a ticket. > IMO we should fix the schema inconsistencies ASAP. > Please review the rest of the defined attributes and make sure there are > no problems like this. > >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > The IPA schema is more sane now, this patch does the right thing. ack, pushed to master and ipa-2-0 rob From JR.Aquino at citrix.com Fri Apr 8 15:01:38 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 8 Apr 2011 15:01:38 +0000 Subject: [Freeipa-devel] [PATCH] 760 don't crash when calculating indirect In-Reply-To: <4D9F1C79.6000302@redhat.com> References: <4D934146.6020706@redhat.com> <4D93423D.4040607@redhat.com> <1301570541.25947.25.camel@dhcp-25-52.brq.redhat.com> <4D9F1C79.6000302@redhat.com> Message-ID: <64554891-D6EC-4152-9522-5F2228F8138C@citrixonline.com> On Apr 8, 2011, at 7:32 AM, Rob Crittenden wrote: Martin Kosek wrote: On Wed, 2011-03-30 at 10:46 -0400, Rob Crittenden wrote: Rob Crittenden wrote: This prevents an internal error when calculating direct vs indirect membership. ticket 1133 I accidentally included a change from another patch. Updated patch attached. rob I think it is OK. But I would suggest adding some comment to the code - a reason why we pass the ValueError exception. It may not be self-explanatory when we return to this code in the future. Martin I'm withdrawing this patch. It seems to be covering up for a real problem. JR is doing further investigation. rob Yes, I believe I have identified the root cause of the crashes, and I believe they should be addressed by my patch for https://fedorahosted.org/freeipa/ticket/1139 My patch ensures that only the groups for which a member is a part of, will be searched to determine the object's direct or indirect membership. The only time this should throw an exception after the fix for 1139, should be if the memberOf plugin has failed to provide referential integrity. From rcritten at redhat.com Fri Apr 8 15:03:31 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 11:03:31 -0400 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> References: <4D9F1A20.30303@redhat.com> <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> Message-ID: <4D9F23C3.6020902@redhat.com> JR Aquino wrote: > Does this imply the use of ldap with tls now or just standard ldap? > > There was a previous ticket that changed this and many other tools such that they used ldapi to accommodate FreeIPA with a minssf set. It uses 389, no TLS. rob > > On Apr 8, 2011, at 7:24 AM, "Rob Crittenden" wrote: > >> ipa-nis-manage was failing because root has very limited capabilities when binding over ldapi because of autobind. So don't use ldapi. >> >> Also force this to be run as root since we start/stop and configure/unconfigure services. >> >> ticket 1157 >> >> rob >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel From JR.Aquino at citrix.com Fri Apr 8 15:09:31 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 8 Apr 2011 15:09:31 +0000 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: <4D9F23C3.6020902@redhat.com> References: <4D9F1A20.30303@redhat.com> <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> <4D9F23C3.6020902@redhat.com> Message-ID: On Apr 8, 2011, at 8:03 AM, Rob Crittenden wrote: >> On Apr 8, 2011, at 7:24 AM, "Rob Crittenden" wrote: >> >>> ipa-nis-manage was failing because root has very limited capabilities when binding over ldapi because of autobind. So don't use ldapi. >>> >>> Also force this to be run as root since we start/stop and configure/unconfigure services. >>> >>> ticket 1157 >>> >>> rob >>> > JR Aquino wrote: >> Does this imply the use of ldap with tls now or just standard ldap? >> >> There was a previous ticket that changed this and many other tools such that they used ldapi to accommodate FreeIPA with a minssf set. > > It uses 389, no TLS. > > rob Is there a way to solve both problems? #1 Autobind limits root -> ldapi #2 IPA Tools should not fail when 389ds:dse.ldif has minssf set? -Fixed the top posting. sorry about that.- From pzuna at redhat.com Fri Apr 8 15:49:08 2011 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 08 Apr 2011 17:49:08 +0200 Subject: [Freeipa-devel] [PATCH] Add a new user-add flag param to disable the creation of UPG. In-Reply-To: <20110404094704.62bdc75f@willson.li.ssimo.org> References: <4D90F1C7.1090909@redhat.com> <4D91099F.8070400@redhat.com> <4D910B62.4060900@redhat.com> <20110404094704.62bdc75f@willson.li.ssimo.org> Message-ID: <4D9F2E74.9010701@redhat.com> On 04/04/2011 03:47 PM, Simo Sorce wrote: > On Mon, 28 Mar 2011 15:27:46 -0700 > Nathan Kinder wrote: > >> On 03/28/2011 03:20 PM, Dmitri Pal wrote: >>> On 03/28/2011 04:38 PM, Pavel Z?na wrote: >>>> This patch handles the issue in a kind of stupid way, but I >>>> couldn't think of anything better. >>>> >>>> It adds a new flag parameter to user-add (--noprivate). With this >>>> flag, the command marks the private group about to be created for >>>> deletion and is deleted after the user is created. The only >>>> exception is when there is a group, that is named the same way as >>>> the user, but isn't a private group - then the group is left there. >>>> >>>> Private groups are created automatically by the managed entry DS >>>> plugin and I didn't find a way to disable its creation for a >>>> specific user. >>> >>> The idea that comes to mind is to define some magical attribute >>> that the DS plugin would recognize and skip the creation of the >>> managed entry as well as strip the entry of this magic >>> attribute/value. I remember that other plugins might take advantage >>> of the similar approach. >>> >>> Is something like this possible? >> You are probably thinking of the DNA plug-in and it's use of a magic >> value used to tell the plug-in to allocate a value from a range. I >> would not like to use this approach here, as it requires additional >> coding and complexity that I don't think is needed. >> >> I would prefer that we use the originFilter to deal with this. We >> could have an auxiliary objectclass that IPA usually adds when >> creating an IPA user. The originFilter can key off of this >> objectclass to create managed groups. When a user is added with the >> --noprivate option, this objectclass is not included in the user >> entry that is added. Rob and I discussed this approach on IRC >> earlier today. > > Ack, this sounds like a better approach, although it doesn't > necessarily need to be an objectclass it can also be an attribute with > a specific value that is checked in the filter as (!(attrib=value)) > > Simo. > New patch with new approach attached. It sets the checked filter to: (&(objectclass=posixAccount)(!(description=__no_upg__))) If a user entry is created with the description attribute equal to the string "__no_upg__", the DS plugin will not trigger and no UPG is going to be created. After this patch, the user-add plugin adds this description attribute (NO_UPG_MAGIC = "__no_upg__") in the pre_callback and deletes it in the post_callback if necessary. I think the description attribute is the best choice, because it's part of the posixAccount objectClass and we don't use it for anything on user entries. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pzuna-88-2-noprivate.patch Type: text/x-patch Size: 5168 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 8 15:50:09 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 11:50:09 -0400 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: References: <4D9F1A20.30303@redhat.com> <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> <4D9F23C3.6020902@redhat.com> Message-ID: <4D9F2EB1.3040907@redhat.com> JR Aquino wrote: > > On Apr 8, 2011, at 8:03 AM, Rob Crittenden wrote: > >>> On Apr 8, 2011, at 7:24 AM, "Rob Crittenden" wrote: >>> >>>> ipa-nis-manage was failing because root has very limited capabilities when binding over ldapi because of autobind. So don't use ldapi. >>>> >>>> Also force this to be run as root since we start/stop and configure/unconfigure services. >>>> >>>> ticket 1157 >>>> >>>> rob >>>> > >> JR Aquino wrote: >>> Does this imply the use of ldap with tls now or just standard ldap? >>> >>> There was a previous ticket that changed this and many other tools such that they used ldapi to accommodate FreeIPA with a minssf set. >> >> It uses 389, no TLS. >> >> rob > > Is there a way to solve both problems? > > #1 Autobind limits root -> ldapi > #2 IPA Tools should not fail when 389ds:dse.ldif has minssf set? > > -Fixed the top posting. sorry about that.- Maybe, I also want to apply an appropriate level of effort. In reality this command is going to be run 1 or 2 times in the lifetime of an IPA server. rob From JR.Aquino at citrix.com Fri Apr 8 15:56:23 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 8 Apr 2011 15:56:23 +0000 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: <4D9F2EB1.3040907@redhat.com> References: <4D9F1A20.30303@redhat.com> <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> <4D9F23C3.6020902@redhat.com> <4D9F2EB1.3040907@redhat.com> Message-ID: On Apr 8, 2011, at 8:53 AM, "Rob Crittenden" wrote: > JR Aquino wrote: >> >> On Apr 8, 2011, at 8:03 AM, Rob Crittenden wrote: >> >>>> On Apr 8, 2011, at 7:24 AM, "Rob Crittenden" wrote: >>>> >>>>> ipa-nis-manage was failing because root has very limited capabilities when binding over ldapi because of autobind. So don't use ldapi. >>>>> >>>>> Also force this to be run as root since we start/stop and configure/unconfigure services. >>>>> >>>>> ticket 1157 >>>>> >>>>> rob >>>>> >> >>> JR Aquino wrote: >>>> Does this imply the use of ldap with tls now or just standard ldap? >>>> >>>> There was a previous ticket that changed this and many other tools such that they used ldapi to accommodate FreeIPA with a minssf set. >>> >>> It uses 389, no TLS. >>> >>> rob >> >> Is there a way to solve both problems? >> >> #1 Autobind limits root -> ldapi >> #2 IPA Tools should not fail when 389ds:dse.ldif has minssf set? >> >> -Fixed the top posting. sorry about that.- > > Maybe, I also want to apply an appropriate level of effort. In reality this command is going to be run 1 or 2 times in the lifetime of an IPA server. > > rob Fair enough. The minssf gate should apply to the pieces that have a higher usage frequency. From JR.Aquino at citrix.com Fri Apr 8 16:07:23 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 8 Apr 2011 16:07:23 +0000 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: References: <4D9F1A20.30303@redhat.com> <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> <4D9F23C3.6020902@redhat.com> <4D9F2EB1.3040907@redhat.com> Message-ID: On Apr 8, 2011, at 8:56 AM, "JR Aquino" wrote: > On Apr 8, 2011, at 8:53 AM, "Rob Crittenden" wrote: > >> JR Aquino wrote: >>> >>> On Apr 8, 2011, at 8:03 AM, Rob Crittenden wrote: >>> >>>>> On Apr 8, 2011, at 7:24 AM, "Rob Crittenden" wrote: >>>>> >>>>>> ipa-nis-manage was failing because root has very limited capabilities when binding over ldapi because of autobind. So don't use ldapi. >>>>>> >>>>>> Also force this to be run as root since we start/stop and configure/unconfigure services. >>>>>> >>>>>> ticket 1157 >>>>>> >>>>>> rob >>>>>> >>> >>>> JR Aquino wrote: >>>>> Does this imply the use of ldap with tls now or just standard ldap? >>>>> >>>>> There was a previous ticket that changed this and many other tools such that they used ldapi to accommodate FreeIPA with a minssf set. >>>> >>>> It uses 389, no TLS. >>>> >>>> rob >>> >>> Is there a way to solve both problems? >>> >>> #1 Autobind limits root -> ldapi >>> #2 IPA Tools should not fail when 389ds:dse.ldif has minssf set? >>> >>> -Fixed the top posting. sorry about that.- >> >> Maybe, I also want to apply an appropriate level of effort. In reality this command is going to be run 1 or 2 times in the lifetime of an IPA server. >> >> rob > > Fair enough. The minssf gate should apply to the pieces that have a higher usage frequency. > Does the limitation of autobind with root mean that all of the tools that use ldapi need to be revisited and turned back to 389? From rcritten at redhat.com Fri Apr 8 17:07:26 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 13:07:26 -0400 Subject: [Freeipa-devel] [PATCH] 764 update ipa-client-install man page In-Reply-To: <1301999640.20811.5.camel@dhcp-25-52.brq.redhat.com> References: <4D9A36E3.5010207@redhat.com> <1301999640.20811.5.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4D9F40CE.40103@redhat.com> Martin Kosek wrote: > I don't think it is a good idea to have this option in > ipa-client-install --help at all. > > Since it is not intended to be used by the user and we just use it in > our scripts why would we want to have it in ipa-client-install --help or > man pages? We could just hide it using help=optparse.SUPPRESS_HELP > attribute for the option and document it only in the installation script > source. > > Martin > > On Mon, 2011-04-04 at 17:23 -0400, Rob Crittenden wrote: >> Make it clear that --on-master is for install scripts only. >> >> ticket 1050 An excellent idea. See new patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-764-2-man.patch Type: application/mbox Size: 2928 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 8 17:12:22 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 13:12:22 -0400 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: References: <4D9F1A20.30303@redhat.com> <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> <4D9F23C3.6020902@redhat.com> <4D9F2EB1.3040907@redhat.com> Message-ID: <4D9F41F6.2020504@redhat.com> JR Aquino wrote: > > On Apr 8, 2011, at 8:56 AM, "JR Aquino" wrote: > >> On Apr 8, 2011, at 8:53 AM, "Rob Crittenden" wrote: >> >>> JR Aquino wrote: >>>> >>>> On Apr 8, 2011, at 8:03 AM, Rob Crittenden wrote: >>>> >>>>>> On Apr 8, 2011, at 7:24 AM, "Rob Crittenden" wrote: >>>>>> >>>>>>> ipa-nis-manage was failing because root has very limited capabilities when binding over ldapi because of autobind. So don't use ldapi. >>>>>>> >>>>>>> Also force this to be run as root since we start/stop and configure/unconfigure services. >>>>>>> >>>>>>> ticket 1157 >>>>>>> >>>>>>> rob >>>>>>> >>>> >>>>> JR Aquino wrote: >>>>>> Does this imply the use of ldap with tls now or just standard ldap? >>>>>> >>>>>> There was a previous ticket that changed this and many other tools such that they used ldapi to accommodate FreeIPA with a minssf set. >>>>> >>>>> It uses 389, no TLS. >>>>> >>>>> rob >>>> >>>> Is there a way to solve both problems? >>>> >>>> #1 Autobind limits root -> ldapi >>>> #2 IPA Tools should not fail when 389ds:dse.ldif has minssf set? >>>> >>>> -Fixed the top posting. sorry about that.- >>> >>> Maybe, I also want to apply an appropriate level of effort. In reality this command is going to be run 1 or 2 times in the lifetime of an IPA server. >>> >>> rob >> >> Fair enough. The minssf gate should apply to the pieces that have a higher usage frequency. >> > Does the limitation of autobind with root mean that all of the tools that use ldapi need to be revisited and turned back to 389? ipa-host-net-manage and ipa-compat-manage work ok for me with this patch applied. rob From ssorce at redhat.com Fri Apr 8 18:36:29 2011 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 8 Apr 2011 14:36:29 -0400 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: <4D9F41F6.2020504@redhat.com> References: <4D9F1A20.30303@redhat.com> <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> <4D9F23C3.6020902@redhat.com> <4D9F2EB1.3040907@redhat.com> <4D9F41F6.2020504@redhat.com> Message-ID: <20110408143629.440d18fd@willson.li.ssimo.org> On Fri, 08 Apr 2011 13:12:22 -0400 Rob Crittenden wrote: > JR Aquino wrote: > > Does the limitation of autobind with root mean that all of the > > tools that use ldapi need to be revisited and turned back to 389? > > ipa-host-net-manage and ipa-compat-manage work ok for me with this > patch applied. NACK autobind comes into play only when SASL_EXTERNAL auth is used, the krb5kdc binds as uid=kdc over ldapi w/o any issue. If these tools are having a problem with ldapi, it is most probably an underlying bug in our ldap wrappers, as thyese tools should bind as Directory Manager using simple auth not doing SASL_EXTERNAL auth. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Apr 8 18:42:28 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Apr 2011 14:42:28 -0400 Subject: [Freeipa-devel] [PATCH] 046 Improve DNS PTR record validation In-Reply-To: <1301652399.1997.0.camel@dhcp-25-52.brq.redhat.com> References: <1301652399.1997.0.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4D9F5714.7070508@redhat.com> Martin Kosek wrote: > Current PTR validation is unclear and may misled the user. This > patch improves the validation process so that the eventual exception > is clearer. New check that the PTR record is fully qualified has > been added to ensure that the reverse zone resolution behaves as > expected. > > Additionally, several strings in the DNS plugin were prepared for > localization. > > https://fedorahosted.org/freeipa/ticket/1129 > ack From edewata at redhat.com Fri Apr 8 19:12:35 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 08 Apr 2011 14:12:35 -0500 Subject: [Freeipa-devel] [PATCH] 131 Refactored action panel and client area. Message-ID: <4D9F5E23.40705@redhat.com> To improve code readability and extensibility the containers for action panel and client area are now created in IPA.entity.setup(). The 'client area' has been renamed into 'content'. The IPA.facet.create() has been renamed to IPA.facet.create_content(). -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0131-Refactored-action-panel-and-client-area.patch Type: text/x-patch Size: 11460 bytes Desc: not available URL: From edewata at redhat.com Fri Apr 8 19:13:32 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 08 Apr 2011 14:13:32 -0500 Subject: [Freeipa-devel] [PATCH] 132 Refactored builder interface. Message-ID: <4D9F5E5C.4030504@redhat.com> The IPA.entity_builder has been modified to take a 'factory' parameter in custom facet's and custom dialog's spec. The IPA.dialog has been modified to take an array of fields in the spec. The IPA.search_facet has been modified to take an array of columns in the spec. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0132-Refactored-builder-interface.patch Type: text/x-patch Size: 12911 bytes Desc: not available URL: From edewata at redhat.com Fri Apr 8 19:14:13 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 08 Apr 2011 14:14:13 -0500 Subject: [Freeipa-devel] [PATCH] 133 Refactored search facet. Message-ID: <4D9F5E85.3030708@redhat.com> To simplify customization, the add(), remove(), and refresh() methods have been moved from IPA.search_widget into IPA.search_facet. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0133-Refactored-search-facet.patch Type: text/x-patch Size: 14489 bytes Desc: not available URL: From edewata at redhat.com Fri Apr 8 19:14:56 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 08 Apr 2011 14:14:56 -0500 Subject: [Freeipa-devel] [PATCH] 134 Entitlements. Message-ID: <4D9F5EB0.2050103@redhat.com> Initial implementation of Entitlements. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0134-Entitlements.patch Type: text/x-patch Size: 29008 bytes Desc: not available URL: From edewata at redhat.com Fri Apr 8 19:15:47 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 08 Apr 2011 14:15:47 -0500 Subject: [Freeipa-devel] [PATCH] 135 Updated Selenium tests. Message-ID: <4D9F5EE3.1020207@redhat.com> The Selenium tests have been updated to improve robustness. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0135-Updated-Selenium-tests.patch Type: text/x-patch Size: 109468 bytes Desc: not available URL: From JR.Aquino at citrix.com Sat Apr 9 06:44:02 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Sat, 9 Apr 2011 06:44:02 +0000 Subject: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership In-Reply-To: <8CE5CB9F-4C26-416A-88B4-9EF9B5CB321D@citrixonline.com> References: <4D94E88C.2090004@redhat.com> <934AB894-09AC-425A-92BD-9BA0B236A21D@citrixonline.com> <8CE5CB9F-4C26-416A-88B4-9EF9B5CB321D@citrixonline.com> Message-ID: <69A99C7A-56D1-4FC6-9434-CC470E779A82@citrixonline.com> On Apr 7, 2011, at 7:08 PM, JR Aquino wrote: > > On Apr 7, 2011, at 4:04 PM, JR Aquino wrote: > >> On Apr 7, 2011, at 3:42 PM, JR Aquino wrote: >> >>> On Mar 31, 2011, at 2:16 PM, JR Aquino wrote: >>> >>>> On Mar 31, 2011, at 1:48 PM, Rob Crittenden wrote: >>>> >>>>> JR Aquino wrote: >>>>>> The following patch Removes around 20 lines of code and provides a substantial increase in performance for FreeIPA member/memberof verification searches. >>>>>> >>>>>> The current code base blindly searches static containers for the possible presence of members. >>>>>> >>>>>> This patch provides a method for dynamically identifying the specific objects to verify memberships for. >>>>>> >>>>>> The attached patch addresses ticket: >>>>>> https://fedorahosted.org/freeipa/ticket/1139 >>>>>> >>>>>> >>>>>> >>>>>> ipa hostgroup-find >>>>>> >>>>>> ... >>>>>> >>>>>> ----------------------------- >>>>>> Number of entries returned 52 >>>>>> ----------------------------- >>>>>> >>>>>> real 0m20.054s >>>>>> user 0m0.934s >>>>>> sys 0m0.050s >>>>>> >>>>>> >>>>>> ipa find-hostgroup >>>>>> >>>>>> ... >>>>>> >>>>>> ----------------------------- >>>>>> Number of entries returned 52 >>>>>> ----------------------------- >>>>>> >>>>>> real 0m15.064s >>>>>> user 0m0.945s >>>>>> sys 0m0.057s >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> Number of entries returned 100 >>>>>> ------------------------------ >>>>>> >>>>>> real 0m16.471s >>>>>> user 0m0.814s >>>>>> sys 0m0.040s >>>>>> >>>>>> >>>>>> ipa host-find >>>>>> >>>>>> ... >>>>>> >>>>>> ------------------------------ >>>>>> Number of entries returned 100 >>>>>> ------------------------------ >>>>>> >>>>>> real 0m41.277s >>>>>> user 0m0.806s >>>>>> sys 0m0.060s >>>>>> >>>>>> >>>>>> ipa host-find >>>>>> >>>>>> ... >>>>>> >>>>>> ------------------------------ >>>>>> Number of entries returned 100 >>>>>> ------------------------------ >>>>>> >>>>>> real 0m16.385s >>>>>> user 0m0.814s >>>>>> sys 0m0.053s >>>>> >>>>> There is a typo in the first block, memeber. >>>>> >>>>> Wouldn't it be clearer to do a negative test to continue: >>>>> >>>>> if not 'member' in r[1]: >>>>> continue >>>>> >>>>> rob >>>> >>>> You're right! >>>> >>>> Corrected patch attached. >>> >>> Self Nack >>> >>> After cli and webui testing, it turned out there was a previous try / except block that was reseting the results value back to [] >>> >>> Corrected and reattaching new patch. >>> >>> Testing cli and webui checks out correctly. Speed AND accuracy are now addressed. >>> >>> It was also discovered during the course of testing that this patch addresses one of the causes for the bug thrown in: https://fedorahosted.org/freeipa/ticket/1133 >>> >>> -JR >> >> NACK >> >> Looks like there may still need to be work with the indirect / direct functions. >> >> Will revisit next week. > > Ok I finally think I've got it. > > My for loop was in my try / except block. It has now been corrected. > > I've tested the searches for: users, groups, sudocmds, sudcmdgroups, sudorules, hosts, hostgroups, hbacrules, hbacsv, hbsvcgroups, and all return as expected. > > Please make sure that they return for you as well. > Please let me know if there is anything else I have missed. Final Patch attached due to relationship with ticket 1133: Added Comments regarding Ticket 1133 / calculating indirect: + # If there is an exception here, it is due to a failure in referential integrity. + # All members should have corresponding memberOf entries. Retested against all xmlrpc tests and passed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch Type: application/octet-stream Size: 5833 bytes Desc: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch URL: From ayoung at redhat.com Sun Apr 10 02:05:52 2011 From: ayoung at redhat.com (Adam Young) Date: Sat, 09 Apr 2011 22:05:52 -0400 Subject: [Freeipa-devel] [PATCH] 134 Entitlements. In-Reply-To: <4D9F5EB0.2050103@redhat.com> References: <4D9F5EB0.2050103@redhat.com> Message-ID: <4DA11080.8090401@redhat.com> On 04/08/2011 03:14 PM, Endi Sukma Dewata wrote: > Initial implementation of Entitlements. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Needs to be added to makefile.am and jsl.conf -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Apr 11 08:25:34 2011 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Apr 2011 10:25:34 +0200 Subject: [Freeipa-devel] [PATCH] 042 Password policy commands do not include cospriority In-Reply-To: <4D9F1BD8.5050702@redhat.com> References: <1301326584.3592.10.camel@dhcp-25-52.brq.redhat.com> <4D961089.70701@redhat.com> <1301903472.2932.10.camel@dhcp-25-52.brq.redhat.com> <4D9F1BD8.5050702@redhat.com> Message-ID: <1302510334.7619.5.camel@dhcp-25-52.brq.redhat.com> On Fri, 2011-04-08 at 10:29 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2011-04-01 at 13:51 -0400, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> Target branches: master, ipa-2-0 > >>> --- > >>> > >>> Most of the pwpolicy_* commands do include cospriority in the result > >>> and potentially in the attribute rights (--all --rights). Especially > >>> when --raw output is requested. This patch fixes it for all > >>> pwpolicy commands. > >>> > >>> https://fedorahosted.org/freeipa/ticket/1103 > >>> > >> > >> nack. I see a couple of problems. > >> > >> You should test for rights before doing the cosentry_show(). If rights > >> is False then we won't add the data whatever it is so it is more > >> efficient to exit earlier. > > > > We have to call cosentry_show every time (except for the case when we > > pull data for the global policy) because we read cospriority attribute. > > But the function was indeed not efficient (it called cosentry_show > > twice), I rewrote it. > > > >> > >> Same with pwpolicy_name == global_policy_name. I think you should drop > >> the try/except and make it: > >> > >> if not rights or pwpolicy_name == global_policy_name: > >> return > >> > >> ... > >> > >> It should never be the case that the cosentry is not found so I'd let it > >> fail if that does occur. > > > > Fixed. > > > >> > >> I think that keys[-1] can be None so be aware. > > > > Fixed. > > > >> > >> You hardcode rights == False in pwpolicy_find(), a good thing. I think > >> you should add make it explict rights=False and add a comment explaining > >> that you can't get accessrights with a find. > > > > Fixed. > > > > Fixed patch attached. > > > > Martin > > Looks great, ack. > > rob Pushed to master, ipa-2-0. From mkosek at redhat.com Mon Apr 11 08:26:04 2011 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Apr 2011 10:26:04 +0200 Subject: [Freeipa-devel] [PATCH] 046 Improve DNS PTR record validation In-Reply-To: <4D9F5714.7070508@redhat.com> References: <1301652399.1997.0.camel@dhcp-25-52.brq.redhat.com> <4D9F5714.7070508@redhat.com> Message-ID: <1302510364.7619.6.camel@dhcp-25-52.brq.redhat.com> On Fri, 2011-04-08 at 14:42 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > Current PTR validation is unclear and may misled the user. This > > patch improves the validation process so that the eventual exception > > is clearer. New check that the PTR record is fully qualified has > > been added to ensure that the reverse zone resolution behaves as > > expected. > > > > Additionally, several strings in the DNS plugin were prepared for > > localization. > > > > https://fedorahosted.org/freeipa/ticket/1129 > > > > ack Pushed to master, ipa-2-0. Martin From mkosek at redhat.com Mon Apr 11 08:39:17 2011 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Apr 2011 10:39:17 +0200 Subject: [Freeipa-devel] [PATCH] 764 update ipa-client-install man page In-Reply-To: <4D9F40CE.40103@redhat.com> References: <4D9A36E3.5010207@redhat.com> <1301999640.20811.5.camel@dhcp-25-52.brq.redhat.com> <4D9F40CE.40103@redhat.com> Message-ID: <1302511157.7619.9.camel@dhcp-25-52.brq.redhat.com> On Fri, 2011-04-08 at 13:07 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > I don't think it is a good idea to have this option in > > ipa-client-install --help at all. > > > > Since it is not intended to be used by the user and we just use it in > > our scripts why would we want to have it in ipa-client-install --help or > > man pages? We could just hide it using help=optparse.SUPPRESS_HELP > > attribute for the option and document it only in the installation script > > source. > > > > Martin > > > > On Mon, 2011-04-04 at 17:23 -0400, Rob Crittenden wrote: > >> Make it clear that --on-master is for install scripts only. > >> > >> ticket 1050 > > An excellent idea. See new patch. > > rob Nicely done - we won't confuse the user anymore. I have a one more issue I didn't notice in the first review - why should we allow non-root to run ipa-client-install? It fails in this case. I guess this change slipped in the patch only by accident. Martin From jcholast at redhat.com Mon Apr 11 10:48:15 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 Apr 2011 12:48:15 +0200 Subject: [Freeipa-devel] [PATCH] 3 Add ability to specify netmask with IP addresses during installation In-Reply-To: <4D9F1AFA.8000305@redhat.com> References: <4D9068E5.6090209@redhat.com> <4D90920E.3080900@redhat.com> <4D91DD15.8020109@redhat.com> <4D91DDA6.2060304@redhat.com> <4D923DCA.1030900@redhat.com> <4D930AAD.9020209@redhat.com> <4D9F1AFA.8000305@redhat.com> Message-ID: <4DA2DC6F.1000105@redhat.com> On 8.4.2011 16:26, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 29.3.2011 22:15, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Sorry, forgot to attach the patch. >>>> >>> >>> Is this why you have some blind excepts? >>> >>> installutils._IPAddressWithPrefix('192.168.0.1/33') >>> Traceback (most recent call last): >>> File "", line 1, in >>> File "ipaserver/install/installutils.py", line 167, in __init__ >>> net = netaddr.IPNetwork(addr) >>> File "/usr/lib/python2.7/site-packages/netaddr/ip/__init__.py", line >>> 919, in __init__ >>> implicit_prefix, flags) >>> File "/usr/lib/python2.7/site-packages/netaddr/ip/__init__.py", line >>> 782, in parse_ip_network >>> value = ip._value >>> UnboundLocalError: local variable 'ip' referenced before assignment >>> >>> We should get an upstream bug filed on python-netaddr about this. >> >> https://github.com/drkjam/netaddr/issues/closed#issue/5 >> https://github.com/drkjam/netaddr/issues/closed#issue/6 >> https://github.com/drkjam/netaddr/issues/closed#issue/8 >> >> Apparently it's already been fixed for the next release. >> >> IMHO it's not much of an issue for us, because the exception gets caught >> in parse_ip_address and that's currently the only place where >> _IPAddressWithPrefix is used. >> >>> >>> Shoudl parse_ip_address() raise an exception on bad data rather than >>> returning 0.0.0.0? >> >> I've been down that road and it would need a rewrite of the fragile IP >> address handling logic of ipa-server-install, which is something I'd >> rather avoid. >> >>> >>> >>> installutils.parse_ip_address('355.555.3.3') >>> _IPAddressWithPrefix('0.0.0.0') >>> >>> or >>> >>> >>> installutils.parse_ip_address('192.168.0.1/55') >>> _IPAddressWithPrefix('0.0.0.0') >>> >>> Should it disallow net addresses like 192.168.0.0? >> >> If you mean network and broadcast addresses, it probably should. It >> might be a good idea to disallow localhost, multicast and/or link-local >> addresses too. > > Are you going to resubmit the patch with these added or should we open a > separate ticket? I'm going to resubmit it. Right now it disallows loopback, IANA reserved, link-local, network, multicast and broadcast IP addresses. Does it make sense to also allow only IP addresses attached to one of the local network interfaces? Perhaps it would be sufficient just to print a warning. Or should we not care about that at all? > > rob -- Jan Cholasta From mkosek at redhat.com Mon Apr 11 11:31:44 2011 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Apr 2011 13:31:44 +0200 Subject: [Freeipa-devel] [PATCH] 6 Add lint script for static code analysis In-Reply-To: <4D9DD188.6080704@redhat.com> References: <4D9DD188.6080704@redhat.com> Message-ID: <1302521504.7619.17.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-07 at 17:00 +0200, Jan Cholasta wrote: > This patch adds a script based on pylint for static code analysis during > build. > > https://fedorahosted.org/freeipa/ticket/867 > Good work, works for me. Enabling static analysis for our IPA framework will improve the code base and could identify some hard-to-find bugs - I see that one has been already fixed. I tested this along with the next patch dealing with false positives. Martin From mkosek at redhat.com Mon Apr 11 11:38:38 2011 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Apr 2011 13:38:38 +0200 Subject: [Freeipa-devel] [PATCH] Fix lint false positives In-Reply-To: <4D9DD24A.6000802@redhat.com> References: <4D9DD24A.6000802@redhat.com> Message-ID: <1302521918.7619.24.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-07 at 17:03 +0200, Jan Cholasta wrote: > Added changes to the code necesarry for removal of false positives > reported by the lint script (see my previous patch). > ACK. Along with the previous patch suppressing false positives shows some real issues in the framework. We should investigate those and either mark them as false positives or carefully fix them. Martin From jhrozek at redhat.com Mon Apr 11 11:45:26 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 11 Apr 2011 13:45:26 +0200 Subject: [Freeipa-devel] [PATCH] Fix lint false positives In-Reply-To: <1302521918.7619.24.camel@dhcp-25-52.brq.redhat.com> References: <4D9DD24A.6000802@redhat.com> <1302521918.7619.24.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DA2E9D6.6080409@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/11/2011 01:38 PM, Martin Kosek wrote: > On Thu, 2011-04-07 at 17:03 +0200, Jan Cholasta wrote: >> Added changes to the code necesarry for removal of false positives >> reported by the lint script (see my previous patch). >> > > ACK. Along with the previous patch suppressing false positives shows > some real issues in the framework. We should investigate those and > either mark them as false positives or carefully fix them. > > Martin > When all the real bugs are fixed, I'd like to see a follow up patch that enables make lint during make rpms to avoid new bugs creeping in. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2i6dYACgkQHsardTLnvCWoBwCfSJj/7uAud5yoG2TSwOo3zHLK ecYAoLx+8RWiWmSEdW/5vwMEl/ZlBN1L =CaDE -----END PGP SIGNATURE----- From jcholast at redhat.com Mon Apr 11 12:44:06 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 Apr 2011 14:44:06 +0200 Subject: [Freeipa-devel] [PATCH] 9 Fix unitialized variables Message-ID: <4DA2F796.8060501@redhat.com> Fixed unitialized variables in makeapi validate_api. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-9-makeapi-unitialized-variables.patch Type: text/x-patch Size: 682 bytes Desc: not available URL: From jcholast at redhat.com Mon Apr 11 12:48:15 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 Apr 2011 14:48:15 +0200 Subject: [Freeipa-devel] [PATCH] 10 Fix double definition Message-ID: <4DA2F88F.4000606@redhat.com> Fixed double definition of Command.output_for_cli. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-10-double-definition.patch Type: text/x-patch Size: 620 bytes Desc: not available URL: From jcholast at redhat.com Mon Apr 11 13:07:42 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 Apr 2011 15:07:42 +0200 Subject: [Freeipa-devel] [PATCH] 11 Fix unitialized attributes Message-ID: <4DA2FD1E.1020209@redhat.com> Fixed unitialized attributes in ipalib.aci.ACI, ipalib.parameters.Data, ipalib.text.LazyText, ipaserver.install.service.Service and ipaserver.rpcserver.WSGIExecutioner. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-11-uninitialized-attributes.patch Type: text/x-patch Size: 2492 bytes Desc: not available URL: From jcholast at redhat.com Mon Apr 11 13:44:41 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 11 Apr 2011 15:44:41 +0200 Subject: [Freeipa-devel] [PATCH] 6 Add lint script for static code analysis In-Reply-To: <4D9DD188.6080704@redhat.com> References: <4D9DD188.6080704@redhat.com> Message-ID: <4DA305C9.6020800@redhat.com> On 7.4.2011 17:00, Jan Cholasta wrote: > This patch adds a script based on pylint for static code analysis during > build. > > https://fedorahosted.org/freeipa/ticket/867 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Improved the script a little bit: - The script now exits with non-zero error code if errors were found. This behavior can be suppressed with the --no-fail option. - Added --enable-noerror option to enable warnings and other non-error messages. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-6-lint-script.patch Type: text/x-patch Size: 7376 bytes Desc: not available URL: From mkosek at redhat.com Mon Apr 11 13:56:07 2011 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Apr 2011 15:56:07 +0200 Subject: [Freeipa-devel] [PATCH] 048 Remove doc from API.txt Message-ID: <1302530167.7619.30.camel@dhcp-25-52.brq.redhat.com> Doc parts are not removed from the API completely. This leads to unnecessary updates to API.txt when the option/argument documentation is changed. This patch replaces unreliable doc stripping function with a regular expression. It works for all current doc strings (simple string or GetText). The only limitation is that the RE supports only up to 2 levels of nested parentheses in doc string. https://fedorahosted.org/freeipa/ticket/1057 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-048-remove-doc-from-api.txt.patch Type: text/x-patch Size: 168889 bytes Desc: not available URL: From ayoung at redhat.com Mon Apr 11 15:03:41 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 11 Apr 2011 11:03:41 -0400 Subject: [Freeipa-devel] [PATCH] 131 Refactored action panel and client area. In-Reply-To: <4D9F5E23.40705@redhat.com> References: <4D9F5E23.40705@redhat.com> Message-ID: <4DA3184D.3020202@redhat.com> On 04/08/2011 03:12 PM, Endi Sukma Dewata wrote: > To improve code readability and extensibility the containers for action > panel and client area are now created in IPA.entity.setup(). The > 'client area' has been renamed into 'content'. The IPA.facet.create() > has been renamed to IPA.facet.create_content(). > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Mon Apr 11 15:05:33 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 11 Apr 2011 11:05:33 -0400 Subject: [Freeipa-devel] [PATCH] 132 Refactored builder interface. In-Reply-To: <4D9F5E5C.4030504@redhat.com> References: <4D9F5E5C.4030504@redhat.com> Message-ID: <4DA318BD.9020209@redhat.com> On 04/08/2011 03:13 PM, Endi Sukma Dewata wrote: > The IPA.entity_builder has been modified to take a 'factory' parameter > in custom facet's and custom dialog's spec. The IPA.dialog has been > modified to take an array of fields in the spec. The IPA.search_facet > has been modified to take an array of columns in the spec. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Mon Apr 11 15:23:36 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 11 Apr 2011 11:23:36 -0400 Subject: [Freeipa-devel] [PATCH] 133 Refactored search facet. In-Reply-To: <4D9F5E85.3030708@redhat.com> References: <4D9F5E85.3030708@redhat.com> Message-ID: <4DA31CF8.4060402@redhat.com> On 04/08/2011 03:14 PM, Endi Sukma Dewata wrote: > To simplify customization, the add(), remove(), and refresh() methods > have been moved from IPA.search_widget into IPA.search_facet. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. Follow on work required to make add and delte avaialbel from other facets. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Mon Apr 11 15:23:59 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 11 Apr 2011 10:23:59 -0500 Subject: [Freeipa-devel] [PATCH] 134 Entitlements. In-Reply-To: <4DA11080.8090401@redhat.com> References: <4D9F5EB0.2050103@redhat.com> <4DA11080.8090401@redhat.com> Message-ID: <4DA31D0F.6040103@redhat.com> On 4/9/2011 9:05 PM, Adam Young wrote: > On 04/08/2011 03:14 PM, Endi Sukma Dewata wrote: >> Initial implementation of Entitlements. > Needs to be added to makefile.am and jsl.conf Fixed in the new patch. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0134-2-Entitlements.patch Type: text/x-patch Size: 29841 bytes Desc: not available URL: From edewata at redhat.com Mon Apr 11 16:09:47 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 11 Apr 2011 11:09:47 -0500 Subject: [Freeipa-devel] [PATCH] 131 Refactored action panel and client area. In-Reply-To: <4DA3184D.3020202@redhat.com> References: <4D9F5E23.40705@redhat.com> <4DA3184D.3020202@redhat.com> Message-ID: <4DA327CB.1000007@redhat.com> On 4/11/2011 10:03 AM, Adam Young wrote: > On 04/08/2011 03:12 PM, Endi Sukma Dewata wrote: >> To improve code readability and extensibility the containers for action >> panel and client area are now created in IPA.entity.setup(). The >> 'client area' has been renamed into 'content'. The IPA.facet.create() >> has been renamed to IPA.facet.create_content(). > ACK Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Apr 11 16:10:07 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 11 Apr 2011 11:10:07 -0500 Subject: [Freeipa-devel] [PATCH] 132 Refactored builder interface. In-Reply-To: <4DA318BD.9020209@redhat.com> References: <4D9F5E5C.4030504@redhat.com> <4DA318BD.9020209@redhat.com> Message-ID: <4DA327DF.1070609@redhat.com> On 4/11/2011 10:05 AM, Adam Young wrote: > On 04/08/2011 03:13 PM, Endi Sukma Dewata wrote: >> The IPA.entity_builder has been modified to take a 'factory' parameter >> in custom facet's and custom dialog's spec. The IPA.dialog has been >> modified to take an array of fields in the spec. The IPA.search_facet >> has been modified to take an array of columns in the spec. > ACK Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Apr 11 16:10:41 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 11 Apr 2011 11:10:41 -0500 Subject: [Freeipa-devel] [PATCH] 133 Refactored search facet. In-Reply-To: <4DA31CF8.4060402@redhat.com> References: <4D9F5E85.3030708@redhat.com> <4DA31CF8.4060402@redhat.com> Message-ID: <4DA32801.8000207@redhat.com> On 4/11/2011 10:23 AM, Adam Young wrote: > On 04/08/2011 03:14 PM, Endi Sukma Dewata wrote: >> To simplify customization, the add(), remove(), and refresh() methods >> have been moved from IPA.search_widget into IPA.search_facet. > ACK. Follow on work required to make add and delte avaialbel from other > facets. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Apr 11 16:13:46 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 11 Apr 2011 11:13:46 -0500 Subject: [Freeipa-devel] [PATCH] 134 Entitlements. In-Reply-To: <4DA31D0F.6040103@redhat.com> References: <4D9F5EB0.2050103@redhat.com> <4DA11080.8090401@redhat.com> <4DA31D0F.6040103@redhat.com> Message-ID: <4DA328BA.60501@redhat.com> On 4/11/2011 10:23 AM, Endi Sukma Dewata wrote: > On 4/9/2011 9:05 PM, Adam Young wrote: >> On 04/08/2011 03:14 PM, Endi Sukma Dewata wrote: >>> Initial implementation of Entitlements. >> Needs to be added to makefile.am and jsl.conf > Fixed in the new patch. ACKed on IRC and pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Apr 11 17:24:46 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 11 Apr 2011 12:24:46 -0500 Subject: [Freeipa-devel] [PATCH] 135 Updated Selenium tests. In-Reply-To: <4D9F5EE3.1020207@redhat.com> References: <4D9F5EE3.1020207@redhat.com> Message-ID: <4DA3395E.8080505@redhat.com> On 4/8/2011 2:15 PM, Endi Sukma Dewata wrote: > The Selenium tests have been updated to improve robustness. ACKed on IRC and pushed to master. This still requires further improvements. -- Endi S. Dewata From rcritten at redhat.com Mon Apr 11 17:51:31 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Apr 2011 13:51:31 -0400 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: <20110408143629.440d18fd@willson.li.ssimo.org> References: <4D9F1A20.30303@redhat.com> <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> <4D9F23C3.6020902@redhat.com> <4D9F2EB1.3040907@redhat.com> <4D9F41F6.2020504@redhat.com> <20110408143629.440d18fd@willson.li.ssimo.org> Message-ID: <4DA33FA3.2030009@redhat.com> Simo Sorce wrote: > On Fri, 08 Apr 2011 13:12:22 -0400 > Rob Crittenden wrote: > >> JR Aquino wrote: > >>> Does the limitation of autobind with root mean that all of the >>> tools that use ldapi need to be revisited and turned back to 389? >> >> ipa-host-net-manage and ipa-compat-manage work ok for me with this >> patch applied. > > NACK > autobind comes into play only when SASL_EXTERNAL auth is used, > the krb5kdc binds as uid=kdc over ldapi w/o any issue. > > If these tools are having a problem with ldapi, it is most probably an > underlying bug in our ldap wrappers, as thyese tools should bind as > Directory Manager using simple auth not doing SASL_EXTERNAL auth. > > Simo. > The root user cannot use ldapi because of the autobind configuration. Fall back to a standard GSSAPI sasl bind if the external bind fails. With --ldapi a regular user may be trying this as well, catch that and report a reasonable error message. This also gives priority to the DM password if it is passed in. Also require the user be root to run the ipa-nis-manage command. We enable/disable and start/stop services which need to be done as root. Add a new option to ipa-ldap-updater to prompt for the DM password. Remove restriction to be run as root except when doing an upgrade. Ticket 1157 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-767-2-nis.patch Type: application/mbox Size: 7698 bytes Desc: not available URL: From nkinder at redhat.com Mon Apr 11 17:58:02 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 11 Apr 2011 10:58:02 -0700 Subject: [Freeipa-devel] [Freeipa-users] Auto membership plugin In-Reply-To: <4DA33976.2010201@redhat.com> References: <4D93295E.1030507@redhat.com> <4D935DF6.9060408@redhat.com> <4D93663C.3000109@redhat.com> <4D94A08E.9050804@redhat.com> <4D94D5E9.4020900@redhat.com> <4D94DE14.5010604@redhat.com> <4D9F32B3.1070501@redhat.com> <4DA31DE3.8070608@redhat.com> <4DA33976.2010201@redhat.com> Message-ID: <4DA3412A.4070307@redhat.com> On 04/11/2011 10:25 AM, Dmitri Pal wrote: > On 04/11/2011 11:27 AM, Nathan Kinder wrote: >> On 04/08/2011 09:07 AM, Dmitri Pal wrote: >>> On 04/08/2011 11:49 AM, JR Aquino wrote: >>>> Is there any way to capture a description associated with the regex >>>> -> group mapping? >>>> >>>> I was thinking that after time, it would be important to look back >>>> on rules and know why they were put there. >>>> >>>> Particularly in the case of regex, since it may not be completely >>>> obvious by looking back at alphabet soup. >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>> The more I think about current design the more I want to normalize >>> things. >>> I would rather instead of: >>> >>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>> objectclass: autoMemberDefinition >>> autoMemberScope: dc=example,dc=com >>> autoMemberFilter: objectclass=ipaHost >>> autoMemberExclusiveRegex: >>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com >>> autoMemberInclusiveRegex: >>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com >>> autoMemberInclusiveRegex: >>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com >>> autoMemberInclusiveRegex: >>> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com >>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>> autoMemberGroupingAttr: member:dn >>> >>> >>> Have something like: >>> >>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>> objectclass: autoMemberDefinition >>> objectclass: cnContainer >>> autoMemberScope: dc=example,dc=com >>> autoMemberFilter: objectclass=ipaHost >>> autoMemberRegexRule: cn=Webserver Inclusion >>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>> autoMemberRegexRule: cn=Mailserver Inclusion >>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>> autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto >>> Membership Plugin,cn=plugins,cn=config >>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>> autoMemberGroupingAttr: member:dn >>> >>> >>> dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership >>> Plugin,cn=plugins,cn=config >>> objectclass: autoMemberDefinitionRegexRule >>> cn: Webserver Inclusion Rule >>> description: Rule contains regular expression to include webserver >>> hosts into the webserver group. >>> include: yes<- include or exclude >>> memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>> arrtibuteToMath: fgdn >>> expressionToMatch: ^www[1-9]+\.example\.com >>> >>> >>> Or something along those lines... >> It's a nice logical layout, but it would be hard for an administrator >> to figure out what exactly would happen if they were to add a host >> with a specific hostname. Since the config is spread over so many >> entries, one would have to look at the top level config entry to find >> each rule DN, fetch each rule DN to look at the regexes. All of the >> information is so spread out that you can't just look in one place to >> see the rules that will be used. This could make things difficult >> from a troubleshooting perspective. > This should not be viewed in raw. THe UI and CLi should come to the rescue. > I am not sure that this is a right approach to mix readability and > normalization. > To follow this logic no-one would ever normalize data in any DB due to > the claim that it would be hard to join tables. The feature is implemented outside of the UI, and I would like to be able to troubleshoot it without the UI without a ton of hassle. Ultimately, it is a DS plug-in, and we should be able to troubleshoot it easily as a single component instead of requiring the UI to understand what it is doing. We have run into this same issue with things like access control since ACI attributes can live anywhere in the database. It is for this reason that we have things like the get effective rights control for evaluating settings. If one adds an inclusion rule, but doesn't realize that an exclusion rule is overriding it, they could easily get confused. I understand that we want the UI to be able to notice this and present it to the user, but there is plenty of room for error in the UI as we add more and more logic into it. I am not totally opposed to this approach, but I want to point out some of the downsides in going in this direction. I usually like to make the internal representation of plug-in configuration closely mirror the layout of the configuration entries/attributes themselves. In this case, it would be highly inefficient to do so. Internally to the plug-in, we will be representing the config for a specific object type as a single struct with a list of all inclusive and exclusive rules. I can convert multiple config entries into this same internal format, but it is something I generally like to avoid. I will look into this approach further. I have the current approach from the design document implemented and working at this point, so some surgery will be required to go back to a different configuration layout. Parsing and loading the configuration when it is split across so many dependent entries is not going to be trivial. I can see plenty of corner cases in configuration validation cropping up. Dynamic config changes will also be more difficult to handle, as we will have to back track to find what config entries reference a modified rule. >> The description issue is a tough one to deal with if we have the >> config in the form that is currently described in the design doc. >> Since we want a description per regex rule, we should need to make the >> description be a part of the regex rule value instead of a separate >> description attribute. I don't necessarily like this approach, as the >> readability of the config will not be nice. >> > I think this tips the scale towards the approach I proposed. Yes, it does. >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > From rcritten at redhat.com Mon Apr 11 18:00:30 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Apr 2011 14:00:30 -0400 Subject: [Freeipa-devel] [PATCH] 764 update ipa-client-install man page In-Reply-To: <1302511157.7619.9.camel@dhcp-25-52.brq.redhat.com> References: <4D9A36E3.5010207@redhat.com> <1301999640.20811.5.camel@dhcp-25-52.brq.redhat.com> <4D9F40CE.40103@redhat.com> <1302511157.7619.9.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DA341BE.9080104@redhat.com> Martin Kosek wrote: > On Fri, 2011-04-08 at 13:07 -0400, Rob Crittenden wrote: >> Martin Kosek wrote: >>> I don't think it is a good idea to have this option in >>> ipa-client-install --help at all. >>> >>> Since it is not intended to be used by the user and we just use it in >>> our scripts why would we want to have it in ipa-client-install --help or >>> man pages? We could just hide it using help=optparse.SUPPRESS_HELP >>> attribute for the option and document it only in the installation script >>> source. >>> >>> Martin >>> >>> On Mon, 2011-04-04 at 17:23 -0400, Rob Crittenden wrote: >>>> Make it clear that --on-master is for install scripts only. >>>> >>>> ticket 1050 >> >> An excellent idea. See new patch. >> >> rob > > Nicely done - we won't confuse the user anymore. > > I have a one more issue I didn't notice in the first review - why should > we allow non-root to run ipa-client-install? It fails in this case. I > guess this change slipped in the patch only by accident. > > Martin > Yeah, updated patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-764-3-man.patch Type: application/mbox Size: 2584 bytes Desc: not available URL: From ssorce at redhat.com Mon Apr 11 18:21:19 2011 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 11 Apr 2011 14:21:19 -0400 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: <4DA33FA3.2030009@redhat.com> References: <4D9F1A20.30303@redhat.com> <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> <4D9F23C3.6020902@redhat.com> <4D9F2EB1.3040907@redhat.com> <4D9F41F6.2020504@redhat.com> <20110408143629.440d18fd@willson.li.ssimo.org> <4DA33FA3.2030009@redhat.com> Message-ID: <20110411142119.1914ee2a@willson.li.ssimo.org> On Mon, 11 Apr 2011 13:51:31 -0400 Rob Crittenden wrote: > Add a new option to ipa-ldap-updater to prompt for the DM password. > Remove restriction to be run as root except when doing an upgrade. Ack if you rename the new option variable from dm_password to something like ask_password Simo. -- Simo Sorce * Red Hat, Inc * New York From nkinder at redhat.com Mon Apr 11 18:32:30 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 11 Apr 2011 11:32:30 -0700 Subject: [Freeipa-devel] [Freeipa-users] Auto membership plugin In-Reply-To: <4DA3412A.4070307@redhat.com> References: <4D93295E.1030507@redhat.com> <4D935DF6.9060408@redhat.com> <4D93663C.3000109@redhat.com> <4D94A08E.9050804@redhat.com> <4D94D5E9.4020900@redhat.com> <4D94DE14.5010604@redhat.com> <4D9F32B3.1070501@redhat.com> <4DA31DE3.8070608@redhat.com> <4DA33976.2010201@redhat.com> <4DA3412A.4070307@redhat.com> Message-ID: <4DA3493E.6080102@redhat.com> On 04/11/2011 10:58 AM, Nathan Kinder wrote: > On 04/11/2011 10:25 AM, Dmitri Pal wrote: >> On 04/11/2011 11:27 AM, Nathan Kinder wrote: >>> On 04/08/2011 09:07 AM, Dmitri Pal wrote: >>>> On 04/08/2011 11:49 AM, JR Aquino wrote: >>>>> Is there any way to capture a description associated with the regex >>>>> -> group mapping? >>>>> >>>>> I was thinking that after time, it would be important to look back >>>>> on rules and know why they were put there. >>>>> >>>>> Particularly in the case of regex, since it may not be completely >>>>> obvious by looking back at alphabet soup. >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>>>> >>>> The more I think about current design the more I want to normalize >>>> things. >>>> I would rather instead of: >>>> >>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>> objectclass: autoMemberDefinition >>>> autoMemberScope: dc=example,dc=com >>>> autoMemberFilter: objectclass=ipaHost >>>> autoMemberExclusiveRegex: >>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com >>>> autoMemberInclusiveRegex: >>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com >>>> >>>> autoMemberInclusiveRegex: >>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com >>>> >>>> autoMemberInclusiveRegex: >>>> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com >>>> >>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>> autoMemberGroupingAttr: member:dn >>>> >>>> >>>> Have something like: >>>> >>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>> objectclass: autoMemberDefinition >>>> objectclass: cnContainer >>>> autoMemberScope: dc=example,dc=com >>>> autoMemberFilter: objectclass=ipaHost >>>> autoMemberRegexRule: cn=Webserver Inclusion >>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>> autoMemberRegexRule: cn=Mailserver Inclusion >>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>> autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto >>>> Membership Plugin,cn=plugins,cn=config >>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>> autoMemberGroupingAttr: member:dn >>>> >>>> >>>> dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership >>>> Plugin,cn=plugins,cn=config >>>> objectclass: autoMemberDefinitionRegexRule >>>> cn: Webserver Inclusion Rule >>>> description: Rule contains regular expression to include webserver >>>> hosts into the webserver group. >>>> include: yes<- include or exclude >>>> memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>>> arrtibuteToMath: fgdn >>>> expressionToMatch: ^www[1-9]+\.example\.com >>>> >>>> >>>> Or something along those lines... >>> It's a nice logical layout, but it would be hard for an administrator >>> to figure out what exactly would happen if they were to add a host >>> with a specific hostname. Since the config is spread over so many >>> entries, one would have to look at the top level config entry to find >>> each rule DN, fetch each rule DN to look at the regexes. All of the >>> information is so spread out that you can't just look in one place to >>> see the rules that will be used. This could make things difficult >>> from a troubleshooting perspective. >> This should not be viewed in raw. THe UI and CLi should come to the >> rescue. >> I am not sure that this is a right approach to mix readability and >> normalization. >> To follow this logic no-one would ever normalize data in any DB due to >> the claim that it would be hard to join tables. > The feature is implemented outside of the UI, and I would like to be > able to troubleshoot it without the UI without a ton of hassle. > Ultimately, it is a DS plug-in, and we should be able to troubleshoot > it easily as a single component instead of requiring the UI to > understand what it is doing. We have run into this same issue with > things like access control since ACI attributes can live anywhere in > the database. It is for this reason that we have things like the get > effective rights control for evaluating settings. > > If one adds an inclusion rule, but doesn't realize that an exclusion > rule is overriding it, they could easily get confused. I understand > that we want the UI to be able to notice this and present it to the > user, but there is plenty of room for error in the UI as we add more > and more logic into it. > > I am not totally opposed to this approach, but I want to point out > some of the downsides in going in this direction. I usually like to > make the internal representation of plug-in configuration closely > mirror the layout of the configuration entries/attributes themselves. > In this case, it would be highly inefficient to do so. Internally to > the plug-in, we will be representing the config for a specific object > type as a single struct with a list of all inclusive and exclusive > rules. I can convert multiple config entries into this same internal > format, but it is something I generally like to avoid. > > I will look into this approach further. I have the current approach > from the design document implemented and working at this point, so > some surgery will be required to go back to a different configuration > layout. Parsing and loading the configuration when it is split across > so many dependent entries is not going to be trivial. I can see > plenty of corner cases in configuration validation cropping up. > Dynamic config changes will also be more difficult to handle, as we > will have to back track to find what config entries reference a > modified rule. >>> The description issue is a tough one to deal with if we have the >>> config in the form that is currently described in the design doc. >>> Since we want a description per regex rule, we should need to make the >>> description be a part of the regex rule value instead of a separate >>> description attribute. I don't necessarily like this approach, as the >>> readability of the config will not be nice. >>> >> I think this tips the scale towards the approach I proposed. > Yes, it does. I started writing up some notes to map out how we would represent the configuration with this split out approach. We would have one top level config entry per filter/scope. Child entries would be inclusive/exclusive rule entries. We sould load all child entries as regex rules, so we don't need pointers to each regex entry in the top-level entry. Here is an example: ------------------------------------------------------------------------------------------------- dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipaHost autoMemberGroupingAttr: member:dn autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com dn: cn=www 5,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: exclude www5 from being added to webservers autoMemberRegexType: exclusive autoMemberRegexAttr: fqdn autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com autoMemberRegex: ^www5\.example\.com dn: cn=www hosts,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: include www hosts in webservers autoMemberRegexType: inclusive autoMemberRegexAttr: fqdn autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com autoMemberRegex: ^www[1-9]+\.example\.com dn: cn=web hosts,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: include web hosts in webservers autoMemberRegexType: inclusive autoMemberRegexAttr: fqdn autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com autoMemberRegex: ^web[1-9]+\.example\.com dn: cn=mail hosts,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: include mail hosts in mailservers autoMemberRegexType: inclusive autoMemberRegexAttr: fqdn autoMemberTargetGroup: cn=mailservers,cn=hostgroups,dc=example,dc=com autoMemberRegex: ^mail[1-9]+\.example\.com ------------------------------------------------------------------------------------------------- What I don't like about this approach is that the first 3 regex rules really belong together, as they all have to do with webservers. It makes sense to split out the mail hosts regex since it is logically different. If you have the case where your hosts have hostnames that don't follow any sort of format, you may end up having many inclusive rule entries for all of your different webservers. I see that as being a headache in many cases. Keep in mind that the above is a very simple example. You would likely have many more entries in an actual deployment. To alleviate this problem, we could make the autoMemberRegex attribute multi-valued, but you would only have one description per regex rule entry, not per regex. This is more flexible, as administrators could choose when to group regexes together vs. having them separate. The only real advantage is to add a description to a group of regex rules though. This is all equivalent to the following config with the method described in the design doc (without the ability to have descriptions): ------------------------------------------------------------------------------------------------- dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipaHost autoMemberExclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com autoMemberInclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com autoMemberInclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com autoMemberInclusiveRegex: cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com autoMemberGroupingAttr: member:dn ------------------------------------------------------------------------------------------------- -NGK >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From dpal at redhat.com Mon Apr 11 18:59:41 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Apr 2011 14:59:41 -0400 Subject: [Freeipa-devel] [Freeipa-users] Auto membership plugin In-Reply-To: <4DA3493E.6080102@redhat.com> References: <4D93295E.1030507@redhat.com> <4D935DF6.9060408@redhat.com> <4D93663C.3000109@redhat.com> <4D94A08E.9050804@redhat.com> <4D94D5E9.4020900@redhat.com> <4D94DE14.5010604@redhat.com> <4D9F32B3.1070501@redhat.com> <4DA31DE3.8070608@redhat.com> <4DA33976.2010201@redhat.com> <4DA3412A.4070307@redhat.com> <4DA3493E.6080102@redhat.com> Message-ID: <4DA34F9D.7020705@redhat.com> On 04/11/2011 02:32 PM, Nathan Kinder wrote: > On 04/11/2011 10:58 AM, Nathan Kinder wrote: >> On 04/11/2011 10:25 AM, Dmitri Pal wrote: >>> On 04/11/2011 11:27 AM, Nathan Kinder wrote: >>>> On 04/08/2011 09:07 AM, Dmitri Pal wrote: >>>>> On 04/08/2011 11:49 AM, JR Aquino wrote: >>>>>> Is there any way to capture a description associated with the regex >>>>>> -> group mapping? >>>>>> >>>>>> I was thinking that after time, it would be important to look back >>>>>> on rules and know why they were put there. >>>>>> >>>>>> Particularly in the case of regex, since it may not be completely >>>>>> obvious by looking back at alphabet soup. >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-users mailing list >>>>>> Freeipa-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> >>>>>> >>>>> The more I think about current design the more I want to normalize >>>>> things. >>>>> I would rather instead of: >>>>> >>>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>> objectclass: autoMemberDefinition >>>>> autoMemberScope: dc=example,dc=com >>>>> autoMemberFilter: objectclass=ipaHost >>>>> autoMemberExclusiveRegex: >>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com >>>>> >>>>> autoMemberInclusiveRegex: >>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com >>>>> >>>>> autoMemberInclusiveRegex: >>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com >>>>> >>>>> autoMemberInclusiveRegex: >>>>> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com >>>>> >>>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>>> autoMemberGroupingAttr: member:dn >>>>> >>>>> >>>>> Have something like: >>>>> >>>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>> objectclass: autoMemberDefinition >>>>> objectclass: cnContainer >>>>> autoMemberScope: dc=example,dc=com >>>>> autoMemberFilter: objectclass=ipaHost >>>>> autoMemberRegexRule: cn=Webserver Inclusion >>>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>> autoMemberRegexRule: cn=Mailserver Inclusion >>>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>> autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto >>>>> Membership Plugin,cn=plugins,cn=config >>>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>>> autoMemberGroupingAttr: member:dn >>>>> >>>>> >>>>> dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership >>>>> Plugin,cn=plugins,cn=config >>>>> objectclass: autoMemberDefinitionRegexRule >>>>> cn: Webserver Inclusion Rule >>>>> description: Rule contains regular expression to include webserver >>>>> hosts into the webserver group. >>>>> include: yes<- include or exclude >>>>> memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>>>> arrtibuteToMath: fgdn >>>>> expressionToMatch: ^www[1-9]+\.example\.com >>>>> >>>>> >>>>> Or something along those lines... >>>> It's a nice logical layout, but it would be hard for an administrator >>>> to figure out what exactly would happen if they were to add a host >>>> with a specific hostname. Since the config is spread over so many >>>> entries, one would have to look at the top level config entry to find >>>> each rule DN, fetch each rule DN to look at the regexes. All of the >>>> information is so spread out that you can't just look in one place to >>>> see the rules that will be used. This could make things difficult >>>> from a troubleshooting perspective. >>> This should not be viewed in raw. THe UI and CLi should come to the >>> rescue. >>> I am not sure that this is a right approach to mix readability and >>> normalization. >>> To follow this logic no-one would ever normalize data in any DB due to >>> the claim that it would be hard to join tables. >> The feature is implemented outside of the UI, and I would like to be >> able to troubleshoot it without the UI without a ton of hassle. >> Ultimately, it is a DS plug-in, and we should be able to troubleshoot >> it easily as a single component instead of requiring the UI to >> understand what it is doing. We have run into this same issue with >> things like access control since ACI attributes can live anywhere in >> the database. It is for this reason that we have things like the get >> effective rights control for evaluating settings. >> >> If one adds an inclusion rule, but doesn't realize that an exclusion >> rule is overriding it, they could easily get confused. I understand >> that we want the UI to be able to notice this and present it to the >> user, but there is plenty of room for error in the UI as we add more >> and more logic into it. >> >> I am not totally opposed to this approach, but I want to point out >> some of the downsides in going in this direction. I usually like to >> make the internal representation of plug-in configuration closely >> mirror the layout of the configuration entries/attributes >> themselves. In this case, it would be highly inefficient to do so. >> Internally to the plug-in, we will be representing the config for a >> specific object type as a single struct with a list of all inclusive >> and exclusive rules. I can convert multiple config entries into this >> same internal format, but it is something I generally like to avoid. >> >> I will look into this approach further. I have the current approach >> from the design document implemented and working at this point, so >> some surgery will be required to go back to a different configuration >> layout. Parsing and loading the configuration when it is split >> across so many dependent entries is not going to be trivial. I can >> see plenty of corner cases in configuration validation cropping up. >> Dynamic config changes will also be more difficult to handle, as we >> will have to back track to find what config entries reference a >> modified rule. >>>> The description issue is a tough one to deal with if we have the >>>> config in the form that is currently described in the design doc. >>>> Since we want a description per regex rule, we should need to make the >>>> description be a part of the regex rule value instead of a separate >>>> description attribute. I don't necessarily like this approach, as the >>>> readability of the config will not be nice. >>>> >>> I think this tips the scale towards the approach I proposed. >> Yes, it does. > I started writing up some notes to map out how we would represent the > configuration with this split out approach. We would have one top > level config entry per filter/scope. Child entries would be > inclusive/exclusive rule entries. We sould load all child entries as > regex rules, so we don't need pointers to each regex entry in the > top-level entry. Here is an example: > > ------------------------------------------------------------------------------------------------- > > dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > objectclass: autoMemberDefinition > autoMemberScope: dc=example,dc=com > autoMemberFilter: objectclass=ipaHost > autoMemberGroupingAttr: member:dn > autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com > > dn: cn=www 5,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > objectclass: autoMemberRegexRule > description: exclude www5 from being added to webservers > autoMemberRegexType: exclusive > autoMemberRegexAttr: fqdn > autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com > autoMemberRegex: ^www5\.example\.com > > dn: cn=www hosts,cn=Hostgroups,cn=Auto Membership > Plugin,cn=plugins,cn=config > objectclass: autoMemberRegexRule > description: include www hosts in webservers > autoMemberRegexType: inclusive > autoMemberRegexAttr: fqdn > autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com > autoMemberRegex: ^www[1-9]+\.example\.com > > dn: cn=web hosts,cn=Hostgroups,cn=Auto Membership > Plugin,cn=plugins,cn=config > objectclass: autoMemberRegexRule > description: include web hosts in webservers > autoMemberRegexType: inclusive > autoMemberRegexAttr: fqdn > autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com > autoMemberRegex: ^web[1-9]+\.example\.com > > dn: cn=mail hosts,cn=Hostgroups,cn=Auto Membership > Plugin,cn=plugins,cn=config > objectclass: autoMemberRegexRule > description: include mail hosts in mailservers > autoMemberRegexType: inclusive > autoMemberRegexAttr: fqdn > autoMemberTargetGroup: cn=mailservers,cn=hostgroups,dc=example,dc=com > autoMemberRegex: ^mail[1-9]+\.example\.com > ------------------------------------------------------------------------------------------------- > > > What I don't like about this approach is that the first 3 regex rules > really belong together, as they all have to do with webservers. It > makes sense to split out the mail hosts regex since it is logically > different. If you have the case where your hosts have hostnames that > don't follow any sort of format, you may end up having many inclusive > rule entries for all of your different webservers. I see that as > being a headache in many cases. Keep in mind that the above is a very > simple example. You would likely have many more entries in an actual > deployment. > > To alleviate this problem, we could make the autoMemberRegex attribute > multi-valued, but you would only have one description per regex rule > entry, not per regex. This is more flexible, as administrators could > choose when to group regexes together vs. having them separate. The > only real advantage is to add a description to a group of regex rules > though. > > This is all equivalent to the following config with the method > described in the design doc (without the ability to have descriptions): > > ------------------------------------------------------------------------------------------------- > > dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > objectclass: autoMemberDefinition > autoMemberScope: dc=example,dc=com > autoMemberFilter: objectclass=ipaHost > autoMemberExclusiveRegex: > cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com > autoMemberInclusiveRegex: > cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com > autoMemberInclusiveRegex: > cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com > autoMemberInclusiveRegex: > cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com > autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com > autoMemberGroupingAttr: member:dn > ------------------------------------------------------------------------------------------------- > > Or you can go the other way around and eliminate the top level entry: dn: cn=www 5,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: exclude www5 from being added to webservers autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipaHost autoMemberGroupingAttr: member:dn autoMemberRegexType: exclusive autoMemberRegexAttr: fqdn autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com autoMemberRegex: ^www5\.example\.com If you need to express the default entry you can say dn: cn=default,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: default catch all rule for Hosts autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipaHost autoMemberGroupingAttr: member:dn autoMemberRegexType: default autoMemberTargetGroup: cn=orpahns,cn=hostgroups,dc=example,dc=com Then you read all the entries, sort them buy "exclusive, inclusive, default" and handle accordingly. That will create a little bit more duplication of data but will be readable and manageable in a raw form. > -NGK >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Apr 11 19:34:38 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Apr 2011 15:34:38 -0400 Subject: [Freeipa-devel] [PATCH] 767 fix ipa-nis-manage In-Reply-To: <20110411142119.1914ee2a@willson.li.ssimo.org> References: <4D9F1A20.30303@redhat.com> <805E9E3A-37D1-4D25-9BE1-8AE9719FBCAB@citrixonline.com> <4D9F23C3.6020902@redhat.com> <4D9F2EB1.3040907@redhat.com> <4D9F41F6.2020504@redhat.com> <20110408143629.440d18fd@willson.li.ssimo.org> <4DA33FA3.2030009@redhat.com> <20110411142119.1914ee2a@willson.li.ssimo.org> Message-ID: <4DA357CE.1060506@redhat.com> Simo Sorce wrote: > On Mon, 11 Apr 2011 13:51:31 -0400 > Rob Crittenden wrote: > >> Add a new option to ipa-ldap-updater to prompt for the DM password. >> Remove restriction to be run as root except when doing an upgrade. > > Ack if you rename the new option variable from dm_password to something > like ask_password > > Simo. > > Fixed and pushed to master and ipa-2-0 From rcritten at redhat.com Mon Apr 11 21:05:32 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Apr 2011 17:05:32 -0400 Subject: [Freeipa-devel] [PATCH] 769 enable SSL hostname checking Message-ID: <4DA36D1C.9000702@redhat.com> Enable 389-ds SSL host checking by defauilt Enforce that the remote hostname matches the remote SSL server certificate when 389-ds operates as an SSL client. Also add an update file to turn this off for existing installations. ticket 1069 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-769-ssl.patch Type: application/mbox Size: 2069 bytes Desc: not available URL: From nkinder at redhat.com Mon Apr 11 21:21:04 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 11 Apr 2011 14:21:04 -0700 Subject: [Freeipa-devel] [Freeipa-users] Auto membership plugin In-Reply-To: <4DA34F9D.7020705@redhat.com> References: <4D93295E.1030507@redhat.com> <4D935DF6.9060408@redhat.com> <4D93663C.3000109@redhat.com> <4D94A08E.9050804@redhat.com> <4D94D5E9.4020900@redhat.com> <4D94DE14.5010604@redhat.com> <4D9F32B3.1070501@redhat.com> <4DA31DE3.8070608@redhat.com> <4DA33976.2010201@redhat.com> <4DA3412A.4070307@redhat.com> <4DA3493E.6080102@redhat.com> <4DA34F9D.7020705@redhat.com> Message-ID: <4DA370C0.2050203@redhat.com> On 04/11/2011 11:59 AM, Dmitri Pal wrote: > On 04/11/2011 02:32 PM, Nathan Kinder wrote: >> On 04/11/2011 10:58 AM, Nathan Kinder wrote: >>> On 04/11/2011 10:25 AM, Dmitri Pal wrote: >>>> On 04/11/2011 11:27 AM, Nathan Kinder wrote: >>>>> On 04/08/2011 09:07 AM, Dmitri Pal wrote: >>>>>> On 04/08/2011 11:49 AM, JR Aquino wrote: >>>>>>> Is there any way to capture a description associated with the regex >>>>>>> -> group mapping? >>>>>>> >>>>>>> I was thinking that after time, it would be important to look back >>>>>>> on rules and know why they were put there. >>>>>>> >>>>>>> Particularly in the case of regex, since it may not be completely >>>>>>> obvious by looking back at alphabet soup. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-users mailing list >>>>>>> Freeipa-users at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>> >>>>>>> >>>>>> The more I think about current design the more I want to normalize >>>>>> things. >>>>>> I would rather instead of: >>>>>> >>>>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>> objectclass: autoMemberDefinition >>>>>> autoMemberScope: dc=example,dc=com >>>>>> autoMemberFilter: objectclass=ipaHost >>>>>> autoMemberExclusiveRegex: >>>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com >>>>>> >>>>>> autoMemberInclusiveRegex: >>>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com >>>>>> >>>>>> autoMemberInclusiveRegex: >>>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com >>>>>> >>>>>> autoMemberInclusiveRegex: >>>>>> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com >>>>>> >>>>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>>>> autoMemberGroupingAttr: member:dn >>>>>> >>>>>> >>>>>> Have something like: >>>>>> >>>>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>> objectclass: autoMemberDefinition >>>>>> objectclass: cnContainer >>>>>> autoMemberScope: dc=example,dc=com >>>>>> autoMemberFilter: objectclass=ipaHost >>>>>> autoMemberRegexRule: cn=Webserver Inclusion >>>>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>> autoMemberRegexRule: cn=Mailserver Inclusion >>>>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>> autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto >>>>>> Membership Plugin,cn=plugins,cn=config >>>>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>>>> autoMemberGroupingAttr: member:dn >>>>>> >>>>>> >>>>>> dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership >>>>>> Plugin,cn=plugins,cn=config >>>>>> objectclass: autoMemberDefinitionRegexRule >>>>>> cn: Webserver Inclusion Rule >>>>>> description: Rule contains regular expression to include webserver >>>>>> hosts into the webserver group. >>>>>> include: yes<- include or exclude >>>>>> memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>>>>> arrtibuteToMath: fgdn >>>>>> expressionToMatch: ^www[1-9]+\.example\.com >>>>>> >>>>>> >>>>>> Or something along those lines... >>>>> It's a nice logical layout, but it would be hard for an administrator >>>>> to figure out what exactly would happen if they were to add a host >>>>> with a specific hostname. Since the config is spread over so many >>>>> entries, one would have to look at the top level config entry to find >>>>> each rule DN, fetch each rule DN to look at the regexes. All of the >>>>> information is so spread out that you can't just look in one place to >>>>> see the rules that will be used. This could make things difficult >>>>> from a troubleshooting perspective. >>>> This should not be viewed in raw. THe UI and CLi should come to the >>>> rescue. >>>> I am not sure that this is a right approach to mix readability and >>>> normalization. >>>> To follow this logic no-one would ever normalize data in any DB due to >>>> the claim that it would be hard to join tables. >>> The feature is implemented outside of the UI, and I would like to be >>> able to troubleshoot it without the UI without a ton of hassle. >>> Ultimately, it is a DS plug-in, and we should be able to troubleshoot >>> it easily as a single component instead of requiring the UI to >>> understand what it is doing. We have run into this same issue with >>> things like access control since ACI attributes can live anywhere in >>> the database. It is for this reason that we have things like the get >>> effective rights control for evaluating settings. >>> >>> If one adds an inclusion rule, but doesn't realize that an exclusion >>> rule is overriding it, they could easily get confused. I understand >>> that we want the UI to be able to notice this and present it to the >>> user, but there is plenty of room for error in the UI as we add more >>> and more logic into it. >>> >>> I am not totally opposed to this approach, but I want to point out >>> some of the downsides in going in this direction. I usually like to >>> make the internal representation of plug-in configuration closely >>> mirror the layout of the configuration entries/attributes >>> themselves. In this case, it would be highly inefficient to do so. >>> Internally to the plug-in, we will be representing the config for a >>> specific object type as a single struct with a list of all inclusive >>> and exclusive rules. I can convert multiple config entries into this >>> same internal format, but it is something I generally like to avoid. >>> >>> I will look into this approach further. I have the current approach >>> from the design document implemented and working at this point, so >>> some surgery will be required to go back to a different configuration >>> layout. Parsing and loading the configuration when it is split >>> across so many dependent entries is not going to be trivial. I can >>> see plenty of corner cases in configuration validation cropping up. >>> Dynamic config changes will also be more difficult to handle, as we >>> will have to back track to find what config entries reference a >>> modified rule. >>>>> The description issue is a tough one to deal with if we have the >>>>> config in the form that is currently described in the design doc. >>>>> Since we want a description per regex rule, we should need to make the >>>>> description be a part of the regex rule value instead of a separate >>>>> description attribute. I don't necessarily like this approach, as the >>>>> readability of the config will not be nice. >>>>> >>>> I think this tips the scale towards the approach I proposed. >>> Yes, it does. >> I started writing up some notes to map out how we would represent the >> configuration with this split out approach. We would have one top >> level config entry per filter/scope. Child entries would be >> inclusive/exclusive rule entries. We sould load all child entries as >> regex rules, so we don't need pointers to each regex entry in the >> top-level entry. Here is an example: >> >> ------------------------------------------------------------------------------------------------- >> >> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >> objectclass: autoMemberDefinition >> autoMemberScope: dc=example,dc=com >> autoMemberFilter: objectclass=ipaHost >> autoMemberGroupingAttr: member:dn >> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >> >> dn: cn=www 5,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >> objectclass: autoMemberRegexRule >> description: exclude www5 from being added to webservers >> autoMemberRegexType: exclusive >> autoMemberRegexAttr: fqdn >> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >> autoMemberRegex: ^www5\.example\.com >> >> dn: cn=www hosts,cn=Hostgroups,cn=Auto Membership >> Plugin,cn=plugins,cn=config >> objectclass: autoMemberRegexRule >> description: include www hosts in webservers >> autoMemberRegexType: inclusive >> autoMemberRegexAttr: fqdn >> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >> autoMemberRegex: ^www[1-9]+\.example\.com >> >> dn: cn=web hosts,cn=Hostgroups,cn=Auto Membership >> Plugin,cn=plugins,cn=config >> objectclass: autoMemberRegexRule >> description: include web hosts in webservers >> autoMemberRegexType: inclusive >> autoMemberRegexAttr: fqdn >> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >> autoMemberRegex: ^web[1-9]+\.example\.com >> >> dn: cn=mail hosts,cn=Hostgroups,cn=Auto Membership >> Plugin,cn=plugins,cn=config >> objectclass: autoMemberRegexRule >> description: include mail hosts in mailservers >> autoMemberRegexType: inclusive >> autoMemberRegexAttr: fqdn >> autoMemberTargetGroup: cn=mailservers,cn=hostgroups,dc=example,dc=com >> autoMemberRegex: ^mail[1-9]+\.example\.com >> ------------------------------------------------------------------------------------------------- >> >> >> What I don't like about this approach is that the first 3 regex rules >> really belong together, as they all have to do with webservers. It >> makes sense to split out the mail hosts regex since it is logically >> different. If you have the case where your hosts have hostnames that >> don't follow any sort of format, you may end up having many inclusive >> rule entries for all of your different webservers. I see that as >> being a headache in many cases. Keep in mind that the above is a very >> simple example. You would likely have many more entries in an actual >> deployment. >> >> To alleviate this problem, we could make the autoMemberRegex attribute >> multi-valued, but you would only have one description per regex rule >> entry, not per regex. This is more flexible, as administrators could >> choose when to group regexes together vs. having them separate. The >> only real advantage is to add a description to a group of regex rules >> though. >> >> This is all equivalent to the following config with the method >> described in the design doc (without the ability to have descriptions): >> >> ------------------------------------------------------------------------------------------------- >> >> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >> objectclass: autoMemberDefinition >> autoMemberScope: dc=example,dc=com >> autoMemberFilter: objectclass=ipaHost >> autoMemberExclusiveRegex: >> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com >> autoMemberInclusiveRegex: >> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com >> autoMemberInclusiveRegex: >> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com >> autoMemberInclusiveRegex: >> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com >> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >> autoMemberGroupingAttr: member:dn >> ------------------------------------------------------------------------------------------------- >> >> > > Or you can go the other way around and eliminate the top level entry: > > dn: cn=www 5,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > objectclass: autoMemberRegexRule > description: exclude www5 from being added to webservers > autoMemberScope: dc=example,dc=com > autoMemberFilter: objectclass=ipaHost > autoMemberGroupingAttr: member:dn > autoMemberRegexType: exclusive > autoMemberRegexAttr: fqdn > autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com > autoMemberRegex: ^www5\.example\.com > > > If you need to express the default entry you can say > > dn: cn=default,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > objectclass: autoMemberRegexRule > description: default catch all rule for Hosts > autoMemberScope: dc=example,dc=com > autoMemberFilter: objectclass=ipaHost > autoMemberGroupingAttr: member:dn > autoMemberRegexType: default > autoMemberTargetGroup: cn=orpahns,cn=hostgroups,dc=example,dc=com > > Then you read all the entries, sort them buy "exclusive, inclusive, > default" and handle accordingly. > That will create a little bit more duplication of data but will be > readable and manageable in a raw form. Why not just leave the config the way I have it now then? There's nothing preventing you from creating multiple config entries for the same scope/filter/grouping attr. Right now, I use a single struct for each config entry, even if you defined multiple entries with the same scope/filter/grouping attr. Each config entry is processed independently of other config entries. You can't have an exclusion in one config entry that overrides an inclusion from another config entry. If we want multiple config entries to interact in this way, I would need to group and order inclusion rules from multiple config entries that have the same exact scope/filter/grouping attr values into a single struct when parsing and loading the config. This can be done, but we need to handle things such as duplicate regex rules. The reason I like the single struct approach is that I only need to do a filter check against an entry being added for each config entry. If we don't handle it this way internally, we would end up checking the filter and scope from each and every config entry against every entry added to DS. This would mean 100 filter checks for 100 regex rules. This obviously can't be done this way for performance reasons. We can make the internal representation differ from the presentation as config entries, but I find that this introduces room for confusion in how the plug-in will work for a given configuration. I still feel that this is adding a lot of complexity (and room for bugs) for very little value. The main downside with the current approach is that we don't have a way to have a description per regex, right? Is there some other downside here? Maybe we can solve the description issue without the additional complexity if that is the only requirement that is lacking in the current approach. > > >> -NGK >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>>>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> > From dpal at redhat.com Mon Apr 11 21:53:07 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Apr 2011 17:53:07 -0400 Subject: [Freeipa-devel] [Freeipa-users] Auto membership plugin In-Reply-To: <4DA370C0.2050203@redhat.com> References: <4D93295E.1030507@redhat.com> <4D935DF6.9060408@redhat.com> <4D93663C.3000109@redhat.com> <4D94A08E.9050804@redhat.com> <4D94D5E9.4020900@redhat.com> <4D94DE14.5010604@redhat.com> <4D9F32B3.1070501@redhat.com> <4DA31DE3.8070608@redhat.com> <4DA33976.2010201@redhat.com> <4DA3412A.4070307@redhat.com> <4DA3493E.6080102@redhat.com> <4DA34F9D.7020705@redhat.com> <4DA370C0.2050203@redhat.com> Message-ID: <4DA37843.9090303@redhat.com> On 04/11/2011 05:21 PM, Nathan Kinder wrote: > On 04/11/2011 11:59 AM, Dmitri Pal wrote: >> On 04/11/2011 02:32 PM, Nathan Kinder wrote: >>> On 04/11/2011 10:58 AM, Nathan Kinder wrote: >>>> On 04/11/2011 10:25 AM, Dmitri Pal wrote: >>>>> On 04/11/2011 11:27 AM, Nathan Kinder wrote: >>>>>> On 04/08/2011 09:07 AM, Dmitri Pal wrote: >>>>>>> On 04/08/2011 11:49 AM, JR Aquino wrote: >>>>>>>> Is there any way to capture a description associated with the >>>>>>>> regex >>>>>>>> -> group mapping? >>>>>>>> >>>>>>>> I was thinking that after time, it would be important to look back >>>>>>>> on rules and know why they were put there. >>>>>>>> >>>>>>>> Particularly in the case of regex, since it may not be completely >>>>>>>> obvious by looking back at alphabet soup. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-users mailing list >>>>>>>> Freeipa-users at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>> >>>>>>>> >>>>>>> The more I think about current design the more I want to normalize >>>>>>> things. >>>>>>> I would rather instead of: >>>>>>> >>>>>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>>> objectclass: autoMemberDefinition >>>>>>> autoMemberScope: dc=example,dc=com >>>>>>> autoMemberFilter: objectclass=ipaHost >>>>>>> autoMemberExclusiveRegex: >>>>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com >>>>>>> >>>>>>> >>>>>>> autoMemberInclusiveRegex: >>>>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com >>>>>>> >>>>>>> >>>>>>> autoMemberInclusiveRegex: >>>>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com >>>>>>> >>>>>>> >>>>>>> autoMemberInclusiveRegex: >>>>>>> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com >>>>>>> >>>>>>> >>>>>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>>>>> autoMemberGroupingAttr: member:dn >>>>>>> >>>>>>> >>>>>>> Have something like: >>>>>>> >>>>>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>>> objectclass: autoMemberDefinition >>>>>>> objectclass: cnContainer >>>>>>> autoMemberScope: dc=example,dc=com >>>>>>> autoMemberFilter: objectclass=ipaHost >>>>>>> autoMemberRegexRule: cn=Webserver Inclusion >>>>>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>>> autoMemberRegexRule: cn=Mailserver Inclusion >>>>>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>>> autoMemberRegexRule: cn=Desktop exclusion >>>>>>> Rule,cn=Hostgroups,cn=Auto >>>>>>> Membership Plugin,cn=plugins,cn=config >>>>>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>>>>> autoMemberGroupingAttr: member:dn >>>>>>> >>>>>>> >>>>>>> dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership >>>>>>> Plugin,cn=plugins,cn=config >>>>>>> objectclass: autoMemberDefinitionRegexRule >>>>>>> cn: Webserver Inclusion Rule >>>>>>> description: Rule contains regular expression to include webserver >>>>>>> hosts into the webserver group. >>>>>>> include: yes<- include or exclude >>>>>>> memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>>>>>> arrtibuteToMath: fgdn >>>>>>> expressionToMatch: ^www[1-9]+\.example\.com >>>>>>> >>>>>>> >>>>>>> Or something along those lines... >>>>>> It's a nice logical layout, but it would be hard for an >>>>>> administrator >>>>>> to figure out what exactly would happen if they were to add a host >>>>>> with a specific hostname. Since the config is spread over so many >>>>>> entries, one would have to look at the top level config entry to >>>>>> find >>>>>> each rule DN, fetch each rule DN to look at the regexes. All of the >>>>>> information is so spread out that you can't just look in one >>>>>> place to >>>>>> see the rules that will be used. This could make things difficult >>>>>> from a troubleshooting perspective. >>>>> This should not be viewed in raw. THe UI and CLi should come to the >>>>> rescue. >>>>> I am not sure that this is a right approach to mix readability and >>>>> normalization. >>>>> To follow this logic no-one would ever normalize data in any DB >>>>> due to >>>>> the claim that it would be hard to join tables. >>>> The feature is implemented outside of the UI, and I would like to be >>>> able to troubleshoot it without the UI without a ton of hassle. >>>> Ultimately, it is a DS plug-in, and we should be able to troubleshoot >>>> it easily as a single component instead of requiring the UI to >>>> understand what it is doing. We have run into this same issue with >>>> things like access control since ACI attributes can live anywhere in >>>> the database. It is for this reason that we have things like the get >>>> effective rights control for evaluating settings. >>>> >>>> If one adds an inclusion rule, but doesn't realize that an exclusion >>>> rule is overriding it, they could easily get confused. I understand >>>> that we want the UI to be able to notice this and present it to the >>>> user, but there is plenty of room for error in the UI as we add more >>>> and more logic into it. >>>> >>>> I am not totally opposed to this approach, but I want to point out >>>> some of the downsides in going in this direction. I usually like to >>>> make the internal representation of plug-in configuration closely >>>> mirror the layout of the configuration entries/attributes >>>> themselves. In this case, it would be highly inefficient to do so. >>>> Internally to the plug-in, we will be representing the config for a >>>> specific object type as a single struct with a list of all inclusive >>>> and exclusive rules. I can convert multiple config entries into this >>>> same internal format, but it is something I generally like to avoid. >>>> >>>> I will look into this approach further. I have the current approach >>>> from the design document implemented and working at this point, so >>>> some surgery will be required to go back to a different configuration >>>> layout. Parsing and loading the configuration when it is split >>>> across so many dependent entries is not going to be trivial. I can >>>> see plenty of corner cases in configuration validation cropping up. >>>> Dynamic config changes will also be more difficult to handle, as we >>>> will have to back track to find what config entries reference a >>>> modified rule. >>>>>> The description issue is a tough one to deal with if we have the >>>>>> config in the form that is currently described in the design doc. >>>>>> Since we want a description per regex rule, we should need to >>>>>> make the >>>>>> description be a part of the regex rule value instead of a separate >>>>>> description attribute. I don't necessarily like this approach, >>>>>> as the >>>>>> readability of the config will not be nice. >>>>>> >>>>> I think this tips the scale towards the approach I proposed. >>>> Yes, it does. >>> I started writing up some notes to map out how we would represent the >>> configuration with this split out approach. We would have one top >>> level config entry per filter/scope. Child entries would be >>> inclusive/exclusive rule entries. We sould load all child entries as >>> regex rules, so we don't need pointers to each regex entry in the >>> top-level entry. Here is an example: >>> >>> ------------------------------------------------------------------------------------------------- >>> >>> >>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>> objectclass: autoMemberDefinition >>> autoMemberScope: dc=example,dc=com >>> autoMemberFilter: objectclass=ipaHost >>> autoMemberGroupingAttr: member:dn >>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>> >>> dn: cn=www 5,cn=Hostgroups,cn=Auto Membership >>> Plugin,cn=plugins,cn=config >>> objectclass: autoMemberRegexRule >>> description: exclude www5 from being added to webservers >>> autoMemberRegexType: exclusive >>> autoMemberRegexAttr: fqdn >>> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>> autoMemberRegex: ^www5\.example\.com >>> >>> dn: cn=www hosts,cn=Hostgroups,cn=Auto Membership >>> Plugin,cn=plugins,cn=config >>> objectclass: autoMemberRegexRule >>> description: include www hosts in webservers >>> autoMemberRegexType: inclusive >>> autoMemberRegexAttr: fqdn >>> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>> autoMemberRegex: ^www[1-9]+\.example\.com >>> >>> dn: cn=web hosts,cn=Hostgroups,cn=Auto Membership >>> Plugin,cn=plugins,cn=config >>> objectclass: autoMemberRegexRule >>> description: include web hosts in webservers >>> autoMemberRegexType: inclusive >>> autoMemberRegexAttr: fqdn >>> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>> autoMemberRegex: ^web[1-9]+\.example\.com >>> >>> dn: cn=mail hosts,cn=Hostgroups,cn=Auto Membership >>> Plugin,cn=plugins,cn=config >>> objectclass: autoMemberRegexRule >>> description: include mail hosts in mailservers >>> autoMemberRegexType: inclusive >>> autoMemberRegexAttr: fqdn >>> autoMemberTargetGroup: cn=mailservers,cn=hostgroups,dc=example,dc=com >>> autoMemberRegex: ^mail[1-9]+\.example\.com >>> ------------------------------------------------------------------------------------------------- >>> >>> >>> >>> What I don't like about this approach is that the first 3 regex rules >>> really belong together, as they all have to do with webservers. It >>> makes sense to split out the mail hosts regex since it is logically >>> different. If you have the case where your hosts have hostnames that >>> don't follow any sort of format, you may end up having many inclusive >>> rule entries for all of your different webservers. I see that as >>> being a headache in many cases. Keep in mind that the above is a very >>> simple example. You would likely have many more entries in an actual >>> deployment. >>> >>> To alleviate this problem, we could make the autoMemberRegex attribute >>> multi-valued, but you would only have one description per regex rule >>> entry, not per regex. This is more flexible, as administrators could >>> choose when to group regexes together vs. having them separate. The >>> only real advantage is to add a description to a group of regex rules >>> though. >>> >>> This is all equivalent to the following config with the method >>> described in the design doc (without the ability to have descriptions): >>> >>> ------------------------------------------------------------------------------------------------- >>> >>> >>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>> objectclass: autoMemberDefinition >>> autoMemberScope: dc=example,dc=com >>> autoMemberFilter: objectclass=ipaHost >>> autoMemberExclusiveRegex: >>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com >>> autoMemberInclusiveRegex: >>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com >>> >>> autoMemberInclusiveRegex: >>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com >>> >>> autoMemberInclusiveRegex: >>> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com >>> >>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>> autoMemberGroupingAttr: member:dn >>> ------------------------------------------------------------------------------------------------- >>> >>> >>> >> >> Or you can go the other way around and eliminate the top level entry: >> >> dn: cn=www 5,cn=Hostgroups,cn=Auto Membership >> Plugin,cn=plugins,cn=config >> objectclass: autoMemberRegexRule >> description: exclude www5 from being added to webservers >> autoMemberScope: dc=example,dc=com >> autoMemberFilter: objectclass=ipaHost >> autoMemberGroupingAttr: member:dn >> autoMemberRegexType: exclusive >> autoMemberRegexAttr: fqdn >> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >> autoMemberRegex: ^www5\.example\.com >> >> >> If you need to express the default entry you can say >> >> dn: cn=default,cn=Hostgroups,cn=Auto Membership >> Plugin,cn=plugins,cn=config >> objectclass: autoMemberRegexRule >> description: default catch all rule for Hosts >> autoMemberScope: dc=example,dc=com >> autoMemberFilter: objectclass=ipaHost >> autoMemberGroupingAttr: member:dn >> autoMemberRegexType: default >> autoMemberTargetGroup: cn=orpahns,cn=hostgroups,dc=example,dc=com >> >> Then you read all the entries, sort them buy "exclusive, inclusive, >> default" and handle accordingly. >> That will create a little bit more duplication of data but will be >> readable and manageable in a raw form. > Why not just leave the config the way I have it now then? There's > nothing preventing you from creating multiple config entries for the > same scope/filter/grouping attr. > > Right now, I use a single struct for each config entry, even if you > defined multiple entries with the same scope/filter/grouping attr. > Each config entry is processed independently of other config entries. > You can't have an exclusion in one config entry that overrides an > inclusion from another config entry. If we want multiple config > entries to interact in this way, I would need to group and order > inclusion rules from multiple config entries that have the same exact > scope/filter/grouping attr values into a single struct when parsing > and loading the config. This can be done, but we need to handle > things such as duplicate regex rules. > > The reason I like the single struct approach is that I only need to do > a filter check against an entry being added for each config entry. If > we don't handle it this way internally, we would end up checking the > filter and scope from each and every config entry against every entry > added to DS. This would mean 100 filter checks for 100 regex rules. > This obviously can't be done this way for performance reasons. We can > make the internal representation differ from the presentation as > config entries, but I find that this introduces room for confusion in > how the plug-in will work for a given configuration. > > I still feel that this is adding a lot of complexity (and room for > bugs) for very little value. The main downside with the current > approach is that we don't have a way to have a description per regex, > right? Is there some other downside here? Maybe we can solve the > description issue without the additional complexity if that is the > only requirement that is lacking in the current approach. So how you are going to deal with two colliding config entries now or you think there will be single config entry for the whole plugin? If not than there can be colliding config entries that you would have to process anyways. But I am not insisting. I understand your arguments, I am not sure I agree with all of them but you have much more experience in the area than I do. Let us not fix something that is not broken. We can add description to the Regex attribute. It won't be the first time. ACI is like that. >> >> >>> -NGK >>>>>> _______________________________________________ >>>>>> Freeipa-users mailing list >>>>>> Freeipa-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> >>>>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From nkinder at redhat.com Mon Apr 11 22:11:00 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 11 Apr 2011 15:11:00 -0700 Subject: [Freeipa-devel] [Freeipa-users] Auto membership plugin In-Reply-To: <4DA37843.9090303@redhat.com> References: <4D93295E.1030507@redhat.com> <4D935DF6.9060408@redhat.com> <4D93663C.3000109@redhat.com> <4D94A08E.9050804@redhat.com> <4D94D5E9.4020900@redhat.com> <4D94DE14.5010604@redhat.com> <4D9F32B3.1070501@redhat.com> <4DA31DE3.8070608@redhat.com> <4DA33976.2010201@redhat.com> <4DA3412A.4070307@redhat.com> <4DA3493E.6080102@redhat.com> <4DA34F9D.7020705@redhat.com> <4DA370C0.2050203@redhat.com> <4DA37843.9090303@redhat.com> Message-ID: <4DA37C74.7020200@redhat.com> On 04/11/2011 02:53 PM, Dmitri Pal wrote: > On 04/11/2011 05:21 PM, Nathan Kinder wrote: >> On 04/11/2011 11:59 AM, Dmitri Pal wrote: >>> On 04/11/2011 02:32 PM, Nathan Kinder wrote: >>>> On 04/11/2011 10:58 AM, Nathan Kinder wrote: >>>>> On 04/11/2011 10:25 AM, Dmitri Pal wrote: >>>>>> On 04/11/2011 11:27 AM, Nathan Kinder wrote: >>>>>>> On 04/08/2011 09:07 AM, Dmitri Pal wrote: >>>>>>>> On 04/08/2011 11:49 AM, JR Aquino wrote: >>>>>>>>> Is there any way to capture a description associated with the >>>>>>>>> regex >>>>>>>>> -> group mapping? >>>>>>>>> >>>>>>>>> I was thinking that after time, it would be important to look back >>>>>>>>> on rules and know why they were put there. >>>>>>>>> >>>>>>>>> Particularly in the case of regex, since it may not be completely >>>>>>>>> obvious by looking back at alphabet soup. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-users mailing list >>>>>>>>> Freeipa-users at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>> >>>>>>>>> >>>>>>>> The more I think about current design the more I want to normalize >>>>>>>> things. >>>>>>>> I would rather instead of: >>>>>>>> >>>>>>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>>>> objectclass: autoMemberDefinition >>>>>>>> autoMemberScope: dc=example,dc=com >>>>>>>> autoMemberFilter: objectclass=ipaHost >>>>>>>> autoMemberExclusiveRegex: >>>>>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com >>>>>>>> >>>>>>>> >>>>>>>> autoMemberInclusiveRegex: >>>>>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com >>>>>>>> >>>>>>>> >>>>>>>> autoMemberInclusiveRegex: >>>>>>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com >>>>>>>> >>>>>>>> >>>>>>>> autoMemberInclusiveRegex: >>>>>>>> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com >>>>>>>> >>>>>>>> >>>>>>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>>>>>> autoMemberGroupingAttr: member:dn >>>>>>>> >>>>>>>> >>>>>>>> Have something like: >>>>>>>> >>>>>>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>>>> objectclass: autoMemberDefinition >>>>>>>> objectclass: cnContainer >>>>>>>> autoMemberScope: dc=example,dc=com >>>>>>>> autoMemberFilter: objectclass=ipaHost >>>>>>>> autoMemberRegexRule: cn=Webserver Inclusion >>>>>>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>>>> autoMemberRegexRule: cn=Mailserver Inclusion >>>>>>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>>>>>> autoMemberRegexRule: cn=Desktop exclusion >>>>>>>> Rule,cn=Hostgroups,cn=Auto >>>>>>>> Membership Plugin,cn=plugins,cn=config >>>>>>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>>>>>> autoMemberGroupingAttr: member:dn >>>>>>>> >>>>>>>> >>>>>>>> dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership >>>>>>>> Plugin,cn=plugins,cn=config >>>>>>>> objectclass: autoMemberDefinitionRegexRule >>>>>>>> cn: Webserver Inclusion Rule >>>>>>>> description: Rule contains regular expression to include webserver >>>>>>>> hosts into the webserver group. >>>>>>>> include: yes<- include or exclude >>>>>>>> memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>>>>>>> arrtibuteToMath: fgdn >>>>>>>> expressionToMatch: ^www[1-9]+\.example\.com >>>>>>>> >>>>>>>> >>>>>>>> Or something along those lines... >>>>>>> It's a nice logical layout, but it would be hard for an >>>>>>> administrator >>>>>>> to figure out what exactly would happen if they were to add a host >>>>>>> with a specific hostname. Since the config is spread over so many >>>>>>> entries, one would have to look at the top level config entry to >>>>>>> find >>>>>>> each rule DN, fetch each rule DN to look at the regexes. All of the >>>>>>> information is so spread out that you can't just look in one >>>>>>> place to >>>>>>> see the rules that will be used. This could make things difficult >>>>>>> from a troubleshooting perspective. >>>>>> This should not be viewed in raw. THe UI and CLi should come to the >>>>>> rescue. >>>>>> I am not sure that this is a right approach to mix readability and >>>>>> normalization. >>>>>> To follow this logic no-one would ever normalize data in any DB >>>>>> due to >>>>>> the claim that it would be hard to join tables. >>>>> The feature is implemented outside of the UI, and I would like to be >>>>> able to troubleshoot it without the UI without a ton of hassle. >>>>> Ultimately, it is a DS plug-in, and we should be able to troubleshoot >>>>> it easily as a single component instead of requiring the UI to >>>>> understand what it is doing. We have run into this same issue with >>>>> things like access control since ACI attributes can live anywhere in >>>>> the database. It is for this reason that we have things like the get >>>>> effective rights control for evaluating settings. >>>>> >>>>> If one adds an inclusion rule, but doesn't realize that an exclusion >>>>> rule is overriding it, they could easily get confused. I understand >>>>> that we want the UI to be able to notice this and present it to the >>>>> user, but there is plenty of room for error in the UI as we add more >>>>> and more logic into it. >>>>> >>>>> I am not totally opposed to this approach, but I want to point out >>>>> some of the downsides in going in this direction. I usually like to >>>>> make the internal representation of plug-in configuration closely >>>>> mirror the layout of the configuration entries/attributes >>>>> themselves. In this case, it would be highly inefficient to do so. >>>>> Internally to the plug-in, we will be representing the config for a >>>>> specific object type as a single struct with a list of all inclusive >>>>> and exclusive rules. I can convert multiple config entries into this >>>>> same internal format, but it is something I generally like to avoid. >>>>> >>>>> I will look into this approach further. I have the current approach >>>>> from the design document implemented and working at this point, so >>>>> some surgery will be required to go back to a different configuration >>>>> layout. Parsing and loading the configuration when it is split >>>>> across so many dependent entries is not going to be trivial. I can >>>>> see plenty of corner cases in configuration validation cropping up. >>>>> Dynamic config changes will also be more difficult to handle, as we >>>>> will have to back track to find what config entries reference a >>>>> modified rule. >>>>>>> The description issue is a tough one to deal with if we have the >>>>>>> config in the form that is currently described in the design doc. >>>>>>> Since we want a description per regex rule, we should need to >>>>>>> make the >>>>>>> description be a part of the regex rule value instead of a separate >>>>>>> description attribute. I don't necessarily like this approach, >>>>>>> as the >>>>>>> readability of the config will not be nice. >>>>>>> >>>>>> I think this tips the scale towards the approach I proposed. >>>>> Yes, it does. >>>> I started writing up some notes to map out how we would represent the >>>> configuration with this split out approach. We would have one top >>>> level config entry per filter/scope. Child entries would be >>>> inclusive/exclusive rule entries. We sould load all child entries as >>>> regex rules, so we don't need pointers to each regex entry in the >>>> top-level entry. Here is an example: >>>> >>>> ------------------------------------------------------------------------------------------------- >>>> >>>> >>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>> objectclass: autoMemberDefinition >>>> autoMemberScope: dc=example,dc=com >>>> autoMemberFilter: objectclass=ipaHost >>>> autoMemberGroupingAttr: member:dn >>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>> >>>> dn: cn=www 5,cn=Hostgroups,cn=Auto Membership >>>> Plugin,cn=plugins,cn=config >>>> objectclass: autoMemberRegexRule >>>> description: exclude www5 from being added to webservers >>>> autoMemberRegexType: exclusive >>>> autoMemberRegexAttr: fqdn >>>> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>>> autoMemberRegex: ^www5\.example\.com >>>> >>>> dn: cn=www hosts,cn=Hostgroups,cn=Auto Membership >>>> Plugin,cn=plugins,cn=config >>>> objectclass: autoMemberRegexRule >>>> description: include www hosts in webservers >>>> autoMemberRegexType: inclusive >>>> autoMemberRegexAttr: fqdn >>>> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>>> autoMemberRegex: ^www[1-9]+\.example\.com >>>> >>>> dn: cn=web hosts,cn=Hostgroups,cn=Auto Membership >>>> Plugin,cn=plugins,cn=config >>>> objectclass: autoMemberRegexRule >>>> description: include web hosts in webservers >>>> autoMemberRegexType: inclusive >>>> autoMemberRegexAttr: fqdn >>>> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>>> autoMemberRegex: ^web[1-9]+\.example\.com >>>> >>>> dn: cn=mail hosts,cn=Hostgroups,cn=Auto Membership >>>> Plugin,cn=plugins,cn=config >>>> objectclass: autoMemberRegexRule >>>> description: include mail hosts in mailservers >>>> autoMemberRegexType: inclusive >>>> autoMemberRegexAttr: fqdn >>>> autoMemberTargetGroup: cn=mailservers,cn=hostgroups,dc=example,dc=com >>>> autoMemberRegex: ^mail[1-9]+\.example\.com >>>> ------------------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> What I don't like about this approach is that the first 3 regex rules >>>> really belong together, as they all have to do with webservers. It >>>> makes sense to split out the mail hosts regex since it is logically >>>> different. If you have the case where your hosts have hostnames that >>>> don't follow any sort of format, you may end up having many inclusive >>>> rule entries for all of your different webservers. I see that as >>>> being a headache in many cases. Keep in mind that the above is a very >>>> simple example. You would likely have many more entries in an actual >>>> deployment. >>>> >>>> To alleviate this problem, we could make the autoMemberRegex attribute >>>> multi-valued, but you would only have one description per regex rule >>>> entry, not per regex. This is more flexible, as administrators could >>>> choose when to group regexes together vs. having them separate. The >>>> only real advantage is to add a description to a group of regex rules >>>> though. >>>> >>>> This is all equivalent to the following config with the method >>>> described in the design doc (without the ability to have descriptions): >>>> >>>> ------------------------------------------------------------------------------------------------- >>>> >>>> >>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >>>> objectclass: autoMemberDefinition >>>> autoMemberScope: dc=example,dc=com >>>> autoMemberFilter: objectclass=ipaHost >>>> autoMemberExclusiveRegex: >>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com >>>> autoMemberInclusiveRegex: >>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com >>>> >>>> autoMemberInclusiveRegex: >>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com >>>> >>>> autoMemberInclusiveRegex: >>>> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com >>>> >>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >>>> autoMemberGroupingAttr: member:dn >>>> ------------------------------------------------------------------------------------------------- >>>> >>>> >>>> >>> Or you can go the other way around and eliminate the top level entry: >>> >>> dn: cn=www 5,cn=Hostgroups,cn=Auto Membership >>> Plugin,cn=plugins,cn=config >>> objectclass: autoMemberRegexRule >>> description: exclude www5 from being added to webservers >>> autoMemberScope: dc=example,dc=com >>> autoMemberFilter: objectclass=ipaHost >>> autoMemberGroupingAttr: member:dn >>> autoMemberRegexType: exclusive >>> autoMemberRegexAttr: fqdn >>> autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >>> autoMemberRegex: ^www5\.example\.com >>> >>> >>> If you need to express the default entry you can say >>> >>> dn: cn=default,cn=Hostgroups,cn=Auto Membership >>> Plugin,cn=plugins,cn=config >>> objectclass: autoMemberRegexRule >>> description: default catch all rule for Hosts >>> autoMemberScope: dc=example,dc=com >>> autoMemberFilter: objectclass=ipaHost >>> autoMemberGroupingAttr: member:dn >>> autoMemberRegexType: default >>> autoMemberTargetGroup: cn=orpahns,cn=hostgroups,dc=example,dc=com >>> >>> Then you read all the entries, sort them buy "exclusive, inclusive, >>> default" and handle accordingly. >>> That will create a little bit more duplication of data but will be >>> readable and manageable in a raw form. >> Why not just leave the config the way I have it now then? There's >> nothing preventing you from creating multiple config entries for the >> same scope/filter/grouping attr. >> >> Right now, I use a single struct for each config entry, even if you >> defined multiple entries with the same scope/filter/grouping attr. >> Each config entry is processed independently of other config entries. >> You can't have an exclusion in one config entry that overrides an >> inclusion from another config entry. If we want multiple config >> entries to interact in this way, I would need to group and order >> inclusion rules from multiple config entries that have the same exact >> scope/filter/grouping attr values into a single struct when parsing >> and loading the config. This can be done, but we need to handle >> things such as duplicate regex rules. >> >> The reason I like the single struct approach is that I only need to do >> a filter check against an entry being added for each config entry. If >> we don't handle it this way internally, we would end up checking the >> filter and scope from each and every config entry against every entry >> added to DS. This would mean 100 filter checks for 100 regex rules. >> This obviously can't be done this way for performance reasons. We can >> make the internal representation differ from the presentation as >> config entries, but I find that this introduces room for confusion in >> how the plug-in will work for a given configuration. >> >> I still feel that this is adding a lot of complexity (and room for >> bugs) for very little value. The main downside with the current >> approach is that we don't have a way to have a description per regex, >> right? Is there some other downside here? Maybe we can solve the >> description issue without the additional complexity if that is the >> only requirement that is lacking in the current approach. > So how you are going to deal with two colliding config entries now or > you think there will be single config entry for the whole plugin? > If not than there can be colliding config entries that you would have to > process anyways. Each config entry is independent. Collisions are possible, but they should be minimized since the approach minimizes the need to create multiple config entries for the same type of object. A collision is not horrible to deal with, as the plug-in will gracefully handle the case where it adds the same entry as a member when it is already a member. > But I am not insisting. I understand your arguments, I am not sure I > agree with all of them but you have much more experience in the area > than I do. > Let us not fix something that is not broken. We can add description to > the Regex attribute. It won't be the first time. ACI is like that. I'm not insisting on my way either. I think we can still have the UI represent the data the way you are thinking without any additional work over your suggested approach. Since I have the implementation nearly finished, I'll get a test copy out for developers to play with later this week. If we find that we want to change it up, we can do that. > > >>> >>>> -NGK >>>>>>> _______________________________________________ >>>>>>> Freeipa-users mailing list >>>>>>> Freeipa-users at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> > From mkosek at redhat.com Tue Apr 12 07:35:30 2011 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 12 Apr 2011 09:35:30 +0200 Subject: [Freeipa-devel] [PATCH] 764 update ipa-client-install man page In-Reply-To: <4DA341BE.9080104@redhat.com> References: <4D9A36E3.5010207@redhat.com> <1301999640.20811.5.camel@dhcp-25-52.brq.redhat.com> <4D9F40CE.40103@redhat.com> <1302511157.7619.9.camel@dhcp-25-52.brq.redhat.com> <4DA341BE.9080104@redhat.com> Message-ID: <1302593730.28122.0.camel@dhcp-25-52.brq.redhat.com> On Mon, 2011-04-11 at 14:00 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2011-04-08 at 13:07 -0400, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> I don't think it is a good idea to have this option in > >>> ipa-client-install --help at all. > >>> > >>> Since it is not intended to be used by the user and we just use it in > >>> our scripts why would we want to have it in ipa-client-install --help or > >>> man pages? We could just hide it using help=optparse.SUPPRESS_HELP > >>> attribute for the option and document it only in the installation script > >>> source. > >>> > >>> Martin > >>> > >>> On Mon, 2011-04-04 at 17:23 -0400, Rob Crittenden wrote: > >>>> Make it clear that --on-master is for install scripts only. > >>>> > >>>> ticket 1050 > >> > >> An excellent idea. See new patch. > >> > >> rob > > > > Nicely done - we won't confuse the user anymore. > > > > I have a one more issue I didn't notice in the first review - why should > > we allow non-root to run ipa-client-install? It fails in this case. I > > guess this change slipped in the patch only by accident. > > > > Martin > > > > Yeah, updated patch attached. > > rob ACK. Pushed to master, ipa-2-0. Martin From edewata at redhat.com Tue Apr 12 16:09:49 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 12 Apr 2011 11:09:49 -0500 Subject: [Freeipa-devel] [PATCH] 136 Merged IPA.cmd() into IPA.command(). Message-ID: <4DA4794D.4030204@redhat.com> The IPA.cmd() has been merged into IPA.command(). All invocations and test cases have been converted. Ticket #988 Passed JSLint, QUnit and Selenium tests. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0136-Merged-IPA.cmd-into-IPA.command.patch Type: text/x-patch Size: 34611 bytes Desc: not available URL: From JR.Aquino at citrix.com Tue Apr 12 16:45:26 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Tue, 12 Apr 2011 16:45:26 +0000 Subject: [Freeipa-devel] Add sudorule and hbacrule to indirectmemberof attributes of user.py Message-ID: Add HBAC Rule and Sudo Rule to users as indirect member attributes to simplify the auditing of users for their indirect membership to their authorization rights. An Administrator should have the ability to quickly identify the rights a user will have in the system. For example. With the patch added, my user show looks like this: # ipa user-show tester --all dn: uid=builder,cn=users,cn=accounts,dc=example,dc=com User login: tester First name: Tester Last name: Engineering Full name: Tester Engineering Display name: Tester Engineering Initials: TE Home directory: /home/tester GECOS field: Tester Engineering Login shell: /bin/sh Kerberos principal: tester at EXAMPLE.COM UID: 1829800388 GID: 1829800388 Account disabled: False Member of groups: ipausers, auto-dev-deploy-tools, build-integration ipauniqueid: 72fa22c6-6085-11e0-9629-0023aefe4ec0 krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com memberofindirect_HBAC rule: development memberofindirect_Sudo Rule: AUTO-dev-deploy-tools_DEPLOY, AUTO-dev-deploy-tools_ZENOSS, build-integration mepmanagedentry: cn=tester,cn=groups,cn=accounts,dc=example,dc=com objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-indirectmemberof-attrib.patch Type: application/octet-stream Size: 891 bytes Desc: freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-indirectmemberof-attrib.patch URL: From bofh.jr at gmail.com Tue Apr 12 16:45:35 2011 From: bofh.jr at gmail.com (jm k) Date: Tue, 12 Apr 2011 18:45:35 +0200 Subject: [Freeipa-devel] Penrose : where do I submit patches ? Message-ID: Hi, ( * Sorry :his message has nothing to do with freeIPA but the original penrose sites seems to be dead. *) I made some modification to the penrose serveur : - added binary data as jdbc data type ( for jpegphotos), - corrected a typo in some regexp replacement code (leading to unwanted rewrite of source alias names ) ... I would like to know how to submit these patches to upstream for validation/inclusion. Thanks J.-M. From JR.Aquino at citrix.com Tue Apr 12 16:56:09 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Tue, 12 Apr 2011 16:56:09 +0000 Subject: [Freeipa-devel] [PATCH] 24 Add sudorule and hbacrule to indirectmemberof attributes of user.py In-Reply-To: References: Message-ID: <36AD4E47-C1BE-4603-8578-1823F2C89892@citrixonline.com> On Apr 12, 2011, at 9:45 AM, JR Aquino wrote: > Add HBAC Rule and Sudo Rule to users as indirect member attributes to simplify the auditing of users for their indirect membership to their authorization rights. > > An Administrator should have the ability to quickly identify the rights a user will have in the system. > > For example. With the patch added, my user show looks like this: > > # ipa user-show tester --all > dn: uid=builder,cn=users,cn=accounts,dc=example,dc=com > User login: tester > First name: Tester > Last name: Engineering > Full name: Tester Engineering > Display name: Tester Engineering > Initials: TE > Home directory: /home/tester > GECOS field: Tester Engineering > Login shell: /bin/sh > Kerberos principal: tester at EXAMPLE.COM > UID: 1829800388 > GID: 1829800388 > Account disabled: False > Member of groups: ipausers, auto-dev-deploy-tools, build-integration > ipauniqueid: 72fa22c6-6085-11e0-9629-0023aefe4ec0 > krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com > memberofindirect_HBAC rule: development > memberofindirect_Sudo Rule: AUTO-dev-deploy-tools_DEPLOY, AUTO-dev-deploy-tools_ZENOSS, build-integration > mepmanagedentry: cn=tester,cn=groups,cn=accounts,dc=example,dc=com > objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel OPPS, forgot to have PATCH in the subject. From rcritten at redhat.com Tue Apr 12 17:55:13 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Apr 2011 13:55:13 -0400 Subject: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership In-Reply-To: <69A99C7A-56D1-4FC6-9434-CC470E779A82@citrixonline.com> References: <4D94E88C.2090004@redhat.com> <934AB894-09AC-425A-92BD-9BA0B236A21D@citrixonline.com> <8CE5CB9F-4C26-416A-88B4-9EF9B5CB321D@citrixonline.com> <69A99C7A-56D1-4FC6-9434-CC470E779A82@citrixonline.com> Message-ID: <4DA49201.9090605@redhat.com> JR Aquino wrote: > On Apr 7, 2011, at 7:08 PM, JR Aquino wrote: > >> >> On Apr 7, 2011, at 4:04 PM, JR Aquino wrote: >> >>> On Apr 7, 2011, at 3:42 PM, JR Aquino wrote: >>> >>>> On Mar 31, 2011, at 2:16 PM, JR Aquino wrote: >>>> >>>>> On Mar 31, 2011, at 1:48 PM, Rob Crittenden wrote: >>>>> >>>>>> JR Aquino wrote: >>>>>>> The following patch Removes around 20 lines of code and provides a substantial increase in performance for FreeIPA member/memberof verification searches. >>>>>>> >>>>>>> The current code base blindly searches static containers for the possible presence of members. >>>>>>> >>>>>>> This patch provides a method for dynamically identifying the specific objects to verify memberships for. >>>>>>> >>>>>>> The attached patch addresses ticket: >>>>>>> https://fedorahosted.org/freeipa/ticket/1139 >>>>>>> >>>>>>> >>>>>>> >>>>>>> ipa hostgroup-find >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> ----------------------------- >>>>>>> Number of entries returned 52 >>>>>>> ----------------------------- >>>>>>> >>>>>>> real 0m20.054s >>>>>>> user 0m0.934s >>>>>>> sys 0m0.050s >>>>>>> >>>>>>> >>>>>>> ipa find-hostgroup >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> ----------------------------- >>>>>>> Number of entries returned 52 >>>>>>> ----------------------------- >>>>>>> >>>>>>> real 0m15.064s >>>>>>> user 0m0.945s >>>>>>> sys 0m0.057s >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> Number of entries returned 100 >>>>>>> ------------------------------ >>>>>>> >>>>>>> real 0m16.471s >>>>>>> user 0m0.814s >>>>>>> sys 0m0.040s >>>>>>> >>>>>>> >>>>>>> ipa host-find >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> ------------------------------ >>>>>>> Number of entries returned 100 >>>>>>> ------------------------------ >>>>>>> >>>>>>> real 0m41.277s >>>>>>> user 0m0.806s >>>>>>> sys 0m0.060s >>>>>>> >>>>>>> >>>>>>> ipa host-find >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> ------------------------------ >>>>>>> Number of entries returned 100 >>>>>>> ------------------------------ >>>>>>> >>>>>>> real 0m16.385s >>>>>>> user 0m0.814s >>>>>>> sys 0m0.053s >>>>>> >>>>>> There is a typo in the first block, memeber. >>>>>> >>>>>> Wouldn't it be clearer to do a negative test to continue: >>>>>> >>>>>> if not 'member' in r[1]: >>>>>> continue >>>>>> >>>>>> rob >>>>> >>>>> You're right! >>>>> >>>>> Corrected patch attached. >>>> >>>> Self Nack >>>> >>>> After cli and webui testing, it turned out there was a previous try / except block that was reseting the results value back to [] >>>> >>>> Corrected and reattaching new patch. >>>> >>>> Testing cli and webui checks out correctly. Speed AND accuracy are now addressed. >>>> >>>> It was also discovered during the course of testing that this patch addresses one of the causes for the bug thrown in: https://fedorahosted.org/freeipa/ticket/1133 >>>> >>>> -JR >>> >>> NACK >>> >>> Looks like there may still need to be work with the indirect / direct functions. >>> >>> Will revisit next week. >> >> Ok I finally think I've got it. >> >> My for loop was in my try / except block. It has now been corrected. >> >> I've tested the searches for: users, groups, sudocmds, sudcmdgroups, sudorules, hosts, hostgroups, hbacrules, hbacsv, hbsvcgroups, and all return as expected. >> >> Please make sure that they return for you as well. >> Please let me know if there is anything else I have missed. > > Final Patch attached due to relationship with ticket 1133: > > Added Comments regarding Ticket 1133 / calculating indirect: > > + # If there is an exception here, it is due to a failure in referential integrity. > + # All members should have corresponding memberOf entries. > > Retested against all xmlrpc tests and passed. Seems to work as advertised, I just have a couple of requests: - Some of the comments are really long, can you limit to ~75 chars per line? - In this code block: for r in results: direct.append(r[0]) try: indirect.remove(r[0].lower()) except ValueError: pass We should log if a ValueError is thrown, this would mean something is really wrong. Can you import logging in the file and replace pass with something like: logging.info('Failed to remove indirect entry %s from %s' % r[0], entry_dn) I wonder if we should raise the ValueError too. This means that something went very wrong. rob From JR.Aquino at citrix.com Tue Apr 12 18:40:54 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Tue, 12 Apr 2011 18:40:54 +0000 Subject: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership In-Reply-To: <4DA49201.9090605@redhat.com> References: <4D94E88C.2090004@redhat.com> <934AB894-09AC-425A-92BD-9BA0B236A21D@citrixonline.com> <8CE5CB9F-4C26-416A-88B4-9EF9B5CB321D@citrixonline.com> <69A99C7A-56D1-4FC6-9434-CC470E779A82@citrixonline.com> <4DA49201.9090605@redhat.com> Message-ID: <80D35ED5-84DD-4EBD-BED2-68B14DF8AD12@citrixonline.com> On Apr 12, 2011, at 10:55 AM, Rob Crittenden wrote: > JR Aquino wrote: >> On Apr 7, 2011, at 7:08 PM, JR Aquino wrote: >> >>> >>> On Apr 7, 2011, at 4:04 PM, JR Aquino wrote: >>> >>>> On Apr 7, 2011, at 3:42 PM, JR Aquino wrote: >>>> >>>>> On Mar 31, 2011, at 2:16 PM, JR Aquino wrote: >>>>> >>>>>> On Mar 31, 2011, at 1:48 PM, Rob Crittenden wrote: >>>>>> >>>>>>> JR Aquino wrote: >>>>>>>> The following patch Removes around 20 lines of code and provides a substantial increase in performance for FreeIPA member/memberof verification searches. >>>>>>>> >>>>>>>> The current code base blindly searches static containers for the possible presence of members. >>>>>>>> >>>>>>>> This patch provides a method for dynamically identifying the specific objects to verify memberships for. >>>>>>>> >>>>>>>> The attached patch addresses ticket: >>>>>>>> https://fedorahosted.org/freeipa/ticket/1139 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ipa hostgroup-find >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> ----------------------------- >>>>>>>> Number of entries returned 52 >>>>>>>> ----------------------------- >>>>>>>> >>>>>>>> real 0m20.054s >>>>>>>> user 0m0.934s >>>>>>>> sys 0m0.050s >>>>>>>> >>>>>>>> >>>>>>>> ipa find-hostgroup >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> ----------------------------- >>>>>>>> Number of entries returned 52 >>>>>>>> ----------------------------- >>>>>>>> >>>>>>>> real 0m15.064s >>>>>>>> user 0m0.945s >>>>>>>> sys 0m0.057s >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> Number of entries returned 100 >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> real 0m16.471s >>>>>>>> user 0m0.814s >>>>>>>> sys 0m0.040s >>>>>>>> >>>>>>>> >>>>>>>> ipa host-find >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> Number of entries returned 100 >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> real 0m41.277s >>>>>>>> user 0m0.806s >>>>>>>> sys 0m0.060s >>>>>>>> >>>>>>>> >>>>>>>> ipa host-find >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> Number of entries returned 100 >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> real 0m16.385s >>>>>>>> user 0m0.814s >>>>>>>> sys 0m0.053s >>>>>>> >>>>>>> There is a typo in the first block, memeber. >>>>>>> >>>>>>> Wouldn't it be clearer to do a negative test to continue: >>>>>>> >>>>>>> if not 'member' in r[1]: >>>>>>> continue >>>>>>> >>>>>>> rob >>>>>> >>>>>> You're right! >>>>>> >>>>>> Corrected patch attached. >>>>> >>>>> Self Nack >>>>> >>>>> After cli and webui testing, it turned out there was a previous try / except block that was reseting the results value back to [] >>>>> >>>>> Corrected and reattaching new patch. >>>>> >>>>> Testing cli and webui checks out correctly. Speed AND accuracy are now addressed. >>>>> >>>>> It was also discovered during the course of testing that this patch addresses one of the causes for the bug thrown in: https://fedorahosted.org/freeipa/ticket/1133 >>>>> >>>>> -JR >>>> >>>> NACK >>>> >>>> Looks like there may still need to be work with the indirect / direct functions. >>>> >>>> Will revisit next week. >>> >>> Ok I finally think I've got it. >>> >>> My for loop was in my try / except block. It has now been corrected. >>> >>> I've tested the searches for: users, groups, sudocmds, sudcmdgroups, sudorules, hosts, hostgroups, hbacrules, hbacsv, hbsvcgroups, and all return as expected. >>> >>> Please make sure that they return for you as well. >>> Please let me know if there is anything else I have missed. >> >> Final Patch attached due to relationship with ticket 1133: >> >> Added Comments regarding Ticket 1133 / calculating indirect: >> >> + # If there is an exception here, it is due to a failure in referential integrity. >> + # All members should have corresponding memberOf entries. >> >> Retested against all xmlrpc tests and passed. > > Seems to work as advertised, I just have a couple of requests: > > - Some of the comments are really long, can you limit to ~75 chars per line? > - In this code block: > > for r in results: > direct.append(r[0]) > try: > indirect.remove(r[0].lower()) > except ValueError: > pass > > We should log if a ValueError is thrown, this would mean something is really wrong. Can you import logging in the file and replace pass with something like: > > logging.info('Failed to remove indirect entry %s from %s' % r[0], entry_dn) > > I wonder if we should raise the ValueError too. This means that something went very wrong. Yes I agree that we should raise the error. Here is the patch with the requested changes: * Fixed width to be PEP8 compliant * import logging * Added logging line in exception * Raise ValueError if we blow up during indirect removal. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch Type: application/octet-stream Size: 6409 bytes Desc: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch URL: From dpal at redhat.com Tue Apr 12 19:04:37 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 Apr 2011 15:04:37 -0400 Subject: [Freeipa-devel] Penrose : where do I submit patches ? In-Reply-To: References: Message-ID: <4DA4A245.40109@redhat.com> On 04/12/2011 12:45 PM, jm k wrote: > Hi, > > ( * Sorry :his message has nothing to do with freeIPA but the original > penrose sites seems to be dead. *) > > I made some modification to the penrose serveur : > - added binary data as jdbc data type ( for jpegphotos), > - corrected a typo in some regexp replacement code > (leading to unwanted rewrite of source alias names ) > ... > > I would like to know how to submit these patches to upstream for > validation/inclusion. > Unfortunately this project is abandoned. We are not planning to maintain it at any foreseeable future. The rationale behind integrating with Penrose was originally derived from the requirement to inter-operate with the AD. However after multiple iterations of design we decided to build our solution around Kerberos trusts rather than direct lookups against multiple identity sources. The AD trusts approach though more complex creates less burden on the Linux administrators in the enterprise. Feel free to maintain it if you find it useful. > Thanks > > J.-M. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From edewata at redhat.com Tue Apr 12 19:06:39 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 12 Apr 2011 14:06:39 -0500 Subject: [Freeipa-devel] [PATCH] 137 Entitlement registration. Message-ID: <4DA4A2BF.5070200@redhat.com> The entitlement facet will show the appropriate buttons depending on the entitlement status. If it's not registered, the facet will show a Register button. If it's registered, the facet will show a Consume button. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0137-Entitlement-registration.patch Type: text/x-patch Size: 41832 bytes Desc: not available URL: From rcritten at redhat.com Tue Apr 12 20:56:01 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Apr 2011 16:56:01 -0400 Subject: [Freeipa-devel] [PATCH] 761 Sort entries on *-find commands In-Reply-To: <1301575782.31691.5.camel@dhcp-25-52.brq.redhat.com> References: <4D939D2A.40903@redhat.com> <1301575782.31691.5.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DA4BC61.9050608@redhat.com> Martin Kosek wrote: > On Wed, 2011-03-30 at 17:14 -0400, Rob Crittenden wrote: >> Sort output on find commands based on the baseldap LDAPSearch class. >> >> A couple tests had to be modified to match the new order. >> >> ticket 794 >> >> rob > > The patch works fine except the case when entries are being added in > post_callback. Check this search: > > ipa permission-find --permissions=write > > The result is not sorted. I suggest moving the sort process after the > self.POST_CALLBACKS calls. > > What about performance issues? May somebody want to disable the sorting? > (e.g. --nosort option). > > Martin I think the timing would only be a problem if the sizelimit is made very large. The amount of time with/without sorting was negligible. I think we're safe. rob From mkosek at redhat.com Wed Apr 13 06:37:16 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Apr 2011 08:37:16 +0200 Subject: [Freeipa-devel] [PATCH] 761 Sort entries on *-find commands In-Reply-To: <4DA4BC61.9050608@redhat.com> References: <4D939D2A.40903@redhat.com> <1301575782.31691.5.camel@dhcp-25-52.brq.redhat.com> <4DA4BC61.9050608@redhat.com> Message-ID: <1302676636.28122.15.camel@dhcp-25-52.brq.redhat.com> On Tue, 2011-04-12 at 16:56 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Wed, 2011-03-30 at 17:14 -0400, Rob Crittenden wrote: > >> Sort output on find commands based on the baseldap LDAPSearch class. > >> > >> A couple tests had to be modified to match the new order. > >> > >> ticket 794 > >> > >> rob > > > > The patch works fine except the case when entries are being added in > > post_callback. Check this search: > > > > ipa permission-find --permissions=write > > > > The result is not sorted. I suggest moving the sort process after the > > self.POST_CALLBACKS calls. > > > > What about performance issues? May somebody want to disable the sorting? > > (e.g. --nosort option). > > > > Martin > > I think the timing would only be a problem if the sizelimit is made very > large. The amount of time with/without sorting was negligible. I think > we're safe. > > rob I agree. What do you think about my first comment? The patch fails to sort correctly when the entries are being added in the post_callback. Martin From mkosek at redhat.com Wed Apr 13 10:03:03 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Apr 2011 12:03:03 +0200 Subject: [Freeipa-devel] [PATCH] 9 Fix unitialized variables In-Reply-To: <4DA2F796.8060501@redhat.com> References: <4DA2F796.8060501@redhat.com> Message-ID: <1302688983.28122.16.camel@dhcp-25-52.brq.redhat.com> On Mon, 2011-04-11 at 14:44 +0200, Jan Cholasta wrote: > Fixed unitialized variables in makeapi validate_api. > ACK. Pushed to master, ipa-2-0. Martin From mkosek at redhat.com Wed Apr 13 10:11:24 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Apr 2011 12:11:24 +0200 Subject: [Freeipa-devel] [PATCH] 10 Fix double definition In-Reply-To: <4DA2F88F.4000606@redhat.com> References: <4DA2F88F.4000606@redhat.com> Message-ID: <1302689484.28122.17.camel@dhcp-25-52.brq.redhat.com> On Mon, 2011-04-11 at 14:48 +0200, Jan Cholasta wrote: > Fixed double definition of Command.output_for_cli. > ACK. Pushed to master, ipa-2-0. Martin From mkosek at redhat.com Wed Apr 13 11:04:47 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Apr 2011 13:04:47 +0200 Subject: [Freeipa-devel] [PATCH] 11 Fix unitialized attributes In-Reply-To: <4DA2FD1E.1020209@redhat.com> References: <4DA2FD1E.1020209@redhat.com> Message-ID: <1302692687.28122.19.camel@dhcp-25-52.brq.redhat.com> On Mon, 2011-04-11 at 15:07 +0200, Jan Cholasta wrote: > Fixed unitialized attributes in ipalib.aci.ACI, ipalib.parameters.Data, > ipalib.text.LazyText, ipaserver.install.service.Service and > ipaserver.rpcserver.WSGIExecutioner. > NACK. This patch breaks the build. $ make rpms [snip] if [ "" != "yes" ]; then \ ./makeapi --validate; \ fi Traceback (most recent call last): File "./makeapi", line 281, in sys.exit(main()) File "./makeapi", line 259, in main api.finalize() File "/home/mkosek/freeipa/ipalib/plugable.py", line 574, in finalize self.__do_if_not_done('load_plugins') File "/home/mkosek/freeipa/ipalib/plugable.py", line 384, in __do_if_not_done getattr(self, name)() File "/home/mkosek/freeipa/ipalib/plugable.py", line 526, in load_plugins self.import_plugins('ipalib') File "/home/mkosek/freeipa/ipalib/plugable.py", line 564, in import_plugins raise e AttributeError: locked: cannot set Str.re to None make: *** [version-update] Error 1 Martin From jcholast at redhat.com Wed Apr 13 11:17:24 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 13 Apr 2011 13:17:24 +0200 Subject: [Freeipa-devel] [PATCH] 3 Add ability to specify netmask with IP addresses during installation In-Reply-To: <4DA2DC6F.1000105@redhat.com> References: <4D9068E5.6090209@redhat.com> <4D90920E.3080900@redhat.com> <4D91DD15.8020109@redhat.com> <4D91DDA6.2060304@redhat.com> <4D923DCA.1030900@redhat.com> <4D930AAD.9020209@redhat.com> <4D9F1AFA.8000305@redhat.com> <4DA2DC6F.1000105@redhat.com> Message-ID: <4DA58644.3020506@redhat.com> On 11.4.2011 12:48, Jan Cholasta wrote: > On 8.4.2011 16:26, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 29.3.2011 22:15, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Sorry, forgot to attach the patch. >>>>> >>>> >>>> Is this why you have some blind excepts? >>>> >>>> installutils._IPAddressWithPrefix('192.168.0.1/33') >>>> Traceback (most recent call last): >>>> File "", line 1, in >>>> File "ipaserver/install/installutils.py", line 167, in __init__ >>>> net = netaddr.IPNetwork(addr) >>>> File "/usr/lib/python2.7/site-packages/netaddr/ip/__init__.py", line >>>> 919, in __init__ >>>> implicit_prefix, flags) >>>> File "/usr/lib/python2.7/site-packages/netaddr/ip/__init__.py", line >>>> 782, in parse_ip_network >>>> value = ip._value >>>> UnboundLocalError: local variable 'ip' referenced before assignment >>>> >>>> We should get an upstream bug filed on python-netaddr about this. >>> >>> https://github.com/drkjam/netaddr/issues/closed#issue/5 >>> https://github.com/drkjam/netaddr/issues/closed#issue/6 >>> https://github.com/drkjam/netaddr/issues/closed#issue/8 >>> >>> Apparently it's already been fixed for the next release. >>> >>> IMHO it's not much of an issue for us, because the exception gets caught >>> in parse_ip_address and that's currently the only place where >>> _IPAddressWithPrefix is used. >>> >>>> >>>> Shoudl parse_ip_address() raise an exception on bad data rather than >>>> returning 0.0.0.0? >>> >>> I've been down that road and it would need a rewrite of the fragile IP >>> address handling logic of ipa-server-install, which is something I'd >>> rather avoid. >>> >>>> >>>> >>> installutils.parse_ip_address('355.555.3.3') >>>> _IPAddressWithPrefix('0.0.0.0') >>>> >>>> or >>>> >>>> >>> installutils.parse_ip_address('192.168.0.1/55') >>>> _IPAddressWithPrefix('0.0.0.0') >>>> >>>> Should it disallow net addresses like 192.168.0.0? >>> >>> If you mean network and broadcast addresses, it probably should. It >>> might be a good idea to disallow localhost, multicast and/or link-local >>> addresses too. >> >> Are you going to resubmit the patch with these added or should we open a >> separate ticket? > > I'm going to resubmit it. Right now it disallows loopback, IANA > reserved, link-local, network, multicast and broadcast IP addresses. > Does it make sense to also allow only IP addresses attached to one of > the local network interfaces? Perhaps it would be sufficient just to > print a warning. Or should we not care about that at all? Sending the updated patch. > >> >> rob > > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-3-reverse-zone.patch Type: text/x-patch Size: 20244 bytes Desc: not available URL: From jcholast at redhat.com Wed Apr 13 13:21:00 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 13 Apr 2011 15:21:00 +0200 Subject: [Freeipa-devel] [PATCH] 11 Fix unitialized attributes In-Reply-To: <1302692687.28122.19.camel@dhcp-25-52.brq.redhat.com> References: <4DA2FD1E.1020209@redhat.com> <1302692687.28122.19.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DA5A33C.10209@redhat.com> On 13.4.2011 13:04, Martin Kosek wrote: > On Mon, 2011-04-11 at 15:07 +0200, Jan Cholasta wrote: >> Fixed unitialized attributes in ipalib.aci.ACI, ipalib.parameters.Data, >> ipalib.text.LazyText, ipaserver.install.service.Service and >> ipaserver.rpcserver.WSGIExecutioner. >> > > NACK. This patch breaks the build. > > $ make rpms > [snip] > if [ "" != "yes" ]; then \ > ./makeapi --validate; \ > fi > Traceback (most recent call last): > File "./makeapi", line 281, in > sys.exit(main()) > File "./makeapi", line 259, in main > api.finalize() > File "/home/mkosek/freeipa/ipalib/plugable.py", line 574, in finalize > self.__do_if_not_done('load_plugins') > File "/home/mkosek/freeipa/ipalib/plugable.py", line 384, in > __do_if_not_done > getattr(self, name)() > File "/home/mkosek/freeipa/ipalib/plugable.py", line 526, in > load_plugins > self.import_plugins('ipalib') > File "/home/mkosek/freeipa/ipalib/plugable.py", line 564, in > import_plugins > raise e > AttributeError: locked: cannot set Str.re to None > make: *** [version-update] Error 1 Fixed. > > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-11-uninitialized-attributes.patch Type: text/x-patch Size: 2398 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 13 13:53:59 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Apr 2011 15:53:59 +0200 Subject: [Freeipa-devel] [PATCH] 6 Add lint script for static code analysis In-Reply-To: <4DA305C9.6020800@redhat.com> References: <4D9DD188.6080704@redhat.com> <4DA305C9.6020800@redhat.com> Message-ID: <1302702839.28122.22.camel@dhcp-25-52.brq.redhat.com> On Mon, 2011-04-11 at 15:44 +0200, Jan Cholasta wrote: > On 7.4.2011 17:00, Jan Cholasta wrote: > > This patch adds a script based on pylint for static code analysis during > > build. > > > > https://fedorahosted.org/freeipa/ticket/867 > > > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Improved the script a little bit: > > - The script now exits with non-zero error code if errors were found. > This behavior can be suppressed with the --no-fail option. > - Added --enable-noerror option to enable warnings and other non-error > messages. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. Pushed to master, ipa-2-0. Martin From ayoung at redhat.com Wed Apr 13 14:12:32 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 13 Apr 2011 10:12:32 -0400 Subject: [Freeipa-devel] [PATCH] 137 Entitlement registration. In-Reply-To: <4DA4A2BF.5070200@redhat.com> References: <4DA4A2BF.5070200@redhat.com> Message-ID: <4DA5AF50.5080905@redhat.com> On 04/12/2011 03:06 PM, Endi Sukma Dewata wrote: > The entitlement facet will show the appropriate buttons depending on > the entitlement status. If it's not registered, the facet will show > a Register button. If it's registered, the facet will show a Consume > button. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Please make sure all String literals come from the interal.py messages plugin. New button labels are defined in entitle.js for Consume and Register. The consume dialog should be limited to accepting only integer values: pass the validation pattern in to the text widget. that.entity = function(spec) { We are starting to see a proliferation of code like this: if (spec instanceof Object){ var factory = spec.factory || IPA.entity; entity = factory(spec); } else { var name = spec; entity = IPA.entity({name: name}); } return that; }; Can we pull it into a helper function? In dialog.js the code that.entity = IPA.get_entity(that.entity_name); should happen before init, in the initial construction of the object. The goal is to remove init functions; please don't put any more code into them from here on out. Same thing with Facet in entity.js -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Apr 13 14:15:09 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Apr 2011 16:15:09 +0200 Subject: [Freeipa-devel] [PATCH] Fix lint false positives In-Reply-To: <1302521918.7619.24.camel@dhcp-25-52.brq.redhat.com> References: <4D9DD24A.6000802@redhat.com> <1302521918.7619.24.camel@dhcp-25-52.brq.redhat.com> Message-ID: <1302704109.28122.26.camel@dhcp-25-52.brq.redhat.com> On Mon, 2011-04-11 at 13:38 +0200, Martin Kosek wrote: > On Thu, 2011-04-07 at 17:03 +0200, Jan Cholasta wrote: > > Added changes to the code necesarry for removal of false positives > > reported by the lint script (see my previous patch). > > > > ACK. Along with the previous patch suppressing false positives shows > some real issues in the framework. We should investigate those and > either mark them as false positives or carefully fix them. > > Martin > ACK. Pushed to master, ipa-2-0. Martin From ayoung at redhat.com Wed Apr 13 14:19:35 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 13 Apr 2011 10:19:35 -0400 Subject: [Freeipa-devel] [PATCH] 136 Merged IPA.cmd() into IPA.command(). In-Reply-To: <4DA4794D.4030204@redhat.com> References: <4DA4794D.4030204@redhat.com> Message-ID: <4DA5B0F7.4070400@redhat.com> On 04/12/2011 12:09 PM, Endi Sukma Dewata wrote: > The IPA.cmd() has been merged into IPA.command(). All invocations > and test cases have been converted. > > Ticket #988 > > Passed JSLint, QUnit and Selenium tests. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I'm not a fan of the string concatination in the command calls. I'd prefer to do that inside the IPA.command object, the way it was done in IPA.cmd: { entity:cert method:revoke: ... } and if (spec.entity){ method = spec.entity + spec.method; }else{ method = spec.method; } Other than that, it looks good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Apr 13 14:49:59 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Apr 2011 10:49:59 -0400 Subject: [Freeipa-devel] [PATCH] 761 Sort entries on *-find commands In-Reply-To: <1302676636.28122.15.camel@dhcp-25-52.brq.redhat.com> References: <4D939D2A.40903@redhat.com> <1301575782.31691.5.camel@dhcp-25-52.brq.redhat.com> <4DA4BC61.9050608@redhat.com> <1302676636.28122.15.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DA5B817.9050309@redhat.com> Martin Kosek wrote: > On Tue, 2011-04-12 at 16:56 -0400, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Wed, 2011-03-30 at 17:14 -0400, Rob Crittenden wrote: >>>> Sort output on find commands based on the baseldap LDAPSearch class. >>>> >>>> A couple tests had to be modified to match the new order. >>>> >>>> ticket 794 >>>> >>>> rob >>> >>> The patch works fine except the case when entries are being added in >>> post_callback. Check this search: >>> >>> ipa permission-find --permissions=write >>> >>> The result is not sorted. I suggest moving the sort process after the >>> self.POST_CALLBACKS calls. >>> >>> What about performance issues? May somebody want to disable the sorting? >>> (e.g. --nosort option). >>> >>> Martin >> >> I think the timing would only be a problem if the sizelimit is made very >> large. The amount of time with/without sorting was negligible. I think >> we're safe. >> >> rob > > I agree. > > What do you think about my first comment? The patch fails to sort > correctly when the entries are being added in the post_callback. > > Martin > Ah right, forgot to attach updated patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-761-2-sort.patch Type: text/x-patch Size: 3495 bytes Desc: not available URL: From edewata at redhat.com Wed Apr 13 15:03:53 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 13 Apr 2011 10:03:53 -0500 Subject: [Freeipa-devel] [PATCH] 137 Entitlement registration. In-Reply-To: <4DA5AF50.5080905@redhat.com> References: <4DA4A2BF.5070200@redhat.com> <4DA5AF50.5080905@redhat.com> Message-ID: <4DA5BB59.4040202@redhat.com> On 4/13/2011 9:12 AM, Adam Young wrote: > Please make sure all String literals come from the interal.py messages > plugin. New button labels are defined in entitle.js for Consume and > Register. I'm thinking to do that once we have all the entitlement functionalities implemented. There are also hard-coded button labels in ipa.css which I'm not sure how to remove. Any suggestion? > The consume dialog should be limited to accepting only integer values: > pass the validation pattern in to the text widget. that.entity = > function(spec) { There's no pattern defined in the metadata for the quantity. There is an 'int' type though. I think we can add a general purpose type checking in addition to pattern validation. This can be done in a separate patch. > We are starting to see a proliferation of code like this: > > if (spec instanceof Object){ > var factory = spec.factory || IPA.entity; > entity = factory(spec); > } else { > var name = spec; > entity = IPA.entity({name: name}); > } > return that; > }; > > > Can we pull it into a helper function? I checked the code, there are only 2 instances (in entity.js and search.js) where the structures appear to be identical. Other instances contain slight variation which is difficult to extract. I'd suggest we should try to standardize the invocations first then refactor them into a helper function. > In dialog.js the code that.entity = IPA.get_entity(that.entity_name); > should happen before init, in the initial construction of the object. > The goal is to remove init functions; please don't put any more code > into them from here on out. Same thing with Facet in entity.js See IPA.start_entities(). I don't think that's possible because the entity is only added into IPA.entities_by_name in add_entity() while the constructors are executed before that in the factory() invocation. factory = that.entity_factories[name]; var entity = factory(); add_entity(entity); entity.init(); The entity.init() is executed last, that's why IPA.get_entity() for now can only be invoked during the init() phase. We could pass the entity object instead of entity name in the spec, but that will be a major change. -- Endi S. Dewata From ayoung at redhat.com Wed Apr 13 15:13:25 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 13 Apr 2011 11:13:25 -0400 Subject: [Freeipa-devel] [PATCH] 137 Entitlement registration. In-Reply-To: <4DA5BB59.4040202@redhat.com> References: <4DA4A2BF.5070200@redhat.com> <4DA5AF50.5080905@redhat.com> <4DA5BB59.4040202@redhat.com> Message-ID: <4DA5BD95.6030303@redhat.com> On 04/13/2011 11:03 AM, Endi Sukma Dewata wrote: > On 4/13/2011 9:12 AM, Adam Young wrote: >> Please make sure all String literals come from the interal.py messages >> plugin. New button labels are defined in entitle.js for Consume and >> Register. > > I'm thinking to do that once we have all the entitlement > functionalities implemented. There are also hard-coded button labels > in ipa.css which I'm not sure how to remove. Any suggestion? We'll catch the ipa.css changes in a separate patch. I'll have to take a look. > >> The consume dialog should be limited to accepting only integer values: >> pass the validation pattern in to the text widget. that.entity = >> function(spec) { > > There's no pattern defined in the metadata for the quantity. There is > an 'int' type though. I think we can add a general purpose type > checking in addition to pattern validation. This can be done in a > separate patch. We can add a validation rule [1..9][0..9]* to the entitlement plugin, since it should be a positive integer. > >> We are starting to see a proliferation of code like this: >> >> if (spec instanceof Object){ >> var factory = spec.factory || IPA.entity; >> entity = factory(spec); >> } else { >> var name = spec; >> entity = IPA.entity({name: name}); >> } >> return that; >> }; >> >> >> Can we pull it into a helper function? > > I checked the code, there are only 2 instances (in entity.js and > search.js) where the structures appear to be identical. Other > instances contain slight variation which is difficult to extract. I'd > suggest we should try to standardize the invocations first then > refactor them into a helper function. Sounds good. > >> In dialog.js the code that.entity = IPA.get_entity(that.entity_name); >> should happen before init, in the initial construction of the object. >> The goal is to remove init functions; please don't put any more code >> into them from here on out. Same thing with Facet in entity.js > > See IPA.start_entities(). I don't think that's possible because the > entity is only added into IPA.entities_by_name in add_entity() while > the constructors are executed before that in the factory() invocation. > > factory = that.entity_factories[name]; > var entity = factory(); > add_entity(entity); > entity.init(); > > The entity.init() is executed last, that's why IPA.get_entity() for > now can only be invoked during the init() phase. > > We could pass the entity object instead of entity name in the spec, > but that will be a major change. > OK,we can punt on this. We'll work on removing init in a dedicated patch. From edewata at redhat.com Wed Apr 13 15:30:15 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 13 Apr 2011 10:30:15 -0500 Subject: [Freeipa-devel] [PATCH] 137 Entitlement registration. In-Reply-To: <4DA5BD95.6030303@redhat.com> References: <4DA4A2BF.5070200@redhat.com> <4DA5AF50.5080905@redhat.com> <4DA5BB59.4040202@redhat.com> <4DA5BD95.6030303@redhat.com> Message-ID: <4DA5C187.80608@redhat.com> On 4/13/2011 10:13 AM, Adam Young wrote: >> There's no pattern defined in the metadata for the quantity. There is >> an 'int' type though. I think we can add a general purpose type >> checking in addition to pattern validation. This can be done in a >> separate patch. > > We can add a validation rule [1..9][0..9]* to the entitlement plugin, > since it should be a positive integer. It's kind of redundant since this pattern is implied by the int type and there are already min/max value params that limit the range to positive integers. I think it's better to validate the type and the min/max values in the widget because other parameters can benefit from it too. -- Endi S. Dewata From ayoung at redhat.com Wed Apr 13 15:34:22 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 13 Apr 2011 11:34:22 -0400 Subject: [Freeipa-devel] About FreeIPA Blurb Message-ID: <4DA5C27E.7060205@redhat.com> The FreeIPA.org Landing page needs a better description of the project. Can anyone suggest a One-Three line description that orients people to FreeIPA, assuming they know little/nothing about the project? Exl;ainig that it integrates Kerbers an LDAp is the second step, but it really is an implementation detail. I typacilly tell people that we do for Linux systems what Active Directory does for Windows systems. This explanation works for people familiar with AD, and then we can talk about how IPA is built on open source code and open standards. The closest we have4 right now is "FreeIPA is an integrated security information management solution ..." this is a good start, but is a little generic. I'll throw this out as a strawman: FreeIPA is a centralized management solution for Users and Computers. Built on Open Standards and open source software, IPA allows you to securely establish policy for access to the resources in your organization. I challenge you to come up with a better one. From mkosek at redhat.com Wed Apr 13 15:31:50 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Apr 2011 17:31:50 +0200 Subject: [Freeipa-devel] [PATCH] 761 Sort entries on *-find commands In-Reply-To: <4DA5B817.9050309@redhat.com> References: <4D939D2A.40903@redhat.com> <1301575782.31691.5.camel@dhcp-25-52.brq.redhat.com> <4DA4BC61.9050608@redhat.com> <1302676636.28122.15.camel@dhcp-25-52.brq.redhat.com> <4DA5B817.9050309@redhat.com> Message-ID: <1302708710.28122.30.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-13 at 10:49 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Tue, 2011-04-12 at 16:56 -0400, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> On Wed, 2011-03-30 at 17:14 -0400, Rob Crittenden wrote: > >>>> Sort output on find commands based on the baseldap LDAPSearch class. > >>>> > >>>> A couple tests had to be modified to match the new order. > >>>> > >>>> ticket 794 > >>>> > >>>> rob > >>> > >>> The patch works fine except the case when entries are being added in > >>> post_callback. Check this search: > >>> > >>> ipa permission-find --permissions=write > >>> > >>> The result is not sorted. I suggest moving the sort process after the > >>> self.POST_CALLBACKS calls. > >>> > >>> What about performance issues? May somebody want to disable the sorting? > >>> (e.g. --nosort option). > >>> > >>> Martin > >> > >> I think the timing would only be a problem if the sizelimit is made very > >> large. The amount of time with/without sorting was negligible. I think > >> we're safe. > >> > >> rob > > > > I agree. > > > > What do you think about my first comment? The patch fails to sort > > correctly when the entries are being added in the post_callback. > > > > Martin > > > > Ah right, forgot to attach updated patch. > > rob It's OK now. ACK and pushed to master, ipa-2-0. Martin From ayoung at redhat.com Wed Apr 13 15:35:54 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 13 Apr 2011 11:35:54 -0400 Subject: [Freeipa-devel] [PATCH] 137 Entitlement registration. In-Reply-To: <4DA5C187.80608@redhat.com> References: <4DA4A2BF.5070200@redhat.com> <4DA5AF50.5080905@redhat.com> <4DA5BB59.4040202@redhat.com> <4DA5BD95.6030303@redhat.com> <4DA5C187.80608@redhat.com> Message-ID: <4DA5C2DA.3000804@redhat.com> On 04/13/2011 11:30 AM, Endi Sukma Dewata wrote: > On 4/13/2011 10:13 AM, Adam Young wrote: >>> There's no pattern defined in the metadata for the quantity. There is >>> an 'int' type though. I think we can add a general purpose type >>> checking in addition to pattern validation. This can be done in a >>> separate patch. >> >> We can add a validation rule [1..9][0..9]* to the entitlement plugin, >> since it should be a positive integer. > > It's kind of redundant since this pattern is implied by the int type > and there are already min/max value params that limit the range to > positive integers. I think it's better to validate the type and the > min/max values in the widget because other parameters can benefit from > it too. Agreed. Still, the Jascript regex for int type can use that pattern. From rcritten at redhat.com Wed Apr 13 15:34:23 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Apr 2011 11:34:23 -0400 Subject: [Freeipa-devel] [PATCH] 771 include rights for all aci components in permission_show Message-ID: <4DA5C27F.70000@redhat.com> Provide attributelevelrights for the aci components in permission_show. Since the broken-out components are just part of the aci just copy right access rights for aci. ticket 943 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-771-permission.patch Type: text/x-patch Size: 1246 bytes Desc: not available URL: From dpal at redhat.com Wed Apr 13 20:00:50 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 Apr 2011 16:00:50 -0400 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <4DA5C27E.7060205@redhat.com> References: <4DA5C27E.7060205@redhat.com> Message-ID: <4DA600F2.8000103@redhat.com> On 04/13/2011 11:34 AM, Adam Young wrote: > The FreeIPA.org Landing page needs a better description of the > project. Can anyone suggest a One-Three line description that orients > people to FreeIPA, assuming they know little/nothing about the > project? Exl;ainig that it integrates Kerbers an LDAp is the second > step, but it really is an implementation detail. > > I typacilly tell people that we do for Linux systems what Active > Directory does for Windows systems. This explanation works for people > familiar with AD, and then we can talk about how IPA is built on open > source code and open standards. > > > The closest we have4 right now is > > "FreeIPA is an integrated security information management solution > ..." this is a good start, but is a little generic. > > I'll throw this out as a strawman: > > FreeIPA is a centralized management solution for Users and Computers. > Built on Open Standards and open source software, IPA allows you to > securely establish policy for access to the resources in your > organization. > > FreeIPA is a centralized identity management and authentication solution built on open standards leveraging proven technologies. It is a authentication and identity hub with focus towards the needs of the Linux/Unix clients. > > I challenge you to come up with a better one. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From JR.Aquino at citrix.com Wed Apr 13 20:23:32 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Wed, 13 Apr 2011 20:23:32 +0000 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <4DA600F2.8000103@redhat.com> References: <4DA5C27E.7060205@redhat.com> <4DA600F2.8000103@redhat.com> Message-ID: <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> On Apr 13, 2011, at 1:00 PM, Dmitri Pal wrote: > On 04/13/2011 11:34 AM, Adam Young wrote: >> The FreeIPA.org Landing page needs a better description of the >> project. Can anyone suggest a One-Three line description that orients >> people to FreeIPA, assuming they know little/nothing about the >> project? Exl;ainig that it integrates Kerbers an LDAp is the second >> step, but it really is an implementation detail. >> >> I typacilly tell people that we do for Linux systems what Active >> Directory does for Windows systems. This explanation works for people >> familiar with AD, and then we can talk about how IPA is built on open >> source code and open standards. >> >> >> The closest we have4 right now is >> >> "FreeIPA is an integrated security information management solution >> ..." this is a good start, but is a little generic. >> >> I'll throw this out as a strawman: >> >> FreeIPA is a centralized management solution for Users and Computers. >> Built on Open Standards and open source software, IPA allows you to >> securely establish policy for access to the resources in your >> organization. >> >> > > FreeIPA is a centralized identity management and authentication solution > built on open standards leveraging proven technologies. It is a > authentication and identity hub with focus towards the needs of the > Linux/Unix clients. FreeIPA is a scalable centralized identity management framework. It is built on open standards that provide authentication and authorization with a focus towards the needs of the Linux/Unix clients . --- Scalable authorization is a big one that has yet to be properly solved in the Linux Community for a central directory. It should be captured in our description. > >> >> I challenge you to come up with a better one. >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From dpal at redhat.com Wed Apr 13 20:26:03 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 Apr 2011 16:26:03 -0400 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> References: <4DA5C27E.7060205@redhat.com> <4DA600F2.8000103@redhat.com> <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> Message-ID: <4DA606DB.9040605@redhat.com> On 04/13/2011 04:23 PM, JR Aquino wrote: > On Apr 13, 2011, at 1:00 PM, Dmitri Pal wrote: > >> On 04/13/2011 11:34 AM, Adam Young wrote: >>> The FreeIPA.org Landing page needs a better description of the >>> project. Can anyone suggest a One-Three line description that orients >>> people to FreeIPA, assuming they know little/nothing about the >>> project? Exl;ainig that it integrates Kerbers an LDAp is the second >>> step, but it really is an implementation detail. >>> >>> I typacilly tell people that we do for Linux systems what Active >>> Directory does for Windows systems. This explanation works for people >>> familiar with AD, and then we can talk about how IPA is built on open >>> source code and open standards. >>> >>> >>> The closest we have4 right now is >>> >>> "FreeIPA is an integrated security information management solution >>> ..." this is a good start, but is a little generic. >>> >>> I'll throw this out as a strawman: >>> >>> FreeIPA is a centralized management solution for Users and Computers. >>> Built on Open Standards and open source software, IPA allows you to >>> securely establish policy for access to the resources in your >>> organization. >>> >>> >> FreeIPA is a centralized identity management and authentication solution >> built on open standards leveraging proven technologies. It is a >> authentication and identity hub with focus towards the needs of the >> Linux/Unix clients. > FreeIPA is a scalable centralized identity management framework. > It is built on open standards that provide authentication and authorization with a focus towards the needs of the Linux/Unix clients . > Bingo! > --- > Scalable authorization is a big one that has yet to be properly solved in the Linux Community for a central directory. > It should be captured in our description. > >>> I challenge you to come up with a better one. >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IPA project, >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From edewata at redhat.com Wed Apr 13 20:57:12 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 13 Apr 2011 15:57:12 -0500 Subject: [Freeipa-devel] [PATCH] 136 Merged IPA.cmd() into IPA.command(). In-Reply-To: <4DA5B0F7.4070400@redhat.com> References: <4DA4794D.4030204@redhat.com> <4DA5B0F7.4070400@redhat.com> Message-ID: <4DA60E28.8010800@redhat.com> On 4/13/2011 9:19 AM, Adam Young wrote: > I'm not a fan of the string concatination in the command calls. I'd > prefer to do that inside the IPA.command object, the way it was done in > IPA.cmd: > > > { > entity:cert > method:revoke: > ... > } > > > and > > if (spec.entity){ > method = spec.entity + spec.method; > }else{ > method = spec.method; > } Attached is a new patch. The original idea was that spec parameters would match the properties of the JSON request where the entity name is part of the method name. Now they are stored in separate variables and the actual method for JSON request is generated using the get_command(). This allows changing the entity or method name after the command has been created. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0136-2-Merged-IPA.cmd-into-IPA.command.patch Type: text/x-patch Size: 59701 bytes Desc: not available URL: From ayoung at redhat.com Wed Apr 13 21:05:02 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 13 Apr 2011 17:05:02 -0400 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <4DA606DB.9040605@redhat.com> References: <4DA5C27E.7060205@redhat.com> <4DA600F2.8000103@redhat.com> <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> <4DA606DB.9040605@redhat.com> Message-ID: <4DA60FFE.7070702@redhat.com> On 04/13/2011 04:26 PM, Dmitri Pal wrote: > On 04/13/2011 04:23 PM, JR Aquino wrote: >> On Apr 13, 2011, at 1:00 PM, Dmitri Pal wrote: >> >>> On 04/13/2011 11:34 AM, Adam Young wrote: >>>> The FreeIPA.org Landing page needs a better description of the >>>> project. Can anyone suggest a One-Three line description that orients >>>> people to FreeIPA, assuming they know little/nothing about the >>>> project? Exl;ainig that it integrates Kerbers an LDAp is the second >>>> step, but it really is an implementation detail. >>>> >>>> I typacilly tell people that we do for Linux systems what Active >>>> Directory does for Windows systems. This explanation works for people >>>> familiar with AD, and then we can talk about how IPA is built on open >>>> source code and open standards. >>>> >>>> >>>> The closest we have4 right now is >>>> >>>> "FreeIPA is an integrated security information management solution >>>> ..." this is a good start, but is a little generic. >>>> >>>> I'll throw this out as a strawman: >>>> >>>> FreeIPA is a centralized management solution for Users and Computers. >>>> Built on Open Standards and open source software, IPA allows you to >>>> securely establish policy for access to the resources in your >>>> organization. >>>> >>>> >>> FreeIPA is a centralized identity management and authentication solution >>> built on open standards leveraging proven technologies. It is a >>> authentication and identity hub with focus towards the needs of the >>> Linux/Unix clients. >> FreeIPA is a scalable centralized identity management framework. >> It is built on open standards that provide authentication and authorization with a focus towards the needs of the Linux/Unix clients . >> I suspect term "Identity management Framework" might be too general to orient people not already thinking "Users and Computers" The term Scalable is an unnecessary buzzword. Can we cut it down to this? "FreeIPA is a centralized authentication and authorization management framework, built on open standards, with a focus towards the needs of Linux and Unix clients." > Bingo! > >> --- >> Scalable authorization is a big one that has yet to be properly solved in the Linux Community for a central directory. >> It should be captured in our description. >> >>>> I challenge you to come up with a better one. >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IPA project, >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs? >>> www.redhat.com/carveoutcosts/ >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> > From rcritten at redhat.com Wed Apr 13 22:22:16 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Apr 2011 18:22:16 -0400 Subject: [Freeipa-devel] [PATCH] 772 prompt for reverse members Message-ID: <4DA62218.7050302@redhat.com> Always ask members in LDAP*ReverseMember commands. This changes the API but alwaysask is enforced on the client only so doesn't change the wire API so I'm not updating the API version. ticket 1081 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-772-reverse.patch Type: application/mbox Size: 5670 bytes Desc: not available URL: From dpal at redhat.com Thu Apr 14 00:37:15 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 Apr 2011 20:37:15 -0400 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <4DA60FFE.7070702@redhat.com> References: <4DA5C27E.7060205@redhat.com> <4DA600F2.8000103@redhat.com> <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> <4DA606DB.9040605@redhat.com> <4DA60FFE.7070702@redhat.com> Message-ID: <4DA641BB.8050002@redhat.com> On 04/13/2011 05:05 PM, Adam Young wrote: > On 04/13/2011 04:26 PM, Dmitri Pal wrote: >> On 04/13/2011 04:23 PM, JR Aquino wrote: >>> On Apr 13, 2011, at 1:00 PM, Dmitri Pal wrote: >>> >>>> On 04/13/2011 11:34 AM, Adam Young wrote: >>>>> The FreeIPA.org Landing page needs a better description of the >>>>> project. Can anyone suggest a One-Three line description that >>>>> orients >>>>> people to FreeIPA, assuming they know little/nothing about the >>>>> project? Exl;ainig that it integrates Kerbers an LDAp is the second >>>>> step, but it really is an implementation detail. >>>>> >>>>> I typacilly tell people that we do for Linux systems what Active >>>>> Directory does for Windows systems. This explanation works for >>>>> people >>>>> familiar with AD, and then we can talk about how IPA is built on open >>>>> source code and open standards. >>>>> >>>>> >>>>> The closest we have4 right now is >>>>> >>>>> "FreeIPA is an integrated security information management solution >>>>> ..." this is a good start, but is a little generic. >>>>> >>>>> I'll throw this out as a strawman: >>>>> >>>>> FreeIPA is a centralized management solution for Users and Computers. >>>>> Built on Open Standards and open source software, IPA allows you to >>>>> securely establish policy for access to the resources in your >>>>> organization. >>>>> >>>>> >>>> FreeIPA is a centralized identity management and authentication >>>> solution >>>> built on open standards leveraging proven technologies. It is a >>>> authentication and identity hub with focus towards the needs of the >>>> Linux/Unix clients. >>> FreeIPA is a scalable centralized identity management framework. >>> It is built on open standards that provide authentication and >>> authorization with a focus towards the needs of the Linux/Unix >>> clients . >>> > I suspect term "Identity management Framework" might be too general > to orient people not already thinking "Users and Computers" > > The term Scalable is an unnecessary buzzword. Can we cut it down to > this? > > "FreeIPA is a centralized authentication and authorization management > framework, built on open standards, with a focus towards the needs of > Linux and Unix clients." > Works for me. > >> Bingo! >> >>> --- >>> Scalable authorization is a big one that has yet to be properly >>> solved in the Linux Community for a central directory. >>> It should be captured in our description. >>> >>>>> I challenge you to come up with a better one. >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IPA project, >>>> Red Hat Inc. >>>> >>>> >>>> ------------------------------- >>>> Looking to carve out IT costs? >>>> www.redhat.com/carveoutcosts/ >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Thu Apr 14 01:15:47 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 13 Apr 2011 21:15:47 -0400 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <4DA60FFE.7070702@redhat.com> References: <4DA5C27E.7060205@redhat.com> <4DA600F2.8000103@redhat.com> <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> <4DA606DB.9040605@redhat.com> <4DA60FFE.7070702@redhat.com> Message-ID: <20110413211547.155645f1@willson.li.ssimo.org> On Wed, 13 Apr 2011 17:05:02 -0400 Adam Young wrote: > "FreeIPA is a centralized authentication and authorization management > framework, built on open standards, with a focus towards the needs of > Linux and Unix clients." > I'd like to ack, but when I see framework I think of something that needs further work and integration to be useful. I'll take my crack at it: "FreeIPA is an integrated identity and computer management solution, built on open standards, centered on servicing Linux and Unix based infrastructures" Simo. -- Simo Sorce * Red Hat, Inc * New York From ayoung at redhat.com Thu Apr 14 01:26:30 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 13 Apr 2011 21:26:30 -0400 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <20110413211547.155645f1@willson.li.ssimo.org> References: <4DA5C27E.7060205@redhat.com> <4DA600F2.8000103@redhat.com> <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> <4DA606DB.9040605@redhat.com> <4DA60FFE.7070702@redhat.com> <20110413211547.155645f1@willson.li.ssimo.org> Message-ID: <4DA64D46.6040304@redhat.com> On 04/13/2011 09:15 PM, Simo Sorce wrote: > On Wed, 13 Apr 2011 17:05:02 -0400 > Adam Young wrote: > >> "FreeIPA is a centralized authentication and authorization management >> framework, built on open standards, with a focus towards the needs of >> Linux and Unix clients." >> > I'd like to ack, but when I see framework I think of something that > needs further work and integration to be useful. > > I'll take my crack at it: > "FreeIPA is an integrated identity and computer management solution, > built on open standards, centered on servicing Linux and Unix based > infrastructures" I like that better. But "identity and computer management" is awkward. I think we should stick with authentication and authorization: Next hack: FreeIPA is an open standards based authentication and authorization solution for large scale Linux and Unix deployments. > Simo. > From JR.Aquino at citrix.com Thu Apr 14 01:25:51 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 14 Apr 2011 01:25:51 +0000 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <20110413211547.155645f1@willson.li.ssimo.org> References: <4DA5C27E.7060205@redhat.com> <4DA600F2.8000103@redhat.com> <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> <4DA606DB.9040605@redhat.com> <4DA60FFE.7070702@redhat.com> <20110413211547.155645f1@willson.li.ssimo.org> Message-ID: <7F2910AF-7A2E-44E8-80EE-0B05ADAF7D31@citrixonline.com> On Apr 13, 2011, at 6:15 PM, Simo Sorce wrote: > On Wed, 13 Apr 2011 17:05:02 -0400 > Adam Young wrote: > >> "FreeIPA is a centralized authentication and authorization management >> framework, built on open standards, with a focus towards the needs of >> Linux and Unix clients." >> > > I'd like to ack, but when I see framework I think of something that > needs further work and integration to be useful. If framework carries with it a stigma, it was not my intention to hint at an unfinished project. My intention was to capture the fact that the FreeIPA system is modular and plugin based, such that additional components can be added to the framework. If there is a better word to describe this trait, I am all for it! Authorization felt like a good strong word that would reflect the v2 features of HBAC/SUDO/DOGTAG. Something that very clearly separates FreeIPA from 'other' authentication solutions such as Standard LDAP, Kerberos, Novell eDirectory, or Symas Unified User Management. > I'll take my crack at it: > "FreeIPA is an integrated identity and computer management solution, > built on open standards, centered on servicing Linux and Unix based > infrastructures" > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From ayoung at redhat.com Thu Apr 14 01:40:50 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 13 Apr 2011 21:40:50 -0400 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <4DA64D46.6040304@redhat.com> References: <4DA5C27E.7060205@redhat.com> <4DA600F2.8000103@redhat.com> <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> <4DA606DB.9040605@redhat.com> <4DA60FFE.7070702@redhat.com> <20110413211547.155645f1@willson.li.ssimo.org> <4DA64D46.6040304@redhat.com> Message-ID: <4DA650A2.3080000@redhat.com> On 04/13/2011 09:26 PM, Adam Young wrote: > On 04/13/2011 09:15 PM, Simo Sorce wrote: >> On Wed, 13 Apr 2011 17:05:02 -0400 >> Adam Young wrote: >> >>> "FreeIPA is a centralized authentication and authorization management >>> framework, built on open standards, with a focus towards the needs of >>> Linux and Unix clients." >>> >> I'd like to ack, but when I see framework I think of something that >> needs further work and integration to be useful. >> >> I'll take my crack at it: >> "FreeIPA is an integrated identity and computer management solution, >> built on open standards, centered on servicing Linux and Unix based >> infrastructures" > > I like that better. But "identity and computer management" is > awkward. I think we should stick with authentication and authorization: > > Next hack: > > FreeIPA is an open standards based authentication and authorization > solution for large scale Linux and Unix deployments. Self NACK. Next attempt: FreeIPA is an authentication and authorization framework for large scale Linux and Unix deployments. FreeIPA Integrates servers for Kerberos, LDAP, DNS, and X509 Certificates into a secure, reliable, and scalable identity management solution. > >> Simo. >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From JR.Aquino at citrix.com Thu Apr 14 01:51:14 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 14 Apr 2011 01:51:14 +0000 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <4DA650A2.3080000@redhat.com> References: <4DA5C27E.7060205@redhat.com> <4DA600F2.8000103@redhat.com> <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> <4DA606DB.9040605@redhat.com> <4DA60FFE.7070702@redhat.com> <20110413211547.155645f1@willson.li.ssimo.org> <4DA64D46.6040304@redhat.com> <4DA650A2.3080000@redhat.com> Message-ID: <66452F4D-B4B2-4BE7-BC1C-70DD7FDF547D@citrixonline.com> On Apr 13, 2011, at 6:40 PM, Adam Young wrote: > On 04/13/2011 09:26 PM, Adam Young wrote: >> On 04/13/2011 09:15 PM, Simo Sorce wrote: >>> On Wed, 13 Apr 2011 17:05:02 -0400 >>> Adam Young wrote: >>> >>>> "FreeIPA is a centralized authentication and authorization management >>>> framework, built on open standards, with a focus towards the needs of >>>> Linux and Unix clients." >>>> >>> I'd like to ack, but when I see framework I think of something that >>> needs further work and integration to be useful. >>> >>> I'll take my crack at it: >>> "FreeIPA is an integrated identity and computer management solution, >>> built on open standards, centered on servicing Linux and Unix based >>> infrastructures" >> >> I like that better. But "identity and computer management" is awkward. I think we should stick with authentication and authorization: >> >> Next hack: >> >> FreeIPA is an open standards based authentication and authorization solution for large scale Linux and Unix deployments. > > Self NACK. Next attempt: > > > FreeIPA is an authentication and authorization framework for large scale Linux and Unix deployments. FreeIPA Integrates servers for Kerberos, LDAP, DNS, and X509 Certificates into a secure, reliable, and scalable identity management solution. I like it! ACK I see a lot of google hits for that pairing. From ayoung at redhat.com Thu Apr 14 03:28:37 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 13 Apr 2011 23:28:37 -0400 Subject: [Freeipa-devel] [PATCH] 136 Merged IPA.cmd() into IPA.command(). In-Reply-To: <4DA60E28.8010800@redhat.com> References: <4DA4794D.4030204@redhat.com> <4DA5B0F7.4070400@redhat.com> <4DA60E28.8010800@redhat.com> Message-ID: <4DA669E5.4070706@redhat.com> On 04/13/2011 04:57 PM, Endi Sukma Dewata wrote: > On 4/13/2011 9:19 AM, Adam Young wrote: >> I'm not a fan of the string concatination in the command calls. I'd >> prefer to do that inside the IPA.command object, the way it was done in >> IPA.cmd: >> >> >> { >> entity:cert >> method:revoke: >> ... >> } >> >> >> and >> >> if (spec.entity){ >> method = spec.entity + spec.method; >> }else{ >> method = spec.method; >> } > > Attached is a new patch. > > The original idea was that spec parameters would match the properties > of the JSON request where the entity name is part of the method name. > Now they are stored in separate variables and the actual method for > JSON request is generated using the get_command(). This allows > changing the entity or method name after the command has been created. > ACK. Pushed to master From ayoung at redhat.com Thu Apr 14 03:33:05 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 13 Apr 2011 23:33:05 -0400 Subject: [Freeipa-devel] [PATCH] 137 Entitlement registration. In-Reply-To: <4DA5C187.80608@redhat.com> References: <4DA4A2BF.5070200@redhat.com> <4DA5AF50.5080905@redhat.com> <4DA5BB59.4040202@redhat.com> <4DA5BD95.6030303@redhat.com> <4DA5C187.80608@redhat.com> Message-ID: <4DA66AF1.1040606@redhat.com> On 04/13/2011 11:30 AM, Endi Sukma Dewata wrote: > On 4/13/2011 10:13 AM, Adam Young wrote: >>> There's no pattern defined in the metadata for the quantity. There is >>> an 'int' type though. I think we can add a general purpose type >>> checking in addition to pattern validation. This can be done in a >>> separate patch. >> >> We can add a validation rule [1..9][0..9]* to the entitlement plugin, >> since it should be a positive integer. > > It's kind of redundant since this pattern is implied by the int type > and there are already min/max value params that limit the range to > positive integers. I think it's better to validate the type and the > min/max values in the widget because other parameters can benefit from > it too. > BTW, are you planning on updating this patch, or do the validation work in a follow on patch? From edewata at redhat.com Thu Apr 14 05:17:28 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 14 Apr 2011 00:17:28 -0500 Subject: [Freeipa-devel] [PATCH] 137 Entitlement registration. In-Reply-To: <4DA66AF1.1040606@redhat.com> References: <4DA4A2BF.5070200@redhat.com> <4DA5AF50.5080905@redhat.com> <4DA5BB59.4040202@redhat.com> <4DA5BD95.6030303@redhat.com> <4DA5C187.80608@redhat.com> <4DA66AF1.1040606@redhat.com> Message-ID: <4DA68368.7090704@redhat.com> On 4/13/2011 10:33 PM, Adam Young wrote: > BTW, are you planning on updating this patch, or do the validation work > in a follow on patch? Attached is an updated version. There are a few more patches in the pipeline. After that I'll address the I18n labels, integer validation and builder cleanup. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0137-2-Entitlement-registration.patch Type: text/x-patch Size: 42242 bytes Desc: not available URL: From jcholast at redhat.com Thu Apr 14 10:58:47 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 14 Apr 2011 12:58:47 +0200 Subject: [Freeipa-devel] [PATCH] 11 Fix unitialized attributes In-Reply-To: <4DA5A33C.10209@redhat.com> References: <4DA2FD1E.1020209@redhat.com> <1302692687.28122.19.camel@dhcp-25-52.brq.redhat.com> <4DA5A33C.10209@redhat.com> Message-ID: <4DA6D367.80905@redhat.com> On 13.4.2011 15:21, Jan Cholasta wrote: > On 13.4.2011 13:04, Martin Kosek wrote: >> On Mon, 2011-04-11 at 15:07 +0200, Jan Cholasta wrote: >>> Fixed unitialized attributes in ipalib.aci.ACI, ipalib.parameters.Data, >>> ipalib.text.LazyText, ipaserver.install.service.Service and >>> ipaserver.rpcserver.WSGIExecutioner. >>> >> >> NACK. This patch breaks the build. >> >> $ make rpms >> [snip] >> if [ "" != "yes" ]; then \ >> ./makeapi --validate; \ >> fi >> Traceback (most recent call last): >> File "./makeapi", line 281, in >> sys.exit(main()) >> File "./makeapi", line 259, in main >> api.finalize() >> File "/home/mkosek/freeipa/ipalib/plugable.py", line 574, in finalize >> self.__do_if_not_done('load_plugins') >> File "/home/mkosek/freeipa/ipalib/plugable.py", line 384, in >> __do_if_not_done >> getattr(self, name)() >> File "/home/mkosek/freeipa/ipalib/plugable.py", line 526, in >> load_plugins >> self.import_plugins('ipalib') >> File "/home/mkosek/freeipa/ipalib/plugable.py", line 564, in >> import_plugins >> raise e >> AttributeError: locked: cannot set Str.re to None >> make: *** [version-update] Error 1 > > Fixed. NACK, made a stupid mistake. Should be ok now. > >> >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-11-uninitialized-attributes.patch Type: text/x-patch Size: 2490 bytes Desc: not available URL: From jcholast at redhat.com Thu Apr 14 11:07:02 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 14 Apr 2011 13:07:02 +0200 Subject: [Freeipa-devel] [PATCH] 12 Remove unused classes Message-ID: <4DA6D556.5080200@redhat.com> Removes unused classes NSPRConnection and NSPRHTTP from ipapython.nsslib. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-12-unused-classes.patch Type: text/x-patch Size: 1590 bytes Desc: not available URL: From jcholast at redhat.com Thu Apr 14 11:12:43 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 14 Apr 2011 13:12:43 +0200 Subject: [Freeipa-devel] [PATCH] 13 Final lint fixes Message-ID: <4DA6D6AB.8090909@redhat.com> Fixes additional false positives found in install/po/test_i18n.py and a missing import in ipa-nis-manage. This should be the last patch dealing with pylint-discovered issues. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-13-final-lint-fixes.patch Type: text/x-patch Size: 1750 bytes Desc: not available URL: From ssorce at redhat.com Thu Apr 14 12:37:23 2011 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Apr 2011 08:37:23 -0400 Subject: [Freeipa-devel] About FreeIPA Blurb In-Reply-To: <4DA650A2.3080000@redhat.com> References: <4DA5C27E.7060205@redhat.com> <4DA600F2.8000103@redhat.com> <7B230D31-4591-4408-AE2C-3FF97AA503B8@citrixonline.com> <4DA606DB.9040605@redhat.com> <4DA60FFE.7070702@redhat.com> <20110413211547.155645f1@willson.li.ssimo.org> <4DA64D46.6040304@redhat.com> <4DA650A2.3080000@redhat.com> Message-ID: <20110414083723.12a4488b@willson.li.ssimo.org> On Wed, 13 Apr 2011 21:40:50 -0400 Adam Young wrote: > FreeIPA is an authentication and authorization framework for large > scale Linux and Unix deployments. FreeIPA Integrates servers for > Kerberos, LDAP, DNS, and X509 Certificates into a secure, reliable, > and scalable identity management solution. Ack! Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Apr 14 13:00:15 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Apr 2011 15:00:15 +0200 Subject: [Freeipa-devel] [PATCH] 771 include rights for all aci components in permission_show In-Reply-To: <4DA5C27F.70000@redhat.com> References: <4DA5C27F.70000@redhat.com> Message-ID: <1302786015.10716.4.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-13 at 11:34 -0400, Rob Crittenden wrote: > Provide attributelevelrights for the aci components in permission_show. > > Since the broken-out components are just part of the aci just copy right > access rights for aci. > > ticket 943 > > rob NACK. Works fine for permission-show, but I think we should add the attributelevelrights for permission-mod command too. This issue is very similar to ticket #1103, where I was adding missing rights for pwpolicy - we can get some inspiration from there. Martin From mkosek at redhat.com Thu Apr 14 13:13:05 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Apr 2011 15:13:05 +0200 Subject: [Freeipa-devel] [PATCH] 772 prompt for reverse members In-Reply-To: <4DA62218.7050302@redhat.com> References: <4DA62218.7050302@redhat.com> Message-ID: <1302786785.10716.5.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-13 at 18:22 -0400, Rob Crittenden wrote: > Always ask members in LDAP*ReverseMember commands. > > This changes the API but alwaysask is enforced on the client only so > doesn't change the wire API so I'm not updating the API version. > > ticket 1081 > > rob ACK. Works fine. Martin From edewata at redhat.com Thu Apr 14 17:02:18 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 14 Apr 2011 12:02:18 -0500 Subject: [Freeipa-devel] [PATCH] 138 Entitlement import. Message-ID: <4DA7289A.4080601@redhat.com> The entitlement facet will invoke entitle_status to check the entitlement status and show the appropriate buttons. If it's unregistered it will show Register and Import button. If it's registered it will show the Consume button only. If it's imported it will show the Import button only. The Import button will open a dialog box for importing entitlement certificate. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0138-Entitlement-import.patch Type: text/x-patch Size: 11895 bytes Desc: not available URL: From rcritten at redhat.com Thu Apr 14 18:40:48 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Apr 2011 14:40:48 -0400 Subject: [Freeipa-devel] [PATCH] 773 add ipaUniqueId to default groups Message-ID: <4DA73FB0.6050407@redhat.com> The default groups we create should have ipaUniqueId set This adds a new directive to ipa-ldap-updater: addifnew. This will add a new attribute only if it doesn't exist in the current entry. We can't compare values because the value we are adding is automatically generated. ticket 1177 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-773-uuid.patch Type: application/mbox Size: 5560 bytes Desc: not available URL: From mkosek at redhat.com Thu Apr 14 19:44:32 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Apr 2011 21:44:32 +0200 Subject: [Freeipa-devel] [PATCH] 773 add ipaUniqueId to default groups In-Reply-To: <4DA73FB0.6050407@redhat.com> References: <4DA73FB0.6050407@redhat.com> Message-ID: <1302810272.22231.4.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-14 at 14:40 -0400, Rob Crittenden wrote: > The default groups we create should have ipaUniqueId set > > This adds a new directive to ipa-ldap-updater: addifnew. This will add a > new attribute only if it doesn't exist in the current entry. We can't > compare values because the value we are adding is automatically generated. > > ticket 1177 > > rob ACK. Works like a charm. I tested both RPM upgrade to existing IPA installation where I checked that UID of my custom group is not changed and also a new IPA server installation. Missing UID was correctly added in all cases. Martin From ayoung at redhat.com Thu Apr 14 21:13:15 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 14 Apr 2011 17:13:15 -0400 Subject: [Freeipa-devel] [PATCH] 138 Entitlement import. In-Reply-To: <4DA7289A.4080601@redhat.com> References: <4DA7289A.4080601@redhat.com> Message-ID: <4DA7636B.10001@redhat.com> On 04/14/2011 01:02 PM, Endi Sukma Dewata wrote: > The entitlement facet will invoke entitle_status to check the > entitlement status and show the appropriate buttons. If it's > unregistered it will show Register and Import button. If it's > registered it will show the Consume button only. If it's imported it > will show the Import button only. The Import button will open a dialog > box for importing entitlement certificate. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel NACK. The logic post imort is wrong. Need to be able to consume the newly imported entitlements, just like after register. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Thu Apr 14 23:08:46 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 14 Apr 2011 18:08:46 -0500 Subject: [Freeipa-devel] [PATCH] 137 Entitlement registration. In-Reply-To: <4DA68368.7090704@redhat.com> References: <4DA4A2BF.5070200@redhat.com> <4DA5AF50.5080905@redhat.com> <4DA5BB59.4040202@redhat.com> <4DA5BD95.6030303@redhat.com> <4DA5C187.80608@redhat.com> <4DA66AF1.1040606@redhat.com> <4DA68368.7090704@redhat.com> Message-ID: <4DA77E7E.3020709@redhat.com> On 4/14/2011 12:17 AM, Endi Sukma Dewata wrote: > Attached is an updated version. There are a few more patches in the > pipeline. After that I'll address the I18n labels, integer validation > and builder cleanup. ACKed on IRC. Replaced integer constants with string. Pushed to master. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0137-3-Entitlement-registration.patch Type: text/x-patch Size: 42266 bytes Desc: not available URL: From mkosek at redhat.com Fri Apr 15 11:04:46 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 Apr 2011 13:04:46 +0200 Subject: [Freeipa-devel] [PATCH] 773 add ipaUniqueId to default groups In-Reply-To: <1302810272.22231.4.camel@dhcp-25-52.brq.redhat.com> References: <4DA73FB0.6050407@redhat.com> <1302810272.22231.4.camel@dhcp-25-52.brq.redhat.com> Message-ID: <1302865486.898.6.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-14 at 21:44 +0200, Martin Kosek wrote: > On Thu, 2011-04-14 at 14:40 -0400, Rob Crittenden wrote: > > The default groups we create should have ipaUniqueId set > > > > This adds a new directive to ipa-ldap-updater: addifnew. This will add a > > new attribute only if it doesn't exist in the current entry. We can't > > compare values because the value we are adding is automatically generated. > > > > ticket 1177 > > > > rob > > ACK. Works like a charm. I tested both RPM upgrade to existing IPA > installation where I checked that UID of my custom group is not changed > and also a new IPA server installation. Missing UID was correctly added > in all cases. > > Martin > Pushed to master, ipa-2-0. Martin From mkosek at redhat.com Fri Apr 15 11:13:38 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 Apr 2011 13:13:38 +0200 Subject: [Freeipa-devel] [PATCH] 772 prompt for reverse members In-Reply-To: <1302786785.10716.5.camel@dhcp-25-52.brq.redhat.com> References: <4DA62218.7050302@redhat.com> <1302786785.10716.5.camel@dhcp-25-52.brq.redhat.com> Message-ID: <1302866018.898.7.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-14 at 15:13 +0200, Martin Kosek wrote: > On Wed, 2011-04-13 at 18:22 -0400, Rob Crittenden wrote: > > Always ask members in LDAP*ReverseMember commands. > > > > This changes the API but alwaysask is enforced on the client only so > > doesn't change the wire API so I'm not updating the API version. > > > > ticket 1081 > > > > rob > > ACK. Works fine. > > Martin > Pushed to master, ipa-2-0. Martin From edewata at redhat.com Fri Apr 15 20:05:57 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 15 Apr 2011 15:05:57 -0500 Subject: [Freeipa-devel] [PATCH] 138 Entitlement import. In-Reply-To: <4DA7636B.10001@redhat.com> References: <4DA7289A.4080601@redhat.com> <4DA7636B.10001@redhat.com> Message-ID: <4DA8A525.4000402@redhat.com> On 4/14/2011 4:13 PM, Adam Young wrote: >> The entitlement facet will invoke entitle_status to check the >> entitlement status and show the appropriate buttons. If it's >> unregistered it will show Register and Import button. If it's >> registered it will show the Consume button only. If it's imported it >> will show the Import button only. The Import button will open a dialog >> box for importing entitlement certificate. > NACK. The logic post imort is wrong. Need to be able to consume the > newly imported entitlements, just like after register. This behavior actually reflects the current server implementation: https://fedorahosted.org/freeipa/ticket/1179 I've updated the patch so that when the bug is fixed it would be easier to adjust the UI to the new behavior. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0138-2-Entitlement-import.patch Type: text/x-patch Size: 17467 bytes Desc: not available URL: From edewata at redhat.com Fri Apr 15 20:21:36 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 15 Apr 2011 15:21:36 -0500 Subject: [Freeipa-devel] [PATCH] 139 Entitlement download. Message-ID: <4DA8A8D0.8030002@redhat.com> A Download link has been added to download entitlement certificates. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0139-Entitlement-download.patch Type: text/x-patch Size: 8895 bytes Desc: not available URL: From ayoung at redhat.com Mon Apr 18 15:16:29 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 18 Apr 2011 11:16:29 -0400 Subject: [Freeipa-devel] [PATCH] 138 Entitlement import. In-Reply-To: <4DA8A525.4000402@redhat.com> References: <4DA7289A.4080601@redhat.com> <4DA7636B.10001@redhat.com> <4DA8A525.4000402@redhat.com> Message-ID: <4DAC55CD.1010308@redhat.com> On 04/15/2011 04:05 PM, Endi Sukma Dewata wrote: > On 4/14/2011 4:13 PM, Adam Young wrote: >>> The entitlement facet will invoke entitle_status to check the >>> entitlement status and show the appropriate buttons. If it's >>> unregistered it will show Register and Import button. If it's >>> registered it will show the Consume button only. If it's imported it >>> will show the Import button only. The Import button will open a dialog >>> box for importing entitlement certificate. > >> NACK. The logic post imort is wrong. Need to be able to consume the >> newly imported entitlements, just like after register. > > This behavior actually reflects the current server implementation: > https://fedorahosted.org/freeipa/ticket/1179 > > I've updated the patch so that when the bug is fixed it would be > easier to adjust the UI to the new behavior. > ACK. Pushed to master From ayoung at redhat.com Mon Apr 18 15:16:39 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 18 Apr 2011 11:16:39 -0400 Subject: [Freeipa-devel] [PATCH] 139 Entitlement download. In-Reply-To: <4DA8A8D0.8030002@redhat.com> References: <4DA8A8D0.8030002@redhat.com> Message-ID: <4DAC55D7.9020002@redhat.com> On 04/15/2011 04:21 PM, Endi Sukma Dewata wrote: > A Download link has been added to download entitlement certificates. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Mon Apr 18 22:47:32 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 18 Apr 2011 17:47:32 -0500 Subject: [Freeipa-devel] [PATCH] 140 Moved adder dialog box into entity. Message-ID: <4DACBF84.9070808@redhat.com> The adder dialog box definition has been moved from search facet into entity to make it available to other facets. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0140-Moved-adder-dialog-box-into-entity.patch Type: text/x-patch Size: 24826 bytes Desc: not available URL: From ayoung at redhat.com Mon Apr 18 23:06:05 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 18 Apr 2011 19:06:05 -0400 Subject: [Freeipa-devel] [PATCH] 140 Moved adder dialog box into entity. In-Reply-To: <4DACBF84.9070808@redhat.com> References: <4DACBF84.9070808@redhat.com> Message-ID: <4DACC3DD.8070102@redhat.com> On 04/18/2011 06:47 PM, Endi Sukma Dewata wrote: > The adder dialog box definition has been moved from search facet > into entity to make it available to other facets. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Shouldn't it move into add.js, or should add.js go away? -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Tue Apr 19 15:19:36 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 19 Apr 2011 10:19:36 -0500 Subject: [Freeipa-devel] [PATCH] 140 Moved adder dialog box into entity. In-Reply-To: <4DACC3DD.8070102@redhat.com> References: <4DACBF84.9070808@redhat.com> <4DACC3DD.8070102@redhat.com> Message-ID: <4DADA808.1040905@redhat.com> On 4/18/2011 6:06 PM, Adam Young wrote: >> The adder dialog box definition has been moved from search facet >> into entity to make it available to other facets. > Shouldn't it move into add.js, or should add.js go away? This patch only modifies the entity builder interface which is stored in entity.js. The adder dialog base class is still defined in add.js like before. We could merge add.js into another file, but that's a separate issue. -- Endi S. Dewata From edewata at redhat.com Tue Apr 19 18:07:10 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 19 Apr 2011 13:07:10 -0500 Subject: [Freeipa-devel] [PATCH] 141 Standardized action panel buttons creation. Message-ID: <4DADCF4E.3050601@redhat.com> Action panel buttons are now created in facet's create_action_panel(). This is to allow a subclass to override and customize the buttons. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0141-Standardized-action-panel-buttons-creation.patch Type: text/x-patch Size: 8017 bytes Desc: not available URL: From ayoung at redhat.com Tue Apr 19 20:07:00 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 19 Apr 2011 16:07:00 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs Message-ID: <4DADEB64.3090103@redhat.com> going to post this, but with a request to hold on pushing to the repo. I have not yet tested against selenium, and suspect that it will break all selenium test navigation. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0221-action-panel-to-top-tabs.patch Type: text/x-patch Size: 45629 bytes Desc: not available URL: From edewata at redhat.com Tue Apr 19 21:31:48 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 19 Apr 2011 16:31:48 -0500 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DADEB64.3090103@redhat.com> References: <4DADEB64.3090103@redhat.com> Message-ID: <4DADFF44.9000709@redhat.com> On 4/19/2011 3:07 PM, Adam Young wrote: > going to post this, but with a request to hold on pushing to the repo. I > have not yet tested against selenium, and suspect that it will break all > selenium test navigation. I've tested this patch with static data. There are some issues: 1. Incorrect data after switching tabs. Open Users tab, then click User Groups tab, all of the groups will be admin's. Refresh the page, it will show the correct data. 2. Missing third level tabs. Open HBAC tab, the Services & Service Groups are missing. Open SUDO tab, the Commands and Command Groups tabs are missing. Open Role Based Access Control, the Permissions and Privileges tabs are missing. 3. Default tab is not activated. Open Users->admin, the Settings tab is inactive. It should be bigger than the other tabs. 4. Inconsistent position of the action buttons. Open Users tab, observe the position of the Delete & Add buttons. Then click one of the users, the Reset & Update buttons move to the left. 5. Entity label (e.g. Users) should be used instead of entity name (e.g. user) as the page title (next to the buttons). 6. The page title (e.g. user) is too close to the tab groups (e.g. Settings). It needs some space between them. 7. The order of tab groups is not very intuitive. Open Groups tab, click one of the groups. The default tab group (i.e. Settings) is located between Member and Member Of. It would be better to put the default tab at the left most position. 8. The if-then clause on entity.js:46 is unnecessary. There's no need to check spec.facet_group before assigning it to that.facet_group. 9. The assignment on entity.js:296 is unnecessary. Each facet has a reference to the entity, so the entity header can be accessed using that.entity.header. 10. IPA.entity_header() should take a spec object instead of attribute list for consistency. -- Endi S. Dewata From edewata at redhat.com Tue Apr 19 22:50:31 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 19 Apr 2011 17:50:31 -0500 Subject: [Freeipa-devel] [PATCH] 142 Moved entity builder registration into webui.js. Message-ID: <4DAE11B7.4050107@redhat.com> The entity builder registration have been moved into webui.js. This allows the WebUI to control which entities will be loaded. For instance, the entitlement should be loaded only if the plugin is enabled. This is done by checking the metadata. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0142-Moved-entity-builder-registration-into-webui.js.patch Type: text/x-patch Size: 13370 bytes Desc: not available URL: From ayoung at redhat.com Wed Apr 20 00:59:37 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 19 Apr 2011 20:59:37 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DADFF44.9000709@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> Message-ID: <4DAE2FF9.3030907@redhat.com> Good points all. Only one minoir quibble, in-line. On 04/19/2011 05:31 PM, Endi Sukma Dewata wrote: > On 4/19/2011 3:07 PM, Adam Young wrote: >> going to post this, but with a request to hold on pushing to the repo. I >> have not yet tested against selenium, and suspect that it will break all >> selenium test navigation. > > I've tested this patch with static data. There are some issues: > > 1. Incorrect data after switching tabs. > Open Users tab, then click User Groups tab, all of the groups will > be admin's. Refresh the page, it will show the correct data. > > 2. Missing third level tabs. > Open HBAC tab, the Services & Service Groups are missing. > Open SUDO tab, the Commands and Command Groups tabs are missing. > Open Role Based Access Control, the Permissions and Privileges tabs > are missing. > > 3. Default tab is not activated. > Open Users->admin, the Settings tab is inactive. It should be bigger > than the other tabs. > > 4. Inconsistent position of the action buttons. > Open Users tab, observe the position of the Delete & Add buttons. > Then click one of the users, the Reset & Update buttons move to > the left. > > 5. Entity label (e.g. Users) should be used instead of entity name > (e.g. user) as the page title (next to the buttons). > > 6. The page title (e.g. user) is too close to the tab groups (e.g. > Settings). It needs some space between them. > > 7. The order of tab groups is not very intuitive. > Open Groups tab, click one of the groups. The default tab group (i.e. > Settings) is located between Member and Member Of. It would be > better to put the default tab at the left most position. While in general your observations are spot on, I'd like to point out that this is intentional, but that the goal will be to always open the leftmost tab. This will allow us to make entities that are primarily containers, like netgroups, as well as dns zone, default to the page that shows the most common use case: manage contained entities. > > 8. The if-then clause on entity.js:46 is unnecessary. There's no need > to check spec.facet_group before assigning it to that.facet_group. > > 9. The assignment on entity.js:296 is unnecessary. Each facet has a > reference to the entity, so the entity header can be accessed using > that.entity.header. > > 10. IPA.entity_header() should take a spec object instead of attribute > list for consistency. > From ayoung at redhat.com Wed Apr 20 14:43:23 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 20 Apr 2011 10:43:23 -0400 Subject: [Freeipa-devel] [PATCH] 142 Moved entity builder registration into webui.js. In-Reply-To: <4DAE11B7.4050107@redhat.com> References: <4DAE11B7.4050107@redhat.com> Message-ID: <4DAEF10B.7020701@redhat.com> On 04/19/2011 06:50 PM, Endi Sukma Dewata wrote: > The entity builder registration have been moved into webui.js. This > allows the WebUI to control which entities will be loaded. For instance, > the entitlement should be loaded only if the plugin is enabled. This > is done by checking the metadata. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel NACK. I like the concept, but the implementation is too verbose. Instead: Leave the factories as the top level object. For the factory name, say 'entitle' check that the object is in the metadata. If not, don't create the entity. Then, when processing the tabs, if the entity does not exist, drop the tab from the tab set. The explicit enumeration of entities in webui.js is not necessary, nor is putting every entity's factory into its own namespace. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Wed Apr 20 16:28:05 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 20 Apr 2011 11:28:05 -0500 Subject: [Freeipa-devel] [PATCH] 142 Moved entity builder registration into webui.js. In-Reply-To: <4DAEF10B.7020701@redhat.com> References: <4DAE11B7.4050107@redhat.com> <4DAEF10B.7020701@redhat.com> Message-ID: <4DAF0995.5080007@redhat.com> On 4/20/2011 9:43 AM, Adam Young wrote: > On 04/19/2011 06:50 PM, Endi Sukma Dewata wrote: >> The entity builder registration have been moved into webui.js. This >> allows the WebUI to control which entities will be loaded. For instance, >> the entitlement should be loaded only if the plugin is enabled. This >> is done by checking the metadata. >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > NACK. > > I like the concept, but the implementation is too verbose. Instead: > > Leave the factories as the top level object. For the factory name, say > 'entitle' check that the object is in the metadata. If not, don't create > the entity. Then, when processing the tabs, if the entity does not > exist, drop the tab from the tab set. The explicit enumeration of > entities in webui.js is not necessary, nor is putting every entity's > factory into its own namespace. I think it would be even better to create only the entities that are actually needed. So entity creation should be done after we determine the user and the tab set for that user. What do you think? Creating a namespace for each entity is actually a separate but related issue. It's mainly needed to avoid conflicts and we have done that for certificates and entitlements. Sooner or later we'll create name space for other entities anyway. The namespace will also improve modularity. It can be used to specify the default builder for that entity (e.g. IPA.user.entity_builder) instead of registering itself into IPA.entity_factories with a fixed name. This would be useful suppose one day we want to provide different entity implementations with the same name for different users. For example: IPA.user.entity_builder = IPA.admin.user.entity_builder = Both are 'user' entity, but depending on which user logs in, the web ui can decide which implementation to use: var module = IPA.entity_factory[entity_name] = module.entity_builder; -- Endi S. Dewata From ayoung at redhat.com Wed Apr 20 16:50:19 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 20 Apr 2011 12:50:19 -0400 Subject: [Freeipa-devel] [PATCH] 142 Moved entity builder registration into webui.js. In-Reply-To: <4DAF0995.5080007@redhat.com> References: <4DAE11B7.4050107@redhat.com> <4DAEF10B.7020701@redhat.com> <4DAF0995.5080007@redhat.com> Message-ID: <4DAF0ECB.1080905@redhat.com> On 04/20/2011 12:28 PM, Endi Sukma Dewata wrote: > On 4/20/2011 9:43 AM, Adam Young wrote: >> On 04/19/2011 06:50 PM, Endi Sukma Dewata wrote: >>> The entity builder registration have been moved into webui.js. This >>> allows the WebUI to control which entities will be loaded. For >>> instance, >>> the entitlement should be loaded only if the plugin is enabled. This >>> is done by checking the metadata. >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> NACK. >> >> I like the concept, but the implementation is too verbose. Instead: >> >> Leave the factories as the top level object. For the factory name, say >> 'entitle' check that the object is in the metadata. If not, don't create >> the entity. Then, when processing the tabs, if the entity does not >> exist, drop the tab from the tab set. The explicit enumeration of >> entities in webui.js is not necessary, nor is putting every entity's >> factory into its own namespace. > > I think it would be even better to create only the entities that are > actually needed. So entity creation should be done after we determine > the user and the tab set for that user. What do you think? Absolutely. I think that the check should be something like: that.start_entities = function(){ ... for (name in that.entity_factories){ if (!metadata.objects[name]) continue; ... } and then the tab gets dropped later if the entity doesn't exist. > > Creating a namespace for each entity is actually a separate but > related issue. It's mainly needed to avoid conflicts and we have done > that for certificates and entitlements. Sooner or later we'll create > name space for other entities anyway. "You don't need it now" lets avoid introducing it for as long as possible. The namespaces are not likely to be needed for most entities. They are really the exception, not the rule. > > The namespace will also improve modularity. It can be used to specify > the default builder for that entity (e.g. IPA.user.entity_builder) > instead of registering itself into IPA.entity_factories with a fixed > name. This would be useful suppose one day we want to provide > different entity implementations with the same name for different > users. For example: > > IPA.user.entity_builder = > > IPA.admin.user.entity_builder = Interesting approach. I'd rather not do that right now, though. > > Both are 'user' entity, but depending on which user logs in, the web > ui can decide which implementation to use: > > var module = > IPA.entity_factory[entity_name] = module.entity_builder; > From rcritten at redhat.com Wed Apr 20 17:27:50 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Apr 2011 13:27:50 -0400 Subject: [Freeipa-devel] [PATCH] 771 include rights for all aci components in permission_show In-Reply-To: <1302786015.10716.4.camel@dhcp-25-52.brq.redhat.com> References: <4DA5C27F.70000@redhat.com> <1302786015.10716.4.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DAF1796.2000005@redhat.com> Martin Kosek wrote: > On Wed, 2011-04-13 at 11:34 -0400, Rob Crittenden wrote: >> Provide attributelevelrights for the aci components in permission_show. >> >> Since the broken-out components are just part of the aci just copy right >> access rights for aci. >> >> ticket 943 >> >> rob > > NACK. Works fine for permission-show, but I think we should add the > attributelevelrights for permission-mod command too. > > This issue is very similar to ticket #1103, where I was adding missing > rights for pwpolicy - we can get some inspiration from there. > > Martin > permission_mod calls permission_show so passing **options should fix it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-771-2-permission.patch Type: application/mbox Size: 1618 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 20 17:32:12 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Apr 2011 13:32:12 -0400 Subject: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership In-Reply-To: <80D35ED5-84DD-4EBD-BED2-68B14DF8AD12@citrixonline.com> References: <4D94E88C.2090004@redhat.com> <934AB894-09AC-425A-92BD-9BA0B236A21D@citrixonline.com> <8CE5CB9F-4C26-416A-88B4-9EF9B5CB321D@citrixonline.com> <69A99C7A-56D1-4FC6-9434-CC470E779A82@citrixonline.com> <4DA49201.9090605@redhat.com> <80D35ED5-84DD-4EBD-BED2-68B14DF8AD12@citrixonline.com> Message-ID: <4DAF189C.4010804@redhat.com> JR Aquino wrote: > On Apr 12, 2011, at 10:55 AM, Rob Crittenden wrote: > >> JR Aquino wrote: >>> On Apr 7, 2011, at 7:08 PM, JR Aquino wrote: >>> >>>> >>>> On Apr 7, 2011, at 4:04 PM, JR Aquino wrote: >>>> >>>>> On Apr 7, 2011, at 3:42 PM, JR Aquino wrote: >>>>> >>>>>> On Mar 31, 2011, at 2:16 PM, JR Aquino wrote: >>>>>> >>>>>>> On Mar 31, 2011, at 1:48 PM, Rob Crittenden wrote: >>>>>>> >>>>>>>> JR Aquino wrote: >>>>>>>>> The following patch Removes around 20 lines of code and provides a substantial increase in performance for FreeIPA member/memberof verification searches. >>>>>>>>> >>>>>>>>> The current code base blindly searches static containers for the possible presence of members. >>>>>>>>> >>>>>>>>> This patch provides a method for dynamically identifying the specific objects to verify memberships for. >>>>>>>>> >>>>>>>>> The attached patch addresses ticket: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/1139 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ipa hostgroup-find >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> ----------------------------- >>>>>>>>> Number of entries returned 52 >>>>>>>>> ----------------------------- >>>>>>>>> >>>>>>>>> real 0m20.054s >>>>>>>>> user 0m0.934s >>>>>>>>> sys 0m0.050s >>>>>>>>> >>>>>>>>> >>>>>>>>> ipa find-hostgroup >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> ----------------------------- >>>>>>>>> Number of entries returned 52 >>>>>>>>> ----------------------------- >>>>>>>>> >>>>>>>>> real 0m15.064s >>>>>>>>> user 0m0.945s >>>>>>>>> sys 0m0.057s >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> Number of entries returned 100 >>>>>>>>> ------------------------------ >>>>>>>>> >>>>>>>>> real 0m16.471s >>>>>>>>> user 0m0.814s >>>>>>>>> sys 0m0.040s >>>>>>>>> >>>>>>>>> >>>>>>>>> ipa host-find >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> Number of entries returned 100 >>>>>>>>> ------------------------------ >>>>>>>>> >>>>>>>>> real 0m41.277s >>>>>>>>> user 0m0.806s >>>>>>>>> sys 0m0.060s >>>>>>>>> >>>>>>>>> >>>>>>>>> ipa host-find >>>>>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> Number of entries returned 100 >>>>>>>>> ------------------------------ >>>>>>>>> >>>>>>>>> real 0m16.385s >>>>>>>>> user 0m0.814s >>>>>>>>> sys 0m0.053s >>>>>>>> >>>>>>>> There is a typo in the first block, memeber. >>>>>>>> >>>>>>>> Wouldn't it be clearer to do a negative test to continue: >>>>>>>> >>>>>>>> if not 'member' in r[1]: >>>>>>>> continue >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> You're right! >>>>>>> >>>>>>> Corrected patch attached. >>>>>> >>>>>> Self Nack >>>>>> >>>>>> After cli and webui testing, it turned out there was a previous try / except block that was reseting the results value back to [] >>>>>> >>>>>> Corrected and reattaching new patch. >>>>>> >>>>>> Testing cli and webui checks out correctly. Speed AND accuracy are now addressed. >>>>>> >>>>>> It was also discovered during the course of testing that this patch addresses one of the causes for the bug thrown in: https://fedorahosted.org/freeipa/ticket/1133 >>>>>> >>>>>> -JR >>>>> >>>>> NACK >>>>> >>>>> Looks like there may still need to be work with the indirect / direct functions. >>>>> >>>>> Will revisit next week. >>>> >>>> Ok I finally think I've got it. >>>> >>>> My for loop was in my try / except block. It has now been corrected. >>>> >>>> I've tested the searches for: users, groups, sudocmds, sudcmdgroups, sudorules, hosts, hostgroups, hbacrules, hbacsv, hbsvcgroups, and all return as expected. >>>> >>>> Please make sure that they return for you as well. >>>> Please let me know if there is anything else I have missed. >>> >>> Final Patch attached due to relationship with ticket 1133: >>> >>> Added Comments regarding Ticket 1133 / calculating indirect: >>> >>> + # If there is an exception here, it is due to a failure in referential integrity. >>> + # All members should have corresponding memberOf entries. >>> >>> Retested against all xmlrpc tests and passed. >> >> Seems to work as advertised, I just have a couple of requests: >> >> - Some of the comments are really long, can you limit to ~75 chars per line? >> - In this code block: >> >> for r in results: >> direct.append(r[0]) >> try: >> indirect.remove(r[0].lower()) >> except ValueError: >> pass >> >> We should log if a ValueError is thrown, this would mean something is really wrong. Can you import logging in the file and replace pass with something like: >> >> logging.info('Failed to remove indirect entry %s from %s' % r[0], entry_dn) >> >> I wonder if we should raise the ValueError too. This means that something went very wrong. > > Yes I agree that we should raise the error. > > Here is the patch with the requested changes: > > * Fixed width to be PEP8 compliant > * import logging > * Added logging line in exception > * Raise ValueError if we blow up during indirect removal. > Fixes 1-3 look good. I think for the exception you want: except ValueError, e: logging .... raise e A ValueError won't get returned over XML-RPC but the full backtrace will be logged on the server side. The end-user will get a 903 (Internal error raised). rob From JR.Aquino at citrix.com Wed Apr 20 18:19:29 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Wed, 20 Apr 2011 18:19:29 +0000 Subject: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership In-Reply-To: <4DAF189C.4010804@redhat.com> References: <4D94E88C.2090004@redhat.com> <934AB894-09AC-425A-92BD-9BA0B236A21D@citrixonline.com> <8CE5CB9F-4C26-416A-88B4-9EF9B5CB321D@citrixonline.com> <69A99C7A-56D1-4FC6-9434-CC470E779A82@citrixonline.com> <4DA49201.9090605@redhat.com> <80D35ED5-84DD-4EBD-BED2-68B14DF8AD12@citrixonline.com> <4DAF189C.4010804@redhat.com> Message-ID: On Apr 20, 2011, at 10:32 AM, Rob Crittenden wrote: ... >>> Seems to work as advertised, I just have a couple of requests: >>> >>> - Some of the comments are really long, can you limit to ~75 chars per line? >>> - In this code block: >>> >>> for r in results: >>> direct.append(r[0]) >>> try: >>> indirect.remove(r[0].lower()) >>> except ValueError: >>> pass >>> >>> We should log if a ValueError is thrown, this would mean something is really wrong. Can you import logging in the file and replace pass with something like: >>> >>> logging.info('Failed to remove indirect entry %s from %s' % r[0], entry_dn) >>> >>> I wonder if we should raise the ValueError too. This means that something went very wrong. >> >> Yes I agree that we should raise the error. >> >> Here is the patch with the requested changes: >> >> * Fixed width to be PEP8 compliant >> * import logging >> * Added logging line in exception >> * Raise ValueError if we blow up during indirect removal. >> > > Fixes 1-3 look good. I think for the exception you want: > > except ValueError, e: > logging .... > raise e > > A ValueError won't get returned over XML-RPC but the full backtrace will be logged on the server side. The end-user will get a 903 (Internal error raised). > > rob Ok adjusted patch attached to correct for the exception raised. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch Type: application/octet-stream Size: 6399 bytes Desc: freeipa-jraquino-0023-Optimize-and-dynamically-verify-group-membership.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From rcritten at redhat.com Wed Apr 20 18:38:44 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Apr 2011 14:38:44 -0400 Subject: [Freeipa-devel] [PATCH] 12 Remove unused classes In-Reply-To: <4DA6D556.5080200@redhat.com> References: <4DA6D556.5080200@redhat.com> Message-ID: <4DAF2834.6070104@redhat.com> Jan Cholasta wrote: > Removes unused classes NSPRConnection and NSPRHTTP from ipapython.nsslib. > ack, pushed to master and ipa-2-0 From rcritten at redhat.com Wed Apr 20 18:39:17 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Apr 2011 14:39:17 -0400 Subject: [Freeipa-devel] [PATCH] 13 Final lint fixes In-Reply-To: <4DA6D6AB.8090909@redhat.com> References: <4DA6D6AB.8090909@redhat.com> Message-ID: <4DAF2855.3070700@redhat.com> Jan Cholasta wrote: > Fixes additional false positives found in install/po/test_i18n.py and a > missing import in ipa-nis-manage. > > This should be the last patch dealing with pylint-discovered issues. ack, pushed to master and ipa-2-0. FYI, I amended the commit message to be a bit more specific. rob From rcritten at redhat.com Wed Apr 20 20:08:58 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Apr 2011 16:08:58 -0400 Subject: [Freeipa-devel] [PATCH] 3 Add ability to specify netmask with IP addresses during installation In-Reply-To: <4DA58644.3020506@redhat.com> References: <4D9068E5.6090209@redhat.com> <4D90920E.3080900@redhat.com> <4D91DD15.8020109@redhat.com> <4D91DDA6.2060304@redhat.com> <4D923DCA.1030900@redhat.com> <4D930AAD.9020209@redhat.com> <4D9F1AFA.8000305@redhat.com> <4DA2DC6F.1000105@redhat.com> <4DA58644.3020506@redhat.com> Message-ID: <4DAF3D5A.7080300@redhat.com> Jan Cholasta wrote: > On 11.4.2011 12:48, Jan Cholasta wrote: >> On 8.4.2011 16:26, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 29.3.2011 22:15, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Sorry, forgot to attach the patch. >>>>>> >>>>> >>>>> Is this why you have some blind excepts? >>>>> >>>>> installutils._IPAddressWithPrefix('192.168.0.1/33') >>>>> Traceback (most recent call last): >>>>> File "", line 1, in >>>>> File "ipaserver/install/installutils.py", line 167, in __init__ >>>>> net = netaddr.IPNetwork(addr) >>>>> File "/usr/lib/python2.7/site-packages/netaddr/ip/__init__.py", line >>>>> 919, in __init__ >>>>> implicit_prefix, flags) >>>>> File "/usr/lib/python2.7/site-packages/netaddr/ip/__init__.py", line >>>>> 782, in parse_ip_network >>>>> value = ip._value >>>>> UnboundLocalError: local variable 'ip' referenced before assignment >>>>> >>>>> We should get an upstream bug filed on python-netaddr about this. >>>> >>>> https://github.com/drkjam/netaddr/issues/closed#issue/5 >>>> https://github.com/drkjam/netaddr/issues/closed#issue/6 >>>> https://github.com/drkjam/netaddr/issues/closed#issue/8 >>>> >>>> Apparently it's already been fixed for the next release. >>>> >>>> IMHO it's not much of an issue for us, because the exception gets >>>> caught >>>> in parse_ip_address and that's currently the only place where >>>> _IPAddressWithPrefix is used. >>>> >>>>> >>>>> Shoudl parse_ip_address() raise an exception on bad data rather than >>>>> returning 0.0.0.0? >>>> >>>> I've been down that road and it would need a rewrite of the fragile IP >>>> address handling logic of ipa-server-install, which is something I'd >>>> rather avoid. >>>> >>>>> >>>>> >>> installutils.parse_ip_address('355.555.3.3') >>>>> _IPAddressWithPrefix('0.0.0.0') >>>>> >>>>> or >>>>> >>>>> >>> installutils.parse_ip_address('192.168.0.1/55') >>>>> _IPAddressWithPrefix('0.0.0.0') >>>>> >>>>> Should it disallow net addresses like 192.168.0.0? >>>> >>>> If you mean network and broadcast addresses, it probably should. It >>>> might be a good idea to disallow localhost, multicast and/or link-local >>>> addresses too. >>> >>> Are you going to resubmit the patch with these added or should we open a >>> separate ticket? >> >> I'm going to resubmit it. Right now it disallows loopback, IANA >> reserved, link-local, network, multicast and broadcast IP addresses. >> Does it make sense to also allow only IP addresses attached to one of >> the local network interfaces? Perhaps it would be sufficient just to >> print a warning. Or should we not care about that at all? > > Sending the updated patch. This looks ok, just one question. Should we add a dependency on the iproute package because of the /sbin/ip package? rob From edewata at redhat.com Wed Apr 20 21:32:31 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 20 Apr 2011 16:32:31 -0500 Subject: [Freeipa-devel] [PATCH] 142 Moved entity builder registration into webui.js. In-Reply-To: <4DAF0ECB.1080905@redhat.com> References: <4DAE11B7.4050107@redhat.com> <4DAEF10B.7020701@redhat.com> <4DAF0995.5080007@redhat.com> <4DAF0ECB.1080905@redhat.com> Message-ID: <4DAF50EF.5030009@redhat.com> On 4/20/2011 11:50 AM, Adam Young wrote: >>> Leave the factories as the top level object. For the factory name, say >>> 'entitle' check that the object is in the metadata. If not, don't create >>> the entity. Then, when processing the tabs, if the entity does not >>> exist, drop the tab from the tab set. The explicit enumeration of >>> entities in webui.js is not necessary, nor is putting every entity's >>> factory into its own namespace. >> >> I think it would be even better to create only the entities that are >> actually needed. So entity creation should be done after we determine >> the user and the tab set for that user. What do you think? > Absolutely. I think that the check should be something like: > that.start_entities = function(){ > ... > for (name in that.entity_factories){ > if (!metadata.objects[name]) continue; > ... > > } > > and then the tab gets dropped later if the entity doesn't exist. I don't think this approach will work for DNS. If dns_is_enabled is false the entity should not be created either. I'm not sure inserting this logic in the IPA.start_entities() would be a good idea. The start_entities() should read from a list of entities to be created instead of filtering out the entities within the loop. >> Creating a namespace for each entity is actually a separate but >> related issue. It's mainly needed to avoid conflicts and we have done >> that for certificates and entitlements. Sooner or later we'll create >> name space for other entities anyway. > "You don't need it now" lets avoid introducing it for as long as > possible. The namespaces are not likely to be needed for most entities. > They are really the exception, not the rule. The navigation is using a namespace too. It's not a rule, but more like planning ahead rather than reactively fixing it when we encounter the first problem. This is important since JavaScript will not alert us when there's a conflict. User, Host, Service, DNS, HBAC, Sudo, ACI and Widgets are strong candidates because they have a set of related classes. This is similar to Python modules vs. C-style prefixes. We do have the IPA namespace, but right now it's still mostly flat without additional organization. -- Endi S. Dewata From edewata at redhat.com Thu Apr 21 02:41:35 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 20 Apr 2011 21:41:35 -0500 Subject: [Freeipa-devel] [PATCH] 142 Moved entity builder registration into webui.js. In-Reply-To: <4DAF50EF.5030009@redhat.com> References: <4DAE11B7.4050107@redhat.com> <4DAEF10B.7020701@redhat.com> <4DAF0995.5080007@redhat.com> <4DAF0ECB.1080905@redhat.com> <4DAF50EF.5030009@redhat.com> Message-ID: <4DAF995F.2030405@redhat.com> On 4/20/2011 4:32 PM, Endi Sukma Dewata wrote: > On 4/20/2011 11:50 AM, Adam Young wrote: >>>> Leave the factories as the top level object. For the factory name, say >>>> 'entitle' check that the object is in the metadata. If not, don't >>>> create >>>> the entity. Then, when processing the tabs, if the entity does not >>>> exist, drop the tab from the tab set. The explicit enumeration of >>>> entities in webui.js is not necessary, nor is putting every entity's >>>> factory into its own namespace. >>> >>> I think it would be even better to create only the entities that are >>> actually needed. So entity creation should be done after we determine >>> the user and the tab set for that user. What do you think? > >> Absolutely. I think that the check should be something like: >> that.start_entities = function(){ >> ... >> for (name in that.entity_factories){ >> if (!metadata.objects[name]) continue; >> ... >> >> } >> >> and then the tab gets dropped later if the entity doesn't exist. > > I don't think this approach will work for DNS. If dns_is_enabled is > false the entity should not be created either. I'm not sure inserting > this logic in the IPA.start_entities() would be a good idea. The > start_entities() should read from a list of entities to be created > instead of filtering out the entities within the loop. Attached is a new patch that creates only the entities that are enabled and needed by the navigation tabs. It passes jslint, qunit, and essential Selenium tests. This patch can be applied against master or your patch #221. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0142-2-Fixed-entity-creation-and-navigation.patch Type: text/x-patch Size: 25772 bytes Desc: not available URL: From mkosek at redhat.com Thu Apr 21 06:26:53 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Apr 2011 08:26:53 +0200 Subject: [Freeipa-devel] [PATCH] 771 include rights for all aci components in permission_show In-Reply-To: <4DAF1796.2000005@redhat.com> References: <4DA5C27F.70000@redhat.com> <1302786015.10716.4.camel@dhcp-25-52.brq.redhat.com> <4DAF1796.2000005@redhat.com> Message-ID: <1303367213.22142.1.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-20 at 13:27 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Wed, 2011-04-13 at 11:34 -0400, Rob Crittenden wrote: > >> Provide attributelevelrights for the aci components in permission_show. > >> > >> Since the broken-out components are just part of the aci just copy right > >> access rights for aci. > >> > >> ticket 943 > >> > >> rob > > > > NACK. Works fine for permission-show, but I think we should add the > > attributelevelrights for permission-mod command too. > > > > This issue is very similar to ticket #1103, where I was adding missing > > rights for pwpolicy - we can get some inspiration from there. > > > > Martin > > > > permission_mod calls permission_show so passing **options should fix it. > > rob ACK. Pushed to master, ipa-2-0. Martin From jcholast at redhat.com Thu Apr 21 07:36:05 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 21 Apr 2011 09:36:05 +0200 Subject: [Freeipa-devel] [PATCH] 3 Add ability to specify netmask with IP addresses during installation In-Reply-To: <4DAF3D5A.7080300@redhat.com> References: <4D9068E5.6090209@redhat.com> <4D90920E.3080900@redhat.com> <4D91DD15.8020109@redhat.com> <4D91DDA6.2060304@redhat.com> <4D923DCA.1030900@redhat.com> <4D930AAD.9020209@redhat.com> <4D9F1AFA.8000305@redhat.com> <4DA2DC6F.1000105@redhat.com> <4DA58644.3020506@redhat.com> <4DAF3D5A.7080300@redhat.com> Message-ID: <4DAFDE65.5050100@redhat.com> On 20.4.2011 22:08, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 11.4.2011 12:48, Jan Cholasta wrote: >>> On 8.4.2011 16:26, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> On 29.3.2011 22:15, Rob Crittenden wrote: >>>>>> Jan Cholasta wrote: >>>>>>> Sorry, forgot to attach the patch. >>>>>>> >>>>>> >>>>>> Is this why you have some blind excepts? >>>>>> >>>>>> installutils._IPAddressWithPrefix('192.168.0.1/33') >>>>>> Traceback (most recent call last): >>>>>> File "", line 1, in >>>>>> File "ipaserver/install/installutils.py", line 167, in __init__ >>>>>> net = netaddr.IPNetwork(addr) >>>>>> File "/usr/lib/python2.7/site-packages/netaddr/ip/__init__.py", line >>>>>> 919, in __init__ >>>>>> implicit_prefix, flags) >>>>>> File "/usr/lib/python2.7/site-packages/netaddr/ip/__init__.py", line >>>>>> 782, in parse_ip_network >>>>>> value = ip._value >>>>>> UnboundLocalError: local variable 'ip' referenced before assignment >>>>>> >>>>>> We should get an upstream bug filed on python-netaddr about this. >>>>> >>>>> https://github.com/drkjam/netaddr/issues/closed#issue/5 >>>>> https://github.com/drkjam/netaddr/issues/closed#issue/6 >>>>> https://github.com/drkjam/netaddr/issues/closed#issue/8 >>>>> >>>>> Apparently it's already been fixed for the next release. >>>>> >>>>> IMHO it's not much of an issue for us, because the exception gets >>>>> caught >>>>> in parse_ip_address and that's currently the only place where >>>>> _IPAddressWithPrefix is used. >>>>> >>>>>> >>>>>> Shoudl parse_ip_address() raise an exception on bad data rather than >>>>>> returning 0.0.0.0? >>>>> >>>>> I've been down that road and it would need a rewrite of the fragile IP >>>>> address handling logic of ipa-server-install, which is something I'd >>>>> rather avoid. >>>>> >>>>>> >>>>>> >>> installutils.parse_ip_address('355.555.3.3') >>>>>> _IPAddressWithPrefix('0.0.0.0') >>>>>> >>>>>> or >>>>>> >>>>>> >>> installutils.parse_ip_address('192.168.0.1/55') >>>>>> _IPAddressWithPrefix('0.0.0.0') >>>>>> >>>>>> Should it disallow net addresses like 192.168.0.0? >>>>> >>>>> If you mean network and broadcast addresses, it probably should. It >>>>> might be a good idea to disallow localhost, multicast and/or >>>>> link-local >>>>> addresses too. >>>> >>>> Are you going to resubmit the patch with these added or should we >>>> open a >>>> separate ticket? >>> >>> I'm going to resubmit it. Right now it disallows loopback, IANA >>> reserved, link-local, network, multicast and broadcast IP addresses. >>> Does it make sense to also allow only IP addresses attached to one of >>> the local network interfaces? Perhaps it would be sufficient just to >>> print a warning. Or should we not care about that at all? >> >> Sending the updated patch. > > This looks ok, just one question. Should we add a dependency on the > iproute package because of the /sbin/ip package? Yes, we should. > > rob -- Jan Cholasta From jcholast at redhat.com Thu Apr 21 08:18:09 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 21 Apr 2011 10:18:09 +0200 Subject: [Freeipa-devel] [PATCH] 11 Fix unitialized attributes In-Reply-To: <4DA6D367.80905@redhat.com> References: <4DA2FD1E.1020209@redhat.com> <1302692687.28122.19.camel@dhcp-25-52.brq.redhat.com> <4DA5A33C.10209@redhat.com> <4DA6D367.80905@redhat.com> Message-ID: <4DAFE841.5040705@redhat.com> On 14.4.2011 12:58, Jan Cholasta wrote: > On 13.4.2011 15:21, Jan Cholasta wrote: >> On 13.4.2011 13:04, Martin Kosek wrote: >>> On Mon, 2011-04-11 at 15:07 +0200, Jan Cholasta wrote: >>>> Fixed unitialized attributes in ipalib.aci.ACI, ipalib.parameters.Data, >>>> ipalib.text.LazyText, ipaserver.install.service.Service and >>>> ipaserver.rpcserver.WSGIExecutioner. >>>> >>> >>> NACK. This patch breaks the build. >>> >>> $ make rpms >>> [snip] >>> if [ "" != "yes" ]; then \ >>> ./makeapi --validate; \ >>> fi >>> Traceback (most recent call last): >>> File "./makeapi", line 281, in >>> sys.exit(main()) >>> File "./makeapi", line 259, in main >>> api.finalize() >>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 574, in finalize >>> self.__do_if_not_done('load_plugins') >>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 384, in >>> __do_if_not_done >>> getattr(self, name)() >>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 526, in >>> load_plugins >>> self.import_plugins('ipalib') >>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 564, in >>> import_plugins >>> raise e >>> AttributeError: locked: cannot set Str.re to None >>> make: *** [version-update] Error 1 >> >> Fixed. > > NACK, made a stupid mistake. Should be ok now. More elegant solution, per Martin's request. > >> >>> >>> >>> Martin >>> -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-11-uninitialized-attributes.patch Type: text/x-patch Size: 2457 bytes Desc: not available URL: From mkosek at redhat.com Thu Apr 21 08:45:15 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Apr 2011 10:45:15 +0200 Subject: [Freeipa-devel] [PATCH] 11 Fix unitialized attributes In-Reply-To: <4DAFE841.5040705@redhat.com> References: <4DA2FD1E.1020209@redhat.com> <1302692687.28122.19.camel@dhcp-25-52.brq.redhat.com> <4DA5A33C.10209@redhat.com> <4DA6D367.80905@redhat.com> <4DAFE841.5040705@redhat.com> Message-ID: <1303375515.22142.20.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-21 at 10:18 +0200, Jan Cholasta wrote: > On 14.4.2011 12:58, Jan Cholasta wrote: > > On 13.4.2011 15:21, Jan Cholasta wrote: > >> On 13.4.2011 13:04, Martin Kosek wrote: > >>> On Mon, 2011-04-11 at 15:07 +0200, Jan Cholasta wrote: > >>>> Fixed unitialized attributes in ipalib.aci.ACI, ipalib.parameters.Data, > >>>> ipalib.text.LazyText, ipaserver.install.service.Service and > >>>> ipaserver.rpcserver.WSGIExecutioner. > >>>> > >>> > >>> NACK. This patch breaks the build. > >>> > >>> $ make rpms > >>> [snip] > >>> if [ "" != "yes" ]; then \ > >>> ./makeapi --validate; \ > >>> fi > >>> Traceback (most recent call last): > >>> File "./makeapi", line 281, in > >>> sys.exit(main()) > >>> File "./makeapi", line 259, in main > >>> api.finalize() > >>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 574, in finalize > >>> self.__do_if_not_done('load_plugins') > >>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 384, in > >>> __do_if_not_done > >>> getattr(self, name)() > >>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 526, in > >>> load_plugins > >>> self.import_plugins('ipalib') > >>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 564, in > >>> import_plugins > >>> raise e > >>> AttributeError: locked: cannot set Str.re to None > >>> make: *** [version-update] Error 1 > >> > >> Fixed. > > > > NACK, made a stupid mistake. Should be ok now. > > More elegant solution, per Martin's request. ACK. Good, this is much more elegant solution. Pushed to master, ipa-2-0. Honza, one more thing. Please, include patch version into it's filename, e.g. freeipa-jcholast-11-4-uninitialized-attributes.patch. This will prevent confusion and will also make it easier to get differences between patch versions. I won't have to rename it manually myself. This is the last patch for pylint errors, our code is pylint-clean (with python-rhsm installed). I think we can integrate "make lint" to our build process as we talked earlier. I have one more suggestion regarding pylint implementation (as we discussed). When a python package is missing (python-rhsm at the moment) pylint produces false positives without any further explanation - until the missing package is installed. It would be great to have this covered. Martin From jcholast at redhat.com Thu Apr 21 09:00:28 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 21 Apr 2011 11:00:28 +0200 Subject: [Freeipa-devel] [PATCH] 11 Fix unitialized attributes In-Reply-To: <1303375515.22142.20.camel@dhcp-25-52.brq.redhat.com> References: <4DA2FD1E.1020209@redhat.com> <1302692687.28122.19.camel@dhcp-25-52.brq.redhat.com> <4DA5A33C.10209@redhat.com> <4DA6D367.80905@redhat.com> <4DAFE841.5040705@redhat.com> <1303375515.22142.20.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DAFF22C.1010602@redhat.com> On 21.4.2011 10:45, Martin Kosek wrote: > On Thu, 2011-04-21 at 10:18 +0200, Jan Cholasta wrote: >> On 14.4.2011 12:58, Jan Cholasta wrote: >>> On 13.4.2011 15:21, Jan Cholasta wrote: >>>> On 13.4.2011 13:04, Martin Kosek wrote: >>>>> On Mon, 2011-04-11 at 15:07 +0200, Jan Cholasta wrote: >>>>>> Fixed unitialized attributes in ipalib.aci.ACI, ipalib.parameters.Data, >>>>>> ipalib.text.LazyText, ipaserver.install.service.Service and >>>>>> ipaserver.rpcserver.WSGIExecutioner. >>>>>> >>>>> >>>>> NACK. This patch breaks the build. >>>>> >>>>> $ make rpms >>>>> [snip] >>>>> if [ "" != "yes" ]; then \ >>>>> ./makeapi --validate; \ >>>>> fi >>>>> Traceback (most recent call last): >>>>> File "./makeapi", line 281, in >>>>> sys.exit(main()) >>>>> File "./makeapi", line 259, in main >>>>> api.finalize() >>>>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 574, in finalize >>>>> self.__do_if_not_done('load_plugins') >>>>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 384, in >>>>> __do_if_not_done >>>>> getattr(self, name)() >>>>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 526, in >>>>> load_plugins >>>>> self.import_plugins('ipalib') >>>>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 564, in >>>>> import_plugins >>>>> raise e >>>>> AttributeError: locked: cannot set Str.re to None >>>>> make: *** [version-update] Error 1 >>>> >>>> Fixed. >>> >>> NACK, made a stupid mistake. Should be ok now. >> >> More elegant solution, per Martin's request. > > ACK. Good, this is much more elegant solution. > Pushed to master, ipa-2-0. > > Honza, one more thing. Please, include patch version into it's filename, > e.g. freeipa-jcholast-11-4-uninitialized-attributes.patch. This will > prevent confusion and will also make it easier to get differences > between patch versions. I won't have to rename it manually myself. OK. > > This is the last patch for pylint errors, our code is pylint-clean (with > python-rhsm installed). I think we can integrate "make lint" to our > build process as we talked earlier. https://fedorahosted.org/freeipa/ticket/1180 > > I have one more suggestion regarding pylint implementation (as we > discussed). When a python package is missing (python-rhsm at the moment) > pylint produces false positives without any further explanation - until > the missing package is installed. It would be great to have this > covered. Should I create a ticket for that? > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Jan Cholasta From mkosek at redhat.com Thu Apr 21 09:07:03 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Apr 2011 11:07:03 +0200 Subject: [Freeipa-devel] [PATCH] 11 Fix unitialized attributes In-Reply-To: <4DAFF22C.1010602@redhat.com> References: <4DA2FD1E.1020209@redhat.com> <1302692687.28122.19.camel@dhcp-25-52.brq.redhat.com> <4DA5A33C.10209@redhat.com> <4DA6D367.80905@redhat.com> <4DAFE841.5040705@redhat.com> <1303375515.22142.20.camel@dhcp-25-52.brq.redhat.com> <4DAFF22C.1010602@redhat.com> Message-ID: <1303376823.22142.24.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-21 at 11:00 +0200, Jan Cholasta wrote: > On 21.4.2011 10:45, Martin Kosek wrote: > > On Thu, 2011-04-21 at 10:18 +0200, Jan Cholasta wrote: > >> On 14.4.2011 12:58, Jan Cholasta wrote: > >>> On 13.4.2011 15:21, Jan Cholasta wrote: > >>>> On 13.4.2011 13:04, Martin Kosek wrote: > >>>>> On Mon, 2011-04-11 at 15:07 +0200, Jan Cholasta wrote: > >>>>>> Fixed unitialized attributes in ipalib.aci.ACI, ipalib.parameters.Data, > >>>>>> ipalib.text.LazyText, ipaserver.install.service.Service and > >>>>>> ipaserver.rpcserver.WSGIExecutioner. > >>>>>> > >>>>> > >>>>> NACK. This patch breaks the build. > >>>>> > >>>>> $ make rpms > >>>>> [snip] > >>>>> if [ "" != "yes" ]; then \ > >>>>> ./makeapi --validate; \ > >>>>> fi > >>>>> Traceback (most recent call last): > >>>>> File "./makeapi", line 281, in > >>>>> sys.exit(main()) > >>>>> File "./makeapi", line 259, in main > >>>>> api.finalize() > >>>>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 574, in finalize > >>>>> self.__do_if_not_done('load_plugins') > >>>>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 384, in > >>>>> __do_if_not_done > >>>>> getattr(self, name)() > >>>>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 526, in > >>>>> load_plugins > >>>>> self.import_plugins('ipalib') > >>>>> File "/home/mkosek/freeipa/ipalib/plugable.py", line 564, in > >>>>> import_plugins > >>>>> raise e > >>>>> AttributeError: locked: cannot set Str.re to None > >>>>> make: *** [version-update] Error 1 > >>>> > >>>> Fixed. > >>> > >>> NACK, made a stupid mistake. Should be ok now. > >> > >> More elegant solution, per Martin's request. > > > > ACK. Good, this is much more elegant solution. > > Pushed to master, ipa-2-0. > > > > Honza, one more thing. Please, include patch version into it's filename, > > e.g. freeipa-jcholast-11-4-uninitialized-attributes.patch. This will > > prevent confusion and will also make it easier to get differences > > between patch versions. I won't have to rename it manually myself. > > OK. > > > > > This is the last patch for pylint errors, our code is pylint-clean (with > > python-rhsm installed). I think we can integrate "make lint" to our > > build process as we talked earlier. > > https://fedorahosted.org/freeipa/ticket/1180 > > > > > I have one more suggestion regarding pylint implementation (as we > > discussed). When a python package is missing (python-rhsm at the moment) > > pylint produces false positives without any further explanation - until > > the missing package is installed. It would be great to have this > > covered. > > Should I create a ticket for that? Yeah, it will be better to have it tracked. Martin From ayoung at redhat.com Thu Apr 21 17:55:09 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 21 Apr 2011 13:55:09 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DAE2FF9.3030907@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> Message-ID: <4DB06F7D.7060000@redhat.com> Again, have not yet run Selenium against this, so please do not push. There are conflicts between this version and some of edewata's patch. Additionally, there are some know issues with the rendering on the ACI pages which I'll iron out before this gets submitted for real. This version solves Issues 1,2,4,5 (sort of) ,8,9,and 10 from below. On 04/19/2011 08:59 PM, Adam Young wrote: > Good points all. Only one minoir quibble, in-line. > > > On 04/19/2011 05:31 PM, Endi Sukma Dewata wrote: >> On 4/19/2011 3:07 PM, Adam Young wrote: >>> going to post this, but with a request to hold on pushing to the >>> repo. I >>> have not yet tested against selenium, and suspect that it will break >>> all >>> selenium test navigation. >> >> I've tested this patch with static data. There are some issues: >> >> 1. Incorrect data after switching tabs. >> Open Users tab, then click User Groups tab, all of the groups will >> be admin's. Refresh the page, it will show the correct data. >> >> 2. Missing third level tabs. >> Open HBAC tab, the Services & Service Groups are missing. >> Open SUDO tab, the Commands and Command Groups tabs are missing. >> Open Role Based Access Control, the Permissions and Privileges tabs >> are missing. >> >> 3. Default tab is not activated. >> Open Users->admin, the Settings tab is inactive. It should be bigger >> than the other tabs. >> >> 4. Inconsistent position of the action buttons. >> Open Users tab, observe the position of the Delete & Add buttons. >> Then click one of the users, the Reset & Update buttons move to >> the left. >> >> 5. Entity label (e.g. Users) should be used instead of entity name >> (e.g. user) as the page title (next to the buttons). >> >> 6. The page title (e.g. user) is too close to the tab groups (e.g. >> Settings). It needs some space between them. >> >> 7. The order of tab groups is not very intuitive. >> Open Groups tab, click one of the groups. The default tab group (i.e. >> Settings) is located between Member and Member Of. It would be >> better to put the default tab at the left most position. > > While in general your observations are spot on, I'd like to point out > that this is intentional, but that the goal will be to always open the > leftmost tab. This will allow us to make entities that are primarily > containers, like netgroups, as well as dns zone, default to the page > that shows the most common use case: manage contained entities. > >> >> 8. The if-then clause on entity.js:46 is unnecessary. There's no need >> to check spec.facet_group before assigning it to that.facet_group. >> >> 9. The assignment on entity.js:296 is unnecessary. Each facet has a >> reference to the entity, so the entity header can be accessed using >> that.entity.header. > >> >> 10. IPA.entity_header() should take a spec object instead of attribute >> list for consistency. >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0221-1-action-panel-to-top-tabs.patch Type: text/x-patch Size: 58358 bytes Desc: not available URL: From ayoung at redhat.com Thu Apr 21 18:59:09 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 21 Apr 2011 14:59:09 -0400 Subject: [Freeipa-devel] [PATCH] 140 Moved adder dialog box into entity. In-Reply-To: <4DADA808.1040905@redhat.com> References: <4DACBF84.9070808@redhat.com> <4DACC3DD.8070102@redhat.com> <4DADA808.1040905@redhat.com> Message-ID: <4DB07E7D.70304@redhat.com> On 04/19/2011 11:19 AM, Endi Sukma Dewata wrote: > On 4/18/2011 6:06 PM, Adam Young wrote: >>> The adder dialog box definition has been moved from search facet >>> into entity to make it available to other facets. > >> Shouldn't it move into add.js, or should add.js go away? > > This patch only modifies the entity builder interface which is stored > in entity.js. The adder dialog base class is still defined in add.js > like before. > > We could merge add.js into another file, but that's a separate issue. > ACK From ayoung at redhat.com Thu Apr 21 19:00:45 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 21 Apr 2011 15:00:45 -0400 Subject: [Freeipa-devel] [PATCH] 142 Moved entity builder registration into webui.js. In-Reply-To: <4DAF995F.2030405@redhat.com> References: <4DAE11B7.4050107@redhat.com> <4DAEF10B.7020701@redhat.com> <4DAF0995.5080007@redhat.com> <4DAF0ECB.1080905@redhat.com> <4DAF50EF.5030009@redhat.com> <4DAF995F.2030405@redhat.com> Message-ID: <4DB07EDD.1090409@redhat.com> On 04/20/2011 10:41 PM, Endi Sukma Dewata wrote: > On 4/20/2011 4:32 PM, Endi Sukma Dewata wrote: >> On 4/20/2011 11:50 AM, Adam Young wrote: >>>>> Leave the factories as the top level object. For the factory name, >>>>> say >>>>> 'entitle' check that the object is in the metadata. If not, don't >>>>> create >>>>> the entity. Then, when processing the tabs, if the entity does not >>>>> exist, drop the tab from the tab set. The explicit enumeration of >>>>> entities in webui.js is not necessary, nor is putting every entity's >>>>> factory into its own namespace. >>>> >>>> I think it would be even better to create only the entities that are >>>> actually needed. So entity creation should be done after we determine >>>> the user and the tab set for that user. What do you think? >> >>> Absolutely. I think that the check should be something like: >>> that.start_entities = function(){ >>> ... >>> for (name in that.entity_factories){ >>> if (!metadata.objects[name]) continue; >>> ... >>> >>> } >>> >>> and then the tab gets dropped later if the entity doesn't exist. >> >> I don't think this approach will work for DNS. If dns_is_enabled is >> false the entity should not be created either. I'm not sure inserting >> this logic in the IPA.start_entities() would be a good idea. The >> start_entities() should read from a list of entities to be created >> instead of filtering out the entities within the loop. > > Attached is a new patch that creates only the entities that are > enabled and needed by the navigation tabs. It passes jslint, qunit, > and essential Selenium tests. > > This patch can be applied against master or your patch #221. > Officially a NACK, but I am going to integrate most of these changes into an updated verison of my latest patch, as git merging them will be too painful. From ayoung at redhat.com Thu Apr 21 19:01:55 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 21 Apr 2011 15:01:55 -0400 Subject: [Freeipa-devel] [PATCH] 141 Standardized action panel buttons creation. In-Reply-To: <4DADCF4E.3050601@redhat.com> References: <4DADCF4E.3050601@redhat.com> Message-ID: <4DB07F23.7010904@redhat.com> On 04/19/2011 02:07 PM, Endi Sukma Dewata wrote: > Action panel buttons are now created in facet's create_action_panel(). > This is to allow a subclass to override and customize the buttons. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK I'll have to re-do these changes in my next verison of 0221, but the logic is fine -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Thu Apr 21 19:08:24 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 21 Apr 2011 14:08:24 -0500 Subject: [Freeipa-devel] [PATCH] 044 Remove unwanted trimming in text fields In-Reply-To: <1301398264.3592.34.camel@dhcp-25-52.brq.redhat.com> References: <1301398264.3592.34.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB080A8.20004@redhat.com> On 3/29/2011 6:31 AM, Martin Kosek wrote: > UI trims whitespace at the beginning or at the end when user data > are being saved. This confuses is_dirty function which incorrectly > recognizes given field as modified. > > This patch fixes this issue for both general text fields and > ACI filter field. > > https://fedorahosted.org/freeipa/ticket/1096 ACK and pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Apr 21 19:09:18 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 21 Apr 2011 14:09:18 -0500 Subject: [Freeipa-devel] [PATCH] 047 Need force option in DNS zone adder dialog In-Reply-To: <1301670758.1997.1.camel@dhcp-25-52.brq.redhat.com> References: <1301670758.1997.1.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB080DE.8070903@redhat.com> On 4/1/2011 10:12 AM, Martin Kosek wrote: > When adding a new DNS zone in the WebUI, IPA server will verify > whether the nameserver is in DNS. Sometimes it is necessary to > skip the verification. > > This patch adds a --force option already available in CLI which > can skip this the verification. > > https://fedorahosted.org/freeipa/ticket/1105 ACK. Rebased, updated API.txt, and pushed to master. -- Endi S. Dewata From JR.Aquino at citrix.com Thu Apr 21 19:17:44 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 21 Apr 2011 19:17:44 +0000 Subject: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry Message-ID: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> This patch address ticket: * https://fedorahosted.org/freeipa/ticket/1181 This patch provides: * ipa-managed-entries tool which can enable/disable any of the managed entry plugins without the need of separate tools. -When run without any arguments, the tool will display a list of available plugins detected inside of /usr/share/ipa (this directory can be overridden with the --dir flag) * Man Page documenting the tool usage. * The removal of install/tools/ipa-host-net-manage and install/tools/man/ipa-host-net-manage.1 * Modification to ldap2.py: Added method for verifying upg is disabled by objectfilter: objectclass=disabled. The current code assumes that the user private group managed plugin is disabled, if the managed plugin entry is not present. Due to bug https://bugzilla.redhat.com/show_bug.cgi?id=660399, the running system will prohibit you from removing a Managed Entry plugin. NOTE: As I was writing this tool, I noticed that in addition to Managed Entry tools, we also seem to have Schema Compatibility management tools. I had considered rolling support for those plugins as well, but after further inspection, it appears that there is hierarchical way to determine our current 'Compatibility Plugins' via looking at the .uldif files. The method employed by the managed entry tool checks to see if the .ldif file contains a modification which adds an object to the container: cn=Managed Entries,cn=plugins,cn=config. If there is interest in it, we could consolidate ipa-compat-manage and ipa-nis-manage by deciding on a default Container for Compat plugins to be located in such as: "cn=Schema Compatibility,cn=plugins,cn=config" This would potentially give us 1 tool: ipa-plugin-manage that could handle the enabling / disabling of Compat and Managed Entry Plugins... -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0025-Create-Tool-for-Enabling-Disabling-Managed-Entries.patch Type: application/octet-stream Size: 27110 bytes Desc: freeipa-jraquino-0025-Create-Tool-for-Enabling-Disabling-Managed-Entries.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From dpal at redhat.com Thu Apr 21 19:30:03 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 21 Apr 2011 15:30:03 -0400 Subject: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry In-Reply-To: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> References: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> Message-ID: <4DB085BB.6080104@redhat.com> On 04/21/2011 03:17 PM, JR Aquino wrote: > This patch address ticket: > * https://fedorahosted.org/freeipa/ticket/1181 > > This patch provides: > * ipa-managed-entries tool which can enable/disable any of the managed entry plugins without the need of separate tools. > -When run without any arguments, the tool will display a list of available plugins detected inside of /usr/share/ipa (this directory can be overridden with the --dir flag) > * Man Page documenting the tool usage. > * The removal of install/tools/ipa-host-net-manage and install/tools/man/ipa-host-net-manage.1 > * Modification to ldap2.py: Added method for verifying upg is disabled by objectfilter: objectclass=disabled. > The current code assumes that the user private group managed plugin is disabled, if the managed plugin entry is not present. > Due to bug https://bugzilla.redhat.com/show_bug.cgi?id=660399, the running system will prohibit you from removing a Managed Entry plugin. > > NOTE: > As I was writing this tool, I noticed that in addition to Managed Entry tools, we also seem to have Schema Compatibility management tools. > I had considered rolling support for those plugins as well, but after further inspection, it appears that there is hierarchical way to determine our current 'Compatibility Plugins' via looking at the .uldif files. > The method employed by the managed entry tool checks to see if the .ldif file contains a modification which adds an object to the container: cn=Managed Entries,cn=plugins,cn=config. > If there is interest in it, we could consolidate ipa-compat-manage and ipa-nis-manage by deciding on a default Container for Compat plugins to be located in such as: "cn=Schema Compatibility,cn=plugins,cn=config" > This would potentially give us 1 tool: ipa-plugin-manage that could handle the enabling / disabling of Compat and Managed Entry Plugins... > Please log an enhancement ticket. I think it will be deferred but having it in the backlog would be good. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From JR.Aquino at citrix.com Thu Apr 21 19:45:46 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 21 Apr 2011 19:45:46 +0000 Subject: [Freeipa-devel] [PATCH] 26 Delete the sudoers entry when disabling the Schema Compat plugin Message-ID: <9F431B03-AB08-49D1-BB8A-F254EB375989@citrixonline.com> This patch addresses ticket: https://fedorahosted.org/freeipa/ticket/1160 The disabling of the Schema Compat plugin is failing because the code was not removing all of the entries from the Schema Compatibility Container. This is a 1 line patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0026-Delete-the-sudoers-entry-when-disabling-Schema-Compat.patch Type: application/octet-stream Size: 1196 bytes Desc: freeipa-jraquino-0026-Delete-the-sudoers-entry-when-disabling-Schema-Compat.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From edewata at redhat.com Thu Apr 21 19:48:48 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 21 Apr 2011 14:48:48 -0500 Subject: [Freeipa-devel] [PATCH] 140 Moved adder dialog box into entity. In-Reply-To: <4DB07E7D.70304@redhat.com> References: <4DACBF84.9070808@redhat.com> <4DACC3DD.8070102@redhat.com> <4DADA808.1040905@redhat.com> <4DB07E7D.70304@redhat.com> Message-ID: <4DB08A20.1020600@redhat.com> On 4/21/2011 1:59 PM, Adam Young wrote: > On 04/19/2011 11:19 AM, Endi Sukma Dewata wrote: >> On 4/18/2011 6:06 PM, Adam Young wrote: >>>> The adder dialog box definition has been moved from search facet >>>> into entity to make it available to other facets. >> >>> Shouldn't it move into add.js, or should add.js go away? >> >> This patch only modifies the entity builder interface which is stored >> in entity.js. The adder dialog base class is still defined in add.js >> like before. >> >> We could merge add.js into another file, but that's a separate issue. >> > ACK Rebased, fixed typos, and pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Apr 21 19:49:32 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 21 Apr 2011 14:49:32 -0500 Subject: [Freeipa-devel] [PATCH] 141 Standardized action panel buttons creation. In-Reply-To: <4DB07F23.7010904@redhat.com> References: <4DADCF4E.3050601@redhat.com> <4DB07F23.7010904@redhat.com> Message-ID: <4DB08A4C.5060906@redhat.com> On 4/21/2011 2:01 PM, Adam Young wrote: > On 04/19/2011 02:07 PM, Endi Sukma Dewata wrote: >> Action panel buttons are now created in facet's create_action_panel(). >> This is to allow a subclass to override and customize the buttons. > ACK > > > I'll have to re-do these changes in my next verison of 0221, but the > logic is fine Pushed to master. -- Endi S. Dewata From rcritten at redhat.com Thu Apr 21 20:03:31 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Apr 2011 16:03:31 -0400 Subject: [Freeipa-devel] [PATCH] 774 configure nss properly with --no-sssd Message-ID: <4DB08D93.20703@redhat.com> nss wasn't being configured properly with the --no-sssd argument. It is supposed to fall back to nss_ldap. We needed the --enableforcelegacy option. Also always back up sssd.conf, it gets updated regardless of whether it is used in nss (by --enablekrb5). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-774-client.patch Type: application/mbox Size: 2722 bytes Desc: not available URL: From rcritten at redhat.com Thu Apr 21 20:47:43 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Apr 2011 16:47:43 -0400 Subject: [Freeipa-devel] [PATCH] 775 wait for memberof task during install Message-ID: <4DB097EF.1050608@redhat.com> Wait for memberof task and DS to start before proceeding in installation. This was causing a replica DS instance to crash if the task was not completed when we attempted a shutdown to do a restart. In replication.py we were restarting the DS instance without waiting for the ports to become available. It is unlikely that the dn of the memberof task will change but just in case I noted it in the two places it is referenced. ticket 1188 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-775-task.patch Type: application/mbox Size: 4231 bytes Desc: not available URL: From rmeggins at redhat.com Thu Apr 21 21:10:08 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 21 Apr 2011 15:10:08 -0600 Subject: [Freeipa-devel] [PATCH] 775 wait for memberof task during install In-Reply-To: <4DB097EF.1050608@redhat.com> References: <4DB097EF.1050608@redhat.com> Message-ID: <4DB09D30.9020704@redhat.com> On 04/21/2011 02:47 PM, Rob Crittenden wrote: > Wait for memberof task and DS to start before proceeding in installation. > > This was causing a replica DS instance to crash if the task was not > completed when we attempted a shutdown to do a restart. > > In replication.py we were restarting the DS instance without waiting > for the ports to become available. > > It is unlikely that the dn of the memberof task will change but just > in case I noted it in the two places it is referenced. ack > > ticket 1188 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Thu Apr 21 23:01:15 2011 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 21 Apr 2011 19:01:15 -0400 Subject: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry In-Reply-To: <4DB085BB.6080104@redhat.com> References: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> <4DB085BB.6080104@redhat.com> Message-ID: <1303426875.26325.4.camel@willson.li.ssimo.org> On Thu, 2011-04-21 at 15:30 -0400, Dmitri Pal wrote: > On 04/21/2011 03:17 PM, JR Aquino wrote: > > This patch address ticket: > > * https://fedorahosted.org/freeipa/ticket/1181 > > > > This patch provides: > > * ipa-managed-entries tool which can enable/disable any of the managed entry plugins without the need of separate tools. > > -When run without any arguments, the tool will display a list of available plugins detected inside of /usr/share/ipa (this directory can be overridden with the --dir flag) > > * Man Page documenting the tool usage. > > * The removal of install/tools/ipa-host-net-manage and install/tools/man/ipa-host-net-manage.1 > > * Modification to ldap2.py: Added method for verifying upg is disabled by objectfilter: objectclass=disabled. > > The current code assumes that the user private group managed plugin is disabled, if the managed plugin entry is not present. > > Due to bug https://bugzilla.redhat.com/show_bug.cgi?id=660399, the running system will prohibit you from removing a Managed Entry plugin. > > > > NOTE: > > As I was writing this tool, I noticed that in addition to Managed Entry tools, we also seem to have Schema Compatibility management tools. > > I had considered rolling support for those plugins as well, but after further inspection, it appears that there is hierarchical way to determine our current 'Compatibility Plugins' via looking at the .uldif files. > > The method employed by the managed entry tool checks to see if the .ldif file contains a modification which adds an object to the container: cn=Managed Entries,cn=plugins,cn=config. > > If there is interest in it, we could consolidate ipa-compat-manage and ipa-nis-manage by deciding on a default Container for Compat plugins to be located in such as: "cn=Schema Compatibility,cn=plugins,cn=config" > > This would potentially give us 1 tool: ipa-plugin-manage that could handle the enabling / disabling of Compat and Managed Entry Plugins... > > > > Please log an enhancement ticket. I think it will be deferred but > having it in the backlog would be good. Please note that the schema compatibility plugin enabling/disabling should behave differently from the managed entries emabling/disabling. The schema compat plugins configurations are per server, so that you can decide which servers show it and which one doesn't (you may have many masters and only a few allocated to serve legacy machines that need the compat tree). This also means that you have to go to each server to enable/disable the compat trees. This should be made abundantly clear in the documentation of the respective tools. The managed entries stuff instead should be global, and shouldn't touch entries under cn=config (as they are local). If it does please let me know. Simo. -- Simo Sorce * Red Hat, Inc * New York From JR.Aquino at citrix.com Thu Apr 21 23:28:03 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 21 Apr 2011 23:28:03 +0000 Subject: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry In-Reply-To: <1303426875.26325.4.camel@willson.li.ssimo.org> References: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> <4DB085BB.6080104@redhat.com> <1303426875.26325.4.camel@willson.li.ssimo.org> Message-ID: On Apr 21, 2011, at 4:03 PM, "Simo Sorce" > wrote: On Thu, 2011-04-21 at 15:30 -0400, Dmitri Pal wrote: On 04/21/2011 03:17 PM, JR Aquino wrote: This patch address ticket: * https://fedorahosted.org/freeipa/ticket/1181 This patch provides: * ipa-managed-entries tool which can enable/disable any of the managed entry plugins without the need of separate tools. -When run without any arguments, the tool will display a list of available plugins detected inside of /usr/share/ipa (this directory can be overridden with the --dir flag) * Man Page documenting the tool usage. * The removal of install/tools/ipa-host-net-manage and install/tools/man/ipa-host-net-manage.1 * Modification to ldap2.py: Added method for verifying upg is disabled by objectfilter: objectclass=disabled. The current code assumes that the user private group managed plugin is disabled, if the managed plugin entry is not present. Due to bug https://bugzilla.redhat.com/show_bug.cgi?id=660399, the running system will prohibit you from removing a Managed Entry plugin. NOTE: As I was writing this tool, I noticed that in addition to Managed Entry tools, we also seem to have Schema Compatibility management tools. I had considered rolling support for those plugins as well, but after further inspection, it appears that there is hierarchical way to determine our current 'Compatibility Plugins' via looking at the .uldif files. The method employed by the managed entry tool checks to see if the .ldif file contains a modification which adds an object to the container: cn=Managed Entries,cn=plugins,cn=config. If there is interest in it, we could consolidate ipa-compat-manage and ipa-nis-manage by deciding on a default Container for Compat plugins to be located in such as: "cn=Schema Compatibility,cn=plugins,cn=config" This would potentially give us 1 tool: ipa-plugin-manage that could handle the enabling / disabling of Compat and Managed Entry Plugins... Please log an enhancement ticket. I think it will be deferred but having it in the backlog would be good. Please note that the schema compatibility plugin enabling/disabling should behave differently from the managed entries emabling/disabling. The schema compat plugins configurations are per server, so that you can decide which servers show it and which one doesn't (you may have many masters and only a few allocated to serve legacy machines that need the compat tree). This also means that you have to go to each server to enable/disable the compat trees. This should be made abundantly clear in the documentation of the respective tools. The managed entries stuff instead should be global, and shouldn't touch entries under cn=config (as they are local). If it does please let me know. Hmmm Both Private Groups and the Hostgroup -> Netgroup Managed Entries create objects in the container: cn=Managed Entries,cn=plugins,cn=config Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, and one in the cn=config How will these be treated by replication and the multi masters? Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel From ayoung at redhat.com Fri Apr 22 02:43:21 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 21 Apr 2011 22:43:21 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DB06F7D.7060000@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> <4DB06F7D.7060000@redhat.com> Message-ID: <4DB0EB49.9070605@redhat.com> This version deals with #7. Unit tests and jsl is fixed. Rebased on top of Endi's last action-button patch. Remaining issues have to do with css and styling. Still haven't run it through the Selenium tests. On 04/21/2011 01:55 PM, Adam Young wrote: > Again, have not yet run Selenium against this, so please do not push. > There are conflicts between this version and some of edewata's patch. > Additionally, there are some know issues with the rendering on the ACI > pages which I'll iron out before this gets submitted for real. > > This version solves Issues 1,2,4,5 (sort of) ,8,9,and 10 from below. > > > On 04/19/2011 08:59 PM, Adam Young wrote: >> Good points all. Only one minoir quibble, in-line. >> >> >> On 04/19/2011 05:31 PM, Endi Sukma Dewata wrote: >>> On 4/19/2011 3:07 PM, Adam Young wrote: >>>> going to post this, but with a request to hold on pushing to the >>>> repo. I >>>> have not yet tested against selenium, and suspect that it will >>>> break all >>>> selenium test navigation. >>> >>> I've tested this patch with static data. There are some issues: >>> >>> 1. Incorrect data after switching tabs. >>> Open Users tab, then click User Groups tab, all of the groups will >>> be admin's. Refresh the page, it will show the correct data. >>> >>> 2. Missing third level tabs. >>> Open HBAC tab, the Services & Service Groups are missing. >>> Open SUDO tab, the Commands and Command Groups tabs are missing. >>> Open Role Based Access Control, the Permissions and Privileges tabs >>> are missing. >>> >>> 3. Default tab is not activated. >>> Open Users->admin, the Settings tab is inactive. It should be bigger >>> than the other tabs. >>> >>> 4. Inconsistent position of the action buttons. >>> Open Users tab, observe the position of the Delete & Add buttons. >>> Then click one of the users, the Reset & Update buttons move to >>> the left. >>> >>> 5. Entity label (e.g. Users) should be used instead of entity name >>> (e.g. user) as the page title (next to the buttons). >>> >>> 6. The page title (e.g. user) is too close to the tab groups (e.g. >>> Settings). It needs some space between them. >>> >>> 7. The order of tab groups is not very intuitive. >>> Open Groups tab, click one of the groups. The default tab group >>> (i.e. >>> Settings) is located between Member and Member Of. It would be >>> better to put the default tab at the left most position. >> >> While in general your observations are spot on, I'd like to point out >> that this is intentional, but that the goal will be to always open >> the leftmost tab. This will allow us to make entities that are >> primarily containers, like netgroups, as well as dns zone, default to >> the page that shows the most common use case: manage contained entities. >> >>> >>> 8. The if-then clause on entity.js:46 is unnecessary. There's no need >>> to check spec.facet_group before assigning it to that.facet_group. >>> >>> 9. The assignment on entity.js:296 is unnecessary. Each facet has a >>> reference to the entity, so the entity header can be accessed using >>> that.entity.header. >> >>> >>> 10. IPA.entity_header() should take a spec object instead of attribute >>> list for consistency. >>> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0221-2-action-panel-to-top-tabs.patch Type: text/x-patch Size: 64136 bytes Desc: not available URL: From mkosek at redhat.com Fri Apr 22 09:48:50 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 22 Apr 2011 11:48:50 +0200 Subject: [Freeipa-devel] [PATCH] 775 wait for memberof task during install In-Reply-To: <4DB09D30.9020704@redhat.com> References: <4DB097EF.1050608@redhat.com> <4DB09D30.9020704@redhat.com> Message-ID: <1303465730.22142.51.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-21 at 15:10 -0600, Rich Megginson wrote: > On 04/21/2011 02:47 PM, Rob Crittenden wrote: > > Wait for memberof task and DS to start before proceeding in > > installation. > > > > This was causing a replica DS instance to crash if the task was not > > completed when we attempted a shutdown to do a restart. > > > > In replication.py we were restarting the DS instance without waiting > > for the ports to become available. > > > > It is unlikely that the dn of the memberof task will change but just > > in case I noted it in the two places it is referenced. > ack > > > > ticket 1188 > > > > rob It's OK with me too. Tested on F-15, pylint is clean. Pushed to master, ipa-2-0. I have a related question: Is it intentional that we don't run "chkconfig ipa on" for the replica? It surprised me when IPA replica did not start after the restart. If it is a bug, I will open a ticket for that. Martin From rcritten at redhat.com Fri Apr 22 13:45:38 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Apr 2011 09:45:38 -0400 Subject: [Freeipa-devel] [PATCH] 776 handle manager properly Message-ID: <4DB18682.5000800@redhat.com> manager should be a dn string so convert back and forth when adding/viewing entries. ticket 1151 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-776-manager.patch Type: application/mbox Size: 5466 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 22 17:47:30 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Apr 2011 13:47:30 -0400 Subject: [Freeipa-devel] [PATCH] 777 adjust output of user-find Message-ID: <4DB1BF32.4090005@redhat.com> Modify the default attributes shown in user-find to match the UI design. This change means the UI can stop using the --all option and have to retrieve significantly less information from the server. It also speeds up user-find as it doesn't have to calculate membership. This adds a new baseclass parameter, search_display_attributes, which can provide a separate list from default_attributes just for find commands. The UI will need to be changed to switch from using cn to using givenname and sn. ticket 1136 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-777-userfind.patch Type: application/mbox Size: 5269 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 22 18:16:19 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Apr 2011 14:16:19 -0400 Subject: [Freeipa-devel] [PATCH] 23 Optimize and dynamically verify group membership In-Reply-To: References: <4D94E88C.2090004@redhat.com> <934AB894-09AC-425A-92BD-9BA0B236A21D@citrixonline.com> <8CE5CB9F-4C26-416A-88B4-9EF9B5CB321D@citrixonline.com> <69A99C7A-56D1-4FC6-9434-CC470E779A82@citrixonline.com> <4DA49201.9090605@redhat.com> <80D35ED5-84DD-4EBD-BED2-68B14DF8AD12@citrixonline.com> <4DAF189C.4010804@redhat.com> Message-ID: <4DB1C5F3.8080109@redhat.com> JR Aquino wrote: > On Apr 20, 2011, at 10:32 AM, Rob Crittenden wrote: > ... > >>>> Seems to work as advertised, I just have a couple of requests: >>>> >>>> - Some of the comments are really long, can you limit to ~75 chars per line? >>>> - In this code block: >>>> >>>> for r in results: >>>> direct.append(r[0]) >>>> try: >>>> indirect.remove(r[0].lower()) >>>> except ValueError: >>>> pass >>>> >>>> We should log if a ValueError is thrown, this would mean something is really wrong. Can you import logging in the file and replace pass with something like: >>>> >>>> logging.info('Failed to remove indirect entry %s from %s' % r[0], entry_dn) >>>> >>>> I wonder if we should raise the ValueError too. This means that something went very wrong. >>> >>> Yes I agree that we should raise the error. >>> >>> Here is the patch with the requested changes: >>> >>> * Fixed width to be PEP8 compliant >>> * import logging >>> * Added logging line in exception >>> * Raise ValueError if we blow up during indirect removal. >>> >> >> Fixes 1-3 look good. I think for the exception you want: >> >> except ValueError, e: >> logging .... >> raise e >> >> A ValueError won't get returned over XML-RPC but the full backtrace will be logged on the server side. The end-user will get a 903 (Internal error raised). >> >> rob > > Ok adjusted patch attached to correct for the exception raised. > ack, pushed to master and ipa-2-0. Before pushing I removed some trailing whitespace and amended the commit message to add more information. rob From ayoung at redhat.com Fri Apr 22 18:34:52 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 22 Apr 2011 14:34:52 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0222-Removed-entities-that-are-for-some-reason-invalid Message-ID: <4DB1CA4C.7030103@redhat.com> This might be my favorite patch name yet. This patch depends on admiyo-0221-2 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0222-Removed-entities-that-are-for-some-reason-invalid.patch Type: text/x-patch Size: 4149 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 22 18:32:33 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Apr 2011 14:32:33 -0400 Subject: [Freeipa-devel] [PATCH] 775 wait for memberof task during install In-Reply-To: <1303465730.22142.51.camel@dhcp-25-52.brq.redhat.com> References: <4DB097EF.1050608@redhat.com> <4DB09D30.9020704@redhat.com> <1303465730.22142.51.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB1C9C1.1050307@redhat.com> Martin Kosek wrote: > On Thu, 2011-04-21 at 15:10 -0600, Rich Megginson wrote: >> On 04/21/2011 02:47 PM, Rob Crittenden wrote: >>> Wait for memberof task and DS to start before proceeding in >>> installation. >>> >>> This was causing a replica DS instance to crash if the task was not >>> completed when we attempted a shutdown to do a restart. >>> >>> In replication.py we were restarting the DS instance without waiting >>> for the ports to become available. >>> >>> It is unlikely that the dn of the memberof task will change but just >>> in case I noted it in the two places it is referenced. >> ack >>> >>> ticket 1188 >>> >>> rob > > It's OK with me too. Tested on F-15, pylint is clean. > > Pushed to master, ipa-2-0. > > I have a related question: > Is it intentional that we don't run "chkconfig ipa on" for the replica? > It surprised me when IPA replica did not start after the restart. If it > is a bug, I will open a ticket for that. > > Martin > I think that's a bug, please open a ticket. rob From adam at younglogic.com Fri Apr 22 19:24:44 2011 From: adam at younglogic.com (Adam Young) Date: Fri, 22 Apr 2011 15:24:44 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0223-make-use-of-new-user-find-columns Message-ID: <4DB1D5FC.7070302@younglogic.com> required rcrit-0777 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0223-make-use-of-new-user-find-columns.patch Type: text/x-patch Size: 884 bytes Desc: not available URL: From ayoung at redhat.com Fri Apr 22 19:33:51 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 22 Apr 2011 15:33:51 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DB0EB49.9070605@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> <4DB06F7D.7060000@redhat.com> <4DB0EB49.9070605@redhat.com> Message-ID: <4DB1D81F.2050501@redhat.com> OK, with this, the most egregious of the UI issues are fixed. While I'm sure we'll want to do more with it in the long term, I'm going to say that this is ready to go in. We'll fix the selenium tests as a follow on patch. On 04/21/2011 10:43 PM, Adam Young wrote: > This version deals with #7. Unit tests and jsl is fixed. Rebased on > top of Endi's last action-button patch. > > Remaining issues have to do with css and styling. > > Still haven't run it through the Selenium tests. > > > On 04/21/2011 01:55 PM, Adam Young wrote: >> Again, have not yet run Selenium against this, so please do not >> push. There are conflicts between this version and some of edewata's >> patch. Additionally, there are some know issues with the rendering >> on the ACI pages which I'll iron out before this gets submitted for >> real. >> >> This version solves Issues 1,2,4,5 (sort of) ,8,9,and 10 from below. >> >> >> On 04/19/2011 08:59 PM, Adam Young wrote: >>> Good points all. Only one minoir quibble, in-line. >>> >>> >>> On 04/19/2011 05:31 PM, Endi Sukma Dewata wrote: >>>> On 4/19/2011 3:07 PM, Adam Young wrote: >>>>> going to post this, but with a request to hold on pushing to the >>>>> repo. I >>>>> have not yet tested against selenium, and suspect that it will >>>>> break all >>>>> selenium test navigation. >>>> >>>> I've tested this patch with static data. There are some issues: >>>> >>>> 1. Incorrect data after switching tabs. >>>> Open Users tab, then click User Groups tab, all of the groups will >>>> be admin's. Refresh the page, it will show the correct data. >>>> >>>> 2. Missing third level tabs. >>>> Open HBAC tab, the Services & Service Groups are missing. >>>> Open SUDO tab, the Commands and Command Groups tabs are missing. >>>> Open Role Based Access Control, the Permissions and Privileges tabs >>>> are missing. >>>> >>>> 3. Default tab is not activated. >>>> Open Users->admin, the Settings tab is inactive. It should be >>>> bigger >>>> than the other tabs. >>>> >>>> 4. Inconsistent position of the action buttons. >>>> Open Users tab, observe the position of the Delete & Add buttons. >>>> Then click one of the users, the Reset & Update buttons move to >>>> the left. >>>> >>>> 5. Entity label (e.g. Users) should be used instead of entity name >>>> (e.g. user) as the page title (next to the buttons). >>>> >>>> 6. The page title (e.g. user) is too close to the tab groups (e.g. >>>> Settings). It needs some space between them. >>>> >>>> 7. The order of tab groups is not very intuitive. >>>> Open Groups tab, click one of the groups. The default tab group >>>> (i.e. >>>> Settings) is located between Member and Member Of. It would be >>>> better to put the default tab at the left most position. >>> >>> While in general your observations are spot on, I'd like to point >>> out that this is intentional, but that the goal will be to always >>> open the leftmost tab. This will allow us to make entities that are >>> primarily containers, like netgroups, as well as dns zone, default >>> to the page that shows the most common use case: manage contained >>> entities. >>> >>>> >>>> 8. The if-then clause on entity.js:46 is unnecessary. There's no need >>>> to check spec.facet_group before assigning it to that.facet_group. >>>> >>>> 9. The assignment on entity.js:296 is unnecessary. Each facet has a >>>> reference to the entity, so the entity header can be accessed using >>>> that.entity.header. >>> >>>> >>>> 10. IPA.entity_header() should take a spec object instead of attribute >>>> list for consistency. >>>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0221-3-action-panel-to-top-tabs.patch Type: text/x-patch Size: 64323 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 22 19:53:58 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Apr 2011 15:53:58 -0400 Subject: [Freeipa-devel] [PATCH] 24 Add sudorule and hbacrule to indirectmemberof attributes of user.py In-Reply-To: <36AD4E47-C1BE-4603-8578-1823F2C89892@citrixonline.com> References: <36AD4E47-C1BE-4603-8578-1823F2C89892@citrixonline.com> Message-ID: <4DB1DCD6.1060606@redhat.com> JR Aquino wrote: > On Apr 12, 2011, at 9:45 AM, JR Aquino wrote: > >> Add HBAC Rule and Sudo Rule to users as indirect member attributes to simplify the auditing of users for their indirect membership to their authorization rights. >> >> An Administrator should have the ability to quickly identify the rights a user will have in the system. >> >> For example. With the patch added, my user show looks like this: >> >> # ipa user-show tester --all >> dn: uid=builder,cn=users,cn=accounts,dc=example,dc=com >> User login: tester >> First name: Tester >> Last name: Engineering >> Full name: Tester Engineering >> Display name: Tester Engineering >> Initials: TE >> Home directory: /home/tester >> GECOS field: Tester Engineering >> Login shell: /bin/sh >> Kerberos principal: tester at EXAMPLE.COM >> UID: 1829800388 >> GID: 1829800388 >> Account disabled: False >> Member of groups: ipausers, auto-dev-deploy-tools, build-integration >> ipauniqueid: 72fa22c6-6085-11e0-9629-0023aefe4ec0 >> krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com >> memberofindirect_HBAC rule: development >> memberofindirect_Sudo Rule: AUTO-dev-deploy-tools_DEPLOY, AUTO-dev-deploy-tools_ZENOSS, build-integration >> mepmanagedentry: cn=tester,cn=groups,cn=accounts,dc=example,dc=com >> objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > OPPS, forgot to have PATCH in the subject. > I think you need this as well, right? - 'memberof': ['group', 'netgroup', 'role'], + 'memberof': ['group', 'netgroup', 'role', 'sudorule', 'hbacrule'], From ayoung at redhat.com Fri Apr 22 20:06:47 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 22 Apr 2011 16:06:47 -0400 Subject: [Freeipa-devel] [PATCH] 776 handle manager properly In-Reply-To: <4DB18682.5000800@redhat.com> References: <4DB18682.5000800@redhat.com> Message-ID: <4DB1DFD7.1080107@redhat.com> On 04/22/2011 09:45 AM, Rob Crittenden wrote: > manager should be a dn string so convert back and forth when > adding/viewing entries. > > ticket 1151 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Apr 22 20:06:58 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 22 Apr 2011 16:06:58 -0400 Subject: [Freeipa-devel] [PATCH] 777 adjust output of user-find In-Reply-To: <4DB1BF32.4090005@redhat.com> References: <4DB1BF32.4090005@redhat.com> Message-ID: <4DB1DFE2.5030300@redhat.com> On 04/22/2011 01:47 PM, Rob Crittenden wrote: > Modify the default attributes shown in user-find to match the UI design. > > This change means the UI can stop using the --all option and have to > retrieve significantly less information from the server. It also > speeds up user-find as it doesn't have to calculate membership. > > This adds a new baseclass parameter, search_display_attributes, which > can provide a separate list from default_attributes just for find > commands. > > The UI will need to be changed to switch from using cn to using > givenname and sn. > > ticket 1136 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Apr 22 20:07:14 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 22 Apr 2011 16:07:14 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0223-make-use-of-new-user-find-columns In-Reply-To: <4DB1D5FC.7070302@younglogic.com> References: <4DB1D5FC.7070302@younglogic.com> Message-ID: <4DB1DFF2.4050002@redhat.com> On 04/22/2011 03:24 PM, Adam Young wrote: > required rcrit-0777 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACKed in IRC and pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Apr 22 20:10:47 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 22 Apr 2011 16:10:47 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0223-make-use-of-new-user-find-columns In-Reply-To: <4DB1DFF2.4050002@redhat.com> References: <4DB1D5FC.7070302@younglogic.com> <4DB1DFF2.4050002@redhat.com> Message-ID: <4DB1E0C7.9020600@redhat.com> On 04/22/2011 04:07 PM, Adam Young wrote: > On 04/22/2011 03:24 PM, Adam Young wrote: >> required rcrit-0777 >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACKed in IRC and pushed to master > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Commit missed a Javascript lint error which I had corrected and tested. Pushed under the one line rule [ayoung at ayoung ui]$ git show HEAD commit db07c374aa34ca91831af8a3d158330e8082b7bb Author: Adam Young Date: Fri Apr 22 16:08:48 2011 -0400 fix JSL error diff --git a/install/ui/user.js b/install/ui/user.js index 19a991e..7a8adb7 100644 --- a/install/ui/user.js +++ b/install/ui/user.js @@ -29,7 +29,7 @@ IPA.entity_factories.user = function() { builder. entity('user'). search_facet({ - columns:['uid','givenname','sn','uidnumber','mail','telephonenumber','title'], + columns:['uid','givenname','sn','uidnumber','mail','telephonenumber','title'] }). details_facet({sections:[ { -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Apr 22 20:35:46 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Apr 2011 16:35:46 -0400 Subject: [Freeipa-devel] [PATCH] 776 handle manager properly In-Reply-To: <4DB1DFD7.1080107@redhat.com> References: <4DB18682.5000800@redhat.com> <4DB1DFD7.1080107@redhat.com> Message-ID: <4DB1E6A2.6010705@redhat.com> Adam Young wrote: > On 04/22/2011 09:45 AM, Rob Crittenden wrote: >> manager should be a dn string so convert back and forth when >> adding/viewing entries. >> >> ticket 1151 >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK. pushed to master pushed to ipa-2-0 as well From rcritten at redhat.com Fri Apr 22 20:35:57 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Apr 2011 16:35:57 -0400 Subject: [Freeipa-devel] [PATCH] 777 adjust output of user-find In-Reply-To: <4DB1DFE2.5030300@redhat.com> References: <4DB1BF32.4090005@redhat.com> <4DB1DFE2.5030300@redhat.com> Message-ID: <4DB1E6AD.3090400@redhat.com> Adam Young wrote: > On 04/22/2011 01:47 PM, Rob Crittenden wrote: >> Modify the default attributes shown in user-find to match the UI design. >> >> This change means the UI can stop using the --all option and have to >> retrieve significantly less information from the server. It also >> speeds up user-find as it doesn't have to calculate membership. >> >> This adds a new baseclass parameter, search_display_attributes, which >> can provide a separate list from default_attributes just for find >> commands. >> >> The UI will need to be changed to switch from using cn to using >> givenname and sn. >> >> ticket 1136 >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK. Pushed to master > pushed to ipa-2-0 as well From JR.Aquino at citrix.com Fri Apr 22 20:50:16 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 22 Apr 2011 20:50:16 +0000 Subject: [Freeipa-devel] [PATCH] 24 Add sudorule and hbacrule to (indirect)memberof attributes of user.py In-Reply-To: <4DB1DCD6.1060606@redhat.com> References: <36AD4E47-C1BE-4603-8578-1823F2C89892@citrixonline.com> <4DB1DCD6.1060606@redhat.com> Message-ID: On Apr 22, 2011, at 12:53 PM, Rob Crittenden wrote: > JR Aquino wrote: >> On Apr 12, 2011, at 9:45 AM, JR Aquino wrote: >> >>> Add HBAC Rule and Sudo Rule to users as indirect member attributes to simplify the auditing of users for their indirect membership to their authorization rights. >>> >>> An Administrator should have the ability to quickly identify the rights a user will have in the system. >>> >>> For example. With the patch added, my user show looks like this: >>> >>> # ipa user-show tester --all >>> dn: uid=builder,cn=users,cn=accounts,dc=example,dc=com >>> User login: tester >>> First name: Tester >>> Last name: Engineering >>> Full name: Tester Engineering >>> Display name: Tester Engineering >>> Initials: TE >>> Home directory: /home/tester >>> GECOS field: Tester Engineering >>> Login shell: /bin/sh >>> Kerberos principal: tester at EXAMPLE.COM >>> UID: 1829800388 >>> GID: 1829800388 >>> Account disabled: False >>> Member of groups: ipausers, auto-dev-deploy-tools, build-integration >>> ipauniqueid: 72fa22c6-6085-11e0-9629-0023aefe4ec0 >>> krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com >>> memberofindirect_HBAC rule: development >>> memberofindirect_Sudo Rule: AUTO-dev-deploy-tools_DEPLOY, AUTO-dev-deploy-tools_ZENOSS, build-integration >>> mepmanagedentry: cn=tester,cn=groups,cn=accounts,dc=example,dc=com >>> objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> OPPS, forgot to have PATCH in the subject. >> > > I think you need this as well, right? > > - 'memberof': ['group', 'netgroup', 'role'], > + 'memberof': ['group', 'netgroup', 'role', 'sudorule', 'hbacrule'], Yes, you are right, the users can individually be assigned to rules directly. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-memberof-indirectmemberof-attrib.patch Type: application/octet-stream Size: 974 bytes Desc: freeipa-jraquino-0024-Add-sudorule-and-hbacrule-to-memberof-indirectmemberof-attrib.patch URL: From rcritten at redhat.com Fri Apr 22 21:21:08 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Apr 2011 17:21:08 -0400 Subject: [Freeipa-devel] [PATCH] 778 validate zonemgr Message-ID: <4DB1F144.5020602@redhat.com> Ensure that the zonemgr passed to the installer conforms to IA5String. ticket 1164 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-778-zonemgr.patch Type: application/mbox Size: 1963 bytes Desc: not available URL: From edewata at redhat.com Fri Apr 22 22:28:51 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 22 Apr 2011 17:28:51 -0500 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DB1D81F.2050501@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> <4DB06F7D.7060000@redhat.com> <4DB0EB49.9070605@redhat.com> <4DB1D81F.2050501@redhat.com> Message-ID: <4DB20123.6000707@redhat.com> On 4/22/2011 2:33 PM, Adam Young wrote: >>> Again, have not yet run Selenium against this, so please do not push. >>> There are conflicts between this version and some of edewata's patch. >>> Additionally, there are some know issues with the rendering on the >>> ACI pages which I'll iron out before this gets submitted for real. >>> >>> This version solves Issues 1,2,4,5 (sort of) ,8,9,and 10 from below. >> This version deals with #7. Unit tests and jsl is fixed. Rebased on >> top of Endi's last action-button patch. >> >> Remaining issues have to do with css and styling. >> >> Still haven't run it through the Selenium tests. > OK, with this, the most egregious of the UI issues are fixed. While I'm > sure we'll want to do more with it in the long term, I'm going to say > that this is ready to go in. We'll fix the selenium tests as a follow on > patch. Some issues: 3. Default tab is not activated. Open Users, click one of the user, the default tab is activated. Click Back to List, open the user again, the default tab is not activated. 4. Inconsistent position of the action buttons. - Open Users tab, observe the position of the Delete & Add buttons. Then click one of the users, the Reset & Update buttons move to the left. - Open User Groups tab, observe the Add buttons, click one of the groups, the Enroll button moves to the left. 5. Entity label should be used instead of entity name as the page title. Open Sudo -> Sudo Command Groups -> group1. The page title is "SUDOCMDGROUP:GROUP1". The problem with this is that unlike the label, entity name will not be translated. 9. These facet.entity_header assignments are unnecessary: - entity.js:307 - details_tests.js:211 - entity_tests.js:79 Each facet has a reference to the entity, so the entity header can be accessed using that.entity.header inside the facet or facet.entity.header outside the facet. 11. Navigation error. Open User Groups tab, click one of the groups. Under Member Users, click one of the users. It will show an error dialog box (it has some typos too). 12. In the search facet there is a big space between the buttons and the results table. 13. The 3rd level tabs appear only when the HBAC, Sudo, and RBAC tabs are selected. This is causing the rest of the page to shift down. As I mentioned before, here is my suggestion: http://edewata.fedorapeople.org/images/mock1.png http://edewata.fedorapeople.org/images/mock2.png 14. According to the spec the buttons should be located below the 4th level tabs (facet tabs). So it should be inside a 'facet-header' instead of 'entity-header'. 15. Most of navigation links are on the left part of the page, but 'Back to Link' is on the right side. It's a bit inconvenient having to go all the way to the right just to go back to the search page, especially when reviewing many entries. 16. Some facet group headers in the 4th level tabs are unnecessary. The Settings header above the Settings tab is redundant. The Member header above DNS resource record tab is probably inappropriate although that's how it's implemented internally. There should be a way not to show the headers. 17. Association facet doesn't set page title. Open User Groups, the page title is "USER GROUPS". Click one of the groups, it will open an association facet, the page title is unchanged. Then click Settings tab, the title changes to "GROUP:...". Click the association again, the title remains the same. 18. Kerberos Ticket Policy and Configuration tabs don't have page titles. 19. There should be a space after colon in the page title. Open Users tab, then click admin. The title is "USER:ADMIN". 20. The facet groups needs to be customizable. Currently it's stored in unordered set in entity's facet_group and the order is hard- coded in get_facet() and facet_tabs(). It would be difficult to workaround this limitations in custom facets. See how facets are stored in entity. The names are stored in an ordered list (that.facets) and the instances are stored in a dictionary (that.facets_by_name). Facet groups should use a similar method to store the order and facet collections. In get_facet() the default facet should be the first facet in the first group. In facet_tabs() the tab_section should be created according to the order they are stored. 21. The IPA.entity_header should be created in entity.init() instead of in entity.setup() line 305. The entity.setup() only needs to store the container in the entity.header. This also eliminates manual creations in the qunit tests. For issues #12-16 I think we need to get UXD's feedback. -- Endi S. Dewata From adam at younglogic.com Sat Apr 23 00:40:22 2011 From: adam at younglogic.com (Adam Young) Date: Fri, 22 Apr 2011 20:40:22 -0400 Subject: [Freeipa-devel] [PATCH]admiyo-0224-1-Upgrade-to-jquery-1.5.2 Message-ID: <4DB21FF6.1090200@younglogic.com> Something about this version of JQuery seems to make the unit tests run unbelievably fast. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0224-1-Upgrade-to-jquery-1.5.2.patch Type: text/x-patch Size: 243975 bytes Desc: not available URL: From edewata at redhat.com Sat Apr 23 03:28:24 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 22 Apr 2011 22:28:24 -0500 Subject: [Freeipa-devel] [PATCH]admiyo-0224-1-Upgrade-to-jquery-1.5.2 In-Reply-To: <4DB21FF6.1090200@younglogic.com> References: <4DB21FF6.1090200@younglogic.com> Message-ID: <4DB24758.4090104@redhat.com> On 4/22/2011 7:40 PM, Adam Young wrote: > Something about this version of JQuery seems to make the unit tests run > unbelievably fast. ACK and pushed to master. -- Endi S. Dewata From ssorce at redhat.com Mon Apr 25 13:43:17 2011 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 25 Apr 2011 09:43:17 -0400 Subject: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry In-Reply-To: References: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> <4DB085BB.6080104@redhat.com> <1303426875.26325.4.camel@willson.li.ssimo.org> Message-ID: <1303738997.23464.13.camel@willson.li.ssimo.org> On Thu, 2011-04-21 at 23:28 +0000, JR Aquino wrote: > Hmmm > Both Private Groups and the Hostgroup -> Netgroup Managed Entries > create objects in the container: > cn=Managed Entries,cn=plugins,cn=config > > Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, > and one in the cn=config > > How will these be treated by replication and the multi masters? Only the common objects in the public suffix are replicated. I think at some point we discussed that we should use a filter in the private config entry made so that we could enable/disable the plugin by simply making the filter result true/false. Thus not ever touch the entries in cn=config but simply "enable"/"disable" the functionality by (not)adding the appropriate attributes to objects so that filters would (not) match. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Apr 25 13:49:48 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 25 Apr 2011 09:49:48 -0400 Subject: [Freeipa-devel] [PATCH] 777 adjust output of user-find In-Reply-To: <4DB1BF32.4090005@redhat.com> References: <4DB1BF32.4090005@redhat.com> Message-ID: <4DB57BFC.30108@redhat.com> On 04/22/2011 01:47 PM, Rob Crittenden wrote: > Modify the default attributes shown in user-find to match the UI design. > > This change means the UI can stop using the --all option and have to > retrieve significantly less information from the server. It also > speeds up user-find as it doesn't have to calculate membership. > > This adds a new baseclass parameter, search_display_attributes, which > can provide a separate list from default_attributes just for find > commands. > > The UI will need to be changed to switch from using cn to using > givenname and sn. Please log a ticket to track this. > > ticket 1136 > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Mon Apr 25 14:18:43 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 25 Apr 2011 10:18:43 -0400 Subject: [Freeipa-devel] [PATCH] 777 adjust output of user-find In-Reply-To: <4DB57BFC.30108@redhat.com> References: <4DB1BF32.4090005@redhat.com> <4DB57BFC.30108@redhat.com> Message-ID: <4DB582C3.1020107@redhat.com> On 04/25/2011 09:49 AM, Dmitri Pal wrote: > On 04/22/2011 01:47 PM, Rob Crittenden wrote: >> Modify the default attributes shown in user-find to match the UI design. >> >> This change means the UI can stop using the --all option and have to >> retrieve significantly less information from the server. It also >> speeds up user-find as it doesn't have to calculate membership. >> >> This adds a new baseclass parameter, search_display_attributes, which >> can provide a separate list from default_attributes just for find >> commands. >> >> The UI will need to be changed to switch from using cn to using >> givenname and sn. > > Please log a ticket to track this. Already is one, 1136. Keeping the front and backend work together on one ticket for this makes sense. > > >> >> ticket 1136 >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From JR.Aquino at citrix.com Mon Apr 25 14:59:17 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Mon, 25 Apr 2011 14:59:17 +0000 Subject: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry In-Reply-To: <1303738997.23464.13.camel@willson.li.ssimo.org> References: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> <4DB085BB.6080104@redhat.com> <1303426875.26325.4.camel@willson.li.ssimo.org> <1303738997.23464.13.camel@willson.li.ssimo.org> Message-ID: On Apr 25, 2011, at 6:43 AM, Simo Sorce wrote: > On Thu, 2011-04-21 at 23:28 +0000, JR Aquino wrote: >> Hmmm >> Both Private Groups and the Hostgroup -> Netgroup Managed Entries >> create objects in the container: >> cn=Managed Entries,cn=plugins,cn=config >> >> Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, >> and one in the cn=config >> >> How will these be treated by replication and the multi masters? > > Only the common objects in the public suffix are replicated. > I think at some point we discussed that we should use a filter in the > private config entry made so that we could enable/disable the plugin by > simply making the filter result true/false. > Thus not ever touch the entries in cn=config but simply > "enable"/"disable" the functionality by (not)adding the appropriate > attributes to objects so that filters would (not) match. > > Simo. This tool works by toggling the originfilter: objectclass=disabled in order to turn off the plugin. From ssorce at redhat.com Mon Apr 25 16:00:04 2011 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 25 Apr 2011 12:00:04 -0400 Subject: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry In-Reply-To: References: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> <4DB085BB.6080104@redhat.com> <1303426875.26325.4.camel@willson.li.ssimo.org> <1303738997.23464.13.camel@willson.li.ssimo.org> Message-ID: <1303747204.23464.19.camel@willson.li.ssimo.org> On Mon, 2011-04-25 at 14:59 +0000, JR Aquino wrote: > On Apr 25, 2011, at 6:43 AM, Simo Sorce wrote: > > > On Thu, 2011-04-21 at 23:28 +0000, JR Aquino wrote: > >> Hmmm > >> Both Private Groups and the Hostgroup -> Netgroup Managed Entries > >> create objects in the container: > >> cn=Managed Entries,cn=plugins,cn=config > >> > >> Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, > >> and one in the cn=config > >> > >> How will these be treated by replication and the multi masters? > > > > Only the common objects in the public suffix are replicated. > > I think at some point we discussed that we should use a filter in the > > private config entry made so that we could enable/disable the plugin by > > simply making the filter result true/false. > > Thus not ever touch the entries in cn=config but simply > > "enable"/"disable" the functionality by (not)adding the appropriate > > attributes to objects so that filters would (not) match. > > > > Simo. > > This tool works by toggling the originfilter: objectclass=disabled in order to turn off the plugin. But this is backwards, because originfilter is defined in the configuration entry stored in cn=config Meaning as soon as you change it one server will behave differently from the others until you go and change it on each and every server. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Apr 25 16:12:26 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 25 Apr 2011 12:12:26 -0400 Subject: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry In-Reply-To: <1303747204.23464.19.camel@willson.li.ssimo.org> References: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> <4DB085BB.6080104@redhat.com> <1303426875.26325.4.camel@willson.li.ssimo.org> <1303738997.23464.13.camel@willson.li.ssimo.org> <1303747204.23464.19.camel@willson.li.ssimo.org> Message-ID: <4DB59D6A.9010005@redhat.com> On 04/25/2011 12:00 PM, Simo Sorce wrote: > On Mon, 2011-04-25 at 14:59 +0000, JR Aquino wrote: >> On Apr 25, 2011, at 6:43 AM, Simo Sorce wrote: >> >>> On Thu, 2011-04-21 at 23:28 +0000, JR Aquino wrote: >>>> Hmmm >>>> Both Private Groups and the Hostgroup -> Netgroup Managed Entries >>>> create objects in the container: >>>> cn=Managed Entries,cn=plugins,cn=config >>>> >>>> Each Ldif contains 2 ldap objects. One that lives in the main $SUFFIX, >>>> and one in the cn=config >>>> >>>> How will these be treated by replication and the multi masters? >>> Only the common objects in the public suffix are replicated. >>> I think at some point we discussed that we should use a filter in the >>> private config entry made so that we could enable/disable the plugin by >>> simply making the filter result true/false. >>> Thus not ever touch the entries in cn=config but simply >>> "enable"/"disable" the functionality by (not)adding the appropriate >>> attributes to objects so that filters would (not) match. >>> >>> Simo. >> This tool works by toggling the originfilter: objectclass=disabled in order to turn off the plugin. > But this is backwards, because originfilter is defined in the > configuration entry stored in cn=config > > Meaning as soon as you change it one server will behave differently from > the others until you go and change it on each and every server. > > Simo. > This is a problem with the place where we store the configuration since it is not replicated. But I am concerned about moving it to some other place. Any ideas of what would be a "proper" solution to make the change affect all replicas? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Mon Apr 25 17:32:34 2011 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 25 Apr 2011 13:32:34 -0400 Subject: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry In-Reply-To: <4DB59D6A.9010005@redhat.com> References: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> <4DB085BB.6080104@redhat.com> <1303426875.26325.4.camel@willson.li.ssimo.org> <1303738997.23464.13.camel@willson.li.ssimo.org> <1303747204.23464.19.camel@willson.li.ssimo.org> <4DB59D6A.9010005@redhat.com> Message-ID: <1303752754.23464.24.camel@willson.li.ssimo.org> On Mon, 2011-04-25 at 12:12 -0400, Dmitri Pal wrote: > This is a problem with the place where we store the configuration > since > it is not replicated. But I am concerned about moving it to some other > place. > Any ideas of what would be a "proper" solution to make the change > affect > all replicas? In order to avoid changing all plugins I am thinking we might create a cn=plugin subtree under the shared cn=etc tree. And have a new IPA plugin monitor it. This plugin will act on any change done to this tree and copy any change to the non-shared cn=config tree in order to reconfigure plugins. This still leaves open the fact that someone may change directly what's in cn=config instead of modifying the shared subtree. Not sure how to cope with that best. One way could be to immediately reset back the values to what's in the shared tree, but this means intercepting also changes to cn=config. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Apr 25 18:08:28 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 25 Apr 2011 14:08:28 -0400 Subject: [Freeipa-devel] [PATCH] 25 Create Tool for Enabling Disabling Managed Entry In-Reply-To: <1303752754.23464.24.camel@willson.li.ssimo.org> References: <28D50949-6CAB-4B58-BA3D-7F2C31EFEC35@citrixonline.com> <4DB085BB.6080104@redhat.com> <1303426875.26325.4.camel@willson.li.ssimo.org> <1303738997.23464.13.camel@willson.li.ssimo.org> <1303747204.23464.19.camel@willson.li.ssimo.org> <4DB59D6A.9010005@redhat.com> <1303752754.23464.24.camel@willson.li.ssimo.org> Message-ID: <4DB5B89C.3040603@redhat.com> On 04/25/2011 01:32 PM, Simo Sorce wrote: > On Mon, 2011-04-25 at 12:12 -0400, Dmitri Pal wrote: >> This is a problem with the place where we store the configuration >> since >> it is not replicated. But I am concerned about moving it to some other >> place. >> Any ideas of what would be a "proper" solution to make the change >> affect >> all replicas? > In order to avoid changing all plugins I am thinking we might create a > cn=plugin subtree under the shared cn=etc tree. > > And have a new IPA plugin monitor it. > > This plugin will act on any change done to this tree and copy any change > to the non-shared cn=config tree in order to reconfigure plugins. > > This still leaves open the fact that someone may change directly what's > in cn=config instead of modifying the shared subtree. We can create an ACI that will prevent the modification operation to the managed entry plugin configuration for any user except the internal op. This will prevent direct modification. Of cause if user removes ACI all bets are off, but this operation is similar to removing any other ACI that grants some access or protects some crucial part of the tree. It prevents customer from erroneously shooting himself in the foot but would not prevent a suicide if one is so determined... > Not sure how to cope with that best. One way could be to immediately > reset back the values to what's in the shared tree, but this means > intercepting also changes to cn=config. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Apr 25 18:54:14 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Apr 2011 14:54:14 -0400 Subject: [Freeipa-devel] [PATCH] 26 Delete the sudoers entry when disabling the Schema Compat plugin In-Reply-To: <9F431B03-AB08-49D1-BB8A-F254EB375989@citrixonline.com> References: <9F431B03-AB08-49D1-BB8A-F254EB375989@citrixonline.com> Message-ID: <4DB5C356.60202@redhat.com> JR Aquino wrote: > This patch addresses ticket: > https://fedorahosted.org/freeipa/ticket/1160 > > The disabling of the Schema Compat plugin is failing because the code was not removing all of the entries from the Schema Compatibility Container. > > This is a 1 line patch. ack, pushed to master and ipa-2-0 rob From ayoung at redhat.com Mon Apr 25 19:56:29 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 25 Apr 2011 15:56:29 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DB20123.6000707@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> <4DB06F7D.7060000@redhat.com> <4DB0EB49.9070605@redhat.com> <4DB1D81F.2050501@redhat.com> <4DB20123.6000707@redhat.com> Message-ID: <4DB5D1ED.9070906@redhat.com> On 04/22/2011 06:28 PM, Endi Sukma Dewata wrote: > On 4/22/2011 2:33 PM, Adam Young wrote: >>>> Again, have not yet run Selenium against this, so please do not push. >>>> There are conflicts between this version and some of edewata's patch. >>>> Additionally, there are some know issues with the rendering on the >>>> ACI pages which I'll iron out before this gets submitted for real. >>>> >>>> This version solves Issues 1,2,4,5 (sort of) ,8,9,and 10 from below. > >>> This version deals with #7. Unit tests and jsl is fixed. Rebased on >>> top of Endi's last action-button patch. >>> >>> Remaining issues have to do with css and styling. >>> >>> Still haven't run it through the Selenium tests. > >> OK, with this, the most egregious of the UI issues are fixed. While I'm >> sure we'll want to do more with it in the long term, I'm going to say >> that this is ready to go in. We'll fix the selenium tests as a follow on >> patch. > > Some issues: > > 3. Default tab is not activated. > Open Users, click one of the user, the default tab is activated. > Click Back to List, open the user again, the default tab is not > activated. Fixed > > 4. Inconsistent position of the action buttons. > - Open Users tab, observe the position of the Delete & Add buttons. > Then click one of the users, the Reset & Update buttons move to > the left. > - Open User Groups tab, observe the Add buttons, click one of the > groups, the Enroll button moves to the left. Fixed. Had to remove some of the style info in ipa.css, but I think it was only necessary for action-panels > > 5. Entity label should be used instead of entity name as the page title. > Open Sudo -> Sudo Command Groups -> group1. The page title is > "SUDOCMDGROUP:GROUP1". The problem with this is that unlike the > label, entity name will not be translated. Done. Long term, we need both a Singular and Plural form internationalized. The name field is the single value. > > 9. These facet.entity_header assignments are unnecessary: > - entity.js:307 > - details_tests.js:211 > - entity_tests.js:79 > Each facet has a reference to the entity, so the entity header can > be accessed using that.entity.header inside the facet or > facet.entity.header outside the facet. Leaving them for now. I am not sure that we are going to navigate by way of the entity to the header for always. Changing it broke the unit tests. I'll address this in a follow on patch that will simplify the facet API. > > 11. Navigation error. > Open User Groups tab, click one of the groups. Under Member Users, > click one of the users. It will show an error dialog box (it has > some typos too). > Still a problem. > > 12. In the search facet there is a big space between the buttons and > the results table. > Intentional. That is the space for the tabs. Easy to remove in the future, but want it in there for now. > 13. The 3rd level tabs appear only when the HBAC, Sudo, and RBAC tabs > are selected. This is causing the rest of the page to shift down. > As I mentioned before, here is my suggestion: > http://edewata.fedorapeople.org/images/mock1.png > http://edewata.fedorapeople.org/images/mock2.png Going to leave it like this for now. Don't think what you have in the mock ups is quite right: We'll run past UXD and adjust > > 14. According to the spec the buttons should be located below the 4th > level tabs (facet tabs). So it should be inside a 'facet-header' > instead of 'entity-header'. Spec needs work. It is easy enough to move things around if we decided we want to, but last conversation had the buttons above the tabs. > > 15. Most of navigation links are on the left part of the page, but > 'Back to Link' is on the right side. It's a bit inconvenient having > to go all the way to the right just to go back to the search page, > especially when reviewing many entries. Agree that it is a bit off, but it is the spec. We can revise in the future. > > 16. Some facet group headers in the 4th level tabs are unnecessary. > The Settings header above the Settings tab is redundant. > The Member header above DNS resource record tab is probably > inappropriate although that's how it's implemented internally. > There should be a way not to show the headers. They are there for spacing. Once UXD reviews, we can remove them. > > 17. Association facet doesn't set page title. > Open User Groups, the page title is "USER GROUPS". Click one of the > groups, it will open an association facet, the page title is > unchanged. Then click Settings tab, the title changes to > "GROUP:...". Click the association again, the title remains the > same. Fixed > > 18. Kerberos Ticket Policy and Configuration tabs don't have page > titles. > Fixed > 19. There should be a space after colon in the page title. > Open Users tab, then click admin. The title is "USER:ADMIN". > Fixed > 20. The facet groups needs to be customizable. Currently it's stored > in unordered set in entity's facet_group and the order is hard- > coded in get_facet() and facet_tabs(). It would be difficult > to workaround this limitations in custom facets. > > See how facets are stored in entity. The names are stored in an > ordered list (that.facets) and the instances are stored in a > dictionary (that.facets_by_name). Facet groups should use a similar > method to store the order and facet collections. > > In get_facet() the default facet should be the first facet in the > first group. In facet_tabs() the tab_section should be created > according to the order they are stored. Agreed, but we have this issue now, and so is not a regression. We'll fix in a follow on patch. > > 21. The IPA.entity_header should be created in entity.init() instead of > in entity.setup() line 305. The entity.setup() only needs to store > the container in the entity.header. This also eliminates manual > creations in the qunit tests. Long term, agreed, but init doesn't have the container, so under the current approach, we can't put it there. > > For issues #12-16 I think we need to get UXD's feedback. > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0221-4-action-panel-to-top-tabs.patch Type: text/x-patch Size: 67058 bytes Desc: not available URL: From ayoung at redhat.com Mon Apr 25 20:24:39 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 25 Apr 2011 16:24:39 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DB5D1ED.9070906@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> <4DB06F7D.7060000@redhat.com> <4DB0EB49.9070605@redhat.com> <4DB1D81F.2050501@redhat.com> <4DB20123.6000707@redhat.com> <4DB5D1ED.9070906@redhat.com> Message-ID: <4DB5D887.206@redhat.com> On 04/25/2011 03:56 PM, Adam Young wrote: > On 04/22/2011 06:28 PM, Endi Sukma Dewata wrote: >> On 4/22/2011 2:33 PM, Adam Young wrote: >>>>> Again, have not yet run Selenium against this, so please do not push. >>>>> There are conflicts between this version and some of edewata's patch. >>>>> Additionally, there are some know issues with the rendering on the >>>>> ACI pages which I'll iron out before this gets submitted for real. >>>>> >>>>> This version solves Issues 1,2,4,5 (sort of) ,8,9,and 10 from below. >> >>>> This version deals with #7. Unit tests and jsl is fixed. Rebased on >>>> top of Endi's last action-button patch. >>>> >>>> Remaining issues have to do with css and styling. >>>> >>>> Still haven't run it through the Selenium tests. >> >>> OK, with this, the most egregious of the UI issues are fixed. While I'm >>> sure we'll want to do more with it in the long term, I'm going to say >>> that this is ready to go in. We'll fix the selenium tests as a >>> follow on >>> patch. >> >> Some issues: >> >> 3. Default tab is not activated. >> Open Users, click one of the user, the default tab is activated. >> Click Back to List, open the user again, the default tab is not >> activated. > Fixed >> >> 4. Inconsistent position of the action buttons. >> - Open Users tab, observe the position of the Delete & Add buttons. >> Then click one of the users, the Reset & Update buttons move to >> the left. >> - Open User Groups tab, observe the Add buttons, click one of the >> groups, the Enroll button moves to the left. > Fixed. Had to remove some of the style info in ipa.css, but I think > it was only necessary for action-panels > >> >> 5. Entity label should be used instead of entity name as the page title. >> Open Sudo -> Sudo Command Groups -> group1. The page title is >> "SUDOCMDGROUP:GROUP1". The problem with this is that unlike the >> label, entity name will not be translated. > Done. Long term, we need both a Singular and Plural form > internationalized. The name field is the single value. > >> >> 9. These facet.entity_header assignments are unnecessary: >> - entity.js:307 >> - details_tests.js:211 >> - entity_tests.js:79 >> Each facet has a reference to the entity, so the entity header can >> be accessed using that.entity.header inside the facet or >> facet.entity.header outside the facet. > Leaving them for now. I am not sure that we are going to navigate by > way of the entity to the header for always. Changing it broke the > unit tests. I'll address this in a follow on patch that will simplify > the facet API. > >> >> 11. Navigation error. >> Open User Groups tab, click one of the groups. Under Member Users, >> click one of the users. It will show an error dialog box (it has >> some typos too). >> > Still a problem. OK, got that one fixed in this version as well (version 5) > >> >> 12. In the search facet there is a big space between the buttons and >> the results table. >> > Intentional. That is the space for the tabs. Easy to remove in the > future, but want it in there for now. > >> 13. The 3rd level tabs appear only when the HBAC, Sudo, and RBAC tabs >> are selected. This is causing the rest of the page to shift down. >> As I mentioned before, here is my suggestion: >> http://edewata.fedorapeople.org/images/mock1.png >> http://edewata.fedorapeople.org/images/mock2.png > Going to leave it like this for now. Don't think what you have in the > mock ups is quite right: We'll run past UXD and adjust > > >> >> 14. According to the spec the buttons should be located below the 4th >> level tabs (facet tabs). So it should be inside a 'facet-header' >> instead of 'entity-header'. > Spec needs work. It is easy enough to move things around if we > decided we want to, but last conversation had the buttons above the tabs. > > >> >> 15. Most of navigation links are on the left part of the page, but >> 'Back to Link' is on the right side. It's a bit inconvenient having >> to go all the way to the right just to go back to the search page, >> especially when reviewing many entries. > > Agree that it is a bit off, but it is the spec. We can revise in the > future. > >> >> 16. Some facet group headers in the 4th level tabs are unnecessary. >> The Settings header above the Settings tab is redundant. >> The Member header above DNS resource record tab is probably >> inappropriate although that's how it's implemented internally. >> There should be a way not to show the headers. > They are there for spacing. Once UXD reviews, we can remove them. > >> >> 17. Association facet doesn't set page title. >> Open User Groups, the page title is "USER GROUPS". Click one of the >> groups, it will open an association facet, the page title is >> unchanged. Then click Settings tab, the title changes to >> "GROUP:...". Click the association again, the title remains the >> same. > > Fixed >> >> 18. Kerberos Ticket Policy and Configuration tabs don't have page >> titles. >> > Fixed > >> 19. There should be a space after colon in the page title. >> Open Users tab, then click admin. The title is "USER:ADMIN". >> > Fixed > >> 20. The facet groups needs to be customizable. Currently it's stored >> in unordered set in entity's facet_group and the order is hard- >> coded in get_facet() and facet_tabs(). It would be difficult >> to workaround this limitations in custom facets. >> >> See how facets are stored in entity. The names are stored in an >> ordered list (that.facets) and the instances are stored in a >> dictionary (that.facets_by_name). Facet groups should use a similar >> method to store the order and facet collections. >> >> In get_facet() the default facet should be the first facet in the >> first group. In facet_tabs() the tab_section should be created >> according to the order they are stored. > > Agreed, but we have this issue now, and so is not a regression. We'll > fix in a follow on patch. >> >> 21. The IPA.entity_header should be created in entity.init() instead of >> in entity.setup() line 305. The entity.setup() only needs to store >> the container in the entity.header. This also eliminates manual >> creations in the qunit tests. > > Long term, agreed, but init doesn't have the container, so under the > current approach, we can't put it there. > >> >> For issues #12-16 I think we need to get UXD's feedback. >> > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0221-5-action-panel-to-top-tabs.patch Type: text/x-patch Size: 68006 bytes Desc: not available URL: From dlackey at redhat.com Mon Apr 25 23:16:04 2011 From: dlackey at redhat.com (Deon Lackey) Date: Mon, 25 Apr 2011 19:16:04 -0400 (EDT) Subject: [Freeipa-devel] freeIPA wiki account Message-ID: <949484104.254569.1303773364821.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Hi! Could someone set up a FreeIPA wiki account for me? I thought my Fedora creds would work, but I was wrong. Thanks! Deon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Mon Apr 25 23:34:54 2011 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 25 Apr 2011 19:34:54 -0400 Subject: [Freeipa-devel] freeIPA wiki account In-Reply-To: <949484104.254569.1303773364821.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <949484104.254569.1303773364821.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1303774494.23464.29.camel@willson.li.ssimo.org> On Mon, 2011-04-25 at 19:16 -0400, Deon Lackey wrote: > Hi! > > > > Could someone set up a FreeIPA wiki account for me? I thought my > Fedora creds would work, but I was wrong. Done. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Apr 26 08:41:05 2011 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Apr 2011 10:41:05 +0200 Subject: [Freeipa-devel] [PATCH] 049 IPA replica is not started after the reboot Message-ID: <1303807265.9340.3.camel@dhcp-25-52.brq.redhat.com> https://fedorahosted.org/freeipa/ticket/1191 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-049-ipa-replica-is-not-started-after-the-reboot.patch Type: text/x-patch Size: 905 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 26 11:24:40 2011 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Apr 2011 13:24:40 +0200 Subject: [Freeipa-devel] [PATCH] 778 validate zonemgr In-Reply-To: <4DB1F144.5020602@redhat.com> References: <4DB1F144.5020602@redhat.com> Message-ID: <1303817080.9340.10.camel@dhcp-25-52.brq.redhat.com> On Fri, 2011-04-22 at 17:21 -0400, Rob Crittenden wrote: > Ensure that the zonemgr passed to the installer conforms to IA5String. > > ticket 1164 > > rob ACK. Pushed to master, ipa-2-0. Martin From jcholast at redhat.com Tue Apr 26 11:42:46 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 26 Apr 2011 13:42:46 +0200 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build Message-ID: <4DB6AFB6.1010503@redhat.com> Automatically run the lint script during make rpms|client-rpms|srpms. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-14-lint-build.patch Type: text/x-patch Size: 1550 bytes Desc: not available URL: From edewata at redhat.com Tue Apr 26 13:25:39 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 26 Apr 2011 08:25:39 -0500 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DB5D887.206@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> <4DB06F7D.7060000@redhat.com> <4DB0EB49.9070605@redhat.com> <4DB1D81F.2050501@redhat.com> <4DB20123.6000707@redhat.com> <4DB5D1ED.9070906@redhat.com> <4DB5D887.206@redhat.com> Message-ID: <4DB6C7D3.3030107@redhat.com> There are still some issues. Some of them have been discussed over IRC: On 4/25/2011 3:24 PM, Adam Young wrote: >>> 11. Navigation error. >>> Open User Groups tab, click one of the groups. Under Member Users, >>> click one of the users. It will show an error dialog box (it has >>> some typos too). >> Still a problem. > OK, got that one fixed in this version as well (version 5) Still a problem. Open HBAC -> HBAC Rule, click one of the rules, an error dialog box will appear. >>> 18. Kerberos Ticket Policy and Configuration tabs don't have page >>> titles. >> Fixed These titles end with a colon. >>> 20. The facet groups needs to be customizable. Currently it's stored >>> in unordered set in entity's facet_group and the order is hard- >>> coded in get_facet() and facet_tabs(). It would be difficult >>> to workaround this limitations in custom facets. >>> >>> See how facets are stored in entity. The names are stored in an >>> ordered list (that.facets) and the instances are stored in a >>> dictionary (that.facets_by_name). Facet groups should use a similar >>> method to store the order and facet collections. >>> >>> In get_facet() the default facet should be the first facet in the >>> first group. In facet_tabs() the tab_section should be created >>> according to the order they are stored. >> >> Agreed, but we have this issue now, and so is not a regression. We'll >> fix in a follow on patch. This is actually a regression. Because of this the Host's and Service's Managed By is missing. We also want to be able to replace the facet group names in ACI because they don't quite make sense (e.g. Role being a member of Privilege) although that's how it's implemented internally. >>> 21. The IPA.entity_header should be created in entity.init() instead of >>> in entity.setup() line 305. The entity.setup() only needs to store >>> the container in the entity.header. This also eliminates manual >>> creations in the qunit tests. >> >> Long term, agreed, but init doesn't have the container, so under the >> current approach, we can't put it there. It can be done with a simple change. The following code in the IPA.entity_header can be moved into a create() method which takes a container parameter: that.header = $("
"). append(title(entity)). append(buttons()). append(pkey()). append(search_bar()). append(entity_container()); container.append(that.header); The IPA.entity_header should be created together with the entity. It doesn't need a container. Then the create() method can be called by IPA.entity_setup(). This way a custom entity can customize the entity_header. It's also better to append the DOM object as soon as it's created instead of appending a complex object into the container. It helps troubleshooting. 22. When hovering above the facet tabs, the mouse changes into a text cursor instead of pointer. 23. Facet tab can change although the page is dirty. Open Users tab, click one of the users, this will open the Settings facet. Edit a field, then click another facet, the Dirty dialog box will appear. Close the dialog box, the tab doesn't change back to Settings. -- Endi S. Dewata From mkosek at redhat.com Tue Apr 26 13:28:06 2011 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Apr 2011 15:28:06 +0200 Subject: [Freeipa-devel] [PATCH] 050 KDC autodiscovery may fail when domain is not realm Message-ID: <1303824486.9340.23.camel@dhcp-25-52.brq.redhat.com> How to test: 1) Install IPA server with DNS support with --realm=TESTRELM (different from DOMAIN) 2) Configure client machine to use this DNS server 3) Run "ipa-client-install" on the client machine - Unpatched installer fails because it cannot find KDC for DNS domain "testrelm" - Patched installer turns off KDC DNS autodiscovery and installation succeeds If DNS zone "testrelm" with appropriate SRV records is configured, installer allows KDC DNS autodiscovery. Hint for new zone configuration: # ipa dnszone-add TESTRELM --name-server=vm-057.idm.lab.bos.redhat.com. --admin-email=root at testrelm # ipa dnsrecord-add testrelm _kerberos --txt-rec=TESTRELM # ipa dnsrecord-add testrelm _kerberos-master._tcp --srv-rec="0 100 88 vm-057" # ipa dnsrecord-add testrelm _kerberos-master._udp --srv-rec="0 100 88 vm-057" # ipa dnsrecord-add testrelm _kerberos._udp --srv-rec="0 100 88 vm-057" # ipa dnsrecord-add testrelm _kerberos._tcp --srv-rec="0 100 88 vm-057" # ipa dnsrecord-add idm.lab.bos.redhat.com gordo --a-rec=10.16.78.1 # ipa dnsrecord-add testrelm vm-057 --cname-rec="vm-057.idm.lab.bos.redhat.com." # service named reload Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-050-kdc-autodiscovery-may-fail-when-domain-is-not-realm.patch Type: text/x-patch Size: 6057 bytes Desc: not available URL: From ayoung at redhat.com Tue Apr 26 16:15:29 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 26 Apr 2011 12:15:29 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DB6C7D3.3030107@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> <4DB06F7D.7060000@redhat.com> <4DB0EB49.9070605@redhat.com> <4DB1D81F.2050501@redhat.com> <4DB20123.6000707@redhat.com> <4DB5D1ED.9070906@redhat.com> <4DB5D887.206@redhat.com> <4DB6C7D3.3030107@redhat.com> Message-ID: <4DB6EFA1.3010900@redhat.com> On 04/26/2011 09:25 AM, Endi Sukma Dewata wrote: > There are still some issues. Some of them have been discussed over IRC: > > On 4/25/2011 3:24 PM, Adam Young wrote: >>>> 11. Navigation error. >>>> Open User Groups tab, click one of the groups. Under Member Users, >>>> click one of the users. It will show an error dialog box (it has >>>> some typos too). >>> Still a problem. >> OK, got that one fixed in this version as well (version 5) > > Still a problem. Open HBAC -> HBAC Rule, click one of the rules, an > error dialog box will appear. > >>>> 18. Kerberos Ticket Policy and Configuration tabs don't have page >>>> titles. >>> Fixed > > These titles end with a colon. > >>>> 20. The facet groups needs to be customizable. Currently it's stored >>>> in unordered set in entity's facet_group and the order is hard- >>>> coded in get_facet() and facet_tabs(). It would be difficult >>>> to workaround this limitations in custom facets. >>>> >>>> See how facets are stored in entity. The names are stored in an >>>> ordered list (that.facets) and the instances are stored in a >>>> dictionary (that.facets_by_name). Facet groups should use a similar >>>> method to store the order and facet collections. >>>> >>>> In get_facet() the default facet should be the first facet in the >>>> first group. In facet_tabs() the tab_section should be created >>>> according to the order they are stored. >>> >>> Agreed, but we have this issue now, and so is not a regression. We'll >>> fix in a follow on patch. > > This is actually a regression. Because of this the Host's and > Service's Managed By is missing. We also want to be able to replace > the facet group names in ACI because they don't quite make sense (e.g. > Role being a member of Privilege) although that's how it's implemented > internally. > >>>> 21. The IPA.entity_header should be created in entity.init() >>>> instead of >>>> in entity.setup() line 305. The entity.setup() only needs to store >>>> the container in the entity.header. This also eliminates manual >>>> creations in the qunit tests. >>> >>> Long term, agreed, but init doesn't have the container, so under the >>> current approach, we can't put it there. > > It can be done with a simple change. The following code in the > IPA.entity_header can be moved into a create() method which takes a > container parameter: > > that.header = $("
"). > append(title(entity)). > append(buttons()). > append(pkey()). > append(search_bar()). > append(entity_container()); > container.append(that.header); > > The IPA.entity_header should be created together with the entity. It > doesn't need a container. Then the create() method can be called by > IPA.entity_setup(). This way a custom entity can customize the > entity_header. > > It's also better to append the DOM object as soon as it's created > instead of appending a complex object into the container. It helps > troubleshooting. > > 22. When hovering above the facet tabs, the mouse changes into a text > cursor instead of pointer. > > 23. Facet tab can change although the page is dirty. > Open Users tab, click one of the users, this will open the Settings > facet. Edit a field, then click another facet, the Dirty dialog box > will appear. Close the dialog box, the tab doesn't change back to > Settings. > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0221-6-action-panel-to-top-tabs.patch Type: text/x-patch Size: 68232 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 26 16:14:19 2011 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Apr 2011 18:14:19 +0200 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <4DB6AFB6.1010503@redhat.com> References: <4DB6AFB6.1010503@redhat.com> Message-ID: <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: > Automatically run the lint script during make rpms|client-rpms|srpms. > NACK until ticket 1184 is resolved and pushed. Currently, pylint check fails when optional python packages (like python-rhsm) are not installed on the machine. We should be able to build IPA without those packages installed. Martin From ayoung at redhat.com Tue Apr 26 16:18:17 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 26 Apr 2011 12:18:17 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0222-Removed-entities-that-are-for-some-reason-invalid In-Reply-To: <4DB1CA4C.7030103@redhat.com> References: <4DB1CA4C.7030103@redhat.com> Message-ID: <4DB6F049.4030503@redhat.com> On 04/22/2011 02:34 PM, Adam Young wrote: > This might be my favorite patch name yet. > > This patch depends on admiyo-0221-2 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Rebased on top of 221-6 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0222-4-Removed-entities-that-are-for-some-reason-invalid.patch Type: text/x-patch Size: 4153 bytes Desc: not available URL: From ayoung at redhat.com Tue Apr 26 17:42:59 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 26 Apr 2011 13:42:59 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DB6EFA1.3010900@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> <4DB06F7D.7060000@redhat.com> <4DB0EB49.9070605@redhat.com> <4DB1D81F.2050501@redhat.com> <4DB20123.6000707@redhat.com> <4DB5D1ED.9070906@redhat.com> <4DB5D887.206@redhat.com> <4DB6C7D3.3030107@redhat.com> <4DB6EFA1.3010900@redhat.com> Message-ID: <4DB70423.1070407@redhat.com> On 04/26/2011 12:15 PM, Adam Young wrote: > On 04/26/2011 09:25 AM, Endi Sukma Dewata wrote: >> There are still some issues. Some of them have been discussed over IRC: >> >> On 4/25/2011 3:24 PM, Adam Young wrote: >>>>> 11. Navigation error. >>>>> Open User Groups tab, click one of the groups. Under Member Users, >>>>> click one of the users. It will show an error dialog box (it has >>>>> some typos too). >>>> Still a problem. >>> OK, got that one fixed in this version as well (version 5) >> >> Still a problem. Open HBAC -> HBAC Rule, click one of the rules, an >> error dialog box will appear. >> >>>>> 18. Kerberos Ticket Policy and Configuration tabs don't have page >>>>> titles. >>>> Fixed >> >> These titles end with a colon. >> >>>>> 20. The facet groups needs to be customizable. Currently it's stored >>>>> in unordered set in entity's facet_group and the order is hard- >>>>> coded in get_facet() and facet_tabs(). It would be difficult >>>>> to workaround this limitations in custom facets. >>>>> >>>>> See how facets are stored in entity. The names are stored in an >>>>> ordered list (that.facets) and the instances are stored in a >>>>> dictionary (that.facets_by_name). Facet groups should use a similar >>>>> method to store the order and facet collections. >>>>> >>>>> In get_facet() the default facet should be the first facet in the >>>>> first group. In facet_tabs() the tab_section should be created >>>>> according to the order they are stored. >>>> >>>> Agreed, but we have this issue now, and so is not a regression. We'll >>>> fix in a follow on patch. >> >> This is actually a regression. Because of this the Host's and >> Service's Managed By is missing. We also want to be able to replace >> the facet group names in ACI because they don't quite make sense >> (e.g. Role being a member of Privilege) although that's how it's >> implemented internally. >> >>>>> 21. The IPA.entity_header should be created in entity.init() >>>>> instead of >>>>> in entity.setup() line 305. The entity.setup() only needs to store >>>>> the container in the entity.header. This also eliminates manual >>>>> creations in the qunit tests. >>>> >>>> Long term, agreed, but init doesn't have the container, so under the >>>> current approach, we can't put it there. >> >> It can be done with a simple change. The following code in the >> IPA.entity_header can be moved into a create() method which takes a >> container parameter: >> >> that.header = $("
"). >> append(title(entity)). >> append(buttons()). >> append(pkey()). >> append(search_bar()). >> append(entity_container()); >> container.append(that.header); >> >> The IPA.entity_header should be created together with the entity. It >> doesn't need a container. Then the create() method can be called by >> IPA.entity_setup(). This way a custom entity can customize the >> entity_header. >> >> It's also better to append the DOM object as soon as it's created >> instead of appending a complex object into the container. It helps >> troubleshooting. >> >> 22. When hovering above the facet tabs, the mouse changes into a text >> cursor instead of pointer. >> >> 23. Facet tab can change although the page is dirty. >> Open Users tab, click one of the users, this will open the Settings >> facet. Edit a field, then click another facet, the Dirty dialog box >> will appear. Close the dialog box, the tab doesn't change back to >> Settings. >> > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Merged in patch 222, since this patch does not work with out it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0221-7-action-panel-to-top-tabs.patch Type: text/x-patch Size: 69288 bytes Desc: not available URL: From ayoung at redhat.com Tue Apr 26 17:43:24 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 26 Apr 2011 13:43:24 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0222-Removed-entities-that-are-for-some-reason-invalid In-Reply-To: <4DB6F049.4030503@redhat.com> References: <4DB1CA4C.7030103@redhat.com> <4DB6F049.4030503@redhat.com> Message-ID: <4DB7043C.60008@redhat.com> On 04/26/2011 12:18 PM, Adam Young wrote: > On 04/22/2011 02:34 PM, Adam Young wrote: >> This might be my favorite patch name yet. >> >> This patch depends on admiyo-0221-2 >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Rebased on top of 221-6 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Withdrawn. This patch has been merged into admiyo-221-7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Tue Apr 26 19:12:53 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 26 Apr 2011 14:12:53 -0500 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DB70423.1070407@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> <4DB06F7D.7060000@redhat.com> <4DB0EB49.9070605@redhat.com> <4DB1D81F.2050501@redhat.com> <4DB20123.6000707@redhat.com> <4DB5D1ED.9070906@redhat.com> <4DB5D887.206@redhat.com> <4DB6C7D3.3030107@redhat.com> <4DB6EFA1.3010900@redhat.com> <4DB70423.1070407@redhat.com> Message-ID: <4DB71935.6070009@redhat.com> On 4/26/2011 12:42 PM, Adam Young wrote: >>>>>> 20. The facet groups needs to be customizable. Currently it's stored >>>>>> in unordered set in entity's facet_group and the order is hard- >>>>>> coded in get_facet() and facet_tabs(). It would be difficult >>>>>> to workaround this limitations in custom facets. >>>>>> >>>>>> See how facets are stored in entity. The names are stored in an >>>>>> ordered list (that.facets) and the instances are stored in a >>>>>> dictionary (that.facets_by_name). Facet groups should use a similar >>>>>> method to store the order and facet collections. >>>>>> >>>>>> In get_facet() the default facet should be the first facet in the >>>>>> first group. In facet_tabs() the tab_section should be created >>>>>> according to the order they are stored. >>>>> >>>>> Agreed, but we have this issue now, and so is not a regression. We'll >>>>> fix in a follow on patch. >>> >>> This is actually a regression. Because of this the Host's and >>> Service's Managed By is missing. We also want to be able to replace >>> the facet group names in ACI because they don't quite make sense >>> (e.g. Role being a member of Privilege) although that's how it's >>> implemented internally. As discussed over IRC, patch 221-7 still includes hard-coded facet group names. It may not be an issue for IPA now, but it will be for other projects trying to use the framework. >>>>>> 21. The IPA.entity_header should be created in entity.init() >>>>>> instead of >>>>>> in entity.setup() line 305. The entity.setup() only needs to store >>>>>> the container in the entity.header. This also eliminates manual >>>>>> creations in the qunit tests. >>>>> >>>>> Long term, agreed, but init doesn't have the container, so under the >>>>> current approach, we can't put it there. >>> >>> It can be done with a simple change. The following code in the >>> IPA.entity_header can be moved into a create() method which takes a >>> container parameter: >>> >>> that.header = $("
"). >>> append(title(entity)). >>> append(buttons()). >>> append(pkey()). >>> append(search_bar()). >>> append(entity_container()); >>> container.append(that.header); >>> >>> The IPA.entity_header should be created together with the entity. It >>> doesn't need a container. Then the create() method can be called by >>> IPA.entity_setup(). This way a custom entity can customize the >>> entity_header. >>> >>> It's also better to append the DOM object as soon as it's created >>> instead of appending a complex object into the container. It helps >>> troubleshooting. This is not addressed, but it's not a big issue. >>> 22. When hovering above the facet tabs, the mouse changes into a text >>> cursor instead of pointer. Not addressed, but not a big issue. >>> 23. Facet tab can change although the page is dirty. >>> Open Users tab, click one of the users, this will open the Settings >>> facet. Edit a field, then click another facet, the Dirty dialog box >>> will appear. Close the dialog box, the tab doesn't change back to >>> Settings. Not addressed, but not a big issue. > Merged in patch 222, since this patch does not work with out it. 24. Typo in entity.js and search.js: back_to-seach 25. Typo in ipa.css: .entity-continer 26. Incorrect jQuery selector in search.js: entity-tabs.li 27. There's a jslint warning. Feel free to push if the remaining issues can be fixed before pushing or considered minor. -- Endi S. Dewata From ssorce at redhat.com Tue Apr 26 20:21:09 2011 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 26 Apr 2011 16:21:09 -0400 Subject: [Freeipa-devel] [PATCH] fixes #1193 init script related Message-ID: <1303849269.23464.82.camel@willson.li.ssimo.org> With this patch we stop clearing the environment variables when running binaries allowing for env variables to be passed down by default. This fixes also the init script against Fedora 15 and systemd Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ipautil-Preserve-environment-unless-explicitly-overr.patch Type: text/x-patch Size: 1077 bytes Desc: not available URL: From ayoung at redhat.com Tue Apr 26 20:50:03 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 26 Apr 2011 16:50:03 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0221-action-panel-to-top-tabs In-Reply-To: <4DB71935.6070009@redhat.com> References: <4DADEB64.3090103@redhat.com> <4DADFF44.9000709@redhat.com> <4DAE2FF9.3030907@redhat.com> <4DB06F7D.7060000@redhat.com> <4DB0EB49.9070605@redhat.com> <4DB1D81F.2050501@redhat.com> <4DB20123.6000707@redhat.com> <4DB5D1ED.9070906@redhat.com> <4DB5D887.206@redhat.com> <4DB6C7D3.3030107@redhat.com> <4DB6EFA1.3010900@redhat.com> <4DB70423.1070407@redhat.com> <4DB71935.6070009@redhat.com> Message-ID: <4DB72FFB.80806@redhat.com> On 04/26/2011 03:12 PM, Endi Sukma Dewata wrote: > On 4/26/2011 12:42 PM, Adam Young wrote: >>>>>>> 20. The facet groups needs to be customizable. Currently it's >>>>>>> stored >>>>>>> in unordered set in entity's facet_group and the order is hard- >>>>>>> coded in get_facet() and facet_tabs(). It would be difficult >>>>>>> to workaround this limitations in custom facets. >>>>>>> >>>>>>> See how facets are stored in entity. The names are stored in an >>>>>>> ordered list (that.facets) and the instances are stored in a >>>>>>> dictionary (that.facets_by_name). Facet groups should use a similar >>>>>>> method to store the order and facet collections. >>>>>>> >>>>>>> In get_facet() the default facet should be the first facet in the >>>>>>> first group. In facet_tabs() the tab_section should be created >>>>>>> according to the order they are stored. >>>>>> >>>>>> Agreed, but we have this issue now, and so is not a regression. >>>>>> We'll >>>>>> fix in a follow on patch. >>>> >>>> This is actually a regression. Because of this the Host's and >>>> Service's Managed By is missing. We also want to be able to replace >>>> the facet group names in ACI because they don't quite make sense >>>> (e.g. Role being a member of Privilege) although that's how it's >>>> implemented internally. > > As discussed over IRC, patch 221-7 still includes hard-coded facet > group names. It may not be an issue for IPA now, but it will be for > other projects trying to use the framework. > >>>>>>> 21. The IPA.entity_header should be created in entity.init() >>>>>>> instead of >>>>>>> in entity.setup() line 305. The entity.setup() only needs to store >>>>>>> the container in the entity.header. This also eliminates manual >>>>>>> creations in the qunit tests. >>>>>> >>>>>> Long term, agreed, but init doesn't have the container, so under the >>>>>> current approach, we can't put it there. >>>> >>>> It can be done with a simple change. The following code in the >>>> IPA.entity_header can be moved into a create() method which takes a >>>> container parameter: >>>> >>>> that.header = $("
"). >>>> append(title(entity)). >>>> append(buttons()). >>>> append(pkey()). >>>> append(search_bar()). >>>> append(entity_container()); >>>> container.append(that.header); >>>> >>>> The IPA.entity_header should be created together with the entity. It >>>> doesn't need a container. Then the create() method can be called by >>>> IPA.entity_setup(). This way a custom entity can customize the >>>> entity_header. >>>> >>>> It's also better to append the DOM object as soon as it's created >>>> instead of appending a complex object into the container. It helps >>>> troubleshooting. > > This is not addressed, but it's not a big issue. > >>>> 22. When hovering above the facet tabs, the mouse changes into a text >>>> cursor instead of pointer. > > Not addressed, but not a big issue. > >>>> 23. Facet tab can change although the page is dirty. >>>> Open Users tab, click one of the users, this will open the Settings >>>> facet. Edit a field, then click another facet, the Dirty dialog box >>>> will appear. Close the dialog box, the tab doesn't change back to >>>> Settings. > > Not addressed, but not a big issue. > >> Merged in patch 222, since this patch does not work with out it. > > 24. Typo in entity.js and search.js: back_to-seach This type was done consitently, so it worked. But It is easy to fix.l > 25. Typo in ipa.css: .entity-continer Not being used. Removed > 26. Incorrect jQuery selector in search.js: entity-tabs.li Not being used. removed. These last two were replaced by a later fix in patch 221 that sets the selected tab more consistently. > 27. There's a jslint warning. > > Feel free to push if the remaining issues can be fixed before pushing > or considered minor. > Fixed Pushed to master From rcritten at redhat.com Tue Apr 26 20:52:44 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Apr 2011 16:52:44 -0400 Subject: [Freeipa-devel] [PATCH] 779 Require an imported certificate's issuer to match our issuer Message-ID: <4DB7309C.4010307@redhat.com> The goal is to not import foreign certificates. This caused a bunch of tests to fail because we had a hardcoded server certificate. Instead a developer will need to run make-testcert to create a server certificate generated by the local CA to test against. ticket 1134 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-779-cert.patch Type: application/mbox Size: 19001 bytes Desc: not available URL: From rcritten at redhat.com Tue Apr 26 21:08:51 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Apr 2011 17:08:51 -0400 Subject: [Freeipa-devel] [PATCH] fixes #1193 init script related In-Reply-To: <1303849269.23464.82.camel@willson.li.ssimo.org> References: <1303849269.23464.82.camel@willson.li.ssimo.org> Message-ID: <4DB73463.6090505@redhat.com> Simo Sorce wrote: > With this patch we stop clearing the environment variables when running > binaries allowing for env variables to be passed down by default. > > This fixes also the init script against Fedora 15 and systemd > > Simo. > I think it would be better to import copy and use: if env is None: env = copy.deepcopy(os.environ) env["PATH"] = "/bin:/sbin:..." rob From edewata at redhat.com Tue Apr 26 21:48:08 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 26 Apr 2011 16:48:08 -0500 Subject: [Freeipa-devel] [PATCH] 143 Entitlement quantity validation. Message-ID: <4DB73D98.4040307@redhat.com> The widget base class has been modified to validate integer value if the type is specified in the metadata. This is used to validate entitlement quantity. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0143-Entitlement-quantity-validation.patch Type: text/x-patch Size: 10686 bytes Desc: not available URL: From ssorce at redhat.com Tue Apr 26 22:03:51 2011 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 26 Apr 2011 18:03:51 -0400 Subject: [Freeipa-devel] [PATCH] fixes #1193 init script related In-Reply-To: <4DB73463.6090505@redhat.com> References: <1303849269.23464.82.camel@willson.li.ssimo.org> <4DB73463.6090505@redhat.com> Message-ID: <1303855431.23464.107.camel@willson.li.ssimo.org> On Tue, 2011-04-26 at 17:08 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > With this patch we stop clearing the environment variables when running > > binaries allowing for env variables to be passed down by default. > > > > This fixes also the init script against Fedora 15 and systemd > > > > Simo. > > > > I think it would be better to import copy and use: > > if env is None: > env = copy.deepcopy(os.environ) > env["PATH"] = "/bin:/sbin:..." > > rob Updated patch attached. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ipautil-Preserve-environment-unless-explicitly-overr.patch Type: text/x-patch Size: 1187 bytes Desc: not available URL: From ayoung at redhat.com Wed Apr 27 00:33:58 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 26 Apr 2011 20:33:58 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0225-remove-jquery-cookie-library Message-ID: <4DB76476.3070306@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0225-remove-jquery-cookie-library.patch Type: text/x-patch Size: 6097 bytes Desc: not available URL: From ayoung at redhat.com Wed Apr 27 01:23:01 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 26 Apr 2011 21:23:01 -0400 Subject: [Freeipa-devel] [PATCH] 143 Entitlement quantity validation. In-Reply-To: <4DB73D98.4040307@redhat.com> References: <4DB73D98.4040307@redhat.com> Message-ID: <4DB76FF5.3020602@redhat.com> On 04/26/2011 05:48 PM, Endi Sukma Dewata wrote: > The widget base class has been modified to validate integer value > if the type is specified in the metadata. This is used to validate > entitlement quantity. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Logic looks good. I'd like to make the validator an external object, and have the builder select the validator based on the metadata. The IPA data types beyond String and int are: bool, float, bytes, and enum. We should at least plan for them, even if we are not implementing them now: something like var validators = { int: function (blah){...} string: function (regex){....} } widget.spec. validator = validators[type]; -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Apr 27 10:40:15 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 Apr 2011 12:40:15 +0200 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB7F28F.8040505@redhat.com> On 26.4.2011 18:14, Martin Kosek wrote: > On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: >> Automatically run the lint script during make rpms|client-rpms|srpms. >> > > NACK until ticket 1184 is resolved and pushed. Currently, pylint check > fails when optional python packages (like python-rhsm) are not installed > on the machine. We should be able to build IPA without those packages > installed. I think printing a note asking the developer to kindly install the missing packages would be sufficient. AFAIK there are currently only 2 optional packages: python-rhsm and python-krbV. python-krbV is optional only for the client part of IPA, so you most likely have it already installed and installing python-rhsm is not really much of a chore. That way all of the code would always be checked and the lint script would be free of the unnecessary complexity of handling missing packages. > > Martin -- Jan Cholasta From mkosek at redhat.com Wed Apr 27 10:43:09 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 Apr 2011 12:43:09 +0200 Subject: [Freeipa-devel] [PATCH] 051 Improve Directory Service open port checker Message-ID: <1303900989.15737.0.camel@dhcp-25-52.brq.redhat.com> Wait for DS ports to open after _every_ DS service restart. Several restarts were missed by the current open port checker implementation. https://fedorahosted.org/freeipa/ticket/1182 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-051-improve-directory-service-open-port-checker.patch Type: text/x-patch Size: 3695 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 27 11:17:02 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 Apr 2011 13:17:02 +0200 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <4DB7F28F.8040505@redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> <4DB7F28F.8040505@redhat.com> Message-ID: <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-27 at 12:40 +0200, Jan Cholasta wrote: > On 26.4.2011 18:14, Martin Kosek wrote: > > On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: > >> Automatically run the lint script during make rpms|client-rpms|srpms. > >> > > > > NACK until ticket 1184 is resolved and pushed. Currently, pylint check > > fails when optional python packages (like python-rhsm) are not installed > > on the machine. We should be able to build IPA without those packages > > installed. > > I think printing a note asking the developer to kindly install the > missing packages would be sufficient. AFAIK there are currently only 2 > optional packages: python-rhsm and python-krbV. python-krbV is optional > only for the client part of IPA, so you most likely have it already > installed and installing python-rhsm is not really much of a chore. That > way all of the code would always be checked and the lint script would be > free of the unnecessary complexity of handling missing packages. I don't think this is a right approach. When the package is optional (currently it may be python-rhsm and python-krbV only, but there may be others in the future) I shouldn't be obliged to install them in order to build IPA. When somebody develops something related with the optional package he has them installed and the lint will check the relevant code too. It is not that big deal, I just think it would be an annoyance for developers. But maybe there is a different opinion. Martin From mkosek at redhat.com Wed Apr 27 11:29:41 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 Apr 2011 13:29:41 +0200 Subject: [Freeipa-devel] [PATCH] 052 Log temporary files in ipa-client-install Message-ID: <1303903781.15737.13.camel@dhcp-25-52.brq.redhat.com> This patch will help investigating issues like in ticket 1100 resolved by my patch 50. ------ This patch adds logging of temporary files (Kerberos configuration, nsupdate commands) that may be very useful for debugging purposes. https://fedorahosted.org/freeipa/ticket/1093 https://fedorahosted.org/freeipa/ticket/1094 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-052-log-temporary-files-in-ipa-client-install.patch Type: text/x-patch Size: 2023 bytes Desc: not available URL: From jcholast at redhat.com Wed Apr 27 12:13:00 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 27 Apr 2011 14:13:00 +0200 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> <4DB7F28F.8040505@redhat.com> <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB8084C.7010902@redhat.com> On 27.4.2011 13:17, Martin Kosek wrote: > On Wed, 2011-04-27 at 12:40 +0200, Jan Cholasta wrote: >> On 26.4.2011 18:14, Martin Kosek wrote: >>> On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: >>>> Automatically run the lint script during make rpms|client-rpms|srpms. >>>> >>> >>> NACK until ticket 1184 is resolved and pushed. Currently, pylint check >>> fails when optional python packages (like python-rhsm) are not installed >>> on the machine. We should be able to build IPA without those packages >>> installed. >> >> I think printing a note asking the developer to kindly install the >> missing packages would be sufficient. AFAIK there are currently only 2 >> optional packages: python-rhsm and python-krbV. python-krbV is optional >> only for the client part of IPA, so you most likely have it already >> installed and installing python-rhsm is not really much of a chore. That >> way all of the code would always be checked and the lint script would be >> free of the unnecessary complexity of handling missing packages. > > I don't think this is a right approach. When the package is optional > (currently it may be python-rhsm and python-krbV only, but there may be > others in the future) I shouldn't be obliged to install them in order to > build IPA. You shouldn't be obliged to install them as a user. As a developer, you should be ready for all kinds of crazy stuff IMHO. > When somebody develops something related with the optional > package he has them installed and the lint will check the relevant code > too. All of the code goes to the package, so it all should be checked during the build. Imagine situation like this: You change something in module A, accidentally breaking functionality that module B depends on. Module A is checked and no error is found (because it's the kind of issue that exhibits itself only in certain conditions). Module B isn't checked, because it also depends on a not-installed optional package. If it was checked, it would report an error that would lead you to the error in module A. But everything looks fine, so the build succeeds, even when the error is there. The situation might be improbable, but IMO the code should be checked in the same ecosystem every time anyway, because weird stuff could happen if it wasn't. > > It is not that big deal, I just think it would be an annoyance for > developers. But maybe there is a different opinion. I know we developers are lazy folk, but this is a matter of writing one simple command, just one time. > > Martin > -- Jan Cholasta From dpal at redhat.com Wed Apr 27 13:34:06 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 27 Apr 2011 09:34:06 -0400 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <4DB8084C.7010902@redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> <4DB7F28F.8040505@redhat.com> <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> <4DB8084C.7010902@redhat.com> Message-ID: <4DB81B4E.1030803@redhat.com> On 04/27/2011 08:13 AM, Jan Cholasta wrote: > On 27.4.2011 13:17, Martin Kosek wrote: >> On Wed, 2011-04-27 at 12:40 +0200, Jan Cholasta wrote: >>> On 26.4.2011 18:14, Martin Kosek wrote: >>>> On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: >>>>> Automatically run the lint script during make rpms|client-rpms|srpms. >>>>> >>>> >>>> NACK until ticket 1184 is resolved and pushed. Currently, pylint check >>>> fails when optional python packages (like python-rhsm) are not >>>> installed >>>> on the machine. We should be able to build IPA without those packages >>>> installed. >>> >>> I think printing a note asking the developer to kindly install the >>> missing packages would be sufficient. AFAIK there are currently only 2 >>> optional packages: python-rhsm and python-krbV. python-krbV is optional >>> only for the client part of IPA, so you most likely have it already >>> installed and installing python-rhsm is not really much of a chore. >>> That >>> way all of the code would always be checked and the lint script >>> would be >>> free of the unnecessary complexity of handling missing packages. >> >> I don't think this is a right approach. When the package is optional >> (currently it may be python-rhsm and python-krbV only, but there may be >> others in the future) I shouldn't be obliged to install them in order to >> build IPA. > > You shouldn't be obliged to install them as a user. As a developer, > you should be ready for all kinds of crazy stuff IMHO. > >> When somebody develops something related with the optional >> package he has them installed and the lint will check the relevant code >> too. > > All of the code goes to the package, so it all should be checked > during the build. > > Imagine situation like this: You change something in module A, > accidentally breaking functionality that module B depends on. Module A > is checked and no error is found (because it's the kind of issue that > exhibits itself only in certain conditions). Module B isn't checked, > because it also depends on a not-installed optional package. If it was > checked, it would report an error that would lead you to the error in > module A. But everything looks fine, so the build succeeds, even when > the error is there. > > The situation might be improbable, but IMO the code should be checked > in the same ecosystem every time anyway, because weird stuff could > happen if it wasn't. > >> >> It is not that big deal, I just think it would be an annoyance for >> developers. But maybe there is a different opinion. > > I know we developers are lazy folk, but this is a matter of writing > one simple command, just one time. > >> >> Martin >> > > How about a compromise? By default everything is expected to be installed. But there is a command line switch that allows to skip modules you want to skip. You provide the switch and the list of the modules to skip and build will validate only modules that are not in the list. Will something like this work? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Wed Apr 27 13:56:13 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 27 Apr 2011 09:56:13 -0400 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <4DB81B4E.1030803@redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> <4DB7F28F.8040505@redhat.com> <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> <4DB8084C.7010902@redhat.com> <4DB81B4E.1030803@redhat.com> Message-ID: <4DB8207D.1080603@redhat.com> On 04/27/2011 09:34 AM, Dmitri Pal wrote: > On 04/27/2011 08:13 AM, Jan Cholasta wrote: >> On 27.4.2011 13:17, Martin Kosek wrote: >>> On Wed, 2011-04-27 at 12:40 +0200, Jan Cholasta wrote: >>>> On 26.4.2011 18:14, Martin Kosek wrote: >>>>> On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: >>>>>> Automatically run the lint script during make rpms|client-rpms|srpms. >>>>>> >>>>> NACK until ticket 1184 is resolved and pushed. Currently, pylint check >>>>> fails when optional python packages (like python-rhsm) are not >>>>> installed >>>>> on the machine. We should be able to build IPA without those packages >>>>> installed. >>>> I think printing a note asking the developer to kindly install the >>>> missing packages would be sufficient. AFAIK there are currently only 2 >>>> optional packages: python-rhsm and python-krbV. python-krbV is optional >>>> only for the client part of IPA, so you most likely have it already >>>> installed and installing python-rhsm is not really much of a chore. >>>> That >>>> way all of the code would always be checked and the lint script >>>> would be >>>> free of the unnecessary complexity of handling missing packages. >>> I don't think this is a right approach. When the package is optional >>> (currently it may be python-rhsm and python-krbV only, but there may be >>> others in the future) I shouldn't be obliged to install them in order to >>> build IPA. >> You shouldn't be obliged to install them as a user. As a developer, >> you should be ready for all kinds of crazy stuff IMHO. >> >>> When somebody develops something related with the optional >>> package he has them installed and the lint will check the relevant code >>> too. >> All of the code goes to the package, so it all should be checked >> during the build. >> >> Imagine situation like this: You change something in module A, >> accidentally breaking functionality that module B depends on. Module A >> is checked and no error is found (because it's the kind of issue that >> exhibits itself only in certain conditions). Module B isn't checked, >> because it also depends on a not-installed optional package. If it was >> checked, it would report an error that would lead you to the error in >> module A. But everything looks fine, so the build succeeds, even when >> the error is there. >> >> The situation might be improbable, but IMO the code should be checked >> in the same ecosystem every time anyway, because weird stuff could >> happen if it wasn't. >> >>> It is not that big deal, I just think it would be an annoyance for >>> developers. But maybe there is a different opinion. >> I know we developers are lazy folk, but this is a matter of writing >> one simple command, just one time. >> >>> Martin >>> >> > How about a compromise? > By default everything is expected to be installed. > But there is a command line switch that allows to skip modules you want > to skip. You provide the switch and the list of the modules to skip and > build will validate only modules that are not in the list. > > Will something like this work? > Actually, make the command line switch just means that a Lint failure doesn't stop the build. That way, by default the build will fail unless everything is there and checked, but there is a way to move forward for building with a subset of packages. From mkosek at redhat.com Wed Apr 27 14:17:15 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 Apr 2011 16:17:15 +0200 Subject: [Freeipa-devel] [PATCH] 053 Forbid reinstallation in ipa-client-install Message-ID: <1303913835.15737.14.camel@dhcp-25-52.brq.redhat.com> The --force option may be misused to reinstall an existing IPA client. This is not supported and may lead to unexpected errors. When required, the cleanest way to re-install IPA client is to run uninstall and then install again. This patch also includes few cosmetic changes in "LDAP" term case to provide more consistent experience with the script. https://fedorahosted.org/freeipa/ticket/1117 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-053-forbid-reinstallation-in-ipa-client-install.patch Type: text/x-patch Size: 3200 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 27 14:24:36 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 Apr 2011 16:24:36 +0200 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <4DB8207D.1080603@redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> <4DB7F28F.8040505@redhat.com> <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> <4DB8084C.7010902@redhat.com> <4DB81B4E.1030803@redhat.com> <4DB8207D.1080603@redhat.com> Message-ID: <1303914276.15737.19.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-27 at 09:56 -0400, Adam Young wrote: > On 04/27/2011 09:34 AM, Dmitri Pal wrote: > > On 04/27/2011 08:13 AM, Jan Cholasta wrote: > >> On 27.4.2011 13:17, Martin Kosek wrote: > >>> On Wed, 2011-04-27 at 12:40 +0200, Jan Cholasta wrote: > >>>> On 26.4.2011 18:14, Martin Kosek wrote: > >>>>> On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: > >>>>>> Automatically run the lint script during make rpms|client-rpms|srpms. > >>>>>> > >>>>> NACK until ticket 1184 is resolved and pushed. Currently, pylint check > >>>>> fails when optional python packages (like python-rhsm) are not > >>>>> installed > >>>>> on the machine. We should be able to build IPA without those packages > >>>>> installed. > >>>> I think printing a note asking the developer to kindly install the > >>>> missing packages would be sufficient. AFAIK there are currently only 2 > >>>> optional packages: python-rhsm and python-krbV. python-krbV is optional > >>>> only for the client part of IPA, so you most likely have it already > >>>> installed and installing python-rhsm is not really much of a chore. > >>>> That > >>>> way all of the code would always be checked and the lint script > >>>> would be > >>>> free of the unnecessary complexity of handling missing packages. > >>> I don't think this is a right approach. When the package is optional > >>> (currently it may be python-rhsm and python-krbV only, but there may be > >>> others in the future) I shouldn't be obliged to install them in order to > >>> build IPA. > >> You shouldn't be obliged to install them as a user. As a developer, > >> you should be ready for all kinds of crazy stuff IMHO. > >> > >>> When somebody develops something related with the optional > >>> package he has them installed and the lint will check the relevant code > >>> too. > >> All of the code goes to the package, so it all should be checked > >> during the build. > >> > >> Imagine situation like this: You change something in module A, > >> accidentally breaking functionality that module B depends on. Module A > >> is checked and no error is found (because it's the kind of issue that > >> exhibits itself only in certain conditions). Module B isn't checked, > >> because it also depends on a not-installed optional package. If it was > >> checked, it would report an error that would lead you to the error in > >> module A. But everything looks fine, so the build succeeds, even when > >> the error is there. > >> > >> The situation might be improbable, but IMO the code should be checked > >> in the same ecosystem every time anyway, because weird stuff could > >> happen if it wasn't. > >> > >>> It is not that big deal, I just think it would be an annoyance for > >>> developers. But maybe there is a different opinion. > >> I know we developers are lazy folk, but this is a matter of writing > >> one simple command, just one time. > >> > >>> Martin > >>> > >> > > How about a compromise? > > By default everything is expected to be installed. > > But there is a command line switch that allows to skip modules you want > > to skip. You provide the switch and the list of the modules to skip and > > build will validate only modules that are not in the list. > > > > Will something like this work? > > > Actually, make the command line switch just means that a Lint failure > doesn't stop the build. That way, by default the build will fail unless > everything is there and checked, but there is a way to move forward for > building with a subset of packages. Yes, I think we will can settle with a compromise. My only concern was not to force the developers to install unnecessary packages for build. I would suggest that the build (or "make lint") succeeds without those optional packages installed, but a warning is printed out that some packages are missing and not all the code is checked. Then it is a developers responsibility to handle this and wouldn't be force to install those packages for his test builds etc. Martin From edewata at redhat.com Wed Apr 27 14:34:28 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Apr 2011 09:34:28 -0500 Subject: [Freeipa-devel] [PATCH] 143 Entitlement quantity validation. In-Reply-To: <4DB76FF5.3020602@redhat.com> References: <4DB73D98.4040307@redhat.com> <4DB76FF5.3020602@redhat.com> Message-ID: <4DB82974.3010804@redhat.com> On 4/26/2011 8:23 PM, Adam Young wrote: >> The widget base class has been modified to validate integer value >> if the type is specified in the metadata. This is used to validate >> entitlement quantity. > Logic looks good. I'd like to make the validator an external object, and > have the builder select the validator based on the metadata. > > The IPA data types beyond String and int are: > > bool, float, bytes, and enum. We should at least plan for them, even if > we are not implementing them now: > > something like > > var validators = { > int: function (blah){...} > string: function (regex){....} > } > > widget.spec. validator = validators[type]; I had a similar thought, but the validator interface needs further thinking. I'll keep the patch as is for now. This can be refactored into external validator in a follow on patch. -- Endi S. Dewata From ssorce at redhat.com Wed Apr 27 14:53:27 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 27 Apr 2011 10:53:27 -0400 Subject: [Freeipa-devel] [PATCH] 049 IPA replica is not started after the reboot In-Reply-To: <1303807265.9340.3.camel@dhcp-25-52.brq.redhat.com> References: <1303807265.9340.3.camel@dhcp-25-52.brq.redhat.com> Message-ID: <1303916007.23464.123.camel@willson.li.ssimo.org> On Tue, 2011-04-26 at 10:41 +0200, Martin Kosek wrote: > https://fedorahosted.org/freeipa/ticket/1191 > ACK! Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Apr 27 14:54:58 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 27 Apr 2011 10:54:58 -0400 Subject: [Freeipa-devel] [PATCH] 051 Improve Directory Service open port checker In-Reply-To: <1303900989.15737.0.camel@dhcp-25-52.brq.redhat.com> References: <1303900989.15737.0.camel@dhcp-25-52.brq.redhat.com> Message-ID: <1303916098.23464.124.camel@willson.li.ssimo.org> On Wed, 2011-04-27 at 12:43 +0200, Martin Kosek wrote: > Wait for DS ports to open after _every_ DS service restart. > Several restarts were missed by the current open port checker > implementation. > > https://fedorahosted.org/freeipa/ticket/1182 Ack Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Apr 27 14:56:29 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 27 Apr 2011 10:56:29 -0400 Subject: [Freeipa-devel] [PATCH] 052 Log temporary files in ipa-client-install In-Reply-To: <1303903781.15737.13.camel@dhcp-25-52.brq.redhat.com> References: <1303903781.15737.13.camel@dhcp-25-52.brq.redhat.com> Message-ID: <1303916189.23464.125.camel@willson.li.ssimo.org> On Wed, 2011-04-27 at 13:29 +0200, Martin Kosek wrote: > This patch will help investigating issues like in ticket 1100 resolved > by my patch 50. > > ------ > > This patch adds logging of temporary files (Kerberos configuration, > nsupdate commands) that may be very useful for debugging purposes. > > https://fedorahosted.org/freeipa/ticket/1093 > https://fedorahosted.org/freeipa/ticket/1094 Ack, very useuful stuff, thanks! Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Apr 27 14:59:14 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Apr 2011 10:59:14 -0400 Subject: [Freeipa-devel] [PATCH] fixes #1193 init script related In-Reply-To: <1303855431.23464.107.camel@willson.li.ssimo.org> References: <1303849269.23464.82.camel@willson.li.ssimo.org> <4DB73463.6090505@redhat.com> <1303855431.23464.107.camel@willson.li.ssimo.org> Message-ID: <4DB82F42.3080302@redhat.com> Simo Sorce wrote: > On Tue, 2011-04-26 at 17:08 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> With this patch we stop clearing the environment variables when running >>> binaries allowing for env variables to be passed down by default. >>> >>> This fixes also the init script against Fedora 15 and systemd >>> >>> Simo. >>> >> >> I think it would be better to import copy and use: >> >> if env is None: >> env = copy.deepcopy(os.environ) >> env["PATH"] = "/bin:/sbin:..." >> >> rob > > Updated patch attached. > > Simo. > ack From ssorce at redhat.com Wed Apr 27 14:59:34 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 27 Apr 2011 10:59:34 -0400 Subject: [Freeipa-devel] [PATCH] 053 Forbid reinstallation in ipa-client-install In-Reply-To: <1303913835.15737.14.camel@dhcp-25-52.brq.redhat.com> References: <1303913835.15737.14.camel@dhcp-25-52.brq.redhat.com> Message-ID: <1303916374.23464.126.camel@willson.li.ssimo.org> On Wed, 2011-04-27 at 16:17 +0200, Martin Kosek wrote: > The --force option may be misused to reinstall an existing IPA > client. This is not supported and may lead to unexpected errors. > When required, the cleanest way to re-install IPA client is to > run uninstall and then install again. > > This patch also includes few cosmetic changes in "LDAP" term case > to provide more consistent experience with the script. > > https://fedorahosted.org/freeipa/ticket/1117 Code looks good, but can you add to the last message advice about running --uninstall in case that's what the user is trying to do (a re-install) Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Wed Apr 27 15:00:32 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Apr 2011 10:00:32 -0500 Subject: [Freeipa-devel] [PATCH] admiyo-0225-remove-jquery-cookie-library In-Reply-To: <4DB76476.3070306@redhat.com> References: <4DB76476.3070306@redhat.com> Message-ID: <4DB82F90.4090404@redhat.com> On 4/26/2011 7:33 PM, Adam Young wrote: > ACK and pushed to master. -- Endi S. Dewata From dpal at redhat.com Wed Apr 27 15:01:04 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 27 Apr 2011 11:01:04 -0400 Subject: [Freeipa-devel] [PATCH] 143 Entitlement quantity validation. In-Reply-To: <4DB82974.3010804@redhat.com> References: <4DB73D98.4040307@redhat.com> <4DB76FF5.3020602@redhat.com> <4DB82974.3010804@redhat.com> Message-ID: <4DB82FB0.30403@redhat.com> On 04/27/2011 10:34 AM, Endi Sukma Dewata wrote: > On 4/26/2011 8:23 PM, Adam Young wrote: >>> The widget base class has been modified to validate integer value >>> if the type is specified in the metadata. This is used to validate >>> entitlement quantity. > >> Logic looks good. I'd like to make the validator an external object, and >> have the builder select the validator based on the metadata. >> >> The IPA data types beyond String and int are: >> >> bool, float, bytes, and enum. We should at least plan for them, even if >> we are not implementing them now: >> >> something like >> >> var validators = { >> int: function (blah){...} >> string: function (regex){....} >> } >> >> widget.spec. validator = validators[type]; > > I had a similar thought, but the validator interface needs further > thinking. I'll keep the patch as is for now. This can be refactored > into external validator in a follow on patch. > We will have a conversation about the entitlements next week. We need to get on the same page with the entitlements team and straighten the use cases. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Apr 27 15:23:13 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Apr 2011 11:23:13 -0400 Subject: [Freeipa-devel] [PATCH] 780 Handle principal not found errors when converting replication agreements Message-ID: <4DB834E1.1040201@redhat.com> There are times where one side or the other is missing its peers krbprincipalname when converting from simple to GSSAPI replication. Ticket 1188 should address the cause of this. This patch provides better information and handling should either side be missing. ticket 1044 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-780-replica.patch Type: application/mbox Size: 1534 bytes Desc: not available URL: From ssorce at redhat.com Wed Apr 27 15:26:35 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 27 Apr 2011 11:26:35 -0400 Subject: [Freeipa-devel] [PATCH] fixes #1193 init script related In-Reply-To: <4DB82F42.3080302@redhat.com> References: <1303849269.23464.82.camel@willson.li.ssimo.org> <4DB73463.6090505@redhat.com> <1303855431.23464.107.camel@willson.li.ssimo.org> <4DB82F42.3080302@redhat.com> Message-ID: <1303917995.23464.127.camel@willson.li.ssimo.org> On Wed, 2011-04-27 at 10:59 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 2011-04-26 at 17:08 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> With this patch we stop clearing the environment variables when running > >>> binaries allowing for env variables to be passed down by default. > >>> > >>> This fixes also the init script against Fedora 15 and systemd > >>> > >>> Simo. > >>> > >> > >> I think it would be better to import copy and use: > >> > >> if env is None: > >> env = copy.deepcopy(os.environ) > >> env["PATH"] = "/bin:/sbin:..." > >> > >> rob > > > > Updated patch attached. > > > > Simo. > > > > ack Pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York From ayoung at redhat.com Wed Apr 27 15:43:53 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 27 Apr 2011 11:43:53 -0400 Subject: [Freeipa-devel] [PATCH] 143 Entitlement quantity validation. In-Reply-To: <4DB82974.3010804@redhat.com> References: <4DB73D98.4040307@redhat.com> <4DB76FF5.3020602@redhat.com> <4DB82974.3010804@redhat.com> Message-ID: <4DB839B9.6000300@redhat.com> On 04/27/2011 10:34 AM, Endi Sukma Dewata wrote: > On 4/26/2011 8:23 PM, Adam Young wrote: >>> The widget base class has been modified to validate integer value >>> if the type is specified in the metadata. This is used to validate >>> entitlement quantity. > >> Logic looks good. I'd like to make the validator an external object, and >> have the builder select the validator based on the metadata. >> >> The IPA data types beyond String and int are: >> >> bool, float, bytes, and enum. We should at least plan for them, even if >> we are not implementing them now: >> >> something like >> >> var validators = { >> int: function (blah){...} >> string: function (regex){....} >> } >> >> widget.spec. validator = validators[type]; > > I had a similar thought, but the validator interface needs further > thinking. I'll keep the patch as is for now. This can be refactored > into external validator in a follow on patch. > Sounds good. ACK From edewata at redhat.com Wed Apr 27 15:46:41 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Apr 2011 10:46:41 -0500 Subject: [Freeipa-devel] [PATCH] 143 Entitlement quantity validation. In-Reply-To: <4DB839B9.6000300@redhat.com> References: <4DB73D98.4040307@redhat.com> <4DB76FF5.3020602@redhat.com> <4DB82974.3010804@redhat.com> <4DB839B9.6000300@redhat.com> Message-ID: <4DB83A61.2030902@redhat.com> On 4/27/2011 10:43 AM, Adam Young wrote: >>>> The widget base class has been modified to validate integer value >>>> if the type is specified in the metadata. This is used to validate >>>> entitlement quantity. >>> Logic looks good. I'd like to make the validator an external object, and >>> have the builder select the validator based on the metadata. >> I had a similar thought, but the validator interface needs further >> thinking. I'll keep the patch as is for now. This can be refactored >> into external validator in a follow on patch. > > Sounds good. ACK Pushed to master. -- Endi S. Dewata From ayoung at redhat.com Wed Apr 27 16:33:16 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 27 Apr 2011 12:33:16 -0400 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <1303914276.15737.19.camel@dhcp-25-52.brq.redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> <4DB7F28F.8040505@redhat.com> <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> <4DB8084C.7010902@redhat.com> <4DB81B4E.1030803@redhat.com> <4DB8207D.1080603@redhat.com> <1303914276.15737.19.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB8454C.4010400@redhat.com> On 04/27/2011 10:24 AM, Martin Kosek wrote: > On Wed, 2011-04-27 at 09:56 -0400, Adam Young wrote: >> On 04/27/2011 09:34 AM, Dmitri Pal wrote: >>> On 04/27/2011 08:13 AM, Jan Cholasta wrote: >>>> On 27.4.2011 13:17, Martin Kosek wrote: >>>>> On Wed, 2011-04-27 at 12:40 +0200, Jan Cholasta wrote: >>>>>> On 26.4.2011 18:14, Martin Kosek wrote: >>>>>>> On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: >>>>>>>> Automatically run the lint script during make rpms|client-rpms|srpms. >>>>>>>> >>>>>>> NACK until ticket 1184 is resolved and pushed. Currently, pylint check >>>>>>> fails when optional python packages (like python-rhsm) are not >>>>>>> installed >>>>>>> on the machine. We should be able to build IPA without those packages >>>>>>> installed. >>>>>> I think printing a note asking the developer to kindly install the >>>>>> missing packages would be sufficient. AFAIK there are currently only 2 >>>>>> optional packages: python-rhsm and python-krbV. python-krbV is optional >>>>>> only for the client part of IPA, so you most likely have it already >>>>>> installed and installing python-rhsm is not really much of a chore. >>>>>> That >>>>>> way all of the code would always be checked and the lint script >>>>>> would be >>>>>> free of the unnecessary complexity of handling missing packages. >>>>> I don't think this is a right approach. When the package is optional >>>>> (currently it may be python-rhsm and python-krbV only, but there may be >>>>> others in the future) I shouldn't be obliged to install them in order to >>>>> build IPA. >>>> You shouldn't be obliged to install them as a user. As a developer, >>>> you should be ready for all kinds of crazy stuff IMHO. >>>> >>>>> When somebody develops something related with the optional >>>>> package he has them installed and the lint will check the relevant code >>>>> too. >>>> All of the code goes to the package, so it all should be checked >>>> during the build. >>>> >>>> Imagine situation like this: You change something in module A, >>>> accidentally breaking functionality that module B depends on. Module A >>>> is checked and no error is found (because it's the kind of issue that >>>> exhibits itself only in certain conditions). Module B isn't checked, >>>> because it also depends on a not-installed optional package. If it was >>>> checked, it would report an error that would lead you to the error in >>>> module A. But everything looks fine, so the build succeeds, even when >>>> the error is there. >>>> >>>> The situation might be improbable, but IMO the code should be checked >>>> in the same ecosystem every time anyway, because weird stuff could >>>> happen if it wasn't. >>>> >>>>> It is not that big deal, I just think it would be an annoyance for >>>>> developers. But maybe there is a different opinion. >>>> I know we developers are lazy folk, but this is a matter of writing >>>> one simple command, just one time. >>>> >>>>> Martin >>>>> >>> How about a compromise? >>> By default everything is expected to be installed. >>> But there is a command line switch that allows to skip modules you want >>> to skip. You provide the switch and the list of the modules to skip and >>> build will validate only modules that are not in the list. >>> >>> Will something like this work? >>> >> Actually, make the command line switch just means that a Lint failure >> doesn't stop the build. That way, by default the build will fail unless >> everything is there and checked, but there is a way to move forward for >> building with a subset of packages. > Yes, I think we will can settle with a compromise. My only concern was > not to force the developers to install unnecessary packages for build. > > I would suggest that the build (or "make lint") succeeds without those > optional packages installed, but a warning is printed out that some > packages are missing and not all the code is checked. > > Then it is a developers responsibility to handle this and wouldn't be > force to install those packages for his test builds etc. How about instead it fails bny default, but prints the message "to suppress the lint check stopping the build, run make --no-fail-on-lint" so that skipping lint is a deliberate decision? > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Wed Apr 27 17:32:55 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Apr 2011 13:32:55 -0400 Subject: [Freeipa-devel] [PATCH] fixes #1193 init script related In-Reply-To: <1303917995.23464.127.camel@willson.li.ssimo.org> References: <1303849269.23464.82.camel@willson.li.ssimo.org> <4DB73463.6090505@redhat.com> <1303855431.23464.107.camel@willson.li.ssimo.org> <4DB82F42.3080302@redhat.com> <1303917995.23464.127.camel@willson.li.ssimo.org> Message-ID: <4DB85347.2040207@redhat.com> Simo Sorce wrote: > On Wed, 2011-04-27 at 10:59 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Tue, 2011-04-26 at 17:08 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> With this patch we stop clearing the environment variables when running >>>>> binaries allowing for env variables to be passed down by default. >>>>> >>>>> This fixes also the init script against Fedora 15 and systemd >>>>> >>>>> Simo. >>>>> >>>> >>>> I think it would be better to import copy and use: >>>> >>>> if env is None: >>>> env = copy.deepcopy(os.environ) >>>> env["PATH"] = "/bin:/sbin:..." >>>> >>>> rob >>> >>> Updated patch attached. >>> >>> Simo. >>> >> >> ack > > Pushed to master. > > Simo. > Pushed to ipa-2-0 branch rob From dpal at redhat.com Wed Apr 27 17:52:01 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 27 Apr 2011 13:52:01 -0400 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <4DB8454C.4010400@redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> <4DB7F28F.8040505@redhat.com> <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> <4DB8084C.7010902@redhat.com> <4DB81B4E.1030803@redhat.com> <4DB8207D.1080603@redhat.com> <1303914276.15737.19.camel@dhcp-25-52.brq.redhat.com> <4DB8454C.4010400@redhat.com> Message-ID: <4DB857C1.9050407@redhat.com> On 04/27/2011 12:33 PM, Adam Young wrote: > On 04/27/2011 10:24 AM, Martin Kosek wrote: >> On Wed, 2011-04-27 at 09:56 -0400, Adam Young wrote: >>> On 04/27/2011 09:34 AM, Dmitri Pal wrote: >>>> On 04/27/2011 08:13 AM, Jan Cholasta wrote: >>>>> On 27.4.2011 13:17, Martin Kosek wrote: >>>>>> On Wed, 2011-04-27 at 12:40 +0200, Jan Cholasta wrote: >>>>>>> On 26.4.2011 18:14, Martin Kosek wrote: >>>>>>>> On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: >>>>>>>>> Automatically run the lint script during make >>>>>>>>> rpms|client-rpms|srpms. >>>>>>>>> >>>>>>>> NACK until ticket 1184 is resolved and pushed. Currently, >>>>>>>> pylint check >>>>>>>> fails when optional python packages (like python-rhsm) are not >>>>>>>> installed >>>>>>>> on the machine. We should be able to build IPA without those >>>>>>>> packages >>>>>>>> installed. >>>>>>> I think printing a note asking the developer to kindly install the >>>>>>> missing packages would be sufficient. AFAIK there are currently >>>>>>> only 2 >>>>>>> optional packages: python-rhsm and python-krbV. python-krbV is >>>>>>> optional >>>>>>> only for the client part of IPA, so you most likely have it already >>>>>>> installed and installing python-rhsm is not really much of a chore. >>>>>>> That >>>>>>> way all of the code would always be checked and the lint script >>>>>>> would be >>>>>>> free of the unnecessary complexity of handling missing packages. >>>>>> I don't think this is a right approach. When the package is optional >>>>>> (currently it may be python-rhsm and python-krbV only, but there >>>>>> may be >>>>>> others in the future) I shouldn't be obliged to install them in >>>>>> order to >>>>>> build IPA. >>>>> You shouldn't be obliged to install them as a user. As a developer, >>>>> you should be ready for all kinds of crazy stuff IMHO. >>>>> >>>>>> When somebody develops something related with the optional >>>>>> package he has them installed and the lint will check the >>>>>> relevant code >>>>>> too. >>>>> All of the code goes to the package, so it all should be checked >>>>> during the build. >>>>> >>>>> Imagine situation like this: You change something in module A, >>>>> accidentally breaking functionality that module B depends on. >>>>> Module A >>>>> is checked and no error is found (because it's the kind of issue that >>>>> exhibits itself only in certain conditions). Module B isn't checked, >>>>> because it also depends on a not-installed optional package. If it >>>>> was >>>>> checked, it would report an error that would lead you to the error in >>>>> module A. But everything looks fine, so the build succeeds, even when >>>>> the error is there. >>>>> >>>>> The situation might be improbable, but IMO the code should be checked >>>>> in the same ecosystem every time anyway, because weird stuff could >>>>> happen if it wasn't. >>>>> >>>>>> It is not that big deal, I just think it would be an annoyance for >>>>>> developers. But maybe there is a different opinion. >>>>> I know we developers are lazy folk, but this is a matter of writing >>>>> one simple command, just one time. >>>>> >>>>>> Martin >>>>>> >>>> How about a compromise? >>>> By default everything is expected to be installed. >>>> But there is a command line switch that allows to skip modules you >>>> want >>>> to skip. You provide the switch and the list of the modules to skip >>>> and >>>> build will validate only modules that are not in the list. >>>> >>>> Will something like this work? >>>> >>> Actually, make the command line switch just means that a Lint failure >>> doesn't stop the build. That way, by default the build will fail >>> unless >>> everything is there and checked, but there is a way to move forward for >>> building with a subset of packages. >> Yes, I think we will can settle with a compromise. My only concern was >> not to force the developers to install unnecessary packages for build. >> >> I would suggest that the build (or "make lint") succeeds without those >> optional packages installed, but a warning is printed out that some >> packages are missing and not all the code is checked. >> >> Then it is a developers responsibility to handle this and wouldn't be >> force to install those packages for his test builds etc. > > How about instead it fails bny default, but prints the message "to > suppress the lint check stopping the build, run make > --no-fail-on-lint" so that skipping lint is a deliberate decision? Yes this is the approach I prefer. > >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Wed Apr 27 17:56:37 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 27 Apr 2011 13:56:37 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0226-Added-a-container-for-the-facet Message-ID: <4DB858D5.40204@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0226-Added-a-container-for-the-facet.patch Type: text/x-patch Size: 2736 bytes Desc: not available URL: From edewata at redhat.com Wed Apr 27 20:39:07 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Apr 2011 15:39:07 -0500 Subject: [Freeipa-devel] [PATCH] admiyo-0226-Added-a-container-for-the-facet In-Reply-To: <4DB858D5.40204@redhat.com> References: <4DB858D5.40204@redhat.com> Message-ID: <4DB87EEB.8030409@redhat.com> On 4/27/2011 12:56 PM, Adam Young wrote: > Currently we have this DOM structure:
1. The nested entity-container is confusing and probably will make CSS adjustment harder. The entity content should be in the same level as entity header. 2. The _container suffix for the facet container name is unnecessary because it already has a facet_container class. 3. The use of id attribute could lead to conflicts. It's better to use a name attribute and a class. Querying the element can be done with this selector: $('.facet[name=search]', ...) 4. Rename action-controls to entity-controls for consistency. 5. Rename facet_container to facet-container for consistency. 6. The hidden pkey can be stored in the entity object instead of DOM. The DOM structure will look like this:
What do you think? We can do this in a separate patch if it's too complicated. -- Endi S. Dewata From ayoung at redhat.com Thu Apr 28 01:09:17 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 27 Apr 2011 21:09:17 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0226-Added-a-container-for-the-facet In-Reply-To: <4DB87EEB.8030409@redhat.com> References: <4DB858D5.40204@redhat.com> <4DB87EEB.8030409@redhat.com> Message-ID: <4DB8BE3D.3090905@redhat.com> On 04/27/2011 04:39 PM, Endi Sukma Dewata wrote: > On 4/27/2011 12:56 PM, Adam Young wrote: >> > > Currently we have this DOM structure: > >
>
>
> >
> > >
>
>
>
>
>
>
>
> > 1. The nested entity-container is confusing and probably will make CSS > adjustment harder. The entity content should be in the same level as > entity header. > > 2. The _container suffix for the facet container name is unnecessary > because it already has a facet_container class. > > 3. The use of id attribute could lead to conflicts. It's better to use > a name attribute and a class. Querying the element can be done with > this selector: > > $('.facet[name=search]', ...) > > 4. Rename action-controls to entity-controls for consistency. > > 5. Rename facet_container to facet-container for consistency. > > 6. The hidden pkey can be stored in the entity object instead of DOM. > > The DOM structure will look like this: > >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> > What do you think? We can do this in a separate patch if it's too > complicated. > Very clean: I like it a lot. I'd like to do it as a separate patch, just to keep clear what we are doing. From ayoung at redhat.com Thu Apr 28 01:47:21 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 27 Apr 2011 21:47:21 -0400 Subject: [Freeipa-devel] [PATCH] admiyo-0226-Added-a-container-for-the-facet In-Reply-To: <4DB8BE3D.3090905@redhat.com> References: <4DB858D5.40204@redhat.com> <4DB87EEB.8030409@redhat.com> <4DB8BE3D.3090905@redhat.com> Message-ID: <4DB8C729.7060308@redhat.com> On 04/27/2011 09:09 PM, Adam Young wrote: > On 04/27/2011 04:39 PM, Endi Sukma Dewata wrote: >> On 4/27/2011 12:56 PM, Adam Young wrote: >>> >> >> Currently we have this DOM structure: >> >>
>>
>>
>> >>
>> >> >>
>>
>>
>>
>>
>>
>>
>>
>> >> 1. The nested entity-container is confusing and probably will make >> CSS adjustment harder. The entity content should be in the same level >> as entity header. >> >> 2. The _container suffix for the facet container name is unnecessary >> because it already has a facet_container class. >> >> 3. The use of id attribute could lead to conflicts. It's better to >> use a name attribute and a class. Querying the element can be done >> with this selector: >> >> $('.facet[name=search]', ...) >> >> 4. Rename action-controls to entity-controls for consistency. >> >> 5. Rename facet_container to facet-container for consistency. >> >> 6. The hidden pkey can be stored in the entity object instead of DOM. >> >> The DOM structure will look like this: >> >>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> >> What do you think? We can do this in a separate patch if it's too >> complicated. >> > > > Very clean: I like it a lot. I'd like to do it as a separate patch, > just to keep clear what we are doing. The more I think about it, the more I think that this structure can be created by the navigation code, and then passed to the entity to populate. The entity-header function moves to navigation.js, but does not have a reference to the entity yet. When an entity tab gets activated, we then populate this structure. everything can get created on demand. I'm assuming that entity-search is for the search bar, and not the search facet: search facet still goes inside the entity-content, right? > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From edewata at redhat.com Thu Apr 28 02:15:43 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Apr 2011 21:15:43 -0500 Subject: [Freeipa-devel] [PATCH] admiyo-0226-Added-a-container-for-the-facet In-Reply-To: <4DB8BE3D.3090905@redhat.com> References: <4DB858D5.40204@redhat.com> <4DB87EEB.8030409@redhat.com> <4DB8BE3D.3090905@redhat.com> Message-ID: <4DB8CDCF.8050505@redhat.com> On 4/27/2011 8:09 PM, Adam Young wrote: >>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> >> What do you think? We can do this in a separate patch if it's too >> complicated. > > Very clean: I like it a lot. I'd like to do it as a separate patch, just > to keep clear what we are doing. Found some issues: 1. The selector on entity.js:314 is missing a # sign: var facet_container = $('#'+facet.name +'_container', entity.header.content); 2. Entity header is not updated after switching facets. Open Users tab, click one of the users, then click Back to Search. The title and buttons are wrong and the facet tabs do not disappear. This is because entity header is shared with other facets and isn't updated if the facet container already exists. -- Endi S. Dewata From edewata at redhat.com Thu Apr 28 02:39:15 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Apr 2011 21:39:15 -0500 Subject: [Freeipa-devel] [PATCH] admiyo-0226-Added-a-container-for-the-facet In-Reply-To: <4DB8C729.7060308@redhat.com> References: <4DB858D5.40204@redhat.com> <4DB87EEB.8030409@redhat.com> <4DB8BE3D.3090905@redhat.com> <4DB8C729.7060308@redhat.com> Message-ID: <4DB8D353.9090703@redhat.com> On 4/27/2011 8:47 PM, Adam Young wrote: > The more I think about it, the more I think that this structure can be > created by the navigation code, and then passed to the entity to > populate. The entity-header function moves to navigation.js, but does > not have a reference to the entity yet. When an entity tab gets > activated, we then populate this structure. everything can get created > on demand. Not sure, I'd have to see how it's implemented. My concern is whether it would limit entity customization. > I'm assuming that entity-search is for the search bar, and not the > search facet: search facet still goes inside the entity-content, right? Yes, it's for the search field. The search facet will use a 'facet' class, same as other facets. -- Endi S. Dewata From mkosek at redhat.com Thu Apr 28 06:57:27 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Apr 2011 08:57:27 +0200 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <4DB857C1.9050407@redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> <4DB7F28F.8040505@redhat.com> <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> <4DB8084C.7010902@redhat.com> <4DB81B4E.1030803@redhat.com> <4DB8207D.1080603@redhat.com> <1303914276.15737.19.camel@dhcp-25-52.brq.redhat.com> <4DB8454C.4010400@redhat.com> <4DB857C1.9050407@redhat.com> Message-ID: <1303973847.11310.4.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-27 at 13:52 -0400, Dmitri Pal wrote: > On 04/27/2011 12:33 PM, Adam Young wrote: > > On 04/27/2011 10:24 AM, Martin Kosek wrote: > >> On Wed, 2011-04-27 at 09:56 -0400, Adam Young wrote: > >>> On 04/27/2011 09:34 AM, Dmitri Pal wrote: > >>>> On 04/27/2011 08:13 AM, Jan Cholasta wrote: > >>>>> On 27.4.2011 13:17, Martin Kosek wrote: > >>>>>> On Wed, 2011-04-27 at 12:40 +0200, Jan Cholasta wrote: > >>>>>>> On 26.4.2011 18:14, Martin Kosek wrote: > >>>>>>>> On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: > >>>>>>>>> Automatically run the lint script during make > >>>>>>>>> rpms|client-rpms|srpms. > >>>>>>>>> > >>>>>>>> NACK until ticket 1184 is resolved and pushed. Currently, > >>>>>>>> pylint check > >>>>>>>> fails when optional python packages (like python-rhsm) are not > >>>>>>>> installed > >>>>>>>> on the machine. We should be able to build IPA without those > >>>>>>>> packages > >>>>>>>> installed. > >>>>>>> I think printing a note asking the developer to kindly install the > >>>>>>> missing packages would be sufficient. AFAIK there are currently > >>>>>>> only 2 > >>>>>>> optional packages: python-rhsm and python-krbV. python-krbV is > >>>>>>> optional > >>>>>>> only for the client part of IPA, so you most likely have it already > >>>>>>> installed and installing python-rhsm is not really much of a chore. > >>>>>>> That > >>>>>>> way all of the code would always be checked and the lint script > >>>>>>> would be > >>>>>>> free of the unnecessary complexity of handling missing packages. > >>>>>> I don't think this is a right approach. When the package is optional > >>>>>> (currently it may be python-rhsm and python-krbV only, but there > >>>>>> may be > >>>>>> others in the future) I shouldn't be obliged to install them in > >>>>>> order to > >>>>>> build IPA. > >>>>> You shouldn't be obliged to install them as a user. As a developer, > >>>>> you should be ready for all kinds of crazy stuff IMHO. > >>>>> > >>>>>> When somebody develops something related with the optional > >>>>>> package he has them installed and the lint will check the > >>>>>> relevant code > >>>>>> too. > >>>>> All of the code goes to the package, so it all should be checked > >>>>> during the build. > >>>>> > >>>>> Imagine situation like this: You change something in module A, > >>>>> accidentally breaking functionality that module B depends on. > >>>>> Module A > >>>>> is checked and no error is found (because it's the kind of issue that > >>>>> exhibits itself only in certain conditions). Module B isn't checked, > >>>>> because it also depends on a not-installed optional package. If it > >>>>> was > >>>>> checked, it would report an error that would lead you to the error in > >>>>> module A. But everything looks fine, so the build succeeds, even when > >>>>> the error is there. > >>>>> > >>>>> The situation might be improbable, but IMO the code should be checked > >>>>> in the same ecosystem every time anyway, because weird stuff could > >>>>> happen if it wasn't. > >>>>> > >>>>>> It is not that big deal, I just think it would be an annoyance for > >>>>>> developers. But maybe there is a different opinion. > >>>>> I know we developers are lazy folk, but this is a matter of writing > >>>>> one simple command, just one time. > >>>>> > >>>>>> Martin > >>>>>> > >>>> How about a compromise? > >>>> By default everything is expected to be installed. > >>>> But there is a command line switch that allows to skip modules you > >>>> want > >>>> to skip. You provide the switch and the list of the modules to skip > >>>> and > >>>> build will validate only modules that are not in the list. > >>>> > >>>> Will something like this work? > >>>> > >>> Actually, make the command line switch just means that a Lint failure > >>> doesn't stop the build. That way, by default the build will fail > >>> unless > >>> everything is there and checked, but there is a way to move forward for > >>> building with a subset of packages. > >> Yes, I think we will can settle with a compromise. My only concern was > >> not to force the developers to install unnecessary packages for build. > >> > >> I would suggest that the build (or "make lint") succeeds without those > >> optional packages installed, but a warning is printed out that some > >> packages are missing and not all the code is checked. > >> > >> Then it is a developers responsibility to handle this and wouldn't be > >> force to install those packages for his test builds etc. > > > > How about instead it fails bny default, but prints the message "to > > suppress the lint check stopping the build, run make > > --no-fail-on-lint" so that skipping lint is a deliberate decision? > > > Yes this is the approach I prefer. OK then, I won't go against the crowd here, it's not that big deal :-) Honza, please, update the patch accordingly and I will review it. When the "make lint" fails because of missing optional package(s), I would like the missing package(s) to be printed out for the user. So that user can easily do "yum install " and finish the IPA build. Martin From mkosek at redhat.com Thu Apr 28 08:04:39 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Apr 2011 10:04:39 +0200 Subject: [Freeipa-devel] [PATCH] 049 IPA replica is not started after the reboot In-Reply-To: <1303916007.23464.123.camel@willson.li.ssimo.org> References: <1303807265.9340.3.camel@dhcp-25-52.brq.redhat.com> <1303916007.23464.123.camel@willson.li.ssimo.org> Message-ID: <1303977879.11310.5.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-27 at 10:53 -0400, Simo Sorce wrote: > On Tue, 2011-04-26 at 10:41 +0200, Martin Kosek wrote: > > https://fedorahosted.org/freeipa/ticket/1191 > > > > ACK! > > Simo. > Pushed to master, ipa-2-0. Martin From mkosek at redhat.com Thu Apr 28 08:04:49 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Apr 2011 10:04:49 +0200 Subject: [Freeipa-devel] [PATCH] 051 Improve Directory Service open port checker In-Reply-To: <1303916098.23464.124.camel@willson.li.ssimo.org> References: <1303900989.15737.0.camel@dhcp-25-52.brq.redhat.com> <1303916098.23464.124.camel@willson.li.ssimo.org> Message-ID: <1303977889.11310.6.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-27 at 10:54 -0400, Simo Sorce wrote: > On Wed, 2011-04-27 at 12:43 +0200, Martin Kosek wrote: > > Wait for DS ports to open after _every_ DS service restart. > > Several restarts were missed by the current open port checker > > implementation. > > > > https://fedorahosted.org/freeipa/ticket/1182 > > Ack > > Simo. > Pushed to master, ipa-2-0. Martin From mkosek at redhat.com Thu Apr 28 08:05:00 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Apr 2011 10:05:00 +0200 Subject: [Freeipa-devel] [PATCH] 052 Log temporary files in ipa-client-install In-Reply-To: <1303916189.23464.125.camel@willson.li.ssimo.org> References: <1303903781.15737.13.camel@dhcp-25-52.brq.redhat.com> <1303916189.23464.125.camel@willson.li.ssimo.org> Message-ID: <1303977900.11310.7.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-27 at 10:56 -0400, Simo Sorce wrote: > On Wed, 2011-04-27 at 13:29 +0200, Martin Kosek wrote: > > This patch will help investigating issues like in ticket 1100 resolved > > by my patch 50. > > > > ------ > > > > This patch adds logging of temporary files (Kerberos configuration, > > nsupdate commands) that may be very useful for debugging purposes. > > > > https://fedorahosted.org/freeipa/ticket/1093 > > https://fedorahosted.org/freeipa/ticket/1094 > > Ack, very useuful stuff, thanks! > > Simo. > Pushed to master, ipa-2-0. Martin From mkosek at redhat.com Thu Apr 28 08:23:37 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Apr 2011 10:23:37 +0200 Subject: [Freeipa-devel] [PATCH] 053 Forbid reinstallation in ipa-client-install In-Reply-To: <1303916374.23464.126.camel@willson.li.ssimo.org> References: <1303913835.15737.14.camel@dhcp-25-52.brq.redhat.com> <1303916374.23464.126.camel@willson.li.ssimo.org> Message-ID: <1303979017.11310.10.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-27 at 10:59 -0400, Simo Sorce wrote: > On Wed, 2011-04-27 at 16:17 +0200, Martin Kosek wrote: > > The --force option may be misused to reinstall an existing IPA > > client. This is not supported and may lead to unexpected errors. > > When required, the cleanest way to re-install IPA client is to > > run uninstall and then install again. > > > > This patch also includes few cosmetic changes in "LDAP" term case > > to provide more consistent experience with the script. > > > > https://fedorahosted.org/freeipa/ticket/1117 > > Code looks good, but can you add to the last message advice about > running --uninstall in case that's what the user is trying to do (a > re-install) > > Simo. > Good idea. Updated patch attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-053-2-forbid-reinstallation-in-ipa-client-install.patch Type: text/x-patch Size: 4414 bytes Desc: not available URL: From mkosek at redhat.com Thu Apr 28 08:57:57 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Apr 2011 10:57:57 +0200 Subject: [Freeipa-devel] [PATCH] 780 Handle principal not found errors when converting replication agreements In-Reply-To: <4DB834E1.1040201@redhat.com> References: <4DB834E1.1040201@redhat.com> Message-ID: <1303981077.11310.13.camel@dhcp-25-52.brq.redhat.com> On Wed, 2011-04-27 at 11:23 -0400, Rob Crittenden wrote: > There are times where one side or the other is missing its peers > krbprincipalname when converting from simple to GSSAPI replication. > Ticket 1188 should address the cause of this. > > This patch provides better information and handling should either side > be missing. > > ticket 1044 > > rob NACK. The idea is good, but there is a syntax error (missing parentheses) in the logging lines. Martin From mkosek at redhat.com Thu Apr 28 09:38:51 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Apr 2011 11:38:51 +0200 Subject: [Freeipa-devel] [PATCH] 054 Prevent uninstalling client on the IPA server Message-ID: <1303983531.11310.14.camel@dhcp-25-52.brq.redhat.com> This patch prevents uninstalling IPA client when it is configured as a part of IPA server. ipa-server-installation script is advised for this situation. https://fedorahosted.org/freeipa/ticket/1049 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-054-prevent-uninstalling-client-on-the-ipa-server.patch Type: text/x-patch Size: 1360 bytes Desc: not available URL: From rcritten at redhat.com Thu Apr 28 12:42:57 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Apr 2011 08:42:57 -0400 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <4DB857C1.9050407@redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> <4DB7F28F.8040505@redhat.com> <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> <4DB8084C.7010902@redhat.com> <4DB81B4E.1030803@redhat.com> <4DB8207D.1080603@redhat.com> <1303914276.15737.19.camel@dhcp-25-52.brq.redhat.com> <4DB8454C.4010400@redhat.com> <4DB857C1.9050407@redhat.com> Message-ID: <4DB960D1.2020408@redhat.com> Dmitri Pal wrote: > On 04/27/2011 12:33 PM, Adam Young wrote: >> On 04/27/2011 10:24 AM, Martin Kosek wrote: >>> On Wed, 2011-04-27 at 09:56 -0400, Adam Young wrote: >>>> On 04/27/2011 09:34 AM, Dmitri Pal wrote: >>>>> On 04/27/2011 08:13 AM, Jan Cholasta wrote: >>>>>> On 27.4.2011 13:17, Martin Kosek wrote: >>>>>>> On Wed, 2011-04-27 at 12:40 +0200, Jan Cholasta wrote: >>>>>>>> On 26.4.2011 18:14, Martin Kosek wrote: >>>>>>>>> On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: >>>>>>>>>> Automatically run the lint script during make >>>>>>>>>> rpms|client-rpms|srpms. >>>>>>>>>> >>>>>>>>> NACK until ticket 1184 is resolved and pushed. Currently, >>>>>>>>> pylint check >>>>>>>>> fails when optional python packages (like python-rhsm) are not >>>>>>>>> installed >>>>>>>>> on the machine. We should be able to build IPA without those >>>>>>>>> packages >>>>>>>>> installed. >>>>>>>> I think printing a note asking the developer to kindly install the >>>>>>>> missing packages would be sufficient. AFAIK there are currently >>>>>>>> only 2 >>>>>>>> optional packages: python-rhsm and python-krbV. python-krbV is >>>>>>>> optional >>>>>>>> only for the client part of IPA, so you most likely have it already >>>>>>>> installed and installing python-rhsm is not really much of a chore. >>>>>>>> That >>>>>>>> way all of the code would always be checked and the lint script >>>>>>>> would be >>>>>>>> free of the unnecessary complexity of handling missing packages. >>>>>>> I don't think this is a right approach. When the package is optional >>>>>>> (currently it may be python-rhsm and python-krbV only, but there >>>>>>> may be >>>>>>> others in the future) I shouldn't be obliged to install them in >>>>>>> order to >>>>>>> build IPA. >>>>>> You shouldn't be obliged to install them as a user. As a developer, >>>>>> you should be ready for all kinds of crazy stuff IMHO. >>>>>> >>>>>>> When somebody develops something related with the optional >>>>>>> package he has them installed and the lint will check the >>>>>>> relevant code >>>>>>> too. >>>>>> All of the code goes to the package, so it all should be checked >>>>>> during the build. >>>>>> >>>>>> Imagine situation like this: You change something in module A, >>>>>> accidentally breaking functionality that module B depends on. >>>>>> Module A >>>>>> is checked and no error is found (because it's the kind of issue that >>>>>> exhibits itself only in certain conditions). Module B isn't checked, >>>>>> because it also depends on a not-installed optional package. If it >>>>>> was >>>>>> checked, it would report an error that would lead you to the error in >>>>>> module A. But everything looks fine, so the build succeeds, even when >>>>>> the error is there. >>>>>> >>>>>> The situation might be improbable, but IMO the code should be checked >>>>>> in the same ecosystem every time anyway, because weird stuff could >>>>>> happen if it wasn't. >>>>>> >>>>>>> It is not that big deal, I just think it would be an annoyance for >>>>>>> developers. But maybe there is a different opinion. >>>>>> I know we developers are lazy folk, but this is a matter of writing >>>>>> one simple command, just one time. >>>>>> >>>>>>> Martin >>>>>>> >>>>> How about a compromise? >>>>> By default everything is expected to be installed. >>>>> But there is a command line switch that allows to skip modules you >>>>> want >>>>> to skip. You provide the switch and the list of the modules to skip >>>>> and >>>>> build will validate only modules that are not in the list. >>>>> >>>>> Will something like this work? >>>>> >>>> Actually, make the command line switch just means that a Lint failure >>>> doesn't stop the build. That way, by default the build will fail >>>> unless >>>> everything is there and checked, but there is a way to move forward for >>>> building with a subset of packages. >>> Yes, I think we will can settle with a compromise. My only concern was >>> not to force the developers to install unnecessary packages for build. >>> >>> I would suggest that the build (or "make lint") succeeds without those >>> optional packages installed, but a warning is printed out that some >>> packages are missing and not all the code is checked. >>> >>> Then it is a developers responsibility to handle this and wouldn't be >>> force to install those packages for his test builds etc. >> >> How about instead it fails bny default, but prints the message "to >> suppress the lint check stopping the build, run make >> --no-fail-on-lint" so that skipping lint is a deliberate decision? > > > Yes this is the approach I prefer. This is for developers so I'm fine being as harsh as possible. If pieces are missing then yes, we should kill the build with extreme prejudice. We can handle the client target with an argument passed to make-lint to only check certain directories of the source tree. Otherwise I don't think requiring developers to install an extra package or two is too onerous. If someone adds support for other distros and that makes it difficult then I would ease my stance. If our goal here is to prevent broken code to get into the build then lets do that. If it is painful for developers then we're on the right track. I would propose that we put it in its strictest mode possible to start with and we can see how that works and back off as necessary. rob From rcritten at redhat.com Thu Apr 28 12:53:21 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Apr 2011 08:53:21 -0400 Subject: [Freeipa-devel] [PATCH] honor --no-reverse option Message-ID: <4DB96341.9090700@redhat.com> The --no-reverse option was only working in unattended mode resulting in a reverse zone even if you requested to not create one. ticket 1152 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-770-reverse.patch Type: application/mbox Size: 1048 bytes Desc: not available URL: From mkosek at redhat.com Thu Apr 28 12:57:24 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Apr 2011 14:57:24 +0200 Subject: [Freeipa-devel] [PATCH] 055 pwpolicy-mod doesn't accept old attribute values Message-ID: <1303995444.11310.15.camel@dhcp-25-52.brq.redhat.com> When the pwpolicy attribute "cospriority" is passed to pwpolicy-mod command and the old value is kept, the command should succeed if there was at least one other attribute changed. Current pwpolicy-mod raises exception in this case which may lead to issues in the WebUI. https://fedorahosted.org/freeipa/ticket/1104 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-055-pwpolicy-mod-doesn-t-accept-old-attribute-values.patch Type: text/x-patch Size: 3610 bytes Desc: not available URL: From rcritten at redhat.com Thu Apr 28 12:58:55 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Apr 2011 08:58:55 -0400 Subject: [Freeipa-devel] [PATCH] 780 Handle principal not found errors when converting replication agreements In-Reply-To: <1303981077.11310.13.camel@dhcp-25-52.brq.redhat.com> References: <4DB834E1.1040201@redhat.com> <1303981077.11310.13.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB9648F.7090806@redhat.com> Martin Kosek wrote: > On Wed, 2011-04-27 at 11:23 -0400, Rob Crittenden wrote: >> There are times where one side or the other is missing its peers >> krbprincipalname when converting from simple to GSSAPI replication. >> Ticket 1188 should address the cause of this. >> >> This patch provides better information and handling should either side >> be missing. >> >> ticket 1044 >> >> rob > > NACK. The idea is good, but there is a syntax error (missing > parentheses) in the logging lines. > > Martin Gah, that's what I get for updating the message at the last minute. Updated patch attached, passes make-lint. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-780-2-replica.patch Type: application/mbox Size: 1538 bytes Desc: not available URL: From mkosek at redhat.com Thu Apr 28 13:12:57 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Apr 2011 15:12:57 +0200 Subject: [Freeipa-devel] [PATCH] 780 Handle principal not found errors when converting replication agreements In-Reply-To: <4DB9648F.7090806@redhat.com> References: <4DB834E1.1040201@redhat.com> <1303981077.11310.13.camel@dhcp-25-52.brq.redhat.com> <4DB9648F.7090806@redhat.com> Message-ID: <1303996377.11310.16.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-28 at 08:58 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Wed, 2011-04-27 at 11:23 -0400, Rob Crittenden wrote: > >> There are times where one side or the other is missing its peers > >> krbprincipalname when converting from simple to GSSAPI replication. > >> Ticket 1188 should address the cause of this. > >> > >> This patch provides better information and handling should either side > >> be missing. > >> > >> ticket 1044 > >> > >> rob > > > > NACK. The idea is good, but there is a syntax error (missing > > parentheses) in the logging lines. > > > > Martin > > Gah, that's what I get for updating the message at the last minute. > > Updated patch attached, passes make-lint. > > rob Yeah, we all have been there. That's where pylint comes to service :-) ACK. Pushed to master, ipa-2-0. Martin From rcritten at redhat.com Thu Apr 28 14:26:19 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Apr 2011 10:26:19 -0400 Subject: [Freeipa-devel] [PATCH] 054 Prevent uninstalling client on the IPA server In-Reply-To: <1303983531.11310.14.camel@dhcp-25-52.brq.redhat.com> References: <1303983531.11310.14.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB9790B.9070409@redhat.com> Martin Kosek wrote: > This patch prevents uninstalling IPA client when it is configured > as a part of IPA server. ipa-server-installation script is advised > for this situation. > > https://fedorahosted.org/freeipa/ticket/1049 > ack From rcritten at redhat.com Thu Apr 28 14:44:06 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Apr 2011 10:44:06 -0400 Subject: [Freeipa-devel] [PATCH] 055 pwpolicy-mod doesn't accept old attribute values In-Reply-To: <1303995444.11310.15.camel@dhcp-25-52.brq.redhat.com> References: <1303995444.11310.15.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB97D36.2080804@redhat.com> Martin Kosek wrote: > When the pwpolicy attribute "cospriority" is passed to pwpolicy-mod > command and the old value is kept, the command should succeed > if there was at least one other attribute changed. Current > pwpolicy-mod raises exception in this case which may lead to issues > in the WebUI. > > https://fedorahosted.org/freeipa/ticket/1104 ack From rcritten at redhat.com Thu Apr 28 15:22:46 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Apr 2011 11:22:46 -0400 Subject: [Freeipa-devel] [PATCH] 053 Forbid reinstallation in ipa-client-install In-Reply-To: <1303979017.11310.10.camel@dhcp-25-52.brq.redhat.com> References: <1303913835.15737.14.camel@dhcp-25-52.brq.redhat.com> <1303916374.23464.126.camel@willson.li.ssimo.org> <1303979017.11310.10.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB98646.7060604@redhat.com> Martin Kosek wrote: > On Wed, 2011-04-27 at 10:59 -0400, Simo Sorce wrote: >> On Wed, 2011-04-27 at 16:17 +0200, Martin Kosek wrote: >>> The --force option may be misused to reinstall an existing IPA >>> client. This is not supported and may lead to unexpected errors. >>> When required, the cleanest way to re-install IPA client is to >>> run uninstall and then install again. >>> >>> This patch also includes few cosmetic changes in "LDAP" term case >>> to provide more consistent experience with the script. >>> >>> https://fedorahosted.org/freeipa/ticket/1117 >> >> Code looks good, but can you add to the last message advice about >> running --uninstall in case that's what the user is trying to do (a >> re-install) >> >> Simo. >> > > Good idea. Updated patch attached. > > Martin ack From jcholast at redhat.com Thu Apr 28 16:22:37 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Apr 2011 18:22:37 +0200 Subject: [Freeipa-devel] [PATCH] 14 Run lint during each build In-Reply-To: <1303973847.11310.4.camel@dhcp-25-52.brq.redhat.com> References: <4DB6AFB6.1010503@redhat.com> <1303834459.21334.5.camel@dhcp-25-52.brq.redhat.com> <4DB7F28F.8040505@redhat.com> <1303903022.15737.10.camel@dhcp-25-52.brq.redhat.com> <4DB8084C.7010902@redhat.com> <4DB81B4E.1030803@redhat.com> <4DB8207D.1080603@redhat.com> <1303914276.15737.19.camel@dhcp-25-52.brq.redhat.com> <4DB8454C.4010400@redhat.com> <4DB857C1.9050407@redhat.com> <1303973847.11310.4.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DB9944D.4090307@redhat.com> On 28.4.2011 08:57, Martin Kosek wrote: > On Wed, 2011-04-27 at 13:52 -0400, Dmitri Pal wrote: >> On 04/27/2011 12:33 PM, Adam Young wrote: >>> On 04/27/2011 10:24 AM, Martin Kosek wrote: >>>> On Wed, 2011-04-27 at 09:56 -0400, Adam Young wrote: >>>>> On 04/27/2011 09:34 AM, Dmitri Pal wrote: >>>>>> On 04/27/2011 08:13 AM, Jan Cholasta wrote: >>>>>>> On 27.4.2011 13:17, Martin Kosek wrote: >>>>>>>> On Wed, 2011-04-27 at 12:40 +0200, Jan Cholasta wrote: >>>>>>>>> On 26.4.2011 18:14, Martin Kosek wrote: >>>>>>>>>> On Tue, 2011-04-26 at 13:42 +0200, Jan Cholasta wrote: >>>>>>>>>>> Automatically run the lint script during make >>>>>>>>>>> rpms|client-rpms|srpms. >>>>>>>>>>> >>>>>>>>>> NACK until ticket 1184 is resolved and pushed. Currently, >>>>>>>>>> pylint check >>>>>>>>>> fails when optional python packages (like python-rhsm) are not >>>>>>>>>> installed >>>>>>>>>> on the machine. We should be able to build IPA without those >>>>>>>>>> packages >>>>>>>>>> installed. >>>>>>>>> I think printing a note asking the developer to kindly install the >>>>>>>>> missing packages would be sufficient. AFAIK there are currently >>>>>>>>> only 2 >>>>>>>>> optional packages: python-rhsm and python-krbV. python-krbV is >>>>>>>>> optional >>>>>>>>> only for the client part of IPA, so you most likely have it already >>>>>>>>> installed and installing python-rhsm is not really much of a chore. >>>>>>>>> That >>>>>>>>> way all of the code would always be checked and the lint script >>>>>>>>> would be >>>>>>>>> free of the unnecessary complexity of handling missing packages. >>>>>>>> I don't think this is a right approach. When the package is optional >>>>>>>> (currently it may be python-rhsm and python-krbV only, but there >>>>>>>> may be >>>>>>>> others in the future) I shouldn't be obliged to install them in >>>>>>>> order to >>>>>>>> build IPA. >>>>>>> You shouldn't be obliged to install them as a user. As a developer, >>>>>>> you should be ready for all kinds of crazy stuff IMHO. >>>>>>> >>>>>>>> When somebody develops something related with the optional >>>>>>>> package he has them installed and the lint will check the >>>>>>>> relevant code >>>>>>>> too. >>>>>>> All of the code goes to the package, so it all should be checked >>>>>>> during the build. >>>>>>> >>>>>>> Imagine situation like this: You change something in module A, >>>>>>> accidentally breaking functionality that module B depends on. >>>>>>> Module A >>>>>>> is checked and no error is found (because it's the kind of issue that >>>>>>> exhibits itself only in certain conditions). Module B isn't checked, >>>>>>> because it also depends on a not-installed optional package. If it >>>>>>> was >>>>>>> checked, it would report an error that would lead you to the error in >>>>>>> module A. But everything looks fine, so the build succeeds, even when >>>>>>> the error is there. >>>>>>> >>>>>>> The situation might be improbable, but IMO the code should be checked >>>>>>> in the same ecosystem every time anyway, because weird stuff could >>>>>>> happen if it wasn't. >>>>>>> >>>>>>>> It is not that big deal, I just think it would be an annoyance for >>>>>>>> developers. But maybe there is a different opinion. >>>>>>> I know we developers are lazy folk, but this is a matter of writing >>>>>>> one simple command, just one time. >>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>> How about a compromise? >>>>>> By default everything is expected to be installed. >>>>>> But there is a command line switch that allows to skip modules you >>>>>> want >>>>>> to skip. You provide the switch and the list of the modules to skip >>>>>> and >>>>>> build will validate only modules that are not in the list. >>>>>> >>>>>> Will something like this work? >>>>>> >>>>> Actually, make the command line switch just means that a Lint failure >>>>> doesn't stop the build. That way, by default the build will fail >>>>> unless >>>>> everything is there and checked, but there is a way to move forward for >>>>> building with a subset of packages. >>>> Yes, I think we will can settle with a compromise. My only concern was >>>> not to force the developers to install unnecessary packages for build. >>>> >>>> I would suggest that the build (or "make lint") succeeds without those >>>> optional packages installed, but a warning is printed out that some >>>> packages are missing and not all the code is checked. >>>> >>>> Then it is a developers responsibility to handle this and wouldn't be >>>> force to install those packages for his test builds etc. >>> >>> How about instead it fails bny default, but prints the message "to >>> suppress the lint check stopping the build, run make >>> --no-fail-on-lint" so that skipping lint is a deliberate decision? >> >> >> Yes this is the approach I prefer. > > OK then, I won't go against the crowd here, it's not that big deal :-) > Honza, please, update the patch accordingly and I will review it. I've added two new variables to the makefile: DEVELOPER_MODE and LINT_OPTIONS. LINT_OPTIONS contains the command line options passed to make-lint. Setting DEVELOPER_MODE to 1 enables the developer mode, which currently just presets LINT_OPTIONS to --no-fail (it might be used for more in future), so you can build your rpms even without python-rhsm installed by invoking: make rpms DEVELOPER_MODE=1 > > When the "make lint" fails because of missing optional package(s), I > would like the missing package(s) to be printed out for the user. So > that user can easily do "yum install" and finish the IPA > build. This will be in my next patch, dealing with ticket 1184. > > Martin -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-14.1-lint-build.patch Type: text/x-patch Size: 1971 bytes Desc: not available URL: From jcholast at redhat.com Thu Apr 28 16:50:15 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 28 Apr 2011 18:50:15 +0200 Subject: [Freeipa-devel] [PATCH] 15 Report missing python packages Message-ID: <4DB99AC7.4060305@redhat.com> Improved make-lint to report missing external python packages and fixed a few little bugs in it. I'd like to ask someone (preferably a native English speaker) to go through the new error messages (at the beginning and end of make-lint) and rephrase them if necessary. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-15-lint-missing-packages.patch Type: text/x-patch Size: 5889 bytes Desc: not available URL: From mkosek at redhat.com Fri Apr 29 07:50:18 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Apr 2011 09:50:18 +0200 Subject: [Freeipa-devel] [PATCH] 054 Prevent uninstalling client on the IPA server In-Reply-To: <4DB9790B.9070409@redhat.com> References: <1303983531.11310.14.camel@dhcp-25-52.brq.redhat.com> <4DB9790B.9070409@redhat.com> Message-ID: <1304063419.22903.0.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-28 at 10:26 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > This patch prevents uninstalling IPA client when it is configured > > as a part of IPA server. ipa-server-installation script is advised > > for this situation. > > > > https://fedorahosted.org/freeipa/ticket/1049 > > > > ack Pushed to master, ipa-2-0. Martin From mkosek at redhat.com Fri Apr 29 07:50:24 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Apr 2011 09:50:24 +0200 Subject: [Freeipa-devel] [PATCH] 055 pwpolicy-mod doesn't accept old attribute values In-Reply-To: <4DB97D36.2080804@redhat.com> References: <1303995444.11310.15.camel@dhcp-25-52.brq.redhat.com> <4DB97D36.2080804@redhat.com> Message-ID: <1304063424.22903.1.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-28 at 10:44 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > When the pwpolicy attribute "cospriority" is passed to pwpolicy-mod > > command and the old value is kept, the command should succeed > > if there was at least one other attribute changed. Current > > pwpolicy-mod raises exception in this case which may lead to issues > > in the WebUI. > > > > https://fedorahosted.org/freeipa/ticket/1104 > > ack Pushed to master, ipa-2-0. Martin From mkosek at redhat.com Fri Apr 29 07:50:32 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Apr 2011 09:50:32 +0200 Subject: [Freeipa-devel] [PATCH] 053 Forbid reinstallation in ipa-client-install In-Reply-To: <4DB98646.7060604@redhat.com> References: <1303913835.15737.14.camel@dhcp-25-52.brq.redhat.com> <1303916374.23464.126.camel@willson.li.ssimo.org> <1303979017.11310.10.camel@dhcp-25-52.brq.redhat.com> <4DB98646.7060604@redhat.com> Message-ID: <1304063432.22903.2.camel@dhcp-25-52.brq.redhat.com> On Thu, 2011-04-28 at 11:22 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Wed, 2011-04-27 at 10:59 -0400, Simo Sorce wrote: > >> On Wed, 2011-04-27 at 16:17 +0200, Martin Kosek wrote: > >>> The --force option may be misused to reinstall an existing IPA > >>> client. This is not supported and may lead to unexpected errors. > >>> When required, the cleanest way to re-install IPA client is to > >>> run uninstall and then install again. > >>> > >>> This patch also includes few cosmetic changes in "LDAP" term case > >>> to provide more consistent experience with the script. > >>> > >>> https://fedorahosted.org/freeipa/ticket/1117 > >> > >> Code looks good, but can you add to the last message advice about > >> running --uninstall in case that's what the user is trying to do (a > >> re-install) > >> > >> Simo. > >> > > > > Good idea. Updated patch attached. > > > > Martin > > ack Pushed to master, ipa-2-0. Martin From jcholast at redhat.com Fri Apr 29 11:23:01 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 29 Apr 2011 13:23:01 +0200 Subject: [Freeipa-devel] [PATCH] 16 Fixes for issues found by Coverity Message-ID: <4DBA9F95.3080308@redhat.com> https://fedorahosted.org/freeipa/ticket/1166 https://fedorahosted.org/freeipa/ticket/1167 https://fedorahosted.org/freeipa/ticket/1168 https://fedorahosted.org/freeipa/ticket/1169 -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-16-coverity-fixes.patch Type: text/x-patch Size: 8665 bytes Desc: not available URL: From mkosek at redhat.com Fri Apr 29 14:28:59 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 29 Apr 2011 16:28:59 +0200 Subject: [Freeipa-devel] [PATCH] 056 ipa-client-install uninstall does not work on IPA server Message-ID: <1304087339.22903.12.camel@dhcp-25-52.brq.redhat.com> When IPA server is being uninstalled, IPA client on-master uninstallation which is called by the script fails. https://fedorahosted.org/freeipa/ticket/1197 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-056-ipa-client-install-uninstall.patch Type: text/x-patch Size: 1199 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 29 20:33:34 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 29 Apr 2011 16:33:34 -0400 Subject: [Freeipa-devel] [PATCH] 056 ipa-client-install uninstall does not work on IPA server In-Reply-To: <1304087339.22903.12.camel@dhcp-25-52.brq.redhat.com> References: <1304087339.22903.12.camel@dhcp-25-52.brq.redhat.com> Message-ID: <4DBB209E.7090709@redhat.com> Martin Kosek wrote: > When IPA server is being uninstalled, IPA client on-master > uninstallation which is called by the script fails. > > https://fedorahosted.org/freeipa/ticket/1197 ack, pushed to master and ipa-2-0 rob