From pviktori at redhat.com Thu Mar 1 09:52:09 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 01 Mar 2012 10:52:09 +0100 Subject: [Freeipa-devel] [PATCHES] 0016 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F4E4586.2070805@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F4E4586.2070805@redhat.com> Message-ID: <4F4F46C9.6030804@redhat.com> On 02/29/2012 04:34 PM, Petr Viktorin wrote: > On 02/29/2012 03:50 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> Patch 16 defers validation & conversion until after >>>>> {add,del,set}attr is >>>>> processed, so that we don't search for an integer in a list of strings >>>>> (this caused ticket #2405), and so that the end result of these >>>>> operations is validated (#2407). >>>>> >>>>> >>>>> Patch 17 makes these options honor params marked no_create and >>>>> no_update. >>>>> >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2405 >>>>> https://fedorahosted.org/freeipa/ticket/2407 >>>>> https://fedorahosted.org/freeipa/ticket/2408 >>>> >>>> NACK on Patch 17 which breaks patch 16. >>> >>> How is patch 16 broken? It works for me. >> >> My point is they rely on one another, IMHO, so without 17 the reported >> problem still exists. >> >>> >>>> *attr is specifically made to be powerful. We don't want to arbitrarily >>>> block updating certain values. >>> >>> Noted >>> >>>> Not having patch 17 means that the problem reported in 2408 still >>>> occurs. It should probably check both the schema and the param to >>>> determine if something can have multiple values and reject that way. >>> >>> I see the problem now: the certificate subject base is defined as a >>> multi-value attribute in the LDAP schema. If it's changed to >>> single-value the existing validation should catch it. >>> >>> Also, most of the config attributes should probably be required in the >>> schema. Am I right? >>> >>> I'm a newbie here; what do I need to do when changing the schema? Is >>> there a patch that does something similar I could use as an example? >>> >> >> The framework should be able to impose its own single-value will as >> well. If a Param is designated as single-value the *attr should honor it. > > Here is the updated patch. > Since *attr is powerful enough to modify 'no_update' Params, which > CRUDUpdate forgets about, I need to check the params of the LDAPObject > itself. > >> Updating schema is a bit of a nasty business right now. See >> 10-selinuxusermap.update for an example. > > I'll leave schema changes for after the release, then. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Attached patch includes tests. Note that the test depends on my patches 12-13, which make ipasearchrecordslimit required. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0016-03-Defer-conversion-and-validation-until-after-add-del-.patch Type: text/x-patch Size: 6444 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 1 10:06:25 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 01 Mar 2012 11:06:25 +0100 Subject: [Freeipa-devel] [PATCH] 226 Improve hostname verification in install tools Message-ID: <1330596385.4451.13.camel@balmora.brq.redhat.com> Our install tools like ipa-server-install, ipa-replica-{prepare, install} may allow hostnames that do not match the requirements in ipalib. This creates a disconnect and may cause issues when user cannot delete hostnames created by install tools. This patch makes sure that ipalib requirements are applied to install tools hostnames as well. https://fedorahosted.org/freeipa/ticket/2089 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-226-improve-hostname-verification-in-install-tools.patch Type: text/x-patch Size: 1860 bytes Desc: not available URL: From jcholast at redhat.com Thu Mar 1 10:09:31 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 01 Mar 2012 11:09:31 +0100 Subject: [Freeipa-devel] [PATCH] 940 apply some validation to some classes only In-Reply-To: <4F4E7266.2040208@redhat.com> References: <4F2C586A.5070804@redhat.com> <1328541277.11036.41.camel@balmora.brq.redhat.com> <4F30053A.20304@redhat.com> <1328603247.8855.6.camel@balmora.brq.redhat.com> <4F311A2E.5050009@redhat.com> <4F313202.4070200@redhat.com> <4F317A96.8000300@redhat.com> <4F3A8153.6030103@redhat.com> <4F3A82C8.9090203@redhat.com> <4F3ACF1D.2070207@redhat.com> <4F3B990A.2090903@redhat.com> <4F3BC245.7020308@redhat.com> <4F3BCCF1.9000108@redhat.com> <4F42AD9A.7030407@redhat.com> <4F42C178.9080303@redhat.com> <4F4E47E4.2010606@redhat.com> <4F4E7266.2040208@redhat.com> Message-ID: <4F4F4ADB.7010803@redhat.com> On 29.2.2012 19:45, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 20.2.2012 22:56, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> The variable name rdnattr can be misleading. It is only used to give >>>> the >>>> name of hte RDN in something that can be renamed. Compare this to >>>> something like netgroups where the DN has no visible relationship to >>>> the >>>> content of the object (ipaUniqueId). Only those objects that define >>>> rdnattr get a rename option (look at netgroups, for example). >>>> >>>> rdnattr is always the primary key but not always defined. It should >>>> probably be a boolean instead, rdn_is_primary_key or something a bit >>>> more obvious. I can make that change here. >>>> >>>> rob >>> >>> Updated patch. It seems I broke query a few months ago trying to enforce >>> no white spaces in some names. >>> >>> I did the rdnattr variable rename. Looking back at the changelog this >>> was meant to always match the primary key so lets remove the possibility >>> that it doesn't. By doing it this way we get the pattern for free. >>> >>> rob >> >> This is certainly better, but I still have a few concerns: >> >> 1. --rename is tied to the RDN change operation. I think this is wrong. >> --rename should be available for all objects, not only when the object's >> RDN attribute and primary key attribute are the same (so that we can >> change the primary key of any object). Similarly, modrdn should be >> triggered for all objects every time the RDN attribute changes, not only >> when the object's RDN attribute and primary key attribute are the same >> (so the DN is properly updated for all objects). >> >> I don't know if this is in the scope of this patch, though. > > Right, not in this scope. An entry where RDN != primary key doesn't need > --rename to do a rename, just a mod on whatever its "key" is. We can > fake this to have a consistent interface though. Please open a ticket. Well, you have to do it using --setattr, which is not very user-friendly IMO. https://fedorahosted.org/freeipa/ticket/2466 > >> >> 2. In crud.Create/crud.Update, query is set for params which have the >> ask_create/ask_update flag set. This is an error, as we are obviously >> not querying LDAP with these params (it seems someone forgot to remove >> the query=True keyword argument after copy-pasting from crud.Search). >> >> Honza >> > > Updated ACK. > > rob > Honza -- Jan Cholasta From pviktori at redhat.com Thu Mar 1 10:45:55 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 01 Mar 2012 11:45:55 +0100 Subject: [Freeipa-devel] [PATCH] 0014 Add final debug message in installers In-Reply-To: <4F4E728C.2070109@redhat.com> References: <4F44B860.9050809@redhat.com> <4F4BB48C.7010200@redhat.com> <1330535684.32367.30.camel@balmora.brq.redhat.com> <4F4E728C.2070109@redhat.com> Message-ID: <4F4F5363.4030408@redhat.com> On 02/29/2012 07:46 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On Mon, 2012-02-27 at 17:51 +0100, Petr Viktorin wrote: >>> On 02/22/2012 10:41 AM, Petr Viktorin wrote: >>>> This fixes https://fedorahosted.org/freeipa/ticket/2071 (Add final >>>> debug >>>> message in installers). The try/except blocks at the end of >>>> installers/management scripts are replaced by a call to a common >>>> function, which includes the final message. >>>> >>>> Obviously the installers still need some more love. This is as far as I >>>> got before Martin stopped me, saying I shouldn't change too much before >>>> a release :) >>>> >>>> >>>> If it's still too many changes to test, I could just wrap the blocks in >>>> some `with add_final_message` block for now, and resubmit this patch >>>> after the release. >>>> >>>> >> >> Yeah, this is exactly the kind of changes that can have yet-unseen >> consequences and I don't like pushing this close to the release. >> >> The original ticket just asks for a debug message when the install >> script ends. If possible, I would really prefer to have some low-risk >> patch adding just those and leave install script refactoring for next >> big release, like 3.x. Rob, what's your opinion on this? >> >> Martin >> > > Yes, I agree. Simpler is better at this point. > > rob This patch simply wraps the try blocks in a context that logs the final result. Most of the changes are indentation; diff with -w to see the additions. Not sure if this would count as an update or a new patch... -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0014-03-Add-final-debug-message-in-installers.patch Type: text/x-patch Size: 29969 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 1 12:19:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 01 Mar 2012 13:19:19 +0100 Subject: [Freeipa-devel] [PATCH] 227-228 Add last missing bits in new bind-dyndb-ldap Message-ID: <1330604359.4451.18.camel@balmora.brq.redhat.com> These 2 patches changes the DNS API to support the last missing bits in new bind-dyndb-ldap: 1) Both global and per-zone forwarders now support a conditional custom port (with format "IP_ADDRESS PORT") 2) Missing global configuration options have been added: * idnsforwardpolicy: Default policy for conditional forwarding * idnsallowsyncptr: Allow globaly PTR synchronization for dynamic updates * idnszonerefresh: Default interval between regular polls of the name server for new DNS zones Before these patches are pushed, I will just have to update the minimal bind-dyndb-ldap version (it has not been built yet) which have a full support for these. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-227-allow-port-numbers-for-idnsforwarders.patch Type: text/x-patch Size: 2514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-228-add-missing-global-options-in-dnsconfig.patch Type: text/x-patch Size: 4304 bytes Desc: not available URL: From ohamada at redhat.com Thu Mar 1 12:43:16 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Thu, 01 Mar 2012 13:43:16 +0100 Subject: [Freeipa-devel] [PATCH] 12 When migrating warn user if compat is enabled In-Reply-To: <4F4E4D47.4020707@redhat.com> References: <4F3CC2E9.8020305@redhat.com> <4F428894.7080002@redhat.com> <4F439CD6.2040901@redhat.com> <4F44CEF4.9070004@redhat.com> <4F4BEBE0.5070304@redhat.com> <4F4CD521.6070106@redhat.com> <4F4D4CB8.40106@redhat.com> <4F4E3CF0.2030608@redhat.com> <4F4E4D47.4020707@redhat.com> Message-ID: <4F4F6EE4.6040703@redhat.com> On 02/29/2012 05:07 PM, Rob Crittenden wrote: > Ondrej Hamada wrote: >> On 02/28/2012 10:52 PM, Rob Crittenden wrote: >>> Ondrej Hamada wrote: >>>> On 02/27/2012 09:47 PM, Rob Crittenden wrote: >>>>> Ondrej Hamada wrote: >>>>>> On 02/21/2012 02:32 PM, Ondrej Hamada wrote: >>>>>>> On 02/20/2012 06:53 PM, Rob Crittenden wrote: >>>>>>>> Ondrej Hamada wrote: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/2274 >>>>>>>>> >>>>>>>>> Added check into migration plugin to warn user when compat is >>>>>>>>> enabled. >>>>>>>>> If compat is enabled, the migration fails and user is warned >>>>>>>>> that he >>>>>>>>> must turn the compat off or run the script with (the newly >>>>>>>>> introduced) >>>>>>>>> option '--compat'. >>>>>>>>> >>>>>>>>> '--compat' is just a flag, by default set to false. If it is >>>>>>>>> set, the >>>>>>>>> compat check is skipped. >>>>>>>>> >>>>>>>> >>>>>>>> Interesting approach. I think this is probably good, preventing >>>>>>>> migration when the compat plugin is enabled unless you >>>>>>>> specifically >>>>>>>> decide to. >>>>>>>> >>>>>>>> I think the option may need another name, maybe --with-compat or >>>>>>>> something. >>>>>>>> >>>>>>>> I think in the message we should use "enabled" instead of "on". >>>>>>>> That >>>>>>>> is the language of ipa-compat-manage. >>>>>>>> >>>>>>>> The migration help should have a discussion of why this is a >>>>>>>> problem >>>>>>>> too, and what compat really is (provides a different view of the >>>>>>>> data >>>>>>>> to be compatible with non RFC2703bis systems). >>>>>>>> >>>>>>>> rob >>>>>>> corrected >>>>>>> >>>>>>> Ondra >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> I forget to update the commit message about the change of flag name. >>>>>> Corrected patch attached. >>>>>> >>>>> >>>>> This works ok it just seems to be making an assumption on the client >>>>> when to print this. I think a similar value like enabled needs to be >>>>> created to explicitly say why we are returning. >>>>> >>>>> rob >>>> sorry for that, value created >>>> >>>> Ondra >>>> >>> >>> I think you need to define beter what compat means in the output, it >>> coudl be very confusing. You can return a value for it without testing >>> whether it is actually a problem or not. >>> >>> I think what compat is supposed to mean is "Am I failing because of >>> compat" and not an indication of whether compat is enabled or not. >>> >>> Some documentation at a minimum should be added. >>> >>> It otherwise seems to work ok. >>> >>> rob >>> You could return a value for compat here without >> I've updated the description of 'compat' value in output and also >> changed the condition when this value is set to False. Now it is set to >> False only when the migration fails because of compatibility plugin. >> > > Code looks good. I think the error language needs some tweaking. > > I think the help text should read: > > The schema compat feature allows IPA to reformat data for systems that > do not support RFC2307bis. It is recommended that this be disabled > during migration to reduce system overhead. It can be re-enabled after > migration. To migrate with it enabled use the "--with-compat" option. > > I think the client-side error should read: > > The compat plug-in is enabled. This can increase the memory > requirements during migration. Disable the compat plug-in with > \'ipa-compat-manage disable\' or re-run this script with > \'--with-compat\' option." > > rob patch attached Ondra -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-12-6-Migration-warning-when-compat-enabled.patch Type: text/x-patch Size: 6889 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 1 13:10:16 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 01 Mar 2012 14:10:16 +0100 Subject: [Freeipa-devel] [PATCH] 229 Add help for new structured DNS framework Message-ID: <1330607416.4451.19.camel@balmora.brq.redhat.com> DNS Test Day shown that the new RR specific DNS options and the concepts behind them may not be easily understood. This patch adds an explanation of the new DNS framework for structured options to make it easier for the user to understand and use the new options. https://fedorahosted.org/freeipa/ticket/2382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-229-add-help-for-new-structured-dns-framework.patch Type: text/x-patch Size: 3299 bytes Desc: not available URL: From pvoborni at redhat.com Thu Mar 1 13:16:57 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 01 Mar 2012 14:16:57 +0100 Subject: [Freeipa-devel] [PATCH] 0100 Improved usability of login dialog Message-ID: <4F4F76C9.5020305@redhat.com> Usability was improved in Unauthorized/Login dialog. When the dialog is opened a link which switches to login form is focus so user can do following: 1) press enter (login form is displayed and username field is focused ) 2) type username 3) press tab 4) type password 5) press enter this sequence will execute login request. When filling form user can also press 'escape' to go back to previous form state. It's the same as if he would click on the 'back' button. https://fedorahosted.org/freeipa/ticket/2450 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0100-Improved-usability-of-login-dialog.patch Type: text/x-patch Size: 4556 bytes Desc: not available URL: From ohamada at redhat.com Thu Mar 1 13:32:33 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Thu, 01 Mar 2012 14:32:33 +0100 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <1330529763.25597.55.camel@willson.li.ssimo.org> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> Message-ID: <4F4F7A71.7060708@redhat.com> On 02/29/2012 04:36 PM, Simo Sorce wrote: > On Wed, 2012-02-29 at 16:19 +0100, Ondrej Hamada wrote: >> Hi everyone, >> I'm currently working on my thesis. It's objective is $SUBJ and we >> already have ticket for that: #194. The task is to create two more >> replica types - the HUB and Consumer. In 389-DS both the HUB and >> Consumer are read-only. Additionally the HUB can push the data to the >> Consumers. >> >> In case of FreeIPA the server is not only providing data, but also >> services like CA, NTP, DNS, Kerberos. Therefore I'm kindly asking you >> for advices and opinions on that: >> >> 1. What should be the position of HUB? >> I mean should it be used as an interconnection between Masters and >> Consumers only, so that it will be 'hidden' in the topology and only >> forwards the updates, or should the HUB be also used as a regular >> Consumer which has additional ability to push the updates further to >> Consumers/HUBS? >> > I would think that having shadow HUBs would make things more reliable. > >> 2. Which services should be available on HUB and Consumer? >> I think, the priority of these replicas would be to answer to data >> request by ipa whatever-(find|show) commands or to provide some LDAP >> data for email addressing etc. Also it shouldn't cause much trouble to >> run NTP on Consumer, but what about Kerberos or CA? Is it a good >> solution to let users authenticate against these replicas? Is it >> correct to leave classified data like passwords on these replicas? > CA's clearly have no place in a read-only replica in my mind. > > Kerberos stuff is different. The problem with a read-only replica and > Kerberos is that krb needs to write data for local user lockouts. > Password changes can be avoided by allowing kadmind only on full > masters. > > There is also another angle to consider and that is the Rad-Only Domain > Controller (RODC) available in the Microsoft world. This kind of server > is even more limited than a read-only replica as it does not contain the > full data. To do that it requires quite some tweaking on the KDC > component too, so maybe it is out of scope, but it may make sense > reading up on what they do to have a sense of the kind of services they > enable/disable on read only servers. I've read some articles about RODC and according to them, RODC is supposed to be used in branch offices where could be problem providing physical security of the machine - therefore RODC doesn't contain any passwords or confident data. The authentication requests must be forwarded to regular Domain Controller, but it is also possible to cache some credentials - usually the credentials of users that uses the RODC frequently, so that possible crack of RODC affects only this small group of users. If someone's credentials are not cached and the connection is broken between RODC and DC, he can't log in. RODC also supports read-only DNS. If the consumer should really be read-only, then the RODC way seems to be exactly what we are looking for. > Simo. > -- Regards, Ondrej Hamada FreeIPA team jabber:ohama at jabbim.cz IRC: ohamada From pspacek at redhat.com Thu Mar 1 14:22:13 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 01 Mar 2012 15:22:13 +0100 Subject: [Freeipa-devel] [PATCH] 0009 Support for IPv6 elements in idnsForwarders attribute In-Reply-To: <1330533225.32367.25.camel@balmora.brq.redhat.com> References: <4F4E31E1.7010406@redhat.com> <4F4E32AF.9050601@redhat.com> <1330529440.25597.50.camel@willson.li.ssimo.org> <4F4E47D4.3030700@redhat.com> <1330533225.32367.25.camel@balmora.brq.redhat.com> Message-ID: <4F4F8615.8020804@redhat.com> Hello, here is reworked patch for https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . Changes after yesterday's discussion on IRC with Simo and Mkosek: It follows BIND9 syntax for optional specification of port & adds documentation for this new syntax. Petr^2 Spacek On 02/29/2012 05:33 PM, Martin Kosek wrote: > I agree that we should keep the BIND syntax and separate port and IP > address with a space. We will at least avoid possible issues with IP > address decoding in the future. > > Since this is a new attribute we have a good chance to do changes now so > that it is used correctly. I created an upstream ticket to change the > behavior and validators in FreeIPA: > > https://fedorahosted.org/freeipa/ticket/2462 > > Martin > > On Wed, 2012-02-29 at 16:44 +0100, Petr Spacek wrote: >> On 02/29/2012 04:30 PM, Simo Sorce wrote: >>> Either way looks ok to me. >>> I agree that using a space may be less confusing if this syntax never >>> allows to specify multiple addresses. >>> If multiple address can be specified than it may be less ideal to use >>> spaces. >>> >>> Simo. >> >> idnsForwarders is multi-value attribute, so each value contain single >> forwarder address. >> >> Petr^2 Spacek >> >>> On Wed, 2012-02-29 at 15:14 +0100, Petr Spacek wrote: >>>> And there is the patch, sorry. >>>> >>>> Petr^2 >>>> >>>> On 02/29/2012 03:10 PM, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> this patch fixes https://fedorahosted.org/bind-dyndb-ldap/ticket/49 , >>>>> but I want to discuss one (unimplemented) change: >>>>> >>>>> I propose a change in (currently very strange) forwarders syntax. >>>>> >>>>> Current syntax: >>>>> [.port] >>>>> >>>>> examples: >>>>> 1.2.3.4 (without optional port) >>>>> 1.2.3.4.5553 (optional port 5553) >>>>> A::B (IPv6, without optional port) >>>>> A::B.5553 >>>>> ::FFFF:1.2.3.4 (6to4, without optional port) >>>>> ::FFFF:1.2.3.4.5553 (6to4, with optional port 5553) >>>>> >>>>> I find this syntax confusing, non-standard and not-typo-proof. >>>>> >>>>> >>>>> IMHO better choice is to follow BIND forwarders syntax: >>>>> [port ip_port] (port is string delimited with spaces) >>>>> >>>>> (From: http://www.zytrax.com/books/dns/ch7/queries.html#forwarders) >>>>> >>>>> >>>>> *Current syntax is not documented*, so probably is not used anywhere. >>>>> (And DNS server on non-standard port is probably useful only for testing >>>>> purposes, but it's another story.) >>>>> >>>>> >>>>> What is you opinion? -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0009-Add-support-for-IPv6-elements-in-idnsForwarders-attr.patch Type: text/x-patch Size: 8361 bytes Desc: not available URL: From jcholast at redhat.com Thu Mar 1 14:48:08 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 01 Mar 2012 15:48:08 +0100 Subject: [Freeipa-devel] [PATCH] 971 detect binary LDAP data In-Reply-To: <4F4E39EF.5080607@redhat.com> References: <4F4B96DE.60805@redhat.com> <1330357665.2718.11.camel@willson.li.ssimo.org> <4F4BA7FD.5040209@redhat.com> <4F4BAB11.3070608@redhat.com> <4F4BB316.3020500@redhat.com> <4F4C43B7.4030601@redhat.com> <4F4C91B8.4040102@redhat.com> <4F4CF689.5030808@redhat.com> <4F4D0889.1090105@redhat.com> <4F4D14FD.70402@redhat.com> <4F4D15E2.6000101@redhat.com> <4F4DEC91.603@redhat.com> <4F4E39EF.5080607@redhat.com> Message-ID: <4F4F8C28.6050607@redhat.com> On 29.2.2012 15:45, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 28.2.2012 18:58, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 28.2.2012 18:02, Petr Viktorin wrote: >>>>> On 02/28/2012 04:45 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 02/28/2012 04:02 AM, Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>>>> On 02/27/2012 05:10 PM, Rob Crittenden wrote: >>>>>>>>>> Rob Crittenden wrote: >>>>>>>>>>> Simo Sorce wrote: >>>>>>>>>>>> On Mon, 2012-02-27 at 09:44 -0500, Rob Crittenden wrote: >>>>>>>>>>>>> We are pretty trusting that the data coming out of LDAP >>>>>>>>>>>>> matches >>>>>>>>>>>>> its >>>>>>>>>>>>> schema but it is possible to stuff non-printable characters >>>>>>>>>>>>> into >>>>>>>>>>>>> most >>>>>>>>>>>>> attributes. >>>>>>>>>>>>> >>>>>>>>>>>>> I've added a sanity checker to keep a value as a python str >>>>>>>>>>>>> type >>>>>>>>>>>>> (treated as binary internally). This will result in a base64 >>>>>>>>>>>>> encoded >>>>>>>>>>>>> blob be returned to the client. >>>> >>>> I don't like the idea of having arbitrary binary data where unicode >>>> strings are expected. It might cause some unexpected errors (I have a >>>> feeling that --addattr and/or --delattr and possibly some plugins might >>>> not handle this very well). Wouldn't it be better to just throw away >>>> the >>>> value if it's invalid and warn the user? >>> >>> This isn't for user input, it is for data stored in LDAP. User's are >>> going to have no way to provide binary data to us unless they use the >>> API themselves in which case they have to follow our rules. >> >> Well my point was that --addattr and --delattr cause an LDAP search for >> the given attribute and plugins might get the result of a LDAP search in >> their post_callback and I'm not sure if they can cope with binary data. > > It wouldn't be any different than if we had the value as a unicode. Let's see what happens if the mail attribute of a user contains invalid UTF-8 (ff 62 30 72 6b 65 64): $ ipa user-find jdoe -------------- 1 user matched -------------- User login: jdoe First name: John Last name: Doe Home directory: /home/jdoe Login shell: /bin/sh Email address: /2IwcmtlZA== UID: 526 GID: 526 Account disabled: False Password: False Kerberos keys available: False ---------------------------- Number of entries returned 1 ---------------------------- $ ipa user-mod jdoe --addattr mail=jdoe at example.com ipa: ERROR: an internal error has occurred The internal error is: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 302, in wsgi_execute result = self.Command[name](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run return self.execute(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 1217, in execute ldap, dn, entry_attrs, attrs_list, *keys, **options File "/usr/lib/python2.7/site-packages/ipalib/plugins/user.py", line 532, in pre_callback entry_attrs['mail'] = self.obj._normalize_email(entry_attrs['mail']) File "/usr/lib/python2.7/site-packages/ipalib/plugins/user.py", line 338, in _normalize_email norm_email.append(m + u'@' + config['ipadefaultemaildomain'][0]) UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 0: invalid start byte $ ipa user-mod jdoe --delattr mail=/2IwcmtlZA== ipa: ERROR: mail does not contain '/2IwcmtlZA==' $ ipa user-mod jdoe --delattr mail=`echo 'ff 62 30 72 6b 65 64' | xxd -p -r` ipa: ERROR: UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 5: invalid start byte Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1242, in run sys.exit(api.Backend.cli.run(argv)) File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1024, in run kw = self.parse(cmd, argv) File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1049, in parse return dict(self.parse_iter(cmd, kw)) File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1058, in parse_iter yield (key, self.Backend.textui.decode(value)) File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 136, in decode return value.decode(encoding) File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 5: invalid start byte ipa: ERROR: an internal error has occurred I'm sure there is a lot more places in the code where things will break when you feed them arbitrary data. > > We treat the python type str as binary data. Anything that is a str gets > based64 encoded before json or xml-rpc transmission. > > The type unicode is considered a "string" and goes in the clear. > > We determine what this type should be not from the data but from the > schema. This is a big assumption. Hopefully this answer's Petr's point > as well. > > We decided long ago that str means Binary and unicode means String. It > is a bit clumsy perhaps python handles it well. It will be more clear > when we switch to Python 3.0 and we'll have bytes and str instead as types. Well, this is all super-obvious and I'm not really sure why do you bring it up here... My concern is that with your approach, you can no longer be sure that an attribute value is a valid unicode string. This creates a maintainability burden, as you *always* have to keep in mind that you first have to check whether the value is valid or not before touching it. You can easily forget to include the check in new code and there is a lot of places in old code that need to be changed because of this (as you can see in the mail example above). Let me quote John Dennis (): > I'm very interested in this work. I too have recognized that we have a > very real structural problem with how we handle the types we use > internally, especially when it corresponds to an external type and > requires conversion. In fact we do a remarkably bad job in this area, we > have conversions which are done ad hoc all over the place. There is no > well established place for the conversions to occur and it's difficult > to know at any point in the code what type to expect. Your patch adds yet another occurence of "it's difficult to know at any point in the code what type to expect". IMO this is very bad and we should not do this at all in new code. I'm not sure if just dropping bad values (as I have suggested before) is the best idea, but IMHO anything is better than letting these bad values into the bowels of IPA. > >>> We are trusting that the data in LDAP matches its schema. This is just >>> belt and suspenders verifying that it is the case. >> >> Sure, but I still think we should allow any valid unicode data to come >> from LDAP, not just what is valid in XML-RPC. > > This won't affect data coming out of LDAP, only the way it is > transmitted to the client. It will affect the data flowing through IPA, after we get it from LDAP, before it is transmitted through XML-RPC. In other words, I think it is more correct to do this: LDAP -> check unicode validity -> (rest of IPA) -> check XML-RPC validitity -> XML-RPC than this: LDAP -> check unicode validity -> check XML-RPC validity -> (rest of IPA) -> XML-RPC (Let's keep things isolated please.) > > rob Honza -- Jan Cholasta From jcholast at redhat.com Thu Mar 1 16:01:20 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 01 Mar 2012 17:01:20 +0100 Subject: [Freeipa-devel] [PATCH] 69 Configure SSH features of SSSD in ipa-client-install In-Reply-To: <1330524025.32367.5.camel@balmora.brq.redhat.com> References: <4F4CCFDD.7030302@redhat.com> <4F4D5869.6080106@redhat.com> <4F4DF579.7010307@redhat.com> <1330521888.32367.1.camel@balmora.brq.redhat.com> <4F4E2BC6.2050803@redhat.com> <1330524025.32367.5.camel@balmora.brq.redhat.com> Message-ID: <4F4F9D50.3040804@redhat.com> On 29.2.2012 15:00, Martin Kosek wrote: > On Wed, 2012-02-29 at 14:44 +0100, Jan Cholasta wrote: >> On 29.2.2012 14:24, Martin Kosek wrote: >>> On Wed, 2012-02-29 at 10:52 +0100, Jan Cholasta wrote: >>>> On 28.2.2012 23:42, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> this patch configures the new SSH features of SSSD in ipa-client-install. >>>>>> >>>>>> To test it, you need to have SSSD 1.8.0 installed. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> >>>>> Is there a better name for 'GlobalKnownHostsFile2'? >>>> >>>> What do you mean? The option name or the file name? Either way, I don't >>>> think there is a better name. >>>> >>>>> >>>>> When is PubKeyAgent used?I tried in RHEL 6.2, F-11 and F15-17 and it was >>>>> an unknown option in all. >>>> >>>> It's in openssh in RHEL 6.0. >>>> >>>>> >>>>> Should you test for the existence of /usr/bin/sss_ssh_knownhostsproxy >>>>> and /usr/bin/sss_ssh_authorizedkeys before setting it in a config file? >>>> >>>> It depends. Do we want to support clients with SSSD< 1.8.0? >>>> >>>>> >>>>> How would you recommend testing this? Enroll a client and try to log >>>>> into the IPA server? >>>> >>>> To test host authentication, you need an IPA host with SSH public keys >>>> set (which is done automatically in ipa-client-install, so any IPA host >>>> should work) and try to ssh into that host from other (actually, it can >>>> be the same) IPA host. You should not see "The authenticity of host ... >>>> can't be estabilished" ssh message. >>>> >>>> To test user authentication, you need an IPA user with SSH public keys >>>> set. To do that, you need to set the public keys using ipa user-mod. You >>>> should then be able to authenticate using your private key on any IPA host. >>>> >>>>> >>>>> rob >>>> >>>> Honza >>>> >>> >>> I get this exception when running ipa-client-install with your patch. >>> >>> # ipa-client-install --enable-dns-updates >>> Discovery was successful! >>> Hostname: vm-138.idm.lab.bos.redhat.com >>> Realm: IDM.LAB.BOS.REDHAT.COM >>> DNS Domain: idm.lab.bos.redhat.com >>> IPA Server: vm-068.idm.lab.bos.redhat.com >>> BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>> >>> >>> Continue to configure the system with these values? [no]: y >>> User authorized to enroll computers: admin >>> Synchronizing time with KDC... >>> Unable to sync time with IPA NTP server, assuming the time is in sync. >>> Password for admin at IDM.LAB.BOS.REDHAT.COM: >>> >>> Enrolled in IPA realm IDM.LAB.BOS.REDHAT.COM >>> Created /etc/ipa/default.conf >>> Traceback (most recent call last): >>> File "/usr/sbin/ipa-client-install", line 1514, in >>> sys.exit(main()) >>> File "/usr/sbin/ipa-client-install", line 1501, in main >>> rval = install(options, env, fstore, statestore) >>> File "/usr/sbin/ipa-client-install", line 1326, in install >>> if configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, >>> options): >>> File "/usr/sbin/ipa-client-install", line 711, in configure_sssd_conf >>> sssdconfig.activate_service('ssh') >>> File "/usr/lib/python2.7/site-packages/SSSDConfig.py", line 1516, in >>> activate_service >>> raise NoServiceError >>> SSSDConfig.NoServiceError >>> >>> >>> SSSD version: sssd-1.8.1-0.20120228T2018Zgit751b121.fc16.x86_64 >>> >>> Martin >>> >> >> Does your /etc/sssd/sssd.conf and /usr/share/sssd/sssd.api.conf contain >> [ssh] section? >> > > sssd.api.conf did contain the ssh section: > > # grep -C 3 ssh /usr/share/sssd/sssd.api.conf > # autofs service > autofs_negative_timeout = int, None, false > > [ssh] > # ssh service > > [provider] > #Available provider types > > > sssd.conf did not. > > > Either case, we should not crash but handle the issue in some more > friendly way. > > Martin > Patch updated with more defensive code. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-69.1-ssh-install-config-sssd.patch Type: text/x-patch Size: 4802 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 1 16:11:16 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 11:11:16 -0500 Subject: [Freeipa-devel] [PATCH] 940 apply some validation to some classes only In-Reply-To: <4F4F4ADB.7010803@redhat.com> References: <4F2C586A.5070804@redhat.com> <1328541277.11036.41.camel@balmora.brq.redhat.com> <4F30053A.20304@redhat.com> <1328603247.8855.6.camel@balmora.brq.redhat.com> <4F311A2E.5050009@redhat.com> <4F313202.4070200@redhat.com> <4F317A96.8000300@redhat.com> <4F3A8153.6030103@redhat.com> <4F3A82C8.9090203@redhat.com> <4F3ACF1D.2070207@redhat.com> <4F3B990A.2090903@redhat.com> <4F3BC245.7020308@redhat.com> <4F3BCCF1.9000108@redhat.com> <4F42AD9A.7030407@redhat.com> <4F42C178.9080303@redhat.com> <4F4E47E4.2010606@redhat.com> <4F4E7266.2040208@redhat.com> <4F4F4ADB.7010803@redhat.com> Message-ID: <4F4F9FA4.8080801@redhat.com> Jan Cholasta wrote: > On 29.2.2012 19:45, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 20.2.2012 22:56, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> The variable name rdnattr can be misleading. It is only used to give >>>>> the >>>>> name of hte RDN in something that can be renamed. Compare this to >>>>> something like netgroups where the DN has no visible relationship to >>>>> the >>>>> content of the object (ipaUniqueId). Only those objects that define >>>>> rdnattr get a rename option (look at netgroups, for example). >>>>> >>>>> rdnattr is always the primary key but not always defined. It should >>>>> probably be a boolean instead, rdn_is_primary_key or something a bit >>>>> more obvious. I can make that change here. >>>>> >>>>> rob >>>> >>>> Updated patch. It seems I broke query a few months ago trying to >>>> enforce >>>> no white spaces in some names. >>>> >>>> I did the rdnattr variable rename. Looking back at the changelog this >>>> was meant to always match the primary key so lets remove the >>>> possibility >>>> that it doesn't. By doing it this way we get the pattern for free. >>>> >>>> rob >>> >>> This is certainly better, but I still have a few concerns: >>> >>> 1. --rename is tied to the RDN change operation. I think this is wrong. >>> --rename should be available for all objects, not only when the object's >>> RDN attribute and primary key attribute are the same (so that we can >>> change the primary key of any object). Similarly, modrdn should be >>> triggered for all objects every time the RDN attribute changes, not only >>> when the object's RDN attribute and primary key attribute are the same >>> (so the DN is properly updated for all objects). >>> >>> I don't know if this is in the scope of this patch, though. >> >> Right, not in this scope. An entry where RDN != primary key doesn't need >> --rename to do a rename, just a mod on whatever its "key" is. We can >> fake this to have a consistent interface though. Please open a ticket. > > Well, you have to do it using --setattr, which is not very user-friendly > IMO. > > https://fedorahosted.org/freeipa/ticket/2466 > >> >>> >>> 2. In crud.Create/crud.Update, query is set for params which have the >>> ask_create/ask_update flag set. This is an error, as we are obviously >>> not querying LDAP with these params (it seems someone forgot to remove >>> the query=True keyword argument after copy-pasting from crud.Search). >>> >>> Honza >>> >> >> Updated > > ACK. > >> >> rob >> > > Honza > Thanks, pushed to master and ipa-2-2 rob From rcritten at redhat.com Thu Mar 1 16:20:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 11:20:53 -0500 Subject: [Freeipa-devel] [PATCH] 226 Improve hostname verification in install tools In-Reply-To: <1330596385.4451.13.camel@balmora.brq.redhat.com> References: <1330596385.4451.13.camel@balmora.brq.redhat.com> Message-ID: <4F4FA1E5.1090302@redhat.com> Martin Kosek wrote: > Our install tools like ipa-server-install, ipa-replica-{prepare, > install} may allow hostnames that do not match the requirements > in ipalib. This creates a disconnect and may cause issues when > user cannot delete hostnames created by install tools. > > This patch makes sure that ipalib requirements are applied to > install tools hostnames as well. > > https://fedorahosted.org/freeipa/ticket/2089 ACK From rcritten at redhat.com Thu Mar 1 16:39:37 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 11:39:37 -0500 Subject: [Freeipa-devel] [PATCH] 12 When migrating warn user if compat is enabled In-Reply-To: <4F4F6EE4.6040703@redhat.com> References: <4F3CC2E9.8020305@redhat.com> <4F428894.7080002@redhat.com> <4F439CD6.2040901@redhat.com> <4F44CEF4.9070004@redhat.com> <4F4BEBE0.5070304@redhat.com> <4F4CD521.6070106@redhat.com> <4F4D4CB8.40106@redhat.com> <4F4E3CF0.2030608@redhat.com> <4F4E4D47.4020707@redhat.com> <4F4F6EE4.6040703@redhat.com> Message-ID: <4F4FA649.1070309@redhat.com> Ondrej Hamada wrote: > On 02/29/2012 05:07 PM, Rob Crittenden wrote: >> Ondrej Hamada wrote: >>> On 02/28/2012 10:52 PM, Rob Crittenden wrote: >>>> Ondrej Hamada wrote: >>>>> On 02/27/2012 09:47 PM, Rob Crittenden wrote: >>>>>> Ondrej Hamada wrote: >>>>>>> On 02/21/2012 02:32 PM, Ondrej Hamada wrote: >>>>>>>> On 02/20/2012 06:53 PM, Rob Crittenden wrote: >>>>>>>>> Ondrej Hamada wrote: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2274 >>>>>>>>>> >>>>>>>>>> Added check into migration plugin to warn user when compat is >>>>>>>>>> enabled. >>>>>>>>>> If compat is enabled, the migration fails and user is warned >>>>>>>>>> that he >>>>>>>>>> must turn the compat off or run the script with (the newly >>>>>>>>>> introduced) >>>>>>>>>> option '--compat'. >>>>>>>>>> >>>>>>>>>> '--compat' is just a flag, by default set to false. If it is >>>>>>>>>> set, the >>>>>>>>>> compat check is skipped. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Interesting approach. I think this is probably good, preventing >>>>>>>>> migration when the compat plugin is enabled unless you >>>>>>>>> specifically >>>>>>>>> decide to. >>>>>>>>> >>>>>>>>> I think the option may need another name, maybe --with-compat or >>>>>>>>> something. >>>>>>>>> >>>>>>>>> I think in the message we should use "enabled" instead of "on". >>>>>>>>> That >>>>>>>>> is the language of ipa-compat-manage. >>>>>>>>> >>>>>>>>> The migration help should have a discussion of why this is a >>>>>>>>> problem >>>>>>>>> too, and what compat really is (provides a different view of the >>>>>>>>> data >>>>>>>>> to be compatible with non RFC2703bis systems). >>>>>>>>> >>>>>>>>> rob >>>>>>>> corrected >>>>>>>> >>>>>>>> Ondra >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> I forget to update the commit message about the change of flag name. >>>>>>> Corrected patch attached. >>>>>>> >>>>>> >>>>>> This works ok it just seems to be making an assumption on the client >>>>>> when to print this. I think a similar value like enabled needs to be >>>>>> created to explicitly say why we are returning. >>>>>> >>>>>> rob >>>>> sorry for that, value created >>>>> >>>>> Ondra >>>>> >>>> >>>> I think you need to define beter what compat means in the output, it >>>> coudl be very confusing. You can return a value for it without testing >>>> whether it is actually a problem or not. >>>> >>>> I think what compat is supposed to mean is "Am I failing because of >>>> compat" and not an indication of whether compat is enabled or not. >>>> >>>> Some documentation at a minimum should be added. >>>> >>>> It otherwise seems to work ok. >>>> >>>> rob >>>> You could return a value for compat here without >>> I've updated the description of 'compat' value in output and also >>> changed the condition when this value is set to False. Now it is set to >>> False only when the migration fails because of compatibility plugin. >>> >> >> Code looks good. I think the error language needs some tweaking. >> >> I think the help text should read: >> >> The schema compat feature allows IPA to reformat data for systems that >> do not support RFC2307bis. It is recommended that this be disabled >> during migration to reduce system overhead. It can be re-enabled after >> migration. To migrate with it enabled use the "--with-compat" option. >> >> I think the client-side error should read: >> >> The compat plug-in is enabled. This can increase the memory >> requirements during migration. Disable the compat plug-in with >> \'ipa-compat-manage disable\' or re-run this script with >> \'--with-compat\' option." >> >> rob > patch attached > > Ondra > ACK, pushed to master and ipa-2-2 From jcholast at redhat.com Thu Mar 1 17:44:40 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 01 Mar 2012 18:44:40 +0100 Subject: [Freeipa-devel] [PATCH] 976 add tests for HTTP_Status In-Reply-To: <4F4E9733.4080100@redhat.com> References: <4F4E9733.4080100@redhat.com> Message-ID: <4F4FB588.4080807@redhat.com> On 29.2.2012 22:22, Rob Crittenden wrote: > The tests for not_found were broken, this fixes it and adds tests for > the other statuses. > > I changed the parent class of HTTP_Status because it calls self.info > which is provided by Plugable. This wasn't a problem at runtime because > Backend provides self.log. > > rob > ACK. Honza -- Jan Cholasta From pspacek at redhat.com Thu Mar 1 18:55:33 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 01 Mar 2012 19:55:33 +0100 Subject: [Freeipa-devel] [PATCH] 0009 Support for IPv6 elements in idnsForwarders attribute In-Reply-To: <4F4F8615.8020804@redhat.com> References: <4F4E31E1.7010406@redhat.com> <4F4E32AF.9050601@redhat.com> <1330529440.25597.50.camel@willson.li.ssimo.org> <4F4E47D4.3030700@redhat.com> <1330533225.32367.25.camel@balmora.brq.redhat.com> <4F4F8615.8020804@redhat.com> Message-ID: <4F4FC625.3000108@redhat.com> Hello, here is (again) reworked patch for https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . Adam pointed me to existing BIND parser, which I missed. Now is all parsing & socket magic done inside BIND libraries. Our code is a bit shorter and syntax is 100% BIND-compatible. (But it means same as discussed yesterday :-) Adam, please review it. Thanks. Petr^2 Spacek On 03/01/2012 03:22 PM, Petr Spacek wrote: > Hello, > > here is reworked patch for > https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . > > Changes after yesterday's discussion on IRC with Simo and Mkosek: > It follows BIND9 syntax for optional specification of port & adds > documentation for this new syntax. > > Petr^2 Spacek > > On 02/29/2012 05:33 PM, Martin Kosek wrote: >> I agree that we should keep the BIND syntax and separate port and IP >> address with a space. We will at least avoid possible issues with IP >> address decoding in the future. >> >> Since this is a new attribute we have a good chance to do changes now so >> that it is used correctly. I created an upstream ticket to change the >> behavior and validators in FreeIPA: >> >> https://fedorahosted.org/freeipa/ticket/2462 >> >> Martin >> >> On Wed, 2012-02-29 at 16:44 +0100, Petr Spacek wrote: >>> On 02/29/2012 04:30 PM, Simo Sorce wrote: >>>> Either way looks ok to me. >>>> I agree that using a space may be less confusing if this syntax never >>>> allows to specify multiple addresses. >>>> If multiple address can be specified than it may be less ideal to use >>>> spaces. >>>> >>>> Simo. >>> >>> idnsForwarders is multi-value attribute, so each value contain single >>> forwarder address. >>> >>> Petr^2 Spacek >>> >>>> On Wed, 2012-02-29 at 15:14 +0100, Petr Spacek wrote: >>>>> And there is the patch, sorry. >>>>> >>>>> Petr^2 >>>>> >>>>> On 02/29/2012 03:10 PM, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> this patch fixes https://fedorahosted.org/bind-dyndb-ldap/ticket/49 , >>>>>> but I want to discuss one (unimplemented) change: >>>>>> >>>>>> I propose a change in (currently very strange) forwarders syntax. >>>>>> >>>>>> Current syntax: >>>>>> [.port] >>>>>> >>>>>> examples: >>>>>> 1.2.3.4 (without optional port) >>>>>> 1.2.3.4.5553 (optional port 5553) >>>>>> A::B (IPv6, without optional port) >>>>>> A::B.5553 >>>>>> ::FFFF:1.2.3.4 (6to4, without optional port) >>>>>> ::FFFF:1.2.3.4.5553 (6to4, with optional port 5553) >>>>>> >>>>>> I find this syntax confusing, non-standard and not-typo-proof. >>>>>> >>>>>> >>>>>> IMHO better choice is to follow BIND forwarders syntax: >>>>>> [port ip_port] (port is string delimited with spaces) >>>>>> >>>>>> (From: http://www.zytrax.com/books/dns/ch7/queries.html#forwarders) >>>>>> >>>>>> >>>>>> *Current syntax is not documented*, so probably is not used anywhere. >>>>>> (And DNS server on non-standard port is probably useful only for >>>>>> testing >>>>>> purposes, but it's another story.) >>>>>> >>>>>> >>>>>> What is you opinion? -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0009-Add-support-for-IPv6-elements-in-idnsForwarders-attr.patch Type: text/x-patch Size: 10121 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 1 19:06:46 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 14:06:46 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F4E2AC7.6030107@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> <4F14F131.3080503@redhat.com> <4F4E2AC7.6030107@redhat.com> Message-ID: <4F4FC8C6.2000103@redhat.com> Jan Cholasta wrote: > On 17.1.2012 04:55, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): >>>> Jan Cholasta wrote: >>>>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >>>>>> Jan Cholasta wrote: >>>>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>>>>>> Jan Cholasta wrote: >>>>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and >>>>>>>>>> sudoNotAfter >>>>>>>>>> but these weren't available in the sudorule plugin. >>>>>>>>>> >>>>>>>>>> I've added support for these. sudoOrder enforces uniqueness >>>>>>>>>> because >>>>>>>>>> duplicates are undefined. >>>>>>>>>> >>>>>>>>>> I also added support for a GeneralizedTime parameter type. >>>>>>>>>> This is >>>>>>>>>> similar to the existing AccessTime parameter but it only >>>>>>>>>> handles a >>>>>>>>>> single time value. >>>>>>>>> >>>>>>>>> You should parse the date/time part of the value with >>>>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it >>>>>>>>> manually, >>>>>>>>> that way you'll get most of the validation for free. >>>>>>>> >>>>>>>> Yes but it gives a crappy error message, just saying that some >>>>>>>> data is >>>>>>>> left over not what is wrong. >>>>>>> >>>>>>> IMHO having a separate error message for every field in the time >>>>>>> string >>>>>>> (like you do in the patch) is an overkill, simple "invalid time" >>>>>>> and/or >>>>>>> "unknown time format" should suffice (we don't have errors like >>>>>>> "invalid >>>>>>> 3rd octet" for IP adresses either). >>>>>> >>>>>> Well, the work is done, hard to go back on a better error message. >>>>>> >>>>>>>> >>>>>>>>> Also, it would be nice to be able to enter the value in more >>>>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and >>>>>>>>> normalize >>>>>>>>> that to LDAP generalized time. >>>>>>>> >>>>>>>> When dealing with time there are so many ways to input and display >>>>>>>> the >>>>>>>> same values this becomes difficult. >>>>>>>> >>>>>>>> I'd expect that the times for these two attributes will be >>>>>>>> relatively >>>>>>>> simple and I somehow doubt users are going to want seconds, leap >>>>>>>> seconds >>>>>>>> or fractions, but we'll need to consider how to do it for future >>>>>>>> consistency (otherwise we could have a case where time is >>>>>>>> entered in >>>>>>>> one >>>>>>>> format for some attributes and another for others). >>>>>>>> >>>>>>>> If we input in a nice way we need to output in the same way. >>>>>>> >>>>>>> We could make the preferred input/output time format >>>>>>> user-configurable, >>>>>>> defaulting to current locale time format. This format would be used >>>>>>> for >>>>>>> output. For input, we could go over a list of formats (first the >>>>>>> user-configured format, then current locale format, then a >>>>>>> handful of >>>>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first >>>>>>> format >>>>>>> that can be successfully used to parse the time string. >>>>>> >>>>>> See how far you get into the rabbit hole with even this simple >>>>>> format? >>>>> >>>>> I don't mind, as long as it is the right thing to do (IMHO) :) >>>>> >>>>> Anyway, I think this could be done on the client side, so we might use >>>>> your patch without changes. However, I would prefer if the parameter >>>>> class was more generic, so we could use it (hypothetically) to store >>>>> time in some other way than LDAP generalized time attribute (at least >>>>> name it DateTime please). >>>>> >>>> >>>> Ok, I'm fine with that. >>> >>> Thanks. >>> >>>> >>>>>> >>>>>> The LDAP GeneralizedTime needs to be either in GMT or include a >>>>>> differential. This gets us into the territory where the client >>>>>> could be >>>>>> in a different timezone than the server which leads us to why we >>>>>> dropped >>>>>> AccessTime in the first place. >>>>> >>>>> Speaking of time zones, the differential alone is not a sufficient >>>>> time >>>>> zone description, as it doesn't account for DST. Is there a way to >>>>> store >>>>> time in LDAP with full time zone name (just in case it's needed >>>>> sometime >>>>> in future)? >>>> >>>> There is no way to store DST in LDAP (probably for good reason). Oddly >>>> enough the older LDAP v3 RFC (2252) strongly recommends using only GMT >>>> but the RFC that obsoletes it (4517) does not include this. >>> >>> Thanks for the info. >>> >>>> >>>>> >>>>>> So I'd like the user to supply the >>>>>> timezone themselves so I don't have to guess (wrongly) and let them >>>>>> worry about differing timezones. >>>>> >>>>> We don't have to guess, IIRC there is a way to get the local timezone >>>>> differential in both Python and JavaScript, so the client could supply >>>>> it automatically if necessary. >>>> >>>> I was thinking more about non-IPA clients (like sudo and notBefore). >>> >>> I think this can still be done at least in CLI, but it could be done in >>> a separate patch. >>> >>>> >>>> Updated patches attached. >>>> >>>> rob >>> >>> Patch 919 doesn't cleanly apply on current master (neither does 916 >>> BTW). >>> >>> Honza >>> >> >> Rebased patch (and 916 too, separately). >> >> rob > > Patch 918: > > 1. LDAP generalized time allows you to omit minutes from time zone > differential, your code treats such values as invalid > > 2. IMO a better pattern could be used, such as > u'^([0-9]{2}){5,7}([.,][0-9]+)?([-+]([0-9]{2}){1,2}|Z)$' > > 3. 20120229000Z has malformed minutes, but the error message says > "Malformed seconds" > > 4. 20120229000+0000 has malformed minutes, but the error message says > "Missing operator for differential or malformed time string" > > 5. 201202290000+0000 is valid generalized time, but it causes "Missing > operator for differential or malformed time string" error > > 6. Invalid month/day combinations (such as 201202310000Z) are treated as > valid > > 7. When + or - is missing, the error message says "Missing operator ..." > - IMO a better term than "operator" is "sign" in this case > > 8. The DateTime docstring includes grammar definition for MINUS, but not > for PLUS, DOT or COMMA. > > 9. I'm not too fond of the _rule_required hack. Can't the same thing be > done in _validate_scalar? > > 10. pattern_errmsg should say "Must be of the form YYYYMMDDHH[MM]Z or > YYYYMMDDHH[MM]{+|-}HHMM" > > There might be more bugs in validation that I didn't discover. I would > suggest you to use a more pythonic approach for the validation code > (e.g. use partition() to split the time zone and fraction from the rest > of the value, etc.), the current code is rather C-ish, hard to read and > apparently error-prone. > > > Patch 919: > > 1. sudoorder uniqueness is not properly checked in ipa sudorule-mod: > > $ ipa sudorule-add rule1 > ----------------------- > Added Sudo Rule "rule1" > ----------------------- > Rule name: rule1 > Enabled: TRUE > > $ ipa sudorule-add rule2 --order=0 > ----------------------- > Added Sudo Rule "rule2" > ----------------------- > Rule name: rule2 > Enabled: TRUE > Sudo order: 0 > > $ ipa sudorule-add rule3 --order=0 > ipa: ERROR: invalid 'order': order must be a unique value (0 already > used by rule2) > > $ ipa sudorule-mod rule1 --order=0 > -------------------------- > Modified Sudo Rule "rule1" > -------------------------- > Rule name: rule1 > Enabled: TRUE > Sudo order: 0 > > (now both rule1 and rule2 have sudoorder=0) > > 2. Shouldn't we check that sudonotbefore <= sudonotafter? > > 3. sudonotbefore param doc should say "Start of time interval for which > the entry is valid (YYYYMMDDHH[MM]Z)" > > 4. sudonotafter param doc should say "End of time interval for which the > entry is valid (YYYYMMDDHH[MM]Z)" > > 5. In 60ipasudo.ldif, the ipaSudoRule object class is missing the > sudoOrder, sudoNotBefore and sudoNotAfter attributes. Is this OK? > > > Both patches need to be rebased. > > Honza > Ok, lets take this one step at a time. This updated patch adds schema for all three attributes but just a Param for sudoOrder. I'll have to revisit DateTime for notbefore and notafter. I addressed the issue with order and added a test for it. Schema is fixed on new installs. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-919-3-sudo.patch Type: text/x-diff Size: 10621 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 1 19:12:27 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 14:12:27 -0500 Subject: [Freeipa-devel] [PATCH] 976 add tests for HTTP_Status In-Reply-To: <4F4FB588.4080807@redhat.com> References: <4F4E9733.4080100@redhat.com> <4F4FB588.4080807@redhat.com> Message-ID: <4F4FCA1B.6000407@redhat.com> Jan Cholasta wrote: > On 29.2.2012 22:22, Rob Crittenden wrote: >> The tests for not_found were broken, this fixes it and adds tests for >> the other statuses. >> >> I changed the parent class of HTTP_Status because it calls self.info >> which is provided by Plugable. This wasn't a problem at runtime because >> Backend provides self.log. >> >> rob >> > > ACK. > > Honza > Pushed to master and ipa-2-2 rob From rcritten at redhat.com Thu Mar 1 19:38:10 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 14:38:10 -0500 Subject: [Freeipa-devel] [PATCH] 226 Improve hostname verification in install tools In-Reply-To: <4F4FA1E5.1090302@redhat.com> References: <1330596385.4451.13.camel@balmora.brq.redhat.com> <4F4FA1E5.1090302@redhat.com> Message-ID: <4F4FD022.20703@redhat.com> Rob Crittenden wrote: > Martin Kosek wrote: >> Our install tools like ipa-server-install, ipa-replica-{prepare, >> install} may allow hostnames that do not match the requirements >> in ipalib. This creates a disconnect and may cause issues when >> user cannot delete hostnames created by install tools. >> >> This patch makes sure that ipalib requirements are applied to >> install tools hostnames as well. >> >> https://fedorahosted.org/freeipa/ticket/2089 > > ACK pushed to master and ipa-2-2 From rcritten at redhat.com Thu Mar 1 19:57:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 14:57:20 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F4FC8C6.2000103@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> <4F14F131.3080503@redhat.com> <4F4E2AC7.6030107@redhat.com> <4F4FC8C6.2000103@redhat.com> Message-ID: <4F4FD4A0.5020105@redhat.com> Rob Crittenden wrote: > Jan Cholasta wrote: >> On 17.1.2012 04:55, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): >>>>> Jan Cholasta wrote: >>>>>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >>>>>>> Jan Cholasta wrote: >>>>>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>>>>>>> Jan Cholasta wrote: >>>>>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and >>>>>>>>>>> sudoNotAfter >>>>>>>>>>> but these weren't available in the sudorule plugin. >>>>>>>>>>> >>>>>>>>>>> I've added support for these. sudoOrder enforces uniqueness >>>>>>>>>>> because >>>>>>>>>>> duplicates are undefined. >>>>>>>>>>> >>>>>>>>>>> I also added support for a GeneralizedTime parameter type. >>>>>>>>>>> This is >>>>>>>>>>> similar to the existing AccessTime parameter but it only >>>>>>>>>>> handles a >>>>>>>>>>> single time value. >>>>>>>>>> >>>>>>>>>> You should parse the date/time part of the value with >>>>>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it >>>>>>>>>> manually, >>>>>>>>>> that way you'll get most of the validation for free. >>>>>>>>> >>>>>>>>> Yes but it gives a crappy error message, just saying that some >>>>>>>>> data is >>>>>>>>> left over not what is wrong. >>>>>>>> >>>>>>>> IMHO having a separate error message for every field in the time >>>>>>>> string >>>>>>>> (like you do in the patch) is an overkill, simple "invalid time" >>>>>>>> and/or >>>>>>>> "unknown time format" should suffice (we don't have errors like >>>>>>>> "invalid >>>>>>>> 3rd octet" for IP adresses either). >>>>>>> >>>>>>> Well, the work is done, hard to go back on a better error message. >>>>>>> >>>>>>>>> >>>>>>>>>> Also, it would be nice to be able to enter the value in more >>>>>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and >>>>>>>>>> normalize >>>>>>>>>> that to LDAP generalized time. >>>>>>>>> >>>>>>>>> When dealing with time there are so many ways to input and display >>>>>>>>> the >>>>>>>>> same values this becomes difficult. >>>>>>>>> >>>>>>>>> I'd expect that the times for these two attributes will be >>>>>>>>> relatively >>>>>>>>> simple and I somehow doubt users are going to want seconds, leap >>>>>>>>> seconds >>>>>>>>> or fractions, but we'll need to consider how to do it for future >>>>>>>>> consistency (otherwise we could have a case where time is >>>>>>>>> entered in >>>>>>>>> one >>>>>>>>> format for some attributes and another for others). >>>>>>>>> >>>>>>>>> If we input in a nice way we need to output in the same way. >>>>>>>> >>>>>>>> We could make the preferred input/output time format >>>>>>>> user-configurable, >>>>>>>> defaulting to current locale time format. This format would be used >>>>>>>> for >>>>>>>> output. For input, we could go over a list of formats (first the >>>>>>>> user-configured format, then current locale format, then a >>>>>>>> handful of >>>>>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first >>>>>>>> format >>>>>>>> that can be successfully used to parse the time string. >>>>>>> >>>>>>> See how far you get into the rabbit hole with even this simple >>>>>>> format? >>>>>> >>>>>> I don't mind, as long as it is the right thing to do (IMHO) :) >>>>>> >>>>>> Anyway, I think this could be done on the client side, so we might >>>>>> use >>>>>> your patch without changes. However, I would prefer if the parameter >>>>>> class was more generic, so we could use it (hypothetically) to store >>>>>> time in some other way than LDAP generalized time attribute (at least >>>>>> name it DateTime please). >>>>>> >>>>> >>>>> Ok, I'm fine with that. >>>> >>>> Thanks. >>>> >>>>> >>>>>>> >>>>>>> The LDAP GeneralizedTime needs to be either in GMT or include a >>>>>>> differential. This gets us into the territory where the client >>>>>>> could be >>>>>>> in a different timezone than the server which leads us to why we >>>>>>> dropped >>>>>>> AccessTime in the first place. >>>>>> >>>>>> Speaking of time zones, the differential alone is not a sufficient >>>>>> time >>>>>> zone description, as it doesn't account for DST. Is there a way to >>>>>> store >>>>>> time in LDAP with full time zone name (just in case it's needed >>>>>> sometime >>>>>> in future)? >>>>> >>>>> There is no way to store DST in LDAP (probably for good reason). Oddly >>>>> enough the older LDAP v3 RFC (2252) strongly recommends using only GMT >>>>> but the RFC that obsoletes it (4517) does not include this. >>>> >>>> Thanks for the info. >>>> >>>>> >>>>>> >>>>>>> So I'd like the user to supply the >>>>>>> timezone themselves so I don't have to guess (wrongly) and let them >>>>>>> worry about differing timezones. >>>>>> >>>>>> We don't have to guess, IIRC there is a way to get the local timezone >>>>>> differential in both Python and JavaScript, so the client could >>>>>> supply >>>>>> it automatically if necessary. >>>>> >>>>> I was thinking more about non-IPA clients (like sudo and notBefore). >>>> >>>> I think this can still be done at least in CLI, but it could be done in >>>> a separate patch. >>>> >>>>> >>>>> Updated patches attached. >>>>> >>>>> rob >>>> >>>> Patch 919 doesn't cleanly apply on current master (neither does 916 >>>> BTW). >>>> >>>> Honza >>>> >>> >>> Rebased patch (and 916 too, separately). >>> >>> rob >> >> Patch 918: >> >> 1. LDAP generalized time allows you to omit minutes from time zone >> differential, your code treats such values as invalid >> >> 2. IMO a better pattern could be used, such as >> u'^([0-9]{2}){5,7}([.,][0-9]+)?([-+]([0-9]{2}){1,2}|Z)$' >> >> 3. 20120229000Z has malformed minutes, but the error message says >> "Malformed seconds" >> >> 4. 20120229000+0000 has malformed minutes, but the error message says >> "Missing operator for differential or malformed time string" >> >> 5. 201202290000+0000 is valid generalized time, but it causes "Missing >> operator for differential or malformed time string" error >> >> 6. Invalid month/day combinations (such as 201202310000Z) are treated as >> valid >> >> 7. When + or - is missing, the error message says "Missing operator ..." >> - IMO a better term than "operator" is "sign" in this case >> >> 8. The DateTime docstring includes grammar definition for MINUS, but not >> for PLUS, DOT or COMMA. >> >> 9. I'm not too fond of the _rule_required hack. Can't the same thing be >> done in _validate_scalar? >> >> 10. pattern_errmsg should say "Must be of the form YYYYMMDDHH[MM]Z or >> YYYYMMDDHH[MM]{+|-}HHMM" >> >> There might be more bugs in validation that I didn't discover. I would >> suggest you to use a more pythonic approach for the validation code >> (e.g. use partition() to split the time zone and fraction from the rest >> of the value, etc.), the current code is rather C-ish, hard to read and >> apparently error-prone. >> >> >> Patch 919: >> >> 1. sudoorder uniqueness is not properly checked in ipa sudorule-mod: >> >> $ ipa sudorule-add rule1 >> ----------------------- >> Added Sudo Rule "rule1" >> ----------------------- >> Rule name: rule1 >> Enabled: TRUE >> >> $ ipa sudorule-add rule2 --order=0 >> ----------------------- >> Added Sudo Rule "rule2" >> ----------------------- >> Rule name: rule2 >> Enabled: TRUE >> Sudo order: 0 >> >> $ ipa sudorule-add rule3 --order=0 >> ipa: ERROR: invalid 'order': order must be a unique value (0 already >> used by rule2) >> >> $ ipa sudorule-mod rule1 --order=0 >> -------------------------- >> Modified Sudo Rule "rule1" >> -------------------------- >> Rule name: rule1 >> Enabled: TRUE >> Sudo order: 0 >> >> (now both rule1 and rule2 have sudoorder=0) >> >> 2. Shouldn't we check that sudonotbefore <= sudonotafter? >> >> 3. sudonotbefore param doc should say "Start of time interval for which >> the entry is valid (YYYYMMDDHH[MM]Z)" >> >> 4. sudonotafter param doc should say "End of time interval for which the >> entry is valid (YYYYMMDDHH[MM]Z)" >> >> 5. In 60ipasudo.ldif, the ipaSudoRule object class is missing the >> sudoOrder, sudoNotBefore and sudoNotAfter attributes. Is this OK? >> >> >> Both patches need to be rebased. >> >> Honza >> > > Ok, lets take this one step at a time. > > This updated patch adds schema for all three attributes but just a Param > for sudoOrder. I'll have to revisit DateTime for notbefore and notafter. > > I addressed the issue with order and added a test for it. > > Schema is fixed on new installs. > > rob And now with updated API.txt. Forgot to squash the commit. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-919-4-sudo.patch Type: text/x-diff Size: 15004 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 1 21:26:04 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 16:26:04 -0500 Subject: [Freeipa-devel] [PATCH] 956 user lockout status In-Reply-To: <1330518873.10228.20.camel@balmora.brq.redhat.com> References: <4F440556.7090006@redhat.com> <1329863296.18690.43.camel@willson.li.ssimo.org> <4F441DAD.3020503@redhat.com> <1330363878.2925.18.camel@balmora.brq.redhat.com> <4F4DFBF2.8090108@redhat.com> <1330518873.10228.20.camel@balmora.brq.redhat.com> Message-ID: <4F4FE96C.7020405@redhat.com> Martin Kosek wrote: > On Wed, 2012-02-29 at 11:20 +0100, Petr Viktorin wrote: >> On 02/27/2012 06:31 PM, Martin Kosek wrote: >>> >>> 4) Minor change: >>> - except Exception: >>> + except: >>> >> >> Don't do that. It would for example disable Ctrl+C by trapping >> KeyboardInterrupt. >> >> PEP8 has a paragraph on this, search for 'except Exception:' >> >> > > Good to know, thanks. Rob, in that case please ignore issue #4. > > Martin Updated patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-956-2-status.patch Type: text/x-diff Size: 2199 bytes Desc: not available URL: From simo at redhat.com Thu Mar 1 22:33:42 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Mar 2012 17:33:42 -0500 Subject: [Freeipa-devel] [PATCH] 484 Fix credentials checks with s4u2proxy delegation Message-ID: <1330641222.25597.157.camel@willson.li.ssimo.org> The commit message says it all I think. This is critical for 2.2 and master. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-484-1-Fix-ticket-checks-when-using-either-s4u2proxy-or-a-d.patch Type: text/x-patch Size: 2413 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 1 23:05:00 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 18:05:00 -0500 Subject: [Freeipa-devel] [PATCH] 484 Fix credentials checks with s4u2proxy delegation In-Reply-To: <1330641222.25597.157.camel@willson.li.ssimo.org> References: <1330641222.25597.157.camel@willson.li.ssimo.org> Message-ID: <4F50009C.6010606@redhat.com> Simo Sorce wrote: > The commit message says it all I think. > > This is critical for 2.2 and master. > > Simo. ACK. Tested with patch krb 1.9 on F-16. Pushed to master and ipa-2-2 rob From rcritten at redhat.com Thu Mar 1 23:39:01 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 18:39:01 -0500 Subject: [Freeipa-devel] [PATCH] 098 Forms based authentication UI In-Reply-To: <4F4E3F1E.6090205@redhat.com> References: <4F4E3F1E.6090205@redhat.com> Message-ID: <4F500895.3060701@redhat.com> Petr Vobornik wrote: > Support for forms based authentication was added to UI. > > It consist of: > > 1) new login page > Page url is [ipa server]/ipa/ui/login.html > > Page contains a login form. For authentication it sends ajax request at > [ipa server]/session/json/login_password. If authentication is > successfull page is redirected to [ipa server]/ipa/ui if it fails from > whatever reason a message is shown. > > 2) new enhanced error dialog - authorization_dialog. > > This dialog is displayed when user is not authorized to perform action - > usually when ticket and session expires. > It is a standard error dialog which shows kerberos ticket related error > message and newly offers (as a link) to use form based authentication. > If user click on the link, the dialog content and buttons switch to > login dialog which has same functionality as 'new login page'. User is > able to return back to the error message by clicking on a back button. > > login.html uses same css styles as migration page -> ipa-migration.css > was merged into ipa.css. > > https://fedorahosted.org/freeipa/ticket/2450 > > Theoretically the login.html is not needed. > Sometime later we should come up with a method how to i18n static pages > and main page prior to authentication. ACK. It looks like ipa.js in master and ipa-2-2 have diverged slightly, I'll let you push this so you can make sure everything is ok. rob From rcritten at redhat.com Thu Mar 1 23:39:12 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 18:39:12 -0500 Subject: [Freeipa-devel] [PATCH] 0100 Improved usability of login dialog In-Reply-To: <4F4F76C9.5020305@redhat.com> References: <4F4F76C9.5020305@redhat.com> Message-ID: <4F5008A0.7020700@redhat.com> Petr Vobornik wrote: > Usability was improved in Unauthorized/Login dialog. > > When the dialog is opened a link which switches to login form is focus > so user can do following: > > 1) press enter (login form is displayed and username field is focused ) > 2) type username > 3) press tab > 4) type password > 5) press enter > > this sequence will execute login request. > > When filling form user can also press 'escape' to go back to previous > form state. It's the same as if he would click on the 'back' button. > > https://fedorahosted.org/freeipa/ticket/2450 ACK From rcritten at redhat.com Fri Mar 2 03:17:41 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 22:17:41 -0500 Subject: [Freeipa-devel] [PATCH] 977 fix WSGI exceptions Message-ID: <4F503BD5.60405@redhat.com> Trying to raise some exceptions in the WSGI code just raised other exceptiosn and were generally confusing. To test this do various combinations (with and without a ccache) of: curl -kv https://ipa.example.com/ipa/json --negotiate -u : -H 'Referer: https://ipa.example.com/ipa/json' curl -kv https://ipa.example.com/ipa/json --negotiate -u : curl -kv https://ipa.example.com/ipa/xml --negotiate -u : -H 'Referer: https://ipa.example.com/ipa/xml' curl -kv https://ipa.example.com/ipa/json --negotiate -u : If you want to get really clever set krbConstrainedDelegation to off in ipa.conf and restart and try them all again. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-977-wsgi.patch Type: text/x-diff Size: 4089 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 2 03:26:11 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 22:26:11 -0500 Subject: [Freeipa-devel] [PATCH] 978 fix hostnames in hbac tests Message-ID: <4F503DD3.2050601@redhat.com> I pushed this under the 1-liner rule. Martin drastically improved hostname validation and this broke several HBAC tests that were using invalid domain names. Pushed to master and ipa-2-2. Incidentally there are some broken sudo tests too but I addressed those in patch 919. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-978-test.patch Type: text/x-diff Size: 1046 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 2 03:56:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Mar 2012 22:56:20 -0500 Subject: [Freeipa-devel] [PATCH] 69 Configure SSH features of SSSD in ipa-client-install In-Reply-To: <4F4F9D50.3040804@redhat.com> References: <4F4CCFDD.7030302@redhat.com> <4F4D5869.6080106@redhat.com> <4F4DF579.7010307@redhat.com> <1330521888.32367.1.camel@balmora.brq.redhat.com> <4F4E2BC6.2050803@redhat.com> <1330524025.32367.5.camel@balmora.brq.redhat.com> <4F4F9D50.3040804@redhat.com> Message-ID: <4F5044E4.9030506@redhat.com> Jan Cholasta wrote: > On 29.2.2012 15:00, Martin Kosek wrote: >> On Wed, 2012-02-29 at 14:44 +0100, Jan Cholasta wrote: >>> On 29.2.2012 14:24, Martin Kosek wrote: >>>> On Wed, 2012-02-29 at 10:52 +0100, Jan Cholasta wrote: >>>>> On 28.2.2012 23:42, Rob Crittenden wrote: >>>>>> Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> this patch configures the new SSH features of SSSD in >>>>>>> ipa-client-install. >>>>>>> >>>>>>> To test it, you need to have SSSD 1.8.0 installed. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> >>>>>> Is there a better name for 'GlobalKnownHostsFile2'? >>>>> >>>>> What do you mean? The option name or the file name? Either way, I >>>>> don't >>>>> think there is a better name. >>>>> >>>>>> >>>>>> When is PubKeyAgent used?I tried in RHEL 6.2, F-11 and F15-17 and >>>>>> it was >>>>>> an unknown option in all. >>>>> >>>>> It's in openssh in RHEL 6.0. >>>>> >>>>>> >>>>>> Should you test for the existence of /usr/bin/sss_ssh_knownhostsproxy >>>>>> and /usr/bin/sss_ssh_authorizedkeys before setting it in a config >>>>>> file? >>>>> >>>>> It depends. Do we want to support clients with SSSD< 1.8.0? >>>>> >>>>>> >>>>>> How would you recommend testing this? Enroll a client and try to log >>>>>> into the IPA server? >>>>> >>>>> To test host authentication, you need an IPA host with SSH public keys >>>>> set (which is done automatically in ipa-client-install, so any IPA >>>>> host >>>>> should work) and try to ssh into that host from other (actually, it >>>>> can >>>>> be the same) IPA host. You should not see "The authenticity of host >>>>> ... >>>>> can't be estabilished" ssh message. >>>>> >>>>> To test user authentication, you need an IPA user with SSH public keys >>>>> set. To do that, you need to set the public keys using ipa >>>>> user-mod. You >>>>> should then be able to authenticate using your private key on any >>>>> IPA host. >>>>> >>>>>> >>>>>> rob >>>>> >>>>> Honza >>>>> >>>> >>>> I get this exception when running ipa-client-install with your patch. >>>> >>>> # ipa-client-install --enable-dns-updates >>>> Discovery was successful! >>>> Hostname: vm-138.idm.lab.bos.redhat.com >>>> Realm: IDM.LAB.BOS.REDHAT.COM >>>> DNS Domain: idm.lab.bos.redhat.com >>>> IPA Server: vm-068.idm.lab.bos.redhat.com >>>> BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>> >>>> >>>> Continue to configure the system with these values? [no]: y >>>> User authorized to enroll computers: admin >>>> Synchronizing time with KDC... >>>> Unable to sync time with IPA NTP server, assuming the time is in sync. >>>> Password for admin at IDM.LAB.BOS.REDHAT.COM: >>>> >>>> Enrolled in IPA realm IDM.LAB.BOS.REDHAT.COM >>>> Created /etc/ipa/default.conf >>>> Traceback (most recent call last): >>>> File "/usr/sbin/ipa-client-install", line 1514, in >>>> sys.exit(main()) >>>> File "/usr/sbin/ipa-client-install", line 1501, in main >>>> rval = install(options, env, fstore, statestore) >>>> File "/usr/sbin/ipa-client-install", line 1326, in install >>>> if configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, >>>> options): >>>> File "/usr/sbin/ipa-client-install", line 711, in configure_sssd_conf >>>> sssdconfig.activate_service('ssh') >>>> File "/usr/lib/python2.7/site-packages/SSSDConfig.py", line 1516, in >>>> activate_service >>>> raise NoServiceError >>>> SSSDConfig.NoServiceError >>>> >>>> >>>> SSSD version: sssd-1.8.1-0.20120228T2018Zgit751b121.fc16.x86_64 >>>> >>>> Martin >>>> >>> >>> Does your /etc/sssd/sssd.conf and /usr/share/sssd/sssd.api.conf contain >>> [ssh] section? >>> >> >> sssd.api.conf did contain the ssh section: >> >> # grep -C 3 ssh /usr/share/sssd/sssd.api.conf >> # autofs service >> autofs_negative_timeout = int, None, false >> >> [ssh] >> # ssh service >> >> [provider] >> #Available provider types >> >> >> sssd.conf did not. >> >> >> Either case, we should not crash but handle the issue in some more >> friendly way. >> >> Martin >> > > Patch updated with more defensive code. > > Honza > Needs a BuildRequires of sssd 1.8 or you get some pylint errors: ipa-client/ipa-install/ipa-client-install:712: [E1101, configure_sssd_conf] Instance of 'SSSDConfig' has no 'activate_service' member ipa-client/ipa-install/ipa-client-install:723: [E1101, configure_sssd_conf] Instance of 'SSSDConfig' has no 'activate_service' member ipa-client/ipa-install/ipa-client-install:734: [E1101, configure_sssd_conf] Instance of 'SSSDConfig' has no 'activate_service' member Host keys work fine. I wasn't able to get user ssh keys working but my server is still on F-15. I had a daily build of sssd (1.8.1) but it was missing /usr/libexec/sssd/sssd_ssh!? Too tired to work out why right now. Two more things: 1. You will need explicit test cases for QE to test positive and negative login cases (it would have sped me along too). 2. You need to beef up the commit message to describe what this does (e.g. configure for knownhost support). commit message space is cheap, be verbose. rob From jcholast at redhat.com Fri Mar 2 08:00:45 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 02 Mar 2012 09:00:45 +0100 Subject: [Freeipa-devel] [PATCH] 69 Configure SSH features of SSSD in ipa-client-install In-Reply-To: <4F5044E4.9030506@redhat.com> References: <4F4CCFDD.7030302@redhat.com> <4F4D5869.6080106@redhat.com> <4F4DF579.7010307@redhat.com> <1330521888.32367.1.camel@balmora.brq.redhat.com> <4F4E2BC6.2050803@redhat.com> <1330524025.32367.5.camel@balmora.brq.redhat.com> <4F4F9D50.3040804@redhat.com> <4F5044E4.9030506@redhat.com> Message-ID: <4F507E2D.2040108@redhat.com> On 2.3.2012 04:56, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 29.2.2012 15:00, Martin Kosek wrote: >>> On Wed, 2012-02-29 at 14:44 +0100, Jan Cholasta wrote: >>>> On 29.2.2012 14:24, Martin Kosek wrote: >>>>> On Wed, 2012-02-29 at 10:52 +0100, Jan Cholasta wrote: >>>>>> On 28.2.2012 23:42, Rob Crittenden wrote: >>>>>>> Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> this patch configures the new SSH features of SSSD in >>>>>>>> ipa-client-install. >>>>>>>> >>>>>>>> To test it, you need to have SSSD 1.8.0 installed. >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Is there a better name for 'GlobalKnownHostsFile2'? >>>>>> >>>>>> What do you mean? The option name or the file name? Either way, I >>>>>> don't >>>>>> think there is a better name. >>>>>> >>>>>>> >>>>>>> When is PubKeyAgent used?I tried in RHEL 6.2, F-11 and F15-17 and >>>>>>> it was >>>>>>> an unknown option in all. >>>>>> >>>>>> It's in openssh in RHEL 6.0. >>>>>> >>>>>>> >>>>>>> Should you test for the existence of >>>>>>> /usr/bin/sss_ssh_knownhostsproxy >>>>>>> and /usr/bin/sss_ssh_authorizedkeys before setting it in a config >>>>>>> file? >>>>>> >>>>>> It depends. Do we want to support clients with SSSD< 1.8.0? >>>>>> >>>>>>> >>>>>>> How would you recommend testing this? Enroll a client and try to log >>>>>>> into the IPA server? >>>>>> >>>>>> To test host authentication, you need an IPA host with SSH public >>>>>> keys >>>>>> set (which is done automatically in ipa-client-install, so any IPA >>>>>> host >>>>>> should work) and try to ssh into that host from other (actually, it >>>>>> can >>>>>> be the same) IPA host. You should not see "The authenticity of host >>>>>> ... >>>>>> can't be estabilished" ssh message. >>>>>> >>>>>> To test user authentication, you need an IPA user with SSH public >>>>>> keys >>>>>> set. To do that, you need to set the public keys using ipa >>>>>> user-mod. You >>>>>> should then be able to authenticate using your private key on any >>>>>> IPA host. >>>>>> >>>>>>> >>>>>>> rob >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> I get this exception when running ipa-client-install with your patch. >>>>> >>>>> # ipa-client-install --enable-dns-updates >>>>> Discovery was successful! >>>>> Hostname: vm-138.idm.lab.bos.redhat.com >>>>> Realm: IDM.LAB.BOS.REDHAT.COM >>>>> DNS Domain: idm.lab.bos.redhat.com >>>>> IPA Server: vm-068.idm.lab.bos.redhat.com >>>>> BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>> >>>>> >>>>> Continue to configure the system with these values? [no]: y >>>>> User authorized to enroll computers: admin >>>>> Synchronizing time with KDC... >>>>> Unable to sync time with IPA NTP server, assuming the time is in sync. >>>>> Password for admin at IDM.LAB.BOS.REDHAT.COM: >>>>> >>>>> Enrolled in IPA realm IDM.LAB.BOS.REDHAT.COM >>>>> Created /etc/ipa/default.conf >>>>> Traceback (most recent call last): >>>>> File "/usr/sbin/ipa-client-install", line 1514, in >>>>> sys.exit(main()) >>>>> File "/usr/sbin/ipa-client-install", line 1501, in main >>>>> rval = install(options, env, fstore, statestore) >>>>> File "/usr/sbin/ipa-client-install", line 1326, in install >>>>> if configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, >>>>> options): >>>>> File "/usr/sbin/ipa-client-install", line 711, in configure_sssd_conf >>>>> sssdconfig.activate_service('ssh') >>>>> File "/usr/lib/python2.7/site-packages/SSSDConfig.py", line 1516, in >>>>> activate_service >>>>> raise NoServiceError >>>>> SSSDConfig.NoServiceError >>>>> >>>>> >>>>> SSSD version: sssd-1.8.1-0.20120228T2018Zgit751b121.fc16.x86_64 >>>>> >>>>> Martin >>>>> >>>> >>>> Does your /etc/sssd/sssd.conf and /usr/share/sssd/sssd.api.conf contain >>>> [ssh] section? >>>> >>> >>> sssd.api.conf did contain the ssh section: >>> >>> # grep -C 3 ssh /usr/share/sssd/sssd.api.conf >>> # autofs service >>> autofs_negative_timeout = int, None, false >>> >>> [ssh] >>> # ssh service >>> >>> [provider] >>> #Available provider types >>> >>> >>> sssd.conf did not. >>> >>> >>> Either case, we should not crash but handle the issue in some more >>> friendly way. >>> >>> Martin >>> >> >> Patch updated with more defensive code. >> >> Honza >> > > Needs a BuildRequires of sssd 1.8 or you get some pylint errors: > > ipa-client/ipa-install/ipa-client-install:712: [E1101, > configure_sssd_conf] Instance of 'SSSDConfig' has no 'activate_service' > member > ipa-client/ipa-install/ipa-client-install:723: [E1101, > configure_sssd_conf] Instance of 'SSSDConfig' has no 'activate_service' > member > ipa-client/ipa-install/ipa-client-install:734: [E1101, > configure_sssd_conf] Instance of 'SSSDConfig' has no 'activate_service' > member Added. > > Host keys work fine. > > I wasn't able to get user ssh keys working but my server is still on > F-15. I had a daily build of sssd (1.8.1) but it was missing > /usr/libexec/sssd/sssd_ssh!? Too tired to work out why right now. F15 is not the problem, the SSSD package in ipa-devel is built without experimental features for some reason (in the patch I assumed that it always is, fixed that). > > Two more things: > > 1. You will need explicit test cases for QE to test positive and > negative login cases (it would have sped me along too). Should that be part of the patch? > > 2. You need to beef up the commit message to describe what this does > (e.g. configure for knownhost support). commit message space is cheap, > be verbose. Done. > > rob Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-69.2-ssh-install-config-sssd.patch Type: text/x-patch Size: 4503 bytes Desc: not available URL: From jcholast at redhat.com Fri Mar 2 08:19:01 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 02 Mar 2012 09:19:01 +0100 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F4FD4A0.5020105@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> <4F14F131.3080503@redhat.com> <4F4E2AC7.6030107@redhat.com> <4F4FC8C6.2000103@redhat.com> <4F4FD4A0.5020105@redhat.com> Message-ID: <4F508275.4000206@redhat.com> On 1.3.2012 20:57, Rob Crittenden wrote: > Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 17.1.2012 04:55, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): >>>>>> Jan Cholasta wrote: >>>>>>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >>>>>>>> Jan Cholasta wrote: >>>>>>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and >>>>>>>>>>>> sudoNotAfter >>>>>>>>>>>> but these weren't available in the sudorule plugin. >>>>>>>>>>>> >>>>>>>>>>>> I've added support for these. sudoOrder enforces uniqueness >>>>>>>>>>>> because >>>>>>>>>>>> duplicates are undefined. >>>>>>>>>>>> >>>>>>>>>>>> I also added support for a GeneralizedTime parameter type. >>>>>>>>>>>> This is >>>>>>>>>>>> similar to the existing AccessTime parameter but it only >>>>>>>>>>>> handles a >>>>>>>>>>>> single time value. >>>>>>>>>>> >>>>>>>>>>> You should parse the date/time part of the value with >>>>>>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it >>>>>>>>>>> manually, >>>>>>>>>>> that way you'll get most of the validation for free. >>>>>>>>>> >>>>>>>>>> Yes but it gives a crappy error message, just saying that some >>>>>>>>>> data is >>>>>>>>>> left over not what is wrong. >>>>>>>>> >>>>>>>>> IMHO having a separate error message for every field in the time >>>>>>>>> string >>>>>>>>> (like you do in the patch) is an overkill, simple "invalid time" >>>>>>>>> and/or >>>>>>>>> "unknown time format" should suffice (we don't have errors like >>>>>>>>> "invalid >>>>>>>>> 3rd octet" for IP adresses either). >>>>>>>> >>>>>>>> Well, the work is done, hard to go back on a better error message. >>>>>>>> >>>>>>>>>> >>>>>>>>>>> Also, it would be nice to be able to enter the value in more >>>>>>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and >>>>>>>>>>> normalize >>>>>>>>>>> that to LDAP generalized time. >>>>>>>>>> >>>>>>>>>> When dealing with time there are so many ways to input and >>>>>>>>>> display >>>>>>>>>> the >>>>>>>>>> same values this becomes difficult. >>>>>>>>>> >>>>>>>>>> I'd expect that the times for these two attributes will be >>>>>>>>>> relatively >>>>>>>>>> simple and I somehow doubt users are going to want seconds, leap >>>>>>>>>> seconds >>>>>>>>>> or fractions, but we'll need to consider how to do it for future >>>>>>>>>> consistency (otherwise we could have a case where time is >>>>>>>>>> entered in >>>>>>>>>> one >>>>>>>>>> format for some attributes and another for others). >>>>>>>>>> >>>>>>>>>> If we input in a nice way we need to output in the same way. >>>>>>>>> >>>>>>>>> We could make the preferred input/output time format >>>>>>>>> user-configurable, >>>>>>>>> defaulting to current locale time format. This format would be >>>>>>>>> used >>>>>>>>> for >>>>>>>>> output. For input, we could go over a list of formats (first the >>>>>>>>> user-configured format, then current locale format, then a >>>>>>>>> handful of >>>>>>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first >>>>>>>>> format >>>>>>>>> that can be successfully used to parse the time string. >>>>>>>> >>>>>>>> See how far you get into the rabbit hole with even this simple >>>>>>>> format? >>>>>>> >>>>>>> I don't mind, as long as it is the right thing to do (IMHO) :) >>>>>>> >>>>>>> Anyway, I think this could be done on the client side, so we might >>>>>>> use >>>>>>> your patch without changes. However, I would prefer if the parameter >>>>>>> class was more generic, so we could use it (hypothetically) to store >>>>>>> time in some other way than LDAP generalized time attribute (at >>>>>>> least >>>>>>> name it DateTime please). >>>>>>> >>>>>> >>>>>> Ok, I'm fine with that. >>>>> >>>>> Thanks. >>>>> >>>>>> >>>>>>>> >>>>>>>> The LDAP GeneralizedTime needs to be either in GMT or include a >>>>>>>> differential. This gets us into the territory where the client >>>>>>>> could be >>>>>>>> in a different timezone than the server which leads us to why we >>>>>>>> dropped >>>>>>>> AccessTime in the first place. >>>>>>> >>>>>>> Speaking of time zones, the differential alone is not a sufficient >>>>>>> time >>>>>>> zone description, as it doesn't account for DST. Is there a way to >>>>>>> store >>>>>>> time in LDAP with full time zone name (just in case it's needed >>>>>>> sometime >>>>>>> in future)? >>>>>> >>>>>> There is no way to store DST in LDAP (probably for good reason). >>>>>> Oddly >>>>>> enough the older LDAP v3 RFC (2252) strongly recommends using only >>>>>> GMT >>>>>> but the RFC that obsoletes it (4517) does not include this. >>>>> >>>>> Thanks for the info. >>>>> >>>>>> >>>>>>> >>>>>>>> So I'd like the user to supply the >>>>>>>> timezone themselves so I don't have to guess (wrongly) and let them >>>>>>>> worry about differing timezones. >>>>>>> >>>>>>> We don't have to guess, IIRC there is a way to get the local >>>>>>> timezone >>>>>>> differential in both Python and JavaScript, so the client could >>>>>>> supply >>>>>>> it automatically if necessary. >>>>>> >>>>>> I was thinking more about non-IPA clients (like sudo and notBefore). >>>>> >>>>> I think this can still be done at least in CLI, but it could be >>>>> done in >>>>> a separate patch. >>>>> >>>>>> >>>>>> Updated patches attached. >>>>>> >>>>>> rob >>>>> >>>>> Patch 919 doesn't cleanly apply on current master (neither does 916 >>>>> BTW). >>>>> >>>>> Honza >>>>> >>>> >>>> Rebased patch (and 916 too, separately). >>>> >>>> rob >>> >>> Patch 918: >>> >>> 1. LDAP generalized time allows you to omit minutes from time zone >>> differential, your code treats such values as invalid >>> >>> 2. IMO a better pattern could be used, such as >>> u'^([0-9]{2}){5,7}([.,][0-9]+)?([-+]([0-9]{2}){1,2}|Z)$' >>> >>> 3. 20120229000Z has malformed minutes, but the error message says >>> "Malformed seconds" >>> >>> 4. 20120229000+0000 has malformed minutes, but the error message says >>> "Missing operator for differential or malformed time string" >>> >>> 5. 201202290000+0000 is valid generalized time, but it causes "Missing >>> operator for differential or malformed time string" error >>> >>> 6. Invalid month/day combinations (such as 201202310000Z) are treated as >>> valid >>> >>> 7. When + or - is missing, the error message says "Missing operator ..." >>> - IMO a better term than "operator" is "sign" in this case >>> >>> 8. The DateTime docstring includes grammar definition for MINUS, but not >>> for PLUS, DOT or COMMA. >>> >>> 9. I'm not too fond of the _rule_required hack. Can't the same thing be >>> done in _validate_scalar? >>> >>> 10. pattern_errmsg should say "Must be of the form YYYYMMDDHH[MM]Z or >>> YYYYMMDDHH[MM]{+|-}HHMM" >>> >>> There might be more bugs in validation that I didn't discover. I would >>> suggest you to use a more pythonic approach for the validation code >>> (e.g. use partition() to split the time zone and fraction from the rest >>> of the value, etc.), the current code is rather C-ish, hard to read and >>> apparently error-prone. >>> >>> >>> Patch 919: >>> >>> 1. sudoorder uniqueness is not properly checked in ipa sudorule-mod: >>> >>> $ ipa sudorule-add rule1 >>> ----------------------- >>> Added Sudo Rule "rule1" >>> ----------------------- >>> Rule name: rule1 >>> Enabled: TRUE >>> >>> $ ipa sudorule-add rule2 --order=0 >>> ----------------------- >>> Added Sudo Rule "rule2" >>> ----------------------- >>> Rule name: rule2 >>> Enabled: TRUE >>> Sudo order: 0 >>> >>> $ ipa sudorule-add rule3 --order=0 >>> ipa: ERROR: invalid 'order': order must be a unique value (0 already >>> used by rule2) >>> >>> $ ipa sudorule-mod rule1 --order=0 >>> -------------------------- >>> Modified Sudo Rule "rule1" >>> -------------------------- >>> Rule name: rule1 >>> Enabled: TRUE >>> Sudo order: 0 >>> >>> (now both rule1 and rule2 have sudoorder=0) >>> >>> 2. Shouldn't we check that sudonotbefore <= sudonotafter? >>> >>> 3. sudonotbefore param doc should say "Start of time interval for which >>> the entry is valid (YYYYMMDDHH[MM]Z)" >>> >>> 4. sudonotafter param doc should say "End of time interval for which the >>> entry is valid (YYYYMMDDHH[MM]Z)" >>> >>> 5. In 60ipasudo.ldif, the ipaSudoRule object class is missing the >>> sudoOrder, sudoNotBefore and sudoNotAfter attributes. Is this OK? >>> >>> >>> Both patches need to be rebased. >>> >>> Honza >>> >> >> Ok, lets take this one step at a time. >> >> This updated patch adds schema for all three attributes but just a Param >> for sudoOrder. I'll have to revisit DateTime for notbefore and notafter. >> >> I addressed the issue with order and added a test for it. >> >> Schema is fixed on new installs. ipa-server-install fails with: [02/Mar/2012:09:13:08 +0100] dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/schema/60ipasudo.ldif (lineno: 1) is invalid, error code 21 (Invalid syntax) - object class ipaSudoRule: Unknown allowed attribute type "sudoNotBefore" [02/Mar/2012:09:13:08 +0100] dse - Please edit the file to correct the reported problems and then restart the server. >> >> rob > > And now with updated API.txt. Forgot to squash the commit. > > rob > Honza -- Jan Cholasta From mkosek at redhat.com Fri Mar 2 08:29:17 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 09:29:17 +0100 Subject: [Freeipa-devel] [PATCH] 956 user lockout status In-Reply-To: <4F4FE96C.7020405@redhat.com> References: <4F440556.7090006@redhat.com> <1329863296.18690.43.camel@willson.li.ssimo.org> <4F441DAD.3020503@redhat.com> <1330363878.2925.18.camel@balmora.brq.redhat.com> <4F4DFBF2.8090108@redhat.com> <1330518873.10228.20.camel@balmora.brq.redhat.com> <4F4FE96C.7020405@redhat.com> Message-ID: <1330676957.2123.3.camel@priserak> On Thu, 2012-03-01 at 16:26 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Wed, 2012-02-29 at 11:20 +0100, Petr Viktorin wrote: > >> On 02/27/2012 06:31 PM, Martin Kosek wrote: > >>> > >>> 4) Minor change: > >>> - except Exception: > >>> + except: > >>> > >> > >> Don't do that. It would for example disable Ctrl+C by trapping > >> KeyboardInterrupt. > >> > >> PEP8 has a paragraph on this, search for 'except Exception:' > >> > >> > > > > Good to know, thanks. Rob, in that case please ignore issue #4. > > > > Martin > > Updated patch attached. > > rob This does not look like the right patch. Martin From pviktori at redhat.com Fri Mar 2 09:07:44 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 02 Mar 2012 10:07:44 +0100 Subject: [Freeipa-devel] [PATCHES] 0012-13 Don't allow deleting required config options In-Reply-To: <4F4E3FB0.9060409@redhat.com> References: <4F42159E.8080006@redhat.com> <4F42A440.7080904@redhat.com> <4F436910.4040004@redhat.com> <4F4BF934.4000902@redhat.com> <4F4CB257.5090001@redhat.com> <4F4CE275.6070708@redhat.com> <4F4DF93E.80509@redhat.com> <4F4DFA85.4010400@redhat.com> <4F4E19E0.5010305@redhat.com> <4F4E3BEA.5010308@redhat.com> <4F4E3FB0.9060409@redhat.com> Message-ID: <4F508DE0.2040402@redhat.com> On 02/29/2012 04:09 PM, Petr Viktorin wrote: > On 02/29/2012 03:53 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 02/29/2012 11:14 AM, Jan Cholasta wrote: >>>> On 29.2.2012 11:09, Petr Viktorin wrote: >>>>> On 02/28/2012 03:19 PM, Jan Cholasta wrote: >>>>>> On 28.2.2012 11:54, Petr Viktorin wrote: >>>>>>> On 02/27/2012 10:44 PM, Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>>>> On 02/20/2012 08:51 PM, Rob Crittenden wrote: >>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2159 says various config >>>>>>>>>>> options >>>>>>>>>>> are not marked Required, so entering an empty value for it will >>>>>>>>>>> pass >>>>>>>>>>> validation (and IPA will blow up later when it expects a >>>>>>>>>>> string,not >>>>>>>>>>> None). Forexample the following: >>>>>>>>>>> $ ipa config-mod --groupsearch= >>>>>>>>>>> fails with AttributeError: 'NoneType' object has no attribute >>>>>>>>>>> 'split' >>>>>>>>>>> >>>>>>>>>>> There is a more general problem behind this, though: even if the >>>>>>>>>>> attributes *are* marked as Required, an empty string will pass >>>>>>>>>>> validation. This is because `None` is used in >>>>>>>>>>> `Param.validate` to >>>>>>>>>>> mean >>>>>>>>>>> both "No value supplied" and "Empty value supplied". The method >>>>>>>>>>> currently assumes the former, and skips validation entirely for >>>>>>>>>>> `None` >>>>>>>>>>> values to optional parameters. >>>>>>>>>>> >>>>>>>>>>> For example, the following will delete "membergroup", even >>>>>>>>>>> though >>>>>>>>>>> it's a >>>>>>>>>>> required attribute : >>>>>>>>>>> >>>>>>>>>>> $ ipa delegation-add --attrs=street --group=editors \ >>>>>>>>>>> --membergroup=admins td1 >>>>>>>>>>> $ ipa delegation-mod --membergroup= td1 >>>>>>>>>>> >>>>>>>>>>> Note that some LDAPObjects handle this with a _check_empty_attrs >>>>>>>>>>> function, so they aren't affected. That function is specific to >>>>>>>>>>> LADP >>>>>>>>>>> objects, though. So I needed to tackle this on a lower level. >>>>>>>>>>> >>>>>>>>>>> This patch solves the problem by >>>>>>>>>>> * adding a 'nonempty' flag when a required parameter of a CRUD >>>>>>>>>>> Update >>>>>>>>>>> object is auto-converted to a non-required parameter >>>>>>>>>>> * making the`validate` method aware of whether the parameter was >>>>>>>>>>> supplied; and if it was, honor the "nonempty" flag. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The second patch fixes >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2159 by >>>>>>>>>>> marking required config options as required. >>>>>>>>>> >>>>>>>>>> This looks good but I think there are other things to protect in >>>>>>>>>> config >>>>>>>>>> as well such as the default e-mail domain. It is probably safe to >>>>>>>>>> say >>>>>>>>>> that everything in there is required. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> >>>>>>>>> Let me just double-check this with you. >>>>>>>>> >>>>>>>>> According to code in the user plugin (around line 330), if the >>>>>>>>> default >>>>>>>>> e-mail domain is not set, users don't get an address >>>>>>>>> auto-assigned. Do >>>>>>>>> we really want to require user e-mails? >>>>>>>>> >>>>>>>>> ipaconfigstring (the password plugin flags) are a set (multivalue, >>>>>>>>> not >>>>>>>>> required). >>>>>>>>> >>>>>>>>> The rest of the values I left as not required are for optional >>>>>>>>> features >>>>>>>>> or limits: search results & time limit, max. username length, >>>>>>>>> password >>>>>>>>> expiry notification. Currently if these are missing, the >>>>>>>>> feature/limit >>>>>>>>> is disabled (well, except for the time limit). >>>>>>>>> But, there are also special values (0 or -1) that have the same >>>>>>>>> effect >>>>>>>>> as a missing value. Sometimes they're documented. >>>>>>>>> So we want to enforce that users use these special values >>>>>>>>> instead of >>>>>>>>> removing the config entry? >>>>>>>> >>>>>>>> I think we want to enforce that these are defined. It will be >>>>>>>> confusing >>>>>>>> for users if these are not there at all. I don't think we need to >>>>>>>> show >>>>>>>> the special options, just declare that the attribute is required. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> Attaching updated patch 13. >>>>>>> >>>>>>> Only the default e-mail domain >>>>>>> (https://fedorahosted.org/freeipa/ticket/2409) and ipaconfigstring >>>>>>> are >>>>>>> still optional. >>>>>>> >>>>>> >>>>>> You have removed all the config-related defensive code in the >>>>>> patch, is >>>>>> this a good idea? What will happen if someone e.g. deletes a required >>>>>> config attribute directly from LDAP? >>>>>> >>>>> >>>>> Then IPA crashes. The defensive code wasn't there for all cases >>>>> anyway, >>>>> as ticket #2159 shows. >>>>> >>>>> If we want to protect against this it would probably be better to make >>>>> the config class itself give the default when a required value is >>>>> missing. >>>>> >>>> >>>> This, and raise an error in cases where no default is available (the >>>> check should probably be done in ldap.get_ipa_config). >>>> >>>> Honza >>>> >>> >>> Would a better approach be to modify the LDAP schema to require these >>> values? >>> >> >> I think that may be a longer-term fix. I propose we keep the defensive >> code in for now and correct it in the future. >> >> rob > > Here is an updated patch 13 that does that. > And here is patch 12 rebased against current master. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0012-02-Enforce-that-required-attributes-can-t-be-set-to-Non.patch Type: text/x-patch Size: 4625 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 2 10:02:39 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 11:02:39 +0100 Subject: [Freeipa-devel] [PATCH] 977 fix WSGI exceptions In-Reply-To: <4F503BD5.60405@redhat.com> References: <4F503BD5.60405@redhat.com> Message-ID: <1330682559.2123.7.camel@priserak> On Thu, 2012-03-01 at 22:17 -0500, Rob Crittenden wrote: > Trying to raise some exceptions in the WSGI code just raised other > exceptiosn and were generally confusing. > > To test this do various combinations (with and without a ccache) of: > > curl -kv https://ipa.example.com/ipa/json --negotiate -u : -H 'Referer: > https://ipa.example.com/ipa/json' > > curl -kv https://ipa.example.com/ipa/json --negotiate -u : > > curl -kv https://ipa.example.com/ipa/xml --negotiate -u : -H 'Referer: > https://ipa.example.com/ipa/xml' > > curl -kv https://ipa.example.com/ipa/json --negotiate -u : > > If you want to get really clever set krbConstrainedDelegation to off in > ipa.conf and restart and try them all again. > > rob Looks OK to me. ACK. Pushed to master, ipa-2-2. Martin From pvoborni at redhat.com Fri Mar 2 11:10:17 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 02 Mar 2012 12:10:17 +0100 Subject: [Freeipa-devel] [PATCH] 098 Forms based authentication UI In-Reply-To: <4F500895.3060701@redhat.com> References: <4F4E3F1E.6090205@redhat.com> <4F500895.3060701@redhat.com> Message-ID: <4F50AA99.9060706@redhat.com> On 03/02/2012 12:39 AM, Rob Crittenden wrote: > Petr Vobornik wrote: >> Support for forms based authentication was added to UI. >> >> It consist of: >> >> 1) new login page >> Page url is [ipa server]/ipa/ui/login.html >> >> Page contains a login form. For authentication it sends ajax request at >> [ipa server]/session/json/login_password. If authentication is >> successfull page is redirected to [ipa server]/ipa/ui if it fails from >> whatever reason a message is shown. >> >> 2) new enhanced error dialog - authorization_dialog. >> >> This dialog is displayed when user is not authorized to perform action - >> usually when ticket and session expires. >> It is a standard error dialog which shows kerberos ticket related error >> message and newly offers (as a link) to use form based authentication. >> If user click on the link, the dialog content and buttons switch to >> login dialog which has same functionality as 'new login page'. User is >> able to return back to the error message by clicking on a back button. >> >> login.html uses same css styles as migration page -> ipa-migration.css >> was merged into ipa.css. >> >> https://fedorahosted.org/freeipa/ticket/2450 >> >> Theoretically the login.html is not needed. >> Sometime later we should come up with a method how to i18n static pages >> and main page prior to authentication. > > ACK. It looks like ipa.js in master and ipa-2-2 have diverged slightly, > I'll let you push this so you can make sure everything is ok. > > rob Pushed to master an ipa-2-2. ipa.js is same in master and ipa-2-2. Maybe you were confused by the fact that when I was recently pushing 14 batches at once, I pushed two pairs of patches in different order. (Is it bad?) The final code is the same though. -- Petr Vobornik From pvoborni at redhat.com Fri Mar 2 11:10:32 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 02 Mar 2012 12:10:32 +0100 Subject: [Freeipa-devel] [PATCH] 0100 Improved usability of login dialog In-Reply-To: <4F5008A0.7020700@redhat.com> References: <4F4F76C9.5020305@redhat.com> <4F5008A0.7020700@redhat.com> Message-ID: <4F50AAA8.6080300@redhat.com> On 03/02/2012 12:39 AM, Rob Crittenden wrote: > Petr Vobornik wrote: >> Usability was improved in Unauthorized/Login dialog. >> >> When the dialog is opened a link which switches to login form is focus >> so user can do following: >> >> 1) press enter (login form is displayed and username field is focused ) >> 2) type username >> 3) press tab >> 4) type password >> 5) press enter >> >> this sequence will execute login request. >> >> When filling form user can also press 'escape' to go back to previous >> form state. It's the same as if he would click on the 'back' button. >> >> https://fedorahosted.org/freeipa/ticket/2450 > > ACK > Pushed to master an ipa-2-2. -- Petr Vobornik From mkosek at redhat.com Fri Mar 2 11:34:23 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 12:34:23 +0100 Subject: [Freeipa-devel] [PATCH] 216 Remove memberPrincipal for deleted replicas Message-ID: <1330688063.2123.8.camel@priserak> When a replica is deleted, its memberPrincipal entries in cn=s4u2proxy,cn=etc,SUFFIX were not removed. Then, if the replica is reinstalled and connected again, the installer would report an error with duplicate value in LDAP. This patch extends replica cleanup procedure to remove replica principal from s4u2proxy configuration. https://fedorahosted.org/freeipa/ticket/2451 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-216-remove-memberprincipal-for-deleted-replicas.patch Type: text/x-patch Size: 3537 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 2 12:28:56 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 02 Mar 2012 13:28:56 +0100 Subject: [Freeipa-devel] [PATCH] 0019 Use reboot from /sbin Message-ID: <4F50BD08.4070208@redhat.com> Commit message says it all. So does the ticket. https://fedorahosted.org/freeipa/ticket/2480 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0019-Use-reboot-from-sbin.patch Type: text/x-patch Size: 1232 bytes Desc: not available URL: From jhrozek at redhat.com Fri Mar 2 12:42:24 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 2 Mar 2012 13:42:24 +0100 Subject: [Freeipa-devel] [PATCH] 0019 Use reboot from /sbin In-Reply-To: <4F50BD08.4070208@redhat.com> References: <4F50BD08.4070208@redhat.com> Message-ID: <20120302124224.GC6596@zeppelin.brq.redhat.com> On Fri, Mar 02, 2012 at 01:28:56PM +0100, Petr Viktorin wrote: > Commit message says it all. So does the ticket. > > https://fedorahosted.org/freeipa/ticket/2480 > > -- > Petr? Does it matter? It the UsrMoved world, both are just symlinks to systemctl.. [root at vm-146 ~]# ll /sbin/reboot lrwxrwxrwx. 1 root root 16 Feb 29 16:25 /sbin/reboot -> ../bin/systemctl [root at vm-146 ~]# ll /usr/sbin/reboot lrwxrwxrwx. 1 root root 16 Feb 29 16:25 /usr/sbin/reboot -> ../bin/systemctl [root at vm-146 ~]# cat /etc/redhat-release Fedora release 18 (Rawhide) From pviktori at redhat.com Fri Mar 2 13:08:38 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 02 Mar 2012 14:08:38 +0100 Subject: [Freeipa-devel] [PATCH] 0019 Use reboot from /sbin In-Reply-To: <20120302124224.GC6596@zeppelin.brq.redhat.com> References: <4F50BD08.4070208@redhat.com> <20120302124224.GC6596@zeppelin.brq.redhat.com> Message-ID: <4F50C656.3050109@redhat.com> On 03/02/2012 01:42 PM, Jakub Hrozek wrote: > On Fri, Mar 02, 2012 at 01:28:56PM +0100, Petr Viktorin wrote: >> Commit message says it all. So does the ticket. >> >> https://fedorahosted.org/freeipa/ticket/2480 >> >> -- >> Petr? > > Does it matter? It the UsrMoved world, both are just symlinks to > systemctl.. > > [root at vm-146 ~]# ll /sbin/reboot > lrwxrwxrwx. 1 root root 16 Feb 29 16:25 /sbin/reboot -> ../bin/systemctl > [root at vm-146 ~]# ll /usr/sbin/reboot > lrwxrwxrwx. 1 root root 16 Feb 29 16:25 /usr/sbin/reboot -> > ../bin/systemctl > [root at vm-146 ~]# cat /etc/redhat-release > Fedora release 18 (Rawhide) > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Things are different on Fedora 16: vm-084:~# ls -l /sbin/reboot lrwxrwxrwx. 1 root root 16 Mar 2 04:43 /sbin/reboot -> ../bin/systemctl vm-084:~# ls -l /usr/bin/reboot ls: cannot access /usr/bin/reboot: No such file or directory vm-084:~# cat /etc/redhat-release Fedora release 16 (Verne) vm-084:~# vm-084:~# yum whatprovides /usr/bin/reboot Loaded plugins: product-id, subscription-manager Updating certificate-based repositories. usermode-1.108-1.fc16.x86_64 : Tools for certain user account management tasks Repo : Fedora-16-x86_64-Everything Matched from: Filename : /usr/bin/reboot usermode-1.108-1.fc16.x86_64 : Tools for certain user account management tasks Repo : fedora Matched from: Filename : /usr/bin/reboot Also, I expect other distros will follow FHS rather than UsrMove. -- Petr? From mkosek at redhat.com Fri Mar 2 13:40:31 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 14:40:31 +0100 Subject: [Freeipa-devel] [PATCH] 217 Fix typos in ipa-replica-manage man page Message-ID: <1330695631.2123.11.camel@priserak> ACK for patch fixing typos in ipa-replica-manage. I just had to fix it a little bit. Pushed to master, ipa-2-2. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-217-fix-typos-in-ipa-replica-manage-man-page.patch Type: text/x-patch Size: 1451 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 2 13:42:35 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 14:42:35 +0100 Subject: [Freeipa-devel] [PATCH] 217 Fix typos in ipa-replica-manage man page In-Reply-To: <1330695631.2123.11.camel@priserak> References: <1330695631.2123.11.camel@priserak> Message-ID: <1330695755.2123.12.camel@priserak> On Fri, 2012-03-02 at 14:40 +0100, Martin Kosek wrote: > ACK for patch fixing typos in ipa-replica-manage. I just had to fix it a > little bit. > > Pushed to master, ipa-2-2. > > Martin Just a clarification - the original patch was linked to the bug in Bugzilla. From rcritten at redhat.com Fri Mar 2 13:46:01 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 08:46:01 -0500 Subject: [Freeipa-devel] [PATCH] 956 user lockout status In-Reply-To: <1330676957.2123.3.camel@priserak> References: <4F440556.7090006@redhat.com> <1329863296.18690.43.camel@willson.li.ssimo.org> <4F441DAD.3020503@redhat.com> <1330363878.2925.18.camel@balmora.brq.redhat.com> <4F4DFBF2.8090108@redhat.com> <1330518873.10228.20.camel@balmora.brq.redhat.com> <4F4FE96C.7020405@redhat.com> <1330676957.2123.3.camel@priserak> Message-ID: <4F50CF19.7030407@redhat.com> Martin Kosek wrote: > On Thu, 2012-03-01 at 16:26 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Wed, 2012-02-29 at 11:20 +0100, Petr Viktorin wrote: >>>> On 02/27/2012 06:31 PM, Martin Kosek wrote: >>>>> >>>>> 4) Minor change: >>>>> - except Exception: >>>>> + except: >>>>> >>>> >>>> Don't do that. It would for example disable Ctrl+C by trapping >>>> KeyboardInterrupt. >>>> >>>> PEP8 has a paragraph on this, search for 'except Exception:' >>>> >>>> >>> >>> Good to know, thanks. Rob, in that case please ignore issue #4. >>> >>> Martin >> >> Updated patch attached. >> >> rob > > This does not look like the right patch. > > Martin > Right, it was just the new changes. All squashed together now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-956-3-status.patch Type: text/x-diff Size: 6791 bytes Desc: not available URL: From jhrozek at redhat.com Fri Mar 2 13:59:37 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 2 Mar 2012 14:59:37 +0100 Subject: [Freeipa-devel] [PATCH] 0019 Use reboot from /sbin In-Reply-To: <4F50C656.3050109@redhat.com> References: <4F50BD08.4070208@redhat.com> <20120302124224.GC6596@zeppelin.brq.redhat.com> <4F50C656.3050109@redhat.com> Message-ID: <20120302135937.GE6596@zeppelin.brq.redhat.com> On Fri, Mar 02, 2012 at 02:08:38PM +0100, Petr Viktorin wrote: > On 03/02/2012 01:42 PM, Jakub Hrozek wrote: > >On Fri, Mar 02, 2012 at 01:28:56PM +0100, Petr Viktorin wrote: > >>Commit message says it all. So does the ticket. > >> > >>https://fedorahosted.org/freeipa/ticket/2480 > >> > >>-- > >>Petr? > > > >Does it matter? It the UsrMoved world, both are just symlinks to > >systemctl.. > > > >[root at vm-146 ~]# ll /sbin/reboot > >lrwxrwxrwx. 1 root root 16 Feb 29 16:25 /sbin/reboot -> ../bin/systemctl > >[root at vm-146 ~]# ll /usr/sbin/reboot > >lrwxrwxrwx. 1 root root 16 Feb 29 16:25 /usr/sbin/reboot -> > >../bin/systemctl > >[root at vm-146 ~]# cat /etc/redhat-release > >Fedora release 18 (Rawhide) > > > >_______________________________________________ > >Freeipa-devel mailing list > >Freeipa-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/freeipa-devel > > Things are different on Fedora 16: > > vm-084:~# ls -l /sbin/reboot > lrwxrwxrwx. 1 root root 16 Mar 2 04:43 /sbin/reboot -> ../bin/systemctl > vm-084:~# ls -l /usr/bin/reboot > ls: cannot access /usr/bin/reboot: No such file or directory > vm-084:~# cat /etc/redhat-release > Fedora release 16 (Verne) > vm-084:~# > vm-084:~# yum whatprovides /usr/bin/reboot > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > usermode-1.108-1.fc16.x86_64 : Tools for certain user account > management tasks > Repo : Fedora-16-x86_64-Everything > Matched from: > Filename : /usr/bin/reboot > > > > usermode-1.108-1.fc16.x86_64 : Tools for certain user account > management tasks > Repo : fedora > Matched from: > Filename : /usr/bin/reboot > > I see. Ack > Also, I expect other distros will follow FHS rather than UsrMove. > From mkosek at redhat.com Fri Mar 2 14:24:44 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 15:24:44 +0100 Subject: [Freeipa-devel] [PATCH] 956 user lockout status In-Reply-To: <4F50CF19.7030407@redhat.com> References: <4F440556.7090006@redhat.com> <1329863296.18690.43.camel@willson.li.ssimo.org> <4F441DAD.3020503@redhat.com> <1330363878.2925.18.camel@balmora.brq.redhat.com> <4F4DFBF2.8090108@redhat.com> <1330518873.10228.20.camel@balmora.brq.redhat.com> <4F4FE96C.7020405@redhat.com> <1330676957.2123.3.camel@priserak> <4F50CF19.7030407@redhat.com> Message-ID: <1330698284.2123.14.camel@priserak> On Fri, 2012-03-02 at 08:46 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Thu, 2012-03-01 at 16:26 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> On Wed, 2012-02-29 at 11:20 +0100, Petr Viktorin wrote: > >>>> On 02/27/2012 06:31 PM, Martin Kosek wrote: > >>>>> > >>>>> 4) Minor change: > >>>>> - except Exception: > >>>>> + except: > >>>>> > >>>> > >>>> Don't do that. It would for example disable Ctrl+C by trapping > >>>> KeyboardInterrupt. > >>>> > >>>> PEP8 has a paragraph on this, search for 'except Exception:' > >>>> > >>>> > >>> > >>> Good to know, thanks. Rob, in that case please ignore issue #4. > >>> > >>> Martin > >> > >> Updated patch attached. > >> > >> rob > > > > This does not look like the right patch. > > > > Martin > > > > Right, it was just the new changes. All squashed together now. > > rob The new changes are ok, dates and default values are fine. But it seems like you squashed it with a wrong patch, its again raising an error when any master is not reachable (you can just interdiff 956-2 and 956-3 to see these malicious changes). Martin From rcritten at redhat.com Fri Mar 2 14:29:55 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 09:29:55 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F508275.4000206@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> <4F14F131.3080503@redhat.com> <4F4E2AC7.6030107@redhat.com> <4F4FC8C6.2000103@redhat.com> <4F4FD4A0.5020105@redhat.com> <4F508275.4000206@redhat.com> Message-ID: <4F50D963.9080203@redhat.com> Jan Cholasta wrote: > On 1.3.2012 20:57, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 17.1.2012 04:55, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): >>>>>>> Jan Cholasta wrote: >>>>>>>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >>>>>>>>> Jan Cholasta wrote: >>>>>>>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>>>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and >>>>>>>>>>>>> sudoNotAfter >>>>>>>>>>>>> but these weren't available in the sudorule plugin. >>>>>>>>>>>>> >>>>>>>>>>>>> I've added support for these. sudoOrder enforces uniqueness >>>>>>>>>>>>> because >>>>>>>>>>>>> duplicates are undefined. >>>>>>>>>>>>> >>>>>>>>>>>>> I also added support for a GeneralizedTime parameter type. >>>>>>>>>>>>> This is >>>>>>>>>>>>> similar to the existing AccessTime parameter but it only >>>>>>>>>>>>> handles a >>>>>>>>>>>>> single time value. >>>>>>>>>>>> >>>>>>>>>>>> You should parse the date/time part of the value with >>>>>>>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it >>>>>>>>>>>> manually, >>>>>>>>>>>> that way you'll get most of the validation for free. >>>>>>>>>>> >>>>>>>>>>> Yes but it gives a crappy error message, just saying that some >>>>>>>>>>> data is >>>>>>>>>>> left over not what is wrong. >>>>>>>>>> >>>>>>>>>> IMHO having a separate error message for every field in the time >>>>>>>>>> string >>>>>>>>>> (like you do in the patch) is an overkill, simple "invalid time" >>>>>>>>>> and/or >>>>>>>>>> "unknown time format" should suffice (we don't have errors like >>>>>>>>>> "invalid >>>>>>>>>> 3rd octet" for IP adresses either). >>>>>>>>> >>>>>>>>> Well, the work is done, hard to go back on a better error message. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Also, it would be nice to be able to enter the value in more >>>>>>>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and >>>>>>>>>>>> normalize >>>>>>>>>>>> that to LDAP generalized time. >>>>>>>>>>> >>>>>>>>>>> When dealing with time there are so many ways to input and >>>>>>>>>>> display >>>>>>>>>>> the >>>>>>>>>>> same values this becomes difficult. >>>>>>>>>>> >>>>>>>>>>> I'd expect that the times for these two attributes will be >>>>>>>>>>> relatively >>>>>>>>>>> simple and I somehow doubt users are going to want seconds, leap >>>>>>>>>>> seconds >>>>>>>>>>> or fractions, but we'll need to consider how to do it for future >>>>>>>>>>> consistency (otherwise we could have a case where time is >>>>>>>>>>> entered in >>>>>>>>>>> one >>>>>>>>>>> format for some attributes and another for others). >>>>>>>>>>> >>>>>>>>>>> If we input in a nice way we need to output in the same way. >>>>>>>>>> >>>>>>>>>> We could make the preferred input/output time format >>>>>>>>>> user-configurable, >>>>>>>>>> defaulting to current locale time format. This format would be >>>>>>>>>> used >>>>>>>>>> for >>>>>>>>>> output. For input, we could go over a list of formats (first the >>>>>>>>>> user-configured format, then current locale format, then a >>>>>>>>>> handful of >>>>>>>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first >>>>>>>>>> format >>>>>>>>>> that can be successfully used to parse the time string. >>>>>>>>> >>>>>>>>> See how far you get into the rabbit hole with even this simple >>>>>>>>> format? >>>>>>>> >>>>>>>> I don't mind, as long as it is the right thing to do (IMHO) :) >>>>>>>> >>>>>>>> Anyway, I think this could be done on the client side, so we might >>>>>>>> use >>>>>>>> your patch without changes. However, I would prefer if the >>>>>>>> parameter >>>>>>>> class was more generic, so we could use it (hypothetically) to >>>>>>>> store >>>>>>>> time in some other way than LDAP generalized time attribute (at >>>>>>>> least >>>>>>>> name it DateTime please). >>>>>>>> >>>>>>> >>>>>>> Ok, I'm fine with that. >>>>>> >>>>>> Thanks. >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> The LDAP GeneralizedTime needs to be either in GMT or include a >>>>>>>>> differential. This gets us into the territory where the client >>>>>>>>> could be >>>>>>>>> in a different timezone than the server which leads us to why we >>>>>>>>> dropped >>>>>>>>> AccessTime in the first place. >>>>>>>> >>>>>>>> Speaking of time zones, the differential alone is not a sufficient >>>>>>>> time >>>>>>>> zone description, as it doesn't account for DST. Is there a way to >>>>>>>> store >>>>>>>> time in LDAP with full time zone name (just in case it's needed >>>>>>>> sometime >>>>>>>> in future)? >>>>>>> >>>>>>> There is no way to store DST in LDAP (probably for good reason). >>>>>>> Oddly >>>>>>> enough the older LDAP v3 RFC (2252) strongly recommends using only >>>>>>> GMT >>>>>>> but the RFC that obsoletes it (4517) does not include this. >>>>>> >>>>>> Thanks for the info. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> So I'd like the user to supply the >>>>>>>>> timezone themselves so I don't have to guess (wrongly) and let >>>>>>>>> them >>>>>>>>> worry about differing timezones. >>>>>>>> >>>>>>>> We don't have to guess, IIRC there is a way to get the local >>>>>>>> timezone >>>>>>>> differential in both Python and JavaScript, so the client could >>>>>>>> supply >>>>>>>> it automatically if necessary. >>>>>>> >>>>>>> I was thinking more about non-IPA clients (like sudo and notBefore). >>>>>> >>>>>> I think this can still be done at least in CLI, but it could be >>>>>> done in >>>>>> a separate patch. >>>>>> >>>>>>> >>>>>>> Updated patches attached. >>>>>>> >>>>>>> rob >>>>>> >>>>>> Patch 919 doesn't cleanly apply on current master (neither does 916 >>>>>> BTW). >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> Rebased patch (and 916 too, separately). >>>>> >>>>> rob >>>> >>>> Patch 918: >>>> >>>> 1. LDAP generalized time allows you to omit minutes from time zone >>>> differential, your code treats such values as invalid >>>> >>>> 2. IMO a better pattern could be used, such as >>>> u'^([0-9]{2}){5,7}([.,][0-9]+)?([-+]([0-9]{2}){1,2}|Z)$' >>>> >>>> 3. 20120229000Z has malformed minutes, but the error message says >>>> "Malformed seconds" >>>> >>>> 4. 20120229000+0000 has malformed minutes, but the error message says >>>> "Missing operator for differential or malformed time string" >>>> >>>> 5. 201202290000+0000 is valid generalized time, but it causes "Missing >>>> operator for differential or malformed time string" error >>>> >>>> 6. Invalid month/day combinations (such as 201202310000Z) are >>>> treated as >>>> valid >>>> >>>> 7. When + or - is missing, the error message says "Missing operator >>>> ..." >>>> - IMO a better term than "operator" is "sign" in this case >>>> >>>> 8. The DateTime docstring includes grammar definition for MINUS, but >>>> not >>>> for PLUS, DOT or COMMA. >>>> >>>> 9. I'm not too fond of the _rule_required hack. Can't the same thing be >>>> done in _validate_scalar? >>>> >>>> 10. pattern_errmsg should say "Must be of the form YYYYMMDDHH[MM]Z or >>>> YYYYMMDDHH[MM]{+|-}HHMM" >>>> >>>> There might be more bugs in validation that I didn't discover. I would >>>> suggest you to use a more pythonic approach for the validation code >>>> (e.g. use partition() to split the time zone and fraction from the rest >>>> of the value, etc.), the current code is rather C-ish, hard to read and >>>> apparently error-prone. >>>> >>>> >>>> Patch 919: >>>> >>>> 1. sudoorder uniqueness is not properly checked in ipa sudorule-mod: >>>> >>>> $ ipa sudorule-add rule1 >>>> ----------------------- >>>> Added Sudo Rule "rule1" >>>> ----------------------- >>>> Rule name: rule1 >>>> Enabled: TRUE >>>> >>>> $ ipa sudorule-add rule2 --order=0 >>>> ----------------------- >>>> Added Sudo Rule "rule2" >>>> ----------------------- >>>> Rule name: rule2 >>>> Enabled: TRUE >>>> Sudo order: 0 >>>> >>>> $ ipa sudorule-add rule3 --order=0 >>>> ipa: ERROR: invalid 'order': order must be a unique value (0 already >>>> used by rule2) >>>> >>>> $ ipa sudorule-mod rule1 --order=0 >>>> -------------------------- >>>> Modified Sudo Rule "rule1" >>>> -------------------------- >>>> Rule name: rule1 >>>> Enabled: TRUE >>>> Sudo order: 0 >>>> >>>> (now both rule1 and rule2 have sudoorder=0) >>>> >>>> 2. Shouldn't we check that sudonotbefore <= sudonotafter? >>>> >>>> 3. sudonotbefore param doc should say "Start of time interval for which >>>> the entry is valid (YYYYMMDDHH[MM]Z)" >>>> >>>> 4. sudonotafter param doc should say "End of time interval for which >>>> the >>>> entry is valid (YYYYMMDDHH[MM]Z)" >>>> >>>> 5. In 60ipasudo.ldif, the ipaSudoRule object class is missing the >>>> sudoOrder, sudoNotBefore and sudoNotAfter attributes. Is this OK? >>>> >>>> >>>> Both patches need to be rebased. >>>> >>>> Honza >>>> >>> >>> Ok, lets take this one step at a time. >>> >>> This updated patch adds schema for all three attributes but just a Param >>> for sudoOrder. I'll have to revisit DateTime for notbefore and notafter. >>> >>> I addressed the issue with order and added a test for it. >>> >>> Schema is fixed on new installs. > > ipa-server-install fails with: > > [02/Mar/2012:09:13:08 +0100] dse_read_one_file - The entry cn=schema in > file /etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/schema/60ipasudo.ldif > (lineno: 1) is invalid, error code 21 (Invalid syntax) - object class > ipaSudoRule: Unknown allowed attribute type "sudoNotBefore" > [02/Mar/2012:09:13:08 +0100] dse - Please edit the file to correct the > reported problems and then restart the server. > >>> >>> rob >> >> And now with updated API.txt. Forgot to squash the commit. >> >> rob >> > > Honza > Another forgotten patch squash. There now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-919-3-sudo.patch Type: text/x-diff Size: 10621 bytes Desc: not available URL: From simo at redhat.com Fri Mar 2 14:39:32 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Mar 2012 09:39:32 -0500 Subject: [Freeipa-devel] [PATCH] 216 Remove memberPrincipal for deleted replicas In-Reply-To: <1330688063.2123.8.camel@priserak> References: <1330688063.2123.8.camel@priserak> Message-ID: <1330699172.25597.180.camel@willson.li.ssimo.org> On Fri, 2012-03-02 at 12:34 +0100, Martin Kosek wrote: > + principals.remove(member_principal) > + mod = [(ldap.MOD_REPLACE, 'memberPrincipal', > principals)] Any special reason why you use a search and then a replace instead of a delete by value ? A delete by value seem a lot less error prone to me, and should give you the same resuls. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Mar 2 14:48:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 09:48:38 -0500 Subject: [Freeipa-devel] [PATCH] 956 user lockout status In-Reply-To: <1330698284.2123.14.camel@priserak> References: <4F440556.7090006@redhat.com> <1329863296.18690.43.camel@willson.li.ssimo.org> <4F441DAD.3020503@redhat.com> <1330363878.2925.18.camel@balmora.brq.redhat.com> <4F4DFBF2.8090108@redhat.com> <1330518873.10228.20.camel@balmora.brq.redhat.com> <4F4FE96C.7020405@redhat.com> <1330676957.2123.3.camel@priserak> <4F50CF19.7030407@redhat.com> <1330698284.2123.14.camel@priserak> Message-ID: <4F50DDC6.2010501@redhat.com> Martin Kosek wrote: > On Fri, 2012-03-02 at 08:46 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Thu, 2012-03-01 at 16:26 -0500, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On Wed, 2012-02-29 at 11:20 +0100, Petr Viktorin wrote: >>>>>> On 02/27/2012 06:31 PM, Martin Kosek wrote: >>>>>>> >>>>>>> 4) Minor change: >>>>>>> - except Exception: >>>>>>> + except: >>>>>>> >>>>>> >>>>>> Don't do that. It would for example disable Ctrl+C by trapping >>>>>> KeyboardInterrupt. >>>>>> >>>>>> PEP8 has a paragraph on this, search for 'except Exception:' >>>>>> >>>>>> >>>>> >>>>> Good to know, thanks. Rob, in that case please ignore issue #4. >>>>> >>>>> Martin >>>> >>>> Updated patch attached. >>>> >>>> rob >>> >>> This does not look like the right patch. >>> >>> Martin >>> >> >> Right, it was just the new changes. All squashed together now. >> >> rob > > The new changes are ok, dates and default values are fine. > > But it seems like you squashed it with a wrong patch, its again raising > an error when any master is not reachable (you can just interdiff 956-2 > and 956-3 to see these malicious changes). > > Martin > Added back and added another try/except block around connect to catch those as well. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-956-4-status.patch Type: text/x-diff Size: 7546 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 2 15:22:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 16:22:00 +0100 Subject: [Freeipa-devel] [PATCH] 216 Remove memberPrincipal for deleted replicas In-Reply-To: <1330699172.25597.180.camel@willson.li.ssimo.org> References: <1330688063.2123.8.camel@priserak> <1330699172.25597.180.camel@willson.li.ssimo.org> Message-ID: <1330701720.2123.16.camel@priserak> On Fri, 2012-03-02 at 09:39 -0500, Simo Sorce wrote: > On Fri, 2012-03-02 at 12:34 +0100, Martin Kosek wrote: > > + principals.remove(member_principal) > > + mod = [(ldap.MOD_REPLACE, 'memberPrincipal', > > principals)] > > Any special reason why you use a search and then a replace instead of a > delete by value ? > > A delete by value seem a lot less error prone to me, and should give you > the same resuls. > > Simo. > Hm, thanks, that's a good point and much better approach. Updated patch is attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-216-2-remove-memberprincipal-for-deleted-replicas.patch Type: text/x-patch Size: 3202 bytes Desc: not available URL: From simo at redhat.com Fri Mar 2 15:30:40 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Mar 2012 10:30:40 -0500 Subject: [Freeipa-devel] [PATCH] 216 Remove memberPrincipal for deleted replicas In-Reply-To: <1330701720.2123.16.camel@priserak> References: <1330688063.2123.8.camel@priserak> <1330699172.25597.180.camel@willson.li.ssimo.org> <1330701720.2123.16.camel@priserak> Message-ID: <1330702240.26197.7.camel@willson.li.ssimo.org> On Fri, 2012-03-02 at 16:22 +0100, Martin Kosek wrote: > On Fri, 2012-03-02 at 09:39 -0500, Simo Sorce wrote: > > On Fri, 2012-03-02 at 12:34 +0100, Martin Kosek wrote: > > > + principals.remove(member_principal) > > > + mod = [(ldap.MOD_REPLACE, 'memberPrincipal', > > > principals)] > > > > Any special reason why you use a search and then a replace instead of a > > delete by value ? > > > > A delete by value seem a lot less error prone to me, and should give you > > the same resuls. > > > > Simo. > > > > Hm, thanks, that's a good point and much better approach. Updated patch > is attached. Ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Mar 2 15:30:57 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 16:30:57 +0100 Subject: [Freeipa-devel] [PATCH] 956 user lockout status In-Reply-To: <4F50DDC6.2010501@redhat.com> References: <4F440556.7090006@redhat.com> <1329863296.18690.43.camel@willson.li.ssimo.org> <4F441DAD.3020503@redhat.com> <1330363878.2925.18.camel@balmora.brq.redhat.com> <4F4DFBF2.8090108@redhat.com> <1330518873.10228.20.camel@balmora.brq.redhat.com> <4F4FE96C.7020405@redhat.com> <1330676957.2123.3.camel@priserak> <4F50CF19.7030407@redhat.com> <1330698284.2123.14.camel@priserak> <4F50DDC6.2010501@redhat.com> Message-ID: <1330702257.2123.17.camel@priserak> On Fri, 2012-03-02 at 09:48 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2012-03-02 at 08:46 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> On Thu, 2012-03-01 at 16:26 -0500, Rob Crittenden wrote: > >>>> Martin Kosek wrote: > >>>>> On Wed, 2012-02-29 at 11:20 +0100, Petr Viktorin wrote: > >>>>>> On 02/27/2012 06:31 PM, Martin Kosek wrote: > >>>>>>> > >>>>>>> 4) Minor change: > >>>>>>> - except Exception: > >>>>>>> + except: > >>>>>>> > >>>>>> > >>>>>> Don't do that. It would for example disable Ctrl+C by trapping > >>>>>> KeyboardInterrupt. > >>>>>> > >>>>>> PEP8 has a paragraph on this, search for 'except Exception:' > >>>>>> > >>>>>> > >>>>> > >>>>> Good to know, thanks. Rob, in that case please ignore issue #4. > >>>>> > >>>>> Martin > >>>> > >>>> Updated patch attached. > >>>> > >>>> rob > >>> > >>> This does not look like the right patch. > >>> > >>> Martin > >>> > >> > >> Right, it was just the new changes. All squashed together now. > >> > >> rob > > > > The new changes are ok, dates and default values are fine. > > > > But it seems like you squashed it with a wrong patch, its again raising > > an error when any master is not reachable (you can just interdiff 956-2 > > and 956-3 to see these malicious changes). > > > > Martin > > > > Added back and added another try/except block around connect to catch > those as well. > > rob ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Fri Mar 2 15:48:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 16:48:11 +0100 Subject: [Freeipa-devel] [PATCH] 216 Remove memberPrincipal for deleted replicas In-Reply-To: <1330702240.26197.7.camel@willson.li.ssimo.org> References: <1330688063.2123.8.camel@priserak> <1330699172.25597.180.camel@willson.li.ssimo.org> <1330701720.2123.16.camel@priserak> <1330702240.26197.7.camel@willson.li.ssimo.org> Message-ID: <1330703291.2123.18.camel@priserak> On Fri, 2012-03-02 at 10:30 -0500, Simo Sorce wrote: > On Fri, 2012-03-02 at 16:22 +0100, Martin Kosek wrote: > > On Fri, 2012-03-02 at 09:39 -0500, Simo Sorce wrote: > > > On Fri, 2012-03-02 at 12:34 +0100, Martin Kosek wrote: > > > > + principals.remove(member_principal) > > > > + mod = [(ldap.MOD_REPLACE, 'memberPrincipal', > > > > principals)] > > > > > > Any special reason why you use a search and then a replace instead of a > > > delete by value ? > > > > > > A delete by value seem a lot less error prone to me, and should give you > > > the same resuls. > > > > > > Simo. > > > > > > > Hm, thanks, that's a good point and much better approach. Updated patch > > is attached. > > Ack. > > Simo. > Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Fri Mar 2 15:54:13 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 16:54:13 +0100 Subject: [Freeipa-devel] [PATCH] 0019 Use reboot from /sbin In-Reply-To: <20120302135937.GE6596@zeppelin.brq.redhat.com> References: <4F50BD08.4070208@redhat.com> <20120302124224.GC6596@zeppelin.brq.redhat.com> <4F50C656.3050109@redhat.com> <20120302135937.GE6596@zeppelin.brq.redhat.com> Message-ID: <1330703653.2123.19.camel@priserak> On Fri, 2012-03-02 at 14:59 +0100, Jakub Hrozek wrote: > On Fri, Mar 02, 2012 at 02:08:38PM +0100, Petr Viktorin wrote: > > On 03/02/2012 01:42 PM, Jakub Hrozek wrote: > > >On Fri, Mar 02, 2012 at 01:28:56PM +0100, Petr Viktorin wrote: > > >>Commit message says it all. So does the ticket. > > >> > > >>https://fedorahosted.org/freeipa/ticket/2480 > > >> > > >>-- > > >>Petr? > > > > > >Does it matter? It the UsrMoved world, both are just symlinks to > > >systemctl.. > > > > > >[root at vm-146 ~]# ll /sbin/reboot > > >lrwxrwxrwx. 1 root root 16 Feb 29 16:25 /sbin/reboot -> ../bin/systemctl > > >[root at vm-146 ~]# ll /usr/sbin/reboot > > >lrwxrwxrwx. 1 root root 16 Feb 29 16:25 /usr/sbin/reboot -> > > >../bin/systemctl > > >[root at vm-146 ~]# cat /etc/redhat-release > > >Fedora release 18 (Rawhide) > > > > > >_______________________________________________ > > >Freeipa-devel mailing list > > >Freeipa-devel at redhat.com > > >https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > Things are different on Fedora 16: > > > > vm-084:~# ls -l /sbin/reboot > > lrwxrwxrwx. 1 root root 16 Mar 2 04:43 /sbin/reboot -> ../bin/systemctl > > vm-084:~# ls -l /usr/bin/reboot > > ls: cannot access /usr/bin/reboot: No such file or directory > > vm-084:~# cat /etc/redhat-release > > Fedora release 16 (Verne) > > vm-084:~# > > vm-084:~# yum whatprovides /usr/bin/reboot > > Loaded plugins: product-id, subscription-manager > > Updating certificate-based repositories. > > usermode-1.108-1.fc16.x86_64 : Tools for certain user account > > management tasks > > Repo : Fedora-16-x86_64-Everything > > Matched from: > > Filename : /usr/bin/reboot > > > > > > > > usermode-1.108-1.fc16.x86_64 : Tools for certain user account > > management tasks > > Repo : fedora > > Matched from: > > Filename : /usr/bin/reboot > > > > > > I see. > > Ack > > > Also, I expect other distros will follow FHS rather than UsrMove. > > > Pushed to master, ipa-2-2. Martin From rcritten at redhat.com Fri Mar 2 16:40:07 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 11:40:07 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F508275.4000206@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> <4F14F131.3080503@redhat.com> <4F4E2AC7.6030107@redhat.com> <4F4FC8C6.2000103@redhat.com> <4F4FD4A0.5020105@redhat.com> <4F508275.4000206@redhat.com> Message-ID: <4F50F7E7.3050409@redhat.com> Jan Cholasta wrote: > On 1.3.2012 20:57, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 17.1.2012 04:55, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): >>>>>>> Jan Cholasta wrote: >>>>>>>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >>>>>>>>> Jan Cholasta wrote: >>>>>>>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>>>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and >>>>>>>>>>>>> sudoNotAfter >>>>>>>>>>>>> but these weren't available in the sudorule plugin. >>>>>>>>>>>>> >>>>>>>>>>>>> I've added support for these. sudoOrder enforces uniqueness >>>>>>>>>>>>> because >>>>>>>>>>>>> duplicates are undefined. >>>>>>>>>>>>> >>>>>>>>>>>>> I also added support for a GeneralizedTime parameter type. >>>>>>>>>>>>> This is >>>>>>>>>>>>> similar to the existing AccessTime parameter but it only >>>>>>>>>>>>> handles a >>>>>>>>>>>>> single time value. >>>>>>>>>>>> >>>>>>>>>>>> You should parse the date/time part of the value with >>>>>>>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it >>>>>>>>>>>> manually, >>>>>>>>>>>> that way you'll get most of the validation for free. >>>>>>>>>>> >>>>>>>>>>> Yes but it gives a crappy error message, just saying that some >>>>>>>>>>> data is >>>>>>>>>>> left over not what is wrong. >>>>>>>>>> >>>>>>>>>> IMHO having a separate error message for every field in the time >>>>>>>>>> string >>>>>>>>>> (like you do in the patch) is an overkill, simple "invalid time" >>>>>>>>>> and/or >>>>>>>>>> "unknown time format" should suffice (we don't have errors like >>>>>>>>>> "invalid >>>>>>>>>> 3rd octet" for IP adresses either). >>>>>>>>> >>>>>>>>> Well, the work is done, hard to go back on a better error message. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Also, it would be nice to be able to enter the value in more >>>>>>>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and >>>>>>>>>>>> normalize >>>>>>>>>>>> that to LDAP generalized time. >>>>>>>>>>> >>>>>>>>>>> When dealing with time there are so many ways to input and >>>>>>>>>>> display >>>>>>>>>>> the >>>>>>>>>>> same values this becomes difficult. >>>>>>>>>>> >>>>>>>>>>> I'd expect that the times for these two attributes will be >>>>>>>>>>> relatively >>>>>>>>>>> simple and I somehow doubt users are going to want seconds, leap >>>>>>>>>>> seconds >>>>>>>>>>> or fractions, but we'll need to consider how to do it for future >>>>>>>>>>> consistency (otherwise we could have a case where time is >>>>>>>>>>> entered in >>>>>>>>>>> one >>>>>>>>>>> format for some attributes and another for others). >>>>>>>>>>> >>>>>>>>>>> If we input in a nice way we need to output in the same way. >>>>>>>>>> >>>>>>>>>> We could make the preferred input/output time format >>>>>>>>>> user-configurable, >>>>>>>>>> defaulting to current locale time format. This format would be >>>>>>>>>> used >>>>>>>>>> for >>>>>>>>>> output. For input, we could go over a list of formats (first the >>>>>>>>>> user-configured format, then current locale format, then a >>>>>>>>>> handful of >>>>>>>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first >>>>>>>>>> format >>>>>>>>>> that can be successfully used to parse the time string. >>>>>>>>> >>>>>>>>> See how far you get into the rabbit hole with even this simple >>>>>>>>> format? >>>>>>>> >>>>>>>> I don't mind, as long as it is the right thing to do (IMHO) :) >>>>>>>> >>>>>>>> Anyway, I think this could be done on the client side, so we might >>>>>>>> use >>>>>>>> your patch without changes. However, I would prefer if the >>>>>>>> parameter >>>>>>>> class was more generic, so we could use it (hypothetically) to >>>>>>>> store >>>>>>>> time in some other way than LDAP generalized time attribute (at >>>>>>>> least >>>>>>>> name it DateTime please). >>>>>>>> >>>>>>> >>>>>>> Ok, I'm fine with that. >>>>>> >>>>>> Thanks. >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> The LDAP GeneralizedTime needs to be either in GMT or include a >>>>>>>>> differential. This gets us into the territory where the client >>>>>>>>> could be >>>>>>>>> in a different timezone than the server which leads us to why we >>>>>>>>> dropped >>>>>>>>> AccessTime in the first place. >>>>>>>> >>>>>>>> Speaking of time zones, the differential alone is not a sufficient >>>>>>>> time >>>>>>>> zone description, as it doesn't account for DST. Is there a way to >>>>>>>> store >>>>>>>> time in LDAP with full time zone name (just in case it's needed >>>>>>>> sometime >>>>>>>> in future)? >>>>>>> >>>>>>> There is no way to store DST in LDAP (probably for good reason). >>>>>>> Oddly >>>>>>> enough the older LDAP v3 RFC (2252) strongly recommends using only >>>>>>> GMT >>>>>>> but the RFC that obsoletes it (4517) does not include this. >>>>>> >>>>>> Thanks for the info. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> So I'd like the user to supply the >>>>>>>>> timezone themselves so I don't have to guess (wrongly) and let >>>>>>>>> them >>>>>>>>> worry about differing timezones. >>>>>>>> >>>>>>>> We don't have to guess, IIRC there is a way to get the local >>>>>>>> timezone >>>>>>>> differential in both Python and JavaScript, so the client could >>>>>>>> supply >>>>>>>> it automatically if necessary. >>>>>>> >>>>>>> I was thinking more about non-IPA clients (like sudo and notBefore). >>>>>> >>>>>> I think this can still be done at least in CLI, but it could be >>>>>> done in >>>>>> a separate patch. >>>>>> >>>>>>> >>>>>>> Updated patches attached. >>>>>>> >>>>>>> rob >>>>>> >>>>>> Patch 919 doesn't cleanly apply on current master (neither does 916 >>>>>> BTW). >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> Rebased patch (and 916 too, separately). >>>>> >>>>> rob >>>> >>>> Patch 918: >>>> >>>> 1. LDAP generalized time allows you to omit minutes from time zone >>>> differential, your code treats such values as invalid >>>> >>>> 2. IMO a better pattern could be used, such as >>>> u'^([0-9]{2}){5,7}([.,][0-9]+)?([-+]([0-9]{2}){1,2}|Z)$' >>>> >>>> 3. 20120229000Z has malformed minutes, but the error message says >>>> "Malformed seconds" >>>> >>>> 4. 20120229000+0000 has malformed minutes, but the error message says >>>> "Missing operator for differential or malformed time string" >>>> >>>> 5. 201202290000+0000 is valid generalized time, but it causes "Missing >>>> operator for differential or malformed time string" error >>>> >>>> 6. Invalid month/day combinations (such as 201202310000Z) are >>>> treated as >>>> valid >>>> >>>> 7. When + or - is missing, the error message says "Missing operator >>>> ..." >>>> - IMO a better term than "operator" is "sign" in this case >>>> >>>> 8. The DateTime docstring includes grammar definition for MINUS, but >>>> not >>>> for PLUS, DOT or COMMA. >>>> >>>> 9. I'm not too fond of the _rule_required hack. Can't the same thing be >>>> done in _validate_scalar? >>>> >>>> 10. pattern_errmsg should say "Must be of the form YYYYMMDDHH[MM]Z or >>>> YYYYMMDDHH[MM]{+|-}HHMM" >>>> >>>> There might be more bugs in validation that I didn't discover. I would >>>> suggest you to use a more pythonic approach for the validation code >>>> (e.g. use partition() to split the time zone and fraction from the rest >>>> of the value, etc.), the current code is rather C-ish, hard to read and >>>> apparently error-prone. >>>> >>>> >>>> Patch 919: >>>> >>>> 1. sudoorder uniqueness is not properly checked in ipa sudorule-mod: >>>> >>>> $ ipa sudorule-add rule1 >>>> ----------------------- >>>> Added Sudo Rule "rule1" >>>> ----------------------- >>>> Rule name: rule1 >>>> Enabled: TRUE >>>> >>>> $ ipa sudorule-add rule2 --order=0 >>>> ----------------------- >>>> Added Sudo Rule "rule2" >>>> ----------------------- >>>> Rule name: rule2 >>>> Enabled: TRUE >>>> Sudo order: 0 >>>> >>>> $ ipa sudorule-add rule3 --order=0 >>>> ipa: ERROR: invalid 'order': order must be a unique value (0 already >>>> used by rule2) >>>> >>>> $ ipa sudorule-mod rule1 --order=0 >>>> -------------------------- >>>> Modified Sudo Rule "rule1" >>>> -------------------------- >>>> Rule name: rule1 >>>> Enabled: TRUE >>>> Sudo order: 0 >>>> >>>> (now both rule1 and rule2 have sudoorder=0) >>>> >>>> 2. Shouldn't we check that sudonotbefore <= sudonotafter? >>>> >>>> 3. sudonotbefore param doc should say "Start of time interval for which >>>> the entry is valid (YYYYMMDDHH[MM]Z)" >>>> >>>> 4. sudonotafter param doc should say "End of time interval for which >>>> the >>>> entry is valid (YYYYMMDDHH[MM]Z)" >>>> >>>> 5. In 60ipasudo.ldif, the ipaSudoRule object class is missing the >>>> sudoOrder, sudoNotBefore and sudoNotAfter attributes. Is this OK? >>>> >>>> >>>> Both patches need to be rebased. >>>> >>>> Honza >>>> >>> >>> Ok, lets take this one step at a time. >>> >>> This updated patch adds schema for all three attributes but just a Param >>> for sudoOrder. I'll have to revisit DateTime for notbefore and notafter. >>> >>> I addressed the issue with order and added a test for it. >>> >>> Schema is fixed on new installs. > > ipa-server-install fails with: > > [02/Mar/2012:09:13:08 +0100] dse_read_one_file - The entry cn=schema in > file /etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/schema/60ipasudo.ldif > (lineno: 1) is invalid, error code 21 (Invalid syntax) - object class > ipaSudoRule: Unknown allowed attribute type "sudoNotBefore" > [02/Mar/2012:09:13:08 +0100] dse - Please edit the file to correct the > reported problems and then restart the server. > >>> >>> rob >> >> And now with updated API.txt. Forgot to squash the commit. >> >> rob >> > > Honza > And now the right patch -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-919-5-sudo.patch Type: text/x-diff Size: 15950 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 2 16:54:10 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 11:54:10 -0500 Subject: [Freeipa-devel] [PATCH] 69 Configure SSH features of SSSD in ipa-client-install In-Reply-To: <4F507E2D.2040108@redhat.com> References: <4F4CCFDD.7030302@redhat.com> <4F4D5869.6080106@redhat.com> <4F4DF579.7010307@redhat.com> <1330521888.32367.1.camel@balmora.brq.redhat.com> <4F4E2BC6.2050803@redhat.com> <1330524025.32367.5.camel@balmora.brq.redhat.com> <4F4F9D50.3040804@redhat.com> <4F5044E4.9030506@redhat.com> <4F507E2D.2040108@redhat.com> Message-ID: <4F50FB32.8000904@redhat.com> Jan Cholasta wrote: > On 2.3.2012 04:56, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 29.2.2012 15:00, Martin Kosek wrote: >>>> On Wed, 2012-02-29 at 14:44 +0100, Jan Cholasta wrote: >>>>> On 29.2.2012 14:24, Martin Kosek wrote: >>>>>> On Wed, 2012-02-29 at 10:52 +0100, Jan Cholasta wrote: >>>>>>> On 28.2.2012 23:42, Rob Crittenden wrote: >>>>>>>> Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> this patch configures the new SSH features of SSSD in >>>>>>>>> ipa-client-install. >>>>>>>>> >>>>>>>>> To test it, you need to have SSSD 1.8.0 installed. >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Is there a better name for 'GlobalKnownHostsFile2'? >>>>>>> >>>>>>> What do you mean? The option name or the file name? Either way, I >>>>>>> don't >>>>>>> think there is a better name. >>>>>>> >>>>>>>> >>>>>>>> When is PubKeyAgent used?I tried in RHEL 6.2, F-11 and F15-17 and >>>>>>>> it was >>>>>>>> an unknown option in all. >>>>>>> >>>>>>> It's in openssh in RHEL 6.0. >>>>>>> >>>>>>>> >>>>>>>> Should you test for the existence of >>>>>>>> /usr/bin/sss_ssh_knownhostsproxy >>>>>>>> and /usr/bin/sss_ssh_authorizedkeys before setting it in a config >>>>>>>> file? >>>>>>> >>>>>>> It depends. Do we want to support clients with SSSD< 1.8.0? >>>>>>> >>>>>>>> >>>>>>>> How would you recommend testing this? Enroll a client and try to >>>>>>>> log >>>>>>>> into the IPA server? >>>>>>> >>>>>>> To test host authentication, you need an IPA host with SSH public >>>>>>> keys >>>>>>> set (which is done automatically in ipa-client-install, so any IPA >>>>>>> host >>>>>>> should work) and try to ssh into that host from other (actually, it >>>>>>> can >>>>>>> be the same) IPA host. You should not see "The authenticity of host >>>>>>> ... >>>>>>> can't be estabilished" ssh message. >>>>>>> >>>>>>> To test user authentication, you need an IPA user with SSH public >>>>>>> keys >>>>>>> set. To do that, you need to set the public keys using ipa >>>>>>> user-mod. You >>>>>>> should then be able to authenticate using your private key on any >>>>>>> IPA host. >>>>>>> >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> I get this exception when running ipa-client-install with your patch. >>>>>> >>>>>> # ipa-client-install --enable-dns-updates >>>>>> Discovery was successful! >>>>>> Hostname: vm-138.idm.lab.bos.redhat.com >>>>>> Realm: IDM.LAB.BOS.REDHAT.COM >>>>>> DNS Domain: idm.lab.bos.redhat.com >>>>>> IPA Server: vm-068.idm.lab.bos.redhat.com >>>>>> BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>>>>> >>>>>> >>>>>> Continue to configure the system with these values? [no]: y >>>>>> User authorized to enroll computers: admin >>>>>> Synchronizing time with KDC... >>>>>> Unable to sync time with IPA NTP server, assuming the time is in >>>>>> sync. >>>>>> Password for admin at IDM.LAB.BOS.REDHAT.COM: >>>>>> >>>>>> Enrolled in IPA realm IDM.LAB.BOS.REDHAT.COM >>>>>> Created /etc/ipa/default.conf >>>>>> Traceback (most recent call last): >>>>>> File "/usr/sbin/ipa-client-install", line 1514, in >>>>>> sys.exit(main()) >>>>>> File "/usr/sbin/ipa-client-install", line 1501, in main >>>>>> rval = install(options, env, fstore, statestore) >>>>>> File "/usr/sbin/ipa-client-install", line 1326, in install >>>>>> if configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, >>>>>> options): >>>>>> File "/usr/sbin/ipa-client-install", line 711, in configure_sssd_conf >>>>>> sssdconfig.activate_service('ssh') >>>>>> File "/usr/lib/python2.7/site-packages/SSSDConfig.py", line 1516, in >>>>>> activate_service >>>>>> raise NoServiceError >>>>>> SSSDConfig.NoServiceError >>>>>> >>>>>> >>>>>> SSSD version: sssd-1.8.1-0.20120228T2018Zgit751b121.fc16.x86_64 >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> Does your /etc/sssd/sssd.conf and /usr/share/sssd/sssd.api.conf >>>>> contain >>>>> [ssh] section? >>>>> >>>> >>>> sssd.api.conf did contain the ssh section: >>>> >>>> # grep -C 3 ssh /usr/share/sssd/sssd.api.conf >>>> # autofs service >>>> autofs_negative_timeout = int, None, false >>>> >>>> [ssh] >>>> # ssh service >>>> >>>> [provider] >>>> #Available provider types >>>> >>>> >>>> sssd.conf did not. >>>> >>>> >>>> Either case, we should not crash but handle the issue in some more >>>> friendly way. >>>> >>>> Martin >>>> >>> >>> Patch updated with more defensive code. >>> >>> Honza >>> >> >> Needs a BuildRequires of sssd 1.8 or you get some pylint errors: >> >> ipa-client/ipa-install/ipa-client-install:712: [E1101, >> configure_sssd_conf] Instance of 'SSSDConfig' has no 'activate_service' >> member >> ipa-client/ipa-install/ipa-client-install:723: [E1101, >> configure_sssd_conf] Instance of 'SSSDConfig' has no 'activate_service' >> member >> ipa-client/ipa-install/ipa-client-install:734: [E1101, >> configure_sssd_conf] Instance of 'SSSDConfig' has no 'activate_service' >> member > > Added. > >> >> Host keys work fine. >> >> I wasn't able to get user ssh keys working but my server is still on >> F-15. I had a daily build of sssd (1.8.1) but it was missing >> /usr/libexec/sssd/sssd_ssh!? Too tired to work out why right now. > > F15 is not the problem, the SSSD package in ipa-devel is built without > experimental features for some reason (in the patch I assumed that it > always is, fixed that). > >> >> Two more things: >> >> 1. You will need explicit test cases for QE to test positive and >> negative login cases (it would have sped me along too). > > Should that be part of the patch? Needs to be somewhere, attached here would have been fine. >> >> 2. You need to beef up the commit message to describe what this does >> (e.g. configure for knownhost support). commit message space is cheap, >> be verbose. > > Done. > >> >> rob > > Updated patch attached. > > Honza > ACK, pushed to master and ipa-2-2 From edewata at redhat.com Fri Mar 2 17:46:21 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 02 Mar 2012 11:46:21 -0600 Subject: [Freeipa-devel] [PATCH] 099 Removed CSV creation from UI In-Reply-To: <4F4E69B6.4090101@redhat.com> References: <4F4E69B6.4090101@redhat.com> Message-ID: <4F51076D.9020604@redhat.com> On 2/29/2012 12:08 PM, Petr Vobornik wrote: > Creating CSV values in UI is unnecessary and error-prone because server > converts them back to list. Possible problems with values containing > commas may occur. All occurrences of CSV joining were therefore removed. > > https://fedorahosted.org/freeipa/ticket/2227 ACK. Pushed to master and ipa-2-2. Finally it's gone.. :) -- Endi S. Dewata From pviktori at redhat.com Fri Mar 2 17:58:49 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 02 Mar 2012 18:58:49 +0100 Subject: [Freeipa-devel] [PATCH] 0015 Only split CSV strings once (updated) In-Reply-To: <4F4E6AC4.3070103@redhat.com> References: <4F464D59.2020601@redhat.com> <4F4B7EC3.9070003@redhat.com> <4F4E6AC4.3070103@redhat.com> Message-ID: <4F510A59.6070800@redhat.com> On 02/29/2012 07:13 PM, Petr Vobornik wrote: > On 02/27/2012 02:01 PM, Petr Viktorin wrote: >> It seems I didn't communicate the problem and my solution clearly >> enough, so let me try again. (Also, I learned from the discussions!) >> >> Currently, both the client and the server parse CSV options. The client >> does *not* re-encode the CSV before sending; the parsing is really done >> twice. This means e.g. that you need 3 backslashes to escape a literal >> comma: after the client-side split, '\\\,' becomes '\,'; which after the >> server-side split becomes ','. >> >> >> Since CSV is specific to the command-line, and the client is responsible >> for translating command-line input to XML-RPC (which has its own syntax >> for lists), the ideal fix will be to move CSV processing entirely to the >> client. >> This will be a rather invasive change, mainly because some parts of the >> UI now expect the server-side parsing (but they don't escape CSV, so >> values containing commas or backslashes are broken). So it won't make it >> to the upcoming release. My patch provides a quick fix: when a call >> comes from the command-line client, disable the server-side parsing. > > I investigated all occurrences of CSV creation in Web UI. I removed them > and UI is working fine. The patch is on the list: pvoborni 099. So your > patch shouldn't affect UI if my patch is applied. > >> >> I can't get away from moving split_csv() (which is not idempotent) out >> of normalize() (which is, and gets called lots of times); this is the >> patch's major change in therms of LOC. >> >> >> I'll note again that this only affects values with backslashes or double >> quotes. Exactly these options are currently broken (=need double >> escaping). The "normal" uses of CSV are completely unaffected. >> >> >> Attaching updated patch; the change vs. the original is that the "don't >> parse again" flag is now only set at the server, when a XMLRPC call is >> received, making the client fully forward-compatible (the flag doesn't >> get sent through the wire). >> >> >> The ticket is https://fedorahosted.org/freeipa/ticket/2227, but this >> patch is only the first step in fixing it. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > The webUI patch is in, and also I heard this patch is not making it to the release anyway, so the workaround makes little sense. I'd like to go for the real fix. Meanwhile I found some other bugs (https://fedorahosted.org/freeipa/ticket/2482, https://fedorahosted.org/freeipa/ticket/2483) that prevent me from testing this throroughly. Self-NACK for now. -- Petr? From mkosek at redhat.com Fri Mar 2 18:28:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 19:28:49 +0100 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F50F7E7.3050409@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> <4F14F131.3080503@redhat.com> <4F4E2AC7.6030107@redhat.com> <4F4FC8C6.2000103@redhat.com> <4F4FD4A0.5020105@redhat.com> <4F508275.4000206@redhat.com> <4F50F7E7.3050409@redhat.com> Message-ID: <1330712929.2123.24.camel@priserak> On Fri, 2012-03-02 at 11:40 -0500, Rob Crittenden wrote: > Jan Cholasta wrote: > > On 1.3.2012 20:57, Rob Crittenden wrote: > >> Rob Crittenden wrote: > >>> Jan Cholasta wrote: > >>>> On 17.1.2012 04:55, Rob Crittenden wrote: > >>>>> Jan Cholasta wrote: > >>>>>> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): > >>>>>>> Jan Cholasta wrote: > >>>>>>>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): > >>>>>>>>> Jan Cholasta wrote: > >>>>>>>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): > >>>>>>>>>>> Jan Cholasta wrote: > >>>>>>>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): > >>>>>>>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and > >>>>>>>>>>>>> sudoNotAfter > >>>>>>>>>>>>> but these weren't available in the sudorule plugin. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I've added support for these. sudoOrder enforces uniqueness > >>>>>>>>>>>>> because > >>>>>>>>>>>>> duplicates are undefined. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I also added support for a GeneralizedTime parameter type. > >>>>>>>>>>>>> This is > >>>>>>>>>>>>> similar to the existing AccessTime parameter but it only > >>>>>>>>>>>>> handles a > >>>>>>>>>>>>> single time value. > >>>>>>>>>>>> > >>>>>>>>>>>> You should parse the date/time part of the value with > >>>>>>>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it > >>>>>>>>>>>> manually, > >>>>>>>>>>>> that way you'll get most of the validation for free. > >>>>>>>>>>> > >>>>>>>>>>> Yes but it gives a crappy error message, just saying that some > >>>>>>>>>>> data is > >>>>>>>>>>> left over not what is wrong. > >>>>>>>>>> > >>>>>>>>>> IMHO having a separate error message for every field in the time > >>>>>>>>>> string > >>>>>>>>>> (like you do in the patch) is an overkill, simple "invalid time" > >>>>>>>>>> and/or > >>>>>>>>>> "unknown time format" should suffice (we don't have errors like > >>>>>>>>>> "invalid > >>>>>>>>>> 3rd octet" for IP adresses either). > >>>>>>>>> > >>>>>>>>> Well, the work is done, hard to go back on a better error message. > >>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Also, it would be nice to be able to enter the value in more > >>>>>>>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and > >>>>>>>>>>>> normalize > >>>>>>>>>>>> that to LDAP generalized time. > >>>>>>>>>>> > >>>>>>>>>>> When dealing with time there are so many ways to input and > >>>>>>>>>>> display > >>>>>>>>>>> the > >>>>>>>>>>> same values this becomes difficult. > >>>>>>>>>>> > >>>>>>>>>>> I'd expect that the times for these two attributes will be > >>>>>>>>>>> relatively > >>>>>>>>>>> simple and I somehow doubt users are going to want seconds, leap > >>>>>>>>>>> seconds > >>>>>>>>>>> or fractions, but we'll need to consider how to do it for future > >>>>>>>>>>> consistency (otherwise we could have a case where time is > >>>>>>>>>>> entered in > >>>>>>>>>>> one > >>>>>>>>>>> format for some attributes and another for others). > >>>>>>>>>>> > >>>>>>>>>>> If we input in a nice way we need to output in the same way. > >>>>>>>>>> > >>>>>>>>>> We could make the preferred input/output time format > >>>>>>>>>> user-configurable, > >>>>>>>>>> defaulting to current locale time format. This format would be > >>>>>>>>>> used > >>>>>>>>>> for > >>>>>>>>>> output. For input, we could go over a list of formats (first the > >>>>>>>>>> user-configured format, then current locale format, then a > >>>>>>>>>> handful of > >>>>>>>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first > >>>>>>>>>> format > >>>>>>>>>> that can be successfully used to parse the time string. > >>>>>>>>> > >>>>>>>>> See how far you get into the rabbit hole with even this simple > >>>>>>>>> format? > >>>>>>>> > >>>>>>>> I don't mind, as long as it is the right thing to do (IMHO) :) > >>>>>>>> > >>>>>>>> Anyway, I think this could be done on the client side, so we might > >>>>>>>> use > >>>>>>>> your patch without changes. However, I would prefer if the > >>>>>>>> parameter > >>>>>>>> class was more generic, so we could use it (hypothetically) to > >>>>>>>> store > >>>>>>>> time in some other way than LDAP generalized time attribute (at > >>>>>>>> least > >>>>>>>> name it DateTime please). > >>>>>>>> > >>>>>>> > >>>>>>> Ok, I'm fine with that. > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>>> > >>>>>>>>> > >>>>>>>>> The LDAP GeneralizedTime needs to be either in GMT or include a > >>>>>>>>> differential. This gets us into the territory where the client > >>>>>>>>> could be > >>>>>>>>> in a different timezone than the server which leads us to why we > >>>>>>>>> dropped > >>>>>>>>> AccessTime in the first place. > >>>>>>>> > >>>>>>>> Speaking of time zones, the differential alone is not a sufficient > >>>>>>>> time > >>>>>>>> zone description, as it doesn't account for DST. Is there a way to > >>>>>>>> store > >>>>>>>> time in LDAP with full time zone name (just in case it's needed > >>>>>>>> sometime > >>>>>>>> in future)? > >>>>>>> > >>>>>>> There is no way to store DST in LDAP (probably for good reason). > >>>>>>> Oddly > >>>>>>> enough the older LDAP v3 RFC (2252) strongly recommends using only > >>>>>>> GMT > >>>>>>> but the RFC that obsoletes it (4517) does not include this. > >>>>>> > >>>>>> Thanks for the info. > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>>> So I'd like the user to supply the > >>>>>>>>> timezone themselves so I don't have to guess (wrongly) and let > >>>>>>>>> them > >>>>>>>>> worry about differing timezones. > >>>>>>>> > >>>>>>>> We don't have to guess, IIRC there is a way to get the local > >>>>>>>> timezone > >>>>>>>> differential in both Python and JavaScript, so the client could > >>>>>>>> supply > >>>>>>>> it automatically if necessary. > >>>>>>> > >>>>>>> I was thinking more about non-IPA clients (like sudo and notBefore). > >>>>>> > >>>>>> I think this can still be done at least in CLI, but it could be > >>>>>> done in > >>>>>> a separate patch. > >>>>>> > >>>>>>> > >>>>>>> Updated patches attached. > >>>>>>> > >>>>>>> rob > >>>>>> > >>>>>> Patch 919 doesn't cleanly apply on current master (neither does 916 > >>>>>> BTW). > >>>>>> > >>>>>> Honza > >>>>>> > >>>>> > >>>>> Rebased patch (and 916 too, separately). > >>>>> > >>>>> rob > >>>> > >>>> Patch 918: > >>>> > >>>> 1. LDAP generalized time allows you to omit minutes from time zone > >>>> differential, your code treats such values as invalid > >>>> > >>>> 2. IMO a better pattern could be used, such as > >>>> u'^([0-9]{2}){5,7}([.,][0-9]+)?([-+]([0-9]{2}){1,2}|Z)$' > >>>> > >>>> 3. 20120229000Z has malformed minutes, but the error message says > >>>> "Malformed seconds" > >>>> > >>>> 4. 20120229000+0000 has malformed minutes, but the error message says > >>>> "Missing operator for differential or malformed time string" > >>>> > >>>> 5. 201202290000+0000 is valid generalized time, but it causes "Missing > >>>> operator for differential or malformed time string" error > >>>> > >>>> 6. Invalid month/day combinations (such as 201202310000Z) are > >>>> treated as > >>>> valid > >>>> > >>>> 7. When + or - is missing, the error message says "Missing operator > >>>> ..." > >>>> - IMO a better term than "operator" is "sign" in this case > >>>> > >>>> 8. The DateTime docstring includes grammar definition for MINUS, but > >>>> not > >>>> for PLUS, DOT or COMMA. > >>>> > >>>> 9. I'm not too fond of the _rule_required hack. Can't the same thing be > >>>> done in _validate_scalar? > >>>> > >>>> 10. pattern_errmsg should say "Must be of the form YYYYMMDDHH[MM]Z or > >>>> YYYYMMDDHH[MM]{+|-}HHMM" > >>>> > >>>> There might be more bugs in validation that I didn't discover. I would > >>>> suggest you to use a more pythonic approach for the validation code > >>>> (e.g. use partition() to split the time zone and fraction from the rest > >>>> of the value, etc.), the current code is rather C-ish, hard to read and > >>>> apparently error-prone. > >>>> > >>>> > >>>> Patch 919: > >>>> > >>>> 1. sudoorder uniqueness is not properly checked in ipa sudorule-mod: > >>>> > >>>> $ ipa sudorule-add rule1 > >>>> ----------------------- > >>>> Added Sudo Rule "rule1" > >>>> ----------------------- > >>>> Rule name: rule1 > >>>> Enabled: TRUE > >>>> > >>>> $ ipa sudorule-add rule2 --order=0 > >>>> ----------------------- > >>>> Added Sudo Rule "rule2" > >>>> ----------------------- > >>>> Rule name: rule2 > >>>> Enabled: TRUE > >>>> Sudo order: 0 > >>>> > >>>> $ ipa sudorule-add rule3 --order=0 > >>>> ipa: ERROR: invalid 'order': order must be a unique value (0 already > >>>> used by rule2) > >>>> > >>>> $ ipa sudorule-mod rule1 --order=0 > >>>> -------------------------- > >>>> Modified Sudo Rule "rule1" > >>>> -------------------------- > >>>> Rule name: rule1 > >>>> Enabled: TRUE > >>>> Sudo order: 0 > >>>> > >>>> (now both rule1 and rule2 have sudoorder=0) > >>>> > >>>> 2. Shouldn't we check that sudonotbefore <= sudonotafter? > >>>> > >>>> 3. sudonotbefore param doc should say "Start of time interval for which > >>>> the entry is valid (YYYYMMDDHH[MM]Z)" > >>>> > >>>> 4. sudonotafter param doc should say "End of time interval for which > >>>> the > >>>> entry is valid (YYYYMMDDHH[MM]Z)" > >>>> > >>>> 5. In 60ipasudo.ldif, the ipaSudoRule object class is missing the > >>>> sudoOrder, sudoNotBefore and sudoNotAfter attributes. Is this OK? > >>>> > >>>> > >>>> Both patches need to be rebased. > >>>> > >>>> Honza > >>>> > >>> > >>> Ok, lets take this one step at a time. > >>> > >>> This updated patch adds schema for all three attributes but just a Param > >>> for sudoOrder. I'll have to revisit DateTime for notbefore and notafter. > >>> > >>> I addressed the issue with order and added a test for it. > >>> > >>> Schema is fixed on new installs. > > > > ipa-server-install fails with: > > > > [02/Mar/2012:09:13:08 +0100] dse_read_one_file - The entry cn=schema in > > file /etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/schema/60ipasudo.ldif > > (lineno: 1) is invalid, error code 21 (Invalid syntax) - object class > > ipaSudoRule: Unknown allowed attribute type "sudoNotBefore" > > [02/Mar/2012:09:13:08 +0100] dse - Please edit the file to correct the > > reported problems and then restart the server. > > > >>> > >>> rob > >> > >> And now with updated API.txt. Forgot to squash the commit. > >> > >> rob > >> > > > > Honza > > > > And now the right patch The issue with clean install is that the sudo attribute types are shipped in 60sudo.ldif schema, but our schema 60ipasudo.ldif which uses some attributeTypes defined in 60sudo.ldif is alphabetically before 60sudo.ldif and is this processed first. That's why upgrade worked and clean install did not. ACK if you squash with the attached patch which renames 60ipasudo.ldif to 65ipasudo.ldif so that our schema is processed _after_ the bundled 60ipasudo.ldif. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-rename-sudo-ldif.patch Type: text/x-patch Size: 2994 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 2 18:43:42 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 13:43:42 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <1330712929.2123.24.camel@priserak> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> <4F14F131.3080503@redhat.com> <4F4E2AC7.6030107@redhat.com> <4F4FC8C6.2000103@redhat.com> <4F4FD4A0.5020105@redhat.com> <4F508275.4000206@redhat.com> <4F50F7E7.3050409@redhat.com> <1330712929.2123.24.camel@priserak> Message-ID: <4F5114DE.7050107@redhat.com> Martin Kosek wrote: > On Fri, 2012-03-02 at 11:40 -0500, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 1.3.2012 20:57, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> On 17.1.2012 04:55, Rob Crittenden wrote: >>>>>>> Jan Cholasta wrote: >>>>>>>> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): >>>>>>>>> Jan Cholasta wrote: >>>>>>>>>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>>>>>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and >>>>>>>>>>>>>>> sudoNotAfter >>>>>>>>>>>>>>> but these weren't available in the sudorule plugin. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've added support for these. sudoOrder enforces uniqueness >>>>>>>>>>>>>>> because >>>>>>>>>>>>>>> duplicates are undefined. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I also added support for a GeneralizedTime parameter type. >>>>>>>>>>>>>>> This is >>>>>>>>>>>>>>> similar to the existing AccessTime parameter but it only >>>>>>>>>>>>>>> handles a >>>>>>>>>>>>>>> single time value. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You should parse the date/time part of the value with >>>>>>>>>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it >>>>>>>>>>>>>> manually, >>>>>>>>>>>>>> that way you'll get most of the validation for free. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes but it gives a crappy error message, just saying that some >>>>>>>>>>>>> data is >>>>>>>>>>>>> left over not what is wrong. >>>>>>>>>>>> >>>>>>>>>>>> IMHO having a separate error message for every field in the time >>>>>>>>>>>> string >>>>>>>>>>>> (like you do in the patch) is an overkill, simple "invalid time" >>>>>>>>>>>> and/or >>>>>>>>>>>> "unknown time format" should suffice (we don't have errors like >>>>>>>>>>>> "invalid >>>>>>>>>>>> 3rd octet" for IP adresses either). >>>>>>>>>>> >>>>>>>>>>> Well, the work is done, hard to go back on a better error message. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Also, it would be nice to be able to enter the value in more >>>>>>>>>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and >>>>>>>>>>>>>> normalize >>>>>>>>>>>>>> that to LDAP generalized time. >>>>>>>>>>>>> >>>>>>>>>>>>> When dealing with time there are so many ways to input and >>>>>>>>>>>>> display >>>>>>>>>>>>> the >>>>>>>>>>>>> same values this becomes difficult. >>>>>>>>>>>>> >>>>>>>>>>>>> I'd expect that the times for these two attributes will be >>>>>>>>>>>>> relatively >>>>>>>>>>>>> simple and I somehow doubt users are going to want seconds, leap >>>>>>>>>>>>> seconds >>>>>>>>>>>>> or fractions, but we'll need to consider how to do it for future >>>>>>>>>>>>> consistency (otherwise we could have a case where time is >>>>>>>>>>>>> entered in >>>>>>>>>>>>> one >>>>>>>>>>>>> format for some attributes and another for others). >>>>>>>>>>>>> >>>>>>>>>>>>> If we input in a nice way we need to output in the same way. >>>>>>>>>>>> >>>>>>>>>>>> We could make the preferred input/output time format >>>>>>>>>>>> user-configurable, >>>>>>>>>>>> defaulting to current locale time format. This format would be >>>>>>>>>>>> used >>>>>>>>>>>> for >>>>>>>>>>>> output. For input, we could go over a list of formats (first the >>>>>>>>>>>> user-configured format, then current locale format, then a >>>>>>>>>>>> handful of >>>>>>>>>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first >>>>>>>>>>>> format >>>>>>>>>>>> that can be successfully used to parse the time string. >>>>>>>>>>> >>>>>>>>>>> See how far you get into the rabbit hole with even this simple >>>>>>>>>>> format? >>>>>>>>>> >>>>>>>>>> I don't mind, as long as it is the right thing to do (IMHO) :) >>>>>>>>>> >>>>>>>>>> Anyway, I think this could be done on the client side, so we might >>>>>>>>>> use >>>>>>>>>> your patch without changes. However, I would prefer if the >>>>>>>>>> parameter >>>>>>>>>> class was more generic, so we could use it (hypothetically) to >>>>>>>>>> store >>>>>>>>>> time in some other way than LDAP generalized time attribute (at >>>>>>>>>> least >>>>>>>>>> name it DateTime please). >>>>>>>>>> >>>>>>>>> >>>>>>>>> Ok, I'm fine with that. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The LDAP GeneralizedTime needs to be either in GMT or include a >>>>>>>>>>> differential. This gets us into the territory where the client >>>>>>>>>>> could be >>>>>>>>>>> in a different timezone than the server which leads us to why we >>>>>>>>>>> dropped >>>>>>>>>>> AccessTime in the first place. >>>>>>>>>> >>>>>>>>>> Speaking of time zones, the differential alone is not a sufficient >>>>>>>>>> time >>>>>>>>>> zone description, as it doesn't account for DST. Is there a way to >>>>>>>>>> store >>>>>>>>>> time in LDAP with full time zone name (just in case it's needed >>>>>>>>>> sometime >>>>>>>>>> in future)? >>>>>>>>> >>>>>>>>> There is no way to store DST in LDAP (probably for good reason). >>>>>>>>> Oddly >>>>>>>>> enough the older LDAP v3 RFC (2252) strongly recommends using only >>>>>>>>> GMT >>>>>>>>> but the RFC that obsoletes it (4517) does not include this. >>>>>>>> >>>>>>>> Thanks for the info. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> So I'd like the user to supply the >>>>>>>>>>> timezone themselves so I don't have to guess (wrongly) and let >>>>>>>>>>> them >>>>>>>>>>> worry about differing timezones. >>>>>>>>>> >>>>>>>>>> We don't have to guess, IIRC there is a way to get the local >>>>>>>>>> timezone >>>>>>>>>> differential in both Python and JavaScript, so the client could >>>>>>>>>> supply >>>>>>>>>> it automatically if necessary. >>>>>>>>> >>>>>>>>> I was thinking more about non-IPA clients (like sudo and notBefore). >>>>>>>> >>>>>>>> I think this can still be done at least in CLI, but it could be >>>>>>>> done in >>>>>>>> a separate patch. >>>>>>>> >>>>>>>>> >>>>>>>>> Updated patches attached. >>>>>>>>> >>>>>>>>> rob >>>>>>>> >>>>>>>> Patch 919 doesn't cleanly apply on current master (neither does 916 >>>>>>>> BTW). >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> Rebased patch (and 916 too, separately). >>>>>>> >>>>>>> rob >>>>>> >>>>>> Patch 918: >>>>>> >>>>>> 1. LDAP generalized time allows you to omit minutes from time zone >>>>>> differential, your code treats such values as invalid >>>>>> >>>>>> 2. IMO a better pattern could be used, such as >>>>>> u'^([0-9]{2}){5,7}([.,][0-9]+)?([-+]([0-9]{2}){1,2}|Z)$' >>>>>> >>>>>> 3. 20120229000Z has malformed minutes, but the error message says >>>>>> "Malformed seconds" >>>>>> >>>>>> 4. 20120229000+0000 has malformed minutes, but the error message says >>>>>> "Missing operator for differential or malformed time string" >>>>>> >>>>>> 5. 201202290000+0000 is valid generalized time, but it causes "Missing >>>>>> operator for differential or malformed time string" error >>>>>> >>>>>> 6. Invalid month/day combinations (such as 201202310000Z) are >>>>>> treated as >>>>>> valid >>>>>> >>>>>> 7. When + or - is missing, the error message says "Missing operator >>>>>> ..." >>>>>> - IMO a better term than "operator" is "sign" in this case >>>>>> >>>>>> 8. The DateTime docstring includes grammar definition for MINUS, but >>>>>> not >>>>>> for PLUS, DOT or COMMA. >>>>>> >>>>>> 9. I'm not too fond of the _rule_required hack. Can't the same thing be >>>>>> done in _validate_scalar? >>>>>> >>>>>> 10. pattern_errmsg should say "Must be of the form YYYYMMDDHH[MM]Z or >>>>>> YYYYMMDDHH[MM]{+|-}HHMM" >>>>>> >>>>>> There might be more bugs in validation that I didn't discover. I would >>>>>> suggest you to use a more pythonic approach for the validation code >>>>>> (e.g. use partition() to split the time zone and fraction from the rest >>>>>> of the value, etc.), the current code is rather C-ish, hard to read and >>>>>> apparently error-prone. >>>>>> >>>>>> >>>>>> Patch 919: >>>>>> >>>>>> 1. sudoorder uniqueness is not properly checked in ipa sudorule-mod: >>>>>> >>>>>> $ ipa sudorule-add rule1 >>>>>> ----------------------- >>>>>> Added Sudo Rule "rule1" >>>>>> ----------------------- >>>>>> Rule name: rule1 >>>>>> Enabled: TRUE >>>>>> >>>>>> $ ipa sudorule-add rule2 --order=0 >>>>>> ----------------------- >>>>>> Added Sudo Rule "rule2" >>>>>> ----------------------- >>>>>> Rule name: rule2 >>>>>> Enabled: TRUE >>>>>> Sudo order: 0 >>>>>> >>>>>> $ ipa sudorule-add rule3 --order=0 >>>>>> ipa: ERROR: invalid 'order': order must be a unique value (0 already >>>>>> used by rule2) >>>>>> >>>>>> $ ipa sudorule-mod rule1 --order=0 >>>>>> -------------------------- >>>>>> Modified Sudo Rule "rule1" >>>>>> -------------------------- >>>>>> Rule name: rule1 >>>>>> Enabled: TRUE >>>>>> Sudo order: 0 >>>>>> >>>>>> (now both rule1 and rule2 have sudoorder=0) >>>>>> >>>>>> 2. Shouldn't we check that sudonotbefore<= sudonotafter? >>>>>> >>>>>> 3. sudonotbefore param doc should say "Start of time interval for which >>>>>> the entry is valid (YYYYMMDDHH[MM]Z)" >>>>>> >>>>>> 4. sudonotafter param doc should say "End of time interval for which >>>>>> the >>>>>> entry is valid (YYYYMMDDHH[MM]Z)" >>>>>> >>>>>> 5. In 60ipasudo.ldif, the ipaSudoRule object class is missing the >>>>>> sudoOrder, sudoNotBefore and sudoNotAfter attributes. Is this OK? >>>>>> >>>>>> >>>>>> Both patches need to be rebased. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> Ok, lets take this one step at a time. >>>>> >>>>> This updated patch adds schema for all three attributes but just a Param >>>>> for sudoOrder. I'll have to revisit DateTime for notbefore and notafter. >>>>> >>>>> I addressed the issue with order and added a test for it. >>>>> >>>>> Schema is fixed on new installs. >>> >>> ipa-server-install fails with: >>> >>> [02/Mar/2012:09:13:08 +0100] dse_read_one_file - The entry cn=schema in >>> file /etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/schema/60ipasudo.ldif >>> (lineno: 1) is invalid, error code 21 (Invalid syntax) - object class >>> ipaSudoRule: Unknown allowed attribute type "sudoNotBefore" >>> [02/Mar/2012:09:13:08 +0100] dse - Please edit the file to correct the >>> reported problems and then restart the server. >>> >>>>> >>>>> rob >>>> >>>> And now with updated API.txt. Forgot to squash the commit. >>>> >>>> rob >>>> >>> >>> Honza >>> >> >> And now the right patch > > The issue with clean install is that the sudo attribute types are > shipped in 60sudo.ldif schema, but our schema 60ipasudo.ldif which uses > some attributeTypes defined in 60sudo.ldif is alphabetically before > 60sudo.ldif and is this processed first. That's why upgrade worked and > clean install did not. > > ACK if you squash with the attached patch which renames 60ipasudo.ldif > to 65ipasudo.ldif so that our schema is processed _after_ the bundled > 60ipasudo.ldif. > > Martin Good idea, rolled into my patch. I hadn't fixed Honza's mod problem completely either. 0 was essentially a special case because of the way I was looking to see if a sudoorder change was being requested. I fixed that too and added a specific test case for it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-919-6-sudo.patch Type: text/x-diff Size: 25992 bytes Desc: not available URL: From jcholast at redhat.com Fri Mar 2 19:01:50 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 02 Mar 2012 20:01:50 +0100 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F5114DE.7050107@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> <4F14F131.3080503@redhat.com> <4F4E2AC7.6030107@redhat.com> <4F4FC8C6.2000103@redhat.com> <4F4FD4A0.5020105@redhat.com> <4F508275.4000206@redhat.com> <4F50F7E7.3050409@redhat.com> <1330712929.2123.24.camel@priserak> <4F5114DE.7050107@redhat.com> Message-ID: <4F51191E.80304@redhat.com> On 2.3.2012 19:43, Rob Crittenden wrote: > Martin Kosek wrote: >> On Fri, 2012-03-02 at 11:40 -0500, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 1.3.2012 20:57, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> Jan Cholasta wrote: >>>>>>> On 17.1.2012 04:55, Rob Crittenden wrote: >>>>>>>> Jan Cholasta wrote: >>>>>>>>> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): >>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >>>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>>>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>>>>>>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and >>>>>>>>>>>>>>>> sudoNotAfter >>>>>>>>>>>>>>>> but these weren't available in the sudorule plugin. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've added support for these. sudoOrder enforces uniqueness >>>>>>>>>>>>>>>> because >>>>>>>>>>>>>>>> duplicates are undefined. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I also added support for a GeneralizedTime parameter type. >>>>>>>>>>>>>>>> This is >>>>>>>>>>>>>>>> similar to the existing AccessTime parameter but it only >>>>>>>>>>>>>>>> handles a >>>>>>>>>>>>>>>> single time value. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You should parse the date/time part of the value with >>>>>>>>>>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it >>>>>>>>>>>>>>> manually, >>>>>>>>>>>>>>> that way you'll get most of the validation for free. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes but it gives a crappy error message, just saying that >>>>>>>>>>>>>> some >>>>>>>>>>>>>> data is >>>>>>>>>>>>>> left over not what is wrong. >>>>>>>>>>>>> >>>>>>>>>>>>> IMHO having a separate error message for every field in the >>>>>>>>>>>>> time >>>>>>>>>>>>> string >>>>>>>>>>>>> (like you do in the patch) is an overkill, simple "invalid >>>>>>>>>>>>> time" >>>>>>>>>>>>> and/or >>>>>>>>>>>>> "unknown time format" should suffice (we don't have errors >>>>>>>>>>>>> like >>>>>>>>>>>>> "invalid >>>>>>>>>>>>> 3rd octet" for IP adresses either). >>>>>>>>>>>> >>>>>>>>>>>> Well, the work is done, hard to go back on a better error >>>>>>>>>>>> message. >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also, it would be nice to be able to enter the value in more >>>>>>>>>>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and >>>>>>>>>>>>>>> normalize >>>>>>>>>>>>>>> that to LDAP generalized time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> When dealing with time there are so many ways to input and >>>>>>>>>>>>>> display >>>>>>>>>>>>>> the >>>>>>>>>>>>>> same values this becomes difficult. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd expect that the times for these two attributes will be >>>>>>>>>>>>>> relatively >>>>>>>>>>>>>> simple and I somehow doubt users are going to want >>>>>>>>>>>>>> seconds, leap >>>>>>>>>>>>>> seconds >>>>>>>>>>>>>> or fractions, but we'll need to consider how to do it for >>>>>>>>>>>>>> future >>>>>>>>>>>>>> consistency (otherwise we could have a case where time is >>>>>>>>>>>>>> entered in >>>>>>>>>>>>>> one >>>>>>>>>>>>>> format for some attributes and another for others). >>>>>>>>>>>>>> >>>>>>>>>>>>>> If we input in a nice way we need to output in the same way. >>>>>>>>>>>>> >>>>>>>>>>>>> We could make the preferred input/output time format >>>>>>>>>>>>> user-configurable, >>>>>>>>>>>>> defaulting to current locale time format. This format would be >>>>>>>>>>>>> used >>>>>>>>>>>>> for >>>>>>>>>>>>> output. For input, we could go over a list of formats >>>>>>>>>>>>> (first the >>>>>>>>>>>>> user-configured format, then current locale format, then a >>>>>>>>>>>>> handful of >>>>>>>>>>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first >>>>>>>>>>>>> format >>>>>>>>>>>>> that can be successfully used to parse the time string. >>>>>>>>>>>> >>>>>>>>>>>> See how far you get into the rabbit hole with even this simple >>>>>>>>>>>> format? >>>>>>>>>>> >>>>>>>>>>> I don't mind, as long as it is the right thing to do (IMHO) :) >>>>>>>>>>> >>>>>>>>>>> Anyway, I think this could be done on the client side, so we >>>>>>>>>>> might >>>>>>>>>>> use >>>>>>>>>>> your patch without changes. However, I would prefer if the >>>>>>>>>>> parameter >>>>>>>>>>> class was more generic, so we could use it (hypothetically) to >>>>>>>>>>> store >>>>>>>>>>> time in some other way than LDAP generalized time attribute (at >>>>>>>>>>> least >>>>>>>>>>> name it DateTime please). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ok, I'm fine with that. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The LDAP GeneralizedTime needs to be either in GMT or include a >>>>>>>>>>>> differential. This gets us into the territory where the client >>>>>>>>>>>> could be >>>>>>>>>>>> in a different timezone than the server which leads us to >>>>>>>>>>>> why we >>>>>>>>>>>> dropped >>>>>>>>>>>> AccessTime in the first place. >>>>>>>>>>> >>>>>>>>>>> Speaking of time zones, the differential alone is not a >>>>>>>>>>> sufficient >>>>>>>>>>> time >>>>>>>>>>> zone description, as it doesn't account for DST. Is there a >>>>>>>>>>> way to >>>>>>>>>>> store >>>>>>>>>>> time in LDAP with full time zone name (just in case it's needed >>>>>>>>>>> sometime >>>>>>>>>>> in future)? >>>>>>>>>> >>>>>>>>>> There is no way to store DST in LDAP (probably for good reason). >>>>>>>>>> Oddly >>>>>>>>>> enough the older LDAP v3 RFC (2252) strongly recommends using >>>>>>>>>> only >>>>>>>>>> GMT >>>>>>>>>> but the RFC that obsoletes it (4517) does not include this. >>>>>>>>> >>>>>>>>> Thanks for the info. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> So I'd like the user to supply the >>>>>>>>>>>> timezone themselves so I don't have to guess (wrongly) and let >>>>>>>>>>>> them >>>>>>>>>>>> worry about differing timezones. >>>>>>>>>>> >>>>>>>>>>> We don't have to guess, IIRC there is a way to get the local >>>>>>>>>>> timezone >>>>>>>>>>> differential in both Python and JavaScript, so the client could >>>>>>>>>>> supply >>>>>>>>>>> it automatically if necessary. >>>>>>>>>> >>>>>>>>>> I was thinking more about non-IPA clients (like sudo and >>>>>>>>>> notBefore). >>>>>>>>> >>>>>>>>> I think this can still be done at least in CLI, but it could be >>>>>>>>> done in >>>>>>>>> a separate patch. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Updated patches attached. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> >>>>>>>>> Patch 919 doesn't cleanly apply on current master (neither does >>>>>>>>> 916 >>>>>>>>> BTW). >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> >>>>>>>> Rebased patch (and 916 too, separately). >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> Patch 918: >>>>>>> >>>>>>> 1. LDAP generalized time allows you to omit minutes from time zone >>>>>>> differential, your code treats such values as invalid >>>>>>> >>>>>>> 2. IMO a better pattern could be used, such as >>>>>>> u'^([0-9]{2}){5,7}([.,][0-9]+)?([-+]([0-9]{2}){1,2}|Z)$' >>>>>>> >>>>>>> 3. 20120229000Z has malformed minutes, but the error message says >>>>>>> "Malformed seconds" >>>>>>> >>>>>>> 4. 20120229000+0000 has malformed minutes, but the error message >>>>>>> says >>>>>>> "Missing operator for differential or malformed time string" >>>>>>> >>>>>>> 5. 201202290000+0000 is valid generalized time, but it causes >>>>>>> "Missing >>>>>>> operator for differential or malformed time string" error >>>>>>> >>>>>>> 6. Invalid month/day combinations (such as 201202310000Z) are >>>>>>> treated as >>>>>>> valid >>>>>>> >>>>>>> 7. When + or - is missing, the error message says "Missing operator >>>>>>> ..." >>>>>>> - IMO a better term than "operator" is "sign" in this case >>>>>>> >>>>>>> 8. The DateTime docstring includes grammar definition for MINUS, but >>>>>>> not >>>>>>> for PLUS, DOT or COMMA. >>>>>>> >>>>>>> 9. I'm not too fond of the _rule_required hack. Can't the same >>>>>>> thing be >>>>>>> done in _validate_scalar? >>>>>>> >>>>>>> 10. pattern_errmsg should say "Must be of the form >>>>>>> YYYYMMDDHH[MM]Z or >>>>>>> YYYYMMDDHH[MM]{+|-}HHMM" >>>>>>> >>>>>>> There might be more bugs in validation that I didn't discover. I >>>>>>> would >>>>>>> suggest you to use a more pythonic approach for the validation code >>>>>>> (e.g. use partition() to split the time zone and fraction from >>>>>>> the rest >>>>>>> of the value, etc.), the current code is rather C-ish, hard to >>>>>>> read and >>>>>>> apparently error-prone. >>>>>>> >>>>>>> >>>>>>> Patch 919: >>>>>>> >>>>>>> 1. sudoorder uniqueness is not properly checked in ipa sudorule-mod: >>>>>>> >>>>>>> $ ipa sudorule-add rule1 >>>>>>> ----------------------- >>>>>>> Added Sudo Rule "rule1" >>>>>>> ----------------------- >>>>>>> Rule name: rule1 >>>>>>> Enabled: TRUE >>>>>>> >>>>>>> $ ipa sudorule-add rule2 --order=0 >>>>>>> ----------------------- >>>>>>> Added Sudo Rule "rule2" >>>>>>> ----------------------- >>>>>>> Rule name: rule2 >>>>>>> Enabled: TRUE >>>>>>> Sudo order: 0 >>>>>>> >>>>>>> $ ipa sudorule-add rule3 --order=0 >>>>>>> ipa: ERROR: invalid 'order': order must be a unique value (0 already >>>>>>> used by rule2) >>>>>>> >>>>>>> $ ipa sudorule-mod rule1 --order=0 >>>>>>> -------------------------- >>>>>>> Modified Sudo Rule "rule1" >>>>>>> -------------------------- >>>>>>> Rule name: rule1 >>>>>>> Enabled: TRUE >>>>>>> Sudo order: 0 >>>>>>> >>>>>>> (now both rule1 and rule2 have sudoorder=0) >>>>>>> >>>>>>> 2. Shouldn't we check that sudonotbefore<= sudonotafter? >>>>>>> >>>>>>> 3. sudonotbefore param doc should say "Start of time interval for >>>>>>> which >>>>>>> the entry is valid (YYYYMMDDHH[MM]Z)" >>>>>>> >>>>>>> 4. sudonotafter param doc should say "End of time interval for which >>>>>>> the >>>>>>> entry is valid (YYYYMMDDHH[MM]Z)" >>>>>>> >>>>>>> 5. In 60ipasudo.ldif, the ipaSudoRule object class is missing the >>>>>>> sudoOrder, sudoNotBefore and sudoNotAfter attributes. Is this OK? >>>>>>> >>>>>>> >>>>>>> Both patches need to be rebased. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> Ok, lets take this one step at a time. >>>>>> >>>>>> This updated patch adds schema for all three attributes but just a >>>>>> Param >>>>>> for sudoOrder. I'll have to revisit DateTime for notbefore and >>>>>> notafter. >>>>>> >>>>>> I addressed the issue with order and added a test for it. >>>>>> >>>>>> Schema is fixed on new installs. >>>> >>>> ipa-server-install fails with: >>>> >>>> [02/Mar/2012:09:13:08 +0100] dse_read_one_file - The entry cn=schema in >>>> file /etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/schema/60ipasudo.ldif >>>> (lineno: 1) is invalid, error code 21 (Invalid syntax) - object class >>>> ipaSudoRule: Unknown allowed attribute type "sudoNotBefore" >>>> [02/Mar/2012:09:13:08 +0100] dse - Please edit the file to correct the >>>> reported problems and then restart the server. >>>> >>>>>> >>>>>> rob >>>>> >>>>> And now with updated API.txt. Forgot to squash the commit. >>>>> >>>>> rob >>>>> >>>> >>>> Honza >>>> >>> >>> And now the right patch >> >> The issue with clean install is that the sudo attribute types are >> shipped in 60sudo.ldif schema, but our schema 60ipasudo.ldif which uses >> some attributeTypes defined in 60sudo.ldif is alphabetically before >> 60sudo.ldif and is this processed first. That's why upgrade worked and >> clean install did not. >> >> ACK if you squash with the attached patch which renames 60ipasudo.ldif >> to 65ipasudo.ldif so that our schema is processed _after_ the bundled >> 60ipasudo.ldif. >> >> Martin > > Good idea, rolled into my patch. > > I hadn't fixed Honza's mod problem completely either. 0 was essentially > a special case because of the way I was looking to see if a sudoorder > change was being requested. I fixed that too and added a specific test > case for it. > > rob ACK. Honza -- Jan Cholasta From mkosek at redhat.com Fri Mar 2 19:02:38 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Mar 2012 20:02:38 +0100 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4F51191E.80304@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> <4F14F131.3080503@redhat.com> <4F4E2AC7.6030107@redhat.com> <4F4FC8C6.2000103@redhat.com> <4F4FD4A0.5020105@redhat.com> <4F508275.4000206@redhat.com> <4F50F7E7.3050409@redhat.com> <1330712929.2123.24.camel@priserak> <4F5114DE.7050107@redhat.com> <4F51191E.80304@redhat.com> Message-ID: <1330714958.2123.25.camel@priserak> On Fri, 2012-03-02 at 20:01 +0100, Jan Cholasta wrote: > On 2.3.2012 19:43, Rob Crittenden wrote: > > Martin Kosek wrote: > >> On Fri, 2012-03-02 at 11:40 -0500, Rob Crittenden wrote: > >>> Jan Cholasta wrote: > >>>> On 1.3.2012 20:57, Rob Crittenden wrote: > >>>>> Rob Crittenden wrote: > >>>>>> Jan Cholasta wrote: > >>>>>>> On 17.1.2012 04:55, Rob Crittenden wrote: > >>>>>>>> Jan Cholasta wrote: > >>>>>>>>> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): > >>>>>>>>>> Jan Cholasta wrote: > >>>>>>>>>>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): > >>>>>>>>>>>> Jan Cholasta wrote: > >>>>>>>>>>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): > >>>>>>>>>>>>>> Jan Cholasta wrote: > >>>>>>>>>>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): > >>>>>>>>>>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and > >>>>>>>>>>>>>>>> sudoNotAfter > >>>>>>>>>>>>>>>> but these weren't available in the sudorule plugin. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I've added support for these. sudoOrder enforces uniqueness > >>>>>>>>>>>>>>>> because > >>>>>>>>>>>>>>>> duplicates are undefined. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I also added support for a GeneralizedTime parameter type. > >>>>>>>>>>>>>>>> This is > >>>>>>>>>>>>>>>> similar to the existing AccessTime parameter but it only > >>>>>>>>>>>>>>>> handles a > >>>>>>>>>>>>>>>> single time value. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> You should parse the date/time part of the value with > >>>>>>>>>>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it > >>>>>>>>>>>>>>> manually, > >>>>>>>>>>>>>>> that way you'll get most of the validation for free. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Yes but it gives a crappy error message, just saying that > >>>>>>>>>>>>>> some > >>>>>>>>>>>>>> data is > >>>>>>>>>>>>>> left over not what is wrong. > >>>>>>>>>>>>> > >>>>>>>>>>>>> IMHO having a separate error message for every field in the > >>>>>>>>>>>>> time > >>>>>>>>>>>>> string > >>>>>>>>>>>>> (like you do in the patch) is an overkill, simple "invalid > >>>>>>>>>>>>> time" > >>>>>>>>>>>>> and/or > >>>>>>>>>>>>> "unknown time format" should suffice (we don't have errors > >>>>>>>>>>>>> like > >>>>>>>>>>>>> "invalid > >>>>>>>>>>>>> 3rd octet" for IP adresses either). > >>>>>>>>>>>> > >>>>>>>>>>>> Well, the work is done, hard to go back on a better error > >>>>>>>>>>>> message. > >>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Also, it would be nice to be able to enter the value in more > >>>>>>>>>>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and > >>>>>>>>>>>>>>> normalize > >>>>>>>>>>>>>>> that to LDAP generalized time. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> When dealing with time there are so many ways to input and > >>>>>>>>>>>>>> display > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>> same values this becomes difficult. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I'd expect that the times for these two attributes will be > >>>>>>>>>>>>>> relatively > >>>>>>>>>>>>>> simple and I somehow doubt users are going to want > >>>>>>>>>>>>>> seconds, leap > >>>>>>>>>>>>>> seconds > >>>>>>>>>>>>>> or fractions, but we'll need to consider how to do it for > >>>>>>>>>>>>>> future > >>>>>>>>>>>>>> consistency (otherwise we could have a case where time is > >>>>>>>>>>>>>> entered in > >>>>>>>>>>>>>> one > >>>>>>>>>>>>>> format for some attributes and another for others). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> If we input in a nice way we need to output in the same way. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We could make the preferred input/output time format > >>>>>>>>>>>>> user-configurable, > >>>>>>>>>>>>> defaulting to current locale time format. This format would be > >>>>>>>>>>>>> used > >>>>>>>>>>>>> for > >>>>>>>>>>>>> output. For input, we could go over a list of formats > >>>>>>>>>>>>> (first the > >>>>>>>>>>>>> user-configured format, then current locale format, then a > >>>>>>>>>>>>> handful of > >>>>>>>>>>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first > >>>>>>>>>>>>> format > >>>>>>>>>>>>> that can be successfully used to parse the time string. > >>>>>>>>>>>> > >>>>>>>>>>>> See how far you get into the rabbit hole with even this simple > >>>>>>>>>>>> format? > >>>>>>>>>>> > >>>>>>>>>>> I don't mind, as long as it is the right thing to do (IMHO) :) > >>>>>>>>>>> > >>>>>>>>>>> Anyway, I think this could be done on the client side, so we > >>>>>>>>>>> might > >>>>>>>>>>> use > >>>>>>>>>>> your patch without changes. However, I would prefer if the > >>>>>>>>>>> parameter > >>>>>>>>>>> class was more generic, so we could use it (hypothetically) to > >>>>>>>>>>> store > >>>>>>>>>>> time in some other way than LDAP generalized time attribute (at > >>>>>>>>>>> least > >>>>>>>>>>> name it DateTime please). > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Ok, I'm fine with that. > >>>>>>>>> > >>>>>>>>> Thanks. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> The LDAP GeneralizedTime needs to be either in GMT or include a > >>>>>>>>>>>> differential. This gets us into the territory where the client > >>>>>>>>>>>> could be > >>>>>>>>>>>> in a different timezone than the server which leads us to > >>>>>>>>>>>> why we > >>>>>>>>>>>> dropped > >>>>>>>>>>>> AccessTime in the first place. > >>>>>>>>>>> > >>>>>>>>>>> Speaking of time zones, the differential alone is not a > >>>>>>>>>>> sufficient > >>>>>>>>>>> time > >>>>>>>>>>> zone description, as it doesn't account for DST. Is there a > >>>>>>>>>>> way to > >>>>>>>>>>> store > >>>>>>>>>>> time in LDAP with full time zone name (just in case it's needed > >>>>>>>>>>> sometime > >>>>>>>>>>> in future)? > >>>>>>>>>> > >>>>>>>>>> There is no way to store DST in LDAP (probably for good reason). > >>>>>>>>>> Oddly > >>>>>>>>>> enough the older LDAP v3 RFC (2252) strongly recommends using > >>>>>>>>>> only > >>>>>>>>>> GMT > >>>>>>>>>> but the RFC that obsoletes it (4517) does not include this. > >>>>>>>>> > >>>>>>>>> Thanks for the info. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> So I'd like the user to supply the > >>>>>>>>>>>> timezone themselves so I don't have to guess (wrongly) and let > >>>>>>>>>>>> them > >>>>>>>>>>>> worry about differing timezones. > >>>>>>>>>>> > >>>>>>>>>>> We don't have to guess, IIRC there is a way to get the local > >>>>>>>>>>> timezone > >>>>>>>>>>> differential in both Python and JavaScript, so the client could > >>>>>>>>>>> supply > >>>>>>>>>>> it automatically if necessary. > >>>>>>>>>> > >>>>>>>>>> I was thinking more about non-IPA clients (like sudo and > >>>>>>>>>> notBefore). > >>>>>>>>> > >>>>>>>>> I think this can still be done at least in CLI, but it could be > >>>>>>>>> done in > >>>>>>>>> a separate patch. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Updated patches attached. > >>>>>>>>>> > >>>>>>>>>> rob > >>>>>>>>> > >>>>>>>>> Patch 919 doesn't cleanly apply on current master (neither does > >>>>>>>>> 916 > >>>>>>>>> BTW). > >>>>>>>>> > >>>>>>>>> Honza > >>>>>>>>> > >>>>>>>> > >>>>>>>> Rebased patch (and 916 too, separately). > >>>>>>>> > >>>>>>>> rob > >>>>>>> > >>>>>>> Patch 918: > >>>>>>> > >>>>>>> 1. LDAP generalized time allows you to omit minutes from time zone > >>>>>>> differential, your code treats such values as invalid > >>>>>>> > >>>>>>> 2. IMO a better pattern could be used, such as > >>>>>>> u'^([0-9]{2}){5,7}([.,][0-9]+)?([-+]([0-9]{2}){1,2}|Z)$' > >>>>>>> > >>>>>>> 3. 20120229000Z has malformed minutes, but the error message says > >>>>>>> "Malformed seconds" > >>>>>>> > >>>>>>> 4. 20120229000+0000 has malformed minutes, but the error message > >>>>>>> says > >>>>>>> "Missing operator for differential or malformed time string" > >>>>>>> > >>>>>>> 5. 201202290000+0000 is valid generalized time, but it causes > >>>>>>> "Missing > >>>>>>> operator for differential or malformed time string" error > >>>>>>> > >>>>>>> 6. Invalid month/day combinations (such as 201202310000Z) are > >>>>>>> treated as > >>>>>>> valid > >>>>>>> > >>>>>>> 7. When + or - is missing, the error message says "Missing operator > >>>>>>> ..." > >>>>>>> - IMO a better term than "operator" is "sign" in this case > >>>>>>> > >>>>>>> 8. The DateTime docstring includes grammar definition for MINUS, but > >>>>>>> not > >>>>>>> for PLUS, DOT or COMMA. > >>>>>>> > >>>>>>> 9. I'm not too fond of the _rule_required hack. Can't the same > >>>>>>> thing be > >>>>>>> done in _validate_scalar? > >>>>>>> > >>>>>>> 10. pattern_errmsg should say "Must be of the form > >>>>>>> YYYYMMDDHH[MM]Z or > >>>>>>> YYYYMMDDHH[MM]{+|-}HHMM" > >>>>>>> > >>>>>>> There might be more bugs in validation that I didn't discover. I > >>>>>>> would > >>>>>>> suggest you to use a more pythonic approach for the validation code > >>>>>>> (e.g. use partition() to split the time zone and fraction from > >>>>>>> the rest > >>>>>>> of the value, etc.), the current code is rather C-ish, hard to > >>>>>>> read and > >>>>>>> apparently error-prone. > >>>>>>> > >>>>>>> > >>>>>>> Patch 919: > >>>>>>> > >>>>>>> 1. sudoorder uniqueness is not properly checked in ipa sudorule-mod: > >>>>>>> > >>>>>>> $ ipa sudorule-add rule1 > >>>>>>> ----------------------- > >>>>>>> Added Sudo Rule "rule1" > >>>>>>> ----------------------- > >>>>>>> Rule name: rule1 > >>>>>>> Enabled: TRUE > >>>>>>> > >>>>>>> $ ipa sudorule-add rule2 --order=0 > >>>>>>> ----------------------- > >>>>>>> Added Sudo Rule "rule2" > >>>>>>> ----------------------- > >>>>>>> Rule name: rule2 > >>>>>>> Enabled: TRUE > >>>>>>> Sudo order: 0 > >>>>>>> > >>>>>>> $ ipa sudorule-add rule3 --order=0 > >>>>>>> ipa: ERROR: invalid 'order': order must be a unique value (0 already > >>>>>>> used by rule2) > >>>>>>> > >>>>>>> $ ipa sudorule-mod rule1 --order=0 > >>>>>>> -------------------------- > >>>>>>> Modified Sudo Rule "rule1" > >>>>>>> -------------------------- > >>>>>>> Rule name: rule1 > >>>>>>> Enabled: TRUE > >>>>>>> Sudo order: 0 > >>>>>>> > >>>>>>> (now both rule1 and rule2 have sudoorder=0) > >>>>>>> > >>>>>>> 2. Shouldn't we check that sudonotbefore<= sudonotafter? > >>>>>>> > >>>>>>> 3. sudonotbefore param doc should say "Start of time interval for > >>>>>>> which > >>>>>>> the entry is valid (YYYYMMDDHH[MM]Z)" > >>>>>>> > >>>>>>> 4. sudonotafter param doc should say "End of time interval for which > >>>>>>> the > >>>>>>> entry is valid (YYYYMMDDHH[MM]Z)" > >>>>>>> > >>>>>>> 5. In 60ipasudo.ldif, the ipaSudoRule object class is missing the > >>>>>>> sudoOrder, sudoNotBefore and sudoNotAfter attributes. Is this OK? > >>>>>>> > >>>>>>> > >>>>>>> Both patches need to be rebased. > >>>>>>> > >>>>>>> Honza > >>>>>>> > >>>>>> > >>>>>> Ok, lets take this one step at a time. > >>>>>> > >>>>>> This updated patch adds schema for all three attributes but just a > >>>>>> Param > >>>>>> for sudoOrder. I'll have to revisit DateTime for notbefore and > >>>>>> notafter. > >>>>>> > >>>>>> I addressed the issue with order and added a test for it. > >>>>>> > >>>>>> Schema is fixed on new installs. > >>>> > >>>> ipa-server-install fails with: > >>>> > >>>> [02/Mar/2012:09:13:08 +0100] dse_read_one_file - The entry cn=schema in > >>>> file /etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/schema/60ipasudo.ldif > >>>> (lineno: 1) is invalid, error code 21 (Invalid syntax) - object class > >>>> ipaSudoRule: Unknown allowed attribute type "sudoNotBefore" > >>>> [02/Mar/2012:09:13:08 +0100] dse - Please edit the file to correct the > >>>> reported problems and then restart the server. > >>>> > >>>>>> > >>>>>> rob > >>>>> > >>>>> And now with updated API.txt. Forgot to squash the commit. > >>>>> > >>>>> rob > >>>>> > >>>> > >>>> Honza > >>>> > >>> > >>> And now the right patch > >> > >> The issue with clean install is that the sudo attribute types are > >> shipped in 60sudo.ldif schema, but our schema 60ipasudo.ldif which uses > >> some attributeTypes defined in 60sudo.ldif is alphabetically before > >> 60sudo.ldif and is this processed first. That's why upgrade worked and > >> clean install did not. > >> > >> ACK if you squash with the attached patch which renames 60ipasudo.ldif > >> to 65ipasudo.ldif so that our schema is processed _after_ the bundled > >> 60ipasudo.ldif. > >> > >> Martin > > > > Good idea, rolled into my patch. > > > > I hadn't fixed Honza's mod problem completely either. 0 was essentially > > a special case because of the way I was looking to see if a sudoorder > > change was being requested. I fixed that too and added a specific test > > case for it. > > > > rob > > ACK. > > Honza > ACK from me as well. Installation is now ok, no redundant attributetypes. Martin From orquidea.peramor at gmail.com Fri Mar 2 19:13:11 2012 From: orquidea.peramor at gmail.com (Orquidea Salt mas) Date: Fri, 2 Mar 2012 20:13:11 +0100 Subject: [Freeipa-devel] =?iso-8859-1?q?Reb=E9late_by_self-management=2C_f?= =?iso-8859-1?q?irst_project_of_free_software_by_which_we_bet_all_/?= =?iso-8859-1?q?_Reb=E9late_por_la_autogesti=F3n=2C_primer_proyecto?= =?iso-8859-1?q?_de_software_libre_por_el_que_apostamos_todas?= Message-ID: Ingl?s : Many already we have contributed to the first project of free software dedicated to self-management in this campaign of collective financing, it collaborates and it spreads!/ Beginning campaign collective financing http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion?lang=en Login to enter with user of social networks and for would register in Goteo : http://www.goteo.org/user/login?lang=en Rebelaos! Publication by self-management A massive publication that floods the public transport, the work centers, the parks, the consumption centers, by means of distribution of 500,000 gratuitous units, acting simultaneously in all sides and nowhere. We announce the main tool of a vestibule Web for the management of self-sustaining resources by means of Drupal, in addition in the publication there will be an article dedicated to free software, hardware, It is being prepared in ingl?s, the machinery You can see more details in the index of the publication https://n-1.cc/pg/file/read/1151902/indexresumen-de-los-contenidos-pdf . A computer system that allows us to share resources in all the scopes of our life so that we do not have to generate means different for each subject nor for each territory. A point of contact digitalis to generate projects of life outside Capitalism and to margin of the State. A tool to spread and to impel the social transformation through the resources that will set out in their contents around self-management, the autoorganizaci?n, the disobedience and the collective action. In which the capitalist system goes to the collapse, in a while immersed in a deep systemic crisis (ecological, political and economic, but mainly of values), where individual and collective of people they are being lacking of his fundamental rights, is necessary to develop a horizontal collective process where all the human beings we pruned to interact in equality of conditions and freedom. To interact means to relate to us (as much human as economically), to communicate to us, to cover our basic needs, to generate and to protect communal properties, to know and to provide collective solutions us problematic that our lives interfere. We want abrir a breach within normality in the monotonous life state-capitalist, a day anyone, that finally will not be any day. By means of this publication we try: - To drive a horizontal collective process where all and all we pruned to interact in equality of conditions and freedom. - To create communications network between the people it jeopardize with the change and arranged to act. - To find collective solutions to problematic that our lives interfere - To facilitate the access to resources that make possible self-management. - To participate in the construction of networks of mutual support, generated horizontals, asamblearias and from the base. - To publish all this information in an attractive format stops to facilitate the access to all the society. There are 15 days remaining for the upcoming March 15, the day that will come Rebelaos!, Magazine for the selfmanagement Today, we issue the cover of Rebelaos! (Castilian version) that can be displayed on the following link: https://n-1.cc/pg/file/read/1200503/portada-15-de-marzo-rebelaos The contents of the store owners to us by 15 March. Do you? Do you keep on 15 March? In addition, we have over 200 distribution nodes, distributed throughout the Spanish state. Check the map: https://afinidadrebelde.crowdmap.com/ On the other hand, the funding campaign continues to move and still have 12 days to collect the remaining 6,000 euros. We can all make a bit for all the grains of sand become a great beach on March 15. You can access the co-financing campaign: http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Rebel Affinity group www.rebelaos.net ------------------------------------------------------------------------------- Castellano: Muchos ya hemos aportado al primer proyecto de software libre dedicado a la la financiaci?n colectiva, colabora y diffunde !!!!! Inicio campa?a financiaci?n colectiva goteo.org www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Link para registrarse en Goteo y acceder a redes sociales para colaborar en la difus?n http://www.goteo.org/user/login ?Rebelaos! Publicaci?n por la autogesti?n Una publicaci?n masiva que inunde el transporte p?blico, los centros de trabajo, los parques, los centros de consumo, mediante la distribuci?n de 500.000 ejemplares gratuitos, actuando simult?neamente en todos lados y en ninguna parte. Anunciamos la herramienta principal de un portal web para la gesti?n de recursos autogestionados mediante Drupal, adem?s en la publicaci?n habr? un art?culo dedicado al software libre, el hardware, la maquinaria... Puedes ver m?s detalles en el ?ndice de la publicaci?n https://n-1.cc/pg/file/read/1151902/indexresumen-de-los-contenidos-pdf Un sistema inf?rmatico que nos permita compartir recursos en todos los ?mbitos de nuestra vida de forma que no tengamos que generar un medio distinto para cada tema ni para cada territorio. Un punto de encuentro digital para generar proyectos de vida fuera del capitalismo y al margen del Estado. Una herramienta para difundir e impulsar la transformaci?n social a trav?s de los recursos que se propondr?n en sus contenidos en torno a la autogesti?n, la autoorganizaci?n, la desobediencia y la acci?n colectiva. En un momento en que el sistema capitalista se dirige al colapso, inmerso en una profunda crisis sist?mica (ecol?gica, pol?tica y econ?mica, pero principalmente de valores), donde individuos y colectivos de personas est?n siendo desprovistos de sus derechos fundamentales, es necesario desarrollar un proceso colectivo horizontal donde todos los seres humanos podamos interactuar en igualdad de condiciones y en libertad. Interactuar significa relacionarnos (tanto humana como econ?micamente), comunicarnos, cubrir nuestras necesidades b?sicas, generar y proteger bienes comunes, conocernos y dar soluciones colectivas a problem?ticas que interfieren nuestras vidas. Queremos abrir una brecha dentro de la normalidad en la mon?tona vida estatal-capitalista, un d?a cualquiera, que finalmente no ser? cualquier d?a. Mediante esta publicaci?n pretendemos: - Impulsar un proceso colectivo horizontal donde todos y todas podamos interactuar en igualdad de condiciones y en libertad. - Crear red de comunicaciones entre las personas comprometidas con el cambio y dispuestas a actuar. - Encontrar soluciones colectivas a problem?ticas que interfieren nuestras vidas. - Facilitar el acceso a recursos que posibiliten la autogesti?n. - Participar en la construcci?n de redes de apoyo mutuo, horizontales, asamblearias y generadas desde la base. - Publicar toda esta informaci?n en un formato atractivo para facilitar el acceso a toda la sociedad. Son 15 los d?as que restan para el pr?ximo 15 de marzo, d?a en el que ver? la luz ?Rebelaos!, publicaci?n por la autogesti?n. Hoy, hacemos p?blica la portada de ?Rebelaos! (versi?n en castellano) que pod?is visualizar en el siguiente enlace: https://n-1.cc/pg/file/read/1200503/portada-15-de-marzo-rebelaos El contenido de los titulares nos los guardamos para el 15 de marzo. ?Y t?? ?Te guardas el 15 de marzo? Adem?s, ya hemos superado los 200 nodos de distribuci?n, repartidos por todo el estado espa?ol. Ver el mapa: https://afinidadrebelde.crowdmap.com/ Por otro lado, la campa?a de financiaci?n contin?a avanzando y todav?a quedan 12 d?as para reunir los 6.000 euros que restan. Todas podemos aportar un poco para que todos los granitos de arena se conviertan en una gran playa el 15 de marzo. Pod?is acceder a la campa?a de cofinanciaci?n en: http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Colectivo Afinidad Rebelde www.rebelaos.net From rcritten at redhat.com Fri Mar 2 19:16:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 14:16:03 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <1330714958.2123.25.camel@priserak> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> <4EE8BEEF.1080408@redhat.com> <4F06B9D4.6010300@redhat.com> <4F105E3C.3090907@redhat.com> <4F145E15.7050609@redhat.com> <4F14F131.3080503@redhat.com> <4F4E2AC7.6030107@redhat.com> <4F4FC8C6.2000103@redhat.com> <4F4FD4A0.5020105@redhat.com> <4F508275.4000206@redhat.com> <4F50F7E7.3050409@redhat.com> <1330712929.2123.24.camel@priserak> <4F5114DE.7050107@redhat.com> <4F51191E.80304@redhat.com> <1330714958.2123.25.camel@priserak> Message-ID: <4F511C73.9000702@redhat.com> Martin Kosek wrote: > On Fri, 2012-03-02 at 20:01 +0100, Jan Cholasta wrote: >> On 2.3.2012 19:43, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On Fri, 2012-03-02 at 11:40 -0500, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> On 1.3.2012 20:57, Rob Crittenden wrote: >>>>>>> Rob Crittenden wrote: >>>>>>>> Jan Cholasta wrote: >>>>>>>>> On 17.1.2012 04:55, Rob Crittenden wrote: >>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>> Dne 13.1.2012 17:39, Rob Crittenden napsal(a): >>>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>>> Dne 14.12.2011 16:21, Rob Crittenden napsal(a): >>>>>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>>>>> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >>>>>>>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>>>>>>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>>>>>>>>>>>>>>>> The sudo schema now defines sudoOrder, sudoNotBefore and >>>>>>>>>>>>>>>>>> sudoNotAfter >>>>>>>>>>>>>>>>>> but these weren't available in the sudorule plugin. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I've added support for these. sudoOrder enforces uniqueness >>>>>>>>>>>>>>>>>> because >>>>>>>>>>>>>>>>>> duplicates are undefined. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I also added support for a GeneralizedTime parameter type. >>>>>>>>>>>>>>>>>> This is >>>>>>>>>>>>>>>>>> similar to the existing AccessTime parameter but it only >>>>>>>>>>>>>>>>>> handles a >>>>>>>>>>>>>>>>>> single time value. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You should parse the date/time part of the value with >>>>>>>>>>>>>>>>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it >>>>>>>>>>>>>>>>> manually, >>>>>>>>>>>>>>>>> that way you'll get most of the validation for free. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes but it gives a crappy error message, just saying that >>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>> data is >>>>>>>>>>>>>>>> left over not what is wrong. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> IMHO having a separate error message for every field in the >>>>>>>>>>>>>>> time >>>>>>>>>>>>>>> string >>>>>>>>>>>>>>> (like you do in the patch) is an overkill, simple "invalid >>>>>>>>>>>>>>> time" >>>>>>>>>>>>>>> and/or >>>>>>>>>>>>>>> "unknown time format" should suffice (we don't have errors >>>>>>>>>>>>>>> like >>>>>>>>>>>>>>> "invalid >>>>>>>>>>>>>>> 3rd octet" for IP adresses either). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Well, the work is done, hard to go back on a better error >>>>>>>>>>>>>> message. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also, it would be nice to be able to enter the value in more >>>>>>>>>>>>>>>>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and >>>>>>>>>>>>>>>>> normalize >>>>>>>>>>>>>>>>> that to LDAP generalized time. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> When dealing with time there are so many ways to input and >>>>>>>>>>>>>>>> display >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> same values this becomes difficult. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'd expect that the times for these two attributes will be >>>>>>>>>>>>>>>> relatively >>>>>>>>>>>>>>>> simple and I somehow doubt users are going to want >>>>>>>>>>>>>>>> seconds, leap >>>>>>>>>>>>>>>> seconds >>>>>>>>>>>>>>>> or fractions, but we'll need to consider how to do it for >>>>>>>>>>>>>>>> future >>>>>>>>>>>>>>>> consistency (otherwise we could have a case where time is >>>>>>>>>>>>>>>> entered in >>>>>>>>>>>>>>>> one >>>>>>>>>>>>>>>> format for some attributes and another for others). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If we input in a nice way we need to output in the same way. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We could make the preferred input/output time format >>>>>>>>>>>>>>> user-configurable, >>>>>>>>>>>>>>> defaulting to current locale time format. This format would be >>>>>>>>>>>>>>> used >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> output. For input, we could go over a list of formats >>>>>>>>>>>>>>> (first the >>>>>>>>>>>>>>> user-configured format, then current locale format, then a >>>>>>>>>>>>>>> handful of >>>>>>>>>>>>>>> "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first >>>>>>>>>>>>>>> format >>>>>>>>>>>>>>> that can be successfully used to parse the time string. >>>>>>>>>>>>>> >>>>>>>>>>>>>> See how far you get into the rabbit hole with even this simple >>>>>>>>>>>>>> format? >>>>>>>>>>>>> >>>>>>>>>>>>> I don't mind, as long as it is the right thing to do (IMHO) :) >>>>>>>>>>>>> >>>>>>>>>>>>> Anyway, I think this could be done on the client side, so we >>>>>>>>>>>>> might >>>>>>>>>>>>> use >>>>>>>>>>>>> your patch without changes. However, I would prefer if the >>>>>>>>>>>>> parameter >>>>>>>>>>>>> class was more generic, so we could use it (hypothetically) to >>>>>>>>>>>>> store >>>>>>>>>>>>> time in some other way than LDAP generalized time attribute (at >>>>>>>>>>>>> least >>>>>>>>>>>>> name it DateTime please). >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Ok, I'm fine with that. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The LDAP GeneralizedTime needs to be either in GMT or include a >>>>>>>>>>>>>> differential. This gets us into the territory where the client >>>>>>>>>>>>>> could be >>>>>>>>>>>>>> in a different timezone than the server which leads us to >>>>>>>>>>>>>> why we >>>>>>>>>>>>>> dropped >>>>>>>>>>>>>> AccessTime in the first place. >>>>>>>>>>>>> >>>>>>>>>>>>> Speaking of time zones, the differential alone is not a >>>>>>>>>>>>> sufficient >>>>>>>>>>>>> time >>>>>>>>>>>>> zone description, as it doesn't account for DST. Is there a >>>>>>>>>>>>> way to >>>>>>>>>>>>> store >>>>>>>>>>>>> time in LDAP with full time zone name (just in case it's needed >>>>>>>>>>>>> sometime >>>>>>>>>>>>> in future)? >>>>>>>>>>>> >>>>>>>>>>>> There is no way to store DST in LDAP (probably for good reason). >>>>>>>>>>>> Oddly >>>>>>>>>>>> enough the older LDAP v3 RFC (2252) strongly recommends using >>>>>>>>>>>> only >>>>>>>>>>>> GMT >>>>>>>>>>>> but the RFC that obsoletes it (4517) does not include this. >>>>>>>>>>> >>>>>>>>>>> Thanks for the info. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> So I'd like the user to supply the >>>>>>>>>>>>>> timezone themselves so I don't have to guess (wrongly) and let >>>>>>>>>>>>>> them >>>>>>>>>>>>>> worry about differing timezones. >>>>>>>>>>>>> >>>>>>>>>>>>> We don't have to guess, IIRC there is a way to get the local >>>>>>>>>>>>> timezone >>>>>>>>>>>>> differential in both Python and JavaScript, so the client could >>>>>>>>>>>>> supply >>>>>>>>>>>>> it automatically if necessary. >>>>>>>>>>>> >>>>>>>>>>>> I was thinking more about non-IPA clients (like sudo and >>>>>>>>>>>> notBefore). >>>>>>>>>>> >>>>>>>>>>> I think this can still be done at least in CLI, but it could be >>>>>>>>>>> done in >>>>>>>>>>> a separate patch. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Updated patches attached. >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>> Patch 919 doesn't cleanly apply on current master (neither does >>>>>>>>>>> 916 >>>>>>>>>>> BTW). >>>>>>>>>>> >>>>>>>>>>> Honza >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Rebased patch (and 916 too, separately). >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> >>>>>>>>> Patch 918: >>>>>>>>> >>>>>>>>> 1. LDAP generalized time allows you to omit minutes from time zone >>>>>>>>> differential, your code treats such values as invalid >>>>>>>>> >>>>>>>>> 2. IMO a better pattern could be used, such as >>>>>>>>> u'^([0-9]{2}){5,7}([.,][0-9]+)?([-+]([0-9]{2}){1,2}|Z)$' >>>>>>>>> >>>>>>>>> 3. 20120229000Z has malformed minutes, but the error message says >>>>>>>>> "Malformed seconds" >>>>>>>>> >>>>>>>>> 4. 20120229000+0000 has malformed minutes, but the error message >>>>>>>>> says >>>>>>>>> "Missing operator for differential or malformed time string" >>>>>>>>> >>>>>>>>> 5. 201202290000+0000 is valid generalized time, but it causes >>>>>>>>> "Missing >>>>>>>>> operator for differential or malformed time string" error >>>>>>>>> >>>>>>>>> 6. Invalid month/day combinations (such as 201202310000Z) are >>>>>>>>> treated as >>>>>>>>> valid >>>>>>>>> >>>>>>>>> 7. When + or - is missing, the error message says "Missing operator >>>>>>>>> ..." >>>>>>>>> - IMO a better term than "operator" is "sign" in this case >>>>>>>>> >>>>>>>>> 8. The DateTime docstring includes grammar definition for MINUS, but >>>>>>>>> not >>>>>>>>> for PLUS, DOT or COMMA. >>>>>>>>> >>>>>>>>> 9. I'm not too fond of the _rule_required hack. Can't the same >>>>>>>>> thing be >>>>>>>>> done in _validate_scalar? >>>>>>>>> >>>>>>>>> 10. pattern_errmsg should say "Must be of the form >>>>>>>>> YYYYMMDDHH[MM]Z or >>>>>>>>> YYYYMMDDHH[MM]{+|-}HHMM" >>>>>>>>> >>>>>>>>> There might be more bugs in validation that I didn't discover. I >>>>>>>>> would >>>>>>>>> suggest you to use a more pythonic approach for the validation code >>>>>>>>> (e.g. use partition() to split the time zone and fraction from >>>>>>>>> the rest >>>>>>>>> of the value, etc.), the current code is rather C-ish, hard to >>>>>>>>> read and >>>>>>>>> apparently error-prone. >>>>>>>>> >>>>>>>>> >>>>>>>>> Patch 919: >>>>>>>>> >>>>>>>>> 1. sudoorder uniqueness is not properly checked in ipa sudorule-mod: >>>>>>>>> >>>>>>>>> $ ipa sudorule-add rule1 >>>>>>>>> ----------------------- >>>>>>>>> Added Sudo Rule "rule1" >>>>>>>>> ----------------------- >>>>>>>>> Rule name: rule1 >>>>>>>>> Enabled: TRUE >>>>>>>>> >>>>>>>>> $ ipa sudorule-add rule2 --order=0 >>>>>>>>> ----------------------- >>>>>>>>> Added Sudo Rule "rule2" >>>>>>>>> ----------------------- >>>>>>>>> Rule name: rule2 >>>>>>>>> Enabled: TRUE >>>>>>>>> Sudo order: 0 >>>>>>>>> >>>>>>>>> $ ipa sudorule-add rule3 --order=0 >>>>>>>>> ipa: ERROR: invalid 'order': order must be a unique value (0 already >>>>>>>>> used by rule2) >>>>>>>>> >>>>>>>>> $ ipa sudorule-mod rule1 --order=0 >>>>>>>>> -------------------------- >>>>>>>>> Modified Sudo Rule "rule1" >>>>>>>>> -------------------------- >>>>>>>>> Rule name: rule1 >>>>>>>>> Enabled: TRUE >>>>>>>>> Sudo order: 0 >>>>>>>>> >>>>>>>>> (now both rule1 and rule2 have sudoorder=0) >>>>>>>>> >>>>>>>>> 2. Shouldn't we check that sudonotbefore<= sudonotafter? >>>>>>>>> >>>>>>>>> 3. sudonotbefore param doc should say "Start of time interval for >>>>>>>>> which >>>>>>>>> the entry is valid (YYYYMMDDHH[MM]Z)" >>>>>>>>> >>>>>>>>> 4. sudonotafter param doc should say "End of time interval for which >>>>>>>>> the >>>>>>>>> entry is valid (YYYYMMDDHH[MM]Z)" >>>>>>>>> >>>>>>>>> 5. In 60ipasudo.ldif, the ipaSudoRule object class is missing the >>>>>>>>> sudoOrder, sudoNotBefore and sudoNotAfter attributes. Is this OK? >>>>>>>>> >>>>>>>>> >>>>>>>>> Both patches need to be rebased. >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> >>>>>>>> Ok, lets take this one step at a time. >>>>>>>> >>>>>>>> This updated patch adds schema for all three attributes but just a >>>>>>>> Param >>>>>>>> for sudoOrder. I'll have to revisit DateTime for notbefore and >>>>>>>> notafter. >>>>>>>> >>>>>>>> I addressed the issue with order and added a test for it. >>>>>>>> >>>>>>>> Schema is fixed on new installs. >>>>>> >>>>>> ipa-server-install fails with: >>>>>> >>>>>> [02/Mar/2012:09:13:08 +0100] dse_read_one_file - The entry cn=schema in >>>>>> file /etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/schema/60ipasudo.ldif >>>>>> (lineno: 1) is invalid, error code 21 (Invalid syntax) - object class >>>>>> ipaSudoRule: Unknown allowed attribute type "sudoNotBefore" >>>>>> [02/Mar/2012:09:13:08 +0100] dse - Please edit the file to correct the >>>>>> reported problems and then restart the server. >>>>>> >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> And now with updated API.txt. Forgot to squash the commit. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> And now the right patch >>>> >>>> The issue with clean install is that the sudo attribute types are >>>> shipped in 60sudo.ldif schema, but our schema 60ipasudo.ldif which uses >>>> some attributeTypes defined in 60sudo.ldif is alphabetically before >>>> 60sudo.ldif and is this processed first. That's why upgrade worked and >>>> clean install did not. >>>> >>>> ACK if you squash with the attached patch which renames 60ipasudo.ldif >>>> to 65ipasudo.ldif so that our schema is processed _after_ the bundled >>>> 60ipasudo.ldif. >>>> >>>> Martin >>> >>> Good idea, rolled into my patch. >>> >>> I hadn't fixed Honza's mod problem completely either. 0 was essentially >>> a special case because of the way I was looking to see if a sudoorder >>> change was being requested. I fixed that too and added a specific test >>> case for it. >>> >>> rob >> >> ACK. >> >> Honza >> > > ACK from me as well. Installation is now ok, no redundant > attributetypes. > > Martin > I made one minor change before pushing. I set the minvalue for sudoorder to 0, < 0 is undefined. Pushed to master and ipa-2-2 rob From rcritten at redhat.com Fri Mar 2 20:01:16 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 15:01:16 -0500 Subject: [Freeipa-devel] [PATCH] 221 Fix encoding for setattr/addattr/delattr In-Reply-To: <1329914805.27833.7.camel@balmora.brq.redhat.com> References: <1329914805.27833.7.camel@balmora.brq.redhat.com> Message-ID: <4F51270C.1080105@redhat.com> Martin Kosek wrote: > Attribute values passed by --{set,add,del}attr parameters were > normalized and validated using appropriate parameter, but were > never encoded for the backend. This make prevents manipulation > with dirsvr BOOL attributes where framework tries to pass > boolean value instead of encoded "TRUE"/"FALSE" values. > > https://fedorahosted.org/freeipa/ticket/2418 ACK, pushed to master and ipa-2-2 From rcritten at redhat.com Fri Mar 2 20:02:18 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 15:02:18 -0500 Subject: [Freeipa-devel] [PATCH] fix hbactest failures Message-ID: <4F51274A.5060505@redhat.com> Another module with some now invalid domain names caught by new validator. Pushed under one-liner rule. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: hbactest.patch Type: text/x-diff Size: 1025 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 2 20:08:09 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 15:08:09 -0500 Subject: [Freeipa-devel] [PATCH] 229 Add help for new structured DNS framework In-Reply-To: <1330607416.4451.19.camel@balmora.brq.redhat.com> References: <1330607416.4451.19.camel@balmora.brq.redhat.com> Message-ID: <4F5128A9.8020402@redhat.com> Martin Kosek wrote: > DNS Test Day shown that the new RR specific DNS options and the > concepts behind them may not be easily understood. This patch adds > an explanation of the new DNS framework for structured options > to make it easier for the user to understand and use the new > options. > > https://fedorahosted.org/freeipa/ticket/2382 ACK, pushed to master and ipa-2-2 rob From rcritten at redhat.com Fri Mar 2 20:22:22 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 15:22:22 -0500 Subject: [Freeipa-devel] [PATCH] 225 Improve dnsrecord interactive help In-Reply-To: <1330440190.1134.10.camel@balmora.brq.redhat.com> References: <1330440190.1134.10.camel@balmora.brq.redhat.com> Message-ID: <4F512BFE.5000506@redhat.com> Martin Kosek wrote: > This patch is build on top of my DNS patches 218-220 > ---- > > Add 2 new features to DNS record interactive help to increase its > usability and also make its behavior more consistent with standard > parameter interactive help: > > 1) Ask for missing DNS parts > When a required part of a newly added DNS record was missing, we > just returned a ValidationError. Now, the interactive help rather > asks for all missing required parts of all DNS records that were > being added by its parts. > > 2) Let user amend invalid part > When an interactive help asked for a DNS record part value and > user enters an invalid value, the entire interactive help exits > with an error. This may upset a user if he already entered several > correct DNS record part values. Now, the help rather tells user > what's wrong and give him an opportunity to amend the value. > > https://fedorahosted.org/freeipa/ticket/2386 > > ------------- > A demonstration of the new features: > > # ipa dnsrecord-add example.com foo --mx-exchanger=mx.example.com. > MX Preference: 0<<< we don't fail now > Record name: foo > MX record: 0 mx.example.com. > > # ipa dnsrecord-add example.com foo > Please choose a type of DNS resource record to be added > The most common types for this type of zone are: A, AAAA > > DNS resource record type: LOC > LOC Degrees Latitude: 1 > [LOC Minutes Latitude]: 1000<<< we don't fail with invalid values! >>>> LOC Minutes Latitude: can be at most 59 > [LOC Minutes Latitude]: 50 > [LOC Seconds Latitude]: > LOC Direction Latitude: E >>>> LOC Direction Latitude: must be one of (u'N', u'S') > LOC Direction Latitude: N > LOC Degrees Longtitude: 2 > [LOC Minutes Longtitude]: > [LOC Seconds Longtitude]: > LOC Direction Longtitude: E > LOC Altitude: 123 > [LOC Size]: > [LOC Horizontal Precision]: > [LOC Vertical Precision]: > Record name: foo > LOC record: 1 50 N 2 E 123.00 > MX record: 0 mx.example.com. ACK, pushed to master and ipa-2-2 rob From rcritten at redhat.com Fri Mar 2 20:34:45 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Mar 2012 15:34:45 -0500 Subject: [Freeipa-devel] [PATCH] fix API for suduOrder Message-ID: <4F512EE5.3070002@redhat.com> I modified minvalue of sudoOrder without updating API.txt. I bumped VERSION to reflect the new option as well. Pushed to ipa-2-2 and master as a one liner. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-API.txt-and-VERSION-to-reflect-new-sudoOrder-opt.patch Type: text/x-diff Size: 4290 bytes Desc: not available URL: From JR.Aquino at citrix.com Fri Mar 2 21:51:07 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 2 Mar 2012 21:51:07 +0000 Subject: [Freeipa-devel] [PATCH] 41-2 During ipa-client-install verify forward and reverse dns lookup of server In-Reply-To: <2BAFC1AA-C712-418B-B3C6-92D655193A28@citrixonline.com> References: <0E422ADE-6BC6-4085-A9EE-262403C7670E@citrixonline.com> <2BAFC1AA-C712-418B-B3C6-92D655193A28@citrixonline.com> Message-ID: On Feb 28, 2012, at 10:43 AM, JR Aquino wrote: > On Feb 23, 2012, at 3:56 PM, JR Aquino wrote: > >> ipa-server-install has a method for validating forward and reverse via ipaserver/install/installutils.py >> ipa-client-install does not currently have an equivalent >> This patch adds valid_dns to ipapython/ipautil.py to validate foward and reverse DNS >> This patch adds the valid_dns test in ipa-client/ipa-install/ipa-client-install to validate the dns of the FreeIPA server >> >> https://fedorahosted.org/freeipa/ticket/2438 > > Rebased and corrected patch > > NEW Rebased and corrected patch -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jraquino-0041-During-ipa-client-install-verify-forward-and-reve.patch Type: application/octet-stream Size: 17626 bytes Desc: freeipa-jraquino-0041-During-ipa-client-install-verify-forward-and-reve.patch URL: From dpal at redhat.com Sat Mar 3 23:33:06 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 03 Mar 2012 18:33:06 -0500 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <4F4F7A71.7060708@redhat.com> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> Message-ID: <4F52AA32.5070200@redhat.com> On 03/01/2012 08:32 AM, Ondrej Hamada wrote: > On 02/29/2012 04:36 PM, Simo Sorce wrote: >> On Wed, 2012-02-29 at 16:19 +0100, Ondrej Hamada wrote: >>> Hi everyone, >>> I'm currently working on my thesis. It's objective is $SUBJ and we >>> already have ticket for that: #194. The task is to create two more >>> replica types - the HUB and Consumer. In 389-DS both the HUB and >>> Consumer are read-only. Additionally the HUB can push the data to the >>> Consumers. >>> >>> In case of FreeIPA the server is not only providing data, but also >>> services like CA, NTP, DNS, Kerberos. Therefore I'm kindly asking you >>> for advices and opinions on that: >>> >>> 1. What should be the position of HUB? >>> I mean should it be used as an interconnection between Masters and >>> Consumers only, so that it will be 'hidden' in the topology and only >>> forwards the updates, or should the HUB be also used as a regular >>> Consumer which has additional ability to push the updates further to >>> Consumers/HUBS? >>> >> I would think that having shadow HUBs would make things more reliable. >> >>> 2. Which services should be available on HUB and Consumer? >>> I think, the priority of these replicas would be to answer to data >>> request by ipa whatever-(find|show) commands or to provide some LDAP >>> data for email addressing etc. Also it shouldn't cause much trouble to >>> run NTP on Consumer, but what about Kerberos or CA? Is it a good >>> solution to let users authenticate against these replicas? Is it >>> correct to leave classified data like passwords on these replicas? >> CA's clearly have no place in a read-only replica in my mind. >> >> Kerberos stuff is different. The problem with a read-only replica and >> Kerberos is that krb needs to write data for local user lockouts. >> Password changes can be avoided by allowing kadmind only on full >> masters. >> >> There is also another angle to consider and that is the Rad-Only Domain >> Controller (RODC) available in the Microsoft world. This kind of server >> is even more limited than a read-only replica as it does not contain the >> full data. To do that it requires quite some tweaking on the KDC >> component too, so maybe it is out of scope, but it may make sense >> reading up on what they do to have a sense of the kind of services they >> enable/disable on read only servers. > > I've read some articles about RODC and according to them, RODC is > supposed to be used in branch offices where could be problem providing > physical security of the machine - therefore RODC doesn't contain any > passwords or confident data. The authentication requests must be > forwarded to regular Domain Controller, but it is also possible to > cache some credentials - usually the credentials of users that uses > the RODC frequently, so that possible crack of RODC affects only this > small group of users. If someone's credentials are not cached and the > connection is broken between RODC and DC, he can't log in. RODC also > supports read-only DNS. > > If the consumer should really be read-only, then the RODC way seems to > be exactly what we are looking for. >> Simo. >> > > This sounds like enabling DS pass-through PAM proxy using SSSD to relay to IPA if user connects via LDAP and use AuthHub if he authenticates using Kerberos is something you should consider. I would start exploring those projects and features but the setup would be pretty complex. May be it can be tuned down in some way with a special plugin like AuthHub that would go directly to SSSD. -- 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 Sun Mar 4 01:04:36 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 03 Mar 2012 20:04:36 -0500 Subject: [Freeipa-devel] [PATCH] 979 kinit before connect in client Message-ID: <4F52BFA4.3070107@redhat.com> I'm not sure why this didn't always fail but in the client installer we were creating a connection before calling kinit. I re-arranged this in and beefed up the client logging. While testing this I periodically ran into an NSS shutdown error where the ping() connection hadn't closed before the host_mod to add the SSH keys was run. This stores dbdir in the connection so we can check to see if the same database is being used so NSSConnection can skip the nss_init(). I tested client installs using: ipa-client-install --enable-dns-updates --ssh-trust-dns This same error was reported when installing a replica with --setup-dns. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-979-client.patch Type: text/x-patch Size: 6969 bytes Desc: not available URL: From simo at redhat.com Sun Mar 4 21:23:31 2012 From: simo at redhat.com (Simo Sorce) Date: Sun, 04 Mar 2012 16:23:31 -0500 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <4F52AA32.5070200@redhat.com> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> Message-ID: <1330896212.26197.32.camel@willson.li.ssimo.org> On Sat, 2012-03-03 at 18:33 -0500, Dmitri Pal wrote: > On 03/01/2012 08:32 AM, Ondrej Hamada wrote: > > On 02/29/2012 04:36 PM, Simo Sorce wrote: > >> On Wed, 2012-02-29 at 16:19 +0100, Ondrej Hamada wrote: > >>> Hi everyone, > >>> I'm currently working on my thesis. It's objective is $SUBJ and we > >>> already have ticket for that: #194. The task is to create two more > >>> replica types - the HUB and Consumer. In 389-DS both the HUB and > >>> Consumer are read-only. Additionally the HUB can push the data to the > >>> Consumers. > >>> > >>> In case of FreeIPA the server is not only providing data, but also > >>> services like CA, NTP, DNS, Kerberos. Therefore I'm kindly asking you > >>> for advices and opinions on that: > >>> > >>> 1. What should be the position of HUB? > >>> I mean should it be used as an interconnection between Masters and > >>> Consumers only, so that it will be 'hidden' in the topology and only > >>> forwards the updates, or should the HUB be also used as a regular > >>> Consumer which has additional ability to push the updates further to > >>> Consumers/HUBS? > >>> > >> I would think that having shadow HUBs would make things more reliable. > >> > >>> 2. Which services should be available on HUB and Consumer? > >>> I think, the priority of these replicas would be to answer to data > >>> request by ipa whatever-(find|show) commands or to provide some LDAP > >>> data for email addressing etc. Also it shouldn't cause much trouble to > >>> run NTP on Consumer, but what about Kerberos or CA? Is it a good > >>> solution to let users authenticate against these replicas? Is it > >>> correct to leave classified data like passwords on these replicas? > >> CA's clearly have no place in a read-only replica in my mind. > >> > >> Kerberos stuff is different. The problem with a read-only replica and > >> Kerberos is that krb needs to write data for local user lockouts. > >> Password changes can be avoided by allowing kadmind only on full > >> masters. > >> > >> There is also another angle to consider and that is the Rad-Only Domain > >> Controller (RODC) available in the Microsoft world. This kind of server > >> is even more limited than a read-only replica as it does not contain the > >> full data. To do that it requires quite some tweaking on the KDC > >> component too, so maybe it is out of scope, but it may make sense > >> reading up on what they do to have a sense of the kind of services they > >> enable/disable on read only servers. > > > > I've read some articles about RODC and according to them, RODC is > > supposed to be used in branch offices where could be problem providing > > physical security of the machine - therefore RODC doesn't contain any > > passwords or confident data. The authentication requests must be > > forwarded to regular Domain Controller, but it is also possible to > > cache some credentials - usually the credentials of users that uses > > the RODC frequently, so that possible crack of RODC affects only this > > small group of users. If someone's credentials are not cached and the > > connection is broken between RODC and DC, he can't log in. RODC also > > supports read-only DNS. > > > > If the consumer should really be read-only, then the RODC way seems to > > be exactly what we are looking for. > >> Simo. > >> > > > > > This sounds like enabling DS pass-through PAM proxy using SSSD to relay > to IPA if user connects via LDAP and use AuthHub if he authenticates > using Kerberos is something you should consider. I would start exploring > those projects and features but the setup would be pretty complex. May > be it can be tuned down in some way with a special plugin like AuthHub > that would go directly to SSSD. I am not so sure your characterization is really spot on. For ldap binds we would probably have a much simpler plugin than PAm-passthrough and simply perform a bind against the remote server. For kerberos, keep in mind that authhub needs a special client and sends password over the wire (yes encrypted, still makes little difference). It is not a solution where normal kerberos clients and services are involved (authhub does not help you if you have a keytab and want to kinit with it). For many years it will be a good solution for 2FA, but hardly applicable beyond that. For a read-only KDC we need to investigate what's the better solution. There are many ways we can handle the issue, one of the simplest is probably to allow the RO KDC to use a special LDAP Extended operation against a full R/W server to get the user keys to sign, authenticating with a special R/O KDC principal. We can also investigate how MS does internal forwarding and do something similar as I suspect that's something samba4-RODC will want to implement too, so we could share some of the development burden there. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Mon Mar 5 08:43:36 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 05 Mar 2012 09:43:36 +0100 Subject: [Freeipa-devel] [PATCH] 979 kinit before connect in client In-Reply-To: <4F52BFA4.3070107@redhat.com> References: <4F52BFA4.3070107@redhat.com> Message-ID: <4F547CB8.6080405@redhat.com> On 4.3.2012 02:04, Rob Crittenden wrote: > I'm not sure why this didn't always fail but in the client installer we > were creating a connection before calling kinit. I re-arranged this in > and beefed up the client logging. > > While testing this I periodically ran into an NSS shutdown error where > the ping() connection hadn't closed before the host_mod to add the SSH > keys was run. > > This stores dbdir in the connection so we can check to see if the same > database is being used so NSSConnection can skip the nss_init(). > > I tested client installs using: ipa-client-install --enable-dns-updates > --ssh-trust-dns > > This same error was reported when installing a replica with --setup-dns. > > rob > ACK, both ipa-client-install and ipa-replica-install work fine now. However, in __nss_initialized we should check for SSLTransport instead of KerbTransport (as dbdir is set in SSLTransport) and we don't have to check for its subclasses (because isinstance checks them automatically). Also, we can make the function more readable by getting rid of the nested ifs: + def __nss_initialized(self, dbdir): + """ + If there is another connections open it may have already + initialized NSS. This is likely to lead to an NSS shutdown + failure. One way to mitigate this is to tell NSS to not + initialize if it has already been done in another open connection. + + Returns True if another connection is using the same db. + """ + for value in context.__dict__.values(): + if not isinstance(value, Connection): + continue + if not isinstance(value.conn._ServerProxy__transport, SSLTransport): + continue + if value.conn._ServerProxy__transport.dbdir == dbdir: + return True + return False Honza -- Jan Cholasta From atkac at redhat.com Mon Mar 5 11:32:53 2012 From: atkac at redhat.com (Adam Tkac) Date: Mon, 5 Mar 2012 12:32:53 +0100 Subject: [Freeipa-devel] [PATCH] 0009 Support for IPv6 elements in idnsForwarders attribute In-Reply-To: <4F4FC625.3000108@redhat.com> References: <4F4E31E1.7010406@redhat.com> <4F4E32AF.9050601@redhat.com> <1330529440.25597.50.camel@willson.li.ssimo.org> <4F4E47D4.3030700@redhat.com> <1330533225.32367.25.camel@balmora.brq.redhat.com> <4F4F8615.8020804@redhat.com> <4F4FC625.3000108@redhat.com> Message-ID: <20120305113252.GB7168@redhat.com> On Thu, Mar 01, 2012 at 07:55:33PM +0100, Petr Spacek wrote: > Hello, > > here is (again) reworked patch for > https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . > > Adam pointed me to existing BIND parser, which I missed. Now is all > parsing & socket magic done inside BIND libraries. Our code is a bit > shorter and syntax is 100% BIND-compatible. (But it means same as > discussed yesterday :-) > > Adam, please review it. Thanks for the patch Petr, see my comments below. > Petr^2 Spacek > > On 03/01/2012 03:22 PM, Petr Spacek wrote: > >Hello, > > > >here is reworked patch for > >https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . > > > >Changes after yesterday's discussion on IRC with Simo and Mkosek: > >It follows BIND9 syntax for optional specification of port & adds > >documentation for this new syntax. > > > >Petr^2 Spacek > > > >On 02/29/2012 05:33 PM, Martin Kosek wrote: > >>I agree that we should keep the BIND syntax and separate port and IP > >>address with a space. We will at least avoid possible issues with IP > >>address decoding in the future. > >> > >>Since this is a new attribute we have a good chance to do changes now so > >>that it is used correctly. I created an upstream ticket to change the > >>behavior and validators in FreeIPA: > >> > >>https://fedorahosted.org/freeipa/ticket/2462 > >> > >>Martin > >> > >>On Wed, 2012-02-29 at 16:44 +0100, Petr Spacek wrote: > >>>On 02/29/2012 04:30 PM, Simo Sorce wrote: > >>>>Either way looks ok to me. > >>>>I agree that using a space may be less confusing if this syntax never > >>>>allows to specify multiple addresses. > >>>>If multiple address can be specified than it may be less ideal to use > >>>>spaces. > >>>> > >>>>Simo. > >>> > >>>idnsForwarders is multi-value attribute, so each value contain single > >>>forwarder address. > >>> > >>>Petr^2 Spacek > >>> > >>>>On Wed, 2012-02-29 at 15:14 +0100, Petr Spacek wrote: > >>>>>And there is the patch, sorry. > >>>>> > >>>>>Petr^2 > >>>>> > >>>>>On 02/29/2012 03:10 PM, Petr Spacek wrote: > >>>>>>Hello, > >>>>>> > >>>>>>this patch fixes https://fedorahosted.org/bind-dyndb-ldap/ticket/49 , > >>>>>>but I want to discuss one (unimplemented) change: > >>>>>> > >>>>>>I propose a change in (currently very strange) forwarders syntax. > >>>>>> > >>>>>>Current syntax: > >>>>>>[.port] > >>>>>> > >>>>>>examples: > >>>>>>1.2.3.4 (without optional port) > >>>>>>1.2.3.4.5553 (optional port 5553) > >>>>>>A::B (IPv6, without optional port) > >>>>>>A::B.5553 > >>>>>>::FFFF:1.2.3.4 (6to4, without optional port) > >>>>>>::FFFF:1.2.3.4.5553 (6to4, with optional port 5553) > >>>>>> > >>>>>>I find this syntax confusing, non-standard and not-typo-proof. > >>>>>> > >>>>>> > >>>>>>IMHO better choice is to follow BIND forwarders syntax: > >>>>>> [port ip_port] (port is string delimited with spaces) > >>>>>> > >>>>>>(From: http://www.zytrax.com/books/dns/ch7/queries.html#forwarders) > >>>>>> > >>>>>> > >>>>>>*Current syntax is not documented*, so probably is not used anywhere. > >>>>>>(And DNS server on non-standard port is probably useful only for > >>>>>>testing > >>>>>>purposes, but it's another story.) > >>>>>> > >>>>>> > >>>>>>What is you opinion? > From 14056200915a90c2a957e8a2219819bd3b7f9365 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 1 Mar 2012 15:08:10 +0100 > Subject: [PATCH] Add support for IPv6 elements in idnsForwarders attribute > and make syntax compatible with BIND9 forwarders. > Signed-off-by: Petr Spacek > > --- > NEWS | 3 + > README | 8 ++- > src/acl.c | 89 ++++++++++++++++++++++++++++++++++ > src/acl.h | 3 + > src/ldap_helper.c | 136 ++++++----------------------------------------------- > 5 files changed, 116 insertions(+), 123 deletions(-) > > diff --git a/NEWS b/NEWS > index ced6250..a97a5f3 100644 > --- a/NEWS > +++ b/NEWS > @@ -1,3 +1,6 @@ > +[1] Add support for IPv6 elements in idnsForwarders attribute > + and make syntax compatible with BIND9 forwarders. > + > 1.1.0a2 > ====== > > diff --git a/README b/README > index 914abdc..aedb88c 100644 > --- a/README > +++ b/README > @@ -89,8 +89,12 @@ example zone ldif is available in the doc directory. > with a valid idnsForwarders attribute. > > * idnsForwarders > - Defines multiple IP addresses (TODO: optional port numbers) to which > - queries will be forwarded. > + Defines multiple IP addresses to which queries will be forwarded. > + It is multi-value attribute: Each IP address (and optional port) has to > + be in own value. BIND9 syntax for "forwarders" is required. > + Optional port can be specified by adding " port " after IP > + address. IPv4 and IPv6 addresses are supported. > + Examples: "1.2.3.4" or "1.2.3.4 port 553" or "A::B" or "A::B port 553" In my opinion we should mark the idnsForwarders attribute single-value and deal with them as with idnsAllow{Query,Transfer} (i.e. specify forwarders splitted by semi-colon). It will be more consistent with idnsAllow{Query,Transfer}. What do you think about this? > 5. Configuration > ================ > diff --git a/src/acl.c b/src/acl.c > index 32ca702..b888aea 100644 > --- a/src/acl.c > +++ b/src/acl.c > @@ -69,6 +69,7 @@ static isc_once_t once = ISC_ONCE_INIT; > static cfg_type_t *update_policy; > static cfg_type_t *allow_query; > static cfg_type_t *allow_transfer; > +static cfg_type_t *forwarders; > > static cfg_type_t * > get_type_from_tuplefield(const cfg_type_t *cfg_type, const char *name) > @@ -139,6 +140,7 @@ init_cfgtypes(void) > update_policy = get_type_from_clause_array(zoneopts, "update-policy"); > allow_query = get_type_from_clause_array(zoneopts, "allow-query"); > allow_transfer = get_type_from_clause_array(zoneopts, "allow-transfer"); > + forwarders = get_type_from_clause_array(zoneopts, "forwarders"); > } > > static isc_result_t > @@ -351,6 +353,24 @@ cleanup: > return result; > } > > +static isc_result_t > +semicolon_bracket_str(isc_mem_t *mctx, const char *str, ld_string_t **bracket_strp) > +{ > + ld_string_t *tmp = NULL; > + isc_result_t result; > + > + CHECK(str_new(mctx, &tmp)); > + CHECK(str_sprintf(tmp, "{ %s; }", str)); > + > + *bracket_strp = tmp; > + > + return ISC_R_SUCCESS; > + > +cleanup: > + str_destroy(&tmp); > + return result; > +} > + This function won't be needed if we mark idnsForwarders single-value. > isc_result_t > acl_configure_zone_ssutable(const char *policy_str, dns_zone_t *zone) > { > @@ -480,3 +500,72 @@ cleanup: > return result; > } > > + > +/** > + * Parse nameserver IP address with or without port specified in BIND9 syntax. > + * IPv4 and IPv6 addresses are supported, see examples. > + * > + * @param[in] forwarder_str String with IP address and optionally port. > + * @param[in] mctx Memory for allocating temporary and sa structure. > + * @param[out] sa Socket address structure. > + * > + * @return Pointer to newly allocated isc_sockaddr_t structure. > + * > + * @example > + * "192.168.0.100" -> { address:192.168.0.100, port:53 } > + * "192.168.0.100 port 553" -> { address:192.168.0.100, port:553 } > + * "0102:0304:0506:0708:090A:0B0C:0D0E:0FAA" -> > + * { address:0102:0304:0506:0708:090A:0B0C:0D0E:0FAA, port:53 } > + * "0102:0304:0506:0708:090A:0B0C:0D0E:0FAA port 553" -> > + * { address:0102:0304:0506:0708:090A:0B0C:0D0E:0FAA, port:553 } > + * > + */ > +isc_result_t > +acl_parse_forwarder(const char *forwarder_str, isc_mem_t *mctx, isc_sockaddr_t **sa) I would recommend to change the last param to isc_sockaddrlist_t* when idnsForwarders is single-value & modify the function appropriately. > +{ > + isc_result_t result = ISC_R_SUCCESS; > + cfg_parser_t *parser = NULL; > + > + cfg_obj_t *forwarders_cfg = NULL; > + ld_string_t *new_forwarder_str = NULL; > + const cfg_obj_t *faddresses; > + const cfg_listelt_t *element; > + > + in_port_t port = 53; > + > + REQUIRE(forwarder_str != NULL); > + REQUIRE(mctx != NULL); REQUIRE(mctx != NULL); is not needed, every isc_mem_* function checks mctx validity. > + REQUIRE(sa != NULL); > + REQUIRE(*sa == NULL); REQUIRE(sa != NULL && *sa == NULL); is better. > + > + /* add semicolon and brackets as necessary for parser */ > + if (!index(forwarder_str, ';')) > + CHECK(semicolon_bracket_str(mctx, forwarder_str, &new_forwarder_str)); > + else > + CHECK(bracket_str(mctx, forwarder_str, &new_forwarder_str)); > + > + CHECK(cfg_parser_create(mctx, dns_lctx, &parser)); > + CHECK(parse(parser, str_buf(new_forwarder_str), &forwarders, &forwarders_cfg)); > + > + faddresses = cfg_tuple_get(forwarders_cfg, "addresses"); > + element = cfg_list_first(faddresses); > + if (!element) { > + result = ISC_R_FAILURE; > + goto cleanup; > + } > + > + const cfg_obj_t *forwarder = cfg_listelt_value(element); > + *sa = isc_mem_get(mctx, sizeof(isc_sockaddr_t)); > + if (*sa == NULL) { > + result = ISC_R_NOMEMORY; > + goto cleanup; > + } > + **sa = *cfg_obj_assockaddr(forwarder); > + if (isc_sockaddr_getport(*sa) == 0) > + isc_sockaddr_setport(*sa, port); > + > +cleanup: > + if (new_forwarder_str) > + str_destroy(&new_forwarder_str); Destroy the new_forwarder_str unconditionally, str_destroy handles NULL strings correctly. > + return result; > +} > diff --git a/src/acl.h b/src/acl.h > index d0ab216..7e4471b 100644 > --- a/src/acl.h > +++ b/src/acl.h > @@ -42,4 +42,7 @@ acl_from_ldap(isc_mem_t *mctx, const char *aclstr, acl_type_t type, > * Please refer to BIND 9 ARM (Administrator Reference Manual) about ACLs. > */ > > +isc_result_t > +acl_parse_forwarder(const char *forwarders_str, isc_mem_t *mctx, isc_sockaddr_t **sa); > + > #endif /* !_LD_ACL_H_ */ > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index d9e8629..21c3690 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -776,108 +776,6 @@ cleanup: > } > > > -/** > - * @brief > - * > - * @param nameserver > - * @param sa > - * > - * @return > - */ > -static isc_result_t > -sockaddr_fromchar(char *nameserver, struct sockaddr *sa) > -{ > - isc_result_t result = ISC_R_FAILURE; > - struct addrinfo *ai; > - struct addrinfo hints; > - int res; > - > - REQUIRE(sa != NULL); > - > - memset(&hints, 0, sizeof(hints)); > - hints.ai_flags = AI_NUMERICHOST; > - > - res = getaddrinfo(nameserver, NULL, &hints, &ai); > - if (res == 0) { > - if ((ai->ai_family == AF_INET) || (ai->ai_family == AF_INET6)) { > - memcpy(sa, ai->ai_addr, ai->ai_addrlen); > - result = ISC_R_SUCCESS; > - } > - freeaddrinfo(ai); > - } > - return result; > -} > - > -/** > - * Parse nameserver IP address with or without > - * port separated with a dot. > - * > - * @example > - * "192.168.0.100.53" -> { address:192.168.0.100, port:53 } > - * > - * @param token > - * @param sa Socket address structure. > - */ > -static isc_result_t > -parse_nameserver(char *token, struct sockaddr *sa) > -{ > - isc_result_t result = ISC_R_FAILURE; > - char *dot; > - long number; > - > - REQUIRE(token != NULL); > - REQUIRE(sa != NULL); > - > - result = sockaddr_fromchar(token, sa); > - if (result == ISC_R_SUCCESS) > - return result; > - > - dot = strrchr(token, '.'); > - if (dot == NULL) > - return ISC_R_FAILURE; > - > - number = strtol(dot + 1, NULL, 10); > - if ((number < 0) || (number > UINT16_MAX)) > - return ISC_R_FAILURE; > - > - *dot = '\0'; > - result = sockaddr_fromchar(token, sa); > - *dot = '.'; /* restore value */ > - if (result == ISC_R_SUCCESS) { > - in_port_t port = htons(number); > - switch (sa->sa_family) { > - case AF_INET : > - ((struct sockaddr_in *)sa)->sin_port = port; > - break; > - case AF_INET6 : > - ((struct sockaddr_in6 *)sa)->sin6_port = port; > - break; > - default: > - log_bug("Unknown sa_family type"); > - return ISC_R_FAILURE; > - } > - } > - return result; > -} > - > -/* TODO: Code hardering. */ > -static void * > -get_in_addr(struct sockaddr *sa) > -{ > - if (sa->sa_family == AF_INET) > - return &(((struct sockaddr_in*)sa)->sin_addr); > - else > - return &(((struct sockaddr_in6*)sa)->sin6_addr); > -} > - > -static in_port_t > -get_in_port(struct sockaddr *sa) > -{ > - if (sa->sa_family == AF_INET) > - return (((struct sockaddr_in*)sa)->sin_port); > - else > - return (((struct sockaddr_in6*)sa)->sin6_port); > -} > > static isc_result_t > configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, > @@ -887,7 +785,6 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, > isc_result_t result; > ldap_value_t *value; > isc_sockaddrlist_t addrs; > - isc_sockaddr_t *addr; > > REQUIRE(entry != NULL && inst != NULL && name != NULL && values != NULL); > > @@ -905,28 +802,19 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, > > ISC_LIST_INIT(addrs); > for (value = HEAD(*values); value != NULL; value = NEXT(value, link)) { > - struct sockaddr sa; > - > - addr = isc_mem_get(inst->mctx, sizeof(*addr)); > - if (addr == NULL) { > - result = ISC_R_NOMEMORY; > - goto cleanup; > - } > - ISC_LINK_INIT(addr, link); > + isc_sockaddr_t *addr = NULL; > + char forwarder_txt[ISC_SOCKADDR_FORMATSIZE]; > > - result = parse_nameserver(value->value, &sa); > - if (result != ISC_R_SUCCESS) { > - log_bug("Could not convert IP address " > - "from string '%s'.", value->value); > + if( acl_parse_forwarder(value->value, inst->mctx, &addr) > + != ISC_R_SUCCESS) { > + log_error("Could not parse forwarder '%s'", value->value); > + continue; > } > > - /* Convert port from network byte order. */ > - in_port_t port = ntohs(get_in_port(&sa)); > - port = (port != 0) ? port : 53; /* use well known port */ > - > - isc_sockaddr_fromin(addr, get_in_addr(&sa), port); > + ISC_LINK_INIT(addr, link); > ISC_LIST_APPEND(addrs, addr, link); > - log_debug(5, "Adding forwarder %s (:%d) for %s", value->value, port, dn); > + isc_sockaddr_format(addr, forwarder_txt, ISC_SOCKADDR_FORMATSIZE); > + log_debug(5, "Adding forwarder %s for %s", forwarder_txt, dn); > } > > /* > @@ -944,6 +832,11 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, > fwdpolicy = dns_fwdpolicy_only; > } > > + if (ISC_LIST_EMPTY(addrs)) { > + log_debug(5, "No forwarders seen; disabling forwarding"); > + fwdpolicy = dns_fwdpolicy_none; > + } > + > log_debug(5, "Forward policy: %d", fwdpolicy); > > /* Set forward table up. */ > @@ -951,6 +844,7 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, > > cleanup: > while (!ISC_LIST_EMPTY(addrs)) { > + isc_sockaddr_t *addr = NULL; > addr = ISC_LIST_HEAD(addrs); > ISC_LIST_UNLINK(addrs, addr, link); > isc_mem_put(inst->mctx, addr, sizeof(*addr)); > -- > 1.7.7.6 > -- Adam Tkac, Red Hat, Inc. From simo at redhat.com Mon Mar 5 12:49:12 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 05 Mar 2012 07:49:12 -0500 Subject: [Freeipa-devel] [PATCH] 0009 Support for IPv6 elements in idnsForwarders attribute In-Reply-To: <20120305113252.GB7168@redhat.com> References: <4F4E31E1.7010406@redhat.com> <4F4E32AF.9050601@redhat.com> <1330529440.25597.50.camel@willson.li.ssimo.org> <4F4E47D4.3030700@redhat.com> <1330533225.32367.25.camel@balmora.brq.redhat.com> <4F4F8615.8020804@redhat.com> <4F4FC625.3000108@redhat.com> <20120305113252.GB7168@redhat.com> Message-ID: <1330951752.26197.34.camel@willson.li.ssimo.org> On Mon, 2012-03-05 at 12:32 +0100, Adam Tkac wrote: > > I would recommend to change the last param to isc_sockaddrlist_t* when > idnsForwarders > is single-value & modify the function appropriately. > > Single value should be used only if there is an ordering problem with the attributes. Also we already use idnsForwarders (just w/o the port value) so moving to single-value would mean both a schema and a data change. I would avoid it unless there are extremely good reasons. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Mon Mar 5 12:56:14 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 05 Mar 2012 13:56:14 +0100 Subject: [Freeipa-devel] discussion needed: Support for IPv6 elements in idnsForwarders attribute In-Reply-To: <20120305113252.GB7168@redhat.com> References: <4F4E31E1.7010406@redhat.com> <4F4E32AF.9050601@redhat.com> <1330529440.25597.50.camel@willson.li.ssimo.org> <4F4E47D4.3030700@redhat.com> <1330533225.32367.25.camel@balmora.brq.redhat.com> <4F4F8615.8020804@redhat.com> <4F4FC625.3000108@redhat.com> <20120305113252.GB7168@redhat.com> Message-ID: <4F54B7EE.9060306@redhat.com> Hello, we are back with another proposal from Adam. See last lines. On 03/05/2012 12:32 PM, Adam Tkac wrote: > On Thu, Mar 01, 2012 at 07:55:33PM +0100, Petr Spacek wrote: >> > Hello, >> > >> > here is (again) reworked patch for >> > https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . >> > >> > Adam pointed me to existing BIND parser, which I missed. Now is all >> > parsing& socket magic done inside BIND libraries. Our code is a bit >> > shorter and syntax is 100% BIND-compatible. (But it means same as >> > discussed yesterday:-) >> > >> > Adam, please review it. > Thanks for the patch Petr, see my comments below. > >> > Petr^2 Spacek >> > >> > On 03/01/2012 03:22 PM, Petr Spacek wrote: >>> > >Hello, >>> > > >>> > >here is reworked patch for >>> > >https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . >>> > > >>> > >Changes after yesterday's discussion on IRC with Simo and Mkosek: >>> > >It follows BIND9 syntax for optional specification of port& adds >>> > >documentation for this new syntax. >>> > > >>> > >Petr^2 Spacek >>> > > >>> > >On 02/29/2012 05:33 PM, Martin Kosek wrote: >>>> > >>I agree that we should keep the BIND syntax and separate port and IP >>>> > >>address with a space. We will at least avoid possible issues with IP >>>> > >>address decoding in the future. >>>> > >> >>>> > >>Since this is a new attribute we have a good chance to do changes now so >>>> > >>that it is used correctly. I created an upstream ticket to change the >>>> > >>behavior and validators in FreeIPA: >>>> > >> >>>> > >>https://fedorahosted.org/freeipa/ticket/2462 >>>> > >> >>>> > >>Martin >>>> > >> >>>> > >>On Wed, 2012-02-29 at 16:44 +0100, Petr Spacek wrote: >>>>> > >>>On 02/29/2012 04:30 PM, Simo Sorce wrote: >>>>>> > >>>>Either way looks ok to me. >>>>>> > >>>>I agree that using a space may be less confusing if this syntax never >>>>>> > >>>>allows to specify multiple addresses. >>>>>> > >>>>If multiple address can be specified than it may be less ideal to use >>>>>> > >>>>spaces. >>>>>> > >>>> >>>>>> > >>>>Simo. >>>>> > >>> >>>>> > >>>idnsForwarders is multi-value attribute, so each value contain single >>>>> > >>>forwarder address. >>>>> > >>> >>>>> > >>>Petr^2 Spacek >>>>> > >>> >>>>>> > >>>>On Wed, 2012-02-29 at 15:14 +0100, Petr Spacek wrote: >>>>>>> > >>>>>And there is the patch, sorry. >>>>>>> > >>>>> >>>>>>> > >>>>>Petr^2 >>>>>>> > >>>>> >>>>>>> > >>>>>On 02/29/2012 03:10 PM, Petr Spacek wrote: >>>>>>>> > >>>>>>Hello, >>>>>>>> > >>>>>> >>>>>>>> > >>>>>>this patch fixeshttps://fedorahosted.org/bind-dyndb-ldap/ticket/49 , >>>>>>>> > >>>>>>but I want to discuss one (unimplemented) change: >>>>>>>> > >>>>>> >>>>>>>> > >>>>>>I propose a change in (currently very strange) forwarders syntax. >>>>>>>> > >>>>>> >>>>>>>> > >>>>>>Current syntax: >>>>>>>> > >>>>>>[.port] >>>>>>>> > >>>>>> >>>>>>>> > >>>>>>examples: >>>>>>>> > >>>>>>1.2.3.4 (without optional port) >>>>>>>> > >>>>>>1.2.3.4.5553 (optional port 5553) >>>>>>>> > >>>>>>A::B (IPv6, without optional port) >>>>>>>> > >>>>>>A::B.5553 >>>>>>>> > >>>>>>::FFFF:1.2.3.4 (6to4, without optional port) >>>>>>>> > >>>>>>::FFFF:1.2.3.4.5553 (6to4, with optional port 5553) >>>>>>>> > >>>>>> >>>>>>>> > >>>>>>I find this syntax confusing, non-standard and not-typo-proof. >>>>>>>> > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > >>>>>>IMHO better choice is to follow BIND forwarders syntax: >>>>>>>> > >>>>>> [port ip_port] (port is string delimited with spaces) >>>>>>>> > >>>>>> >>>>>>>> > >>>>>>(From:http://www.zytrax.com/books/dns/ch7/queries.html#forwarders) >>>>>>>> > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > >>>>>>*Current syntax is not documented*, so probably is not used anywhere. >>>>>>>> > >>>>>>(And DNS server on non-standard port is probably useful only for >>>>>>>> > >>>>>>testing >>>>>>>> > >>>>>>purposes, but it's another story.) >>>>>>>> > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > >>>>>>What is you opinion? >> > From 14056200915a90c2a957e8a2219819bd3b7f9365 Mon Sep 17 00:00:00 2001 >> > From: Petr Spacek >> > Date: Thu, 1 Mar 2012 15:08:10 +0100 >> > Subject: [PATCH] Add support for IPv6 elements in idnsForwarders attribute >> > and make syntax compatible with BIND9 forwarders. >> > Signed-off-by: Petr Spacek >> > >> > --- >> > NEWS | 3 + >> > README | 8 ++- >> > src/acl.c | 89 ++++++++++++++++++++++++++++++++++ >> > src/acl.h | 3 + >> > src/ldap_helper.c | 136 ++++++----------------------------------------------- >> > 5 files changed, 116 insertions(+), 123 deletions(-) >> > >> > diff --git a/NEWS b/NEWS >> > index ced6250..a97a5f3 100644 >> > --- a/NEWS >> > +++ b/NEWS >> > @@ -1,3 +1,6 @@ >> > +[1] Add support for IPv6 elements in idnsForwarders attribute >> > + and make syntax compatible with BIND9 forwarders. >> > + >> > 1.1.0a2 >> > ====== >> > >> > diff --git a/README b/README >> > index 914abdc..aedb88c 100644 >> > --- a/README >> > +++ b/README >> > @@ -89,8 +89,12 @@ example zone ldif is available in the doc directory. >> > with a valid idnsForwarders attribute. >> > >> > * idnsForwarders >> > - Defines multiple IP addresses (TODO: optional port numbers) to which >> > - queries will be forwarded. >> > + Defines multiple IP addresses to which queries will be forwarded. >> > + It is multi-value attribute: Each IP address (and optional port) has to >> > + be in own value. BIND9 syntax for "forwarders" is required. >> > + Optional port can be specified by adding " port" after IP >> > + address. IPv4 and IPv6 addresses are supported. >> > + Examples: "1.2.3.4" or "1.2.3.4 port 553" or "A::B" or "A::B port 553" On 03/05/2012 12:32 PM, Adam Tkac wrote: > In my opinion we should mark the idnsForwarders attribute single-value and deal > with them as with idnsAllow{Query,Transfer} (i.e. specify forwarders splitted by > semi-colon). It will be more consistent with idnsAllow{Query,Transfer}. What do > you think about this? It sounds good to me. It's more consistent with real BIND configuration and other parts of plugin. What about upgrade process? It is necessary to change schema and convert existing entries to new format. Petr^2 Spacek From atkac at redhat.com Mon Mar 5 13:03:53 2012 From: atkac at redhat.com (Adam Tkac) Date: Mon, 5 Mar 2012 14:03:53 +0100 Subject: [Freeipa-devel] discussion needed: Support for IPv6 elements in idnsForwarders attribute In-Reply-To: <4F54B7EE.9060306@redhat.com> References: <4F4E31E1.7010406@redhat.com> <4F4E32AF.9050601@redhat.com> <1330529440.25597.50.camel@willson.li.ssimo.org> <4F4E47D4.3030700@redhat.com> <1330533225.32367.25.camel@balmora.brq.redhat.com> <4F4F8615.8020804@redhat.com> <4F4FC625.3000108@redhat.com> <20120305113252.GB7168@redhat.com> <4F54B7EE.9060306@redhat.com> Message-ID: <20120305130352.GA16404@redhat.com> On Mon, Mar 05, 2012 at 01:56:14PM +0100, Petr Spacek wrote: > Hello, > > we are back with another proposal from Adam. See last lines. Hello, reply is below... > > On 03/05/2012 12:32 PM, Adam Tkac wrote: > >On Thu, Mar 01, 2012 at 07:55:33PM +0100, Petr Spacek wrote: > >>> Hello, > >>> > >>> here is (again) reworked patch for > >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . > >>> > >>> Adam pointed me to existing BIND parser, which I missed. Now is all > >>> parsing& socket magic done inside BIND libraries. Our code is a bit > >>> shorter and syntax is 100% BIND-compatible. (But it means same as > >>> discussed yesterday:-) > >>> > >>> Adam, please review it. > >Thanks for the patch Petr, see my comments below. > > > >>> Petr^2 Spacek > >>> > >>> On 03/01/2012 03:22 PM, Petr Spacek wrote: > >>>> >Hello, > >>>> > > >>>> >here is reworked patch for > >>>> >https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . > >>>> > > >>>> >Changes after yesterday's discussion on IRC with Simo and Mkosek: > >>>> >It follows BIND9 syntax for optional specification of port& adds > >>>> >documentation for this new syntax. > >>>> > > >>>> >Petr^2 Spacek > >>>> > > >>>> >On 02/29/2012 05:33 PM, Martin Kosek wrote: > >>>>> >>I agree that we should keep the BIND syntax and separate port and IP > >>>>> >>address with a space. We will at least avoid possible issues with IP > >>>>> >>address decoding in the future. > >>>>> >> > >>>>> >>Since this is a new attribute we have a good chance to do changes now so > >>>>> >>that it is used correctly. I created an upstream ticket to change the > >>>>> >>behavior and validators in FreeIPA: > >>>>> >> > >>>>> >>https://fedorahosted.org/freeipa/ticket/2462 > >>>>> >> > >>>>> >>Martin > >>>>> >> > >>>>> >>On Wed, 2012-02-29 at 16:44 +0100, Petr Spacek wrote: > >>>>>> >>>On 02/29/2012 04:30 PM, Simo Sorce wrote: > >>>>>>> >>>>Either way looks ok to me. > >>>>>>> >>>>I agree that using a space may be less confusing if this syntax never > >>>>>>> >>>>allows to specify multiple addresses. > >>>>>>> >>>>If multiple address can be specified than it may be less ideal to use > >>>>>>> >>>>spaces. > >>>>>>> >>>> > >>>>>>> >>>>Simo. > >>>>>> >>> > >>>>>> >>>idnsForwarders is multi-value attribute, so each value contain single > >>>>>> >>>forwarder address. > >>>>>> >>> > >>>>>> >>>Petr^2 Spacek > >>>>>> >>> > >>>>>>> >>>>On Wed, 2012-02-29 at 15:14 +0100, Petr Spacek wrote: > >>>>>>>> >>>>>And there is the patch, sorry. > >>>>>>>> >>>>> > >>>>>>>> >>>>>Petr^2 > >>>>>>>> >>>>> > >>>>>>>> >>>>>On 02/29/2012 03:10 PM, Petr Spacek wrote: > >>>>>>>>> >>>>>>Hello, > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>>this patch fixeshttps://fedorahosted.org/bind-dyndb-ldap/ticket/49 , > >>>>>>>>> >>>>>>but I want to discuss one (unimplemented) change: > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>>I propose a change in (currently very strange) forwarders syntax. > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>>Current syntax: > >>>>>>>>> >>>>>>[.port] > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>>examples: > >>>>>>>>> >>>>>>1.2.3.4 (without optional port) > >>>>>>>>> >>>>>>1.2.3.4.5553 (optional port 5553) > >>>>>>>>> >>>>>>A::B (IPv6, without optional port) > >>>>>>>>> >>>>>>A::B.5553 > >>>>>>>>> >>>>>>::FFFF:1.2.3.4 (6to4, without optional port) > >>>>>>>>> >>>>>>::FFFF:1.2.3.4.5553 (6to4, with optional port 5553) > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>>I find this syntax confusing, non-standard and not-typo-proof. > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>>IMHO better choice is to follow BIND forwarders syntax: > >>>>>>>>> >>>>>> [port ip_port] (port is string delimited with spaces) > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>>(From:http://www.zytrax.com/books/dns/ch7/queries.html#forwarders) > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>>*Current syntax is not documented*, so probably is not used anywhere. > >>>>>>>>> >>>>>>(And DNS server on non-standard port is probably useful only for > >>>>>>>>> >>>>>>testing > >>>>>>>>> >>>>>>purposes, but it's another story.) > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>> > >>>>>>>>> >>>>>>What is you opinion? > >>> From 14056200915a90c2a957e8a2219819bd3b7f9365 Mon Sep 17 00:00:00 2001 > >>> From: Petr Spacek > >>> Date: Thu, 1 Mar 2012 15:08:10 +0100 > >>> Subject: [PATCH] Add support for IPv6 elements in idnsForwarders attribute > >>> and make syntax compatible with BIND9 forwarders. > >>> Signed-off-by: Petr Spacek > >>> > >>> --- > >>> NEWS | 3 + > >>> README | 8 ++- > >>> src/acl.c | 89 ++++++++++++++++++++++++++++++++++ > >>> src/acl.h | 3 + > >>> src/ldap_helper.c | 136 ++++++----------------------------------------------- > >>> 5 files changed, 116 insertions(+), 123 deletions(-) > >>> > >>> diff --git a/NEWS b/NEWS > >>> index ced6250..a97a5f3 100644 > >>> --- a/NEWS > >>> +++ b/NEWS > >>> @@ -1,3 +1,6 @@ > >>> +[1] Add support for IPv6 elements in idnsForwarders attribute > >>> + and make syntax compatible with BIND9 forwarders. > >>> + > >>> 1.1.0a2 > >>> ====== > >>> > >>> diff --git a/README b/README > >>> index 914abdc..aedb88c 100644 > >>> --- a/README > >>> +++ b/README > >>> @@ -89,8 +89,12 @@ example zone ldif is available in the doc directory. > >>> with a valid idnsForwarders attribute. > >>> > >>> * idnsForwarders > >>> - Defines multiple IP addresses (TODO: optional port numbers) to which > >>> - queries will be forwarded. > >>> + Defines multiple IP addresses to which queries will be forwarded. > >>> + It is multi-value attribute: Each IP address (and optional port) has to > >>> + be in own value. BIND9 syntax for "forwarders" is required. > >>> + Optional port can be specified by adding " port" after IP > >>> + address. IPv4 and IPv6 addresses are supported. > >>> + Examples: "1.2.3.4" or "1.2.3.4 port 553" or "A::B" or "A::B port 553" > > On 03/05/2012 12:32 PM, Adam Tkac wrote: > >In my opinion we should mark the idnsForwarders attribute single-value and deal > >with them as with idnsAllow{Query,Transfer} (i.e. specify forwarders splitted by > >semi-colon). It will be more consistent with idnsAllow{Query,Transfer}. What do > >you think about this? > > It sounds good to me. It's more consistent with real BIND > configuration and other parts of plugin. > > What about upgrade process? It is necessary to change schema and > convert existing entries to new format. If idnsForward is already in use, I'm ok with multival attribute because ordering is not an issue here. Please incorporate changes which I suggested (if you don't dissagree, of course) and then push the patch. Thank you in advance! Regards, Adam -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Mon Mar 5 13:22:49 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 05 Mar 2012 14:22:49 +0100 Subject: [Freeipa-devel] discussion needed: Support for IPv6 elements in idnsForwarders attribute In-Reply-To: <20120305130352.GA16404@redhat.com> References: <4F4E31E1.7010406@redhat.com> <4F4E32AF.9050601@redhat.com> <1330529440.25597.50.camel@willson.li.ssimo.org> <4F4E47D4.3030700@redhat.com> <1330533225.32367.25.camel@balmora.brq.redhat.com> <4F4F8615.8020804@redhat.com> <4F4FC625.3000108@redhat.com> <20120305113252.GB7168@redhat.com> <4F54B7EE.9060306@redhat.com> <20120305130352.GA16404@redhat.com> Message-ID: <4F54BE29.2090103@redhat.com> On 03/05/2012 02:03 PM, Adam Tkac wrote: > On Mon, Mar 05, 2012 at 01:56:14PM +0100, Petr Spacek wrote: >> Hello, >> >> we are back with another proposal from Adam. See last lines. > > Hello, > > reply is below... > >> >> On 03/05/2012 12:32 PM, Adam Tkac wrote: >>> On Thu, Mar 01, 2012 at 07:55:33PM +0100, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> here is (again) reworked patch for >>>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . >>>>> >>>>> Adam pointed me to existing BIND parser, which I missed. Now is all >>>>> parsing& socket magic done inside BIND libraries. Our code is a bit >>>>> shorter and syntax is 100% BIND-compatible. (But it means same as >>>>> discussed yesterday:-) >>>>> >>>>> Adam, please review it. >>> Thanks for the patch Petr, see my comments below. >>> >>>>> Petr^2 Spacek >>>>> >>>>> On 03/01/2012 03:22 PM, Petr Spacek wrote: >>>>>> >Hello, >>>>>> > >>>>>> >here is reworked patch for >>>>>> >https://fedorahosted.org/bind-dyndb-ldap/ticket/49 . >>>>>> > >>>>>> >Changes after yesterday's discussion on IRC with Simo and Mkosek: >>>>>> >It follows BIND9 syntax for optional specification of port& adds >>>>>> >documentation for this new syntax. >>>>>> > >>>>>> >Petr^2 Spacek >>>>>> > >>>>>> >On 02/29/2012 05:33 PM, Martin Kosek wrote: >>>>>>> >>I agree that we should keep the BIND syntax and separate port and IP >>>>>>> >>address with a space. We will at least avoid possible issues with IP >>>>>>> >>address decoding in the future. >>>>>>> >> >>>>>>> >>Since this is a new attribute we have a good chance to do changes now so >>>>>>> >>that it is used correctly. I created an upstream ticket to change the >>>>>>> >>behavior and validators in FreeIPA: >>>>>>> >> >>>>>>> >>https://fedorahosted.org/freeipa/ticket/2462 >>>>>>> >> >>>>>>> >>Martin >>>>>>> >> >>>>>>> >>On Wed, 2012-02-29 at 16:44 +0100, Petr Spacek wrote: >>>>>>>> >>>On 02/29/2012 04:30 PM, Simo Sorce wrote: >>>>>>>>> >>>>Either way looks ok to me. >>>>>>>>> >>>>I agree that using a space may be less confusing if this syntax never >>>>>>>>> >>>>allows to specify multiple addresses. >>>>>>>>> >>>>If multiple address can be specified than it may be less ideal to use >>>>>>>>> >>>>spaces. >>>>>>>>> >>>> >>>>>>>>> >>>>Simo. >>>>>>>> >>> >>>>>>>> >>>idnsForwarders is multi-value attribute, so each value contain single >>>>>>>> >>>forwarder address. >>>>>>>> >>> >>>>>>>> >>>Petr^2 Spacek >>>>>>>> >>> >>>>>>>>> >>>>On Wed, 2012-02-29 at 15:14 +0100, Petr Spacek wrote: >>>>>>>>>> >>>>>And there is the patch, sorry. >>>>>>>>>> >>>>> >>>>>>>>>> >>>>>Petr^2 >>>>>>>>>> >>>>> >>>>>>>>>> >>>>>On 02/29/2012 03:10 PM, Petr Spacek wrote: >>>>>>>>>>> >>>>>>Hello, >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>this patch fixeshttps://fedorahosted.org/bind-dyndb-ldap/ticket/49 , >>>>>>>>>>> >>>>>>but I want to discuss one (unimplemented) change: >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>I propose a change in (currently very strange) forwarders syntax. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>Current syntax: >>>>>>>>>>> >>>>>>[.port] >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>examples: >>>>>>>>>>> >>>>>>1.2.3.4 (without optional port) >>>>>>>>>>> >>>>>>1.2.3.4.5553 (optional port 5553) >>>>>>>>>>> >>>>>>A::B (IPv6, without optional port) >>>>>>>>>>> >>>>>>A::B.5553 >>>>>>>>>>> >>>>>>::FFFF:1.2.3.4 (6to4, without optional port) >>>>>>>>>>> >>>>>>::FFFF:1.2.3.4.5553 (6to4, with optional port 5553) >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>I find this syntax confusing, non-standard and not-typo-proof. >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>IMHO better choice is to follow BIND forwarders syntax: >>>>>>>>>>> >>>>>> [port ip_port] (port is string delimited with spaces) >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>(From:http://www.zytrax.com/books/dns/ch7/queries.html#forwarders) >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>*Current syntax is not documented*, so probably is not used anywhere. >>>>>>>>>>> >>>>>>(And DNS server on non-standard port is probably useful only for >>>>>>>>>>> >>>>>>testing >>>>>>>>>>> >>>>>>purposes, but it's another story.) >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> >>>>>>What is you opinion? >>>>> From 14056200915a90c2a957e8a2219819bd3b7f9365 Mon Sep 17 00:00:00 2001 >>>>> From: Petr Spacek >>>>> Date: Thu, 1 Mar 2012 15:08:10 +0100 >>>>> Subject: [PATCH] Add support for IPv6 elements in idnsForwarders attribute >>>>> and make syntax compatible with BIND9 forwarders. >>>>> Signed-off-by: Petr Spacek >>>>> >>>>> --- >>>>> NEWS | 3 + >>>>> README | 8 ++- >>>>> src/acl.c | 89 ++++++++++++++++++++++++++++++++++ >>>>> src/acl.h | 3 + >>>>> src/ldap_helper.c | 136 ++++++----------------------------------------------- >>>>> 5 files changed, 116 insertions(+), 123 deletions(-) >>>>> >>>>> diff --git a/NEWS b/NEWS >>>>> index ced6250..a97a5f3 100644 >>>>> --- a/NEWS >>>>> +++ b/NEWS >>>>> @@ -1,3 +1,6 @@ >>>>> +[1] Add support for IPv6 elements in idnsForwarders attribute >>>>> + and make syntax compatible with BIND9 forwarders. >>>>> + >>>>> 1.1.0a2 >>>>> ====== >>>>> >>>>> diff --git a/README b/README >>>>> index 914abdc..aedb88c 100644 >>>>> --- a/README >>>>> +++ b/README >>>>> @@ -89,8 +89,12 @@ example zone ldif is available in the doc directory. >>>>> with a valid idnsForwarders attribute. >>>>> >>>>> * idnsForwarders >>>>> - Defines multiple IP addresses (TODO: optional port numbers) to which >>>>> - queries will be forwarded. >>>>> + Defines multiple IP addresses to which queries will be forwarded. >>>>> + It is multi-value attribute: Each IP address (and optional port) has to >>>>> + be in own value. BIND9 syntax for "forwarders" is required. >>>>> + Optional port can be specified by adding " port" after IP >>>>> + address. IPv4 and IPv6 addresses are supported. >>>>> + Examples: "1.2.3.4" or "1.2.3.4 port 553" or "A::B" or "A::B port 553" >> >> On 03/05/2012 12:32 PM, Adam Tkac wrote: >>> In my opinion we should mark the idnsForwarders attribute single-value and deal >>> with them as with idnsAllow{Query,Transfer} (i.e. specify forwarders splitted by >>> semi-colon). It will be more consistent with idnsAllow{Query,Transfer}. What do >>> you think about this? >> >> It sounds good to me. It's more consistent with real BIND >> configuration and other parts of plugin. >> >> What about upgrade process? It is necessary to change schema and >> convert existing entries to new format. > > If idnsForward is already in use, I'm ok with multival attribute because > ordering is not an issue here. > > Please incorporate changes which I suggested (if you don't dissagree, of course) > and then push the patch. Thank you in advance! > > Regards, Adam > I did proposed "cosmetic" changes. Multi-value version pushed to master. Latest patch with two cosmetic changes is attached. https://fedorahosted.org/bind-dyndb-ldap/changeset/e114f8e2721e89a6ed84439903cc739c5f8d293a Thanks to Adam and Simo for discussion. Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0009-Add-support-for-IPv6-elements-in-idnsForwarders-attr.patch Type: text/x-patch Size: 10060 bytes Desc: not available URL: From abokovoy at redhat.com Mon Mar 5 14:04:20 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 Mar 2012 16:04:20 +0200 Subject: [Freeipa-devel] [PATCH] 13 ipa-client-install not calling authconfig In-Reply-To: <4F4938C0.3000801@redhat.com> References: <4F466AF1.9040502@redhat.com> <20120225193027.GR13458@redhat.com> <4F4938C0.3000801@redhat.com> Message-ID: <20120305140420.GA30616@redhat.com> On Sat, 25 Feb 2012, Ondrej Hamada wrote: > On 02/25/2012 08:30 PM, Alexander Bokovoy wrote: > >On Thu, 23 Feb 2012, Ondrej Hamada wrote: > > > >>Option '--noac' was added. If set, the ipa-client-install will not call > >>authconfig for setting nsswitch.conf and PAM configuration. In > >>fact no configuration of nsswitch.conf or PAM would be done at > >>all. > >> > >>https://fedorahosted.org/freeipa/ticket/2369 > >NACK. > > > >According to the original request, authconfig will do > >nsswitch/PAM configuration *after* ipa-client-install run so the > >following check in ipa-client-install will fail with --noac: > > > >>+ #Check that nss is working properly > >>+ if not options.on_master: > >>+ n = 0 > >>+ found = False > >>+ # Loop for up to 10 seconds to see if nss is working properly. > >>+ # It can sometimes take a few seconds to connect to the remote provider. > >>+ # Particulary, SSSD might take longer than 6-8 seconds. > >>+ while n< 10 and not found: > >>+ try: > >>+ ipautil.run(["getent", "passwd", "admin"]) > >>+ found = True > >>+ except Exception, e: > >>+ time.sleep(1) > >>+ n = n + 1 > > > This check never happens with --noac. I've rechecked the indentation > (I admit it's badly visible in the patch file) and it's ok. OK then. ACK. Please, someone commit this path as my git trees are a bit in flux due to trusts work and I'm deep in Samba 16-byte session key fixes right now. -- / Alexander Bokovoy From simo at redhat.com Mon Mar 5 14:47:19 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 05 Mar 2012 09:47:19 -0500 Subject: [Freeipa-devel] [PATCH] 13 ipa-client-install not calling authconfig In-Reply-To: <20120305140420.GA30616@redhat.com> References: <4F466AF1.9040502@redhat.com> <20120225193027.GR13458@redhat.com> <4F4938C0.3000801@redhat.com> <20120305140420.GA30616@redhat.com> Message-ID: <1330958839.26197.45.camel@willson.li.ssimo.org> On Mon, 2012-03-05 at 16:04 +0200, Alexander Bokovoy wrote: > On Sat, 25 Feb 2012, Ondrej Hamada wrote: > > On 02/25/2012 08:30 PM, Alexander Bokovoy wrote: > > >On Thu, 23 Feb 2012, Ondrej Hamada wrote: > > > > > >>Option '--noac' was added. If set, the ipa-client-install will not call > > >>authconfig for setting nsswitch.conf and PAM configuration. In > > >>fact no configuration of nsswitch.conf or PAM would be done at > > >>all. > > >> > > >>https://fedorahosted.org/freeipa/ticket/2369 > > >NACK. > > > > > >According to the original request, authconfig will do > > >nsswitch/PAM configuration *after* ipa-client-install run so the > > >following check in ipa-client-install will fail with --noac: > > > > > >>+ #Check that nss is working properly > > >>+ if not options.on_master: > > >>+ n = 0 > > >>+ found = False > > >>+ # Loop for up to 10 seconds to see if nss is working properly. > > >>+ # It can sometimes take a few seconds to connect to the remote provider. > > >>+ # Particulary, SSSD might take longer than 6-8 seconds. > > >>+ while n< 10 and not found: > > >>+ try: > > >>+ ipautil.run(["getent", "passwd", "admin"]) > > >>+ found = True > > >>+ except Exception, e: > > >>+ time.sleep(1) > > >>+ n = n + 1 > > > > > This check never happens with --noac. I've rechecked the indentation > > (I admit it's badly visible in the patch file) and it's ok. > OK then. ACK. > > Please, someone commit this path as my git trees are a bit in flux due > to trusts work and I'm deep in Samba 16-byte session key fixes right > now. > Pushed to 2.2 and master. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Mon Mar 5 14:56:39 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 05 Mar 2012 15:56:39 +0100 Subject: [Freeipa-devel] [PATCH] 0015 Only split CSV strings once (updated) In-Reply-To: <4F4E6AC4.3070103@redhat.com> References: <4F464D59.2020601@redhat.com> <4F4B7EC3.9070003@redhat.com> <4F4E6AC4.3070103@redhat.com> Message-ID: <4F54D427.3080803@redhat.com> On 02/29/2012 07:13 PM, Petr Vobornik wrote: > On 02/27/2012 02:01 PM, Petr Viktorin wrote: >> It seems I didn't communicate the problem and my solution clearly >> enough, so let me try again. (Also, I learned from the discussions!) >> >> Currently, both the client and the server parse CSV options. The client >> does *not* re-encode the CSV before sending; the parsing is really done >> twice. This means e.g. that you need 3 backslashes to escape a literal >> comma: after the client-side split, '\\\,' becomes '\,'; which after the >> server-side split becomes ','. >> >> >> Since CSV is specific to the command-line, and the client is responsible >> for translating command-line input to XML-RPC (which has its own syntax >> for lists), the ideal fix will be to move CSV processing entirely to the >> client. >> This will be a rather invasive change, mainly because some parts of the >> UI now expect the server-side parsing (but they don't escape CSV, so >> values containing commas or backslashes are broken). So it won't make it >> to the upcoming release. My patch provides a quick fix: when a call >> comes from the command-line client, disable the server-side parsing. > > I investigated all occurrences of CSV creation in Web UI. I removed them > and UI is working fine. The patch is on the list: pvoborni 099. So your > patch shouldn't affect UI if my patch is applied. > >> >> I can't get away from moving split_csv() (which is not idempotent) out >> of normalize() (which is, and gets called lots of times); this is the >> patch's major change in therms of LOC. >> >> >> I'll note again that this only affects values with backslashes or double >> quotes. Exactly these options are currently broken (=need double >> escaping). The "normal" uses of CSV are completely unaffected. >> >> >> Attaching updated patch; the change vs. the original is that the "don't >> parse again" flag is now only set at the server, when a XMLRPC call is >> received, making the client fully forward-compatible (the flag doesn't >> get sent through the wire). >> >> >> The ticket is https://fedorahosted.org/freeipa/ticket/2227, but this >> patch is only the first step in fixing it. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > This updated patch moves the CSV handling entirely to the client. This means the web UI (and other XMLRPC/JSON clients that don't use CSV) now works with values containing commas and backslashes. The CLI works too, using the Python CSV parser which is only run once now. It still has some surprising behavior which my patch 18 will try to simplify. I updated the tests. Now that CSV parsing is outside the server, it doesn't fit into the xmlrpc testing framework. I think we'd benefit from tests that would verify whether particular command lines result in correct XML-RPC calls. I'll look into making this more testable (and tested). -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0015-03-Only-split-CSV-in-the-client.patch Type: text/x-patch Size: 13363 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 5 15:10:23 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 05 Mar 2012 16:10:23 +0100 Subject: [Freeipa-devel] [PATCH] 0020 Allow removing sudo commands with special characters from command groups Message-ID: <4F54D75F.3010503@redhat.com> This patch fixes DN handling when removing LDAP entries from groups. Because they deal with commas and backslashes in a CSV param, the tests here rely on my patch 0015. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0020-Allow-removing-sudo-commands-with-special-characters.patch Type: text/x-patch Size: 6292 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 5 15:25:58 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Mar 2012 10:25:58 -0500 Subject: [Freeipa-devel] [PATCH] 13 ipa-client-install not calling authconfig In-Reply-To: <20120305140420.GA30616@redhat.com> References: <4F466AF1.9040502@redhat.com> <20120225193027.GR13458@redhat.com> <4F4938C0.3000801@redhat.com> <20120305140420.GA30616@redhat.com> Message-ID: <4F54DB06.2070407@redhat.com> Alexander Bokovoy wrote: > On Sat, 25 Feb 2012, Ondrej Hamada wrote: >> On 02/25/2012 08:30 PM, Alexander Bokovoy wrote: >>> On Thu, 23 Feb 2012, Ondrej Hamada wrote: >>> >>>> Option '--noac' was added. If set, the ipa-client-install will not call >>>> authconfig for setting nsswitch.conf and PAM configuration. In >>>> fact no configuration of nsswitch.conf or PAM would be done at >>>> all. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2369 >>> NACK. >>> >>> According to the original request, authconfig will do >>> nsswitch/PAM configuration *after* ipa-client-install run so the >>> following check in ipa-client-install will fail with --noac: >>> >>>> + #Check that nss is working properly >>>> + if not options.on_master: >>>> + n = 0 >>>> + found = False >>>> + # Loop for up to 10 seconds to see if nss is working properly. >>>> + # It can sometimes take a few seconds to connect to the remote provider. >>>> + # Particulary, SSSD might take longer than 6-8 seconds. >>>> + while n< 10 and not found: >>>> + try: >>>> + ipautil.run(["getent", "passwd", "admin"]) >>>> + found = True >>>> + except Exception, e: >>>> + time.sleep(1) >>>> + n = n + 1 >>> >> This check never happens with --noac. I've rechecked the indentation >> (I admit it's badly visible in the patch file) and it's ok. > OK then. ACK. > > Please, someone commit this path as my git trees are a bit in flux due > to trusts work and I'm deep in Samba 16-byte session key fixes right > now. > Simo pushed this to master and ipa-2-2 I added --noac to the ipa-client-install man page and pushed that under the 1-liner rule. rob From rcritten at redhat.com Mon Mar 5 15:32:47 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Mar 2012 10:32:47 -0500 Subject: [Freeipa-devel] [PATCH] 979 kinit before connect in client In-Reply-To: <4F547CB8.6080405@redhat.com> References: <4F52BFA4.3070107@redhat.com> <4F547CB8.6080405@redhat.com> Message-ID: <4F54DC9F.3060101@redhat.com> Jan Cholasta wrote: > On 4.3.2012 02:04, Rob Crittenden wrote: >> I'm not sure why this didn't always fail but in the client installer we >> were creating a connection before calling kinit. I re-arranged this in >> and beefed up the client logging. >> >> While testing this I periodically ran into an NSS shutdown error where >> the ping() connection hadn't closed before the host_mod to add the SSH >> keys was run. >> >> This stores dbdir in the connection so we can check to see if the same >> database is being used so NSSConnection can skip the nss_init(). >> >> I tested client installs using: ipa-client-install --enable-dns-updates >> --ssh-trust-dns >> >> This same error was reported when installing a replica with --setup-dns. >> >> rob >> > > ACK, both ipa-client-install and ipa-replica-install work fine now. > > However, in __nss_initialized we should check for SSLTransport instead > of KerbTransport (as dbdir is set in SSLTransport) and we don't have to > check for its subclasses (because isinstance checks them automatically). > Also, we can make the function more readable by getting rid of the > nested ifs: > > + def __nss_initialized(self, dbdir): > + """ > + If there is another connections open it may have already > + initialized NSS. This is likely to lead to an NSS shutdown > + failure. One way to mitigate this is to tell NSS to not > + initialize if it has already been done in another open connection. > + > + Returns True if another connection is using the same db. > + """ > + for value in context.__dict__.values(): > + if not isinstance(value, Connection): > + continue > + if not isinstance(value.conn._ServerProxy__transport, SSLTransport): > + continue > + if value.conn._ServerProxy__transport.dbdir == dbdir: > + return True > + return False > > Honza > Thanks, that is much more readable. Pushed to master and ipa-2-2 with your suggestion. rob From simo at redhat.com Mon Mar 5 15:40:54 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 05 Mar 2012 10:40:54 -0500 Subject: [Freeipa-devel] [PATCH] 965 Allow ipa-getkeytab to skip missing enctypes In-Reply-To: <4F479758.7010908@redhat.com> References: <4F46FE74.2010309@redhat.com> <1330059604.18690.126.camel@willson.li.ssimo.org> <4F479758.7010908@redhat.com> Message-ID: <1330962054.26197.57.camel@willson.li.ssimo.org> On Fri, 2012-02-24 at 08:57 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2012-02-23 at 22:05 -0500, Rob Crittenden wrote: > >> We noticed that older client machines couldn't join FreeIPA 2.1.90 > >> servers running KDC 1.90. It was failing to return a ticket for DES so > >> the whole keytab request was failing. > >> > >> I changed it so failures are acceptable as long as one requested type is > >> returned. > >> > >> I wasn't able to get my KDC to actually return a DES key despite > >> enabling weak crypto and adding the des enctypes. Not sure if this is a > >> problem on my end or not. I used RHEL 5 as the client. > > > > The problem is that the authoritative list for the IPA server is in > > cn=REALM.NAME,cn=kerberos,$suffix > > > > In there there are 2 multivalue attributes: krbDefaultEncSaltTypes and > > krbSupportedEncSaltTypes. > > > > You need to add any enctype you want 'supported' in that list. > > You may have to restart DS after you change those values as I don't > > remember if we update internal structures on the fly. > > Restarting the KDC did it. I disabled arcfour and now I see two failed > cert types from RHEL 5: > > $ ipa-getkeytab -s doberman.example.com -p test/zeus.example.com -k > /tmp/test.kt > Failed to retrieve encryption type ArcFour with HMAC/md5 (#23) > Failed to retrieve encryption type DES cbc mode with CRC-32 (#1) > Keytab successfully retrieved and stored in: /tmp/test.kt > > > > > On the patch where does the '48' comes from ? > > Completely arbitrarily trying to keep error on a single line (similar to > the list of supported enctypes truncating at 79). I do not like this much, but it is just an error message so ACK. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 5 15:52:12 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Mar 2012 10:52:12 -0500 Subject: [Freeipa-devel] [PATCH] 965 Allow ipa-getkeytab to skip missing enctypes In-Reply-To: <1330962054.26197.57.camel@willson.li.ssimo.org> References: <4F46FE74.2010309@redhat.com> <1330059604.18690.126.camel@willson.li.ssimo.org> <4F479758.7010908@redhat.com> <1330962054.26197.57.camel@willson.li.ssimo.org> Message-ID: <4F54E12C.6030605@redhat.com> Simo Sorce wrote: > On Fri, 2012-02-24 at 08:57 -0500, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2012-02-23 at 22:05 -0500, Rob Crittenden wrote: >>>> We noticed that older client machines couldn't join FreeIPA 2.1.90 >>>> servers running KDC 1.90. It was failing to return a ticket for DES so >>>> the whole keytab request was failing. >>>> >>>> I changed it so failures are acceptable as long as one requested type is >>>> returned. >>>> >>>> I wasn't able to get my KDC to actually return a DES key despite >>>> enabling weak crypto and adding the des enctypes. Not sure if this is a >>>> problem on my end or not. I used RHEL 5 as the client. >>> >>> The problem is that the authoritative list for the IPA server is in >>> cn=REALM.NAME,cn=kerberos,$suffix >>> >>> In there there are 2 multivalue attributes: krbDefaultEncSaltTypes and >>> krbSupportedEncSaltTypes. >>> >>> You need to add any enctype you want 'supported' in that list. >>> You may have to restart DS after you change those values as I don't >>> remember if we update internal structures on the fly. >> >> Restarting the KDC did it. I disabled arcfour and now I see two failed >> cert types from RHEL 5: >> >> $ ipa-getkeytab -s doberman.example.com -p test/zeus.example.com -k >> /tmp/test.kt >> Failed to retrieve encryption type ArcFour with HMAC/md5 (#23) >> Failed to retrieve encryption type DES cbc mode with CRC-32 (#1) >> Keytab successfully retrieved and stored in: /tmp/test.kt >> >>> >>> On the patch where does the '48' comes from ? >> >> Completely arbitrarily trying to keep error on a single line (similar to >> the list of supported enctypes truncating at 79). > > I do not like this much, but it is just an error message so ACK. > > Simo.krb5_enctype_to_string > I switch it to use 79 and be consistent with other uses of krb5_enctype_to_string() pushed to master and ipa-2-2 rob From rcritten at redhat.com Mon Mar 5 18:12:27 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Mar 2012 13:12:27 -0500 Subject: [Freeipa-devel] [PATCH] 980 fix NSSHTTPS class Message-ID: <4F55020B.4060602@redhat.com> I added a no_init option to NSSConnection but failed to add it to the older NSSHTTPS interface. This patch makes it work with older python versions. Pushed under 1-liner rule. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-980-noinit.patch Type: text/x-diff Size: 1060 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 5 22:28:12 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Mar 2012 17:28:12 -0500 Subject: [Freeipa-devel] Announcing FreeIPA v2.1.90 beta 1 Release Message-ID: <4F553DFC.7060302@redhat.com> The FreeIPA team is proud to announce version 2.1.90 beta 1. This will eventually become FreeIPA v2.2.0. It can be downloaded from http://www.freeipa.org/Downloads or from our development repo (http://freeipa.org/downloads/freeipa-devel.repo). Fedora 16 and 17 builds are available. Builds for Fedora 15 are no longer being provided. Packages that FreeIPA requires are not available in Fedora 15. == Highlights in 2.1.90 beta 1 == * Forms-based login. If Kerberos negotiate authentication fails you have the option of logging in using a form using username and password. Or you can go directly to /ipa/ui/login.html if you do not have/cannot get a Kerberos ticket. This is the preferred alternative login mechanism over enabling KrbMethodK5Passwd. * Logout from the UI * Support for SSH known-hosts with sssd 1.8.0. This will create a known-hosts file dynamically based on information stored in IPA. * DNS forwarders now configurable via IPA * Configurable by DNS zone: query policy, transfer policy, forward policy and forward and reverse synchronization. * More consistent hostname validation * Recommendation that the compat plugin be disabled during migration (unnecessary overhead) * On new installations the default users group, ipausers, is now non-POSIX == Upgrading == We tested upgrades from 2.1.4 successfully but this is beta code. We do not recommend upgrading a production server. Installing updated rpms is all that is required to upgrade from 2.1.4. It is unlikely that downgrading to a previous release once 2.1.90 is installed will work. Upgrading directly from the alpha may work but is untested. == Feedback == Please provide comments, bugs and other feedback via the freeipa-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed Changelog since 2.1.90 beta 1 == Jan Cholasta (1): * Configure SSH features of SSSD in ipa-client-install. John Dennis (8): * update translation pot file and PY_EXPLICIT_FILES list * update po files * created Transifex resource, adjust tx config file to point to it. * Tweak the session auth to reflect developer consensus. * Implement session activity timeout * Implement password based session login * Log a message when returning non-success HTTP result Martin Kosek (21): * Ease zonemgr restrictions * Update schema for bind-dyndb-ldap * Global DNS options * Query and transfer ACLs for DNS zones * Add DNS conditional forwarding * Add API for PTR sync control * Add gidnumber minvalue * Add reverse DNS record when forward is created * Sanitize UDP checks in conncheck * Add client hostname requirements to man page * Add SSHFP update policy for existing zones * Improve dns error message * Improve dnsrecord-add interactive mode * Improve hostname and domain name validation * Improve FQDN handling in DNS and host plugins * Improve hostname verification in install tools * Fix typos in ipa-replica-manage man page * Remove memberPrincipal for deleted replicas * Fix encoding for setattr/addattr/delattr * Add help for new structured DNS framework * Improve dnsrecord interactive help Ondrej Hamada (3): * Validate attributes in permission-add * Migration warning when compat enabled * ipa-client-install not calling authconfig Petr Viktorin (6): * Make ipausers a non-posix group on new installs * Add extra checking function to XMLRPC test framework * Add common helper for interactive prompts * Make sure the nolog argument to ipautil.run is not a bare string * Use stricter semantics when checking IP address for DNS records * Use stricter semantics when checking IP address for DNS records * Use reboot from /sbin Petr Voborn?k (18): * Fixed content type check in login_password * Improved usability of login dialog * Removed CSV creation from UI * Fixed problem when attributes_widget was displaying empty option * Added missing configuration options * Static metadata update - new DNS options * New checkboxes option: Mutual exclusive * DNS Zone UI: added new attributes * DNS UI: added A,AAAA create reverse options to adder dialog * Fixed displaying of A6 Record * New UI for DNS global configuration * Multiple fields for one attribute * Added attrs to permission when target is group or filter * Moved is_empty method from field to IPA object * Making validators to return true result if empty * Fixed DNS record add handling of 4304 error * Added unsupported_validator * Fixed redirection in Add and edit in automember hostgroup. * Fixed selection of single value in combobox * Added logout button * Forms based authentication UI Rob Crittenden (37): * Limit the change password permission so it can't change admin passwords * Don't allow "Modify Group membership" permission to manage admins * Add the -v option to sslget to provide more verbose errors * Make sure memberof is in replication attribute exclusion list. * Don't check for schema uniqueness when comparing in ldapupdate. * Add Conflicts on mod_ssl because it interferes with mod_proxy and dogtag * Don't allow IPA master hosts or important services be deleted. * Catch public exceptions when creating the LDAP context in WSGI. * Don't consider virtual attributes when validating custom objectclasses * Add Requires to ipa-client on oddjob-mkhomedir * Fix managing winsync replication agreements with ipa-replica-manage * Check for duplicate winsync agreement before trying to set one up. * Remove unused kpasswd.keytab and ldappwd files if they exist. * Make sure 389-ds is running when adding memcache service in upgrade. * Don't run restorecon if SELinux is disabled or not present. * Limit allowed characters in a netgroup name to alpha, digit, -, _ and . * Don't call memberof task when re-initializing a replica. * Fix bad merge of not calling memberof task when re-initializing a replica * Add support defaultNamingContext and add --basedn to migrate-ds * Fix nested netgroups in NIS. * Warn that deleting replica is irreversible, try to detect reconnection. * Don't set migrated user's GID to that of default users group. * Don't delete system users that are added during installation. * Only apply validation rules when adding and updating. * subclass HTTP_Status from plugable.Plugin, fix not_found tests * Make hostnames adhere to new standards in HBAC tests * Fix WSGI error handling * Add status command to retrieve user lockout status * Add support for sudoOrder * Make hostnames adhere to new standards in hbactest plugin tests * Fix API.txt and VERSION to reflect new sudoOrder option. * Add --noac option to ipa-client-install man page * Do kinit in client before connecting to backend * Only warn if ipa-getkeytab doesn't get all requested enctypes. * Fix NSS no_init in the NSSHTTPS class Simo Sorce (4): * ipa-kdb: Fix ACL evaluator * policy: add function to check lockout policy * ipa-kdb: fix delegation acl check * Fix ticket checks when using either s4u2proxy or a delegated krbtgt From mkosek at redhat.com Tue Mar 6 12:37:54 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Mar 2012 13:37:54 +0100 Subject: [Freeipa-devel] [PATCH] 230 Refresh resolvers after DNS install Message-ID: <1331037474.7279.5.camel@balmora.brq.redhat.com> The testing instructions are attached to the ticket. --- Server framework calls acutil.res_send() to send DNS queries used for various DNS tests. However, once acutil is imported it does not change its list of configured resolvers even when /etc/resolv.conf is changed. This may lead to unexpected resolution issues. We should at least reload httpd when we change /etc/resolv.conf to point to FreeIPA nameserver to force a new import of acutil and thus workaround this bug until it is resolved in authconfig. https://fedorahosted.org/freeipa/ticket/2481 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-230-refresh-resolvers-after-dns-install.patch Type: text/x-patch Size: 3794 bytes Desc: not available URL: From pspacek at redhat.com Tue Mar 6 12:46:36 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 06 Mar 2012 13:46:36 +0100 Subject: [Freeipa-devel] [PATCH] 0010 Remove unnecessary mctx double checks Message-ID: <4F56072C.6050300@redhat.com> Hello, this patch removes unnecessary double checks for isc_mem, which are scattered through the code. This problem was mentioned yesterday (another) patch review: https://www.redhat.com/archives/freeipa-devel/2012-March/msg00073.html On 03/05/2012 12:32 PM, Adam Tkac wrote: >> > + REQUIRE(mctx != NULL); > REQUIRE(mctx != NULL); is not needed, every isc_mem_* function checks mctx > validity. I checked each REQUIRE(mctx != NULL) and reference to "mctx" and Adam is right :-D -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0010-Remove-unnecessary-mctx-double-checks.patch Type: text/x-patch Size: 4941 bytes Desc: not available URL: From atkac at redhat.com Tue Mar 6 12:49:52 2012 From: atkac at redhat.com (Adam Tkac) Date: Tue, 06 Mar 2012 13:49:52 +0100 Subject: [Freeipa-devel] [PATCH] 0010 Remove unnecessary mctx double checks In-Reply-To: <4F56072C.6050300@redhat.com> References: <4F56072C.6050300@redhat.com> Message-ID: <4F5607F0.4030602@redhat.com> On 03/06/2012 01:46 PM, Petr Spacek wrote: > Hello, > > this patch removes unnecessary double checks for isc_mem, which are > scattered through the code. > > This problem was mentioned yesterday (another) patch review: > https://www.redhat.com/archives/freeipa-devel/2012-March/msg00073.html > > On 03/05/2012 12:32 PM, Adam Tkac wrote: > >> > + REQUIRE(mctx != NULL); > > REQUIRE(mctx != NULL); is not needed, every isc_mem_* function > checks mctx > > validity. > > I checked each REQUIRE(mctx != NULL) and reference to "mctx" and Adam > is right :-D Ack, please push it to master. A > > > bind-dyndb-ldap-pspacek-0010-Remove-unnecessary-mctx-double-checks.patch > > > From 15305dc1707dfa64dba993d33dfb7714b45d8362 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 6 Mar 2012 13:30:05 +0100 > Subject: [PATCH] Remove unnecessary mctx double checks. Signed-off-by: Petr > Spacek > > --- > src/ldap_convert.c | 1 - > src/ldap_driver.c | 3 --- > src/ldap_helper.c | 4 ---- > src/rdlist.c | 3 --- > src/str.c | 1 - > src/zone_manager.c | 1 - > src/zone_register.c | 4 ---- > 7 files changed, 0 insertions(+), 17 deletions(-) > > diff --git a/src/ldap_convert.c b/src/ldap_convert.c > index 71d930d..6405a98 100644 > --- a/src/ldap_convert.c > +++ b/src/ldap_convert.c > @@ -77,7 +77,6 @@ dn_to_dnsname(isc_mem_t *mctx, const char *dn, dns_name_t *target, > ld_string_t *ostr = NULL; > isc_buffer_t buffer; > > - REQUIRE(mctx != NULL); > REQUIRE(dn != NULL); > > INIT_BUFFERED_NAME(name); > diff --git a/src/ldap_driver.c b/src/ldap_driver.c > index 02d1cee..9e4522e 100644 > --- a/src/ldap_driver.c > +++ b/src/ldap_driver.c > @@ -205,8 +205,6 @@ clone_rdatalist_to_rdataset(isc_mem_t *mctx, dns_rdatalist_t *rdlist, > isc_result_t result; > dns_rdatalist_t *new_rdlist = NULL; > > - REQUIRE(mctx != NULL); > - > CHECK(rdatalist_clone(mctx, rdlist,&new_rdlist)); > > CHECK(dns_rdatalist_tordataset(new_rdlist, rdataset)); > @@ -1295,7 +1293,6 @@ dynamic_driver_init(isc_mem_t *mctx, const char *name, const char * const *argv, > { > isc_result_t result; > > - REQUIRE(mctx != NULL); > REQUIRE(name != NULL); > REQUIRE(argv != NULL); > REQUIRE(dyndb_args != NULL); > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 21c3690..2cb4dab 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -341,7 +341,6 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > end_of_settings > }; > > - REQUIRE(mctx != NULL); > REQUIRE(ldap_instp != NULL&& *ldap_instp == NULL); > > ldap_inst = isc_mem_get(mctx, sizeof(ldap_instance_t)); > @@ -1339,7 +1338,6 @@ ldapdb_nodelist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *nam > ldapdb_node_t *node; > dns_name_t node_name; > > - REQUIRE(mctx != NULL); > REQUIRE(ldap_inst != NULL); > REQUIRE(name != NULL); > REQUIRE(nodelist != NULL); > @@ -1408,7 +1406,6 @@ ldapdb_rdatalist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *na > ld_string_t *string = NULL; > ldap_cache_t *cache; > > - REQUIRE(mctx != NULL); > REQUIRE(ldap_inst != NULL); > REQUIRE(name != NULL); > REQUIRE(rdatalist != NULL); > @@ -1505,7 +1502,6 @@ parse_rdata(isc_mem_t *mctx, ldap_connection_t *ldap_conn, > isc_region_t rdatamem; > dns_rdata_t *rdata; > > - REQUIRE(mctx != NULL); > REQUIRE(ldap_conn != NULL); > REQUIRE(rdata_text != NULL); > REQUIRE(rdatap != NULL); > diff --git a/src/rdlist.c b/src/rdlist.c > index 71ca752..903c948 100644 > --- a/src/rdlist.c > +++ b/src/rdlist.c > @@ -40,7 +40,6 @@ rdata_clone(isc_mem_t *mctx, dns_rdata_t *source, dns_rdata_t **targetp) > dns_rdata_t *target = NULL; > isc_region_t target_region, source_region; > > - REQUIRE(mctx != NULL); > REQUIRE(source != NULL); > REQUIRE(targetp != NULL&& *targetp == NULL); > > @@ -76,7 +75,6 @@ rdatalist_clone(isc_mem_t *mctx, dns_rdatalist_t *source, > dns_rdata_t *target_rdata; > isc_result_t result; > > - REQUIRE(mctx != NULL); > REQUIRE(source != NULL); > REQUIRE(targetp != NULL&& *targetp == NULL); > > @@ -116,7 +114,6 @@ ldap_rdatalist_copy(isc_mem_t *mctx, ldapdb_rdatalist_t source, > dns_rdatalist_t *new_rdlist; > isc_result_t result; > > - REQUIRE(mctx != NULL); > REQUIRE(target != NULL); > > INIT_LIST(*target); > diff --git a/src/str.c b/src/str.c > index 56faa12..0096536 100644 > --- a/src/str.c > +++ b/src/str.c > @@ -145,7 +145,6 @@ str__new(isc_mem_t *mctx, ld_string_t **new_str _STR_MEM_FLARG) > { > ld_string_t *str; > > - REQUIRE(mctx != NULL); > REQUIRE(new_str != NULL&& *new_str == NULL); > > #if ISC_MEM_TRACKLINES > diff --git a/src/zone_manager.c b/src/zone_manager.c > index c8a144f..eb761aa 100644 > --- a/src/zone_manager.c > +++ b/src/zone_manager.c > @@ -124,7 +124,6 @@ manager_create_db_instance(isc_mem_t *mctx, const char *name, > end_of_settings > }; > > - REQUIRE(mctx != NULL); > REQUIRE(name != NULL); > REQUIRE(dyndb_args != NULL); > > diff --git a/src/zone_register.c b/src/zone_register.c > index adbe934..fc6dc07 100644 > --- a/src/zone_register.c > +++ b/src/zone_register.c > @@ -70,7 +70,6 @@ zr_create(isc_mem_t *mctx, zone_register_t **zrp) > isc_result_t result; > zone_register_t *zr = NULL; > > - REQUIRE(mctx != NULL); > REQUIRE(zrp != NULL&& *zrp == NULL); > > CHECKED_MEM_GET_PTR(mctx, zr); > @@ -124,7 +123,6 @@ create_zone_info(isc_mem_t *mctx, dns_zone_t *zone, const char *dn, > isc_result_t result; > zone_info_t *zinfo; > > - REQUIRE(mctx != NULL); > REQUIRE(zone != NULL); > REQUIRE(dn != NULL); > REQUIRE(zinfop != NULL&& *zinfop == NULL); > @@ -152,8 +150,6 @@ delete_zone_info(void *arg1, void *arg2) > zone_info_t *zinfo = arg1; > isc_mem_t *mctx = arg2; > > - REQUIRE(mctx != NULL); > - > if (zinfo == NULL) > return; > From pviktori at redhat.com Tue Mar 6 12:55:43 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 06 Mar 2012 13:55:43 +0100 Subject: [Freeipa-devel] [PATCH] 0020 Allow removing sudo commands with special characters from command groups In-Reply-To: <4F54D75F.3010503@redhat.com> References: <4F54D75F.3010503@redhat.com> Message-ID: <4F56094F.8000206@redhat.com> On 03/05/2012 04:10 PM, Petr Viktorin wrote: > This patch fixes DN handling when removing LDAP entries from groups. > > Because they deal with commas and backslashes in a CSV param, the tests > here rely on my patch 0015. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Here is the same patch with CSV-stuff-dependent tests removed. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0020-02-Allow-removing-sudo-commands-with-special-characters.patch Type: text/x-patch Size: 5793 bytes Desc: not available URL: From pspacek at redhat.com Tue Mar 6 12:57:44 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 06 Mar 2012 13:57:44 +0100 Subject: [Freeipa-devel] [PATCH] 0010 Remove unnecessary mctx double checks In-Reply-To: <4F5607F0.4030602@redhat.com> References: <4F56072C.6050300@redhat.com> <4F5607F0.4030602@redhat.com> Message-ID: <4F5609C8.1040902@redhat.com> On 03/06/2012 01:49 PM, Adam Tkac wrote: > On 03/06/2012 01:46 PM, Petr Spacek wrote: >> Hello, >> >> this patch removes unnecessary double checks for isc_mem, which are >> scattered through the code. >> >> This problem was mentioned yesterday (another) patch review: >> https://www.redhat.com/archives/freeipa-devel/2012-March/msg00073.html >> >> On 03/05/2012 12:32 PM, Adam Tkac wrote: >> >> > + REQUIRE(mctx != NULL); >> > REQUIRE(mctx != NULL); is not needed, every isc_mem_* function >> checks mctx >> > validity. >> >> I checked each REQUIRE(mctx != NULL) and reference to "mctx" and Adam >> is right :-D > > Ack, please push it to master. > > A Pushed to master. https://fedorahosted.org/bind-dyndb-ldap/changeset/15305dc1707dfa64dba993d33dfb7714b45d8362 Petr^2 Spacek > >> >> >> bind-dyndb-ldap-pspacek-0010-Remove-unnecessary-mctx-double-checks.patch >> >> >> From 15305dc1707dfa64dba993d33dfb7714b45d8362 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Tue, 6 Mar 2012 13:30:05 +0100 >> Subject: [PATCH] Remove unnecessary mctx double checks. Signed-off-by: >> Petr >> Spacek From dpal at redhat.com Tue Mar 6 15:56:30 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 06 Mar 2012 10:56:30 -0500 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <1330896212.26197.32.camel@willson.li.ssimo.org> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> Message-ID: <4F5633AE.2090102@redhat.com> [...] > > > For a read-only KDC we need to investigate what's the better solution. > There are many ways we can handle the issue, one of the simplest is > probably to allow the RO KDC to use a special LDAP Extended operation > against a full R/W server to get the user keys to sign, authenticating > with a special R/O KDC principal. We can also investigate how MS does > internal forwarding and do something similar as I suspect that's > something samba4-RODC will want to implement too, so we could share some > of the development burden there. > > Simo. > I do not think it is a good idea for the remote RO KDC to go back to the main datacenter on every authentication without some sort of caching. This is why I think that some kind of SSSD integration might be due. If RO KDC would just pass the authentication to SSSD in some way and SSSD would do the caching in case the office gets offline. I understand that authhub as is will not work as the client sends time stamp encrypted with password and SSSD needs plain text password as credential. I do not know if there is a way to solve this without actually sending the password in the tunnel. IMO it is more important to make sure that remote office can have uninterrupted operation than to worry about the password being sent inside the encrypted tunnel. It is something that deployment should decide and weight risks against convenience. -- 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 simo at redhat.com Tue Mar 6 15:59:22 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 06 Mar 2012 10:59:22 -0500 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <4F5633AE.2090102@redhat.com> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> Message-ID: <1331049562.26197.82.camel@willson.li.ssimo.org> On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: > [...] > > > > > > For a read-only KDC we need to investigate what's the better > solution. > > There are many ways we can handle the issue, one of the simplest is > > probably to allow the RO KDC to use a special LDAP Extended > operation > > against a full R/W server to get the user keys to sign, > authenticating > > with a special R/O KDC principal. We can also investigate how MS > does > > internal forwarding and do something similar as I suspect that's > > something samba4-RODC will want to implement too, so we could share > some > > of the development burden there. > > > > Simo. > > > > I do not think it is a good idea for the remote RO KDC to go back to > the main datacenter on every authentication without some sort of > caching. This is why I think that some kind of SSSD integration might > be due. If RO KDC would just pass the authentication to SSSD in some > way and SSSD would do the caching in case the office gets offline. I > understand that authhub as is will not work as the client sends time > stamp encrypted with password and SSSD needs plain text password as > credential. I do not know if there is a way to solve this without > actually sending the password in the tunnel. IMO it is more important > to make sure that remote office can have uninterrupted operation than > to worry about the password being sent inside the encrypted tunnel. It > is something that deployment should decide and weight risks against > convenience. This is why MS does partial replication, ie allows the RODC to have data about the office users. It's complex and there are many ways to handle it. We need to look at various options and see how they would work against uses cases we want to support. > Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Mar 6 16:47:11 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 06 Mar 2012 11:47:11 -0500 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <1331049562.26197.82.camel@willson.li.ssimo.org> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> <1331049562.26197.82.camel@willson.li.ssimo.org> Message-ID: <4F563F8F.5080504@redhat.com> On 03/06/2012 10:59 AM, Simo Sorce wrote: > On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: >> [...] >>> >>> For a read-only KDC we need to investigate what's the better >> solution. >>> There are many ways we can handle the issue, one of the simplest is >>> probably to allow the RO KDC to use a special LDAP Extended >> operation >>> against a full R/W server to get the user keys to sign, >> authenticating >>> with a special R/O KDC principal. We can also investigate how MS >> does >>> internal forwarding and do something similar as I suspect that's >>> something samba4-RODC will want to implement too, so we could share >> some >>> of the development burden there. >>> >>> Simo. >>> >> I do not think it is a good idea for the remote RO KDC to go back to >> the main datacenter on every authentication without some sort of >> caching. This is why I think that some kind of SSSD integration might >> be due. If RO KDC would just pass the authentication to SSSD in some >> way and SSSD would do the caching in case the office gets offline. I >> understand that authhub as is will not work as the client sends time >> stamp encrypted with password and SSSD needs plain text password as >> credential. I do not know if there is a way to solve this without >> actually sending the password in the tunnel. IMO it is more important >> to make sure that remote office can have uninterrupted operation than >> to worry about the password being sent inside the encrypted tunnel. It >> is something that deployment should decide and weight risks against >> convenience. > This is why MS does partial replication, ie allows the RODC to have data > about the office users. It's complex and there are many ways to handle > it. We need to look at various options and see how they would work > against uses cases we want to support. > Simo. > Then may be Ondrej should start with formulating use cases and requirements based on this discussion. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From atkac at redhat.com Tue Mar 6 16:57:18 2012 From: atkac at redhat.com (Adam Tkac) Date: Tue, 06 Mar 2012 17:57:18 +0100 Subject: [Freeipa-devel] named core dump In-Reply-To: References: <1329680680.18690.16.camel@willson.li.ssimo.org> <20120221141853.GA13230@redhat.com> Message-ID: <4F5641EE.90402@redhat.com> On 02/21/2012 07:55 PM, Marco Pizzoli wrote: > Hi Adam, Hello Marco, thanks for information. This issue should be fixed in 1.1.0b1 release. I've just submitted update for Fedora (https://admin.fedoraproject.org/updates/bind-dyndb-ldap-1.1.0-0.9.b1.fc16) so please test it and let us know if it still crashes. Regards, Adam > > On Tue, Feb 21, 2012 at 3:18 PM, Adam Tkac wrote: > >> On Sun, Feb 19, 2012 at 09:30:47PM +0100, Marco Pizzoli wrote: >>> On Sun, Feb 19, 2012 at 8:44 PM, Simo Sorce wrote: >>> >>>> On Sun, 2012-02-19 at 17:17 +0100, Marco Pizzoli wrote: >>>>> Hi guys, >>>>> today I'm playing a lot with FreeIPA 2.1.90. >>>>> I'm not sure about the exact moment, but I had a named core dump. >>>>> >>>>> My system run with named: >>>>> bind-license-9.8.2-0.2.rc1.fc16.noarch >>>>> bind-libs-lite-9.8.2-0.2.rc1.fc16.x86_64 >>>>> bind-9.8.2-0.2.rc1.fc16.x86_64 >>>>> bind-libs-9.8.2-0.2.rc1.fc16.x86_64 >>>>> bind-utils-9.8.2-0.2.rc1.fc16.x86_64 >>>>> bind-dyndb-ldap-1.1.0-0.8.a2.fc16.x86_64 >>>>> >>>>> Probably it happened during a "ipa-client-install >>>>> --enable-dns-updates" execution from a client machine. I have saved >>>>> the core and I can send to you if necessary. >>>>> Actually my "freeipa01" fedora16 system generated a dir >>>>> under /var/spool/abrt which I think could be more meaningful in >>>>> tracking the cause. >>>>> This is what I saw in my /var/log/messages log >>>>> >>>>> [ 5111.204303] named[1127] general protection ip:7f80d502cd82 >>>>> sp:7f80d6a82148 error:0 in ldap.so[7f80d5024000+1c000] >>>>> >>>> Do you have a backtrace in the abrt dir ? >>>> If so can you send it to the list ? >>>> >>> Honestly, I'm not a great expert in dealing with these things. I hope to >>> have followed the right steps. >>> Please give me a feedback in both cases. >> This backtrace is sufficient, it's very similar to one I've received >> recently to >> our bugzilla. >> >> Can you please check your /var/log/messages if there are any errors from >> named >> right before the crash? It's just for confirmation that your crash is same >> which >> I'm currently working on. Especially if there is something like >> >> named[4818]: bind to LDAP server failed: Invalid credentials >> named[4818]: reloading configuration failed: permission denied >> >> Thank you in advance. >> >> Regards, Adam >> > This is your answer > > Feb 19 16:35:14 freeipa01 named[1126]: bind to LDAP server failed: Timed out > Feb 19 16:35:14 freeipa01 named[1126]: reloading configuration failed: > failure > > I digged my logs more and I found out that last week-end I had another > crash. This is the complete log of what happened. > Bear in mind I was running freeipa in a VMware VM on my laptop **with other > vm active&running at the same time** > > Feb 18 15:16:13 freeipa01 kernel: [ 568.683234] BUG: soft lockup - CPU#0 > stuck for 22s! [khugepaged:23] > Feb 18 15:16:13 freeipa01 kernel: [ 568.683720] Modules linked in: 8021q > garp stp llc snd_ens1371 gameport joydev snd_rawmidi snd_ac97_codec > ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd ppdev i2c_piix4 > parport_pc parport soundcore e1000 snd_page_alloc shpchp i2c_core vmw_ba > lloon microcode uinput mptspi mptscsih mptbase scsi_transport_spi [last > unloaded: scsi_wait_scan] > Feb 18 15:16:13 freeipa01 kernel: [ 568.683762] CPU 0 > Feb 18 15:16:13 freeipa01 kernel: [ 568.683763] Modules linked in: 8021q > garp stp llc snd_ens1371 gameport joydev snd_rawmidi snd_ac97_codec > ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd ppdev i2c_piix4 > parport_pc parport soundcore e1000 snd_page_alloc shpchp i2c_core vmw_ba > lloon microcode uinput mptspi mptscsih mptbase scsi_transport_spi [last > unloaded: scsi_wait_scan] > Feb 18 15:16:13 freeipa01 kernel: [ 568.683874] > Feb 18 15:16:13 freeipa01 kernel: [ 568.683877] Pid: 23, comm: khugepaged > Not tainted 3.2.5-3.fc16.x86_64 #1 VMware, Inc. VMware Virtual Plat > form/440BX Desktop Reference Platform > Feb 18 15:16:13 freeipa01 kernel: [ 568.879568] RIP: > 0010:[] [] copy_page+0x49/0xe0 > Feb 18 15:16:13 freeipa01 kernel: [ 568.879607] RSP: > 0018:ffff880039a85d60 EFLAGS: 00010206 > Feb 18 15:16:13 freeipa01 kernel: [ 568.879608] RAX: 387421c6f640e6d3 RBX: > ffff880039a85d00 RCX: 000000000000003a > Feb 18 15:16:13 freeipa01 kernel: [ 568.879610] RDX: 48186d894c107d89 RSI: > ffff8800015f8000 RDI: ffff880003dc8000 > Feb 18 15:16:13 freeipa01 kernel: [ 568.879612] RBP: ffff880039a85d90 R08: > 000002a0840f183b R09: 48e0658b4cde8948 > Feb 18 15:16:13 freeipa01 kernel: [ 568.879613] R10: 4ce86d8b4cd85d8b R11: > c9f87d8b4cf0758b R12: ffff880039a85d40 > Feb 18 15:16:13 freeipa01 kernel: [ 568.879615] R13: ffff88003fa16b70 R14: > ffff88003ffec700 R15: ffffea0000b70c40 > Feb 18 15:16:13 freeipa01 kernel: [ 568.879646] FS: > 0000000000000000(0000) GS:ffff88003fa00000(0000) knlGS:0000000000000000 > Feb 18 15:16:13 freeipa01 kernel: [ 568.879648] CS: 0010 DS: 0000 ES: > 0000 CR0: 000000008005003b > Feb 18 15:16:13 freeipa01 kernel: [ 568.879649] CR2: 00007fbe7f1f18f4 CR3: > 0000000039991000 CR4: 00000000000406f0 > Feb 18 15:16:13 freeipa01 kernel: [ 568.879671] DR0: 0000000000000000 DR1: > 0000000000000000 DR2: 0000000000000000 > Feb 18 15:16:13 freeipa01 kernel: [ 568.879689] DR3: 0000000000000000 DR6: > 00000000ffff0ff0 DR7: 0000000000000400 > Feb 18 15:16:13 freeipa01 kernel: [ 568.879692] Process khugepaged (pid: > 23, threadinfo ffff880039a84000, task ffff88003cd6ae40) > Feb 18 15:16:13 freeipa01 kernel: [ 568.879693] Stack: > Feb 18 15:16:13 freeipa01 kernel: [ 569.196843] ffff880039a84000 > ffff8800059b73f0 0000000000000001 ffffffff815da732 > Feb 18 15:16:13 freeipa01 kernel: [ 569.196849] a80002efe1000000 > ffffea0000057e00 ffff880039a85ee0 ffffffff8116ae5f > Feb 18 15:16:13 freeipa01 kernel: [ 569.196851] ffff88003fa137f0 > 0000000000000000 ffff88003b402680 ffffea0000c23700 > Feb 18 15:16:13 freeipa01 kernel: [ 569.196856] Call Trace: > Feb 18 15:16:13 freeipa01 kernel: [ 569.196968] [] ? > copy_user_highpage+0x57/0x62 > Feb 18 15:16:13 freeipa01 kernel: [ 569.196986] [] > khugepaged+0x10bf/0x1380 > Feb 18 15:16:13 freeipa01 kernel: [ 569.197000] [] ? > remove_wait_queue+0x50/0x50 > Feb 18 15:16:13 freeipa01 kernel: [ 569.197003] [] ? > collect_mm_slot+0xa0/0xa0 > Feb 18 15:16:13 freeipa01 kernel: [ 569.197006] [] > kthread+0x8c/0xa0 > Feb 18 15:16:13 freeipa01 kernel: [ 569.197015] [] > kernel_thread_helper+0x4/0x10 > Feb 18 15:16:13 freeipa01 kernel: [ 569.197018] [] ? > kthread_worker_fn+0x190/0x190 > Feb 18 15:16:13 freeipa01 kernel: [ 569.197020] [] ? > gs_change+0x13/0x13 > Feb 18 15:16:13 freeipa01 kernel: [ 569.197022] Code: 00 00 48 ff c9 48 8b > 06 48 8b 5e 08 48 8b 56 10 4c 8b 46 18 4c 8b 4e 20 4c 8b 56 28 4c 8b 5e 30 > 4c 8b 66 38 0f 18 8e 40 01 00 00<48> 89 07 48 89 5f 08 48 89 57 10 4c 89 > 47 18 4c 89 4f 20 4c 89 > Feb 18 15:16:13 freeipa01 kernel: [ 569.200211] Call Trace: > Feb 18 15:16:13 freeipa01 kernel: [ 569.200215] [] ? > copy_user_highpage+0x57/0x62 > Feb 18 15:16:13 freeipa01 kernel: [ 569.200218] [] > khugepaged+0x10bf/0x1380 > Feb 18 15:16:13 freeipa01 kernel: [ 569.200221] [] ? > remove_wait_queue+0x50/0x50 > Feb 18 15:16:13 freeipa01 kernel: [ 569.200223] [] ? > collect_mm_slot+0xa0/0xa0 > Feb 18 15:16:13 freeipa01 kernel: [ 569.200225] [] > kthread+0x8c/0xa0 > Feb 18 15:16:13 freeipa01 kernel: [ 569.200227] [] > kernel_thread_helper+0x4/0x10 > Feb 18 15:16:13 freeipa01 kernel: [ 569.200230] [] ? > kthread_worker_fn+0x190/0x190 > Feb 18 15:16:13 freeipa01 kernel: [ 569.200232] [] ? > gs_change+0x13/0x13 > *Feb 18 15:16:13 freeipa01 named[1129]: LDAP query timed out. Try to adjust > "timeout" parameter* > Feb 18 15:16:40 freeipa01 kernel: [ 596.627972] BUG: soft lockup - CPU#0 > stuck for 23s! [khugepaged:23] > Feb 18 15:16:40 freeipa01 kernel: [ 596.628574] Modules linked in: 8021q > garp stp llc snd_ens1371 gameport joydev snd_rawmidi snd_ac97_codec > ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd ppdev i2c_piix4 > parport_pc parport soundcore e1000 snd_page_alloc shpchp i2c_core > vmw_balloon microcode uinput mptspi mptscsih mptbase scsi_transport_spi > [last unloaded: scsi_wait_scan] > Feb 18 15:16:40 freeipa01 kernel: [ 596.628598] CPU 0 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628599] Modules linked in: 8021q > garp stp llc snd_ens1371 gameport joydev snd_rawmidi snd_ac97_codec > ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd ppdev i2c_piix4 > parport_pc parport soundcore e1000 snd_page_alloc shpchp i2c_core > vmw_balloon microcode uinput mptspi mptscsih mptbase scsi_transport_spi > [last unloaded: scsi_wait_scan] > Feb 18 15:16:40 freeipa01 kernel: [ 596.628618] > Feb 18 15:16:40 freeipa01 kernel: [ 596.628620] Pid: 23, comm: khugepaged > Not tainted 3.2.5-3.fc16.x86_64 #1 VMware, Inc. VMware Virtual > Platform/440BX Desktop Reference Platform > Feb 18 15:16:40 freeipa01 kernel: [ 596.628624] RIP: > 0010:[] [] copy_page+0x49/0xe0 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628631] RSP: > 0018:ffff880039a85d60 EFLAGS: 00010206 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628633] RAX: 038e048d058c4906 RBX: > ffff880039a85d00 RCX: 000000000000003a > Feb 18 15:16:40 freeipa01 kernel: [ 596.628634] RDX: 000000000b480807 RSI: > ffff880021c63000 RDI: ffff880003f28000 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628636] RBP: ffff880039a85d90 R08: > 000cc1d400000024 R09: 00000064ffdd10b0 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628641] R10: 0d480286100e4100 R11: > 070c510203834506 R12: ffff880039a85d40 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628642] R13: ffff88003fa16b70 R14: > ffff88003ffec700 R15: ffffea0000871dc0 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628670] FS: > 0000000000000000(0000) GS:ffff88003fa00000(0000) knlGS:0000000000000000 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628672] CS: 0010 DS: 0000 ES: > 0000 CR0: 000000008005003b > Feb 18 15:16:40 freeipa01 kernel: [ 596.628673] CR2: 00007fd4a529ee8c CR3: > 0000000039991000 CR4: 00000000000406f0 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628715] DR0: 0000000000000000 DR1: > 0000000000000000 DR2: 0000000000000000 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628732] DR3: 0000000000000000 DR6: > 00000000ffff0ff0 DR7: 0000000000000400 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628734] Process khugepaged (pid: > 23, threadinfo ffff880039a84000, task ffff88003cd6ae40) > Feb 18 15:16:40 freeipa01 kernel: [ 596.628736] Stack: > Feb 18 15:16:40 freeipa01 kernel: [ 596.628805] ffff880039a84000 > ffff8800059b73f0 0000000000000001 ffffffff815da732 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628808] a800021cc2000000 > ffffea00008718c0 ffff880039a85ee0 ffffffff8116ae5f > Feb 18 15:16:40 freeipa01 kernel: [ 596.628810] ffff88003fa137f0 > 0000000000000000 ffff88003b402680 ffffea00009ea740 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628812] Call Trace: > Feb 18 15:16:40 freeipa01 kernel: [ 596.628891] [] ? > copy_user_highpage+0x57/0x62 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628896] [] > khugepaged+0x10bf/0x1380 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628900] [] ? > remove_wait_queue+0x50/0x50 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628902] [] ? > collect_mm_slot+0xa0/0xa0 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628904] [] > kthread+0x8c/0xa0 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628908] [] > kernel_thread_helper+0x4/0x10 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628910] [] ? > kthread_worker_fn+0x190/0x190 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628912] [] ? > gs_change+0x13/0x13 > Feb 18 15:16:40 freeipa01 kernel: [ 596.628913] Code: 00 00 48 ff c9 48 8b > 06 48 8b 5e 08 48 8b 56 10 4c 8b 46 18 4c 8b 4e 20 4c 8b 56 28 4c 8b 5e 30 > 4c 8b 66 38 0f 18 8e 40 01 00 00<48> 89 07 48 89 5f 08 48 89 57 10 4c 89 > 47 18 4c 89 4f 20 4c 89 > Feb 18 15:16:40 freeipa01 kernel: [ 596.631774] Call Trace: > Feb 18 15:16:40 freeipa01 kernel: [ 596.631778] [] ? > copy_user_highpage+0x57/0x62 > Feb 18 15:16:40 freeipa01 kernel: [ 596.631780] [] > khugepaged+0x10bf/0x1380 > Feb 18 15:16:40 freeipa01 kernel: [ 596.631783] [] ? > remove_wait_queue+0x50/0x50 > Feb 18 15:16:40 freeipa01 kernel: [ 596.631785] [] ? > collect_mm_slot+0xa0/0xa0 > Feb 18 15:16:40 freeipa01 kernel: [ 596.631787] [] > kthread+0x8c/0xa0 > Feb 18 15:16:40 freeipa01 kernel: [ 596.631789] [] > kernel_thread_helper+0x4/0x10 > Feb 18 15:16:40 freeipa01 kernel: [ 596.631792] [] ? > kthread_worker_fn+0x190/0x190 > Feb 18 15:16:40 freeipa01 kernel: [ 596.631794] [] ? > gs_change+0x13/0x13 > Feb 18 15:16:40 freeipa01 abrt-dump-oops[771]: abrt-dump-oops: Found > oopses: 1 > Feb 18 15:16:41 freeipa01 dbus-daemon[813]: dbus[813]: [system] Activating > service name='org.fedoraproject.Setroubleshootd' (using servicehelper) > Feb 18 15:16:41 freeipa01 dbus[813]: [system] Activating service > name='org.fedoraproject.Setroubleshootd' (using servicehelper) > Feb 18 15:16:41 freeipa01 abrt-dump-oops[771]: abrt-dump-oops: Creating > dump directories > *Feb 18 15:16:41 freeipa01 named[1129]: rbt.c:2657: REQUIRE((((chain) != > ((void *)0))&& (((const isc__magic_t *)(chain))->magic == ((('0')<< 24 | > ('-')<< 16 | ('0')<< 8 | ('-')))))) failed, back trace* > Feb 18 15:16:41 freeipa01 named[1129]: #0 0x7fd4a806180b in ?? > Feb 18 15:16:41 freeipa01 named[1129]: #1 0x7fd4a63027ba in ?? > Feb 18 15:16:41 freeipa01 named[1129]: #2 0x7fd4a78ea29c in ?? > Feb 18 15:16:41 freeipa01 named[1129]: #3 0x7fd4a78eb199 in ?? > Feb 18 15:16:41 freeipa01 named[1129]: #4 0x7fd4a2872e01 in ?? > Feb 18 15:16:41 freeipa01 named[1129]: #5 0x7fd4a28769c6 in ?? > Feb 18 15:16:41 freeipa01 named[1129]: #6 0x7fd4a6321e98 in ?? > Feb 18 15:16:41 freeipa01 named[1129]: #7 0x7fd4a5cd7d90 in ?? > Feb 18 15:16:41 freeipa01 named[1129]: #8 0x7fd4a521348d in ?? > Feb 18 15:16:41 freeipa01 named[1129]: exiting (due to assertion failure) > Feb 18 15:16:41 freeipa01 abrt-dump-oops: Reported 1 kernel oopses to Abrt > Feb 18 15:16:41 freeipa01 abrtd: Directory 'oops-2012-02-18-15:16:41-771-0' > creation detected > Feb 18 15:16:43 freeipa01 abrt[1629]: /var/named/core.1129 is not a regular > file with link count 1: Permission denied > Feb 18 15:16:44 freeipa01 abrtd: Can't open file '/var/spool/abrt/oops- > 2012-02-18-15:16:41-771-0/uid': No such file or directory > Feb 18 15:16:50 freeipa01 abrtd: New problem directory /var/spool/abrt/oops- > 2012-02-18-15:16:41-771-0, processing > Feb 18 15:16:50 freeipa01 abrtd: Can't open file '/var/spool/abrt/oops- > 2012-02-18-15:16:41-771-0/uid': No such file or directory > Feb 18 15:16:57 freeipa01 abrt[1629]: Saved core dump of pid 1129 > (/usr/sbin/named) to /var/spool/abrt/ccpp-2012-02-18-15:16:43-1129 > (59924480 bytes) > Feb 18 15:16:57 freeipa01 abrtd: Directory 'ccpp-2012-02-18-15:16:43-1129' > creation detected > Feb 18 15:17:06 freeipa01 dbus[813]: [system] Failed to activate service > 'org.fedoraproject.Setroubleshootd': timed out > Feb 18 15:17:06 freeipa01 dbus-daemon[813]: dbus[813]: [system] Failed to > activate service 'org.fedoraproject.Setroubleshootd': timed out > Feb 18 15:17:19 freeipa01 abrtd: New problem directory /var/spool/abrt/ccpp- > 2012-02-18-15:16:43-1129, processing > > > > > This is the backtrace related to this other coredump. > > [root at freeipa01 ccpp-2012-02-18-15:16:43-1129]# gdb coredump > GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16) > Copyright (C) 2011 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/sbin/named...Reading symbols from > /usr/lib/debug/usr/sbin/named.debug...done. > done. > [New LWP 1130] > [New LWP 1131] > [New LWP 1132] > [New LWP 1129] > Missing separate debuginfo for /usr/lib64/bind/ldap.so > Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install > /usr/lib/debug/.build-id/86/9cfab5937a0516b105c8b7ba5e4500e8029093 > > warning: Can't read pathname for load map: Input/output error. > Core was generated by `/usr/sbin/named -u named'. > Program terminated with signal 6, Aborted. > #0 0x00007fd4a515a285 in ?? () > Missing separate debuginfos, use: debuginfo-install > cyrus-sasl-gssapi-2.1.23-27.fc16.x86_64 > cyrus-sasl-lib-2.1.23-27.fc16.x86_64 cyrus-sasl-md5-2.1.23-27.fc16.x86_64 > cyrus-sasl-plain-2.1.23-27.fc16.x86_64 glibc-2.14.90-24.fc16.4.x86_64 > keyutils-libs-1.5.2-1.fc16.x86_64 krb5-libs-1.9.2-6.fc16.x86_64 > libattr-2.4.46-2.fc16.x86_64 libcap-2.22-1.fc15.x86_64 > libcom_err-1.41.14-2.fc15.x86_64 libdb-5.2.36-1.fc16.x86_64 > libgcc-4.6.2-1.fc16.x86_64 libselinux-2.1.6-6.fc16.x86_64 > libxml2-2.7.8-6.fc16.x86_64 nspr-4.8.9-2.fc16.x86_64 > nss-3.13.1-11.fc16.x86_64 nss-softokn-freebl-3.13.1-15.fc16.x86_64 > nss-util-3.13.1-3.fc16.x86_64 openldap-2.4.26-6.fc16.x86_64 > openssl-1.0.0g-1.fc16.x86_64 sssd-client-1.7.0-5.fc16.x86_64 > zlib-1.2.5-6.fc16.x86_64 > (gdb) > (gdb) > (gdb) > (gdb) bt > #0 0x00007fd4a515a285 in ?? () > #1 0x00007fd4a515bb9b in ?? () > #2 0x0000000000000009 in ?? () > #3 0x00007fd4a82aff38 in ns_g_categories () > #4 0x00007fd4a82aff28 in ?? () > #5 0x00007fd4a654bcb0 in isc_categories () from /usr/lib64/libisc.so.83.0.3 > #6 0x00007fd4a654bca0 in isc_modules () from /usr/lib64/libisc.so.83.0.3 > #7 0x00007fd4a630fa8d in isc_log_write (lctx=, > category=, module=, level=, > format=) at log.c:840 > #8 0x00007fd4a80619c9 in assertion_failed (file=, > line=, type=, cond=) > at ./main.c:219 > #9 0x00007fd4a63027ba in isc_assertion_failed (file=, > line=, type=, cond=) > at assertions.c:57 > #10 0x00007fd4a78ea29c in dns_rbtnodechain_reset (chain=) at > rbt.c:2657 > #11 dns_rbtnodechain_reset (chain=) at rbt.c:2651 > #12 0x00007fd4a78eb199 in dns_rbtnodechain_invalidate > (chain=0x7fd4a42c0d90) at rbt.c:2671 > #13 0x00007fd4a2872e01 in ?? () > #14 0x00007fd4a2879a70 in ?? () > #15 0x00007fd49c202150 in ?? () > #16 0x00007fd400000000 in ?? () > #17 0x00007fd4a992f250 in ?? () > #18 0x0000000000000000 in ?? () > > Hope this helps > Marco > > > >>> [root at freeipa01 ccpp-2012-02-19-16:37:03-1126]# gdb coredump >>> GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16) >>> Copyright (C) 2011 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later< >> http://gnu.org/licenses/gpl.html >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >>> and "show warranty" for details. >>> This GDB was configured as "x86_64-redhat-linux-gnu". >>> For bug reporting instructions, please see: >>> ... >>> Reading symbols from /usr/sbin/named...Reading symbols from >>> /usr/lib/debug/usr/sbin/named.debug...done. >>> done. >>> [New LWP 1127] >>> [New LWP 1128] >>> [New LWP 1129] >>> [New LWP 1126] >>> >>> warning: Can't read pathname for load map: Input/output error. >>> Core was generated by `/usr/sbin/named -u named'. >>> Program terminated with signal 11, Segmentation fault. >>> #0 0x00007f80d502cd82 in ldap_cache_enabled (cache=0xdededededededede) >> at >>> cache.c:216 >>> 216 return (cache->rbt != NULL) ? ISC_TRUE : ISC_FALSE; >>> Missing separate debuginfos, use: debuginfo-install >>> cyrus-sasl-gssapi-2.1.23-27.fc16.x86_64 >>> cyrus-sasl-lib-2.1.23-27.fc16.x86_64 cyrus-sasl-md5-2.1.23-27.fc16.x86_64 >>> cyrus-sasl-plain-2.1.23-27.fc16.x86_64 glibc-2.14.90-24.fc16.4.x86_64 >>> keyutils-libs-1.5.2-1.fc16.x86_64 krb5-libs-1.9.2-6.fc16.x86_64 >>> libattr-2.4.46-2.fc16.x86_64 libcap-2.22-1.fc15.x86_64 >>> libcom_err-1.41.14-2.fc15.x86_64 libdb-5.2.36-1.fc16.x86_64 >>> libselinux-2.1.6-6.fc16.x86_64 libxml2-2.7.8-6.fc16.x86_64 >>> nspr-4.8.9-2.fc16.x86_64 nss-3.13.1-11.fc16.x86_64 >>> nss-softokn-freebl-3.13.1-15.fc16.x86_64 nss-util-3.13.1-3.fc16.x86_64 >>> openldap-2.4.26-6.fc16.x86_64 openssl-1.0.0g-1.fc16.x86_64 >>> sssd-client-1.7.0-5.fc16.x86_64 zlib-1.2.5-6.fc16.x86_64 >>> (gdb) >>> (gdb) >>> (gdb) >>> (gdb) >>> (gdb) bt >>> #0 0x00007f80d502cd82 in ldap_cache_enabled (cache=0xdededededededede) >> at >>> cache.c:216 >>> #1 0x00007f80d502cdd9 in ldap_cache_getrdatalist (mctx=0x7f80dc968250, >>> cache=0xdededededededede, name=0x7f80d6a82260, >>> rdatalist=0x7f80d6a82240) at cache.c:177 >>> #2 0x00007f80d503617a in ldapdb_rdatalist_get (mctx=0x7f80dc968250, >>> ldap_inst=0x7f80da7b2f10, name=0x7f80d6a82260, origin=0x7f80d0207c58, >>> rdatalist=0x7f80d6a82240) at ldap_helper.c:1466 >>> #3 0x00007f80d502fc7e in find (db=0x7f80d0207c40, name=0x7f80d0738020, >>> version=, type=28, options=, >>> now=, nodep=0x7f80d6a82880, foundname=0x7f80d0737ee0, >>> rdataset=0x7f80d073b050, sigrdataset=0x0) at ldap_driver.c:498 >>> #4 0x00007f80da82c01f in query_find (client=0x7f80d06943a0, event=0x0, >>> qtype=28) at query.c:5474 >>> #5 0x00007f80da833011 in ns_query_start (client=0x7f80d06943a0) at >>> query.c:7214 >>> #6 0x00007f80da81a6de in client_request (task=, >>> event=) at client.c:1913 >>> #7 0x00007f80d8ae3e98 in dispatch (manager=0x7f80da78f010) at >> task.c:1012 >>> #8 run (uap=0x7f80da78f010) at task.c:1157 >>> #9 0x00007f80d8499d90 in ?? () >>> #10 0x0000000000000000 in ?? () >>> >>> >>>> If you need help generating the backtrace from the core dump I can >> catch >>>> with you tomorrow on the #freeipa channel. >>>> >>> Thanks >>> Marco >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> -- >> Adam Tkac, Red Hat, Inc. >> From mkosek at redhat.com Tue Mar 6 17:40:15 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Mar 2012 18:40:15 +0100 Subject: [Freeipa-devel] [PATCH] 231 Ignore case in yes/no prompts Message-ID: <1331055615.20710.0.camel@balmora.brq.redhat.com> We did not accept answers like "Yes", "YES", "No", etc. as valid answers to yes/no prompts (used for example in dnsrecord-del interactive mode). This could confuse users. This patch changes the behavior to ignore the answer case. https://fedorahosted.org/freeipa/ticket/2484 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-231-ignore-case-in-yes-no-prompts.patch Type: text/x-patch Size: 1050 bytes Desc: not available URL: From ohamada at redhat.com Tue Mar 6 18:07:03 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Tue, 06 Mar 2012 19:07:03 +0100 Subject: [Freeipa-devel] [PATCH] 15 Confusing default user groups Message-ID: <4F565247.2050105@redhat.com> https://fedorahosted.org/freeipa/ticket/2354 There was added '(fallback)' string in the automember plugin labels referring to automember default groups to point out, that the users are already members of default group specified in IPA config, thus the default group specified in automember will be additional one - a fallback group. -- Regards, Ondrej Hamada FreeIPA team jabber:ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-15-Confusing-default-user-groups.patch Type: text/x-patch Size: 6742 bytes Desc: not available URL: From ohamada at redhat.com Tue Mar 6 18:30:16 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Tue, 06 Mar 2012 19:30:16 +0100 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <4F563F8F.5080504@redhat.com> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> <1331049562.26197.82.camel@willson.li.ssimo.org> <4F563F8F.5080504@redhat.com> Message-ID: <4F5657B8.6080409@redhat.com> On 03/06/2012 05:47 PM, Dmitri Pal wrote: > On 03/06/2012 10:59 AM, Simo Sorce wrote: >> On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: >>> [...] >>>> For a read-only KDC we need to investigate what's the better >>> solution. >>>> There are many ways we can handle the issue, one of the simplest is >>>> probably to allow the RO KDC to use a special LDAP Extended >>> operation >>>> against a full R/W server to get the user keys to sign, >>> authenticating >>>> with a special R/O KDC principal. We can also investigate how MS >>> does >>>> internal forwarding and do something similar as I suspect that's >>>> something samba4-RODC will want to implement too, so we could share >>> some >>>> of the development burden there. >>>> >>>> Simo. >>>> >>> I do not think it is a good idea for the remote RO KDC to go back to >>> the main datacenter on every authentication without some sort of >>> caching. This is why I think that some kind of SSSD integration might >>> be due. If RO KDC would just pass the authentication to SSSD in some >>> way and SSSD would do the caching in case the office gets offline. I >>> understand that authhub as is will not work as the client sends time >>> stamp encrypted with password and SSSD needs plain text password as >>> credential. I do not know if there is a way to solve this without >>> actually sending the password in the tunnel. IMO it is more important >>> to make sure that remote office can have uninterrupted operation than >>> to worry about the password being sent inside the encrypted tunnel. It >>> is something that deployment should decide and weight risks against >>> convenience. >> This is why MS does partial replication, ie allows the RODC to have data >> about the office users. It's complex and there are many ways to handle >> it. We need to look at various options and see how they would work >> against uses cases we want to support. >> Simo. >> > Then may be Ondrej should start with formulating use cases and > requirements based on this discussion. > I see three possible use cases here, but only two should be considered when speaking about consumer node: 1) The office that should rely on that replica is quite a big one (hundreds of employees) or many different users are authenticating against its replica or there are located admins, who need to do a lot of write-operations. --> In this case I suppose the best solution is to deploy master replica there. 2) Office that doesn't fulfil the conditions in 1) - not a desperate need for write-operations on ipa-server, but the priority is to allow (some) clients to authenticate and use available services even when the network is down. --> We need a consumer with credentials caching, authentication requests for non-cached users or write operations must be forwarded to master. 3) Office that doesn't fulfil the conditions in 1), but the priority is security, so that the consumer is not allowed to store or cache any confidential data. --> We need a consumer, authentications and write operations must be forwarded to master. If we choose the second use case, both the caching and request forwarding must be implemented. I suppose that there shouldn't be big problem to decide during the installation to turn the caching off by some option like '-no-chaching' so that the consumer could be used for the third use case as well. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada From rcritten at redhat.com Tue Mar 6 20:56:57 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Mar 2012 15:56:57 -0500 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F1DDA53.6090206@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> <4F1DDA53.6090206@redhat.com> Message-ID: <4F567A19.8070408@redhat.com> Rob Crittenden wrote: > Jan Cholasta wrote: >> Dne 18.1.2012 00:04, Rob Crittenden napsal(a): >>> Jan Cholasta wrote: >>>> Dne 16.1.2012 22:02, Rob Crittenden napsal(a): >>>>> Rob Crittenden wrote: >>>>>> Jan Cholasta wrote: >>>>>>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>>>>>>> When viewing a certificate it will show the serial number as hex >>>>>>>> (dec). >>>>>>>> >>>>>>>> # ipa service-show HTTP/rawhide.example.com >>>>>>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>>>>>>> Certificate: [snip] >>>>>>>> Keytab: True >>>>>>>> Managed by: rawhide.example.com >>>>>>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>>>>>>> Serial Number: 0x403 (1027) >>>>>>>> Issuer: CN=EXAMPLE.COM Certificate Authority >>>>>>>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>>>>>>> Not After: Thu Jan 13 15:00:44 2022 UTC >>>>>>>> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>>>>>>> Fingerprint (SHA1): >>>>>>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> NACK >>>>>>> >>>>>>> Displaying a host or a service in the webUI fails with "IPA error >>>>>>> 3009: >>>>>>> invalid 'serial_number': Decimal or hexadecimal number is required >>>>>>> for >>>>>>> serial number". >>>>>>> >>>>>>> I would suggest to do the nifty formatting of serial numbers on the >>>>>>> client side, that would fix the webUI issue, allow non-IPA >>>>>>> clients to >>>>>>> parse the number without dissecting the string representation of it >>>>>>> and >>>>>>> probably also save me a hack in the type conversion overhaul. You >>>>>>> could >>>>>>> for example add a parameter flag like "format_serial_number" to >>>>>>> indicate >>>>>>> to the client that it should format the value as a serial number. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> Well, we want to do as little client formatting as possible. The >>>>>> idea is >>>>>> to have a very thin client. >>>> >>>> It doesn't seem right to me to enforce this specific representation of >>>> what is really just an integer at the API level. Doing a little >>>> formatting on the client side won't make the client(s) particularly >>>> fat, >>>> will it? >>> >>> Yes. The current code just outputs labels and data. There is no "if it >>> is this attribute then do that" logic. >>> >>>> >>>> IMHO there is too much stuff done on server that would make more sense >>>> to do on client anyway (especially CLI-specific stuff such as CSV >>>> parsing). What is the reason we want such a thin client? >>> >>> To avoid double work such that every time we want a formatting change we >>> have to change it in multiple places. This lesson was learned in v1. >>> >>>> I believe there should be clear separation of presentation and content, >>>> but perhaps I'm a little bit too idealistic :-). >>> >>> You have a point, serial number is defined as an integer. Perhaps we >>> should revisit this decision to display hex at all. >>> >>> >>>> >>>>>> >>>>>> I'll look into fixing the UI side. >>>>> >>>>> I don't see this error in services, it displays correctly. I'm not >>>>> sure >>>>> if it is my browser or what but hosts don't display much of anything >>>>> for >>>>> me. >>>>> >>>>> rob >>>> >>>> I have just checked both master and ipa-2-2 and I'm getting the same >>>> error message (tested in Firefox 9.0.1) when viewing details of a host >>>> or a service with the usercertificate attribute set. >>>> >>>> BTW, wouldn't it make sense to format serial numbers in the cert plugin >>>> in the same way? >>> >>> Perhaps. Like I said, I'm not really in favor of this change. >>> >>> rob >> >> Maybe we can do a compromise of some sort. What about allowing the >> client to specify with each request what representation/formatting the >> server should use for the resulting entries and attributes? > > That would be mighty flexible but would open a new can of worms. I think > long term I'd like to be able to request what attributes to see (ala > ldapsearch) but that too is a bit out of scope. > > This comes down to Output being rather loosely defined and we already > have a ticket open on that. It basically just defines the broad types of > data to be returned (string, list, dict, etc) but not the internal > components of complex types. Took a new approach and created a new output attribute, serial_number_hex, that is displayed separately. UI portion added as well. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-924-2-serial.patch Type: text/x-diff Size: 8969 bytes Desc: not available URL: From rcritten at redhat.com Tue Mar 6 21:18:55 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Mar 2012 16:18:55 -0500 Subject: [Freeipa-devel] [PATCH] 974 minimum selinux-policy for F-17 In-Reply-To: <4F4D9DD1.1090401@redhat.com> References: <4F4D9DD1.1090401@redhat.com> Message-ID: <4F567F3F.9050004@redhat.com> Rob Crittenden wrote: > Update the minimum selinux-policy for F-17. This will enable > ipa_memcached to run in Enforcing mode. Still waiting on this to be > backported to at least F-16. > > You have to manually enable the boolean. > > rob > F-16 package is in updates-testing, patch updated. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-974-2-selinux.patch Type: text/x-diff Size: 1110 bytes Desc: not available URL: From pviktori at redhat.com Wed Mar 7 09:40:10 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 07 Mar 2012 10:40:10 +0100 Subject: [Freeipa-devel] [PATCH] 231 Ignore case in yes/no prompts In-Reply-To: <1331055615.20710.0.camel@balmora.brq.redhat.com> References: <1331055615.20710.0.camel@balmora.brq.redhat.com> Message-ID: <4F572CFA.7010409@redhat.com> On 03/06/2012 06:40 PM, Martin Kosek wrote: > We did not accept answers like "Yes", "YES", "No", etc. as valid > answers to yes/no prompts (used for example in dnsrecord-del > interactive mode). This could confuse users. This patch changes > the behavior to ignore the answer case. > > https://fedorahosted.org/freeipa/ticket/2484 > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK, works as advertised. -- Petr? From pviktori at redhat.com Wed Mar 7 09:45:18 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 07 Mar 2012 10:45:18 +0100 Subject: [Freeipa-devel] [PATCH] 231 Ignore case in yes/no prompts In-Reply-To: <4F572CFA.7010409@redhat.com> References: <1331055615.20710.0.camel@balmora.brq.redhat.com> <4F572CFA.7010409@redhat.com> Message-ID: <4F572E2E.4000409@redhat.com> On 03/07/2012 10:40 AM, Petr Viktorin wrote: > On 03/06/2012 06:40 PM, Martin Kosek wrote: >> We did not accept answers like "Yes", "YES", "No", etc. as valid >> answers to yes/no prompts (used for example in dnsrecord-del >> interactive mode). This could confuse users. This patch changes >> the behavior to ignore the answer case. >> >> https://fedorahosted.org/freeipa/ticket/2484 >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK, works as advertised. > I hit Send too fast. This triggers a lint warning; ACK if you disable it. -- Petr? From pviktori at redhat.com Wed Mar 7 12:52:17 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 07 Mar 2012 13:52:17 +0100 Subject: [Freeipa-devel] [PATCH] 0021 Add CLI tests Message-ID: <4F575A01.1060501@redhat.com> Most of the tests we have check if the server does the right thing with XML-RPC calls. How the commandline is converted to command arguments, including interactive prompting, is untested. This patch adds some tests in this area. To do that I had to break up cli.run into more manageable pieces, and initialize the CLI plugins in test mode. Also I added nose's --nocapture option to the make-test script. With this it's possible to use pdb.set_trace() to drop into a debugger while running the tests. I went ahead and added a test for ticket 2484, fixed in Martin's patch 231 (Ignore case in yes/no prompts). -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0021-Add-CLI-parsing-tests.patch Type: text/x-patch Size: 10318 bytes Desc: not available URL: From rcritten at redhat.com Wed Mar 7 14:32:21 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Mar 2012 09:32:21 -0500 Subject: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa Message-ID: <4F577175.4070407@redhat.com> Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in enforcing mode. This is being done in the HTTP instance so we can set both booleans in one step and save a bit of time (it is still slow). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-981-selinux.patch Type: text/x-diff Size: 4197 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 7 15:06:21 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Mar 2012 16:06:21 +0100 Subject: [Freeipa-devel] [PATCH] 227-228 Add last missing bits in new bind-dyndb-ldap In-Reply-To: <1330604359.4451.18.camel@balmora.brq.redhat.com> References: <1330604359.4451.18.camel@balmora.brq.redhat.com> Message-ID: <1331132781.22847.4.camel@balmora.brq.redhat.com> On Thu, 2012-03-01 at 13:19 +0100, Martin Kosek wrote: > These 2 patches changes the DNS API to support the last missing bits in > new bind-dyndb-ldap: > > 1) Both global and per-zone forwarders now support a conditional custom > port (with format "IP_ADDRESS PORT") > 2) Missing global configuration options have been added: > * idnsforwardpolicy: Default policy for conditional forwarding > * idnsallowsyncptr: Allow globaly PTR synchronization for dynamic > updates > * idnszonerefresh: Default interval between regular polls of the > name server for new DNS zones > > Before these patches are pushed, I will just have to update the minimal > bind-dyndb-ldap version (it has not been built yet) which have a full > support for these. > > Martin New version of bind-dyndb-ldap has been released, attaching a rebased patch with fixed bind-dyndb-ldap version in spec file. I also fixed the forwarder format, it should be "$IP port $PORT", not "$IP $PORT" as it was in a previous version of the patch. I tested this new format with bind-dyndb-ldap it forwards the queries properly. Unfortunately, fixed version of bind have not been released yet, i.e. bind will crash if forwarders are defined both in named.conf and LDAP global configuration (dnsconfig-mod). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-227-2-allow-port-numbers-for-idnsforwarders.patch Type: text/x-patch Size: 3540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-228-2-add-missing-global-options-in-dnsconfig.patch Type: text/x-patch Size: 4258 bytes Desc: not available URL: From pvoborni at redhat.com Wed Mar 7 15:57:19 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Mar 2012 16:57:19 +0100 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F567A19.8070408@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> <4F1DDA53.6090206@redhat.com> <4F567A19.8070408@redhat.com> Message-ID: <4F57855F.10208@redhat.com> On 03/06/2012 09:56 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Dne 18.1.2012 00:04, Rob Crittenden napsal(a): >>>> Jan Cholasta wrote: >>>>> Dne 16.1.2012 22:02, Rob Crittenden napsal(a): >>>>>> Rob Crittenden wrote: >>>>>>> Jan Cholasta wrote: >>>>>>>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>>>>>>>> When viewing a certificate it will show the serial number as hex >>>>>>>>> (dec). >>>>>>>>> >>>>>>>>> # ipa service-show HTTP/rawhide.example.com >>>>>>>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>>>>>>>> Certificate: [snip] >>>>>>>>> Keytab: True >>>>>>>>> Managed by: rawhide.example.com >>>>>>>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>>>>>>>> Serial Number: 0x403 (1027) >>>>>>>>> Issuer: CN=EXAMPLE.COM Certificate Authority >>>>>>>>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>>>>>>>> Not After: Thu Jan 13 15:00:44 2022 UTC >>>>>>>>> Fingerprint (MD5): e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>>>>>>>> Fingerprint (SHA1): >>>>>>>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>> >>>>>>>> NACK >>>>>>>> >>>>>>>> Displaying a host or a service in the webUI fails with "IPA error >>>>>>>> 3009: >>>>>>>> invalid 'serial_number': Decimal or hexadecimal number is required >>>>>>>> for >>>>>>>> serial number". >>>>>>>> >>>>>>>> I would suggest to do the nifty formatting of serial numbers on the >>>>>>>> client side, that would fix the webUI issue, allow non-IPA >>>>>>>> clients to >>>>>>>> parse the number without dissecting the string representation of it >>>>>>>> and >>>>>>>> probably also save me a hack in the type conversion overhaul. You >>>>>>>> could >>>>>>>> for example add a parameter flag like "format_serial_number" to >>>>>>>> indicate >>>>>>>> to the client that it should format the value as a serial number. >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> Well, we want to do as little client formatting as possible. The >>>>>>> idea is >>>>>>> to have a very thin client. >>>>> >>>>> It doesn't seem right to me to enforce this specific representation of >>>>> what is really just an integer at the API level. Doing a little >>>>> formatting on the client side won't make the client(s) particularly >>>>> fat, >>>>> will it? >>>> >>>> Yes. The current code just outputs labels and data. There is no "if it >>>> is this attribute then do that" logic. >>>> >>>>> >>>>> IMHO there is too much stuff done on server that would make more sense >>>>> to do on client anyway (especially CLI-specific stuff such as CSV >>>>> parsing). What is the reason we want such a thin client? >>>> >>>> To avoid double work such that every time we want a formatting >>>> change we >>>> have to change it in multiple places. This lesson was learned in v1. >>>> >>>>> I believe there should be clear separation of presentation and >>>>> content, >>>>> but perhaps I'm a little bit too idealistic :-). >>>> >>>> You have a point, serial number is defined as an integer. Perhaps we >>>> should revisit this decision to display hex at all. >>>> >>>> >>>>> >>>>>>> >>>>>>> I'll look into fixing the UI side. >>>>>> >>>>>> I don't see this error in services, it displays correctly. I'm not >>>>>> sure >>>>>> if it is my browser or what but hosts don't display much of anything >>>>>> for >>>>>> me. >>>>>> >>>>>> rob >>>>> >>>>> I have just checked both master and ipa-2-2 and I'm getting the same >>>>> error message (tested in Firefox 9.0.1) when viewing details of a host >>>>> or a service with the usercertificate attribute set. >>>>> >>>>> BTW, wouldn't it make sense to format serial numbers in the cert >>>>> plugin >>>>> in the same way? >>>> >>>> Perhaps. Like I said, I'm not really in favor of this change. >>>> >>>> rob >>> >>> Maybe we can do a compromise of some sort. What about allowing the >>> client to specify with each request what representation/formatting the >>> server should use for the resulting entries and attributes? >> >> That would be mighty flexible but would open a new can of worms. I think >> long term I'd like to be able to request what attributes to see (ala >> ldapsearch) but that too is a bit out of scope. >> >> This comes down to Output being rather loosely defined and we already >> have a ticket open on that. It basically just defines the broad types of >> data to be returned (string, list, dict, etc) but not the internal >> components of complex types. > > Took a new approach and created a new output attribute, > serial_number_hex, that is displayed separately. > > UI portion added as well. > ACK for the UI part. I attached a patch which extends UI static testing data - to keep things in solid state. I think this approach is still evil (as the whole ticket) but I don't have a better solution (in CLI). Question: Isn't the '0x' part a bit redundant? The label already says '(hex)'. However I can buy a 'It is a convention.' argument. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0101-Certificate-serial-number-in-hex-format-ui-testing-d.patch Type: text/x-patch Size: 2038 bytes Desc: not available URL: From pvoborni at redhat.com Wed Mar 7 16:10:09 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Mar 2012 17:10:09 +0100 Subject: [Freeipa-devel] [PATCH] 102-103 UI part of 'Add last missing bits in new bind-dyndb-ldap' Message-ID: <4F578861.6090900@redhat.com> 1) Add support of new options in dnsconfig dnsconfig was extended of new attributes, so reflecting it in UI. New attributes: * idnsForwardPolicy * idnsAllowSyncPTR * idnsZoneRefresh https://fedorahosted.org/freeipa/ticket/2489 2) DNS forwarder's value can consist of IP address and a port. The syntax is ' port '. A new validator was created for this purpose. It is based on IP address validator. https://fedorahosted.org/freeipa/ticket/2490 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0102-Add-support-of-new-options-in-dnsconfig.patch Type: text/x-patch Size: 3367 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0103-DNS-forwarder-validator.patch Type: text/x-patch Size: 4474 bytes Desc: not available URL: From pvoborni at redhat.com Wed Mar 7 16:10:56 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Mar 2012 17:10:56 +0100 Subject: [Freeipa-devel] [PATCH] 104 Fixed mask validation in network_validator Message-ID: <4F578890.8070100@redhat.com> Network validator allowed invalid mask format: * leading zeros: 192.168.0.1/0024 * trailing chars: 192.168.0.1/24abcd It was fixed. https://fedorahosted.org/freeipa/ticket/2493 -- Petr Vobornik From rcritten at redhat.com Wed Mar 7 16:12:24 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Mar 2012 11:12:24 -0500 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F57855F.10208@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> <4F1DDA53.6090206@redhat.com> <4F567A19.8070408@redhat.com> <4F57855F.10208@redhat.com> Message-ID: <4F5788E8.4010102@redhat.com> Petr Vobornik wrote: > On 03/06/2012 09:56 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Dne 18.1.2012 00:04, Rob Crittenden napsal(a): >>>>> Jan Cholasta wrote: >>>>>> Dne 16.1.2012 22:02, Rob Crittenden napsal(a): >>>>>>> Rob Crittenden wrote: >>>>>>>> Jan Cholasta wrote: >>>>>>>>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>>>>>>>>> When viewing a certificate it will show the serial number as hex >>>>>>>>>> (dec). >>>>>>>>>> >>>>>>>>>> # ipa service-show HTTP/rawhide.example.com >>>>>>>>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>>>>>>>>> Certificate: [snip] >>>>>>>>>> Keytab: True >>>>>>>>>> Managed by: rawhide.example.com >>>>>>>>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>>>>>>>>> Serial Number: 0x403 (1027) >>>>>>>>>> Issuer: CN=EXAMPLE.COM Certificate Authority >>>>>>>>>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>>>>>>>>> Not After: Thu Jan 13 15:00:44 2022 UTC >>>>>>>>>> Fingerprint (MD5): >>>>>>>>>> e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>>>>>>>>> Fingerprint (SHA1): >>>>>>>>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>> >>>>>>>>> NACK >>>>>>>>> >>>>>>>>> Displaying a host or a service in the webUI fails with "IPA error >>>>>>>>> 3009: >>>>>>>>> invalid 'serial_number': Decimal or hexadecimal number is required >>>>>>>>> for >>>>>>>>> serial number". >>>>>>>>> >>>>>>>>> I would suggest to do the nifty formatting of serial numbers on >>>>>>>>> the >>>>>>>>> client side, that would fix the webUI issue, allow non-IPA >>>>>>>>> clients to >>>>>>>>> parse the number without dissecting the string representation >>>>>>>>> of it >>>>>>>>> and >>>>>>>>> probably also save me a hack in the type conversion overhaul. You >>>>>>>>> could >>>>>>>>> for example add a parameter flag like "format_serial_number" to >>>>>>>>> indicate >>>>>>>>> to the client that it should format the value as a serial number. >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> >>>>>>>> Well, we want to do as little client formatting as possible. The >>>>>>>> idea is >>>>>>>> to have a very thin client. >>>>>> >>>>>> It doesn't seem right to me to enforce this specific >>>>>> representation of >>>>>> what is really just an integer at the API level. Doing a little >>>>>> formatting on the client side won't make the client(s) particularly >>>>>> fat, >>>>>> will it? >>>>> >>>>> Yes. The current code just outputs labels and data. There is no "if it >>>>> is this attribute then do that" logic. >>>>> >>>>>> >>>>>> IMHO there is too much stuff done on server that would make more >>>>>> sense >>>>>> to do on client anyway (especially CLI-specific stuff such as CSV >>>>>> parsing). What is the reason we want such a thin client? >>>>> >>>>> To avoid double work such that every time we want a formatting >>>>> change we >>>>> have to change it in multiple places. This lesson was learned in v1. >>>>> >>>>>> I believe there should be clear separation of presentation and >>>>>> content, >>>>>> but perhaps I'm a little bit too idealistic :-). >>>>> >>>>> You have a point, serial number is defined as an integer. Perhaps we >>>>> should revisit this decision to display hex at all. >>>>> >>>>> >>>>>> >>>>>>>> >>>>>>>> I'll look into fixing the UI side. >>>>>>> >>>>>>> I don't see this error in services, it displays correctly. I'm not >>>>>>> sure >>>>>>> if it is my browser or what but hosts don't display much of anything >>>>>>> for >>>>>>> me. >>>>>>> >>>>>>> rob >>>>>> >>>>>> I have just checked both master and ipa-2-2 and I'm getting the same >>>>>> error message (tested in Firefox 9.0.1) when viewing details of a >>>>>> host >>>>>> or a service with the usercertificate attribute set. >>>>>> >>>>>> BTW, wouldn't it make sense to format serial numbers in the cert >>>>>> plugin >>>>>> in the same way? >>>>> >>>>> Perhaps. Like I said, I'm not really in favor of this change. >>>>> >>>>> rob >>>> >>>> Maybe we can do a compromise of some sort. What about allowing the >>>> client to specify with each request what representation/formatting the >>>> server should use for the resulting entries and attributes? >>> >>> That would be mighty flexible but would open a new can of worms. I think >>> long term I'd like to be able to request what attributes to see (ala >>> ldapsearch) but that too is a bit out of scope. >>> >>> This comes down to Output being rather loosely defined and we already >>> have a ticket open on that. It basically just defines the broad types of >>> data to be returned (string, list, dict, etc) but not the internal >>> components of complex types. >> >> Took a new approach and created a new output attribute, >> serial_number_hex, that is displayed separately. >> >> UI portion added as well. >> > > ACK for the UI part. I attached a patch which extends UI static testing > data - to keep things in solid state. > > I think this approach is still evil (as the whole ticket) but I don't > have a better solution (in CLI). We are in agreement. > Question: > Isn't the '0x' part a bit redundant? The label already says '(hex)'. > However I can buy a 'It is a convention.' argument. Yes, I did it for convention, plus to avoid confusion for the case where it looks like a decimal number but isn't, e.g. 10. If you saw: Serial number: 16 Serial number (hex): 10 It might be confusing. 0x10 would be clearer. rob From pvoborni at redhat.com Wed Mar 7 16:15:05 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Mar 2012 17:15:05 +0100 Subject: [Freeipa-devel] [PATCH] 104 Fixed mask validation in network_validator In-Reply-To: <4F578890.8070100@redhat.com> References: <4F578890.8070100@redhat.com> Message-ID: <4F578989.2050208@redhat.com> Attaching patch file. On 03/07/2012 05:10 PM, Petr Vobornik wrote: > Network validator allowed invalid mask format: > * leading zeros: 192.168.0.1/0024 > * trailing chars: 192.168.0.1/24abcd > > It was fixed. > > https://fedorahosted.org/freeipa/ticket/2493 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0104-Fixed-mask-validation-in-network_validator.patch Type: text/x-patch Size: 1934 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 7 17:43:04 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Mar 2012 18:43:04 +0100 Subject: [Freeipa-devel] [PATCH] 232 Treat UPGs correctly in winsync replication Message-ID: <1331142184.2294.1.camel@priserak> There are some test hints attached to the ticket. --- IPA winsync plugin failed to replicate users when default user group was non-posix even though User Private Groups (UPG) were enabled on the server. Both their uidNumber and gidNumber were empty and they missed essential object classes. When the default user group was made posix and UPG was disabled it did not set gidNumber to the default group gidNumber. This patch improves this behavior to set gidNumber correctly according to UPG configuration and the default group status (posix/non-posix). 4 situations can occur, the following list specifies what value is assigned to user gidNumber: 1) Default group posix, UPG enabled: gidNumber = UPG gidNumber 2) Default group posix, UPG disabled: gidNumber = default group gidNumber 3) Default group non-posix, UPG enabled: gidNumber = UPG gidNumber 4) Default group non-posix, UPG disabled: an error is printed to the dirsrv log as the gidNumber cannot be retrieved. User is replicated in the same way as before this patch, i.e. without essential object classes. https://fedorahosted.org/freeipa/ticket/2436 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-232-treat-upgs-correctly-in-winsync-replication.patch Type: text/x-patch Size: 7268 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 7 17:58:16 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Mar 2012 18:58:16 +0100 Subject: [Freeipa-devel] [PATCH] 231 Ignore case in yes/no prompts In-Reply-To: <4F572E2E.4000409@redhat.com> References: <1331055615.20710.0.camel@balmora.brq.redhat.com> <4F572CFA.7010409@redhat.com> <4F572E2E.4000409@redhat.com> Message-ID: <1331143096.2294.2.camel@priserak> On Wed, 2012-03-07 at 10:45 +0100, Petr Viktorin wrote: > On 03/07/2012 10:40 AM, Petr Viktorin wrote: > > On 03/06/2012 06:40 PM, Martin Kosek wrote: > >> We did not accept answers like "Yes", "YES", "No", etc. as valid > >> answers to yes/no prompts (used for example in dnsrecord-del > >> interactive mode). This could confuse users. This patch changes > >> the behavior to ignore the answer case. > >> > >> https://fedorahosted.org/freeipa/ticket/2484 > >> > >> > >> > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > ACK, works as advertised. > > > > I hit Send too fast. This triggers a lint warning; ACK if you disable it. > I disabled the lint warning and pushed to master, ipa-2-2. Martin From rcritten at redhat.com Wed Mar 7 21:50:45 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Mar 2012 16:50:45 -0500 Subject: [Freeipa-devel] [PATCH] 982 tweak to no_init patch Message-ID: <4F57D835.7020605@redhat.com> I discovered today that cert-request was failing with an untrusted CA error. The problem had to do with the NSS no_init patch. We were setting dbdir in the connection object too soon so it was comparing itself to itself and always determined that NSS was initialized just fine. This needs to be moved after the check. To test this you need a master, a replica and a client with DNS set up and SRV records for both servers. You need two or more servers so we run the ping() test. This is where the client was failing before. What would happen is this: - initialize NSS - run ping() against a server - prepare request - initialize NSS - FAIL That second initialization isn't needed and is correctly caught by the code with this patch. You need to test that a client enrollment works and that ipa cert-request works. cert-request was failing because we initialize NSS with nodb so we can load the CSR for validation. Because dbdir was set too early in the connection we were getting no_init set improperly and nss_shutdown() wasn't being called. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-982-noinit.patch Type: text/x-diff Size: 2975 bytes Desc: not available URL: From rcritten at redhat.com Wed Mar 7 22:49:16 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Mar 2012 17:49:16 -0500 Subject: [Freeipa-devel] [PATCH] 983 add subject key identifier Message-ID: <4F57E5EC.4030801@redhat.com> Add subject key identifier to the dogtag server cert profile. This will add it on upgrades too and any new certs issued will have a subject key identifier set. If the user has customized the profile themselves then this won't be applied. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-983-dogtag.patch Type: text/x-diff Size: 4732 bytes Desc: not available URL: From rcritten at redhat.com Wed Mar 7 23:02:31 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Mar 2012 18:02:31 -0500 Subject: [Freeipa-devel] [PATCH] 984 fix anonlimits dn Message-ID: <4F57E907.8060104@redhat.com> The value of nsslapd-anonlimitsdn wasn't being set properly because it wasn't quoted. This will fix it, replacing whatever is there with a correct value. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-984-anonlimits.patch Type: text/x-diff Size: 1881 bytes Desc: not available URL: From pvoborni at redhat.com Thu Mar 8 09:47:34 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 08 Mar 2012 10:47:34 +0100 Subject: [Freeipa-devel] [PATCH] 105 Fixed checkbox value in table without pkey Message-ID: <4F588036.1060808@redhat.com> When a table is displaying a record set without entity's pkey attribute. A checkbox value isn't properly prepared. This patch adds the preparation (converts value to string). https://fedorahosted.org/freeipa/ticket/2404 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0105-Fixed-checkbox-value-in-table-without-pkey.patch Type: text/x-patch Size: 1005 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 8 12:33:47 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Mar 2012 13:33:47 +0100 Subject: [Freeipa-devel] [PATCH] 233 Fix ipa-replica-manage TLS connection error Message-ID: <1331210027.11911.0.camel@balmora.brq.redhat.com> New version of openldap (openldap-2.4.26-6.fc16.x86_64) changed its ABI and broke our TLS connection in ipa-replica-manage. This makes it impossible to connect for example to Active Directory to set up a winsync replication. We always receive a connection error stating that Peer's certificate is not recognized even though we pass a correct certificate. This patch fixes the way we set up TLS. The change is backwards compatible with older versions of openldap. https://fedorahosted.org/freeipa/ticket/2500 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-233-fix-ipa-replica-manage-tls-connection-error.patch Type: text/x-patch Size: 2009 bytes Desc: not available URL: From ohamada at redhat.com Thu Mar 8 13:52:40 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Thu, 08 Mar 2012 14:52:40 +0100 Subject: [Freeipa-devel] [PATCH] 16 Netgroup nisdomain and hosts validation Message-ID: <4F58B9A8.2000508@redhat.com> Netgroup nisdomain and hosts validation nisdomain validation: Added pattern to the 'nisdomain' parameter to validate the specified nisdomain name. According to most common use cases the same patter as for netgroup should fit. Unit-tests added. https://fedorahosted.org/freeipa/ticket/2447 hosts validation: Added precallback to netgroup_add_member. It validates the specified hostnames and raises ValidationError exception for invalid hostnames. Unit-test added. https://fedorahosted.org/freeipa/ticket/2448 -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-16-Netgroup-nisdomain-and-hosts-validation.patch Type: text/x-patch Size: 10209 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 8 13:57:36 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Mar 2012 14:57:36 +0100 Subject: [Freeipa-devel] [PATCH] 234 Avoid deleting DNS zone when a context is reused Message-ID: <1331215056.11911.1.camel@balmora.brq.redhat.com> When dnsrecord-del pre_callback detects that the record does not contain any records, it set a flag to connection context and deletes the record object later. However, when more dnsrecord-del share the same context (and this is the case of "ipa-replica-manage del $MASTER" DNS cleanup), it may reuse a positive flag from previous dnsrecord-del command and delete the root DNS zone record and thus effectively delete the zone. This patch makes sure that this flag is always initialized to sane value in dnsrecord-del pre_callback to make sure that the DNS zone is not deleted. It also fixes pre_callback function definition to prevent adding attrs_list to "keys" parameter and thus confuse developers. https://fedorahosted.org/freeipa/ticket/2503 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-234-avoid-deleting-dns-zone-when-a-context-is-reused.patch Type: text/x-patch Size: 3196 bytes Desc: not available URL: From rmeggins at redhat.com Thu Mar 8 14:45:11 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 08 Mar 2012 07:45:11 -0700 Subject: [Freeipa-devel] [PATCH] 233 Fix ipa-replica-manage TLS connection error In-Reply-To: <1331210027.11911.0.camel@balmora.brq.redhat.com> References: <1331210027.11911.0.camel@balmora.brq.redhat.com> Message-ID: <4F58C5F7.2040907@redhat.com> On 03/08/2012 05:33 AM, Martin Kosek wrote: > New version of openldap (openldap-2.4.26-6.fc16.x86_64) changed its > ABI and broke our TLS connection in ipa-replica-manage. This makes > it impossible to connect for example to Active Directory to set up > a winsync replication. We always receive a connection error stating > that Peer's certificate is not recognized even though we pass > a correct certificate. > > This patch fixes the way we set up TLS. The change is backwards > compatible with older versions of openldap. > > https://fedorahosted.org/freeipa/ticket/2500 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 jcholast at redhat.com Thu Mar 8 15:42:42 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 08 Mar 2012 16:42:42 +0100 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F5788E8.4010102@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> <4F1DDA53.6090206@redhat.com> <4F567A19.8070408@redhat.com> <4F57855F.10208@redhat.com> <4F5788E8.4010102@redhat.com> Message-ID: <4F58D372.4090102@redhat.com> On 7.3.2012 17:12, Rob Crittenden wrote: > Petr Vobornik wrote: >> On 03/06/2012 09:56 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Dne 18.1.2012 00:04, Rob Crittenden napsal(a): >>>>>> Jan Cholasta wrote: >>>>>>> Dne 16.1.2012 22:02, Rob Crittenden napsal(a): >>>>>>>> Rob Crittenden wrote: >>>>>>>>> Jan Cholasta wrote: >>>>>>>>>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>>>>>>>>>> When viewing a certificate it will show the serial number as hex >>>>>>>>>>> (dec). >>>>>>>>>>> >>>>>>>>>>> # ipa service-show HTTP/rawhide.example.com >>>>>>>>>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>>>>>>>>>> Certificate: [snip] >>>>>>>>>>> Keytab: True >>>>>>>>>>> Managed by: rawhide.example.com >>>>>>>>>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>>>>>>>>>> Serial Number: 0x403 (1027) >>>>>>>>>>> Issuer: CN=EXAMPLE.COM Certificate Authority >>>>>>>>>>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>>>>>>>>>> Not After: Thu Jan 13 15:00:44 2022 UTC >>>>>>>>>>> Fingerprint (MD5): >>>>>>>>>>> e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>>>>>>>>>> Fingerprint (SHA1): >>>>>>>>>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> NACK >>>>>>>>>> >>>>>>>>>> Displaying a host or a service in the webUI fails with "IPA error >>>>>>>>>> 3009: >>>>>>>>>> invalid 'serial_number': Decimal or hexadecimal number is >>>>>>>>>> required >>>>>>>>>> for >>>>>>>>>> serial number". >>>>>>>>>> >>>>>>>>>> I would suggest to do the nifty formatting of serial numbers on >>>>>>>>>> the >>>>>>>>>> client side, that would fix the webUI issue, allow non-IPA >>>>>>>>>> clients to >>>>>>>>>> parse the number without dissecting the string representation >>>>>>>>>> of it >>>>>>>>>> and >>>>>>>>>> probably also save me a hack in the type conversion overhaul. You >>>>>>>>>> could >>>>>>>>>> for example add a parameter flag like "format_serial_number" to >>>>>>>>>> indicate >>>>>>>>>> to the client that it should format the value as a serial number. >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>>>>>>>> >>>>>>>>> Well, we want to do as little client formatting as possible. The >>>>>>>>> idea is >>>>>>>>> to have a very thin client. >>>>>>> >>>>>>> It doesn't seem right to me to enforce this specific >>>>>>> representation of >>>>>>> what is really just an integer at the API level. Doing a little >>>>>>> formatting on the client side won't make the client(s) particularly >>>>>>> fat, >>>>>>> will it? >>>>>> >>>>>> Yes. The current code just outputs labels and data. There is no >>>>>> "if it >>>>>> is this attribute then do that" logic. >>>>>> >>>>>>> >>>>>>> IMHO there is too much stuff done on server that would make more >>>>>>> sense >>>>>>> to do on client anyway (especially CLI-specific stuff such as CSV >>>>>>> parsing). What is the reason we want such a thin client? >>>>>> >>>>>> To avoid double work such that every time we want a formatting >>>>>> change we >>>>>> have to change it in multiple places. This lesson was learned in v1. >>>>>> >>>>>>> I believe there should be clear separation of presentation and >>>>>>> content, >>>>>>> but perhaps I'm a little bit too idealistic :-). >>>>>> >>>>>> You have a point, serial number is defined as an integer. Perhaps we >>>>>> should revisit this decision to display hex at all. >>>>>> >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> I'll look into fixing the UI side. >>>>>>>> >>>>>>>> I don't see this error in services, it displays correctly. I'm not >>>>>>>> sure >>>>>>>> if it is my browser or what but hosts don't display much of >>>>>>>> anything >>>>>>>> for >>>>>>>> me. >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> I have just checked both master and ipa-2-2 and I'm getting the same >>>>>>> error message (tested in Firefox 9.0.1) when viewing details of a >>>>>>> host >>>>>>> or a service with the usercertificate attribute set. >>>>>>> >>>>>>> BTW, wouldn't it make sense to format serial numbers in the cert >>>>>>> plugin >>>>>>> in the same way? >>>>>> >>>>>> Perhaps. Like I said, I'm not really in favor of this change. >>>>>> >>>>>> rob >>>>> >>>>> Maybe we can do a compromise of some sort. What about allowing the >>>>> client to specify with each request what representation/formatting the >>>>> server should use for the resulting entries and attributes? >>>> >>>> That would be mighty flexible but would open a new can of worms. I >>>> think >>>> long term I'd like to be able to request what attributes to see (ala >>>> ldapsearch) but that too is a bit out of scope. >>>> >>>> This comes down to Output being rather loosely defined and we already >>>> have a ticket open on that. It basically just defines the broad >>>> types of >>>> data to be returned (string, list, dict, etc) but not the internal >>>> components of complex types. >>> >>> Took a new approach and created a new output attribute, >>> serial_number_hex, that is displayed separately. >>> >>> UI portion added as well. >>> >> >> ACK for the UI part. I attached a patch which extends UI static testing >> data - to keep things in solid state. >> >> I think this approach is still evil (as the whole ticket) but I don't >> have a better solution (in CLI). > > We are in agreement. > >> Question: >> Isn't the '0x' part a bit redundant? The label already says '(hex)'. >> However I can buy a 'It is a convention.' argument. > > Yes, I did it for convention, plus to avoid confusion for the case where > it looks like a decimal number but isn't, e.g. 10. If you saw: > > Serial number: 16 > Serial number (hex): 10 > > It might be confusing. 0x10 would be clearer. > > rob This patch works for me, but let me repeat myself: > BTW, wouldn't it make sense to format serial numbers in the cert > plugin in the same way? Honza -- Jan Cholasta From dpal at redhat.com Thu Mar 8 15:54:08 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 08 Mar 2012 10:54:08 -0500 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <4F5657B8.6080409@redhat.com> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> <1331049562.26197.82.camel@willson.li.ssimo.org> <4F563F8F.5080504@redhat.com> <4F5657B8.6080409@redhat.com> Message-ID: <4F58D620.90107@redhat.com> On 03/06/2012 01:30 PM, Ondrej Hamada wrote: > On 03/06/2012 05:47 PM, Dmitri Pal wrote: >> On 03/06/2012 10:59 AM, Simo Sorce wrote: >>> On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: >>>> [...] >>>>> For a read-only KDC we need to investigate what's the better >>>> solution. >>>>> There are many ways we can handle the issue, one of the simplest is >>>>> probably to allow the RO KDC to use a special LDAP Extended >>>> operation >>>>> against a full R/W server to get the user keys to sign, >>>> authenticating >>>>> with a special R/O KDC principal. We can also investigate how MS >>>> does >>>>> internal forwarding and do something similar as I suspect that's >>>>> something samba4-RODC will want to implement too, so we could share >>>> some >>>>> of the development burden there. >>>>> >>>>> Simo. >>>>> >>>> I do not think it is a good idea for the remote RO KDC to go back to >>>> the main datacenter on every authentication without some sort of >>>> caching. This is why I think that some kind of SSSD integration might >>>> be due. If RO KDC would just pass the authentication to SSSD in some >>>> way and SSSD would do the caching in case the office gets offline. I >>>> understand that authhub as is will not work as the client sends time >>>> stamp encrypted with password and SSSD needs plain text password as >>>> credential. I do not know if there is a way to solve this without >>>> actually sending the password in the tunnel. IMO it is more important >>>> to make sure that remote office can have uninterrupted operation than >>>> to worry about the password being sent inside the encrypted tunnel. It >>>> is something that deployment should decide and weight risks against >>>> convenience. >>> This is why MS does partial replication, ie allows the RODC to have >>> data >>> about the office users. It's complex and there are many ways to handle >>> it. We need to look at various options and see how they would work >>> against uses cases we want to support. >>> Simo. >>> >> Then may be Ondrej should start with formulating use cases and >> requirements based on this discussion. >> > I see three possible use cases here, but only two should be considered > when speaking about consumer node: > > 1) The office that should rely on that replica is quite a big one > (hundreds of employees) or many different users are authenticating > against its replica or there are located admins, who need to do a lot > of write-operations. --> In this case I suppose the best solution is > to deploy master replica there. > > > 2) Office that doesn't fulfil the conditions in 1) - not a desperate > need for write-operations on ipa-server, but the priority is to allow > (some) clients to authenticate and use available services even when > the network is down. --> We need a consumer with credentials caching, > authentication requests for non-cached users or write operations must > be forwarded to master. > > 3) Office that doesn't fulfil the conditions in 1), but the priority > is security, so that the consumer is not allowed to store or cache any > confidential data. --> We need a consumer, authentications and write > operations must be forwarded to master. > > If we choose the second use case, both the caching and request > forwarding must be implemented. I suppose that there shouldn't be big > problem to decide during the installation to turn the caching off by > some option like '-no-chaching' so that the consumer could be used for > the third use case as well. > Can you please now create a set usage scenarios for the 2) and 3). User logs in and he is in cache, he is not in cache, he is redirected and data is cached, he failed and account lockout data is updated locally or on the other server? Admin tries to perform and IPA command or ldapmodify command - what happens? Can those work flows be spelled out in details for caching and non 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 pviktori at redhat.com Thu Mar 8 15:57:28 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 08 Mar 2012 16:57:28 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands Message-ID: <4F58D6E8.7040202@redhat.com> Since sudo commands are case-sensitive, we can't use the CN as the RDN. With this patch, the UUID is used instead. It seems like a too easy fix. What am I missing? As far as I understand, the fact that the DN has a different structure now shouldn't cause problems, even if there still are commands created by old IPA versions. For testing, use an unpatched version to create a few of these. The sudo commands are no longer sorted in sudocmd-find output. Doing that would require the ability to use an arbitrary attribute as sort key. Should I file an issue for that? Tests for the case sensitivity are included. https://fedorahosted.org/freeipa/ticket/2482 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0022-Use-ipauniqueid-as-the-primary-key-for-sudo-commands.patch Type: text/x-patch Size: 13807 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 8 16:22:09 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Mar 2012 17:22:09 +0100 Subject: [Freeipa-devel] [PATCH] 984 fix anonlimits dn In-Reply-To: <4F57E907.8060104@redhat.com> References: <4F57E907.8060104@redhat.com> Message-ID: <1331223729.11911.14.camel@balmora.brq.redhat.com> On Wed, 2012-03-07 at 18:02 -0500, Rob Crittenden wrote: > The value of nsslapd-anonlimitsdn wasn't being set properly because it > wasn't quoted. This will fix it, replacing whatever is there with a > correct value. > > rob The IPA anonlimits DN is now set correctly. However anonlimits in cn=anonymous-limits,cn=etc,SUFFIX are still empty (nsSizeLimit and nsLookThroughLimit values defined in 10-config.update are not set). Martin From josh at knoesis.org Fri Mar 9 00:29:10 2012 From: josh at knoesis.org (Joshua Dotson) Date: Thu, 8 Mar 2012 19:29:10 -0500 Subject: [Freeipa-devel] IPAv2 on SL6.2 using NIS fails with "Failed password" error Message-ID: Hi All, I'm having a problem with my IPA installs; I can't seem to get the NIS mode to work. I tried it with and without 'Migration Mode' enabled. I bind to it and 'getent passwd' and 'getent group' just fine, but when I type my password (post initial kinit password change) in for ssh, I get permission denied and the following in my client-side /var/log/secure log: Mar 8 18:15:07 bastion sshd[18480]: Failed password for bob from 192.168.5.68 port 50788 ssh2 Mar 8 18:15:22 bastion sshd[18480]: Failed password for bob from 192.168.5.68 port 50788 ssh2 Mar 8 18:46:13 bastion sshd[18556]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.6.68 user=bob Mar 8 18:46:16 bastion sshd[18556]: Failed password for bob from 192.168.5.68 port 50839 ssh2 On the server, I can find no error on the server side, matching the timestamp of when I attempt login from a third host to the bastion host (see below). Am I mistaken that IPAv2 provides backwards compatible NIS, without client-side SSSD, KRB5 and the like? Am I missing a service or something? Thanks very much! Please excuse the long email. Perhaps I'm too eager. lol :-) -Joshua. ========BACKGROUND INFO FOLLOWS========= Here are the details of my install, which is my fourth IPA install, so far. As a side note, however, I've not been able to get the NIS mode working, yet. - 2 nearly identical KVM's to test this. (1 for server and 1 for NIS client) - x86_64 - ext4 over LVM over qcow2 over NFSv3 - using virtio - Scientific Linux 6.2 minimal install from GUI of Install DVD - all available yum updates applied - iptables off - ipv4 only - added self FQDN to both /etc/hosts files - NetworkManager off in favor of network - static public IP's - Used the following commands to install my IPA server: # yum -y install \ ipa-server \ bind \ bind-dyndb-ldap # ipa-server-install \ -a 'admin_pass_example' \ --hostname=ipa.example.com \ -p 'dir_man_password_example' \ -n exampledom.com \ -r EXAMPLE.COM \ --setup-dns \ --forwarder=192.168.2.10 \ --forwarder=192.168.1.20 - After a reboot, logging in with Firefox works well... kinit works well after I create an initial user in the UI... Everything is cool..even enrolling other machine with the ipa-client-install tool works well.. No other changes were made inside the UI - Here are the commands I ran on the server outside the UI, per instructions (here: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/migrating-from-nis.html ) [root at ipa ~]# ipa-compat-manage enable Directory Manager password: Plugin already Enabled [root at ipa ~]# rpcinfo program version netid address service owner 100000 4 tcp6 ::.0.111 portmapper superuser 100000 3 tcp6 ::.0.111 portmapper superuser 100000 4 udp6 ::.0.111 portmapper superuser 100000 3 udp6 ::.0.111 portmapper superuser 100000 4 tcp 0.0.0.0.0.111 portmapper superuser 100000 3 tcp 0.0.0.0.0.111 portmapper superuser 100000 2 tcp 0.0.0.0.0.111 portmapper superuser 100000 4 udp 0.0.0.0.0.111 portmapper superuser 100000 3 udp 0.0.0.0.0.111 portmapper superuser 100000 2 udp 0.0.0.0.0.111 portmapper superuser 100000 4 local /var/run/rpcbind.sock portmapper superuser 100000 3 local /var/run/rpcbind.sock portmapper superuser [root at ipa ~]# ipa-nis-manage enable Directory Manager password: Enabling plugin Restarting IPA to initialize updates before performing deletes: [1/2]: stopping directory server [2/2]: starting directory server done configuring dirsrv. This setting will not take effect until you restart Directory Server. The rpcbind service may need to be started. [root at ipa ~]# reboot The system is going down for reboot NOW! sam at bastion:~$ ssh 192.168.5.25 Last login: Thu Mar 8 17:58:58 2012 from 192.168.5.99 [sam at ipa ~]$ su - Password: [root at ipa ~]# rpcinfo program version netid address service owner 100000 4 tcp6 ::.0.111 portmapper superuser 100000 3 tcp6 ::.0.111 portmapper superuser 100000 4 udp6 ::.0.111 portmapper superuser 100000 3 udp6 ::.0.111 portmapper superuser 100000 4 tcp 0.0.0.0.0.111 portmapper superuser 100000 3 tcp 0.0.0.0.0.111 portmapper superuser 100000 2 tcp 0.0.0.0.0.111 portmapper superuser 100000 4 udp 0.0.0.0.0.111 portmapper superuser 100000 3 udp 0.0.0.0.0.111 portmapper superuser 100000 2 udp 0.0.0.0.0.111 portmapper superuser 100000 4 local /var/run/rpcbind.sock portmapper superuser 100000 3 local /var/run/rpcbind.sock portmapper superuser 100004 2 udp6 ::.2.84 ypserv superuser 100004 2 udp 0.0.0.0.2.84 ypserv superuser 100004 2 tcp6 ::.2.84 ypserv superuser 100004 2 tcp 0.0.0.0.2.84 ypserv superuser [root at ipa ~]# - Here is chkconfig for the server (iptables/ip6tables are disabled by the service command when debugging) chkconfig --list|grep ':on' atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off certmonger 0:off 1:off 2:on 3:on 4:on 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off ip6tables 0:off 1:off 2:on 3:on 4:on 5:on 6:off ipa 0:off 1:off 2:on 3:on 4:on 5:on 6:off iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off lvm2-monitor 0:off 1:on 2:on 3:on 4:on 5:on 6:off messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off portreserve 0:off 1:off 2:on 3:on 4:on 5:on 6:off qpidd 0:off 1:off 2:on 3:on 4:on 5:on 6:off rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off sssd 0:off 1:off 2:off 3:on 4:on 5:on 6:off udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off - On the client, it's the same OS... SL6.2 x86_64, no firewall, minimal install, ipv4 only - I used authconfig to setup NIS, and am able to 'getent passwd' on the directory. # authconfig --enablenis --nisdomain=knoesis.org --nisserver=192.168.5.82 --enablemkhomedir --update - resolv.conf points to the IPA address for dns - client is same domain on the same 24-bit subnet - here are the packages I installed for NIS: Mar 08 16:05:19 Installed: libgssglue-0.1-11.el6.x86_64 Mar 08 16:05:19 Installed: libtirpc-0.2.1-5.el6.x86_64 Mar 08 16:05:19 Installed: rpcbind-0.2.0-8.el6.x86_64 Mar 08 16:05:56 Installed: 3:ypbind-1.20.4-29.el6.x86_64 Mar 08 16:05:56 Installed: yp-tools-2.9-12.el6.x86_64 - Here is chkconfig on the client: chkconfig --list|grep ':on' (iptables/ip6tables are disabled by the service command when debugging) auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off ip6tables 0:off 1:off 2:on 3:on 4:on 5:on 6:off iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off lvm2-monitor 0:off 1:on 2:on 3:on 4:on 5:on 6:off messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off qpidd 0:off 1:off 2:on 3:on 4:on 5:on 6:off rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off ypbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off - /etc/yp.conf (client) (I tried it with the server domain syntax, as well) ypserver 192.168.6.82 #domain example.com server 192.168.6.82 - rpcinfo (client) program version netid address service owner 100000 4 tcp6 ::.0.111 portmapper superuser 100000 3 tcp6 ::.0.111 portmapper superuser 100000 4 udp6 ::.0.111 portmapper superuser 100000 3 udp6 ::.0.111 portmapper superuser 100000 4 tcp 0.0.0.0.0.111 portmapper superuser 100000 3 tcp 0.0.0.0.0.111 portmapper superuser 100000 2 tcp 0.0.0.0.0.111 portmapper superuser 100000 4 udp 0.0.0.0.0.111 portmapper superuser 100000 3 udp 0.0.0.0.0.111 portmapper superuser 100000 2 udp 0.0.0.0.0.111 portmapper superuser 100000 4 local /var/run/rpcbind.sock portmapper superuser 100000 3 local /var/run/rpcbind.sock portmapper superuser 100007 2 udp 0.0.0.0.3.46 ypbind superuser 100007 1 udp 0.0.0.0.3.46 ypbind superuser 100007 2 tcp 0.0.0.0.3.49 ypbind superuser 100007 1 tcp 0.0.0.0.3.49 ypbind superuser -- Joshua M. Dotson Systems Administrator Kno.e.sis Center Wright State University - Dayton, OH josh at knoesis.org 937-350-1563 -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at knoesis.org Fri Mar 9 00:49:24 2012 From: josh at knoesis.org (Joshua Dotson) Date: Thu, 8 Mar 2012 19:49:24 -0500 Subject: [Freeipa-devel] IPAv2 on SL6.2 using NIS fails with "Failed password" error Message-ID: Well.... I think I can now answer my own question. The following is from: http://fedoraproject.org/wiki/QA:Testcase_freeipav2_nis Password Hashes You may notice that password hashes are not available, even when you attempt to retrieve entries as root. As this is the default behavior, a prospective client system would need to also be configured to use either Kerberos or LDAP to check user passwords. I'm sorry for the spam.. :-)... And also, my inconsistent hosts and IP's below are the result of a failed obfuscation, rather than actual inconsistencies in my config. Cheers and thanks for FreeIPA! -Joshua P.S. I guess I'll go some other route to authenticate these ancient Ubuntu 9.04 boxes to IPA. lol On Thu, Mar 8, 2012 at 7:29 PM, wrote: > Send Freeipa-devel mailing list submissions to > freeipa-devel at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-devel > or, via email, send a message with subject or body 'help' to > freeipa-devel-request at redhat.com > > You can reach the person managing the list at > freeipa-devel-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-devel digest..." > > > Today's Topics: > > 1. IPAv2 on SL6.2 using NIS fails with "Failed password" error > (Joshua Dotson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 8 Mar 2012 19:29:10 -0500 > From: Joshua Dotson > To: freeipa-devel at redhat.com > Subject: [Freeipa-devel] IPAv2 on SL6.2 using NIS fails with "Failed > password" error > Message-ID: > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi All, > > I'm having a problem with my IPA installs; I can't seem to get the NIS mode > to work. I tried it with and without 'Migration Mode' enabled. > > I bind to it and 'getent passwd' and 'getent group' just fine, but when I > type my password (post initial kinit password change) in for ssh, I get > permission denied and the following in my client-side /var/log/secure log: > > Mar 8 18:15:07 bastion sshd[18480]: Failed password for bob from > 192.168.5.68 port 50788 ssh2 > Mar 8 18:15:22 bastion sshd[18480]: Failed password for bob from > 192.168.5.68 port 50788 ssh2 > Mar 8 18:46:13 bastion sshd[18556]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.6.68 user=bob > Mar 8 18:46:16 bastion sshd[18556]: Failed password for bob from > 192.168.5.68 port 50839 ssh2 > > On the server, I can find no error on the server side, matching the > timestamp of when I attempt login from a third host to the bastion host > (see below). > > Am I mistaken that IPAv2 provides backwards compatible NIS, without > client-side SSSD, KRB5 and the like? Am I missing a service or something? > > Thanks very much! Please excuse the long email. Perhaps I'm too eager. > lol :-) > > -Joshua. > > ========BACKGROUND INFO FOLLOWS========= > > Here are the details of my install, which is my fourth IPA install, so far. > As a side note, however, I've not been able to get the NIS mode working, > yet. > > > - 2 nearly identical KVM's to test this. (1 for server and 1 for NIS > client) > - x86_64 > - ext4 over LVM over qcow2 over NFSv3 > - using virtio > - Scientific Linux 6.2 minimal install from GUI of Install DVD > - all available yum updates applied > - iptables off > - ipv4 only > - added self FQDN to both /etc/hosts files > - NetworkManager off in favor of network > - static public IP's > - Used the following commands to install my IPA server: > > # yum -y install \ > ipa-server \ > bind \ > bind-dyndb-ldap > > # ipa-server-install \ > -a 'admin_pass_example' \ > --hostname=ipa.example.com \ > -p 'dir_man_password_example' \ > -n exampledom.com \ > -r EXAMPLE.COM \ > --setup-dns \ > --forwarder=192.168.2.10 \ > --forwarder=192.168.1.20 > > > - After a reboot, logging in with Firefox works well... kinit works well > after I create an initial user in the UI... Everything is cool..even > enrolling other machine with the ipa-client-install tool works well.. No > other changes were made inside the UI > - Here are the commands I ran on the server outside the UI, per > instructions (here: > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/migrating-from-nis.html > ) > > > [root at ipa ~]# ipa-compat-manage enable > Directory Manager password: > > Plugin already Enabled > [root at ipa ~]# rpcinfo > program version netid address service owner > 100000 4 tcp6 ::.0.111 portmapper superuser > 100000 3 tcp6 ::.0.111 portmapper superuser > 100000 4 udp6 ::.0.111 portmapper superuser > 100000 3 udp6 ::.0.111 portmapper superuser > 100000 4 tcp 0.0.0.0.0.111 portmapper superuser > 100000 3 tcp 0.0.0.0.0.111 portmapper superuser > 100000 2 tcp 0.0.0.0.0.111 portmapper superuser > 100000 4 udp 0.0.0.0.0.111 portmapper superuser > 100000 3 udp 0.0.0.0.0.111 portmapper superuser > 100000 2 udp 0.0.0.0.0.111 portmapper superuser > 100000 4 local /var/run/rpcbind.sock portmapper superuser > 100000 3 local /var/run/rpcbind.sock portmapper superuser > [root at ipa ~]# ipa-nis-manage enable > Directory Manager password: > > Enabling plugin > Restarting IPA to initialize updates before performing deletes: > [1/2]: stopping directory server > [2/2]: starting directory server > done configuring dirsrv. > This setting will not take effect until you restart Directory Server. > The rpcbind service may need to be started. > [root at ipa ~]# reboot > > The system is going down for reboot NOW! > > > sam at bastion:~$ ssh 192.168.5.25 > Last login: Thu Mar 8 17:58:58 2012 from 192.168.5.99 > [sam at ipa ~]$ su - > Password: > [root at ipa ~]# rpcinfo > program version netid address service owner > 100000 4 tcp6 ::.0.111 portmapper superuser > 100000 3 tcp6 ::.0.111 portmapper superuser > 100000 4 udp6 ::.0.111 portmapper superuser > 100000 3 udp6 ::.0.111 portmapper superuser > 100000 4 tcp 0.0.0.0.0.111 portmapper superuser > 100000 3 tcp 0.0.0.0.0.111 portmapper superuser > 100000 2 tcp 0.0.0.0.0.111 portmapper superuser > 100000 4 udp 0.0.0.0.0.111 portmapper superuser > 100000 3 udp 0.0.0.0.0.111 portmapper superuser > 100000 2 udp 0.0.0.0.0.111 portmapper superuser > 100000 4 local /var/run/rpcbind.sock portmapper superuser > 100000 3 local /var/run/rpcbind.sock portmapper superuser > 100004 2 udp6 ::.2.84 ypserv superuser > 100004 2 udp 0.0.0.0.2.84 ypserv superuser > 100004 2 tcp6 ::.2.84 ypserv superuser > 100004 2 tcp 0.0.0.0.2.84 ypserv superuser > [root at ipa ~]# > > > - Here is chkconfig for the server (iptables/ip6tables are disabled by > the service command when debugging) > > chkconfig --list|grep ':on' > atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off > auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > certmonger 0:off 1:off 2:on 3:on 4:on 5:on 6:off > crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off > ip6tables 0:off 1:off 2:on 3:on 4:on 5:on 6:off > ipa 0:off 1:off 2:on 3:on 4:on 5:on 6:off > iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off > lvm2-monitor 0:off 1:on 2:on 3:on 4:on 5:on 6:off > messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off > network 0:off 1:off 2:on 3:on 4:on 5:on 6:off > ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > portreserve 0:off 1:off 2:on 3:on 4:on 5:on 6:off > qpidd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off > rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off > sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > sssd 0:off 1:off 2:off 3:on 4:on 5:on 6:off > udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off > > > > > - On the client, it's the same OS... SL6.2 x86_64, no firewall, minimal > install, ipv4 only > - I used authconfig to setup NIS, and am able to 'getent passwd' on the > directory. > > # authconfig --enablenis --nisdomain=knoesis.org --nisserver=192.168.5.82 > --enablemkhomedir --update > > - resolv.conf points to the IPA address for dns > - client is same domain on the same 24-bit subnet > - here are the packages I installed for NIS: > > Mar 08 16:05:19 Installed: libgssglue-0.1-11.el6.x86_64 > Mar 08 16:05:19 Installed: libtirpc-0.2.1-5.el6.x86_64 > Mar 08 16:05:19 Installed: rpcbind-0.2.0-8.el6.x86_64 > Mar 08 16:05:56 Installed: 3:ypbind-1.20.4-29.el6.x86_64 > Mar 08 16:05:56 Installed: yp-tools-2.9-12.el6.x86_64 > > > - Here is chkconfig on the client: > > chkconfig --list|grep ':on' (iptables/ip6tables are disabled by the > service command when debugging) > auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off > ip6tables 0:off 1:off 2:on 3:on 4:on 5:on 6:off > iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off > lvm2-monitor 0:off 1:on 2:on 3:on 4:on 5:on 6:off > messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off > network 0:off 1:off 2:on 3:on 4:on 5:on 6:off > qpidd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off > rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off > sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off > ypbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off > > > - /etc/yp.conf (client) (I tried it with the server domain syntax, as > well) > > ypserver 192.168.6.82 > #domain example.com server 192.168.6.82 > > > - rpcinfo (client) > > program version netid address service owner > 100000 4 tcp6 ::.0.111 portmapper superuser > 100000 3 tcp6 ::.0.111 portmapper superuser > 100000 4 udp6 ::.0.111 portmapper superuser > 100000 3 udp6 ::.0.111 portmapper superuser > 100000 4 tcp 0.0.0.0.0.111 portmapper superuser > 100000 3 tcp 0.0.0.0.0.111 portmapper superuser > 100000 2 tcp 0.0.0.0.0.111 portmapper superuser > 100000 4 udp 0.0.0.0.0.111 portmapper superuser > 100000 3 udp 0.0.0.0.0.111 portmapper superuser > 100000 2 udp 0.0.0.0.0.111 portmapper superuser > 100000 4 local /var/run/rpcbind.sock portmapper superuser > 100000 3 local /var/run/rpcbind.sock portmapper superuser > 100007 2 udp 0.0.0.0.3.46 ypbind superuser > 100007 1 udp 0.0.0.0.3.46 ypbind superuser > 100007 2 tcp 0.0.0.0.3.49 ypbind superuser > 100007 1 tcp 0.0.0.0.3.49 ypbind superuser > > -- > Joshua M. Dotson > Systems Administrator > Kno.e.sis Center > Wright State University - Dayton, OH > josh at knoesis.org > 937-350-1563 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://www.redhat.com/archives/freeipa-devel/attachments/20120308/f63089e2/attachment.html > > > > ------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > End of Freeipa-devel Digest, Vol 58, Issue 32 > ********************************************* > -- Joshua M. Dotson Systems Administrator Kno.e.sis Center Wright State University - Dayton, OH josh at knoesis.org 937-350-1563 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Fri Mar 9 04:29:23 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 08 Mar 2012 22:29:23 -0600 Subject: [Freeipa-devel] [PATCH] 102-103 UI part of 'Add last missing bits in new bind-dyndb-ldap' In-Reply-To: <4F578861.6090900@redhat.com> References: <4F578861.6090900@redhat.com> Message-ID: <4F598723.8060200@redhat.com> ACK. There are some minor issues. On 3/7/2012 10:10 AM, Petr Vobornik wrote: > 1) Add support of new options in dnsconfig > > dnsconfig was extended of new attributes, so reflecting it in UI. > > New attributes: > * idnsForwardPolicy > * idnsAllowSyncPTR > * idnsZoneRefresh > > https://fedorahosted.org/freeipa/ticket/2489 If you click the idnsallowsyncptr checkbox and click again to return to the original value, it will still show the undo button. > 2) DNS forwarder's value can consist of IP address and a port. > > The syntax is ' port '. A new validator was created > for this purpose. It is based on IP address validator. The validator is rather strict, it allows exactly a single space between the words. If someone mistakenly type an additional space, the validation error could be confusing because two adjacent spaces are sometimes not very obvious. I think either the UI or the server (or both) should normalize the space. Another option is to use separate fields for the IP address and the port in the multivalued field: Global forwarders: [192.168.1.1 ] port [80 ] Delete Add -- Endi S. Dewata From edewata at redhat.com Fri Mar 9 04:29:30 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 08 Mar 2012 22:29:30 -0600 Subject: [Freeipa-devel] [PATCH] 104 Fixed mask validation in network_validator In-Reply-To: <4F578989.2050208@redhat.com> References: <4F578890.8070100@redhat.com> <4F578989.2050208@redhat.com> Message-ID: <4F59872A.4040000@redhat.com> On 3/7/2012 10:15 AM, Petr Vobornik wrote: > Attaching patch file. > > On 03/07/2012 05:10 PM, Petr Vobornik wrote: >> Network validator allowed invalid mask format: >> * leading zeros: 192.168.0.1/0024 >> * trailing chars: 192.168.0.1/24abcd >> >> It was fixed. >> >> https://fedorahosted.org/freeipa/ticket/2493 ACK. -- Endi S. Dewata From edewata at redhat.com Fri Mar 9 04:29:36 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 08 Mar 2012 22:29:36 -0600 Subject: [Freeipa-devel] [PATCH] 105 Fixed checkbox value in table without pkey In-Reply-To: <4F588036.1060808@redhat.com> References: <4F588036.1060808@redhat.com> Message-ID: <4F598730.3030009@redhat.com> On 3/8/2012 3:47 AM, Petr Vobornik wrote: > When a table is displaying a record set without entity's pkey attribute. > A checkbox value isn't properly prepared. This patch adds the > preparation (converts value to string). > > https://fedorahosted.org/freeipa/ticket/2404 ACK. -- Endi S. Dewata From abokovoy at redhat.com Fri Mar 9 06:43:28 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 9 Mar 2012 08:43:28 +0200 Subject: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa In-Reply-To: <4F577175.4070407@redhat.com> References: <4F577175.4070407@redhat.com> Message-ID: <20120309064328.GH2724@redhat.com> On Wed, 07 Mar 2012, Rob Crittenden wrote: > Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in > enforcing mode. > > This is being done in the HTTP instance so we can set both booleans > in one step and save a bit of time (it is still slow). I would prefer all platform-specific manipulations of security policies to be moved to platform-specific module. Make a HTTP class there (like I did dirsrv class in systemd backend) and perform manipulations on service enable. This way main code will stay clear of platform-specific code. Sorry for not looking into the issue before. -- / Alexander Bokovoy From mkosek at redhat.com Fri Mar 9 09:46:08 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Mar 2012 10:46:08 +0100 Subject: [Freeipa-devel] [PATCH] 974 minimum selinux-policy for F-17 In-Reply-To: <4F567F3F.9050004@redhat.com> References: <4F4D9DD1.1090401@redhat.com> <4F567F3F.9050004@redhat.com> Message-ID: <1331286368.26839.1.camel@balmora.brq.redhat.com> On Tue, 2012-03-06 at 16:18 -0500, Rob Crittenden wrote: > Rob Crittenden wrote: > > Update the minimum selinux-policy for F-17. This will enable > > ipa_memcached to run in Enforcing mode. Still waiting on this to be > > backported to at least F-16. > > > > You have to manually enable the boolean. > > > > rob > > > > F-16 package is in updates-testing, patch updated. > > rob ACK. New selinux-policy looks OK. I was able to install IPA server with enforcing. Of course, httpd_manage_ipa need to be ON. Martin From mkosek at redhat.com Fri Mar 9 11:41:10 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Mar 2012 12:41:10 +0100 Subject: [Freeipa-devel] [PATCH] 235 Fix migration plugin compat check Message-ID: <1331293270.26839.2.camel@balmora.brq.redhat.com> Ticket #2274 implements a check for compat plugin and warns user if it is enabled. However, there are 2 issues connected with the plugin: 1) The check is performed against the remote (migrated) LDAP server and not the local LDAP server, which does not make much sense 2) When the compat plugin is missing in cn=plugins,cn=config, it raises an error and thus breaks the migration This patch fixes both issues. https://fedorahosted.org/freeipa/ticket/2508 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-235-fix-migration-plugin-compat-check.patch Type: text/x-patch Size: 1902 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 9 12:10:53 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 09 Mar 2012 13:10:53 +0100 Subject: [Freeipa-devel] [PATCH] 0023 Don't crash when searching with empty relationship options Message-ID: <4F59F34D.3080407@redhat.com> See commit message. https://fedorahosted.org/freeipa/ticket/2479 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0023-Don-t-crash-when-searching-with-empty-relationship-o.patch Type: text/x-patch Size: 8468 bytes Desc: not available URL: From pvoborni at redhat.com Fri Mar 9 13:16:09 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 09 Mar 2012 14:16:09 +0100 Subject: [Freeipa-devel] [PATCH] 107 Content is no more overwritten by error message Message-ID: <4F5A0299.2060006@redhat.com> When an error which caused calling of report_error occur, the content of a facet got replaced by error message. There was no way how to force the facet to recreate its content and the facet became unusable. This patch creates a container for an error message. On error, report_error writes its content to error container, content container is hidden and error container is shown. Older comment in a code suggested to move the error message to facet's footer. A message in a footer could be missed by the user and on top of that a footer is sometimes used by various facet and we would have to solve the same problem again. From experience the cause of an error is usually a missing pkey in a path. Therefore error information suggests user to navigate to top level. It causes to load default facets with default values so errors in navigation state shouldn't happen. Facet content is displayed back on facet_show. If user tries to display same object as before facet's need_update() would return false, therefore need_update was modified to always return true if error is displayed. Also it may be possible to display facet content on refresh success. I tried to avoid that because it would require putting show_content calls to various success handlers or load methods. It would add one more thing developer needs to think of when overriding refresh or load method. Reproduction: 1) display any nested entity - ie DNS record 2) delete its parent pkey from path - &dnszone-pkey=example.com 3) reload the page with this path https://fedorahosted.org/freeipa/ticket/2449 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0106-Content-is-no-more-overwritten-by-error-message.patch Type: text/x-patch Size: 8012 bytes Desc: not available URL: From ohamada at redhat.com Fri Mar 9 13:18:01 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Fri, 09 Mar 2012 14:18:01 +0100 Subject: [Freeipa-devel] [PATCH] 17 More exception handlers in ipa-client-install Message-ID: <4F5A0309.1080001@redhat.com> https://fedorahosted.org/freeipa/ticket/2415 https://fedorahosted.org/freeipa/ticket/1995 Added exception handler to certutil operation of adding CA to the default NSS database. If operation fails, installation is aborted and changes are rolled back. #2415 If obtaining host TGT fails, the installation is aborted and changes are rolled back. #1995 -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-17-More-exception-handlers-in-ipa-client-install.patch Type: text/x-patch Size: 2142 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 9 13:31:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Mar 2012 14:31:19 +0100 Subject: [Freeipa-devel] [PATCH] 983 add subject key identifier In-Reply-To: <4F57E5EC.4030801@redhat.com> References: <4F57E5EC.4030801@redhat.com> Message-ID: <1331299879.26839.7.camel@balmora.brq.redhat.com> On Wed, 2012-03-07 at 17:49 -0500, Rob Crittenden wrote: > Add subject key identifier to the dogtag server cert profile. > > This will add it on upgrades too and any new certs issued will have a > subject key identifier set. > > If the user has customized the profile themselves then this won't be > applied. > > rob NACK I found few issues with the patch: 1) There is an extraneous pdb statement: + import pdb; pdb.set_trace() 2) A name of config file should be put to some variable once and not created every time again in enable_subject_key_identifier. It would be much more readable and less error prone: + installutils.set_directive('/var/lib/% s/profiles/ca/caIPAserviceCert.cfg' % PKI_INSTANCE_NAME, 'policyset.serverCertSet.list', '1,2,3,4,5,6,7,8,10', quotes=False, separator='=') + installutils.set_directive('/var/lib/% s/profiles/ca/caIPAserviceCert.cfg' % PKI_INSTANCE_NAME, 'policyset.serverCertSet.10.constraint.class_id', 'noConstraintImpl', quotes=False, separator='=') ... 3) We do not handle gracefully missing config file. This is what happens when replica without CA is upgraded: # rpm -Uvh --force /home/mkosek/dist-review/rpms/freeipa-* Preparing... ########################################### [100%] 1:freeipa-python ########################################### [ 17%] 2:freeipa-client ########################################### [ 33%] 3:freeipa-admintools ########################################### [ 50%] 4:freeipa-server ########################################### [ 67%] Upgraded /etc/httpd/conf.d/ipa-pki-proxy.conf to version 1 Traceback (most recent call last): File "/usr/sbin/ipa-upgradeconfig", line 301, in sys.exit(main()) File "/usr/sbin/ipa-upgradeconfig", line 297, in main upgrade_ipa_profile(krbctx.default_realm) File "/usr/sbin/ipa-upgradeconfig", line 243, in upgrade_ipa_profile if ca.enable_subject_key_identifier(): File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1079, in enable_subject_key_identifier setlist = installutils.get_directive('/var/lib/%s/profiles/ca/caIPAserviceCert.cfg' % PKI_INSTANCE_NAME, 'policyset.serverCertSet.list', separator='=') File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 429, in get_directive fd = open(filename, "r") IOError: [Errno 2] No such file or directory: '/var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg' 5:freeipa-server-selinux ########################################### [ 83%] 6:freeipa-debuginfo ########################################### [100%] 1. Martin From mkosek at redhat.com Fri Mar 9 14:50:28 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Mar 2012 15:50:28 +0100 Subject: [Freeipa-devel] [PATCH] 17 More exception handlers in ipa-client-install In-Reply-To: <4F5A0309.1080001@redhat.com> References: <4F5A0309.1080001@redhat.com> Message-ID: <1331304628.26839.8.camel@balmora.brq.redhat.com> On Fri, 2012-03-09 at 14:18 +0100, Ondrej Hamada wrote: > https://fedorahosted.org/freeipa/ticket/2415 > https://fedorahosted.org/freeipa/ticket/1995 > > Added exception handler to certutil operation of adding CA to the > default NSS database. If operation fails, installation is aborted and > changes are rolled back. #2415 > > If obtaining host TGT fails, the installation is aborted and changes are > rolled back. #1995 ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Fri Mar 9 15:34:02 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Mar 2012 16:34:02 +0100 Subject: [Freeipa-devel] [PATCH] 16 Netgroup nisdomain and hosts validation In-Reply-To: <4F58B9A8.2000508@redhat.com> References: <4F58B9A8.2000508@redhat.com> Message-ID: <1331307242.26839.24.camel@balmora.brq.redhat.com> On Thu, 2012-03-08 at 14:52 +0100, Ondrej Hamada wrote: > Netgroup nisdomain and hosts validation > > nisdomain validation: > Added pattern to the 'nisdomain' parameter to validate the specified > nisdomain name. According to most common use cases the same patter as > for netgroup should fit. Unit-tests added. > > https://fedorahosted.org/freeipa/ticket/2447 > > hosts validation: > Added precallback to netgroup_add_member. It validates the specified > hostnames and raises ValidationError exception for invalid hostnames. > Unit-test added. > > https://fedorahosted.org/freeipa/ticket/2448 I checked the host validation part and it could be improved. Issue described in #2447 (you have switched the ticket IDs) affects all objects that allow external hosts, users, ..., i.e. those who call add_external_post_callback in their post_callback. Should we fix all of these when we deal with this issue? Otherwise user could do something like this: # ipa sudorule-add-user foo --users=a+b Rule name: foo Enabled: TRUE External User: a+b We could create a similar function called add_external_pre_callback() and pass it attribute name and validating function (which would be common with the linked object). It would then do the validation for all these affected objects consistently and without redundant code. I didn't liked much the implemented pre_callback anyway + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + # validate entered hostnames + if 'host' in options: + invalid_hostnames=[] + for hostname in options['host']: + try: + validate_hostname(hostname, False) + except ValueError: + invalid_hostnames.append(hostname) + if invalid_hostnames: + raise errors.ValidationError(name='host', error='hostnames:\"%s\" contain invalid characters' % ','.join(invalid_hostnames)) + return dn I would rather raise the ValidationError with the first invalid hostname and tell what's wrong (function validate_hostname tells it to you). If you go with the proposed approach, you wouldn't have to deal with formatting error messages, you would just raise the one returned by the validator shared with the linked LDAP object (hostname, user, ...). Martin From pviktori at redhat.com Fri Mar 9 16:31:39 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 09 Mar 2012 17:31:39 +0100 Subject: [Freeipa-devel] [PATCH] 0024 Fix expected exception checking in tests Message-ID: <4F5A306B.9090001@redhat.com> Can you spot the bug in this test code? try: do_invalid_operation() except ExpectedError: pass Our test suite had several of those. Nose provides nice tools, `raises` (a decorator) and `assert_raises` (a context manager) that make checking expected exceptions a lot easier and less error-prone. This patch makes our tests use them. If you didn't catch it, the error is that the test will pass when no exception is raised. Some of our tests handled that by adding an `else: assert False`, or an `assert False` at the end of the try block. For consistency, the patch switches these correct ones to raises/assert_raises as well. I've also uncovered and fixed a few test bugs that were hidden by this. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0024-Use-nose-tools-to-check-for-exceptions.patch Type: text/x-patch Size: 27068 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 9 17:03:36 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 09 Mar 2012 18:03:36 +0100 Subject: [Freeipa-devel] Git post-commit hook Message-ID: <4F5A37E8.2090706@redhat.com> Let me share my post-commit hook with you. Save this as .git/hooks/post-commit, chmod +x it, and each time you make a commit, it will run pylint and a PEP8 check on all .py files you've changed. It takes a long time, but it runs after the commit is made, so you can quite safely kill it or switch to a different terminal and continue working. It's also quite noisy -- IPA doesn't really conform to its style guide, mainly because there are lots of long lines. I always like to check around the changes I made for little style fixes to sneak into my patch. yum install python-pep8 for the style checks. Improvements welcome! -- Petr? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: post-commit URL: From pvoborni at redhat.com Fri Mar 9 17:20:19 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 09 Mar 2012 18:20:19 +0100 Subject: [Freeipa-devel] [PATCH] 107 Fixed evaluating checkbox dirty status Message-ID: <4F5A3BD3.7070703@redhat.com> Problem: When value in checkbox is modified twice in a row (so it is at its original value) an 'undo' button is still visible even when it shouldn't be. Cause: IPA server sends boolean values as 'TRUE' or 'FALSE' (strings). Checkbox_widget converts them to JavaScript? boolean (true, false). Save method in checkbox_widget is returning array with a boolean. So test_dirty method always evaluates to dirty because 'FALSE' != false. This patch is fixing the problem. Note (future enhancements): As we were talking before about making fields less dependent on widget types. The dependency comes from the fact that dirty evaluation is in field. I plan to move the core to widget. I'm thinking about something like: Widget would have: * input value parser - ie for parsing strings to booleans - configurable * original value (parsed) * inner state (inner_save()) * is_dirty() - compare inner state with original value * output formatter - can make boolean back to strings (just example) - configurable * save() would return array of formatted values Field: * load(record) would pick values from record as now * is_dirty - needed for facets. Would be: dirty = 'one of associated widgets is dirty' * save() - merge associated widgets values - usually only on array from one widget Maybe input and output formatters should be in field. https://fedorahosted.org/freeipa/ticket/2494 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0107-Fixed-evaluating-checkbox-dirty-status.patch Type: text/x-patch Size: 4145 bytes Desc: not available URL: From dpal at redhat.com Fri Mar 9 21:06:33 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 09 Mar 2012 16:06:33 -0500 Subject: [Freeipa-devel] IPAv2 on SL6.2 using NIS fails with "Failed password" error In-Reply-To: References: Message-ID: <4F5A70D9.7080007@redhat.com> On 03/08/2012 07:49 PM, Joshua Dotson wrote: > Well.... > > I think I can now answer my own question. > > The following is > from: http://fedoraproject.org/wiki/QA:Testcase_freeipav2_nis > > Password Hashes > You may notice that password hashes are not available, even when > you attempt to retrieve entries as root. As this is the default > behavior, a prospective client system would need to also be > configured to use either Kerberos or LDAP to check user passwords. > > I'm sorry for the spam.. :-)... And also, my inconsistent hosts and > IP's below are the result of a failed obfuscation, rather than actual > inconsistencies in my config. > > Cheers and thanks for FreeIPA! > Joshua is this just test of waters or you actually plan to use NIS on 6.2? It seams odd as 6.2 has much more superior solution (SSSD configured with ipa-client) then NIS. NIS support is mostly for legacy systems that can't do the LDAP. As far as I understand underlying DS can also be configured to create weak hashes needed for NIS but it is not recommended. But this is something that gurus should confirm. > -Joshua > > P.S. I guess I'll go some other route to authenticate these ancient > Ubuntu 9.04 boxes to IPA. lol > > > On Thu, Mar 8, 2012 at 7:29 PM, > wrote: > > Send Freeipa-devel mailing list submissions to > freeipa-devel at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-devel > or, via email, send a message with subject or body 'help' to > freeipa-devel-request at redhat.com > > > You can reach the person managing the list at > freeipa-devel-owner at redhat.com > > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-devel digest..." > > > Today's Topics: > > 1. IPAv2 on SL6.2 using NIS fails with "Failed password" error > (Joshua Dotson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 8 Mar 2012 19:29:10 -0500 > From: Joshua Dotson > > To: freeipa-devel at redhat.com > Subject: [Freeipa-devel] IPAv2 on SL6.2 using NIS fails with "Failed > password" error > Message-ID: > > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi All, > > I'm having a problem with my IPA installs; I can't seem to get the > NIS mode > to work. I tried it with and without 'Migration Mode' enabled. > > I bind to it and 'getent passwd' and 'getent group' just fine, but > when I > type my password (post initial kinit password change) in for ssh, > I get > permission denied and the following in my client-side > /var/log/secure log: > > Mar 8 18:15:07 bastion sshd[18480]: Failed password for bob from > 192.168.5.68 port 50788 ssh2 > Mar 8 18:15:22 bastion sshd[18480]: Failed password for bob from > 192.168.5.68 port 50788 ssh2 > Mar 8 18:46:13 bastion sshd[18556]: pam_unix(sshd:auth): > authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.6.68 > user=bob > Mar 8 18:46:16 bastion sshd[18556]: Failed password for bob from > 192.168.5.68 port 50839 ssh2 > > On the server, I can find no error on the server side, matching the > timestamp of when I attempt login from a third host to the bastion > host > (see below). > > Am I mistaken that IPAv2 provides backwards compatible NIS, without > client-side SSSD, KRB5 and the like? Am I missing a service or > something? > > Thanks very much! Please excuse the long email. Perhaps I'm too > eager. > lol :-) > > -Joshua. > > ========BACKGROUND INFO FOLLOWS========= > > Here are the details of my install, which is my fourth IPA > install, so far. > As a side note, however, I've not been able to get the NIS mode > working, > yet. > > > - 2 nearly identical KVM's to test this. (1 for server and 1 for NIS > client) > - x86_64 > - ext4 over LVM over qcow2 over NFSv3 > - using virtio > - Scientific Linux 6.2 minimal install from GUI of Install DVD > - all available yum updates applied > - iptables off > - ipv4 only > - added self FQDN to both /etc/hosts files > - NetworkManager off in favor of network > - static public IP's > - Used the following commands to install my IPA server: > > # yum -y install \ > ipa-server \ > bind \ > bind-dyndb-ldap > > # ipa-server-install \ > -a 'admin_pass_example' \ > --hostname=ipa.example.com \ > -p 'dir_man_password_example' \ > -n exampledom.com \ > -r EXAMPLE.COM \ > --setup-dns \ > --forwarder=192.168.2.10 \ > --forwarder=192.168.1.20 > > > - After a reboot, logging in with Firefox works well... kinit > works well > after I create an initial user in the UI... Everything is cool..even > enrolling other machine with the ipa-client-install tool works > well.. No > other changes were made inside the UI > - Here are the commands I ran on the server outside the UI, per > instructions (here: > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/migrating-from-nis.html > ) > > > [root at ipa ~]# ipa-compat-manage enable > Directory Manager password: > > Plugin already Enabled > [root at ipa ~]# rpcinfo > program version netid address service owner > 100000 4 tcp6 ::.0.111 portmapper > superuser > 100000 3 tcp6 ::.0.111 portmapper > superuser > 100000 4 udp6 ::.0.111 portmapper > superuser > 100000 3 udp6 ::.0.111 portmapper > superuser > 100000 4 tcp 0.0.0.0.0.111 portmapper > superuser > 100000 3 tcp 0.0.0.0.0.111 portmapper > superuser > 100000 2 tcp 0.0.0.0.0.111 portmapper > superuser > 100000 4 udp 0.0.0.0.0.111 portmapper > superuser > 100000 3 udp 0.0.0.0.0.111 portmapper > superuser > 100000 2 udp 0.0.0.0.0.111 portmapper > superuser > 100000 4 local /var/run/rpcbind.sock portmapper > superuser > 100000 3 local /var/run/rpcbind.sock portmapper > superuser > [root at ipa ~]# ipa-nis-manage enable > Directory Manager password: > > Enabling plugin > Restarting IPA to initialize updates before performing deletes: > [1/2]: stopping directory server > [2/2]: starting directory server > done configuring dirsrv. > This setting will not take effect until you restart Directory Server. > The rpcbind service may need to be started. > [root at ipa ~]# reboot > > The system is going down for reboot NOW! > > > sam at bastion:~$ ssh 192.168.5.25 > Last login: Thu Mar 8 17:58:58 2012 from 192.168.5.99 > [sam at ipa ~]$ su - > Password: > [root at ipa ~]# rpcinfo > program version netid address service owner > 100000 4 tcp6 ::.0.111 portmapper > superuser > 100000 3 tcp6 ::.0.111 portmapper > superuser > 100000 4 udp6 ::.0.111 portmapper > superuser > 100000 3 udp6 ::.0.111 portmapper > superuser > 100000 4 tcp 0.0.0.0.0.111 portmapper > superuser > 100000 3 tcp 0.0.0.0.0.111 portmapper > superuser > 100000 2 tcp 0.0.0.0.0.111 portmapper > superuser > 100000 4 udp 0.0.0.0.0.111 portmapper > superuser > 100000 3 udp 0.0.0.0.0.111 portmapper > superuser > 100000 2 udp 0.0.0.0.0.111 portmapper > superuser > 100000 4 local /var/run/rpcbind.sock portmapper > superuser > 100000 3 local /var/run/rpcbind.sock portmapper > superuser > 100004 2 udp6 ::.2.84 ypserv > superuser > 100004 2 udp 0.0.0.0.2.84 ypserv > superuser > 100004 2 tcp6 ::.2.84 ypserv > superuser > 100004 2 tcp 0.0.0.0.2.84 ypserv > superuser > [root at ipa ~]# > > > - Here is chkconfig for the server (iptables/ip6tables are > disabled by > the service command when debugging) > > chkconfig --list|grep ':on' > atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off > auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > certmonger 0:off 1:off 2:on 3:on 4:on 5:on 6:off > crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off > ip6tables 0:off 1:off 2:on 3:on 4:on 5:on 6:off > ipa 0:off 1:off 2:on 3:on 4:on 5:on 6:off > iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off > lvm2-monitor 0:off 1:on 2:on 3:on 4:on 5:on 6:off > messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off > network 0:off 1:off 2:on 3:on 4:on 5:on 6:off > ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > portreserve 0:off 1:off 2:on 3:on 4:on 5:on 6:off > qpidd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off > rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off > sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > sssd 0:off 1:off 2:off 3:on 4:on 5:on 6:off > udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off > > > > > - On the client, it's the same OS... SL6.2 x86_64, no firewall, > minimal > install, ipv4 only > - I used authconfig to setup NIS, and am able to 'getent passwd' > on the > directory. > > # authconfig --enablenis --nisdomain=knoesis.org > --nisserver=192.168.5.82 > --enablemkhomedir --update > > - resolv.conf points to the IPA address for dns > - client is same domain on the same 24-bit subnet > - here are the packages I installed for NIS: > > Mar 08 16:05:19 Installed: libgssglue-0.1-11.el6.x86_64 > Mar 08 16:05:19 Installed: libtirpc-0.2.1-5.el6.x86_64 > Mar 08 16:05:19 Installed: rpcbind-0.2.0-8.el6.x86_64 > Mar 08 16:05:56 Installed: 3:ypbind-1.20.4-29.el6.x86_64 > Mar 08 16:05:56 Installed: yp-tools-2.9-12.el6.x86_64 > > > - Here is chkconfig on the client: > > chkconfig --list|grep ':on' (iptables/ip6tables are disabled by the > service command when debugging) > auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off > ip6tables 0:off 1:off 2:on 3:on 4:on 5:on 6:off > iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off > lvm2-monitor 0:off 1:on 2:on 3:on 4:on 5:on 6:off > messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off > network 0:off 1:off 2:on 3:on 4:on 5:on 6:off > qpidd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off > rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off > sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off > ypbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off > > > - /etc/yp.conf (client) (I tried it with the server domain > syntax, as > well) > > ypserver 192.168.6.82 > #domain example.com server 192.168.6.82 > > > - rpcinfo (client) > > program version netid address service owner > 100000 4 tcp6 ::.0.111 portmapper > superuser > 100000 3 tcp6 ::.0.111 portmapper > superuser > 100000 4 udp6 ::.0.111 portmapper > superuser > 100000 3 udp6 ::.0.111 portmapper > superuser > 100000 4 tcp 0.0.0.0.0.111 portmapper > superuser > 100000 3 tcp 0.0.0.0.0.111 portmapper > superuser > 100000 2 tcp 0.0.0.0.0.111 portmapper > superuser > 100000 4 udp 0.0.0.0.0.111 portmapper > superuser > 100000 3 udp 0.0.0.0.0.111 portmapper > superuser > 100000 2 udp 0.0.0.0.0.111 portmapper > superuser > 100000 4 local /var/run/rpcbind.sock portmapper > superuser > 100000 3 local /var/run/rpcbind.sock portmapper > superuser > 100007 2 udp 0.0.0.0.3.46 ypbind > superuser > 100007 1 udp 0.0.0.0.3.46 ypbind > superuser > 100007 2 tcp 0.0.0.0.3.49 ypbind > superuser > 100007 1 tcp 0.0.0.0.3.49 ypbind > superuser > > -- > Joshua M. Dotson > Systems Administrator > Kno.e.sis Center > Wright State University - Dayton, OH > josh at knoesis.org > 937-350-1563 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > End of Freeipa-devel Digest, Vol 58, Issue 32 > ********************************************* > > > > > -- > Joshua M. Dotson > Systems Administrator > Kno.e.sis Center > Wright State University - Dayton, OH > josh at knoesis.org > 937-350-1563 > > > _______________________________________________ > 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 pspacek at redhat.com Mon Mar 12 12:15:15 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 12 Mar 2012 13:15:15 +0100 Subject: [Freeipa-devel] [PATCH] 0011 Fix ticket #55: BIND cannot be shutdown correctly Message-ID: <4F5DE8D3.6040001@redhat.com> Hello, this patch fixes annoying bug from ticket #55: BIND cannot be shutdown correctly, if psearch is enabled and LDAP connect fails Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/55 It's trivial three line patch, so Adam ACKed it on IRC. Patch is already in master: https://fedorahosted.org/bind-dyndb-ldap/changeset/55d2886bb016adf3081a25eea616ce40f17d03e4 I think it's annoying and fix is trivial, so I opened BZ ticket for RHEL6.3: https://bugzilla.redhat.com/show_bug.cgi?id=802375 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0011-Fix-ticket-55-BIND-cannot-be-shutdown-correctly-if-p.patch Type: text/x-patch Size: 854 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 12 12:18:46 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Mar 2012 13:18:46 +0100 Subject: [Freeipa-devel] [PATCHES] 0025-26 Test improvements Message-ID: <4F5DE9A6.90704@redhat.com> Patch 25 fixes errors I found by running pylint on the testsuite. They were in code that was unused, either by error or because it only runs on errors. Patch 26 adds a test for the batch plugin. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0025-Fix-little-test-errors.patch Type: text/x-patch Size: 3825 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0026-Test-the-batch-plugin.patch Type: text/x-patch Size: 10181 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 12 12:26:57 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Mar 2012 13:26:57 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands In-Reply-To: <4F58D6E8.7040202@redhat.com> References: <4F58D6E8.7040202@redhat.com> Message-ID: <1331555217.1491.31.camel@balmora.brq.redhat.com> On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: > Since sudo commands are case-sensitive, we can't use the CN as the RDN. > With this patch, the UUID is used instead. > It seems like a too easy fix. What am I missing? > > As far as I understand, the fact that the DN has a different structure > now shouldn't cause problems, even if there still are commands created > by old IPA versions. > For testing, use an unpatched version to create a few of these. > > The sudo commands are no longer sorted in sudocmd-find output. Doing > that would require the ability to use an arbitrary attribute as sort > key. Should I file an issue for that? I don't think that's necessary. We sort by LDAP object's primary key and since new SUDO commands still have sudocmd as its primary key, the sorting should just work (at least it does for me). > > Tests for the case sensitivity are included. > > https://fedorahosted.org/freeipa/ticket/2482 This works pretty fine. Both my old client tests and sudoers compat tree tests looks good. So, cautious ACK from me. Martin From dpal at redhat.com Mon Mar 12 12:46:31 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 Mar 2012 08:46:31 -0400 Subject: [Freeipa-devel] [PATCH] 0011 Fix ticket #55: BIND cannot be shutdown correctly In-Reply-To: <4F5DE8D3.6040001@redhat.com> References: <4F5DE8D3.6040001@redhat.com> Message-ID: <4F5DF027.9070606@redhat.com> On 03/12/2012 08:15 AM, Petr Spacek wrote: > Hello, > > this patch fixes annoying bug from ticket #55: BIND cannot be shutdown > correctly, if psearch is enabled and LDAP connect fails > > Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/55 > > It's trivial three line patch, so Adam ACKed it on IRC. > > Patch is already in master: > https://fedorahosted.org/bind-dyndb-ldap/changeset/55d2886bb016adf3081a25eea616ce40f17d03e4 > > I think it's annoying and fix is trivial, so I opened BZ ticket for > RHEL6.3: https://bugzilla.redhat.com/show_bug.cgi?id=802375 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel It seems that code has tabs which violates our coding standards. At least the indentation looks wrong. -- 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 mkosek at redhat.com Mon Mar 12 13:05:55 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Mar 2012 14:05:55 +0100 Subject: [Freeipa-devel] [PATCH] 0020 Allow removing sudo commands with special characters from command groups In-Reply-To: <4F56094F.8000206@redhat.com> References: <4F54D75F.3010503@redhat.com> <4F56094F.8000206@redhat.com> Message-ID: <1331557555.1491.48.camel@balmora.brq.redhat.com> On Tue, 2012-03-06 at 13:55 +0100, Petr Viktorin wrote: > On 03/05/2012 04:10 PM, Petr Viktorin wrote: > > This patch fixes DN handling when removing LDAP entries from groups. > > > > Because they deal with commas and backslashes in a CSV param, the tests > > here rely on my patch 0015. > > > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Here is the same patch with CSV-stuff-dependent tests removed. > Thanks, this patch looks and works fine, so ACK. Before we push it, can you please update the tests in this patch or even better send an updated version of your patch 22 where RDN is changed to ipaUniqueID? Otherwise, if we push both these patches, we would get test failures with DN mismatches. Martin From mkosek at redhat.com Mon Mar 12 13:14:21 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Mar 2012 14:14:21 +0100 Subject: [Freeipa-devel] [PATCH] 0011 Fix ticket #55: BIND cannot be shutdown correctly In-Reply-To: <4F5DF027.9070606@redhat.com> References: <4F5DE8D3.6040001@redhat.com> <4F5DF027.9070606@redhat.com> Message-ID: <1331558061.1491.52.camel@balmora.brq.redhat.com> On Mon, 2012-03-12 at 08:46 -0400, Dmitri Pal wrote: > On 03/12/2012 08:15 AM, Petr Spacek wrote: > > Hello, > > > > this patch fixes annoying bug from ticket #55: BIND cannot be > > shutdown correctly, if psearch is enabled and LDAP connect fails > > > > Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/55 > > > > It's trivial three line patch, so Adam ACKed it on IRC. > > > > Patch is already in master: > > https://fedorahosted.org/bind-dyndb-ldap/changeset/55d2886bb016adf3081a25eea616ce40f17d03e4 > > > > I think it's annoying and fix is trivial, so I opened BZ ticket for > > RHEL6.3: https://bugzilla.redhat.com/show_bug.cgi?id=802375 > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > It seems that code has tabs which violates our coding standards. At > least the indentation looks wrong. > The whole bind-dyndb-ldap plugin use tabs for indentation, I would keep that unless we want to create mixed tab-space environment. I just see that Petr indented the statement with 2 tabs instead of one. Martin From pvoborni at redhat.com Mon Mar 12 13:22:27 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 12 Mar 2012 14:22:27 +0100 Subject: [Freeipa-devel] [PATCH] 108 Better hbactest validation message Message-ID: <4F5DF893.4000408@redhat.com> HBAC Test validation message now contains all missing values in form of list of links instead of general 'missing values' message and redirection to first missing value's facet. When a link is clicked user is redirected to value's facet. https://fedorahosted.org/freeipa/ticket/2182 Note: In a list I chose to display an option label instead of facet label. IMHO it seems better with message 'Missing values'. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0108-Better-hbactest-validation-message.patch Type: text/x-patch Size: 7424 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 12 13:38:20 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Mar 2012 14:38:20 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased) In-Reply-To: <1331555217.1491.31.camel@balmora.brq.redhat.com> References: <4F58D6E8.7040202@redhat.com> <1331555217.1491.31.camel@balmora.brq.redhat.com> Message-ID: <4F5DFC4C.1080906@redhat.com> On 03/12/2012 01:26 PM, Martin Kosek wrote: > On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: >> Since sudo commands are case-sensitive, we can't use the CN as the RDN. >> With this patch, the UUID is used instead. >> It seems like a too easy fix. What am I missing? >> >> As far as I understand, the fact that the DN has a different structure >> now shouldn't cause problems, even if there still are commands created >> by old IPA versions. >> For testing, use an unpatched version to create a few of these. >> >> The sudo commands are no longer sorted in sudocmd-find output. Doing >> that would require the ability to use an arbitrary attribute as sort >> key. Should I file an issue for that? > > I don't think that's necessary. We sort by LDAP object's primary key and > since new SUDO commands still have sudocmd as its primary key, the > sorting should just work (at least it does for me). Right, sorry for the noise. >> >> Tests for the case sensitivity are included. >> >> https://fedorahosted.org/freeipa/ticket/2482 > > This works pretty fine. Both my old client tests and sudoers compat tree > tests looks good. So, cautious ACK from me. > > Martin > The attached version is rebased against my patch 20. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0022-02-Use-ipauniqueid-for-the-RDN-of-sudo-commands.patch Type: text/x-patch Size: 14311 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 12 15:01:06 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Mar 2012 16:01:06 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased) In-Reply-To: <4F5DFC4C.1080906@redhat.com> References: <4F58D6E8.7040202@redhat.com> <1331555217.1491.31.camel@balmora.brq.redhat.com> <4F5DFC4C.1080906@redhat.com> Message-ID: <1331564466.1491.57.camel@balmora.brq.redhat.com> On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: > On 03/12/2012 01:26 PM, Martin Kosek wrote: > > On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: > >> Since sudo commands are case-sensitive, we can't use the CN as the RDN. > >> With this patch, the UUID is used instead. > >> It seems like a too easy fix. What am I missing? > >> > >> As far as I understand, the fact that the DN has a different structure > >> now shouldn't cause problems, even if there still are commands created > >> by old IPA versions. > >> For testing, use an unpatched version to create a few of these. > >> > >> The sudo commands are no longer sorted in sudocmd-find output. Doing > >> that would require the ability to use an arbitrary attribute as sort > >> key. Should I file an issue for that? > > > > I don't think that's necessary. We sort by LDAP object's primary key and > > since new SUDO commands still have sudocmd as its primary key, the > > sorting should just work (at least it does for me). > > Right, sorry for the noise. > > >> > >> Tests for the case sensitivity are included. > >> > >> https://fedorahosted.org/freeipa/ticket/2482 > > > > This works pretty fine. Both my old client tests and sudoers compat tree > > tests looks good. So, cautious ACK from me. > > > > Martin > > > > The attached version is rebased against my patch 20. > Ah, I found an issue with the changed RDN attribute. We crash when I delete sudocmd that sudorule has enrolled as a member: # ipa sudocmd-add bar1 # ipa sudocmd-add bar2 # ipa sudorule-add foo # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 # ipa sudocmd-del bar2 # ipa sudorule-find ipa: ERROR: an internal error has occurred /var/log/httpd/error_log: [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): [Mon Mar 12 10:41:24 2012] [error] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 315, in wsgi_execute [Mon Mar 12 10:41:24 2012] [error] result = self.Command[name](*args, **options) [Mon Mar 12 10:41:24 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in __call__ [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) [Mon Mar 12 10:41:24 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, **options) [Mon Mar 12 10:41:24 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line 1866, in execute [Mon Mar 12 10:41:24 2012] [error] self.obj.convert_attribute_members(e[1], *args, **options) [Mon Mar 12 10:41:24 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line 518, in convert_attribute_members [Mon Mar 12 10:41:24 2012] [error] ldap_obj.get_primary_key_from_dn(member) [Mon Mar 12 10:41:24 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line 490, in get_primary_key_from_dn [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] [Mon Mar 12 10:41:24 2012] [error] File "/usr/lib/python2.7/site-packages/ipalib/dn.py", line 1137, in __getitem__ [Mon Mar 12 10:41:24 2012] [error] raise KeyError("\\"%s\\" not found in %s" % (key, self. __str__())) The problem is in this function: def get_primary_key_from_dn(self, dn): try: if self.rdn_attribute: (dn, entry_attrs) = self.backend.get_entry( dn, [self.primary_key.name] ) try: return entry_attrs[self.primary_key.name][0] except (KeyError, IndexError): return '' except errors.NotFound: pass # DN object assures we're returning a decoded (unescaped) value dn = DN(dn) return dn[self.primary_key.name] Martin From mkosek at redhat.com Mon Mar 12 15:06:32 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Mar 2012 16:06:32 +0100 Subject: [Freeipa-devel] [PATCH] 0020 Allow removing sudo commands with special characters from command groups In-Reply-To: <1331557555.1491.48.camel@balmora.brq.redhat.com> References: <4F54D75F.3010503@redhat.com> <4F56094F.8000206@redhat.com> <1331557555.1491.48.camel@balmora.brq.redhat.com> Message-ID: <1331564792.1491.58.camel@balmora.brq.redhat.com> On Mon, 2012-03-12 at 14:05 +0100, Martin Kosek wrote: > On Tue, 2012-03-06 at 13:55 +0100, Petr Viktorin wrote: > > On 03/05/2012 04:10 PM, Petr Viktorin wrote: > > > This patch fixes DN handling when removing LDAP entries from groups. > > > > > > Because they deal with commas and backslashes in a CSV param, the tests > > > here rely on my patch 0015. > > > > > > > > > > > > _______________________________________________ > > > Freeipa-devel mailing list > > > Freeipa-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > Here is the same patch with CSV-stuff-dependent tests removed. > > > > Thanks, this patch looks and works fine, so ACK. > > Before we push it, can you please update the tests in this patch or even > better send an updated version of your patch 22 where RDN is changed to > ipaUniqueID? Otherwise, if we push both these patches, we would get test > failures with DN mismatches. > > Martin > Pushed to master, ipa-2-2. Updated test are being dealt with in a scope of patch 0022. Martin From rcritten at redhat.com Mon Mar 12 15:08:30 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 11:08:30 -0400 Subject: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa In-Reply-To: <20120309064328.GH2724@redhat.com> References: <4F577175.4070407@redhat.com> <20120309064328.GH2724@redhat.com> Message-ID: <4F5E116E.3010901@redhat.com> Alexander Bokovoy wrote: > On Wed, 07 Mar 2012, Rob Crittenden wrote: > >> Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in >> enforcing mode. >> >> This is being done in the HTTP instance so we can set both booleans >> in one step and save a bit of time (it is still slow). > I would prefer all platform-specific manipulations of security > policies to be moved to platform-specific module. > > Make a HTTP class there (like I did dirsrv class in systemd > backend) and perform manipulations on service enable. > > This way main code will stay clear of platform-specific code. > > Sorry for not looking into the issue before. > I'd prefer to keep the change simple for now and do the big move post 2.2. rob From abokovoy at redhat.com Mon Mar 12 15:13:04 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Mar 2012 17:13:04 +0200 Subject: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa In-Reply-To: <4F5E116E.3010901@redhat.com> References: <4F577175.4070407@redhat.com> <20120309064328.GH2724@redhat.com> <4F5E116E.3010901@redhat.com> Message-ID: <20120312151304.GD4744@redhat.com> On Mon, 12 Mar 2012, Rob Crittenden wrote: > Alexander Bokovoy wrote: > >On Wed, 07 Mar 2012, Rob Crittenden wrote: > > > >>Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in > >>enforcing mode. > >> > >>This is being done in the HTTP instance so we can set both booleans > >>in one step and save a bit of time (it is still slow). > >I would prefer all platform-specific manipulations of security > >policies to be moved to platform-specific module. > > > >Make a HTTP class there (like I did dirsrv class in systemd > >backend) and perform manipulations on service enable. > > > >This way main code will stay clear of platform-specific code. > > > >Sorry for not looking into the issue before. > > > > I'd prefer to keep the change simple for now and do the big move post 2.2. ACK on condition you'd file a ticket for the post 2.2 work. :) -- / Alexander Bokovoy From rcritten at redhat.com Mon Mar 12 15:17:55 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 11:17:55 -0400 Subject: [Freeipa-devel] [PATCH] 17 More exception handlers in ipa-client-install In-Reply-To: <1331304628.26839.8.camel@balmora.brq.redhat.com> References: <4F5A0309.1080001@redhat.com> <1331304628.26839.8.camel@balmora.brq.redhat.com> Message-ID: <4F5E13A3.7010608@redhat.com> Martin Kosek wrote: > On Fri, 2012-03-09 at 14:18 +0100, Ondrej Hamada wrote: >> https://fedorahosted.org/freeipa/ticket/2415 >> https://fedorahosted.org/freeipa/ticket/1995 >> >> Added exception handler to certutil operation of adding CA to the >> default NSS database. If operation fails, installation is aborted and >> changes are rolled back. #2415 >> >> If obtaining host TGT fails, the installation is aborted and changes are >> rolled back. #1995 > > ACK. Pushed to master, ipa-2-2. > > Martin I wonder if we need to add an escape for --force here. The kinit is just to do things like nsupdate and add the SSH host keys. One might deem those not critical. rob From mkosek at redhat.com Mon Mar 12 15:26:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Mar 2012 16:26:00 +0100 Subject: [Freeipa-devel] [PATCH] 17 More exception handlers in ipa-client-install In-Reply-To: <4F5E13A3.7010608@redhat.com> References: <4F5A0309.1080001@redhat.com> <1331304628.26839.8.camel@balmora.brq.redhat.com> <4F5E13A3.7010608@redhat.com> Message-ID: <1331565960.1491.60.camel@balmora.brq.redhat.com> On Mon, 2012-03-12 at 11:17 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2012-03-09 at 14:18 +0100, Ondrej Hamada wrote: > >> https://fedorahosted.org/freeipa/ticket/2415 > >> https://fedorahosted.org/freeipa/ticket/1995 > >> > >> Added exception handler to certutil operation of adding CA to the > >> default NSS database. If operation fails, installation is aborted and > >> changes are rolled back. #2415 > >> > >> If obtaining host TGT fails, the installation is aborted and changes are > >> rolled back. #1995 > > > > ACK. Pushed to master, ipa-2-2. > > > > Martin > > I wonder if we need to add an escape for --force here. The kinit is just > to do things like nsupdate and add the SSH host keys. One might deem > those not critical. > > rob This was a keytab kinit, as original ticket says a failure to get a correct keytab will make it impossible to login anyway as ldap binds from sssd will fail and auth verification will fail. This sounds pretty critical to me... Martin From mkosek at redhat.com Mon Mar 12 15:44:34 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Mar 2012 16:44:34 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased) In-Reply-To: <1331564466.1491.57.camel@balmora.brq.redhat.com> References: <4F58D6E8.7040202@redhat.com> <1331555217.1491.31.camel@balmora.brq.redhat.com> <4F5DFC4C.1080906@redhat.com> <1331564466.1491.57.camel@balmora.brq.redhat.com> Message-ID: <1331567074.1491.63.camel@balmora.brq.redhat.com> On Mon, 2012-03-12 at 16:01 +0100, Martin Kosek wrote: > On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: > > On 03/12/2012 01:26 PM, Martin Kosek wrote: > > > On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: > > >> Since sudo commands are case-sensitive, we can't use the CN as the RDN. > > >> With this patch, the UUID is used instead. > > >> It seems like a too easy fix. What am I missing? > > >> > > >> As far as I understand, the fact that the DN has a different structure > > >> now shouldn't cause problems, even if there still are commands created > > >> by old IPA versions. > > >> For testing, use an unpatched version to create a few of these. > > >> > > >> The sudo commands are no longer sorted in sudocmd-find output. Doing > > >> that would require the ability to use an arbitrary attribute as sort > > >> key. Should I file an issue for that? > > > > > > I don't think that's necessary. We sort by LDAP object's primary key and > > > since new SUDO commands still have sudocmd as its primary key, the > > > sorting should just work (at least it does for me). > > > > Right, sorry for the noise. > > > > >> > > >> Tests for the case sensitivity are included. > > >> > > >> https://fedorahosted.org/freeipa/ticket/2482 > > > > > > This works pretty fine. Both my old client tests and sudoers compat tree > > > tests looks good. So, cautious ACK from me. > > > > > > Martin > > > > > > > The attached version is rebased against my patch 20. > > > > Ah, I found an issue with the changed RDN attribute. We crash when I > delete sudocmd that sudorule has enrolled as a member: > > # ipa sudocmd-add bar1 > # ipa sudocmd-add bar2 > # ipa sudorule-add foo > # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 > # ipa sudocmd-del bar2 > # ipa sudorule-find > ipa: ERROR: an internal error has occurred > > /var/log/httpd/error_log: > [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 315, > in wsgi_execute > [Mon Mar 12 10:41:24 2012] [error] result = > self.Command[name](*args, **options) > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in > __call__ > [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run > [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, > **options) > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > 1866, in execute > [Mon Mar 12 10:41:24 2012] [error] > self.obj.convert_attribute_members(e[1], *args, **options) > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > 518, in convert_attribute_members > [Mon Mar 12 10:41:24 2012] [error] > ldap_obj.get_primary_key_from_dn(member) > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > 490, in get_primary_key_from_dn > [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/dn.py", line 1137, in > __getitem__ > [Mon Mar 12 10:41:24 2012] [error] raise KeyError("\\"%s\\" not > found in %s" % (key, self. __str__())) > > > The problem is in this function: > def get_primary_key_from_dn(self, dn): > try: > if self.rdn_attribute: > (dn, entry_attrs) = self.backend.get_entry( > dn, [self.primary_key.name] > ) > try: > return entry_attrs[self.primary_key.name][0] > except (KeyError, IndexError): > return '' > except errors.NotFound: > pass > # DN object assures we're returning a decoded (unescaped) value > dn = DN(dn) > return dn[self.primary_key.name] > > Martin > I found one more issue, this one is more serious (I am glad my hunch was not malfunctioning). This patch breaks ACIs for sudocmd, user with appropriate privilege will no longer be able to add/modify/delete sudo commands: # kinit fbar Password for fbar at IDM.LAB.BOS.REDHAT.COM: # ipa sudorule-add fbar ---------------------- Added Sudo Rule "fbar" ---------------------- Rule name: fbar Enabled: TRUE # ipa sudorule-del fbar ------------------------ Deleted Sudo Rule "fbar" ------------------------ # ipa sudocmd-add fbar1 ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the entry 'ipaUniqueID=c68b98ae-6c58-11e1-be75-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. # ipa sudocmd-del sudocmd1 ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'ipaUniqueID=0c7659d4-6c50-11e1-9b18-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. # ipa sudocmd-mod sudocmd1 --desc=foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'description' attribute of entry 'ipauniqueid=0c7659d4-6c50-11e1-9b18-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' Martin From pviktori at redhat.com Mon Mar 12 16:12:37 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Mar 2012 17:12:37 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased) In-Reply-To: <1331564466.1491.57.camel@balmora.brq.redhat.com> References: <4F58D6E8.7040202@redhat.com> <1331555217.1491.31.camel@balmora.brq.redhat.com> <4F5DFC4C.1080906@redhat.com> <1331564466.1491.57.camel@balmora.brq.redhat.com> Message-ID: <4F5E2075.2090906@redhat.com> On 03/12/2012 04:01 PM, Martin Kosek wrote: > On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: >> On 03/12/2012 01:26 PM, Martin Kosek wrote: >>> On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: >>>> Since sudo commands are case-sensitive, we can't use the CN as the RDN. >>>> With this patch, the UUID is used instead. >>>> It seems like a too easy fix. What am I missing? >>>> >>>> As far as I understand, the fact that the DN has a different structure >>>> now shouldn't cause problems, even if there still are commands created >>>> by old IPA versions. >>>> For testing, use an unpatched version to create a few of these. >>>> >>>> The sudo commands are no longer sorted in sudocmd-find output. Doing >>>> that would require the ability to use an arbitrary attribute as sort >>>> key. Should I file an issue for that? >>> >>> I don't think that's necessary. We sort by LDAP object's primary key and >>> since new SUDO commands still have sudocmd as its primary key, the >>> sorting should just work (at least it does for me). >> >> Right, sorry for the noise. >> >>>> >>>> Tests for the case sensitivity are included. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2482 >>> >>> This works pretty fine. Both my old client tests and sudoers compat tree >>> tests looks good. So, cautious ACK from me. >>> >>> Martin >>> >> >> The attached version is rebased against my patch 20. >> > > Ah, I found an issue with the changed RDN attribute. We crash when I > delete sudocmd that sudorule has enrolled as a member: > > # ipa sudocmd-add bar1 > # ipa sudocmd-add bar2 > # ipa sudorule-add foo > # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 > # ipa sudocmd-del bar2 > # ipa sudorule-find > ipa: ERROR: an internal error has occurred > > /var/log/httpd/error_log: > [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 315, > in wsgi_execute > [Mon Mar 12 10:41:24 2012] [error] result = > self.Command[name](*args, **options) > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in > __call__ > [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run > [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, > **options) > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > 1866, in execute > [Mon Mar 12 10:41:24 2012] [error] > self.obj.convert_attribute_members(e[1], *args, **options) > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > 518, in convert_attribute_members > [Mon Mar 12 10:41:24 2012] [error] > ldap_obj.get_primary_key_from_dn(member) > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > 490, in get_primary_key_from_dn > [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] > [Mon Mar 12 10:41:24 2012] [error] File > "/usr/lib/python2.7/site-packages/ipalib/dn.py", line 1137, in > __getitem__ > [Mon Mar 12 10:41:24 2012] [error] raise KeyError("\\"%s\\" not > found in %s" % (key, self. __str__())) > > > The problem is in this function: > def get_primary_key_from_dn(self, dn): > try: > if self.rdn_attribute: > (dn, entry_attrs) = self.backend.get_entry( > dn, [self.primary_key.name] > ) > try: > return entry_attrs[self.primary_key.name][0] > except (KeyError, IndexError): > return '' > except errors.NotFound: > pass > # DN object assures we're returning a decoded (unescaped) value > dn = DN(dn) > return dn[self.primary_key.name] > > Martin > Should sudocmd-del should also delete the command from any rules the command is in? That function needs to be fixed either way. But I'm not sure what it should do if the entry doesn't exist. Return the full DN instead? -- Petr? From mkosek at redhat.com Mon Mar 12 16:21:29 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Mar 2012 17:21:29 +0100 Subject: [Freeipa-devel] [PATCHES] 0012-13 Don't allow deleting required config options In-Reply-To: <4F508DE0.2040402@redhat.com> References: <4F42159E.8080006@redhat.com> <4F42A440.7080904@redhat.com> <4F436910.4040004@redhat.com> <4F4BF934.4000902@redhat.com> <4F4CB257.5090001@redhat.com> <4F4CE275.6070708@redhat.com> <4F4DF93E.80509@redhat.com> <4F4DFA85.4010400@redhat.com> <4F4E19E0.5010305@redhat.com> <4F4E3BEA.5010308@redhat.com> <4F4E3FB0.9060409@redhat.com> <4F508DE0.2040402@redhat.com> Message-ID: <1331569289.1491.65.camel@balmora.brq.redhat.com> On Fri, 2012-03-02 at 10:07 +0100, Petr Viktorin wrote: > On 02/29/2012 04:09 PM, Petr Viktorin wrote: > > On 02/29/2012 03:53 PM, Rob Crittenden wrote: > >> Petr Viktorin wrote: > >>> On 02/29/2012 11:14 AM, Jan Cholasta wrote: > >>>> On 29.2.2012 11:09, Petr Viktorin wrote: > >>>>> On 02/28/2012 03:19 PM, Jan Cholasta wrote: > >>>>>> On 28.2.2012 11:54, Petr Viktorin wrote: > >>>>>>> On 02/27/2012 10:44 PM, Rob Crittenden wrote: > >>>>>>>> Petr Viktorin wrote: > >>>>>>>>> On 02/20/2012 08:51 PM, Rob Crittenden wrote: > >>>>>>>>>> Petr Viktorin wrote: > >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2159 says various config > >>>>>>>>>>> options > >>>>>>>>>>> are not marked Required, so entering an empty value for it will > >>>>>>>>>>> pass > >>>>>>>>>>> validation (and IPA will blow up later when it expects a > >>>>>>>>>>> string,not > >>>>>>>>>>> None). Forexample the following: > >>>>>>>>>>> $ ipa config-mod --groupsearch= > >>>>>>>>>>> fails with AttributeError: 'NoneType' object has no attribute > >>>>>>>>>>> 'split' > >>>>>>>>>>> > >>>>>>>>>>> There is a more general problem behind this, though: even if the > >>>>>>>>>>> attributes *are* marked as Required, an empty string will pass > >>>>>>>>>>> validation. This is because `None` is used in > >>>>>>>>>>> `Param.validate` to > >>>>>>>>>>> mean > >>>>>>>>>>> both "No value supplied" and "Empty value supplied". The method > >>>>>>>>>>> currently assumes the former, and skips validation entirely for > >>>>>>>>>>> `None` > >>>>>>>>>>> values to optional parameters. > >>>>>>>>>>> > >>>>>>>>>>> For example, the following will delete "membergroup", even > >>>>>>>>>>> though > >>>>>>>>>>> it's a > >>>>>>>>>>> required attribute : > >>>>>>>>>>> > >>>>>>>>>>> $ ipa delegation-add --attrs=street --group=editors \ > >>>>>>>>>>> --membergroup=admins td1 > >>>>>>>>>>> $ ipa delegation-mod --membergroup= td1 > >>>>>>>>>>> > >>>>>>>>>>> Note that some LDAPObjects handle this with a _check_empty_attrs > >>>>>>>>>>> function, so they aren't affected. That function is specific to > >>>>>>>>>>> LADP > >>>>>>>>>>> objects, though. So I needed to tackle this on a lower level. > >>>>>>>>>>> > >>>>>>>>>>> This patch solves the problem by > >>>>>>>>>>> * adding a 'nonempty' flag when a required parameter of a CRUD > >>>>>>>>>>> Update > >>>>>>>>>>> object is auto-converted to a non-required parameter > >>>>>>>>>>> * making the`validate` method aware of whether the parameter was > >>>>>>>>>>> supplied; and if it was, honor the "nonempty" flag. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> The second patch fixes > >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2159 by > >>>>>>>>>>> marking required config options as required. > >>>>>>>>>> > >>>>>>>>>> This looks good but I think there are other things to protect in > >>>>>>>>>> config > >>>>>>>>>> as well such as the default e-mail domain. It is probably safe to > >>>>>>>>>> say > >>>>>>>>>> that everything in there is required. > >>>>>>>>>> > >>>>>>>>>> rob > >>>>>>>>> > >>>>>>>>> Let me just double-check this with you. > >>>>>>>>> > >>>>>>>>> According to code in the user plugin (around line 330), if the > >>>>>>>>> default > >>>>>>>>> e-mail domain is not set, users don't get an address > >>>>>>>>> auto-assigned. Do > >>>>>>>>> we really want to require user e-mails? > >>>>>>>>> > >>>>>>>>> ipaconfigstring (the password plugin flags) are a set (multivalue, > >>>>>>>>> not > >>>>>>>>> required). > >>>>>>>>> > >>>>>>>>> The rest of the values I left as not required are for optional > >>>>>>>>> features > >>>>>>>>> or limits: search results & time limit, max. username length, > >>>>>>>>> password > >>>>>>>>> expiry notification. Currently if these are missing, the > >>>>>>>>> feature/limit > >>>>>>>>> is disabled (well, except for the time limit). > >>>>>>>>> But, there are also special values (0 or -1) that have the same > >>>>>>>>> effect > >>>>>>>>> as a missing value. Sometimes they're documented. > >>>>>>>>> So we want to enforce that users use these special values > >>>>>>>>> instead of > >>>>>>>>> removing the config entry? > >>>>>>>> > >>>>>>>> I think we want to enforce that these are defined. It will be > >>>>>>>> confusing > >>>>>>>> for users if these are not there at all. I don't think we need to > >>>>>>>> show > >>>>>>>> the special options, just declare that the attribute is required. > >>>>>>>> > >>>>>>>> rob > >>>>>>>> > >>>>>>> > >>>>>>> Attaching updated patch 13. > >>>>>>> > >>>>>>> Only the default e-mail domain > >>>>>>> (https://fedorahosted.org/freeipa/ticket/2409) and ipaconfigstring > >>>>>>> are > >>>>>>> still optional. > >>>>>>> > >>>>>> > >>>>>> You have removed all the config-related defensive code in the > >>>>>> patch, is > >>>>>> this a good idea? What will happen if someone e.g. deletes a required > >>>>>> config attribute directly from LDAP? > >>>>>> > >>>>> > >>>>> Then IPA crashes. The defensive code wasn't there for all cases > >>>>> anyway, > >>>>> as ticket #2159 shows. > >>>>> > >>>>> If we want to protect against this it would probably be better to make > >>>>> the config class itself give the default when a required value is > >>>>> missing. > >>>>> > >>>> > >>>> This, and raise an error in cases where no default is available (the > >>>> check should probably be done in ldap.get_ipa_config). > >>>> > >>>> Honza > >>>> > >>> > >>> Would a better approach be to modify the LDAP schema to require these > >>> values? > >>> > >> > >> I think that may be a longer-term fix. I propose we keep the defensive > >> code in for now and correct it in the future. > >> > >> rob > > > > Here is an updated patch 13 that does that. > > > > And here is patch 12 rebased against current master. > ACK for 0012-02 and 0013-03. I think this is a good compromise for now. Pushed to master, ipa-2-2. Martin From nalin at redhat.com Mon Mar 12 16:33:20 2012 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 12 Mar 2012 12:33:20 -0400 Subject: [Freeipa-devel] IPAv2 on SL6.2 using NIS fails with "Failed password" error In-Reply-To: <4F5A70D9.7080007@redhat.com> References: <4F5A70D9.7080007@redhat.com> Message-ID: <20120312163320.GA12404@redhat.com> On Fri, Mar 09, 2012 at 04:06:33PM -0500, Dmitri Pal wrote: > As far as I understand underlying DS can also be configured to create > weak hashes needed for NIS but it is not recommended. But this is > something that gurus should confirm. The NIS server will serve up password hashes which are compatible with traditional crypt() if any are found in an entry's userPassword attribute. By default, the directory server doesn't create them in this form (it prefers SSHA, or SSHA256, I guess), but this can be changed by setting "passwordStorageScheme: CRYPT" in its cn=config entry. Two things to watch out for, though. The first is that when you make the change, the directory server starts generating userPassword values which begin with "{crypt}", but the default configuration for the NIS server told it to look for values which began with "{CRYPT}", in a case-sensitive manner, so it wouldn't match them. This was corrected in slapi-nis 0.29. You'll want to either grab a newer package to pick up the new defaults, or override the run-time configuration of your copy to match the defaults from later versions. The second is that changing your passwordStorageScheme only affects how the server hashes passwords that will be set after you make the change, so if you're going to do it, it's better done sooner rather than later. HTH, Nalin From pspacek at redhat.com Mon Mar 12 17:07:07 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 12 Mar 2012 18:07:07 +0100 Subject: [Freeipa-devel] [PATCH] 0011 Fix ticket #55: BIND cannot be shutdown correctly In-Reply-To: <1331558061.1491.52.camel@balmora.brq.redhat.com> References: <4F5DE8D3.6040001@redhat.com> <4F5DF027.9070606@redhat.com> <1331558061.1491.52.camel@balmora.brq.redhat.com> Message-ID: <4F5E2D3B.9050900@redhat.com> On 03/12/2012 02:14 PM, Martin Kosek wrote: > On Mon, 2012-03-12 at 08:46 -0400, Dmitri Pal wrote: >> On 03/12/2012 08:15 AM, Petr Spacek wrote: >>> Hello, >>> >>> this patch fixes annoying bug from ticket #55: BIND cannot be >>> shutdown correctly, if psearch is enabled and LDAP connect fails >>> >>> Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/55 >>> >>> It's trivial three line patch, so Adam ACKed it on IRC. >>> >>> Patch is already in master: >>> https://fedorahosted.org/bind-dyndb-ldap/changeset/55d2886bb016adf3081a25eea616ce40f17d03e4 >>> >>> I think it's annoying and fix is trivial, so I opened BZ ticket for >>> RHEL6.3: https://bugzilla.redhat.com/show_bug.cgi?id=802375 >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> It seems that code has tabs which violates our coding standards. At >> least the indentation looks wrong. >> > > The whole bind-dyndb-ldap plugin use tabs for indentation, I would keep > that unless we want to create mixed tab-space environment. > > I just see that Petr indented the statement with 2 tabs instead of one. > > Martin Thanks for review, I missed double-tab. I agree with Martin, whole plugin and BIND actually use tabs for indentation. Double-tab fixed: https://fedorahosted.org/bind-dyndb-ldap/changeset/284ee38e4cb55766317822a6db0ac2a776435fa5 Sorry for my mistake. Petr^2 Spacek From mkosek at redhat.com Mon Mar 12 17:10:54 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Mar 2012 18:10:54 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased) In-Reply-To: <4F5E2075.2090906@redhat.com> References: <4F58D6E8.7040202@redhat.com> <1331555217.1491.31.camel@balmora.brq.redhat.com> <4F5DFC4C.1080906@redhat.com> <1331564466.1491.57.camel@balmora.brq.redhat.com> <4F5E2075.2090906@redhat.com> Message-ID: <1331572254.1491.78.camel@balmora.brq.redhat.com> On Mon, 2012-03-12 at 17:12 +0100, Petr Viktorin wrote: > On 03/12/2012 04:01 PM, Martin Kosek wrote: > > On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: > >> On 03/12/2012 01:26 PM, Martin Kosek wrote: > >>> On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: > >>>> Since sudo commands are case-sensitive, we can't use the CN as the RDN. > >>>> With this patch, the UUID is used instead. > >>>> It seems like a too easy fix. What am I missing? > >>>> > >>>> As far as I understand, the fact that the DN has a different structure > >>>> now shouldn't cause problems, even if there still are commands created > >>>> by old IPA versions. > >>>> For testing, use an unpatched version to create a few of these. > >>>> > >>>> The sudo commands are no longer sorted in sudocmd-find output. Doing > >>>> that would require the ability to use an arbitrary attribute as sort > >>>> key. Should I file an issue for that? > >>> > >>> I don't think that's necessary. We sort by LDAP object's primary key and > >>> since new SUDO commands still have sudocmd as its primary key, the > >>> sorting should just work (at least it does for me). > >> > >> Right, sorry for the noise. > >> > >>>> > >>>> Tests for the case sensitivity are included. > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/2482 > >>> > >>> This works pretty fine. Both my old client tests and sudoers compat tree > >>> tests looks good. So, cautious ACK from me. > >>> > >>> Martin > >>> > >> > >> The attached version is rebased against my patch 20. > >> > > > > Ah, I found an issue with the changed RDN attribute. We crash when I > > delete sudocmd that sudorule has enrolled as a member: > > > > # ipa sudocmd-add bar1 > > # ipa sudocmd-add bar2 > > # ipa sudorule-add foo > > # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 > > # ipa sudocmd-del bar2 > > # ipa sudorule-find > > ipa: ERROR: an internal error has occurred > > > > /var/log/httpd/error_log: > > [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): > > [Mon Mar 12 10:41:24 2012] [error] File > > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 315, > > in wsgi_execute > > [Mon Mar 12 10:41:24 2012] [error] result = > > self.Command[name](*args, **options) > > [Mon Mar 12 10:41:24 2012] [error] File > > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in > > __call__ > > [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) > > [Mon Mar 12 10:41:24 2012] [error] File > > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run > > [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, > > **options) > > [Mon Mar 12 10:41:24 2012] [error] File > > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > > 1866, in execute > > [Mon Mar 12 10:41:24 2012] [error] > > self.obj.convert_attribute_members(e[1], *args, **options) > > [Mon Mar 12 10:41:24 2012] [error] File > > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > > 518, in convert_attribute_members > > [Mon Mar 12 10:41:24 2012] [error] > > ldap_obj.get_primary_key_from_dn(member) > > [Mon Mar 12 10:41:24 2012] [error] File > > "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > > 490, in get_primary_key_from_dn > > [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] > > [Mon Mar 12 10:41:24 2012] [error] File > > "/usr/lib/python2.7/site-packages/ipalib/dn.py", line 1137, in > > __getitem__ > > [Mon Mar 12 10:41:24 2012] [error] raise KeyError("\\"%s\\" not > > found in %s" % (key, self. __str__())) > > > > > > The problem is in this function: > > def get_primary_key_from_dn(self, dn): > > try: > > if self.rdn_attribute: > > (dn, entry_attrs) = self.backend.get_entry( > > dn, [self.primary_key.name] > > ) > > try: > > return entry_attrs[self.primary_key.name][0] > > except (KeyError, IndexError): > > return '' > > except errors.NotFound: > > pass > > # DN object assures we're returning a decoded (unescaped) value > > dn = DN(dn) > > return dn[self.primary_key.name] > > > > Martin > > > > Should sudocmd-del should also delete the command from any rules the > command is in? I would rather prevent deleting it when it is any sudorule to avoid unpleasant user surprises. > > That function needs to be fixed either way. But I'm not sure what it > should do if the entry doesn't exist. Return the full DN instead? > Probably, as this is the only value we know at the moment - it certainly should not crash. Although DN with ipaUniqueID won't be very helpful. A precaution I suggested above should prevent that. Martin From rcritten at redhat.com Mon Mar 12 18:10:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 14:10:38 -0400 Subject: [Freeipa-devel] [PATCH] 227-228 Add last missing bits in new bind-dyndb-ldap In-Reply-To: <1331132781.22847.4.camel@balmora.brq.redhat.com> References: <1330604359.4451.18.camel@balmora.brq.redhat.com> <1331132781.22847.4.camel@balmora.brq.redhat.com> Message-ID: <4F5E3C1E.9060501@redhat.com> Martin Kosek wrote: > On Thu, 2012-03-01 at 13:19 +0100, Martin Kosek wrote: >> These 2 patches changes the DNS API to support the last missing bits in >> new bind-dyndb-ldap: >> >> 1) Both global and per-zone forwarders now support a conditional custom >> port (with format "IP_ADDRESS PORT") >> 2) Missing global configuration options have been added: >> * idnsforwardpolicy: Default policy for conditional forwarding >> * idnsallowsyncptr: Allow globaly PTR synchronization for dynamic >> updates >> * idnszonerefresh: Default interval between regular polls of the >> name server for new DNS zones >> >> Before these patches are pushed, I will just have to update the minimal >> bind-dyndb-ldap version (it has not been built yet) which have a full >> support for these. >> >> Martin > > New version of bind-dyndb-ldap has been released, attaching a rebased > patch with fixed bind-dyndb-ldap version in spec file. > > I also fixed the forwarder format, it should be "$IP port $PORT", not > "$IP $PORT" as it was in a previous version of the patch. I tested this > new format with bind-dyndb-ldap it forwards the queries properly. > > Unfortunately, fixed version of bind have not been released yet, i.e. > bind will crash if forwarders are defined both in named.conf and LDAP > global configuration (dnsconfig-mod). > > Martin The patch itself looks ok, just a couple of general concerns: 1. By default dnsconfig-show displays nothing. This is a little disconcerting. I don't believe we show empty attributes anywhere else, not sure if we should make an exception here or show some other message, perhaps a varying summary? 2. I don't think there is a lot we can do but this still conflicts with the file-based configuration. For example, someone can add a forwarder and caused named to not restart the next time because there is also one defined in named.conf. I'd almost prefer that one win rather than the daemon not start at all. But for our purposes people may get confused because they don't see the forwarders they configured at install time and merely managing this list can break your name server at some undetermined future point. rob From rcritten at redhat.com Mon Mar 12 19:18:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 15:18:29 -0400 Subject: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa In-Reply-To: <20120312151304.GD4744@redhat.com> References: <4F577175.4070407@redhat.com> <20120309064328.GH2724@redhat.com> <4F5E116E.3010901@redhat.com> <20120312151304.GD4744@redhat.com> Message-ID: <4F5E4C05.6040406@redhat.com> Alexander Bokovoy wrote: > On Mon, 12 Mar 2012, Rob Crittenden wrote: >> Alexander Bokovoy wrote: >>> On Wed, 07 Mar 2012, Rob Crittenden wrote: >>> >>>> Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in >>>> enforcing mode. >>>> >>>> This is being done in the HTTP instance so we can set both booleans >>>> in one step and save a bit of time (it is still slow). >>> I would prefer all platform-specific manipulations of security >>> policies to be moved to platform-specific module. >>> >>> Make a HTTP class there (like I did dirsrv class in systemd >>> backend) and perform manipulations on service enable. >>> >>> This way main code will stay clear of platform-specific code. >>> >>> Sorry for not looking into the issue before. >>> >> >> I'd prefer to keep the change simple for now and do the big move post 2.2. > ACK on condition you'd file a ticket for the post 2.2 work. > > :) Filed this https://fedorahosted.org/freeipa/ticket/2519 I found an issue with this patch that I need to address, will submit a replacement. rob From rcritten at redhat.com Mon Mar 12 19:20:50 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 15:20:50 -0400 Subject: [Freeipa-devel] [PATCH] 230 Refresh resolvers after DNS install In-Reply-To: <1331037474.7279.5.camel@balmora.brq.redhat.com> References: <1331037474.7279.5.camel@balmora.brq.redhat.com> Message-ID: <4F5E4C92.5010602@redhat.com> Martin Kosek wrote: > The testing instructions are attached to the ticket. > > --- > > Server framework calls acutil.res_send() to send DNS queries used > for various DNS tests. However, once acutil is imported it does > not change its list of configured resolvers even when > /etc/resolv.conf is changed. This may lead to unexpected > resolution issues. > > We should at least reload httpd when we change /etc/resolv.conf to > point to FreeIPA nameserver to force a new import of acutil and > thus workaround this bug until it is resolved in authconfig. > > https://fedorahosted.org/freeipa/ticket/2481 ACK, pushed to master and ipa-2-2. The explicit test made verifying this easy, thanks. rob From ohamada at redhat.com Mon Mar 12 19:38:23 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Mon, 12 Mar 2012 20:38:23 +0100 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <4F58D620.90107@redhat.com> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> <1331049562.26197.82.camel@willson.li.ssimo.org> <4F563F8F.5080504@redhat.com> <4F5657B8.6080409@redhat.com> <4F58D620.90107@redhat.com> Message-ID: <4F5E50AF.5090701@redhat.com> On 03/08/2012 04:54 PM, Dmitri Pal wrote: > On 03/06/2012 01:30 PM, Ondrej Hamada wrote: >> On 03/06/2012 05:47 PM, Dmitri Pal wrote: >>> On 03/06/2012 10:59 AM, Simo Sorce wrote: >>>> On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: >>>>> [...] >>>>>> For a read-only KDC we need to investigate what's the better >>>>> solution. >>>>>> There are many ways we can handle the issue, one of the simplest is >>>>>> probably to allow the RO KDC to use a special LDAP Extended >>>>> operation >>>>>> against a full R/W server to get the user keys to sign, >>>>> authenticating >>>>>> with a special R/O KDC principal. We can also investigate how MS >>>>> does >>>>>> internal forwarding and do something similar as I suspect that's >>>>>> something samba4-RODC will want to implement too, so we could share >>>>> some >>>>>> of the development burden there. >>>>>> >>>>>> Simo. >>>>>> >>>>> I do not think it is a good idea for the remote RO KDC to go back to >>>>> the main datacenter on every authentication without some sort of >>>>> caching. This is why I think that some kind of SSSD integration might >>>>> be due. If RO KDC would just pass the authentication to SSSD in some >>>>> way and SSSD would do the caching in case the office gets offline. I >>>>> understand that authhub as is will not work as the client sends time >>>>> stamp encrypted with password and SSSD needs plain text password as >>>>> credential. I do not know if there is a way to solve this without >>>>> actually sending the password in the tunnel. IMO it is more important >>>>> to make sure that remote office can have uninterrupted operation than >>>>> to worry about the password being sent inside the encrypted tunnel. It >>>>> is something that deployment should decide and weight risks against >>>>> convenience. >>>> This is why MS does partial replication, ie allows the RODC to have >>>> data >>>> about the office users. It's complex and there are many ways to handle >>>> it. We need to look at various options and see how they would work >>>> against uses cases we want to support. >>>> Simo. >>>> >>> Then may be Ondrej should start with formulating use cases and >>> requirements based on this discussion. >>> >> I see three possible use cases here, but only two should be considered >> when speaking about consumer node: >> >> 1) The office that should rely on that replica is quite a big one >> (hundreds of employees) or many different users are authenticating >> against its replica or there are located admins, who need to do a lot >> of write-operations. --> In this case I suppose the best solution is >> to deploy master replica there. >> >> >> 2) Office that doesn't fulfil the conditions in 1) - not a desperate >> need for write-operations on ipa-server, but the priority is to allow >> (some) clients to authenticate and use available services even when >> the network is down. --> We need a consumer with credentials caching, >> authentication requests for non-cached users or write operations must >> be forwarded to master. >> >> 3) Office that doesn't fulfil the conditions in 1), but the priority >> is security, so that the consumer is not allowed to store or cache any >> confidential data. --> We need a consumer, authentications and write >> operations must be forwarded to master. >> >> If we choose the second use case, both the caching and request >> forwarding must be implemented. I suppose that there shouldn't be big >> problem to decide during the installation to turn the caching off by >> some option like '-no-chaching' so that the consumer could be used for >> the third use case as well. >> > Can you please now create a set usage scenarios for the 2) and 3). > User logs in and he is in cache, he is not in cache, he is redirected > and data is cached, he failed and account lockout data is updated > locally or on the other server? Admin tries to perform and IPA command > or ldapmodify command - what happens? > > Can those work flows be spelled out in details for caching and non use > cases? > > I'll start with usage scenario for 3), it's shorter: All write operations and authentication requests are forwarded to the master Operations when connection is OK: ---------------------------------------------- read -- local write-forwarding to master authentication-forwarding to master Operations when connection is BROKEN: ----------------------------------------------------- read-local (only until ticket expires) write-not available authentication-not available Usage scenario for 2): USER'S operations when connection is OK: ------------------------------------------------------- read data -> local write data -> forwarding to master authentication: -credentials cached -- authenticate against credentials in local cache -on failure: log failure locally, update data about failures only on lock-down of account -credentials not cached -- forward request to master, on success cache the credentials USER'S operations when connection is BROKEN: -------------------------------------------------------------- read data -> local write data -> not available authentication: -credentials cached -- authenticate against credentials in local cache -on failure: log failure locally, on lock-down lock account locally and update information to master when the connection is back on -credentials not cached -- deny access -- not possible to authenticate user ad ADMIN'S -- I suppose that admin's credentials should not be cached -- it doesn't make much sense because all the operations, he's permitted to do, could be executed on master server only ADMIN'S operations when connection is OK: --------------------------------------------------------- read - local write - forwarding to master authentication - forwarding to master ADMIN'S operations when connection is BROKEN: ---------------------------------------------------------------- read-only operations until valid ticket expires write - not available authentication - not available -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Mar 12 19:45:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 15:45:53 -0400 Subject: [Freeipa-devel] [PATCH] 974 minimum selinux-policy for F-17 In-Reply-To: <1331286368.26839.1.camel@balmora.brq.redhat.com> References: <4F4D9DD1.1090401@redhat.com> <4F567F3F.9050004@redhat.com> <1331286368.26839.1.camel@balmora.brq.redhat.com> Message-ID: <4F5E5271.7060808@redhat.com> Martin Kosek wrote: > On Tue, 2012-03-06 at 16:18 -0500, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Update the minimum selinux-policy for F-17. This will enable >>> ipa_memcached to run in Enforcing mode. Still waiting on this to be >>> backported to at least F-16. >>> >>> You have to manually enable the boolean. >>> >>> rob >>> >> >> F-16 package is in updates-testing, patch updated. >> >> rob > > > ACK. New selinux-policy looks OK. I was able to install IPA server with > enforcing. Of course, httpd_manage_ipa need to be ON. > > Martin > pushed to master and ipa-2-2 From dpal at redhat.com Mon Mar 12 19:51:14 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 Mar 2012 15:51:14 -0400 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <4F5E50AF.5090701@redhat.com> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> <1331049562.26197.82.camel@willson.li.ssimo.org> <4F563F8F.5080504@redhat.com> <4F5657B8.6080409@redhat.com> <4F58D620.90107@redhat.com> <4F5E50AF.5090701@redhat.com> Message-ID: <4F5E53B2.4090706@redhat.com> On 03/12/2012 03:38 PM, Ondrej Hamada wrote: > On 03/08/2012 04:54 PM, Dmitri Pal wrote: >> On 03/06/2012 01:30 PM, Ondrej Hamada wrote: >>> On 03/06/2012 05:47 PM, Dmitri Pal wrote: >>>> On 03/06/2012 10:59 AM, Simo Sorce wrote: >>>>> On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: >>>>>> [...] >>>>>>> For a read-only KDC we need to investigate what's the better >>>>>> solution. >>>>>>> There are many ways we can handle the issue, one of the simplest is >>>>>>> probably to allow the RO KDC to use a special LDAP Extended >>>>>> operation >>>>>>> against a full R/W server to get the user keys to sign, >>>>>> authenticating >>>>>>> with a special R/O KDC principal. We can also investigate how MS >>>>>> does >>>>>>> internal forwarding and do something similar as I suspect that's >>>>>>> something samba4-RODC will want to implement too, so we could share >>>>>> some >>>>>>> of the development burden there. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> I do not think it is a good idea for the remote RO KDC to go back to >>>>>> the main datacenter on every authentication without some sort of >>>>>> caching. This is why I think that some kind of SSSD integration might >>>>>> be due. If RO KDC would just pass the authentication to SSSD in some >>>>>> way and SSSD would do the caching in case the office gets offline. I >>>>>> understand that authhub as is will not work as the client sends time >>>>>> stamp encrypted with password and SSSD needs plain text password as >>>>>> credential. I do not know if there is a way to solve this without >>>>>> actually sending the password in the tunnel. IMO it is more important >>>>>> to make sure that remote office can have uninterrupted operation than >>>>>> to worry about the password being sent inside the encrypted tunnel. It >>>>>> is something that deployment should decide and weight risks against >>>>>> convenience. >>>>> This is why MS does partial replication, ie allows the RODC to have >>>>> data >>>>> about the office users. It's complex and there are many ways to handle >>>>> it. We need to look at various options and see how they would work >>>>> against uses cases we want to support. >>>>> Simo. >>>>> >>>> Then may be Ondrej should start with formulating use cases and >>>> requirements based on this discussion. >>>> >>> I see three possible use cases here, but only two should be considered >>> when speaking about consumer node: >>> >>> 1) The office that should rely on that replica is quite a big one >>> (hundreds of employees) or many different users are authenticating >>> against its replica or there are located admins, who need to do a lot >>> of write-operations. --> In this case I suppose the best solution is >>> to deploy master replica there. >>> >>> >>> 2) Office that doesn't fulfil the conditions in 1) - not a desperate >>> need for write-operations on ipa-server, but the priority is to allow >>> (some) clients to authenticate and use available services even when >>> the network is down. --> We need a consumer with credentials caching, >>> authentication requests for non-cached users or write operations must >>> be forwarded to master. >>> >>> 3) Office that doesn't fulfil the conditions in 1), but the priority >>> is security, so that the consumer is not allowed to store or cache any >>> confidential data. --> We need a consumer, authentications and write >>> operations must be forwarded to master. >>> >>> If we choose the second use case, both the caching and request >>> forwarding must be implemented. I suppose that there shouldn't be big >>> problem to decide during the installation to turn the caching off by >>> some option like '-no-chaching' so that the consumer could be used for >>> the third use case as well. >>> >> Can you please now create a set usage scenarios for the 2) and 3). >> User logs in and he is in cache, he is not in cache, he is redirected >> and data is cached, he failed and account lockout data is updated >> locally or on the other server? Admin tries to perform and IPA command >> or ldapmodify command - what happens? >> >> Can those work flows be spelled out in details for caching and non use >> cases? >> >> > > I'll start with usage scenario for 3), it's shorter: > All write operations and authentication requests are forwarded to the > master > > Operations when connection is OK: > ---------------------------------------------- > read -- local > write-forwarding to master > authentication-forwarding to master > > Operations when connection is BROKEN: > ----------------------------------------------------- > read-local (only until ticket expires) > write-not available > authentication-not available > > > Usage scenario for 2): > > USER'S operations when connection is OK: > ------------------------------------------------------- > read data -> local > write data -> forwarding to master > authentication: > -credentials cached -- authenticate against credentials in local cache > -on failure: log failure locally, update data > about failures only on lock-down of account > I am not sure is this is always right. IMO we should make it configurable and allow the admin to decide if in this case the authentication should be performed against central server and then cached credentials rather than always going to the cache first. > -credentials not cached -- forward request to master, on success cache > the credentials > > USER'S operations when connection is BROKEN: > -------------------------------------------------------------- > read data -> local > write data -> not available > authentication: > -credentials cached -- authenticate against credentials in local cache > -on failure: log failure locally, on > lock-down lock account locally and update information to master when > the connection is back on > I am not sure we propagate the failures and account lockout. I think it is per server and not replicated so when the connection is restored we should just switch to authenticating against a central server. > -credentials not cached -- deny access -- not possible to authenticate > user > > ad ADMIN'S -- I suppose that admin's credentials should not be cached > -- it doesn't make much sense because all the operations, he's > permitted to do, could be executed on master server only > > ADMIN'S operations when connection is OK: > --------------------------------------------------------- > read - local > write - forwarding to master > authentication - forwarding to master > > ADMIN'S operations when connection is BROKEN: > ---------------------------------------------------------------- > read-only operations until valid ticket expires > write - not available > authentication - not available > Now when we know the scenarios (assuming we agree on those after some review) next would be to specify how you plan to implement the forwarding and caching. Is auth forwarding would be implemented using KDC or there will be some kind of referral/redirect issued to the client. No you plan to implement write forwarding> I assume some kind of the DS plugin? It might already be there but might require some tweaks and custom configuration. > -- > Regards, > > Ondrej Hamada > FreeIPA team > jabber: ohama at jabbim.cz > IRC: ohamada -- 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 rmeggins at redhat.com Mon Mar 12 19:51:40 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Mar 2012 13:51:40 -0600 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <4F5E53B2.4090706@redhat.com> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> <1331049562.26197.82.camel@willson.li.ssimo.org> <4F563F8F.5080504@redhat.com> <4F5657B8.6080409@redhat.com> <4F58D620.90107@redhat.com> <4F5E50AF.5090701@redhat.com> <4F5E53B2.4090706@redhat.com> Message-ID: <4F5E53CC.10101@redhat.com> On 03/12/2012 01:51 PM, Dmitri Pal wrote: > On 03/12/2012 03:38 PM, Ondrej Hamada wrote: >> On 03/08/2012 04:54 PM, Dmitri Pal wrote: >>> On 03/06/2012 01:30 PM, Ondrej Hamada wrote: >>>> On 03/06/2012 05:47 PM, Dmitri Pal wrote: >>>>> On 03/06/2012 10:59 AM, Simo Sorce wrote: >>>>>> On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: >>>>>>> [...] >>>>>>>> For a read-only KDC we need to investigate what's the better >>>>>>> solution. >>>>>>>> There are many ways we can handle the issue, one of the simplest is >>>>>>>> probably to allow the RO KDC to use a special LDAP Extended >>>>>>> operation >>>>>>>> against a full R/W server to get the user keys to sign, >>>>>>> authenticating >>>>>>>> with a special R/O KDC principal. We can also investigate how MS >>>>>>> does >>>>>>>> internal forwarding and do something similar as I suspect that's >>>>>>>> something samba4-RODC will want to implement too, so we could share >>>>>>> some >>>>>>>> of the development burden there. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> I do not think it is a good idea for the remote RO KDC to go back to >>>>>>> the main datacenter on every authentication without some sort of >>>>>>> caching. This is why I think that some kind of SSSD integration might >>>>>>> be due. If RO KDC would just pass the authentication to SSSD in some >>>>>>> way and SSSD would do the caching in case the office gets offline. I >>>>>>> understand that authhub as is will not work as the client sends time >>>>>>> stamp encrypted with password and SSSD needs plain text password as >>>>>>> credential. I do not know if there is a way to solve this without >>>>>>> actually sending the password in the tunnel. IMO it is more important >>>>>>> to make sure that remote office can have uninterrupted operation than >>>>>>> to worry about the password being sent inside the encrypted tunnel. It >>>>>>> is something that deployment should decide and weight risks against >>>>>>> convenience. >>>>>> This is why MS does partial replication, ie allows the RODC to have >>>>>> data >>>>>> about the office users. It's complex and there are many ways to handle >>>>>> it. We need to look at various options and see how they would work >>>>>> against uses cases we want to support. >>>>>> Simo. >>>>>> >>>>> Then may be Ondrej should start with formulating use cases and >>>>> requirements based on this discussion. >>>>> >>>> I see three possible use cases here, but only two should be considered >>>> when speaking about consumer node: >>>> >>>> 1) The office that should rely on that replica is quite a big one >>>> (hundreds of employees) or many different users are authenticating >>>> against its replica or there are located admins, who need to do a lot >>>> of write-operations. --> In this case I suppose the best solution is >>>> to deploy master replica there. >>>> >>>> >>>> 2) Office that doesn't fulfil the conditions in 1) - not a desperate >>>> need for write-operations on ipa-server, but the priority is to allow >>>> (some) clients to authenticate and use available services even when >>>> the network is down. --> We need a consumer with credentials caching, >>>> authentication requests for non-cached users or write operations must >>>> be forwarded to master. >>>> >>>> 3) Office that doesn't fulfil the conditions in 1), but the priority >>>> is security, so that the consumer is not allowed to store or cache any >>>> confidential data. --> We need a consumer, authentications and write >>>> operations must be forwarded to master. >>>> >>>> If we choose the second use case, both the caching and request >>>> forwarding must be implemented. I suppose that there shouldn't be big >>>> problem to decide during the installation to turn the caching off by >>>> some option like '-no-chaching' so that the consumer could be used for >>>> the third use case as well. >>>> >>> Can you please now create a set usage scenarios for the 2) and 3). >>> User logs in and he is in cache, he is not in cache, he is redirected >>> and data is cached, he failed and account lockout data is updated >>> locally or on the other server? Admin tries to perform and IPA command >>> or ldapmodify command - what happens? >>> >>> Can those work flows be spelled out in details for caching and non use >>> cases? >>> >>> >> >> I'll start with usage scenario for 3), it's shorter: >> All write operations and authentication requests are forwarded to the >> master >> >> Operations when connection is OK: >> ---------------------------------------------- >> read -- local >> write-forwarding to master >> authentication-forwarding to master >> >> Operations when connection is BROKEN: >> ----------------------------------------------------- >> read-local (only until ticket expires) >> write-not available >> authentication-not available >> >> >> Usage scenario for 2): >> >> USER'S operations when connection is OK: >> ------------------------------------------------------- >> read data -> local >> write data -> forwarding to master >> authentication: >> -credentials cached -- authenticate against credentials in local cache >> -on failure: log failure locally, update data >> about failures only on lock-down of account >> > > I am not sure is this is always right. IMO we should make it > configurable and allow the admin to decide if in this case the > authentication should be performed against central server and then > cached credentials rather than always going to the cache first. > >> -credentials not cached -- forward request to master, on success >> cache the credentials >> >> USER'S operations when connection is BROKEN: >> -------------------------------------------------------------- >> read data -> local >> write data -> not available >> authentication: >> -credentials cached -- authenticate against credentials in local cache >> -on failure: log failure locally, on >> lock-down lock account locally and update information to master when >> the connection is back on >> > > I am not sure we propagate the failures and account lockout. I think > it is per server and not replicated so when the connection is restored > we should just switch to authenticating against a central server. > >> -credentials not cached -- deny access -- not possible to >> authenticate user >> >> ad ADMIN'S -- I suppose that admin's credentials should not be cached >> -- it doesn't make much sense because all the operations, he's >> permitted to do, could be executed on master server only >> >> ADMIN'S operations when connection is OK: >> --------------------------------------------------------- >> read - local >> write - forwarding to master >> authentication - forwarding to master >> >> ADMIN'S operations when connection is BROKEN: >> ---------------------------------------------------------------- >> read-only operations until valid ticket expires >> write - not available >> authentication - not available >> > > Now when we know the scenarios (assuming we agree on those after some > review) next would be to specify how you plan to implement the > forwarding and caching. Is auth forwarding would be implemented using > KDC or there will be some kind of referral/redirect issued to the > client. No you plan to implement write forwarding> I assume some kind > of the DS plugin? It might already be there but might require some > tweaks and custom configuration. http://port389.org/wiki/Howto:ChainOnUpdate > >> -- >> Regards, >> >> Ondrej Hamada >> FreeIPA team >> jabber:ohama at jabbim.cz >> IRC: ohamada > > > -- > 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 simo at redhat.com Mon Mar 12 20:16:05 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 12 Mar 2012 16:16:05 -0400 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <4F5E50AF.5090701@redhat.com> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> <1331049562.26197.82.camel@willson.li.ssimo.org> <4F563F8F.5080504@redhat.com> <4F5657B8.6080409@redhat.com> <4F58D620.90107@redhat.com> <4F5E50AF.5090701@redhat.com> Message-ID: <1331583365.9238.105.camel@willson.li.ssimo.org> On Mon, 2012-03-12 at 20:38 +0100, Ondrej Hamada wrote: > USER'S operations when connection is OK: > ------------------------------------------------------- > read data -> local > write data -> forwarding to master > authentication: > -credentials cached -- authenticate against credentials in local cache > -on failure: log failure locally, update > data > about failures only on lock-down of account > -credentials not cached -- forward request to master, on success > cache > the credentials > This scheme doesn't work with Kerberos. Either you have a copy of the user's keys locally or you don't, there is nothing you can really cache if you don't. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 12 20:18:42 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 16:18:42 -0400 Subject: [Freeipa-devel] [PATCH] 0021 Add CLI tests In-Reply-To: <4F575A01.1060501@redhat.com> References: <4F575A01.1060501@redhat.com> Message-ID: <4F5E5A22.1010109@redhat.com> Petr Viktorin wrote: > Most of the tests we have check if the server does the right thing with > XML-RPC calls. How the commandline is converted to command arguments, > including interactive prompting, is untested. > This patch adds some tests in this area. To do that I had to break up > cli.run into more manageable pieces, and initialize the CLI plugins in > test mode. > > Also I added nose's --nocapture option to the make-test script. With > this it's possible to use pdb.set_trace() to drop into a debugger while > running the tests. > > > I went ahead and added a test for ticket 2484, fixed in Martin's patch > 231 (Ignore case in yes/no prompts). > John had done similar work with --nocapture a while back but it is still pending. Perhaps we can merge his changes in with yours, they look largely overlapping. His patch is [PATCH 54/54] ticet 2135 - enhance make-test for debugging rob From rcritten at redhat.com Mon Mar 12 20:59:11 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 16:59:11 -0400 Subject: [Freeipa-devel] [PATCH] 235 Fix migration plugin compat check In-Reply-To: <1331293270.26839.2.camel@balmora.brq.redhat.com> References: <1331293270.26839.2.camel@balmora.brq.redhat.com> Message-ID: <4F5E639F.4000307@redhat.com> Martin Kosek wrote: > Ticket #2274 implements a check for compat plugin and warns user if > it is enabled. However, there are 2 issues connected with the plugin: > 1) The check is performed against the remote (migrated) LDAP server > and not the local LDAP server, which does not make much sense > 2) When the compat plugin is missing in cn=plugins,cn=config, it > raises an error and thus breaks the migration > This patch fixes both issues. > > https://fedorahosted.org/freeipa/ticket/2508 ACK, pushed to master and ipa-2-2 From rcritten at redhat.com Mon Mar 12 21:04:55 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 17:04:55 -0400 Subject: [Freeipa-devel] [PATCH] 17 More exception handlers in ipa-client-install In-Reply-To: <1331565960.1491.60.camel@balmora.brq.redhat.com> References: <4F5A0309.1080001@redhat.com> <1331304628.26839.8.camel@balmora.brq.redhat.com> <4F5E13A3.7010608@redhat.com> <1331565960.1491.60.camel@balmora.brq.redhat.com> Message-ID: <4F5E64F7.8080105@redhat.com> Martin Kosek wrote: > On Mon, 2012-03-12 at 11:17 -0400, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Fri, 2012-03-09 at 14:18 +0100, Ondrej Hamada wrote: >>>> https://fedorahosted.org/freeipa/ticket/2415 >>>> https://fedorahosted.org/freeipa/ticket/1995 >>>> >>>> Added exception handler to certutil operation of adding CA to the >>>> default NSS database. If operation fails, installation is aborted and >>>> changes are rolled back. #2415 >>>> >>>> If obtaining host TGT fails, the installation is aborted and changes are >>>> rolled back. #1995 >>> >>> ACK. Pushed to master, ipa-2-2. >>> >>> Martin >> >> I wonder if we need to add an escape for --force here. The kinit is just >> to do things like nsupdate and add the SSH host keys. One might deem >> those not critical. >> >> rob > > This was a keytab kinit, as original ticket says a failure to get a > correct keytab will make it impossible to login anyway as ldap binds > from sssd will fail and auth verification will fail. This sounds pretty > critical to me... > > Martin > Right, but we're not failing because kinit failed but because the connection we're trying to make using that keytab failed. That can happen for other reasons, like the NSS shutdown bug we addressed. I won't press this, it is probably fine. Time will tell. rob From dpal at redhat.com Mon Mar 12 21:40:46 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 Mar 2012 17:40:46 -0400 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <1331583365.9238.105.camel@willson.li.ssimo.org> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> <1331049562.26197.82.camel@willson.li.ssimo.org> <4F563F8F.5080504@redhat.com> <4F5657B8.6080409@redhat.com> <4F58D620.90107@redhat.com> <4F5E50AF.5090701@redhat.com> <1331583365.9238.105.camel@willson.li.ssimo.org> Message-ID: <4F5E6D5E.2080807@redhat.com> On 03/12/2012 04:16 PM, Simo Sorce wrote: > On Mon, 2012-03-12 at 20:38 +0100, Ondrej Hamada wrote: >> USER'S operations when connection is OK: >> ------------------------------------------------------- >> read data -> local >> write data -> forwarding to master >> authentication: >> -credentials cached -- authenticate against credentials in local cache >> -on failure: log failure locally, update >> data >> about failures only on lock-down of account >> -credentials not cached -- forward request to master, on success >> cache >> the credentials >> > This scheme doesn't work with Kerberos. > Either you have a copy of the user's keys locally or you don't, there is > nothing you can really cache if you don't. > > Simo. > Yes this is what we are talking about here - the cache would have to contain user Kerberos key but there should be some expiration on the cache so that fetched and stored keys periodically cleaned following the policy an admin has defined. -- 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 Mar 12 21:51:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 17:51:43 -0400 Subject: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa In-Reply-To: <4F5E4C05.6040406@redhat.com> References: <4F577175.4070407@redhat.com> <20120309064328.GH2724@redhat.com> <4F5E116E.3010901@redhat.com> <20120312151304.GD4744@redhat.com> <4F5E4C05.6040406@redhat.com> Message-ID: <4F5E6FEF.2090409@redhat.com> Rob Crittenden wrote: > Alexander Bokovoy wrote: >> On Mon, 12 Mar 2012, Rob Crittenden wrote: >>> Alexander Bokovoy wrote: >>>> On Wed, 07 Mar 2012, Rob Crittenden wrote: >>>> >>>>> Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in >>>>> enforcing mode. >>>>> >>>>> This is being done in the HTTP instance so we can set both booleans >>>>> in one step and save a bit of time (it is still slow). >>>> I would prefer all platform-specific manipulations of security >>>> policies to be moved to platform-specific module. >>>> >>>> Make a HTTP class there (like I did dirsrv class in systemd >>>> backend) and perform manipulations on service enable. >>>> >>>> This way main code will stay clear of platform-specific code. >>>> >>>> Sorry for not looking into the issue before. >>>> >>> >>> I'd prefer to keep the change simple for now and do the big move post >>> 2.2. >> ACK on condition you'd file a ticket for the post 2.2 work. >> >> :) > > Filed this https://fedorahosted.org/freeipa/ticket/2519 > > I found an issue with this patch that I need to address, will submit a > replacement. > > rob Handle things better if a boolean doesn't exist. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-981-2-selinux.patch Type: text/x-diff Size: 4611 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 12 21:58:05 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 17:58:05 -0400 Subject: [Freeipa-devel] [PATCH] 984 fix anonlimits dn In-Reply-To: <1331223729.11911.14.camel@balmora.brq.redhat.com> References: <4F57E907.8060104@redhat.com> <1331223729.11911.14.camel@balmora.brq.redhat.com> Message-ID: <4F5E716D.6080205@redhat.com> Martin Kosek wrote: > On Wed, 2012-03-07 at 18:02 -0500, Rob Crittenden wrote: >> The value of nsslapd-anonlimitsdn wasn't being set properly because it >> wasn't quoted. This will fix it, replacing whatever is there with a >> correct value. >> >> rob > > The IPA anonlimits DN is now set correctly. However anonlimits in > cn=anonymous-limits,cn=etc,SUFFIX are still empty (nsSizeLimit and > nsLookThroughLimit values defined in 10-config.update are not set). > > Martin > These are operational attributes, did you have them in the attribute list of your query? $ ldapsearch -LLL -x -b cn=anonymous-limits,cn=etc,dc=example,dc=com nssizelimit nslookthroughlimit dn: cn=anonymous-limits,cn=etc,dc=example,dc=com nssizelimit: 5000 nslookthroughlimit: 5000 rob From abokovoy at redhat.com Mon Mar 12 21:58:15 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Mar 2012 23:58:15 +0200 Subject: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa In-Reply-To: <4F5E6FEF.2090409@redhat.com> References: <4F577175.4070407@redhat.com> <20120309064328.GH2724@redhat.com> <4F5E116E.3010901@redhat.com> <20120312151304.GD4744@redhat.com> <4F5E4C05.6040406@redhat.com> <4F5E6FEF.2090409@redhat.com> Message-ID: <20120312215815.GE4744@redhat.com> On Mon, 12 Mar 2012, Rob Crittenden wrote: > Rob Crittenden wrote: > >Alexander Bokovoy wrote: > >>On Mon, 12 Mar 2012, Rob Crittenden wrote: > >>>Alexander Bokovoy wrote: > >>>>On Wed, 07 Mar 2012, Rob Crittenden wrote: > >>>> > >>>>>Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in > >>>>>enforcing mode. > >>>>> > >>>>>This is being done in the HTTP instance so we can set both booleans > >>>>>in one step and save a bit of time (it is still slow). > >>>>I would prefer all platform-specific manipulations of security > >>>>policies to be moved to platform-specific module. > >>>> > >>>>Make a HTTP class there (like I did dirsrv class in systemd > >>>>backend) and perform manipulations on service enable. > >>>> > >>>>This way main code will stay clear of platform-specific code. > >>>> > >>>>Sorry for not looking into the issue before. > >>>> > >>> > >>>I'd prefer to keep the change simple for now and do the big move post > >>>2.2. > >>ACK on condition you'd file a ticket for the post 2.2 work. > >> > >>:) > > > >Filed this https://fedorahosted.org/freeipa/ticket/2519 > > > >I found an issue with this patch that I need to address, will submit a > >replacement. > > > >rob > > Handle things better if a boolean doesn't exist. Lucky that setsebool takes multiple booleans at the same time... Maybe it would make sense to merge bools upon recover? Otherwise ACK. -- / Alexander Bokovoy From simo at redhat.com Mon Mar 12 22:10:43 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 12 Mar 2012 18:10:43 -0400 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <4F5E6D5E.2080807@redhat.com> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> <1331049562.26197.82.camel@willson.li.ssimo.org> <4F563F8F.5080504@redhat.com> <4F5657B8.6080409@redhat.com> <4F58D620.90107@redhat.com> <4F5E50AF.5090701@redhat.com> <1331583365.9238.105.camel@willson.li.ssimo.org> <4F5E6D5E.2080807@redhat.com> Message-ID: <1331590243.9238.113.camel@willson.li.ssimo.org> On Mon, 2012-03-12 at 17:40 -0400, Dmitri Pal wrote: > On 03/12/2012 04:16 PM, Simo Sorce wrote: > > On Mon, 2012-03-12 at 20:38 +0100, Ondrej Hamada wrote: > >> USER'S operations when connection is OK: > >> ------------------------------------------------------- > >> read data -> local > >> write data -> forwarding to master > >> authentication: > >> -credentials cached -- authenticate against credentials in local cache > >> -on failure: log failure locally, update > >> data > >> about failures only on lock-down of account > >> -credentials not cached -- forward request to master, on success > >> cache > >> the credentials > >> > > This scheme doesn't work with Kerberos. > > Either you have a copy of the user's keys locally or you don't, there is > > nothing you can really cache if you don't. > > > > Simo. > > > Yes this is what we are talking about here - the cache would have to > contain user Kerberos key but there should be some expiration on the > cache so that fetched and stored keys periodically cleaned following the > policy an admin has defined. We would need a mechanism to transfer Kerberos keys, but that would not be sufficient, you'd have to give read-only servers also the realm krbtgt in order to be able to do anything with those keys. The way MS solves hits (I think) is by giving a special RODC krbtgt to each RODC, and then replicating all RODC krbtgt's with full domain controllers. Full domain controllers have logic to use RODC's krbtgt keys instead of the normal krbtgt to perform operations when user's krbtgt are presented to a different server. This is a lot of work and changes in the KDC, not something we can implement easily. As a first implementation I would restrict read-only replicas to not do Kerberos at all, only LDAP for all the lookup stuff necessary. to add a RO KDC we will need to plan a lot of changes in the KDC. We will also need intelligent partial replication where the rules about which object (and which attributes in the object) need/can be replicated are established based on some grouping+filter mechanism. This also is a pretty important change to 389ds. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Mar 13 00:13:01 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 Mar 2012 20:13:01 -0400 Subject: [Freeipa-devel] More types of replica in FreeIPA In-Reply-To: <1331590243.9238.113.camel@willson.li.ssimo.org> References: <4F4E41FC.6020606@redhat.com> <1330529763.25597.55.camel@willson.li.ssimo.org> <4F4F7A71.7060708@redhat.com> <4F52AA32.5070200@redhat.com> <1330896212.26197.32.camel@willson.li.ssimo.org> <4F5633AE.2090102@redhat.com> <1331049562.26197.82.camel@willson.li.ssimo.org> <4F563F8F.5080504@redhat.com> <4F5657B8.6080409@redhat.com> <4F58D620.90107@redhat.com> <4F5E50AF.5090701@redhat.com> <1331583365.9238.105.camel@willson.li.ssimo.org> <4F5E6D5E.2080807@redhat.com> <1331590243.9238.113.camel@willson.li.ssimo.org> Message-ID: <4F5E910D.3080604@redhat.com> On 03/12/2012 06:10 PM, Simo Sorce wrote: > On Mon, 2012-03-12 at 17:40 -0400, Dmitri Pal wrote: >> On 03/12/2012 04:16 PM, Simo Sorce wrote: >>> On Mon, 2012-03-12 at 20:38 +0100, Ondrej Hamada wrote: >>>> USER'S operations when connection is OK: >>>> ------------------------------------------------------- >>>> read data -> local >>>> write data -> forwarding to master >>>> authentication: >>>> -credentials cached -- authenticate against credentials in local cache >>>> -on failure: log failure locally, update >>>> data >>>> about failures only on lock-down of account >>>> -credentials not cached -- forward request to master, on success >>>> cache >>>> the credentials >>>> >>> This scheme doesn't work with Kerberos. >>> Either you have a copy of the user's keys locally or you don't, there is >>> nothing you can really cache if you don't. >>> >>> Simo. >>> >> Yes this is what we are talking about here - the cache would have to >> contain user Kerberos key but there should be some expiration on the >> cache so that fetched and stored keys periodically cleaned following the >> policy an admin has defined. > We would need a mechanism to transfer Kerberos keys, but that would not > be sufficient, you'd have to give read-only servers also the realm > krbtgt in order to be able to do anything with those keys. > > The way MS solves hits (I think) is by giving a special RODC krbtgt to > each RODC, and then replicating all RODC krbtgt's with full domain > controllers. Full domain controllers have logic to use RODC's krbtgt > keys instead of the normal krbtgt to perform operations when user's > krbtgt are presented to a different server. This is a lot of work and > changes in the KDC, not something we can implement easily. > > As a first implementation I would restrict read-only replicas to not do > Kerberos at all, only LDAP for all the lookup stuff necessary. to add a > RO KDC we will need to plan a lot of changes in the KDC. > > We will also need intelligent partial replication where the rules about > which object (and which attributes in the object) need/can be replicated > are established based on some grouping+filter mechanism. This also is a > pretty important change to 389ds. > > Simo. > I agree. I am just trying to structure the discussion a bit so that all what you are saying can be captured in the design document and then we can pick a subset of what Ondrej will actually implement. So let us capture all the complexity and then do a POC for just LDAP part. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Tue Mar 13 07:35:50 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Mar 2012 08:35:50 +0100 Subject: [Freeipa-devel] [PATCH] 984 fix anonlimits dn In-Reply-To: <4F5E716D.6080205@redhat.com> References: <4F57E907.8060104@redhat.com> <1331223729.11911.14.camel@balmora.brq.redhat.com> <4F5E716D.6080205@redhat.com> Message-ID: <1331624150.24319.1.camel@balmora.brq.redhat.com> On Mon, 2012-03-12 at 17:58 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Wed, 2012-03-07 at 18:02 -0500, Rob Crittenden wrote: > >> The value of nsslapd-anonlimitsdn wasn't being set properly because it > >> wasn't quoted. This will fix it, replacing whatever is there with a > >> correct value. > >> > >> rob > > > > The IPA anonlimits DN is now set correctly. However anonlimits in > > cn=anonymous-limits,cn=etc,SUFFIX are still empty (nsSizeLimit and > > nsLookThroughLimit values defined in 10-config.update are not set). > > > > Martin > > > > These are operational attributes, did you have them in the attribute > list of your query? > > $ ldapsearch -LLL -x -b cn=anonymous-limits,cn=etc,dc=example,dc=com > nssizelimit nslookthroughlimit > dn: cn=anonymous-limits,cn=etc,dc=example,dc=com > nssizelimit: 5000 > nslookthroughlimit: 5000 > > rob Ah, thanks for explanation. These are indeed operational attributes and need to be queried explicitly. Works for me, ACK. Pushed to master, ipa-2-2. Martin From pspacek at redhat.com Tue Mar 13 09:54:42 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Mar 2012 10:54:42 +0100 Subject: [Freeipa-devel] [PATCH] 227-228 Add last missing bits in new bind-dyndb-ldap In-Reply-To: <4F5E3C1E.9060501@redhat.com> References: <1330604359.4451.18.camel@balmora.brq.redhat.com> <1331132781.22847.4.camel@balmora.brq.redhat.com> <4F5E3C1E.9060501@redhat.com> Message-ID: <4F5F1962.6050707@redhat.com> On 03/12/2012 07:10 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On Thu, 2012-03-01 at 13:19 +0100, Martin Kosek wrote: >>> These 2 patches changes the DNS API to support the last missing bits in >>> new bind-dyndb-ldap: >>> >>> 1) Both global and per-zone forwarders now support a conditional custom >>> port (with format "IP_ADDRESS PORT") >>> 2) Missing global configuration options have been added: >>> * idnsforwardpolicy: Default policy for conditional forwarding >>> * idnsallowsyncptr: Allow globaly PTR synchronization for dynamic >>> updates >>> * idnszonerefresh: Default interval between regular polls of the >>> name server for new DNS zones >>> >>> Before these patches are pushed, I will just have to update the minimal >>> bind-dyndb-ldap version (it has not been built yet) which have a full >>> support for these. >>> >>> Martin >> >> New version of bind-dyndb-ldap has been released, attaching a rebased >> patch with fixed bind-dyndb-ldap version in spec file. >> >> I also fixed the forwarder format, it should be "$IP port $PORT", not >> "$IP $PORT" as it was in a previous version of the patch. I tested this >> new format with bind-dyndb-ldap it forwards the queries properly. >> >> Unfortunately, fixed version of bind have not been released yet, i.e. >> bind will crash if forwarders are defined both in named.conf and LDAP >> global configuration (dnsconfig-mod). >> >> Martin > > The patch itself looks ok, just a couple of general concerns: > > 1. By default dnsconfig-show displays nothing. This is a little > disconcerting. I don't believe we show empty attributes anywhere else, > not sure if we should make an exception here or show some other message, > perhaps a varying summary? > > 2. I don't think there is a lot we can do but this still conflicts with > the file-based configuration. For example, someone can add a forwarder > and caused named to not restart the next time because there is also one > defined in named.conf. I'd almost prefer that one win rather than the > daemon not start at all. But for our purposes people may get confused > because they don't see the forwarders they configured at install time > and merely managing this list can break your name server at some > undetermined future point. > > rob This problem is in BZ https://bugzilla.redhat.com/show_bug.cgi?id=795414 . Patch for this is ON_QA in RHEL6 and will be pushed to Fedora at some point this week. (This Adam said yesterday on IRC.) Current solution prefers value from LDAP before local configuration. Petr^2 Spacek From mkosek at redhat.com Tue Mar 13 09:57:51 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Mar 2012 10:57:51 +0100 Subject: [Freeipa-devel] [PATCH] 982 tweak to no_init patch In-Reply-To: <4F57D835.7020605@redhat.com> References: <4F57D835.7020605@redhat.com> Message-ID: <1331632671.24319.8.camel@balmora.brq.redhat.com> On Wed, 2012-03-07 at 16:50 -0500, Rob Crittenden wrote: > I discovered today that cert-request was failing with an untrusted CA error. > > The problem had to do with the NSS no_init patch. We were setting dbdir > in the connection object too soon so it was comparing itself to itself > and always determined that NSS was initialized just fine. This needs to > be moved after the check. > > To test this you need a master, a replica and a client with DNS set up > and SRV records for both servers. > > You need two or more servers so we run the ping() test. This is where > the client was failing before. What would happen is this: > > - initialize NSS > - run ping() against a server > - prepare request > - initialize NSS > - FAIL > > That second initialization isn't needed and is correctly caught by the > code with this patch. > > You need to test that a client enrollment works and that ipa > cert-request works. > > cert-request was failing because we initialize NSS with nodb so we can > load the CSR for validation. Because dbdir was set too early in the > connection we were getting no_init set improperly and nss_shutdown() > wasn't being called. > > rob Works for me, ACK. Please enhance testing instructions in the ticket. I had some issues reproducing the problem myself, but your advice sent off-list helped me. This should be enough. Martin From pviktori at redhat.com Tue Mar 13 11:23:37 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 13 Mar 2012 12:23:37 +0100 Subject: [Freeipa-devel] [PATCH] 0021 Add CLI tests In-Reply-To: <4F5E5A22.1010109@redhat.com> References: <4F575A01.1060501@redhat.com> <4F5E5A22.1010109@redhat.com> Message-ID: <4F5F2E39.2020301@redhat.com> On 03/12/2012 09:18 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> Most of the tests we have check if the server does the right thing with >> XML-RPC calls. How the commandline is converted to command arguments, >> including interactive prompting, is untested. >> This patch adds some tests in this area. To do that I had to break up >> cli.run into more manageable pieces, and initialize the CLI plugins in >> test mode. >> >> Also I added nose's --nocapture option to the make-test script. With >> this it's possible to use pdb.set_trace() to drop into a debugger while >> running the tests. >> >> >> I went ahead and added a test for ticket 2484, fixed in Martin's patch >> 231 (Ignore case in yes/no prompts). >> > > John had done similar work with --nocapture a while back but it is still > pending. Perhaps we can merge his changes in with yours, they look > largely overlapping. His patch is [PATCH 54/54] ticet 2135 - enhance > make-test for debugging > > rob I guess it'll be better to make that a separate patch, then. This updated patch doesn't contain the make-test change. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0021-02-Add-CLI-parsing-tests.patch Type: text/x-patch Size: 8779 bytes Desc: not available URL: From abokovoy at redhat.com Tue Mar 13 11:26:56 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 13 Mar 2012 13:26:56 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Cross-realm trusts with AD Message-ID: <20120313112656.GF4744@redhat.com> Hi, at http://fedorapeople.org/gitweb?p=abbra/public_git/freeipa.git;a=shortlog;h=refs/heads/adwork one can find current state of AD trusts work. This tree introduces 'ipa trust-*' family of commands and freeipa-server-trust-ad package to pull-in additional dependencies after install in order to make 'ipa trust-add-ad' working. You'll need samba4-4.0.0-102alpha18 from ipa-devel repository to get trusts working. There are dragons, however, so beware of possible issues: 1. Make sure you have set up properly domain forwarder to your Active Directory DNS server so that SRV records resolving would work from IPA server side. One can do it with a simple configuration in BIND, for example: zone "ad.local" { type forward; forward only; forwarders { 192.168.111.207; }; check-names ignore; }; You'd need to do the same on Windows side as well. 2. samba4 4.0.0-102alpha18 has one minor bug in systemd service (https://fedorahosted.org/freeipa/ticket/2523), you'd need to add ExecStartPre=/bin/mkdir -p /run/samba before ExecStart= stanza to get it working with tmpfs-based /run in Fedora 17. 3. Once everything is ready, one needs to run ipa-adtrust-install to set up our domain and Samba configuration. ipa-adtrust-install Answer its questions (defaults are fine) and after it has finished, there should be smbd processes running. 4. kinit again to re-generate your ticket with MS PAC included. 5. There is issue in MIT kerberos related to s4u2proxy handling of MS PAC data when comparing the principals. This issue essentially forbids using s4u2proxy functionality with IPA as soon as kerberos ticket contains MS PAC. To get around, one need to always specify --delegate option to 'ipa' command. 6. Run ipa trust-add-ad --admin --password 'ipa trust-add-ad' will ask you for trusted domain's administrator's password and then will do discovery of domain controller using SRV records in trusted domain DNS, set up remote half of the trust and later will attempt to setup local part of the trust. Here is example of use: # ipa --delegate trust-add-ad ad.local --admin Administrator --password Password of the realm's administrator: ------------------------------------------------- Added Active Directory trust for realm "ad.local" ------------------------------------------------- # ipa --delegate trust-show ad.local Realm name: ad.local Domain NetBIOS name: AD Trust direction: Both directions Trust type: Cross-Forest -- / Alexander Bokovoy From pviktori at redhat.com Tue Mar 13 12:43:42 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 13 Mar 2012 13:43:42 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased) In-Reply-To: <1331572254.1491.78.camel@balmora.brq.redhat.com> References: <4F58D6E8.7040202@redhat.com> <1331555217.1491.31.camel@balmora.brq.redhat.com> <4F5DFC4C.1080906@redhat.com> <1331564466.1491.57.camel@balmora.brq.redhat.com> <4F5E2075.2090906@redhat.com> <1331572254.1491.78.camel@balmora.brq.redhat.com> Message-ID: <4F5F40FE.1030606@redhat.com> On 03/12/2012 06:10 PM, Martin Kosek wrote: > On Mon, 2012-03-12 at 17:12 +0100, Petr Viktorin wrote: >> On 03/12/2012 04:01 PM, Martin Kosek wrote: >>> On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: >>>> On 03/12/2012 01:26 PM, Martin Kosek wrote: >>>>> On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: >>>>>> Since sudo commands are case-sensitive, we can't use the CN as the RDN. >>>>>> With this patch, the UUID is used instead. >>>>>> It seems like a too easy fix. What am I missing? >>>>>> >>>>>> As far as I understand, the fact that the DN has a different structure >>>>>> now shouldn't cause problems, even if there still are commands created >>>>>> by old IPA versions. >>>>>> For testing, use an unpatched version to create a few of these. >>>>>> >>>>>> The sudo commands are no longer sorted in sudocmd-find output. Doing >>>>>> that would require the ability to use an arbitrary attribute as sort >>>>>> key. Should I file an issue for that? >>>>> >>>>> I don't think that's necessary. We sort by LDAP object's primary key and >>>>> since new SUDO commands still have sudocmd as its primary key, the >>>>> sorting should just work (at least it does for me). >>>> >>>> Right, sorry for the noise. >>>> >>>>>> >>>>>> Tests for the case sensitivity are included. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/2482 >>>>> >>>>> This works pretty fine. Both my old client tests and sudoers compat tree >>>>> tests looks good. So, cautious ACK from me. >>>>> >>>>> Martin >>>>> >>>> >>>> The attached version is rebased against my patch 20. >>>> >>> >>> Ah, I found an issue with the changed RDN attribute. We crash when I >>> delete sudocmd that sudorule has enrolled as a member: >>> >>> # ipa sudocmd-add bar1 >>> # ipa sudocmd-add bar2 >>> # ipa sudorule-add foo >>> # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 >>> # ipa sudocmd-del bar2 >>> # ipa sudorule-find >>> ipa: ERROR: an internal error has occurred >>> >>> /var/log/httpd/error_log: >>> [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): >>> [Mon Mar 12 10:41:24 2012] [error] File >>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 315, >>> in wsgi_execute >>> [Mon Mar 12 10:41:24 2012] [error] result = >>> self.Command[name](*args, **options) >>> [Mon Mar 12 10:41:24 2012] [error] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in >>> __call__ >>> [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) >>> [Mon Mar 12 10:41:24 2012] [error] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run >>> [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, >>> **options) >>> [Mon Mar 12 10:41:24 2012] [error] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line >>> 1866, in execute >>> [Mon Mar 12 10:41:24 2012] [error] >>> self.obj.convert_attribute_members(e[1], *args, **options) >>> [Mon Mar 12 10:41:24 2012] [error] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line >>> 518, in convert_attribute_members >>> [Mon Mar 12 10:41:24 2012] [error] >>> ldap_obj.get_primary_key_from_dn(member) >>> [Mon Mar 12 10:41:24 2012] [error] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line >>> 490, in get_primary_key_from_dn >>> [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] >>> [Mon Mar 12 10:41:24 2012] [error] File >>> "/usr/lib/python2.7/site-packages/ipalib/dn.py", line 1137, in >>> __getitem__ >>> [Mon Mar 12 10:41:24 2012] [error] raise KeyError("\\"%s\\" not >>> found in %s" % (key, self. __str__())) >>> >>> >>> The problem is in this function: >>> def get_primary_key_from_dn(self, dn): >>> try: >>> if self.rdn_attribute: >>> (dn, entry_attrs) = self.backend.get_entry( >>> dn, [self.primary_key.name] >>> ) >>> try: >>> return entry_attrs[self.primary_key.name][0] >>> except (KeyError, IndexError): >>> return '' >>> except errors.NotFound: >>> pass >>> # DN object assures we're returning a decoded (unescaped) value >>> dn = DN(dn) >>> return dn[self.primary_key.name] >>> >>> Martin >>> >> >> Should sudocmd-del should also delete the command from any rules the >> command is in? > > I would rather prevent deleting it when it is any sudorule to avoid > unpleasant user surprises. > >> >> That function needs to be fixed either way. But I'm not sure what it >> should do if the entry doesn't exist. Return the full DN instead? >> > > Probably, as this is the only value we know at the moment - it certainly > should not crash. Although DN with ipaUniqueID won't be very helpful. A > precaution I suggested above should prevent that. > > Martin > Here is a partial patch to do that, I'll squash after addressing the ACI problem. If you have time I'd welcome comments on this. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0022-partial.patch Type: text/x-patch Size: 4094 bytes Desc: not available URL: From dpal at redhat.com Tue Mar 13 12:48:09 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Mar 2012 08:48:09 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] Cross-realm trusts with AD In-Reply-To: <20120313112656.GF4744@redhat.com> References: <20120313112656.GF4744@redhat.com> Message-ID: <4F5F4209.5010407@redhat.com> On 03/13/2012 07:26 AM, Alexander Bokovoy wrote: > Hi, > > at > http://fedorapeople.org/gitweb?p=abbra/public_git/freeipa.git;a=shortlog;h=refs/heads/adwork > one can find current state of AD trusts work. > > This tree introduces 'ipa trust-*' family of commands and > freeipa-server-trust-ad package to pull-in additional dependencies > after install in order to make 'ipa trust-add-ad' working. > > You'll need samba4-4.0.0-102alpha18 from ipa-devel repository to get > trusts working. There are dragons, however, so beware of possible > issues: > > 1. Make sure you have set up properly domain forwarder to your Active > Directory DNS server so that SRV records resolving would work from IPA > server side. > > One can do it with a simple configuration in BIND, for example: > zone "ad.local" { > type forward; > forward only; > forwarders { 192.168.111.207; }; > check-names ignore; > }; > > You'd need to do the same on Windows side as well. > > 2. samba4 4.0.0-102alpha18 has one minor bug in systemd service > (https://fedorahosted.org/freeipa/ticket/2523), you'd need to add > > ExecStartPre=/bin/mkdir -p /run/samba > > before ExecStart= stanza to get it working with tmpfs-based /run in > Fedora 17. > > 3. Once everything is ready, one needs to run ipa-adtrust-install to > set up our domain and Samba configuration. > > ipa-adtrust-install > > Answer its questions (defaults are fine) and after it has finished, > there should be smbd processes running. > > 4. kinit again to re-generate your ticket with MS PAC included. > > 5. There is issue in MIT kerberos related to s4u2proxy handling of MS > PAC data when comparing the principals. This issue essentially forbids > using s4u2proxy functionality with IPA as soon as kerberos ticket > contains MS PAC. To get around, one need to always specify --delegate > option to 'ipa' command. > What is our plan to address this issue? The workaround does not seem to be good enough for a release. > 6. Run > > ipa trust-add-ad --admin --password > > 'ipa trust-add-ad' will ask you for trusted domain's administrator's > password and then will do discovery of domain controller using SRV > records in trusted domain DNS, set up remote half of the trust and > later will attempt to setup local part of the trust. > > > Here is example of use: > # ipa --delegate trust-add-ad ad.local --admin Administrator --password > Password of the realm's administrator: > ------------------------------------------------- > Added Active Directory trust for realm "ad.local" > ------------------------------------------------- > # ipa --delegate trust-show ad.local > Realm name: ad.local > Domain NetBIOS name: AD > Trust direction: Both directions > Trust type: Cross-Forest > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Tue Mar 13 12:56:30 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 13 Mar 2012 14:56:30 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Cross-realm trusts with AD In-Reply-To: <4F5F4209.5010407@redhat.com> References: <20120313112656.GF4744@redhat.com> <4F5F4209.5010407@redhat.com> Message-ID: <20120313125630.GG4744@redhat.com> On Tue, 13 Mar 2012, Dmitri Pal wrote: > On 03/13/2012 07:26 AM, Alexander Bokovoy wrote: > > Hi, > > > > at > > http://fedorapeople.org/gitweb?p=abbra/public_git/freeipa.git;a=shortlog;h=refs/heads/adwork > > one can find current state of AD trusts work. > > > > This tree introduces 'ipa trust-*' family of commands and > > freeipa-server-trust-ad package to pull-in additional dependencies > > after install in order to make 'ipa trust-add-ad' working. > > > > You'll need samba4-4.0.0-102alpha18 from ipa-devel repository to get > > trusts working. There are dragons, however, so beware of possible > > issues: > > > > 1. Make sure you have set up properly domain forwarder to your Active > > Directory DNS server so that SRV records resolving would work from IPA > > server side. > > > > One can do it with a simple configuration in BIND, for example: > > zone "ad.local" { > > type forward; > > forward only; > > forwarders { 192.168.111.207; }; > > check-names ignore; > > }; > > > > You'd need to do the same on Windows side as well. > > > > 2. samba4 4.0.0-102alpha18 has one minor bug in systemd service > > (https://fedorahosted.org/freeipa/ticket/2523), you'd need to add > > > > ExecStartPre=/bin/mkdir -p /run/samba > > > > before ExecStart= stanza to get it working with tmpfs-based /run in > > Fedora 17. > > > > 3. Once everything is ready, one needs to run ipa-adtrust-install to > > set up our domain and Samba configuration. > > > > ipa-adtrust-install > > > > Answer its questions (defaults are fine) and after it has finished, > > there should be smbd processes running. > > > > 4. kinit again to re-generate your ticket with MS PAC included. > > > > 5. There is issue in MIT kerberos related to s4u2proxy handling of MS > > PAC data when comparing the principals. This issue essentially forbids > > using s4u2proxy functionality with IPA as soon as kerberos ticket > > contains MS PAC. To get around, one need to always specify --delegate > > option to 'ipa' command. > > > > What is our plan to address this issue? > The workaround does not seem to be good enough for a release. Simo works on https://fedorahosted.org/freeipa/ticket/2504 for this sprint. -- / Alexander Bokovoy From simo at redhat.com Tue Mar 13 13:35:47 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Mar 2012 09:35:47 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] Cross-realm trusts with AD In-Reply-To: <20120313112656.GF4744@redhat.com> References: <20120313112656.GF4744@redhat.com> Message-ID: <1331645747.9238.131.camel@willson.li.ssimo.org> On Tue, 2012-03-13 at 13:26 +0200, Alexander Bokovoy wrote: > Hi, > > at > http://fedorapeople.org/gitweb?p=abbra/public_git/freeipa.git;a=shortlog;h=refs/heads/adwork > one can find current state of AD trusts work. > > This tree introduces 'ipa trust-*' family of commands and > freeipa-server-trust-ad package to pull-in additional dependencies > after install in order to make 'ipa trust-add-ad' working. > > You'll need samba4-4.0.0-102alpha18 from ipa-devel repository to get > trusts working. There are dragons, however, so beware of possible > issues: > > 1. Make sure you have set up properly domain forwarder to your Active > Directory DNS server so that SRV records resolving would work from IPA > server side. > > One can do it with a simple configuration in BIND, for example: > zone "ad.local" { > type forward; > forward only; > forwarders { 192.168.111.207; }; > check-names ignore; > }; > > You'd need to do the same on Windows side as well. > > 2. samba4 4.0.0-102alpha18 has one minor bug in systemd service > (https://fedorahosted.org/freeipa/ticket/2523), you'd need to add > > ExecStartPre=/bin/mkdir -p /run/samba > > before ExecStart= stanza to get it working with tmpfs-based /run in > Fedora 17. This is wrong. Please add a file in /etc/tmpfiles.d/samba.conf Contents should be: d /var/run/samba 644 root root (adjust permission and ownership accordingly). This file needs to be added to the samba4 package (and the samba3 package as well ?) > 3. Once everything is ready, one needs to run ipa-adtrust-install to > set up our domain and Samba configuration. > > ipa-adtrust-install > > Answer its questions (defaults are fine) and after it has finished, > there should be smbd processes running. > > 4. kinit again to re-generate your ticket with MS PAC included. > > 5. There is issue in MIT kerberos related to s4u2proxy handling of MS > PAC data when comparing the principals. This issue essentially forbids > using s4u2proxy functionality with IPA as soon as kerberos ticket > contains MS PAC. To get around, one need to always specify --delegate > option to 'ipa' command. > > 6. Run > > ipa trust-add-ad --admin --password > > 'ipa trust-add-ad' will ask you for trusted domain's administrator's > password and then will do discovery of domain controller using SRV > records in trusted domain DNS, set up remote half of the trust and > later will attempt to setup local part of the trust. > > > Here is example of use: > # ipa --delegate trust-add-ad ad.local --admin Administrator --password > Password of the realm's administrator: > ------------------------------------------------- > Added Active Directory trust for realm "ad.local" > ------------------------------------------------- > # ipa --delegate trust-show ad.local > Realm name: ad.local > Domain NetBIOS name: AD > Trust direction: Both directions > Trust type: Cross-Forest > > > -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Mar 13 13:42:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Mar 2012 14:42:49 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased) In-Reply-To: <4F5F40FE.1030606@redhat.com> References: <4F58D6E8.7040202@redhat.com> <1331555217.1491.31.camel@balmora.brq.redhat.com> <4F5DFC4C.1080906@redhat.com> <1331564466.1491.57.camel@balmora.brq.redhat.com> <4F5E2075.2090906@redhat.com> <1331572254.1491.78.camel@balmora.brq.redhat.com> <4F5F40FE.1030606@redhat.com> Message-ID: <1331646169.24319.11.camel@balmora.brq.redhat.com> On Tue, 2012-03-13 at 13:43 +0100, Petr Viktorin wrote: > On 03/12/2012 06:10 PM, Martin Kosek wrote: > > On Mon, 2012-03-12 at 17:12 +0100, Petr Viktorin wrote: > >> On 03/12/2012 04:01 PM, Martin Kosek wrote: > >>> On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: > >>>> On 03/12/2012 01:26 PM, Martin Kosek wrote: > >>>>> On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: > >>>>>> Since sudo commands are case-sensitive, we can't use the CN as the RDN. > >>>>>> With this patch, the UUID is used instead. > >>>>>> It seems like a too easy fix. What am I missing? > >>>>>> > >>>>>> As far as I understand, the fact that the DN has a different structure > >>>>>> now shouldn't cause problems, even if there still are commands created > >>>>>> by old IPA versions. > >>>>>> For testing, use an unpatched version to create a few of these. > >>>>>> > >>>>>> The sudo commands are no longer sorted in sudocmd-find output. Doing > >>>>>> that would require the ability to use an arbitrary attribute as sort > >>>>>> key. Should I file an issue for that? > >>>>> > >>>>> I don't think that's necessary. We sort by LDAP object's primary key and > >>>>> since new SUDO commands still have sudocmd as its primary key, the > >>>>> sorting should just work (at least it does for me). > >>>> > >>>> Right, sorry for the noise. > >>>> > >>>>>> > >>>>>> Tests for the case sensitivity are included. > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/2482 > >>>>> > >>>>> This works pretty fine. Both my old client tests and sudoers compat tree > >>>>> tests looks good. So, cautious ACK from me. > >>>>> > >>>>> Martin > >>>>> > >>>> > >>>> The attached version is rebased against my patch 20. > >>>> > >>> > >>> Ah, I found an issue with the changed RDN attribute. We crash when I > >>> delete sudocmd that sudorule has enrolled as a member: > >>> > >>> # ipa sudocmd-add bar1 > >>> # ipa sudocmd-add bar2 > >>> # ipa sudorule-add foo > >>> # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 > >>> # ipa sudocmd-del bar2 > >>> # ipa sudorule-find > >>> ipa: ERROR: an internal error has occurred > >>> > >>> /var/log/httpd/error_log: > >>> [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): > >>> [Mon Mar 12 10:41:24 2012] [error] File > >>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 315, > >>> in wsgi_execute > >>> [Mon Mar 12 10:41:24 2012] [error] result = > >>> self.Command[name](*args, **options) > >>> [Mon Mar 12 10:41:24 2012] [error] File > >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in > >>> __call__ > >>> [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) > >>> [Mon Mar 12 10:41:24 2012] [error] File > >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run > >>> [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, > >>> **options) > >>> [Mon Mar 12 10:41:24 2012] [error] File > >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > >>> 1866, in execute > >>> [Mon Mar 12 10:41:24 2012] [error] > >>> self.obj.convert_attribute_members(e[1], *args, **options) > >>> [Mon Mar 12 10:41:24 2012] [error] File > >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > >>> 518, in convert_attribute_members > >>> [Mon Mar 12 10:41:24 2012] [error] > >>> ldap_obj.get_primary_key_from_dn(member) > >>> [Mon Mar 12 10:41:24 2012] [error] File > >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > >>> 490, in get_primary_key_from_dn > >>> [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] > >>> [Mon Mar 12 10:41:24 2012] [error] File > >>> "/usr/lib/python2.7/site-packages/ipalib/dn.py", line 1137, in > >>> __getitem__ > >>> [Mon Mar 12 10:41:24 2012] [error] raise KeyError("\\"%s\\" not > >>> found in %s" % (key, self. __str__())) > >>> > >>> > >>> The problem is in this function: > >>> def get_primary_key_from_dn(self, dn): > >>> try: > >>> if self.rdn_attribute: > >>> (dn, entry_attrs) = self.backend.get_entry( > >>> dn, [self.primary_key.name] > >>> ) > >>> try: > >>> return entry_attrs[self.primary_key.name][0] > >>> except (KeyError, IndexError): > >>> return '' > >>> except errors.NotFound: > >>> pass > >>> # DN object assures we're returning a decoded (unescaped) value > >>> dn = DN(dn) > >>> return dn[self.primary_key.name] > >>> > >>> Martin > >>> > >> > >> Should sudocmd-del should also delete the command from any rules the > >> command is in? > > > > I would rather prevent deleting it when it is any sudorule to avoid > > unpleasant user surprises. > > > >> > >> That function needs to be fixed either way. But I'm not sure what it > >> should do if the entry doesn't exist. Return the full DN instead? > >> > > > > Probably, as this is the only value we know at the moment - it certainly > > should not crash. Although DN with ipaUniqueID won't be very helpful. A > > precaution I suggested above should prevent that. > > > > Martin > > > > Here is a partial patch to do that, I'll squash after addressing the ACI > problem. If you have time I'd welcome comments on this. > Yup, the approach looks OK. I just think you don't have to create a new error for this purpose but just use errors.DependentEntry that is already used for the same purpose in hbacrule.py (selinuxusermaps are checked if they don't point to the deleted hbacrule). Martin From pviktori at redhat.com Tue Mar 13 17:17:59 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 13 Mar 2012 18:17:59 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased) In-Reply-To: <1331567074.1491.63.camel@balmora.brq.redhat.com> References: <4F58D6E8.7040202@redhat.com> <1331555217.1491.31.camel@balmora.brq.redhat.com> <4F5DFC4C.1080906@redhat.com> <1331564466.1491.57.camel@balmora.brq.redhat.com> <1331567074.1491.63.camel@balmora.brq.redhat.com> Message-ID: <4F5F8147.7080306@redhat.com> On 03/12/2012 04:44 PM, Martin Kosek wrote: > On Mon, 2012-03-12 at 16:01 +0100, Martin Kosek wrote: >> On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: >>> On 03/12/2012 01:26 PM, Martin Kosek wrote: >>>> On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: >>>>> Since sudo commands are case-sensitive, we can't use the CN as the RDN. >>>>> With this patch, the UUID is used instead. >>>>> It seems like a too easy fix. What am I missing? >>>>> >>>>> As far as I understand, the fact that the DN has a different structure >>>>> now shouldn't cause problems, even if there still are commands created >>>>> by old IPA versions. >>>>> For testing, use an unpatched version to create a few of these. >>>>> >>>>> The sudo commands are no longer sorted in sudocmd-find output. Doing >>>>> that would require the ability to use an arbitrary attribute as sort >>>>> key. Should I file an issue for that? >>>> >>>> I don't think that's necessary. We sort by LDAP object's primary key and >>>> since new SUDO commands still have sudocmd as its primary key, the >>>> sorting should just work (at least it does for me). >>> >>> Right, sorry for the noise. >>> >>>>> >>>>> Tests for the case sensitivity are included. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2482 >>>> >>>> This works pretty fine. Both my old client tests and sudoers compat tree >>>> tests looks good. So, cautious ACK from me. >>>> >>>> Martin >>>> >>> >>> The attached version is rebased against my patch 20. >>> >> >> Ah, I found an issue with the changed RDN attribute. We crash when I >> delete sudocmd that sudorule has enrolled as a member: >> >> # ipa sudocmd-add bar1 >> # ipa sudocmd-add bar2 >> # ipa sudorule-add foo >> # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 >> # ipa sudocmd-del bar2 >> # ipa sudorule-find >> ipa: ERROR: an internal error has occurred >> >> /var/log/httpd/error_log: >> [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): >> [Mon Mar 12 10:41:24 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 315, >> in wsgi_execute >> [Mon Mar 12 10:41:24 2012] [error] result = >> self.Command[name](*args, **options) >> [Mon Mar 12 10:41:24 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in >> __call__ >> [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) >> [Mon Mar 12 10:41:24 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run >> [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, >> **options) >> [Mon Mar 12 10:41:24 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line >> 1866, in execute >> [Mon Mar 12 10:41:24 2012] [error] >> self.obj.convert_attribute_members(e[1], *args, **options) >> [Mon Mar 12 10:41:24 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line >> 518, in convert_attribute_members >> [Mon Mar 12 10:41:24 2012] [error] >> ldap_obj.get_primary_key_from_dn(member) >> [Mon Mar 12 10:41:24 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line >> 490, in get_primary_key_from_dn >> [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] >> [Mon Mar 12 10:41:24 2012] [error] File >> "/usr/lib/python2.7/site-packages/ipalib/dn.py", line 1137, in >> __getitem__ >> [Mon Mar 12 10:41:24 2012] [error] raise KeyError("\\"%s\\" not >> found in %s" % (key, self. __str__())) >> >> >> The problem is in this function: >> def get_primary_key_from_dn(self, dn): >> try: >> if self.rdn_attribute: >> (dn, entry_attrs) = self.backend.get_entry( >> dn, [self.primary_key.name] >> ) >> try: >> return entry_attrs[self.primary_key.name][0] >> except (KeyError, IndexError): >> return '' >> except errors.NotFound: >> pass >> # DN object assures we're returning a decoded (unescaped) value >> dn = DN(dn) >> return dn[self.primary_key.name] >> >> Martin >> > > I found one more issue, this one is more serious (I am glad my hunch was > not malfunctioning). This patch breaks ACIs for sudocmd, user with > appropriate privilege will no longer be able to add/modify/delete sudo > commands: > > # kinit fbar > Password for fbar at IDM.LAB.BOS.REDHAT.COM: > # ipa sudorule-add fbar > ---------------------- > Added Sudo Rule "fbar" > ---------------------- > Rule name: fbar > Enabled: TRUE > # ipa sudorule-del fbar > ------------------------ > Deleted Sudo Rule "fbar" > ------------------------ > # ipa sudocmd-add fbar1 > ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the > entry > 'ipaUniqueID=c68b98ae-6c58-11e1-be75-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. > # ipa sudocmd-del sudocmd1 > ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to > delete the entry > 'ipaUniqueID=0c7659d4-6c50-11e1-9b18-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. > # ipa sudocmd-mod sudocmd1 --desc=foo > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > 'description' attribute of entry > 'ipauniqueid=0c7659d4-6c50-11e1-9b18-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' > Rob, I heard you're the ACI expert around here. We can change the permission subtree to ldap:///*=*,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com which would work (*if* an upgrade goes smoothly). Or do a target filter, but if I understand correctly, IPA permissions can't work with those so we'd have to make sure those don't misbehave. Or drop the entire patch for the upcoming release, and leave Sudo commands case insensitive. (There's potentially a security issue here. Sudo commands are not just the names of the binaries, but also their arguments.) -- Petr? From mkosek at redhat.com Tue Mar 13 19:10:20 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Mar 2012 20:10:20 +0100 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased) In-Reply-To: <4F5F8147.7080306@redhat.com> References: <4F58D6E8.7040202@redhat.com> <1331555217.1491.31.camel@balmora.brq.redhat.com> <4F5DFC4C.1080906@redhat.com> <1331564466.1491.57.camel@balmora.brq.redhat.com> <1331567074.1491.63.camel@balmora.brq.redhat.com> <4F5F8147.7080306@redhat.com> Message-ID: <1331665820.3678.3.camel@priserak> On Tue, 2012-03-13 at 18:17 +0100, Petr Viktorin wrote: > On 03/12/2012 04:44 PM, Martin Kosek wrote: > > On Mon, 2012-03-12 at 16:01 +0100, Martin Kosek wrote: > >> On Mon, 2012-03-12 at 14:38 +0100, Petr Viktorin wrote: > >>> On 03/12/2012 01:26 PM, Martin Kosek wrote: > >>>> On Thu, 2012-03-08 at 16:57 +0100, Petr Viktorin wrote: > >>>>> Since sudo commands are case-sensitive, we can't use the CN as the RDN. > >>>>> With this patch, the UUID is used instead. > >>>>> It seems like a too easy fix. What am I missing? > >>>>> > >>>>> As far as I understand, the fact that the DN has a different structure > >>>>> now shouldn't cause problems, even if there still are commands created > >>>>> by old IPA versions. > >>>>> For testing, use an unpatched version to create a few of these. > >>>>> > >>>>> The sudo commands are no longer sorted in sudocmd-find output. Doing > >>>>> that would require the ability to use an arbitrary attribute as sort > >>>>> key. Should I file an issue for that? > >>>> > >>>> I don't think that's necessary. We sort by LDAP object's primary key and > >>>> since new SUDO commands still have sudocmd as its primary key, the > >>>> sorting should just work (at least it does for me). > >>> > >>> Right, sorry for the noise. > >>> > >>>>> > >>>>> Tests for the case sensitivity are included. > >>>>> > >>>>> https://fedorahosted.org/freeipa/ticket/2482 > >>>> > >>>> This works pretty fine. Both my old client tests and sudoers compat tree > >>>> tests looks good. So, cautious ACK from me. > >>>> > >>>> Martin > >>>> > >>> > >>> The attached version is rebased against my patch 20. > >>> > >> > >> Ah, I found an issue with the changed RDN attribute. We crash when I > >> delete sudocmd that sudorule has enrolled as a member: > >> > >> # ipa sudocmd-add bar1 > >> # ipa sudocmd-add bar2 > >> # ipa sudorule-add foo > >> # ipa sudorule-add-allow-command foo --sudocmds=bar1,bar2 > >> # ipa sudocmd-del bar2 > >> # ipa sudorule-find > >> ipa: ERROR: an internal error has occurred > >> > >> /var/log/httpd/error_log: > >> [Mon Mar 12 10:41:24 2012] [error] Traceback (most recent call last): > >> [Mon Mar 12 10:41:24 2012] [error] File > >> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 315, > >> in wsgi_execute > >> [Mon Mar 12 10:41:24 2012] [error] result = > >> self.Command[name](*args, **options) > >> [Mon Mar 12 10:41:24 2012] [error] File > >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in > >> __call__ > >> [Mon Mar 12 10:41:24 2012] [error] ret = self.run(*args, **options) > >> [Mon Mar 12 10:41:24 2012] [error] File > >> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in run > >> [Mon Mar 12 10:41:24 2012] [error] return self.execute(*args, > >> **options) > >> [Mon Mar 12 10:41:24 2012] [error] File > >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > >> 1866, in execute > >> [Mon Mar 12 10:41:24 2012] [error] > >> self.obj.convert_attribute_members(e[1], *args, **options) > >> [Mon Mar 12 10:41:24 2012] [error] File > >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > >> 518, in convert_attribute_members > >> [Mon Mar 12 10:41:24 2012] [error] > >> ldap_obj.get_primary_key_from_dn(member) > >> [Mon Mar 12 10:41:24 2012] [error] File > >> "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap. py", line > >> 490, in get_primary_key_from_dn > >> [Mon Mar 12 10:41:24 2012] [error] return dn[self.primary_key.name] > >> [Mon Mar 12 10:41:24 2012] [error] File > >> "/usr/lib/python2.7/site-packages/ipalib/dn.py", line 1137, in > >> __getitem__ > >> [Mon Mar 12 10:41:24 2012] [error] raise KeyError("\\"%s\\" not > >> found in %s" % (key, self. __str__())) > >> > >> > >> The problem is in this function: > >> def get_primary_key_from_dn(self, dn): > >> try: > >> if self.rdn_attribute: > >> (dn, entry_attrs) = self.backend.get_entry( > >> dn, [self.primary_key.name] > >> ) > >> try: > >> return entry_attrs[self.primary_key.name][0] > >> except (KeyError, IndexError): > >> return '' > >> except errors.NotFound: > >> pass > >> # DN object assures we're returning a decoded (unescaped) value > >> dn = DN(dn) > >> return dn[self.primary_key.name] > >> > >> Martin > >> > > > > I found one more issue, this one is more serious (I am glad my hunch was > > not malfunctioning). This patch breaks ACIs for sudocmd, user with > > appropriate privilege will no longer be able to add/modify/delete sudo > > commands: > > > > # kinit fbar > > Password for fbar at IDM.LAB.BOS.REDHAT.COM: > > # ipa sudorule-add fbar > > ---------------------- > > Added Sudo Rule "fbar" > > ---------------------- > > Rule name: fbar > > Enabled: TRUE > > # ipa sudorule-del fbar > > ------------------------ > > Deleted Sudo Rule "fbar" > > ------------------------ > > # ipa sudocmd-add fbar1 > > ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the > > entry > > 'ipaUniqueID=c68b98ae-6c58-11e1-be75-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. > > # ipa sudocmd-del sudocmd1 > > ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to > > delete the entry > > 'ipaUniqueID=0c7659d4-6c50-11e1-9b18-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. > > # ipa sudocmd-mod sudocmd1 --desc=foo > > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > > 'description' attribute of entry > > 'ipauniqueid=0c7659d4-6c50-11e1-9b18-00163e7228ea,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' > > > > Rob, I heard you're the ACI expert around here. > > We can change the permission subtree to > ldap:///*=*,cn=sudocmds,cn=sudo,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > which would work (*if* an upgrade goes smoothly). Or do a target filter, > but if I understand correctly, IPA permissions can't work with those so > we'd have to make sure those don't misbehave. > Or drop the entire patch for the upcoming release, and leave Sudo > commands case insensitive. (There's potentially a security issue here. > Sudo commands are not just the names of the binaries, but also their > arguments.) > I would not call it a security issue. Where do we violate the security? AFAIU, the main issue here is that this bug basically prevents admin from creating 2 sudocmds which differ just in a letter case. It does not mean that our sudoers tree in LDAP or the sudo itself handles sudocmd value in a case insensitive matter. Martin From rcritten at redhat.com Tue Mar 13 20:08:07 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Mar 2012 16:08:07 -0400 Subject: [Freeipa-devel] [PATCH] 233 Fix ipa-replica-manage TLS connection error In-Reply-To: <4F58C5F7.2040907@redhat.com> References: <1331210027.11911.0.camel@balmora.brq.redhat.com> <4F58C5F7.2040907@redhat.com> Message-ID: <4F5FA927.1090705@redhat.com> Rich Megginson wrote: > On 03/08/2012 05:33 AM, Martin Kosek wrote: >> New version of openldap (openldap-2.4.26-6.fc16.x86_64) changed its >> ABI and broke our TLS connection in ipa-replica-manage. This makes >> it impossible to connect for example to Active Directory to set up >> a winsync replication. We always receive a connection error stating >> that Peer's certificate is not recognized even though we pass >> a correct certificate. >> >> This patch fixes the way we set up TLS. The change is backwards >> compatible with older versions of openldap. >> >> https://fedorahosted.org/freeipa/ticket/2500 > ack ACK here too, works fine with old and new openldap. rob From edewata at redhat.com Tue Mar 13 21:54:56 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 13 Mar 2012 16:54:56 -0500 Subject: [Freeipa-devel] [PATCH] 107 Content is no more overwritten by error message In-Reply-To: <4F5A0299.2060006@redhat.com> References: <4F5A0299.2060006@redhat.com> Message-ID: <4F5FC230.40207@redhat.com> On 3/9/2012 7:16 AM, Petr Vobornik wrote: > When an error which caused calling of report_error occur, the content of > a facet got replaced by error message. There was no way how to force the > facet to recreate its content and the facet became unusable. > > This patch creates a container for an error message. On error, > report_error writes its content to error container, content container is > hidden and error container is shown. Older comment in a code suggested > to move the error message to facet's footer. A message in a footer could > be missed by the user and on top of that a footer is sometimes used by > various facet and we would have to solve the same problem again. > > From experience the cause of an error is usually a missing pkey in a > path. Therefore error information suggests user to navigate to top > level. It causes to load default facets with default values so errors in > navigation state shouldn't happen. > > Facet content is displayed back on facet_show. If user tries to display > same object as before facet's need_update() would return false, > therefore need_update was modified to always return true if error is > displayed. > > Also it may be possible to display facet content on refresh success. I > tried to avoid that because it would require putting show_content calls > to various success handlers or load methods. It would add one more thing > developer needs to think of when overriding refresh or load method. > > Reproduction: > 1) display any nested entity - ie DNS record > 2) delete its parent pkey from path - &dnszone-pkey=example.com > 3) reload the page with this path > > https://fedorahosted.org/freeipa/ticket/2449 In the ticket I added 2 more scenarios to reproduce the problem. So we have 3 possible cases: 1. invalid UI state 2. non-existent entry 3. server down For case #1, the patch provides a much better message, but I think ideally if some parameters are missing from the URL (e.g. the parent pkey) it should be detected by the UI before sending the request to the server. This probably should be addressed in a separate ticket. See the note below about the error message. For case #2, the patch fixes the issue by clearing up the error message. This works on all entities except users because the user details page uses a batch operation to get the data and it doesn't handle non-existent users properly. I think this is an existing and separate issue. For case #3, the patch will show a message saying that the UI got into an invalid state, which is actually not the case here. Also, returning to the main page or reloading the page wouldn't solve the problem either. So for this ticket I think it would be better to show a more generic error message, something like this: An error has occured (IPA Error 3007) 'idnsname' is required Please try the following options: * Refresh the page. (see note below) * Return to the main page and retry the operation. * Reload the browser. If the problem persists please contact the system administrator. Each of the above options could be made into a link that does the mentioned operation. It would be great if we can use the Refresh button to clear the error message. If this requires significant effort we probably can remove this option from the message above and add it in a separate ticket. One more thing, this may not be a problem now, but the error_container uses both facet-content and facet-error CSS classes. I understand this is done to avoid code duplication, but this also means the facet will have 2 facet-contents. CSS classes can be used for decorative or structural purposes or both, so we need to make sure decorative changes will not affect it structurally. One solution is to duplicate the CSS code from facet-content into facet-error. Another solution is to use a separate decorative class that are added into both facet-content and facet-error elements. -- Endi S. Dewata From rcritten at redhat.com Tue Mar 13 21:57:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Mar 2012 17:57:33 -0400 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F58D372.4090102@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> <4F1DDA53.6090206@redhat.com> <4F567A19.8070408@redhat.com> <4F57855F.10208@redhat.com> <4F5788E8.4010102@redhat.com> <4F58D372.4090102@redhat.com> Message-ID: <4F5FC2CD.1090201@redhat.com> Jan Cholasta wrote: > On 7.3.2012 17:12, Rob Crittenden wrote: >> Petr Vobornik wrote: >>> On 03/06/2012 09:56 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Dne 18.1.2012 00:04, Rob Crittenden napsal(a): >>>>>>> Jan Cholasta wrote: >>>>>>>> Dne 16.1.2012 22:02, Rob Crittenden napsal(a): >>>>>>>>> Rob Crittenden wrote: >>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>>>>>>>>>>> When viewing a certificate it will show the serial number as >>>>>>>>>>>> hex >>>>>>>>>>>> (dec). >>>>>>>>>>>> >>>>>>>>>>>> # ipa service-show HTTP/rawhide.example.com >>>>>>>>>>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>>>>>>>>>>> Certificate: [snip] >>>>>>>>>>>> Keytab: True >>>>>>>>>>>> Managed by: rawhide.example.com >>>>>>>>>>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>>>>>>>>>>> Serial Number: 0x403 (1027) >>>>>>>>>>>> Issuer: CN=EXAMPLE.COM Certificate Authority >>>>>>>>>>>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>>>>>>>>>>> Not After: Thu Jan 13 15:00:44 2022 UTC >>>>>>>>>>>> Fingerprint (MD5): >>>>>>>>>>>> e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>>>>>>>>>>> Fingerprint (SHA1): >>>>>>>>>>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> NACK >>>>>>>>>>> >>>>>>>>>>> Displaying a host or a service in the webUI fails with "IPA >>>>>>>>>>> error >>>>>>>>>>> 3009: >>>>>>>>>>> invalid 'serial_number': Decimal or hexadecimal number is >>>>>>>>>>> required >>>>>>>>>>> for >>>>>>>>>>> serial number". >>>>>>>>>>> >>>>>>>>>>> I would suggest to do the nifty formatting of serial numbers on >>>>>>>>>>> the >>>>>>>>>>> client side, that would fix the webUI issue, allow non-IPA >>>>>>>>>>> clients to >>>>>>>>>>> parse the number without dissecting the string representation >>>>>>>>>>> of it >>>>>>>>>>> and >>>>>>>>>>> probably also save me a hack in the type conversion overhaul. >>>>>>>>>>> You >>>>>>>>>>> could >>>>>>>>>>> for example add a parameter flag like "format_serial_number" to >>>>>>>>>>> indicate >>>>>>>>>>> to the client that it should format the value as a serial >>>>>>>>>>> number. >>>>>>>>>>> >>>>>>>>>>> Honza >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Well, we want to do as little client formatting as possible. The >>>>>>>>>> idea is >>>>>>>>>> to have a very thin client. >>>>>>>> >>>>>>>> It doesn't seem right to me to enforce this specific >>>>>>>> representation of >>>>>>>> what is really just an integer at the API level. Doing a little >>>>>>>> formatting on the client side won't make the client(s) particularly >>>>>>>> fat, >>>>>>>> will it? >>>>>>> >>>>>>> Yes. The current code just outputs labels and data. There is no >>>>>>> "if it >>>>>>> is this attribute then do that" logic. >>>>>>> >>>>>>>> >>>>>>>> IMHO there is too much stuff done on server that would make more >>>>>>>> sense >>>>>>>> to do on client anyway (especially CLI-specific stuff such as CSV >>>>>>>> parsing). What is the reason we want such a thin client? >>>>>>> >>>>>>> To avoid double work such that every time we want a formatting >>>>>>> change we >>>>>>> have to change it in multiple places. This lesson was learned in v1. >>>>>>> >>>>>>>> I believe there should be clear separation of presentation and >>>>>>>> content, >>>>>>>> but perhaps I'm a little bit too idealistic :-). >>>>>>> >>>>>>> You have a point, serial number is defined as an integer. Perhaps we >>>>>>> should revisit this decision to display hex at all. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> I'll look into fixing the UI side. >>>>>>>>> >>>>>>>>> I don't see this error in services, it displays correctly. I'm not >>>>>>>>> sure >>>>>>>>> if it is my browser or what but hosts don't display much of >>>>>>>>> anything >>>>>>>>> for >>>>>>>>> me. >>>>>>>>> >>>>>>>>> rob >>>>>>>> >>>>>>>> I have just checked both master and ipa-2-2 and I'm getting the >>>>>>>> same >>>>>>>> error message (tested in Firefox 9.0.1) when viewing details of a >>>>>>>> host >>>>>>>> or a service with the usercertificate attribute set. >>>>>>>> >>>>>>>> BTW, wouldn't it make sense to format serial numbers in the cert >>>>>>>> plugin >>>>>>>> in the same way? >>>>>>> >>>>>>> Perhaps. Like I said, I'm not really in favor of this change. >>>>>>> >>>>>>> rob >>>>>> >>>>>> Maybe we can do a compromise of some sort. What about allowing the >>>>>> client to specify with each request what representation/formatting >>>>>> the >>>>>> server should use for the resulting entries and attributes? >>>>> >>>>> That would be mighty flexible but would open a new can of worms. I >>>>> think >>>>> long term I'd like to be able to request what attributes to see (ala >>>>> ldapsearch) but that too is a bit out of scope. >>>>> >>>>> This comes down to Output being rather loosely defined and we already >>>>> have a ticket open on that. It basically just defines the broad >>>>> types of >>>>> data to be returned (string, list, dict, etc) but not the internal >>>>> components of complex types. >>>> >>>> Took a new approach and created a new output attribute, >>>> serial_number_hex, that is displayed separately. >>>> >>>> UI portion added as well. >>>> >>> >>> ACK for the UI part. I attached a patch which extends UI static testing >>> data - to keep things in solid state. >>> >>> I think this approach is still evil (as the whole ticket) but I don't >>> have a better solution (in CLI). >> >> We are in agreement. >> >>> Question: >>> Isn't the '0x' part a bit redundant? The label already says '(hex)'. >>> However I can buy a 'It is a convention.' argument. >> >> Yes, I did it for convention, plus to avoid confusion for the case where >> it looks like a decimal number but isn't, e.g. 10. If you saw: >> >> Serial number: 16 >> Serial number (hex): 10 >> >> It might be confusing. 0x10 would be clearer. >> >> rob > > This patch works for me, but let me repeat myself: > > > BTW, wouldn't it make sense to format serial numbers in the cert > > plugin in the same way? > > Honza > Updated. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-924-3-serial.patch Type: text/x-diff Size: 14823 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 14 07:32:20 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Mar 2012 08:32:20 +0100 Subject: [Freeipa-devel] [PATCH] 233 Fix ipa-replica-manage TLS connection error In-Reply-To: <4F5FA927.1090705@redhat.com> References: <1331210027.11911.0.camel@balmora.brq.redhat.com> <4F58C5F7.2040907@redhat.com> <4F5FA927.1090705@redhat.com> Message-ID: <1331710340.25760.1.camel@balmora.brq.redhat.com> On Tue, 2012-03-13 at 16:08 -0400, Rob Crittenden wrote: > Rich Megginson wrote: > > On 03/08/2012 05:33 AM, Martin Kosek wrote: > >> New version of openldap (openldap-2.4.26-6.fc16.x86_64) changed its > >> ABI and broke our TLS connection in ipa-replica-manage. This makes > >> it impossible to connect for example to Active Directory to set up > >> a winsync replication. We always receive a connection error stating > >> that Peer's certificate is not recognized even though we pass > >> a correct certificate. > >> > >> This patch fixes the way we set up TLS. The change is backwards > >> compatible with older versions of openldap. > >> > >> https://fedorahosted.org/freeipa/ticket/2500 > > ack > > ACK here too, works fine with old and new openldap. > > rob I fixed a typo in a comment and pushed to master, ipa-2-2. Martin From pvoborni at redhat.com Wed Mar 14 08:10:38 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 14 Mar 2012 09:10:38 +0100 Subject: [Freeipa-devel] [PATCH] 104 Fixed mask validation in network_validator In-Reply-To: <4F59872A.4040000@redhat.com> References: <4F578890.8070100@redhat.com> <4F578989.2050208@redhat.com> <4F59872A.4040000@redhat.com> Message-ID: <4F60527E.601@redhat.com> On 03/09/2012 05:29 AM, Endi Sukma Dewata wrote: > On 3/7/2012 10:15 AM, Petr Vobornik wrote: >> Attaching patch file. >> >> On 03/07/2012 05:10 PM, Petr Vobornik wrote: >>> Network validator allowed invalid mask format: >>> * leading zeros: 192.168.0.1/0024 >>> * trailing chars: 192.168.0.1/24abcd >>> >>> It was fixed. >>> >>> https://fedorahosted.org/freeipa/ticket/2493 > > ACK. > Pushed to master, ipa-2-2. -- Petr Vobornik From pvoborni at redhat.com Wed Mar 14 08:10:53 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 14 Mar 2012 09:10:53 +0100 Subject: [Freeipa-devel] [PATCH] 105 Fixed checkbox value in table without pkey In-Reply-To: <4F598730.3030009@redhat.com> References: <4F588036.1060808@redhat.com> <4F598730.3030009@redhat.com> Message-ID: <4F60528D.5060603@redhat.com> On 03/09/2012 05:29 AM, Endi Sukma Dewata wrote: > On 3/8/2012 3:47 AM, Petr Vobornik wrote: >> When a table is displaying a record set without entity's pkey attribute. >> A checkbox value isn't properly prepared. This patch adds the >> preparation (converts value to string). >> >> https://fedorahosted.org/freeipa/ticket/2404 > > ACK. > Pushed to master, ipa-2-2. -- Petr Vobornik From ohamada at redhat.com Wed Mar 14 12:32:50 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Wed, 14 Mar 2012 13:32:50 +0100 Subject: [Freeipa-devel] [PATCH] 18 Typos in FreeIPA messages Message-ID: <4F608FF2.5080102@redhat.com> https://fedorahosted.org/freeipa/ticket/2526 Rebased patch sent by Yuri Chornoivan (yurchor at ukr.net). Fixes 'occured' and 'commond' typos in FreeIPA messages. Longtitude/Longitude typo was already corrected in patch for ticket #2382 . -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-18-Fix-typos-in-FreeIPA-messages.patch Type: text/x-patch Size: 3013 bytes Desc: not available URL: From abokovoy at redhat.com Wed Mar 14 13:36:15 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 14 Mar 2012 15:36:15 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] Cross-realm trusts with AD In-Reply-To: <1331645747.9238.131.camel@willson.li.ssimo.org> References: <20120313112656.GF4744@redhat.com> <1331645747.9238.131.camel@willson.li.ssimo.org> Message-ID: <20120314133615.GA18672@redhat.com> On Tue, 13 Mar 2012, Simo Sorce wrote: >> 2. samba4 4.0.0-102alpha18 has one minor bug in systemd service >> (https://fedorahosted.org/freeipa/ticket/2523), you'd need to add >> >> ExecStartPre=/bin/mkdir -p /run/samba >> >> before ExecStart= stanza to get it working with tmpfs-based /run in >> Fedora 17. > >This is wrong. >Please add a file in /etc/tmpfiles.d/samba.conf > >Contents should be: >d /var/run/samba 644 root root > >(adjust permission and ownership accordingly). > >This file needs to be added to the samba4 package (and the samba3 >package as well ?) samba4-4.0.0-103alpha18 (in ipa-devel) now includes proper tmpfiles.d file. With 755 permissions, obviously. -- / Alexander Bokovoy From jcholast at redhat.com Wed Mar 14 14:06:45 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 14 Mar 2012 15:06:45 +0100 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F5FC2CD.1090201@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> <4F1DDA53.6090206@redhat.com> <4F567A19.8070408@redhat.com> <4F57855F.10208@redhat.com> <4F5788E8.4010102@redhat.com> <4F58D372.4090102@redhat.com> <4F5FC2CD.1090201@redhat.com> Message-ID: <4F60A5F5.4070201@redhat.com> On 13.3.2012 22:57, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 7.3.2012 17:12, Rob Crittenden wrote: >>> Petr Vobornik wrote: >>>> On 03/06/2012 09:56 PM, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> Jan Cholasta wrote: >>>>>>> Dne 18.1.2012 00:04, Rob Crittenden napsal(a): >>>>>>>> Jan Cholasta wrote: >>>>>>>>> Dne 16.1.2012 22:02, Rob Crittenden napsal(a): >>>>>>>>>> Rob Crittenden wrote: >>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>> Dne 13.1.2012 20:53, Rob Crittenden napsal(a): >>>>>>>>>>>>> When viewing a certificate it will show the serial number as >>>>>>>>>>>>> hex >>>>>>>>>>>>> (dec). >>>>>>>>>>>>> >>>>>>>>>>>>> # ipa service-show HTTP/rawhide.example.com >>>>>>>>>>>>> Principal: HTTP/rawhide.example.com at EXAMPLE.COM >>>>>>>>>>>>> Certificate: [snip] >>>>>>>>>>>>> Keytab: True >>>>>>>>>>>>> Managed by: rawhide.example.com >>>>>>>>>>>>> Subject: CN=rawhide.example.com,O=EXAMPLE.COM >>>>>>>>>>>>> Serial Number: 0x403 (1027) >>>>>>>>>>>>> Issuer: CN=EXAMPLE.COM Certificate Authority >>>>>>>>>>>>> Not Before: Fri Jan 13 15:00:44 2012 UTC >>>>>>>>>>>>> Not After: Thu Jan 13 15:00:44 2022 UTC >>>>>>>>>>>>> Fingerprint (MD5): >>>>>>>>>>>>> e5:43:17:0d:8d:af:d6:69:d8:fb:eb:ca:79:fb:47:69 >>>>>>>>>>>>> Fingerprint (SHA1): >>>>>>>>>>>>> c2:9e:8e:de:42:c9:4a:29:cc:b0:a0:de:57:c7:b7:d8:f9:b5:fe:e6 >>>>>>>>>>>>> >>>>>>>>>>>>> rob >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> NACK >>>>>>>>>>>> >>>>>>>>>>>> Displaying a host or a service in the webUI fails with "IPA >>>>>>>>>>>> error >>>>>>>>>>>> 3009: >>>>>>>>>>>> invalid 'serial_number': Decimal or hexadecimal number is >>>>>>>>>>>> required >>>>>>>>>>>> for >>>>>>>>>>>> serial number". >>>>>>>>>>>> >>>>>>>>>>>> I would suggest to do the nifty formatting of serial numbers on >>>>>>>>>>>> the >>>>>>>>>>>> client side, that would fix the webUI issue, allow non-IPA >>>>>>>>>>>> clients to >>>>>>>>>>>> parse the number without dissecting the string representation >>>>>>>>>>>> of it >>>>>>>>>>>> and >>>>>>>>>>>> probably also save me a hack in the type conversion overhaul. >>>>>>>>>>>> You >>>>>>>>>>>> could >>>>>>>>>>>> for example add a parameter flag like "format_serial_number" to >>>>>>>>>>>> indicate >>>>>>>>>>>> to the client that it should format the value as a serial >>>>>>>>>>>> number. >>>>>>>>>>>> >>>>>>>>>>>> Honza >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Well, we want to do as little client formatting as possible. The >>>>>>>>>>> idea is >>>>>>>>>>> to have a very thin client. >>>>>>>>> >>>>>>>>> It doesn't seem right to me to enforce this specific >>>>>>>>> representation of >>>>>>>>> what is really just an integer at the API level. Doing a little >>>>>>>>> formatting on the client side won't make the client(s) >>>>>>>>> particularly >>>>>>>>> fat, >>>>>>>>> will it? >>>>>>>> >>>>>>>> Yes. The current code just outputs labels and data. There is no >>>>>>>> "if it >>>>>>>> is this attribute then do that" logic. >>>>>>>> >>>>>>>>> >>>>>>>>> IMHO there is too much stuff done on server that would make more >>>>>>>>> sense >>>>>>>>> to do on client anyway (especially CLI-specific stuff such as CSV >>>>>>>>> parsing). What is the reason we want such a thin client? >>>>>>>> >>>>>>>> To avoid double work such that every time we want a formatting >>>>>>>> change we >>>>>>>> have to change it in multiple places. This lesson was learned in >>>>>>>> v1. >>>>>>>> >>>>>>>>> I believe there should be clear separation of presentation and >>>>>>>>> content, >>>>>>>>> but perhaps I'm a little bit too idealistic :-). >>>>>>>> >>>>>>>> You have a point, serial number is defined as an integer. >>>>>>>> Perhaps we >>>>>>>> should revisit this decision to display hex at all. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'll look into fixing the UI side. >>>>>>>>>> >>>>>>>>>> I don't see this error in services, it displays correctly. I'm >>>>>>>>>> not >>>>>>>>>> sure >>>>>>>>>> if it is my browser or what but hosts don't display much of >>>>>>>>>> anything >>>>>>>>>> for >>>>>>>>>> me. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> >>>>>>>>> I have just checked both master and ipa-2-2 and I'm getting the >>>>>>>>> same >>>>>>>>> error message (tested in Firefox 9.0.1) when viewing details of a >>>>>>>>> host >>>>>>>>> or a service with the usercertificate attribute set. >>>>>>>>> >>>>>>>>> BTW, wouldn't it make sense to format serial numbers in the cert >>>>>>>>> plugin >>>>>>>>> in the same way? >>>>>>>> >>>>>>>> Perhaps. Like I said, I'm not really in favor of this change. >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> Maybe we can do a compromise of some sort. What about allowing the >>>>>>> client to specify with each request what representation/formatting >>>>>>> the >>>>>>> server should use for the resulting entries and attributes? >>>>>> >>>>>> That would be mighty flexible but would open a new can of worms. I >>>>>> think >>>>>> long term I'd like to be able to request what attributes to see (ala >>>>>> ldapsearch) but that too is a bit out of scope. >>>>>> >>>>>> This comes down to Output being rather loosely defined and we already >>>>>> have a ticket open on that. It basically just defines the broad >>>>>> types of >>>>>> data to be returned (string, list, dict, etc) but not the internal >>>>>> components of complex types. >>>>> >>>>> Took a new approach and created a new output attribute, >>>>> serial_number_hex, that is displayed separately. >>>>> >>>>> UI portion added as well. >>>>> >>>> >>>> ACK for the UI part. I attached a patch which extends UI static testing >>>> data - to keep things in solid state. >>>> >>>> I think this approach is still evil (as the whole ticket) but I don't >>>> have a better solution (in CLI). >>> >>> We are in agreement. >>> >>>> Question: >>>> Isn't the '0x' part a bit redundant? The label already says '(hex)'. >>>> However I can buy a 'It is a convention.' argument. >>> >>> Yes, I did it for convention, plus to avoid confusion for the case where >>> it looks like a decimal number but isn't, e.g. 10. If you saw: >>> >>> Serial number: 16 >>> Serial number (hex): 10 >>> >>> It might be confusing. 0x10 would be clearer. >>> >>> rob >> >> This patch works for me, but let me repeat myself: >> >> > BTW, wouldn't it make sense to format serial numbers in the cert >> > plugin in the same way? >> >> Honza >> > > Updated. > > rob > Thanks, ACK. Honza -- Jan Cholasta From edewata at redhat.com Wed Mar 14 14:11:16 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 14 Mar 2012 09:11:16 -0500 Subject: [Freeipa-devel] [PATCH] 107 Fixed evaluating checkbox dirty status In-Reply-To: <4F5A3BD3.7070703@redhat.com> References: <4F5A3BD3.7070703@redhat.com> Message-ID: <4F60A704.2040806@redhat.com> ACK. I have some comments below. On 3/9/2012 11:20 AM, Petr Vobornik wrote: > Problem: > When value in checkbox is modified twice in a row (so it is at its > original value) an 'undo' button is still visible even when it shouldn't > be. > > Cause: > IPA server sends boolean values as 'TRUE' or 'FALSE' (strings). > Checkbox_widget converts them to JavaScript? boolean (true, false). Save > method in checkbox_widget is returning array with a boolean. So > test_dirty method always evaluates to dirty because 'FALSE' != false. > > This patch is fixing the problem. > > Note (future enhancements): > As we were talking before about making fields less dependent on widget > types. The dependency comes from the fact that dirty evaluation is in > field. I plan to move the core to widget. I'm thinking about something > like: > Widget would have: > * input value parser - ie for parsing strings to booleans - configurable > * original value (parsed) > * inner state (inner_save()) > * is_dirty() - compare inner state with original value > * output formatter - can make boolean back to strings (just example) - > configurable > * save() would return array of formatted values > > Field: > * load(record) would pick values from record as now > * is_dirty - needed for facets. Would be: dirty = 'one of associated > widgets is dirty' > * save() - merge associated widgets values - usually only on array from > one widget > > Maybe input and output formatters should be in field. We might need it in both field and widget. There are 3 different values that we need to consider: * stored value (LDAP), e.g. TRUE/FALSE * internal value (JavaScript), e.g. true/false * external value (human readable), e.g. True/False The field will be responsible for converting between stored and internal value. The widget will be responsible for converting between internal & external value if needed. Suppose we want to display a boolean attribute using a checkbox. We will need a boolean field which will convert TRUE/FALSE into true/false. Then we also need a standard checkbox that displays true as checked and false as unchecked. Suppose we want to display the boolean attribute in a table column. We should be able to use the same boolean field, but then we use a boolean column that converts true/false into True/False. -- Endi S. Dewata From edewata at redhat.com Wed Mar 14 14:13:20 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 14 Mar 2012 09:13:20 -0500 Subject: [Freeipa-devel] [PATCH] 108 Better hbactest validation message In-Reply-To: <4F5DF893.4000408@redhat.com> References: <4F5DF893.4000408@redhat.com> Message-ID: <4F60A780.6070106@redhat.com> On 3/12/2012 8:22 AM, Petr Vobornik wrote: > HBAC Test validation message now contains all missing values in form of > list of links instead of general 'missing values' message and > redirection to first missing value's facet. > > When a link is clicked user is redirected to value's facet. > > https://fedorahosted.org/freeipa/ticket/2182 > > Note: In a list I chose to display an option label instead of facet > label. IMHO it seems better with message 'Missing values'. It looks good. ACK. -- Endi S. Dewata From pvoborni at redhat.com Wed Mar 14 14:40:00 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 14 Mar 2012 15:40:00 +0100 Subject: [Freeipa-devel] [PATCH] Fixed rpm build warning - extension.js listed twice Message-ID: <4F60ADC0.1090202@redhat.com> First, I have to say that I'm new to rpm specs and I don't like this patch but I don't have better solution. Problem: Building the ipa rpms returns this: warning: File listed twice: /usr/share/ipa/ui/extension.js Cause: This is because of a glob: %{_usr}/share/ipa/ui/*.js and then more specifically: %config(noreplace) %{_usr}/share/ipa/ui/extension.js https://fedorahosted.org/freeipa/ticket/2253 Solution thoughts:: 1) best way would be limit glob like in bash ie: '%{_usr}/share/ipa/ui/!(extension).js'. It doesn't work in spec file. 2) I don't want to specify each JavaScript file in spec - would have to alter spec each time when adding new one. --> I found nothing better than to use file list. Filelist generation: I'm creating it in %prep phase from install/ui/Makefile.am: grep .js install/ui/Makefile.am | grep -v 'extension.js' | sed -e 's/[\t]*\\//' -e 's|[\t]*|%{_usr}/share/ipa/ui/|' It would also be possible to generate the list from listing the directory: find install/ui/ -maxdepth 1 -type f -name *.js ! -name develop.js ! -name extension.js | sed 's|^install|%{usr}/share/ipa|g' Why from Makefile?: The list of .js files in git and Makefile differs. Therefore listing from dir also needs to create exceptions for not used files (develop.js) - bad in long term. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0109-Fixed-rpm-build-warning-extension.js-listed-twice.patch Type: text/x-patch Size: 1531 bytes Desc: not available URL: From simo at redhat.com Wed Mar 14 14:48:18 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Mar 2012 10:48:18 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] Cross-realm trusts with AD In-Reply-To: <20120314133615.GA18672@redhat.com> References: <20120313112656.GF4744@redhat.com> <1331645747.9238.131.camel@willson.li.ssimo.org> <20120314133615.GA18672@redhat.com> Message-ID: <1331736498.9238.168.camel@willson.li.ssimo.org> On Wed, 2012-03-14 at 15:36 +0200, Alexander Bokovoy wrote: > On Tue, 13 Mar 2012, Simo Sorce wrote: > >> 2. samba4 4.0.0-102alpha18 has one minor bug in systemd service > >> (https://fedorahosted.org/freeipa/ticket/2523), you'd need to add > >> > >> ExecStartPre=/bin/mkdir -p /run/samba > >> > >> before ExecStart= stanza to get it working with tmpfs-based /run in > >> Fedora 17. > > > >This is wrong. > >Please add a file in /etc/tmpfiles.d/samba.conf > > > >Contents should be: > >d /var/run/samba 644 root root > > > >(adjust permission and ownership accordingly). > > > >This file needs to be added to the samba4 package (and the samba3 > >package as well ?) > samba4-4.0.0-103alpha18 (in ipa-devel) now includes proper tmpfiles.d > file. With 755 permissions, obviously. > Great! thanks. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Wed Mar 14 14:49:08 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 14 Mar 2012 09:49:08 -0500 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F57855F.10208@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> <4F1DDA53.6090206@redhat.com> <4F567A19.8070408@redhat.com> <4F57855F.10208@redhat.com> Message-ID: <4F60AFE4.4040606@redhat.com> On 3/7/2012 9:57 AM, Petr Vobornik wrote: > On 03/06/2012 09:56 PM, Rob Crittenden wrote: >> UI portion added as well. > > ACK for the UI part. I attached a patch which extends UI static testing > data - to keep things in solid state. ACK for Petr's patch #101. -- Endi S. Dewata From pviktori at redhat.com Wed Mar 14 15:06:04 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 Mar 2012 16:06:04 +0100 Subject: [Freeipa-devel] [PATCH] Fixed rpm build warning - extension.js listed twice In-Reply-To: <4F60ADC0.1090202@redhat.com> References: <4F60ADC0.1090202@redhat.com> Message-ID: <4F60B3DC.8010508@redhat.com> On 03/14/2012 03:40 PM, Petr Vobornik wrote: > First, I have to say that I'm new to rpm specs and I don't like this > patch but I don't have better solution. > > Problem: > Building the ipa rpms returns this: > warning: File listed twice: /usr/share/ipa/ui/extension.js > > Cause: > This is because of a glob: > %{_usr}/share/ipa/ui/*.js > > and then more specifically: > %config(noreplace) %{_usr}/share/ipa/ui/extension.js > > https://fedorahosted.org/freeipa/ticket/2253 > > Solution thoughts:: > > 1) best way would be limit glob like in bash ie: > '%{_usr}/share/ipa/ui/!(extension).js'. It doesn't work in spec file. > 2) I don't want to specify each JavaScript file in spec - would have to > alter spec each time when adding new one. > > --> I found nothing better than to use file list. > > Filelist generation: > I'm creating it in %prep phase from install/ui/Makefile.am: > grep .js install/ui/Makefile.am | grep -v 'extension.js' | sed -e > 's/[\t]*\\//' -e 's|[\t]*|%{_usr}/share/ipa/ui/|' > > It would also be possible to generate the list from listing the directory: > > find install/ui/ -maxdepth 1 -type f -name *.js ! -name develop.js ! > -name extension.js | sed 's|^install|%{usr}/share/ipa|g' > > Why from Makefile?: > The list of .js files in git and Makefile differs. Therefore listing > from dir also needs to create exceptions for not used files (develop.js) > - bad in long term. Slightly related: Have you thought about concatenating the JS files (automatically), and serving them all as one file? http://developer.yahoo.com/performance/rules.html#num_http -- Petr? From pvoborni at redhat.com Wed Mar 14 15:23:22 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 14 Mar 2012 16:23:22 +0100 Subject: [Freeipa-devel] [PATCH] Fixed rpm build warning - extension.js listed twice In-Reply-To: <4F60B3DC.8010508@redhat.com> References: <4F60ADC0.1090202@redhat.com> <4F60B3DC.8010508@redhat.com> Message-ID: <4F60B7EA.9000404@redhat.com> On 03/14/2012 04:06 PM, Petr Viktorin wrote: > On 03/14/2012 03:40 PM, Petr Vobornik wrote: >> First, I have to say that I'm new to rpm specs and I don't like this >> patch but I don't have better solution. >> >> Problem: >> Building the ipa rpms returns this: >> warning: File listed twice: /usr/share/ipa/ui/extension.js >> >> Cause: >> This is because of a glob: >> %{_usr}/share/ipa/ui/*.js >> >> and then more specifically: >> %config(noreplace) %{_usr}/share/ipa/ui/extension.js >> >> https://fedorahosted.org/freeipa/ticket/2253 >> >> Solution thoughts:: >> >> 1) best way would be limit glob like in bash ie: >> '%{_usr}/share/ipa/ui/!(extension).js'. It doesn't work in spec file. >> 2) I don't want to specify each JavaScript file in spec - would have to >> alter spec each time when adding new one. >> >> --> I found nothing better than to use file list. >> >> Filelist generation: >> I'm creating it in %prep phase from install/ui/Makefile.am: >> grep .js install/ui/Makefile.am | grep -v 'extension.js' | sed -e >> 's/[\t]*\\//' -e 's|[\t]*|%{_usr}/share/ipa/ui/|' >> >> It would also be possible to generate the list from listing the >> directory: >> >> find install/ui/ -maxdepth 1 -type f -name *.js ! -name develop.js ! >> -name extension.js | sed 's|^install|%{usr}/share/ipa|g' >> >> Why from Makefile?: >> The list of .js files in git and Makefile differs. Therefore listing >> from dir also needs to create exceptions for not used files (develop.js) >> - bad in long term. > > Slightly related: Have you thought about concatenating the JS files > (automatically), and serving them all as one file? > http://developer.yahoo.com/performance/rules.html#num_http > We have a ticket for that (slightly differ, but the idea is mentioned there) https://fedorahosted.org/freeipa/ticket/112 . Performance-wise, bigger issue is fetching metadata. Web UI is single page app so it fetches all in first request and then it uses AJAX calls to get things done so it would not be a big benefit. This ticket: I will use Endi's idea and move extension.js to subfolder. -- Petr Vobornik From ohamada at redhat.com Wed Mar 14 15:54:41 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Wed, 14 Mar 2012 16:54:41 +0100 Subject: [Freeipa-devel] [PATCH] 16 Netgroup nisdomain and hosts validation In-Reply-To: <1331307242.26839.24.camel@balmora.brq.redhat.com> References: <4F58B9A8.2000508@redhat.com> <1331307242.26839.24.camel@balmora.brq.redhat.com> Message-ID: <4F60BF41.3000301@redhat.com> On 03/09/2012 04:34 PM, Martin Kosek wrote: > On Thu, 2012-03-08 at 14:52 +0100, Ondrej Hamada wrote: >> Netgroup nisdomain and hosts validation >> >> nisdomain validation: >> Added pattern to the 'nisdomain' parameter to validate the specified >> nisdomain name. According to most common use cases the same patter as >> for netgroup should fit. Unit-tests added. >> >> https://fedorahosted.org/freeipa/ticket/2447 >> >> hosts validation: >> Added precallback to netgroup_add_member. It validates the specified >> hostnames and raises ValidationError exception for invalid hostnames. >> Unit-test added. >> >> https://fedorahosted.org/freeipa/ticket/2448 > > I checked the host validation part and it could be improved. Issue > described in #2447 (you have switched the ticket IDs) affects all > objects that allow external hosts, users, ..., i.e. those who call > add_external_post_callback in their post_callback. > > Should we fix all of these when we deal with this issue? Otherwise user > could do something like this: > # ipa sudorule-add-user foo --users=a+b > Rule name: foo > Enabled: TRUE > External User: a+b > > We could create a similar function called add_external_pre_callback() > and pass it attribute name and validating function (which would be > common with the linked object). It would then do the validation for all > these affected objects consistently and without redundant code. > > I didn't liked much the implemented pre_callback anyway > > + def pre_callback(self, ldap, dn, found, not_found, *keys, > **options): > + # validate entered hostnames > + if 'host' in options: > + invalid_hostnames=[] > + for hostname in options['host']: > + try: > + validate_hostname(hostname, False) > + except ValueError: > + invalid_hostnames.append(hostname) > + if invalid_hostnames: > + raise errors.ValidationError(name='host', > error='hostnames:\"%s\" contain invalid characters' % > ','.join(invalid_hostnames)) > + return dn > > I would rather raise the ValidationError with the first invalid hostname > and tell what's wrong (function validate_hostname tells it to you). If > you go with the proposed approach, you wouldn't have to deal with > formatting error messages, you would just raise the one returned by the > validator shared with the linked LDAP object (hostname, user, ...). > > Martin external_pre_callback function seems as a good idea, but there is a problem how to get the validators for various LDAP objects. For the hostname we already have one in ipalib.utils, but for the uid or group name we use only patterns specified in the parameter objects. Below I propose solution how to use the already defined parameter objects for validation (the only problem is that I have to assume, that it is always the first parameter in takes_params). Do you think this is a good approach? def add_external_pre_callback(memberattr, membertype, externalattr, ldap, dn, found, not_found, *keys, **options): """ Pre callback to validate external members. """ if membertype in options: validator = api.Object[membertype].takes_params[0] for value in options[membertype]: try: validator(value) except errors.ValidationError as e: error_msg = e[(e.find(':')+1):] raise errors.ValidationError(name=membertype, error=e[e.find(':')+1:]) return dn -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada From pviktori at redhat.com Wed Mar 14 16:02:43 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 Mar 2012 17:02:43 +0100 Subject: [Freeipa-devel] [PATCH] 0027 Use valid argument names in tests Message-ID: <4F60C123.3040203@redhat.com> This patch depends on my patch 0024 (but I can rebase if it needs to be pushed earlied). It fixes some of the test bugs that would be found by a fix for https://fedorahosted.org/freeipa/ticket/2509 (Unknown Command arguments are allowed (and ignored)). As you can see it's quite easy, without validation, to use a wrong name for an argument. Unfortunately, some of our plugins (automount, dns, delegation, permission, selfservice) take advantage of the current sloppy validation, so they'll need some untangling for 3.x to make them more robust and testable. For now I'm just touching the tests, so we don't get new bugs in production code. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0027-Use-valid-argument-names-in-tests.patch Type: text/x-patch Size: 7294 bytes Desc: not available URL: From rmeggins at redhat.com Wed Mar 14 19:45:45 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Mar 2012 13:45:45 -0600 Subject: [Freeipa-devel] Please review: take 2: Ticket #1891 - Rewrite IPA plugins to take advantage of the single transaction Message-ID: <4F60F569.7070305@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rmeggins-0004-Rewrite-IPA-plugins-to-take-advantage-of.patch Type: application/mbox Size: 13900 bytes Desc: not available URL: From rcritten at redhat.com Wed Mar 14 19:52:02 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Mar 2012 15:52:02 -0400 Subject: [Freeipa-devel] [PATCH] 982 tweak to no_init patch In-Reply-To: <1331632671.24319.8.camel@balmora.brq.redhat.com> References: <4F57D835.7020605@redhat.com> <1331632671.24319.8.camel@balmora.brq.redhat.com> Message-ID: <4F60F6E2.5040902@redhat.com> Martin Kosek wrote: > On Wed, 2012-03-07 at 16:50 -0500, Rob Crittenden wrote: >> I discovered today that cert-request was failing with an untrusted CA error. >> >> The problem had to do with the NSS no_init patch. We were setting dbdir >> in the connection object too soon so it was comparing itself to itself >> and always determined that NSS was initialized just fine. This needs to >> be moved after the check. >> >> To test this you need a master, a replica and a client with DNS set up >> and SRV records for both servers. >> >> You need two or more servers so we run the ping() test. This is where >> the client was failing before. What would happen is this: >> >> - initialize NSS >> - run ping() against a server >> - prepare request >> - initialize NSS >> - FAIL >> >> That second initialization isn't needed and is correctly caught by the >> code with this patch. >> >> You need to test that a client enrollment works and that ipa >> cert-request works. >> >> cert-request was failing because we initialize NSS with nodb so we can >> load the CSR for validation. Because dbdir was set too early in the >> connection we were getting no_init set improperly and nss_shutdown() >> wasn't being called. >> >> rob > > Works for me, ACK. > > Please enhance testing instructions in the ticket. I had some issues > reproducing the problem myself, but your advice sent off-list helped me. > This should be enough. > > Martin > > pushed to master and ipa-2-2 From rcritten at redhat.com Wed Mar 14 20:37:22 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Mar 2012 16:37:22 -0400 Subject: [Freeipa-devel] [PATCH] 0023 Don't crash when searching with empty relationship options In-Reply-To: <4F59F34D.3080407@redhat.com> References: <4F59F34D.3080407@redhat.com> Message-ID: <4F610182.60308@redhat.com> Petr Viktorin wrote: > See commit message. > > https://fedorahosted.org/freeipa/ticket/2479 > ACK, pushed to master and ipa-2-2 From nhosoi at redhat.com Wed Mar 14 21:19:58 2012 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 14 Mar 2012 14:19:58 -0700 Subject: [Freeipa-devel] Please review: take 2: Ticket #1891 - Rewrite IPA plugins to take advantage of the single transaction In-Reply-To: <4F60F569.7070305@redhat.com> References: <4F60F569.7070305@redhat.com> Message-ID: <4F610B7E.4080209@redhat.com> ack. Rich Megginson wrote: > > > > _______________________________________________ > 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 Wed Mar 14 21:31:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Mar 2012 17:31:03 -0400 Subject: [Freeipa-devel] [PATCH] 983 add subject key identifier In-Reply-To: <1331299879.26839.7.camel@balmora.brq.redhat.com> References: <4F57E5EC.4030801@redhat.com> <1331299879.26839.7.camel@balmora.brq.redhat.com> Message-ID: <4F610E17.7080207@redhat.com> Martin Kosek wrote: > On Wed, 2012-03-07 at 17:49 -0500, Rob Crittenden wrote: >> Add subject key identifier to the dogtag server cert profile. >> >> This will add it on upgrades too and any new certs issued will have a >> subject key identifier set. >> >> If the user has customized the profile themselves then this won't be >> applied. >> >> rob > > NACK > > I found few issues with the patch: > > 1) There is an extraneous pdb statement: > + import pdb; pdb.set_trace() > > 2) A name of config file should be put to some variable once and not > created every time again in enable_subject_key_identifier. It would be > much more readable and less error prone: > + installutils.set_directive('/var/lib/% > s/profiles/ca/caIPAserviceCert.cfg' % PKI_INSTANCE_NAME, > 'policyset.serverCertSet.list', '1,2,3,4,5,6,7,8,10', quotes=False, > separator='=') > + installutils.set_directive('/var/lib/% > s/profiles/ca/caIPAserviceCert.cfg' % PKI_INSTANCE_NAME, > 'policyset.serverCertSet.10.constraint.class_id', 'noConstraintImpl', > quotes=False, separator='=') > ... > > 3) We do not handle gracefully missing config file. This is what happens > when replica without CA is upgraded: > # rpm -Uvh --force /home/mkosek/dist-review/rpms/freeipa-* > Preparing... ########################################### [100%] > 1:freeipa-python ########################################### [ 17%] > 2:freeipa-client ########################################### [ 33%] > 3:freeipa-admintools ########################################### [ 50%] > 4:freeipa-server ########################################### [ 67%] > Upgraded /etc/httpd/conf.d/ipa-pki-proxy.conf to version 1 > Traceback (most recent call last): > File "/usr/sbin/ipa-upgradeconfig", line 301, in > sys.exit(main()) > File "/usr/sbin/ipa-upgradeconfig", line 297, in main > upgrade_ipa_profile(krbctx.default_realm) > File "/usr/sbin/ipa-upgradeconfig", line 243, in upgrade_ipa_profile > if ca.enable_subject_key_identifier(): > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1079, in enable_subject_key_identifier > setlist = installutils.get_directive('/var/lib/%s/profiles/ca/caIPAserviceCert.cfg' % PKI_INSTANCE_NAME, 'policyset.serverCertSet.list', separator='=') > File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 429, in get_directive > fd = open(filename, "r") > IOError: [Errno 2] No such file or directory: '/var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg' > 5:freeipa-server-selinux ########################################### [ 83%] > 6:freeipa-debuginfo ########################################### [100%] > > 1. Martin > I think this should do it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-983-2-dogtag.patch Type: text/x-diff Size: 6360 bytes Desc: not available URL: From JR.Aquino at citrix.com Wed Mar 14 23:43:50 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Wed, 14 Mar 2012 23:43:50 +0000 Subject: [Freeipa-devel] [PATCH] 44 Add Automember Test to simulate logic decisions Message-ID: <90BA7FDD-270E-49FB-B1AE-332900721F8A@citrixonline.com> This will be _very_ helpful for testing automember logic against potential users / hosts. This patch addes a new plugin to FreeIPA that tests automember logic decisions https://fedorahosted.org/freeipa/ticket/2535 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aquino at citrixonline.com http://www.citrixonline.com From rcritten at redhat.com Thu Mar 15 01:50:06 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Mar 2012 21:50:06 -0400 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F60AFE4.4040606@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> <4F1DDA53.6090206@redhat.com> <4F567A19.8070408@redhat.com> <4F57855F.10208@redhat.com> <4F60AFE4.4040606@redhat.com> Message-ID: <4F614ACE.4050102@redhat.com> Endi Sukma Dewata wrote: > On 3/7/2012 9:57 AM, Petr Vobornik wrote: >> On 03/06/2012 09:56 PM, Rob Crittenden wrote: >>> UI portion added as well. >> >> ACK for the UI part. I attached a patch which extends UI static testing >> data - to keep things in solid state. > > ACK for Petr's patch #101. > Pushed both patches to ipa-2-2 and master. rob From rcritten at redhat.com Thu Mar 15 01:53:46 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Mar 2012 21:53:46 -0400 Subject: [Freeipa-devel] [PATCH] 981 set httpd_manage_ipa In-Reply-To: <20120312215815.GE4744@redhat.com> References: <4F577175.4070407@redhat.com> <20120309064328.GH2724@redhat.com> <4F5E116E.3010901@redhat.com> <20120312151304.GD4744@redhat.com> <4F5E4C05.6040406@redhat.com> <4F5E6FEF.2090409@redhat.com> <20120312215815.GE4744@redhat.com> Message-ID: <4F614BAA.1050203@redhat.com> Alexander Bokovoy wrote: > On Mon, 12 Mar 2012, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Alexander Bokovoy wrote: >>>> On Mon, 12 Mar 2012, Rob Crittenden wrote: >>>>> Alexander Bokovoy wrote: >>>>>> On Wed, 07 Mar 2012, Rob Crittenden wrote: >>>>>> >>>>>>> Set SELinux boolean httpd_manage_ipa so ipa_memcached will work in >>>>>>> enforcing mode. >>>>>>> >>>>>>> This is being done in the HTTP instance so we can set both booleans >>>>>>> in one step and save a bit of time (it is still slow). >>>>>> I would prefer all platform-specific manipulations of security >>>>>> policies to be moved to platform-specific module. >>>>>> >>>>>> Make a HTTP class there (like I did dirsrv class in systemd >>>>>> backend) and perform manipulations on service enable. >>>>>> >>>>>> This way main code will stay clear of platform-specific code. >>>>>> >>>>>> Sorry for not looking into the issue before. >>>>>> >>>>> >>>>> I'd prefer to keep the change simple for now and do the big move post >>>>> 2.2. >>>> ACK on condition you'd file a ticket for the post 2.2 work. >>>> >>>> :) >>> >>> Filed this https://fedorahosted.org/freeipa/ticket/2519 >>> >>> I found an issue with this patch that I need to address, will submit a >>> replacement. >>> >>> rob >> >> Handle things better if a boolean doesn't exist. > Lucky that setsebool takes multiple booleans at the same time... > Maybe it would make sense to merge bools upon recover? > > Otherwise ACK. > pushed to master and ipa-2-2 From rcritten at redhat.com Thu Mar 15 02:25:21 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Mar 2012 22:25:21 -0400 Subject: [Freeipa-devel] [PATCH] 232 Treat UPGs correctly in winsync replication In-Reply-To: <1331142184.2294.1.camel@priserak> References: <1331142184.2294.1.camel@priserak> Message-ID: <4F615311.6020006@redhat.com> Martin Kosek wrote: > There are some test hints attached to the ticket. > --- > IPA winsync plugin failed to replicate users when default user group > was non-posix even though User Private Groups (UPG) were enabled > on the server. Both their uidNumber and gidNumber were empty and > they missed essential object classes. When the default user group > was made posix and UPG was disabled it did not set gidNumber to > the default group gidNumber. > > This patch improves this behavior to set gidNumber correctly > according to UPG configuration and the default group status > (posix/non-posix). 4 situations can occur, the following list > specifies what value is assigned to user gidNumber: > 1) Default group posix, UPG enabled: gidNumber = UPG gidNumber > 2) Default group posix, UPG disabled: gidNumber = default > group gidNumber > 3) Default group non-posix, UPG enabled: gidNumber = UPG gidNumber > 4) Default group non-posix, UPG disabled: an error is printed to > the dirsrv log as the gidNumber cannot be retrieved. User > is replicated in the same way as before this patch, i.e. > without essential object classes. > > https://fedorahosted.org/freeipa/ticket/2436 ACK, works as advertised. rob From mkosek at redhat.com Thu Mar 15 07:13:53 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Mar 2012 08:13:53 +0100 Subject: [Freeipa-devel] [PATCH] 16 Netgroup nisdomain and hosts validation In-Reply-To: <4F60BF41.3000301@redhat.com> References: <4F58B9A8.2000508@redhat.com> <1331307242.26839.24.camel@balmora.brq.redhat.com> <4F60BF41.3000301@redhat.com> Message-ID: <1331795633.27127.3.camel@balmora.brq.redhat.com> On Wed, 2012-03-14 at 16:54 +0100, Ondrej Hamada wrote: > On 03/09/2012 04:34 PM, Martin Kosek wrote: > > On Thu, 2012-03-08 at 14:52 +0100, Ondrej Hamada wrote: > >> Netgroup nisdomain and hosts validation > >> > >> nisdomain validation: > >> Added pattern to the 'nisdomain' parameter to validate the specified > >> nisdomain name. According to most common use cases the same patter as > >> for netgroup should fit. Unit-tests added. > >> > >> https://fedorahosted.org/freeipa/ticket/2447 > >> > >> hosts validation: > >> Added precallback to netgroup_add_member. It validates the specified > >> hostnames and raises ValidationError exception for invalid hostnames. > >> Unit-test added. > >> > >> https://fedorahosted.org/freeipa/ticket/2448 > > > > I checked the host validation part and it could be improved. Issue > > described in #2447 (you have switched the ticket IDs) affects all > > objects that allow external hosts, users, ..., i.e. those who call > > add_external_post_callback in their post_callback. > > > > Should we fix all of these when we deal with this issue? Otherwise user > > could do something like this: > > # ipa sudorule-add-user foo --users=a+b > > Rule name: foo > > Enabled: TRUE > > External User: a+b > > > > We could create a similar function called add_external_pre_callback() > > and pass it attribute name and validating function (which would be > > common with the linked object). It would then do the validation for all > > these affected objects consistently and without redundant code. > > > > I didn't liked much the implemented pre_callback anyway > > > > + def pre_callback(self, ldap, dn, found, not_found, *keys, > > **options): > > + # validate entered hostnames > > + if 'host' in options: > > + invalid_hostnames=[] > > + for hostname in options['host']: > > + try: > > + validate_hostname(hostname, False) > > + except ValueError: > > + invalid_hostnames.append(hostname) > > + if invalid_hostnames: > > + raise errors.ValidationError(name='host', > > error='hostnames:\"%s\" contain invalid characters' % > > ','.join(invalid_hostnames)) > > + return dn > > > > I would rather raise the ValidationError with the first invalid hostname > > and tell what's wrong (function validate_hostname tells it to you). If > > you go with the proposed approach, you wouldn't have to deal with > > formatting error messages, you would just raise the one returned by the > > validator shared with the linked LDAP object (hostname, user, ...). > > > > Martin > > external_pre_callback function seems as a good idea, but there is a > problem how to get the validators for various LDAP objects. For the > hostname we already have one in ipalib.utils, but for the uid or group > name we use only patterns specified in the parameter objects. > > Below I propose solution how to use the already defined parameter > objects for validation (the only problem is that I have to assume, that > it is always the first parameter in takes_params). Do you think this is > a good approach? I think the approach is OK, it can just be much improved in order to get rid of the hardcoded parts. See comments below. > > def add_external_pre_callback(memberattr, membertype, externalattr, > ldap, dn, found, not_found, *keys, **options): > """ > Pre callback to validate external members. > """ > if membertype in options: > validator = api.Object[membertype].takes_params[0] You can use api.Object[membertype].params[memberattr] > for value in options[membertype]: > try: > validator(value) > except errors.ValidationError as e: > error_msg = e[(e.find(':')+1):] You don't have to parse error message, you can just use e.name or e.error right from the caught ValidationError. > raise errors.ValidationError(name=membertype, > error=e[e.find(':')+1:]) > return dn > From mkosek at redhat.com Thu Mar 15 08:56:39 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Mar 2012 09:56:39 +0100 Subject: [Freeipa-devel] [PATCH] 983 add subject key identifier In-Reply-To: <4F610E17.7080207@redhat.com> References: <4F57E5EC.4030801@redhat.com> <1331299879.26839.7.camel@balmora.brq.redhat.com> <4F610E17.7080207@redhat.com> Message-ID: <1331801799.27127.10.camel@balmora.brq.redhat.com> On Wed, 2012-03-14 at 17:31 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Wed, 2012-03-07 at 17:49 -0500, Rob Crittenden wrote: > >> Add subject key identifier to the dogtag server cert profile. > >> > >> This will add it on upgrades too and any new certs issued will have a > >> subject key identifier set. > >> > >> If the user has customized the profile themselves then this won't be > >> applied. > >> > >> rob > > > > NACK > > > > I found few issues with the patch: > > > > 1) There is an extraneous pdb statement: > > + import pdb; pdb.set_trace() > > > > 2) A name of config file should be put to some variable once and not > > created every time again in enable_subject_key_identifier. It would be > > much more readable and less error prone: > > + installutils.set_directive('/var/lib/% > > s/profiles/ca/caIPAserviceCert.cfg' % PKI_INSTANCE_NAME, > > 'policyset.serverCertSet.list', '1,2,3,4,5,6,7,8,10', quotes=False, > > separator='=') > > + installutils.set_directive('/var/lib/% > > s/profiles/ca/caIPAserviceCert.cfg' % PKI_INSTANCE_NAME, > > 'policyset.serverCertSet.10.constraint.class_id', 'noConstraintImpl', > > quotes=False, separator='=') > > ... > > > > 3) We do not handle gracefully missing config file. This is what happens > > when replica without CA is upgraded: > > # rpm -Uvh --force /home/mkosek/dist-review/rpms/freeipa-* > > Preparing... ########################################### [100%] > > 1:freeipa-python ########################################### [ 17%] > > 2:freeipa-client ########################################### [ 33%] > > 3:freeipa-admintools ########################################### [ 50%] > > 4:freeipa-server ########################################### [ 67%] > > Upgraded /etc/httpd/conf.d/ipa-pki-proxy.conf to version 1 > > Traceback (most recent call last): > > File "/usr/sbin/ipa-upgradeconfig", line 301, in > > sys.exit(main()) > > File "/usr/sbin/ipa-upgradeconfig", line 297, in main > > upgrade_ipa_profile(krbctx.default_realm) > > File "/usr/sbin/ipa-upgradeconfig", line 243, in upgrade_ipa_profile > > if ca.enable_subject_key_identifier(): > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1079, in enable_subject_key_identifier > > setlist = installutils.get_directive('/var/lib/%s/profiles/ca/caIPAserviceCert.cfg' % PKI_INSTANCE_NAME, 'policyset.serverCertSet.list', separator='=') > > File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 429, in get_directive > > fd = open(filename, "r") > > IOError: [Errno 2] No such file or directory: '/var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg' > > 5:freeipa-server-selinux ########################################### [ 83%] > > 6:freeipa-debuginfo ########################################### [100%] > > > > 1. Martin > > > > I think this should do it. > > rob Yup, its much better. ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Thu Mar 15 09:20:20 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Mar 2012 10:20:20 +0100 Subject: [Freeipa-devel] [PATCH] 232 Treat UPGs correctly in winsync replication In-Reply-To: <4F615311.6020006@redhat.com> References: <1331142184.2294.1.camel@priserak> <4F615311.6020006@redhat.com> Message-ID: <1331803220.27127.12.camel@balmora.brq.redhat.com> On Wed, 2012-03-14 at 22:25 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > There are some test hints attached to the ticket. > > --- > > IPA winsync plugin failed to replicate users when default user group > > was non-posix even though User Private Groups (UPG) were enabled > > on the server. Both their uidNumber and gidNumber were empty and > > they missed essential object classes. When the default user group > > was made posix and UPG was disabled it did not set gidNumber to > > the default group gidNumber. > > > > This patch improves this behavior to set gidNumber correctly > > according to UPG configuration and the default group status > > (posix/non-posix). 4 situations can occur, the following list > > specifies what value is assigned to user gidNumber: > > 1) Default group posix, UPG enabled: gidNumber = UPG gidNumber > > 2) Default group posix, UPG disabled: gidNumber = default > > group gidNumber > > 3) Default group non-posix, UPG enabled: gidNumber = UPG gidNumber > > 4) Default group non-posix, UPG disabled: an error is printed to > > the dirsrv log as the gidNumber cannot be retrieved. User > > is replicated in the same way as before this patch, i.e. > > without essential object classes. > > > > https://fedorahosted.org/freeipa/ticket/2436 > > ACK, works as advertised. > > rob Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Thu Mar 15 09:44:05 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Mar 2012 10:44:05 +0100 Subject: [Freeipa-devel] [PATCH] 236 Amend permissions for new DNS attributes Message-ID: <1331804645.27127.17.camel@balmora.brq.redhat.com> New features in bind-dyndb-ldap and IPA DNS plugin pulled new attributes and objectclasses. ACIs and permissions need to be updated to allow users with appropriate permissions update these attributes in LDAP. This patch updates the ACI for DNS record updates and adds one new permission to update global DNS configuration. https://fedorahosted.org/freeipa/ticket/2510 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-236-amend-permissions-for-new-dns-attributes.patch Type: text/x-patch Size: 8418 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 15 10:03:01 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 15 Mar 2012 11:03:01 +0100 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F5FC2CD.1090201@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> <4F1DDA53.6090206@redhat.com> <4F567A19.8070408@redhat.com> <4F57855F.10208@redhat.com> <4F5788E8.4010102@redhat.com> <4F58D372.4090102@redhat.com> <4F5FC2CD.1090201@redhat.com> Message-ID: <4F61BE55.2070700@redhat.com> On 03/13/2012 10:57 PM, Rob Crittenden wrote: > Jan Cholasta wrote: ..snip.. >> >> This patch works for me, but let me repeat myself: >> >> > BTW, wouldn't it make sense to format serial numbers in the cert >> > plugin in the same way? >> >> Honza >> > > Updated. > > rob > > diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index b31058c1418f7f73854f7ac06701fb6f821a2e40..b56e04f4d8675c34cc5e7db42a1b45402ef79084 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -609,6 +609,7 @@ def parse_profile_submit_result_xml(doc): if len(serial_number) == 1: serial_number = int(serial_number[0].text, 16) # parse as hex response_request['serial_number'] = serial_number + response['serial_number_hex'] = u'0x%X' % serial_number Why are you adding serial_number_hex to the entire response, when serial_number is on the individual response_request? (same in parse_revoke_cert_xml) I think you should also update the docstrings with the new item. -- Petr? From pviktori at redhat.com Thu Mar 15 10:30:20 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 15 Mar 2012 11:30:20 +0100 Subject: [Freeipa-devel] [PATCH] 0014 Add final debug message in installers In-Reply-To: <4F4F5363.4030408@redhat.com> References: <4F44B860.9050809@redhat.com> <4F4BB48C.7010200@redhat.com> <1330535684.32367.30.camel@balmora.brq.redhat.com> <4F4E728C.2070109@redhat.com> <4F4F5363.4030408@redhat.com> Message-ID: <4F61C4BC.60809@redhat.com> On 03/01/2012 11:45 AM, Petr Viktorin wrote: > On 02/29/2012 07:46 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Mon, 2012-02-27 at 17:51 +0100, Petr Viktorin wrote: >>>> On 02/22/2012 10:41 AM, Petr Viktorin wrote: >>>>> This fixes https://fedorahosted.org/freeipa/ticket/2071 (Add final >>>>> debug >>>>> message in installers). The try/except blocks at the end of >>>>> installers/management scripts are replaced by a call to a common >>>>> function, which includes the final message. >>>>> >>>>> Obviously the installers still need some more love. This is as far >>>>> as I >>>>> got before Martin stopped me, saying I shouldn't change too much >>>>> before >>>>> a release :) >>>>> >>>>> >>>>> If it's still too many changes to test, I could just wrap the >>>>> blocks in >>>>> some `with add_final_message` block for now, and resubmit this patch >>>>> after the release. >>>>> >>>>> >>> >>> Yeah, this is exactly the kind of changes that can have yet-unseen >>> consequences and I don't like pushing this close to the release. >>> >>> The original ticket just asks for a debug message when the install >>> script ends. If possible, I would really prefer to have some low-risk >>> patch adding just those and leave install script refactoring for next >>> big release, like 3.x. Rob, what's your opinion on this? >>> >>> Martin >>> >> >> Yes, I agree. Simpler is better at this point. >> >> rob > > This patch simply wraps the try blocks in a context that logs the final > result. > Most of the changes are indentation; diff with -w to see the additions. > > Not sure if this would count as an update or a new patch... > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Rebased against current master. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0014-04-Add-final-debug-message-in-installers.patch Type: text/x-patch Size: 29999 bytes Desc: not available URL: From jcholast at redhat.com Thu Mar 15 10:36:44 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 15 Mar 2012 11:36:44 +0100 Subject: [Freeipa-devel] [PATCHES] Improve framework parameter validation Message-ID: <4F61C63C.2050006@redhat.com> (this is a continuation of ) Hi, the attached patches fix and : [PATCH] Fix the procedure for getting default values of command parameters. The parameters used in default_from of other parameters are now properly validated before the default_from is called. [PATCH] Change parameters to use only default_from for dynamic default values. Replace all occurences of create_default with equivalent default_from and remove create_default from the framework. This is needed for proper parameter validation, as there is no way to tell which parameters to validate prior to calling create_default, because create_default does not provide information about which parameters are used for generating the default value. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-44.3-parameter-validation.patch Type: text/x-patch Size: 9322 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-47.3-parameter-remove-create-default.patch Type: text/x-patch Size: 13047 bytes Desc: not available URL: From jcholast at redhat.com Thu Mar 15 11:05:44 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 15 Mar 2012 12:05:44 +0100 Subject: [Freeipa-devel] [PATCHES] Improve framework parameter validation In-Reply-To: <4F61C63C.2050006@redhat.com> References: <4F61C63C.2050006@redhat.com> Message-ID: <4F61CD08.8090905@redhat.com> On 15.3.2012 11:36, Jan Cholasta wrote: > (this is a continuation of > ) > > > Hi, > > the attached patches fix > and : > > [PATCH] Fix the procedure for getting default values of command parameters. > > The parameters used in default_from of other parameters are now properly > validated before the default_from is called. > > [PATCH] Change parameters to use only default_from for dynamic default > values. > > Replace all occurences of create_default with equivalent default_from > and remove create_default from the framework. This is needed for proper > parameter validation, as there is no way to tell which parameters to > validate prior to calling create_default, because create_default does > not provide information about which parameters are used for generating > the default value. > > Honza > Forgot to remove one FIXME bit in dns.py. Update patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-44.4-parameter-validation.patch Type: text/x-patch Size: 10028 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-47.4-parameter-remove-create-default.patch Type: text/x-patch Size: 13047 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 15 13:00:21 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Mar 2012 14:00:21 +0100 Subject: [Freeipa-devel] [PATCH] 237 Improve user awareness about dnsconfig Message-ID: <1331816421.27127.18.camel@balmora.brq.redhat.com> Global DNS configuration is a nice tool to maintain a common DNS settings stored in LDAP which are then used for all enrolled IPA servers. However, the settings stored in LDAP override local settings in named.conf on DNS servers. This patch adds more information about global DNS configuration options in install scripts and DNS module help. https://fedorahosted.org/freeipa/ticket/2525 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-237-improve-user-awareness-about-dnsconfig.patch Type: text/x-patch Size: 5741 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 15 13:15:33 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 15 Mar 2012 14:15:33 +0100 Subject: [Freeipa-devel] [PATCH] 0028 Remove ipausers' gidnumber from tests Message-ID: <4F61EB75.6080800@redhat.com> Here's an one-liner: don't test for the gidnumber attribute on ipausers, since it's not there by default now. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0028-Remove-ipausers-gidnumber-from-tests.patch Type: text/x-patch Size: 1123 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 15 13:20:13 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 15 Mar 2012 14:20:13 +0100 Subject: [Freeipa-devel] [PATCHES] Improve framework parameter validation In-Reply-To: <4F61CD08.8090905@redhat.com> References: <4F61C63C.2050006@redhat.com> <4F61CD08.8090905@redhat.com> Message-ID: <4F61EC8D.5050208@redhat.com> On 03/15/2012 12:05 PM, Jan Cholasta wrote: > On 15.3.2012 11:36, Jan Cholasta wrote: >> (this is a continuation of >> ) >> >> >> >> Hi, >> >> the attached patches fix >> and : >> >> [PATCH] Fix the procedure for getting default values of command >> parameters. >> >> The parameters used in default_from of other parameters are now properly >> validated before the default_from is called. >> >> [PATCH] Change parameters to use only default_from for dynamic default >> values. >> >> Replace all occurences of create_default with equivalent default_from >> and remove create_default from the framework. This is needed for proper >> parameter validation, as there is no way to tell which parameters to >> validate prior to calling create_default, because create_default does >> not provide information about which parameters are used for generating >> the default value. >> >> Honza >> > > Forgot to remove one FIXME bit in dns.py. Update patch attached. > > Honza > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > index a10960a..61c645d 100644 > --- a/ipalib/plugins/dns.py > +++ b/ipalib/plugins/dns.py > @@ -1528,7 +1528,7 @@ class dnszone(LDAPObject): > label=_('SOA serial'), > doc=_('SOA record serial number'), > minvalue=1, > - create_default=_create_zone_serial, > + default_from=_create_zone_serial, > autofill=True, > ), > Int('idnssoarefresh', > diff --git a/ipalib/plugins/passwd.py b/ipalib/plugins/passwd.py > index b26f7e9..9bee314 100644 > --- a/ipalib/plugins/passwd.py > +++ b/ipalib/plugins/passwd.py > @@ -69,7 +69,7 @@ class passwd(Command): > label=_('User name'), > primary_key=True, > autofill=True, > - create_default=lambda **kw: util.get_current_principal(), > + default_from=lambda: util.get_current_principal(), > normalizer=lambda value: normalize_principal(value), > ), > Password('password', This is just a minor nitpick, but I'd like to know if there's a reason behind it: why are you sometimes using lambda and sometimes not? The patch works well here, but I think I'm not the one to ack it. -- Petr? From pvoborni at redhat.com Thu Mar 15 13:52:34 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Mar 2012 14:52:34 +0100 Subject: [Freeipa-devel] [PATCH] 109 Fixed rpm build warning - extension.js listed twice In-Reply-To: <4F60ADC0.1090202@redhat.com> References: <4F60ADC0.1090202@redhat.com> Message-ID: <4F61F422.10701@redhat.com> Attached updated patch with totally different approach (thanks Endi). This patch moves extension.js to new directory: 'ext'. Ext directory should serve as a place for user extensions. It eliminated the problem. On 03/14/2012 03:40 PM, Petr Vobornik wrote: > First, I have to say that I'm new to rpm specs and I don't like this > patch but I don't have better solution. > > Problem: > Building the ipa rpms returns this: > warning: File listed twice: /usr/share/ipa/ui/extension.js > > Cause: > This is because of a glob: > %{_usr}/share/ipa/ui/*.js > > and then more specifically: > %config(noreplace) %{_usr}/share/ipa/ui/extension.js > > https://fedorahosted.org/freeipa/ticket/2253 > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0109-1-Fixed-rpm-build-warning-extension.js-listed-twice.patch Type: text/x-patch Size: 3676 bytes Desc: not available URL: From jcholast at redhat.com Thu Mar 15 13:57:43 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 15 Mar 2012 14:57:43 +0100 Subject: [Freeipa-devel] [PATCHES] Improve framework parameter validation In-Reply-To: <4F61EC8D.5050208@redhat.com> References: <4F61C63C.2050006@redhat.com> <4F61CD08.8090905@redhat.com> <4F61EC8D.5050208@redhat.com> Message-ID: <4F61F557.2040003@redhat.com> On 15.3.2012 14:20, Petr Viktorin wrote: > On 03/15/2012 12:05 PM, Jan Cholasta wrote: >> On 15.3.2012 11:36, Jan Cholasta wrote: >>> (this is a continuation of >>> ) >>> >>> >>> >>> >>> Hi, >>> >>> the attached patches fix >>> and : >>> >>> [PATCH] Fix the procedure for getting default values of command >>> parameters. >>> >>> The parameters used in default_from of other parameters are now properly >>> validated before the default_from is called. >>> >>> [PATCH] Change parameters to use only default_from for dynamic default >>> values. >>> >>> Replace all occurences of create_default with equivalent default_from >>> and remove create_default from the framework. This is needed for proper >>> parameter validation, as there is no way to tell which parameters to >>> validate prior to calling create_default, because create_default does >>> not provide information about which parameters are used for generating >>> the default value. >>> >>> Honza >>> >> >> Forgot to remove one FIXME bit in dns.py. Update patch attached. >> >> Honza > > > > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > > index a10960a..61c645d 100644 > > --- a/ipalib/plugins/dns.py > > +++ b/ipalib/plugins/dns.py > > @@ -1528,7 +1528,7 @@ class dnszone(LDAPObject): > > label=_('SOA serial'), > > doc=_('SOA record serial number'), > > minvalue=1, > > - create_default=_create_zone_serial, > > + default_from=_create_zone_serial, > > autofill=True, > > ), > > Int('idnssoarefresh', > > diff --git a/ipalib/plugins/passwd.py b/ipalib/plugins/passwd.py > > index b26f7e9..9bee314 100644 > > --- a/ipalib/plugins/passwd.py > > +++ b/ipalib/plugins/passwd.py > > @@ -69,7 +69,7 @@ class passwd(Command): > > label=_('User name'), > > primary_key=True, > > autofill=True, > > - create_default=lambda **kw: util.get_current_principal(), > > + default_from=lambda: util.get_current_principal(), > > normalizer=lambda value: normalize_principal(value), > > ), > > Password('password', > > > This is just a minor nitpick, but I'd like to know if there's a reason > behind it: why are you sometimes using lambda and sometimes not? I use lambda as a protective measure against accidents caused by adding optional arguments to the functions used. _create_zone_serial is an exception to that rule, because it is private to the dns plugin. > > The patch works well here, but I think I'm not the one to ack it. > Honza -- Jan Cholasta From pvoborni at redhat.com Thu Mar 15 15:11:03 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Mar 2012 16:11:03 +0100 Subject: [Freeipa-devel] [PATCH] 108 Better hbactest validation message In-Reply-To: <4F60A780.6070106@redhat.com> References: <4F5DF893.4000408@redhat.com> <4F60A780.6070106@redhat.com> Message-ID: <4F620687.7000207@redhat.com> On 03/14/2012 03:13 PM, Endi Sukma Dewata wrote: > On 3/12/2012 8:22 AM, Petr Vobornik wrote: >> HBAC Test validation message now contains all missing values in form of >> list of links instead of general 'missing values' message and >> redirection to first missing value's facet. >> >> When a link is clicked user is redirected to value's facet. >> >> https://fedorahosted.org/freeipa/ticket/2182 >> >> Note: In a list I chose to display an option label instead of facet >> label. IMHO it seems better with message 'Missing values'. > > It looks good. ACK. > Pushed to master, ipa-2-2. -- Petr Vobornik From pvoborni at redhat.com Thu Mar 15 15:11:19 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Mar 2012 16:11:19 +0100 Subject: [Freeipa-devel] [PATCH] 107 Fixed evaluating checkbox dirty status In-Reply-To: <4F60A704.2040806@redhat.com> References: <4F5A3BD3.7070703@redhat.com> <4F60A704.2040806@redhat.com> Message-ID: <4F620697.30303@redhat.com> On 03/14/2012 03:11 PM, Endi Sukma Dewata wrote: > ACK. I have some comments below. Pushed to master, ipa-2-2. > > On 3/9/2012 11:20 AM, Petr Vobornik wrote: >> Problem: >> When value in checkbox is modified twice in a row (so it is at its >> original value) an 'undo' button is still visible even when it shouldn't >> be. >> >> Cause: >> IPA server sends boolean values as 'TRUE' or 'FALSE' (strings). >> Checkbox_widget converts them to JavaScript? boolean (true, false). Save >> method in checkbox_widget is returning array with a boolean. So >> test_dirty method always evaluates to dirty because 'FALSE' != false. >> >> This patch is fixing the problem. >> >> Note (future enhancements): >> As we were talking before about making fields less dependent on widget >> types. The dependency comes from the fact that dirty evaluation is in >> field. I plan to move the core to widget. I'm thinking about something >> like: >> Widget would have: >> * input value parser - ie for parsing strings to booleans - configurable >> * original value (parsed) >> * inner state (inner_save()) >> * is_dirty() - compare inner state with original value >> * output formatter - can make boolean back to strings (just example) - >> configurable >> * save() would return array of formatted values >> >> Field: >> * load(record) would pick values from record as now >> * is_dirty - needed for facets. Would be: dirty = 'one of associated >> widgets is dirty' >> * save() - merge associated widgets values - usually only on array from >> one widget >> >> Maybe input and output formatters should be in field. > > We might need it in both field and widget. There are 3 different values > that we need to consider: > * stored value (LDAP), e.g. TRUE/FALSE > * internal value (JavaScript), e.g. true/false > * external value (human readable), e.g. True/False > > The field will be responsible for converting between stored and internal > value. The widget will be responsible for converting between internal & > external value if needed. > > Suppose we want to display a boolean attribute using a checkbox. We will > need a boolean field which will convert TRUE/FALSE into true/false. Then > we also need a standard checkbox that displays true as checked and false > as unchecked. > > Suppose we want to display the boolean attribute in a table column. We > should be able to use the same boolean field, but then we use a boolean > column that converts true/false into True/False. > -- Petr Vobornik From mkosek at redhat.com Thu Mar 15 15:14:25 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Mar 2012 16:14:25 +0100 Subject: [Freeipa-devel] [PATCH] 238 Improve automount indirect map error message Message-ID: <1331824465.27127.19.camel@balmora.brq.redhat.com> When user does not pass a name of parent map in automountmap-add-indirect command, auto.master is used as a default. However, when auto.master does not exist in a given location, we raise NotFound error with a name of a location instead of a name of the missing automount map. https://fedorahosted.org/freeipa/ticket/2387 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-238-improve-automount-indirect-map-error-message.patch Type: text/x-patch Size: 1393 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 15 17:31:54 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 13:31:54 -0400 Subject: [Freeipa-devel] [PATCH] 986 remove unnecessary serial conversions Message-ID: <4F62278A.3070700@redhat.com> This is related to my patch 924. Petr Viktorin noticed a couple of serial to hex conversions were wrong and it turns out they aren't needed at all. This patch removes them. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-986-serial.patch Type: text/x-diff Size: 1788 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 15 17:32:41 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 13:32:41 -0400 Subject: [Freeipa-devel] [PATCH] 924 display both hex and decimal serial numbers In-Reply-To: <4F61BE55.2070700@redhat.com> References: <4F108BAA.2020604@redhat.com> <4F1459E3.4050309@redhat.com> <4F146DEA.5070204@redhat.com> <4F149069.4060704@redhat.com> <4F158FCD.4040604@redhat.com> <4F15FE63.8090209@redhat.com> <4F16A0FB.9080808@redhat.com> <4F1DDA53.6090206@redhat.com> <4F567A19.8070408@redhat.com> <4F57855F.10208@redhat.com> <4F5788E8.4010102@redhat.com> <4F58D372.4090102@redhat.com> <4F5FC2CD.1090201@redhat.com> <4F61BE55.2070700@redhat.com> Message-ID: <4F6227B9.7030708@redhat.com> Petr Viktorin wrote: > On 03/13/2012 10:57 PM, Rob Crittenden wrote: >> Jan Cholasta wrote: > ..snip.. >>> >>> This patch works for me, but let me repeat myself: >>> >>> > BTW, wouldn't it make sense to format serial numbers in the cert >>> > plugin in the same way? >>> >>> Honza >>> >> >> Updated. >> >> rob >> >> > > > diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py > index > b31058c1418f7f73854f7ac06701fb6f821a2e40..b56e04f4d8675c34cc5e7db42a1b45402ef79084 > 100644 > --- a/ipaserver/plugins/dogtag.py > +++ b/ipaserver/plugins/dogtag.py > @@ -609,6 +609,7 @@ def parse_profile_submit_result_xml(doc): > if len(serial_number) == 1: > serial_number = int(serial_number[0].text, 16) # parse as hex > response_request['serial_number'] = serial_number > + response['serial_number_hex'] = u'0x%X' % serial_number > > > Why are you adding serial_number_hex to the entire response, when > serial_number is on the individual response_request? (same in > parse_revoke_cert_xml) > > I think you should also update the docstrings with the new item. > What docstrings are those? These calls aren't needed at all. I submitted a new patch, 986, to remove them. rob From rcritten at redhat.com Thu Mar 15 18:59:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 14:59:13 -0400 Subject: [Freeipa-devel] [PATCH] 937 configure /etc/openldap/ldap.conf In-Reply-To: <1328104208.21059.20.camel@willson.li.ssimo.org> References: <4F28BEBB.20008@redhat.com> <1328104208.21059.20.camel@willson.li.ssimo.org> Message-ID: <4F623C01.6030209@redhat.com> Simo Sorce wrote: > On Tue, 2012-01-31 at 23:25 -0500, Rob Crittenden wrote: >> Configure the openldap configuration file with the basics for IPA. >> This >> is mostly to make querying with StartTLS easier but it does make >> ldapsearch a lot nicer in general. >> >> I got a little carried away with the man page. I wanted to include >> that >> we were updating yet another configuration file and found no FILES >> section at all so I added one. I think I caught every file we update, >> it >> is the bulk in any case. >> > Ack > > Simo. > Rebased and pushed to master and ipa-2-2 rob From rcritten at redhat.com Thu Mar 15 19:18:11 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 15:18:11 -0400 Subject: [Freeipa-devel] dns_discovery_domain for clients outside server domain In-Reply-To: References: Message-ID: <4F624073.5010104@redhat.com> Lars Sj?str?m wrote: > Hello, > > I have prepared a patch for https://fedorahosted.org/freeipa/ticket/2209 > > Feedback appreciated. > > Best regards, > Lars ACK, pushed to master and ipa-2-2 rob From rcritten at redhat.com Thu Mar 15 19:55:06 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 15:55:06 -0400 Subject: [Freeipa-devel] [PATCH] 0015 Only split CSV strings once In-Reply-To: <4F464D59.2020601@redhat.com> References: <4F464D59.2020601@redhat.com> Message-ID: <4F62491A.7080105@redhat.com> Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/2227 (Unable to add certain sudo > commands to groups). What an interesting bug to get :) > > > One problem with our CSV splitting is that it's not idempotent > (baskslashes are "eaten" when there are escaped commas), but when we > forward a call it gets done on both the client and the server. The > attached patch fixes that in a somewhat hacky way. It's not a complete > fix for the issue though, for that I need to ask what to do. > > > Some Params use the CSV format when we just need a list of > comma-separated values. Our flavor of CSV does escaping in two different > ways. This is pretty bad for predictability, least-surprise, > documentation, ... > > To recap, the two ways are escaping (escaped commas are ignored, > backslashes also need to be escaped) and quoting (values are optionally > enclosed in double quotes, to include a '"' in a quoted string, use '""'). > Escaping is good because users are used to it, but currently literal > backslashes need to be doubled, making multivalue syntax different from > single-value syntax, even if there are no commas in the value. > Quoting is weird, but complete by itself so it doesn't also need escaping. > > Do we need to use both? Is this documented somewhere? Some of our tests > check only for one, some assume the other. Users are probably even more > confused. > > > If we only keep one of those, the fix for #2227 should be quite easy. > If not (backwards compatibility), we need to document this properly, > test all the corner cases, and fix the UI to handle CSV escaping. > Since it's subtly broken in lots of places, maybe it's best to break > backwards compatibility and go for a simple solution now. > > Anyway, if I want to do a proper fix, CSV handling should be only done > on the client. Unfortunately turning off CSV handling in the server will > break the UI, which at places uses `join(',')` (no escaping commas, no > single place to change it), even though it can just send a list. I'm with Honza, not too keen on the _forwarded_call part. I'd rather you do a mix of comparing self.env.in_server and whether the value is a basestring to determine if we need to split it. I'm not sure why this is broken out of normalize. Isn't this normalizing the incoming values into something more sane? rob From rcritten at redhat.com Thu Mar 15 20:24:01 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 16:24:01 -0400 Subject: [Freeipa-devel] [PATCHES] 0016 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F4F46C9.6030804@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F4E4586.2070805@redhat.com> <4F4F46C9.6030804@redhat.com> Message-ID: <4F624FE1.2080000@redhat.com> Petr Viktorin wrote: > On 02/29/2012 04:34 PM, Petr Viktorin wrote: >> On 02/29/2012 03:50 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> Patch 16 defers validation & conversion until after >>>>>> {add,del,set}attr is >>>>>> processed, so that we don't search for an integer in a list of >>>>>> strings >>>>>> (this caused ticket #2405), and so that the end result of these >>>>>> operations is validated (#2407). >>>>>> >>>>>> >>>>>> Patch 17 makes these options honor params marked no_create and >>>>>> no_update. >>>>>> >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/2405 >>>>>> https://fedorahosted.org/freeipa/ticket/2407 >>>>>> https://fedorahosted.org/freeipa/ticket/2408 >>>>> >>>>> NACK on Patch 17 which breaks patch 16. >>>> >>>> How is patch 16 broken? It works for me. >>> >>> My point is they rely on one another, IMHO, so without 17 the reported >>> problem still exists. >>> >>>> >>>>> *attr is specifically made to be powerful. We don't want to >>>>> arbitrarily >>>>> block updating certain values. >>>> >>>> Noted >>>> >>>>> Not having patch 17 means that the problem reported in 2408 still >>>>> occurs. It should probably check both the schema and the param to >>>>> determine if something can have multiple values and reject that way. >>>> >>>> I see the problem now: the certificate subject base is defined as a >>>> multi-value attribute in the LDAP schema. If it's changed to >>>> single-value the existing validation should catch it. >>>> >>>> Also, most of the config attributes should probably be required in the >>>> schema. Am I right? >>>> >>>> I'm a newbie here; what do I need to do when changing the schema? Is >>>> there a patch that does something similar I could use as an example? >>>> >>> >>> The framework should be able to impose its own single-value will as >>> well. If a Param is designated as single-value the *attr should honor >>> it. >> >> Here is the updated patch. >> Since *attr is powerful enough to modify 'no_update' Params, which >> CRUDUpdate forgets about, I need to check the params of the LDAPObject >> itself. >> >>> Updating schema is a bit of a nasty business right now. See >>> 10-selinuxusermap.update for an example. >> >> I'll leave schema changes for after the release, then. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Attached patch includes tests. Note that the test depends on my patches > 12-13, which make ipasearchrecordslimit required. I gather that this eliminates the need for patch 17? It seems to work as-is. The patch doesn't apply because of an encoding change Martin made recently. It does seem to do the right thing though. rob From rcritten at redhat.com Thu Mar 15 21:04:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 17:04:29 -0400 Subject: [Freeipa-devel] [PATCH] 987 Don't allow IPA master hosts and services to be disabled Message-ID: <4F62595D.6070000@redhat.com> Don't allow IPA master hosts and services to be disabled. This expands on the "don't allow them to be deleted" patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-987-masterdisable.patch Type: text/x-diff Size: 11610 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 15 21:05:08 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 17:05:08 -0400 Subject: [Freeipa-devel] [PATCH] 988 fix host test Message-ID: <4F625984.2090903@redhat.com> A test to make sure hosts can be renamed using setattr is using an invalid hostname so the host_mod will never get hit. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-988-hosttest.patch Type: text/x-diff Size: 1028 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 15 21:08:15 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 17:08:15 -0400 Subject: [Freeipa-devel] [PATCH] 0028 Remove ipausers' gidnumber from tests In-Reply-To: <4F61EB75.6080800@redhat.com> References: <4F61EB75.6080800@redhat.com> Message-ID: <4F625A3F.1000807@redhat.com> Petr Viktorin wrote: > Here's an one-liner: don't test for the gidnumber attribute on ipausers, > since it's not there by default now. ACK, pushed to master and ipa-2-2 From rcritten at redhat.com Thu Mar 15 21:36:42 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 17:36:42 -0400 Subject: [Freeipa-devel] [PATCH] 0024 Fix expected exception checking in tests In-Reply-To: <4F5A306B.9090001@redhat.com> References: <4F5A306B.9090001@redhat.com> Message-ID: <4F6260EA.6080308@redhat.com> Petr Viktorin wrote: > Can you spot the bug in this test code? > > try: > do_invalid_operation() > except ExpectedError: > pass > > > Our test suite had several of those. > Nose provides nice tools, `raises` (a decorator) and `assert_raises` (a > context manager) that make checking expected exceptions a lot easier and > less error-prone. This patch makes our tests use them. > > If you didn't catch it, the error is that the test will pass when no > exception is raised. Some of our tests handled that by adding an `else: > assert False`, or an `assert False` at the end of the try block. > For consistency, the patch switches these correct ones to > raises/assert_raises as well. > > I've also uncovered and fixed a few test bugs that were hidden by this. > test_1a_automountmap_add_indirect() was failing, checking for the wrong exception. I also suggest using @raises for clarity in another spot. Here are my suggested changes: diff --git a/tests/test_xmlrpc/test_automount_plugin.py b/tests/test_xmlrpc/test _automount_plugin.py index 6abc44f..dedd234 100644 --- a/tests/test_xmlrpc/test_automount_plugin.py +++ b/tests/test_xmlrpc/test_automount_plugin.py @@ -79,12 +79,12 @@ class test_automount(XMLRPC_test): assert res assert_attr_equal(res, 'automountkey', self.keyname) + @raises(errors.DuplicateEntry) def test_4_automountkey_add(self): """ Test adding a duplicate key using `xmlrpc.automountkey_add` method. """ - with assert_raises(errors.DuplicateEntry): - api.Command['automountkey_add'](self.locname, self.mapname, **self. key_kw) + res = api.Command['automountkey_add'](self.locname, self.mapname, **sel f.key_kw) def test_5_automountmap_show(self): """ @@ -247,12 +247,12 @@ class test_automount_indirect(XMLRPC_test): assert res assert_attr_equal(res, 'automountmapname', self.mapname) + @raises(errors.DuplicateEntry) def test_1a_automountmap_add_indirect(self): """ Test adding a duplicate indirect map. """ - with assert_raises(errors.NotFound): - api.Command['automountmap_add_indirect'](self.locname, self.mapname , **self.map_kw)['result'] + api.Command['automountmap_add_indirect'](self.locname, self.mapname, ** self.map_kw)['result'] def test_2_automountmap_show(self): """ From jcholast at redhat.com Fri Mar 16 08:00:08 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 16 Mar 2012 09:00:08 +0100 Subject: [Freeipa-devel] [PATCHES] 0016-17 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F4E3B2F.3040609@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> Message-ID: <4F62F308.9000604@redhat.com> On 29.2.2012 15:50, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> Patch 16 defers validation & conversion until after >>>> {add,del,set}attr is >>>> processed, so that we don't search for an integer in a list of strings >>>> (this caused ticket #2405), and so that the end result of these >>>> operations is validated (#2407). >>>> >>>> >>>> Patch 17 makes these options honor params marked no_create and >>>> no_update. >>>> >>>> >>>> https://fedorahosted.org/freeipa/ticket/2405 >>>> https://fedorahosted.org/freeipa/ticket/2407 >>>> https://fedorahosted.org/freeipa/ticket/2408 >>> >>> NACK on Patch 17 which breaks patch 16. >> >> How is patch 16 broken? It works for me. > > My point is they rely on one another, IMHO, so without 17 the reported > problem still exists. > >> >>> *attr is specifically made to be powerful. We don't want to arbitrarily >>> block updating certain values. >> >> Noted >> >>> Not having patch 17 means that the problem reported in 2408 still >>> occurs. It should probably check both the schema and the param to >>> determine if something can have multiple values and reject that way. >> >> I see the problem now: the certificate subject base is defined as a >> multi-value attribute in the LDAP schema. If it's changed to >> single-value the existing validation should catch it. >> >> Also, most of the config attributes should probably be required in the >> schema. Am I right? >> >> I'm a newbie here; what do I need to do when changing the schema? Is >> there a patch that does something similar I could use as an example? >> > > The framework should be able to impose its own single-value will as > well. If a Param is designated as single-value the *attr should honor it. Is that so? Isn't *attr supposed to allow the user to modify attributes at LDAP level, i.e. skip the usual framework constraints? > > Updating schema is a bit of a nasty business right now. See > 10-selinuxusermap.update for an example. > > rob > Honza -- Jan Cholasta From mkosek at redhat.com Fri Mar 16 09:45:31 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 Mar 2012 10:45:31 +0100 Subject: [Freeipa-devel] [PATCH] 239 Tolerate UDP port failures in conncheck Message-ID: <1331891131.27127.23.camel@balmora.brq.redhat.com> UDP port checks in ipa-replica-conncheck are too strict. The entire conncheck fails when UDP ports cannot be verified as open. However, UDP protocol is unrealiable by its nature and the port can also not be checked if there is an application already bound to it. This can happen for example when ipa-replica-conncheck is run as a part of ipa-ca-install and the replica services are thus already running. This patch changes the behavior of UDP port checks. The conncheck script now rather reports a warning that UDP port cannot be verified but does not fail the entire test. https://fedorahosted.org/freeipa/ticket/2514 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-239-tolerate-udp-port-failures-in-conncheck.patch Type: text/x-patch Size: 2769 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 16 11:55:20 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Mar 2012 12:55:20 +0100 Subject: [Freeipa-devel] [PATCH] 0015 Only split CSV strings once In-Reply-To: <4F62491A.7080105@redhat.com> References: <4F464D59.2020601@redhat.com> <4F62491A.7080105@redhat.com> Message-ID: <4F632A28.9060608@redhat.com> On 03/15/2012 08:55 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> https://fedorahosted.org/freeipa/ticket/2227 (Unable to add certain sudo >> commands to groups). What an interesting bug to get :) >> >> >> One problem with our CSV splitting is that it's not idempotent >> (baskslashes are "eaten" when there are escaped commas), but when we >> forward a call it gets done on both the client and the server. The >> attached patch fixes that in a somewhat hacky way. It's not a complete >> fix for the issue though, for that I need to ask what to do. >> >> >> Some Params use the CSV format when we just need a list of >> comma-separated values. Our flavor of CSV does escaping in two different >> ways. This is pretty bad for predictability, least-surprise, >> documentation, ... >> >> To recap, the two ways are escaping (escaped commas are ignored, >> backslashes also need to be escaped) and quoting (values are optionally >> enclosed in double quotes, to include a '"' in a quoted string, use >> '""'). >> Escaping is good because users are used to it, but currently literal >> backslashes need to be doubled, making multivalue syntax different from >> single-value syntax, even if there are no commas in the value. >> Quoting is weird, but complete by itself so it doesn't also need >> escaping. >> >> Do we need to use both? Is this documented somewhere? Some of our tests >> check only for one, some assume the other. Users are probably even more >> confused. >> >> >> If we only keep one of those, the fix for #2227 should be quite easy. >> If not (backwards compatibility), we need to document this properly, >> test all the corner cases, and fix the UI to handle CSV escaping. >> Since it's subtly broken in lots of places, maybe it's best to break >> backwards compatibility and go for a simple solution now. >> >> Anyway, if I want to do a proper fix, CSV handling should be only done >> on the client. Unfortunately turning off CSV handling in the server will >> break the UI, which at places uses `join(',')` (no escaping commas, no >> single place to change it), even though it can just send a list. > > I'm with Honza, not too keen on the _forwarded_call part. I'd rather you > do a mix of comparing self.env.in_server and whether the value is a > basestring to determine if we need to split it. This was a hack necessary because the WebUI relied on server-side splitting (in a few cases, and it did not escape correctly). Now that Petr Vobornik's patch 99 is in, it is unnecessary. This discussion thread has an updated patch (0015-03); what I'm attaching now builds on top of that to add several new changes in tests. To summarize it: the splitting is only done in the client; from the RPC call on no CSV magic is involved at all. Please tell me your reasons for basestring checking. I think it's entirely unnecessary and just adds complexity. In the rest of the framework a string, as a parameter value, has the same effect as a list of that one string. Why break this? We are concerned about the API here, not the command line. Shortcuts to save the user's keystrokes in the common case should *not* win over predictability and making sure the easier way is the correct, robust way to do it. Compare -- with basestring checking: some_command(arg=escape_commas(some_string)) - is correct some_command(arg=[some_string]) - is also correct some_command(arg=some_string) - is WRONG because the string is not escaped - but is the easiest solution! The problem is much worse because it is subtle: it only affects values with commas and backslashes, so *the wrong solution would work* in most of the cases. And I can assure you plugin writers *would* pick the wrong way if it would usually work. Our own web UI had examples. Contrast to my proposed behavior: some_command(arg=some_string) - is correct some_command(arg=[some_string]) - is also correct some_command(arg=escape_commas(some_string)) - is wrong, but doesn't make much sense because at this level you don't have to worry about CSV at all Basestring checking would add unnecessary complexity for both us *and* the plugin writer. The only case it would make it easier for the plugin writer is if the plugin took CSV values ?-- but why force a random format, tailored for our specific frontend, into RPC clients? The client should translate the command line into a RPC call. There's no reason to arbitrarily expect the server to do part of the job. > I'm not sure why this is broken out of normalize. Isn't this normalizing > the incoming values into something more sane? "Normalization" implies it's an idempotent operation, which CSV splitting is not (at least its current incarnation, without the basestring checking): r"a,b\,c" splits to ["a", "b,c"] which splits to ["a", "b", "c"] ----- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0015-04-Only-split-CSV-in-the-client.patch Type: text/x-patch Size: 14022 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 16 12:02:37 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Mar 2012 13:02:37 +0100 Subject: [Freeipa-devel] [PATCH] 0021 Add CLI tests In-Reply-To: <4F5F2E39.2020301@redhat.com> References: <4F575A01.1060501@redhat.com> <4F5E5A22.1010109@redhat.com> <4F5F2E39.2020301@redhat.com> Message-ID: <4F632BDD.1000608@redhat.com> On 03/13/2012 12:23 PM, Petr Viktorin wrote: > On 03/12/2012 09:18 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> Most of the tests we have check if the server does the right thing with >>> XML-RPC calls. How the commandline is converted to command arguments, >>> including interactive prompting, is untested. >>> This patch adds some tests in this area. To do that I had to break up >>> cli.run into more manageable pieces, and initialize the CLI plugins in >>> test mode. >>> >>> Also I added nose's --nocapture option to the make-test script. With >>> this it's possible to use pdb.set_trace() to drop into a debugger while >>> running the tests. >>> >>> >>> I went ahead and added a test for ticket 2484, fixed in Martin's patch >>> 231 (Ignore case in yes/no prompts). >>> >> >> John had done similar work with --nocapture a while back but it is still >> pending. Perhaps we can merge his changes in with yours, they look >> largely overlapping. His patch is [PATCH 54/54] ticet 2135 - enhance >> make-test for debugging >> >> rob > > I guess it'll be better to make that a separate patch, then. This > updated patch doesn't contain the make-test change. > Updating the patch to also test the CSV splitting in my patch 0015.04 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0021-03-Add-CLI-parsing-tests.patch Type: text/x-patch Size: 9293 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 16 12:10:23 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Mar 2012 13:10:23 +0100 Subject: [Freeipa-devel] [PATCH] 987 Don't allow IPA master hosts and services to be disabled In-Reply-To: <4F62595D.6070000@redhat.com> References: <4F62595D.6070000@redhat.com> Message-ID: <4F632DAF.7050307@redhat.com> On 03/15/2012 10:04 PM, Rob Crittenden wrote: > diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py > index 9562ff98729ead6ac9e56d504f6ee0a7c0ca377a..f3c89a0fc5e3f00ed7f132dbff2510d89bc7370d 100644 > --- a/ipalib/plugins/baseldap.py > +++ b/ipalib/plugins/baseldap.py > @@ -887,12 +877,29 @@ last, after all sets and adds."""), > # normalize all values > changedattrs = setattrs | addattrs | delattrs > for attr in changedattrs: > - # remove duplicite and invalid values > - entry_attrs[attr] = list(set([val for val in entry_attrs[attr] if val])) > - if not entry_attrs[attr]: > - entry_attrs[attr] = None > - elif isinstance(entry_attrs[attr], (tuple, list)) and len(entry_attrs[attr]) == 1: > - entry_attrs[attr] = entry_attrs[attr][0] > + if attr in self.obj.params: > + # convert single-value params to scalars > + # Need to use the LDAPObject's params, not self's, because the > + # CRUD classes filter their disallowed parameters out. > + # Yet {set,add,del}attr are powerful enough to change these > + # (e.g. Config's ipacertificatesubjectbase) > + if not self.obj.params[attr].multivalue: > + if len(entry_attrs[attr]) == 1: > + entry_attrs[attr] = entry_attrs[attr][0] > + elif not entry_attrs[attr]: > + entry_attrs[attr] = None > + else: > + raise errors.OnlyOneValueAllowed(attr=attr) > + # validate and convert params > + entry_attrs[attr] = self.obj.params[attr](entry_attrs[attr]) > + else: > + # unknown attribute: remove duplicite and invalid values > + entry_attrs[attr] = list(set([val for val in entry_attrs[attr] if val])) > + if not entry_attrs[attr]: > + entry_attrs[attr] = None > + elif isinstance(entry_attrs[attr], (tuple, list)) and len(entry_attrs[attr]) == 1: > + entry_attrs[attr] = entry_attrs[attr][0] > + You've included an unrelated patch (my 0016). -- Petr? From pviktori at redhat.com Fri Mar 16 12:16:23 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Mar 2012 13:16:23 +0100 Subject: [Freeipa-devel] [PATCH] 986 remove unnecessary serial conversions In-Reply-To: <4F62278A.3070700@redhat.com> References: <4F62278A.3070700@redhat.com> Message-ID: <4F632F17.3060809@redhat.com> On 03/15/2012 06:31 PM, Rob Crittenden wrote: > This is related to my patch 924. Petr Viktorin noticed a couple of > serial to hex conversions were wrong and it turns out they aren't needed > at all. This patch removes them. > > rob On 03/15/2012 06:32 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> >> I think you should also update the docstrings with the new item. >> > > What docstrings are those? The big tables, such as: +----------------+---------------+-----------------+---------------+ |cms name |cms type |result name |result type | +================+===============+=================+===============+ |emailCert |Boolean |email_cert |bool | +----------------+---------------+-----------------+---------------+ |noCertImport |Boolean |no_cert_import |bool | +----------------+---------------+-----------------+---------------+ |revocationReason|int |revocation_reason|int [1]_ | +----------------+---------------+-----------------+---------------+ |certPrettyPrint |string |cert_pretty |unicode | +----------------+---------------+-----------------+---------------+ |authorityid |string |authority |unicode | +----------------+---------------+-----------------+---------------+ |certFingerprint |string |fingerprint |unicode | +----------------+---------------+-----------------+---------------+ |certChainBase64 |string |certificate |unicode [2]_ | +----------------+---------------+-----------------+---------------+ |serialNumber |string |serial_number |int|long | +----------------+---------------+-----------------+---------------+ |pkcs7ChainBase64|string |pkcs7_chain |unicode [2]_ | +----------------+---------------+-----------------+---------------+ etc. -- Petr? From rcritten at redhat.com Fri Mar 16 12:29:22 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 08:29:22 -0400 Subject: [Freeipa-devel] [PATCH] 987 Don't allow IPA master hosts and services to be disabled In-Reply-To: <4F632DAF.7050307@redhat.com> References: <4F62595D.6070000@redhat.com> <4F632DAF.7050307@redhat.com> Message-ID: <4F633222.2020903@redhat.com> Petr Viktorin wrote: > On 03/15/2012 10:04 PM, Rob Crittenden wrote: >> diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py >> index >> 9562ff98729ead6ac9e56d504f6ee0a7c0ca377a..f3c89a0fc5e3f00ed7f132dbff2510d89bc7370d >> 100644 >> --- a/ipalib/plugins/baseldap.py >> +++ b/ipalib/plugins/baseldap.py >> @@ -887,12 +877,29 @@ last, after all sets and adds."""), >> # normalize all values >> changedattrs = setattrs | addattrs | delattrs >> for attr in changedattrs: >> - # remove duplicite and invalid values >> - entry_attrs[attr] = list(set([val for val in entry_attrs[attr] if >> val])) >> - if not entry_attrs[attr]: >> - entry_attrs[attr] = None >> - elif isinstance(entry_attrs[attr], (tuple, list)) and >> len(entry_attrs[attr]) == 1: >> - entry_attrs[attr] = entry_attrs[attr][0] >> + if attr in self.obj.params: >> + # convert single-value params to scalars >> + # Need to use the LDAPObject's params, not self's, because the >> + # CRUD classes filter their disallowed parameters out. >> + # Yet {set,add,del}attr are powerful enough to change these >> + # (e.g. Config's ipacertificatesubjectbase) >> + if not self.obj.params[attr].multivalue: >> + if len(entry_attrs[attr]) == 1: >> + entry_attrs[attr] = entry_attrs[attr][0] >> + elif not entry_attrs[attr]: >> + entry_attrs[attr] = None >> + else: >> + raise errors.OnlyOneValueAllowed(attr=attr) >> + # validate and convert params >> + entry_attrs[attr] = self.obj.params[attr](entry_attrs[attr]) >> + else: >> + # unknown attribute: remove duplicite and invalid values >> + entry_attrs[attr] = list(set([val for val in entry_attrs[attr] if >> val])) >> + if not entry_attrs[attr]: >> + entry_attrs[attr] = None >> + elif isinstance(entry_attrs[attr], (tuple, list)) and >> len(entry_attrs[attr]) == 1: >> + entry_attrs[attr] = entry_attrs[attr][0] >> + > > You've included an unrelated patch (my 0016). > That's what I get for mixing my review and dev branch. Correct patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-987-masterdisable.patch Type: text/x-diff Size: 11610 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 16 12:59:02 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Mar 2012 13:59:02 +0100 Subject: [Freeipa-devel] [PATCH] 0024 Fix expected exception checking in tests In-Reply-To: <4F6260EA.6080308@redhat.com> References: <4F5A306B.9090001@redhat.com> <4F6260EA.6080308@redhat.com> Message-ID: <4F633916.4070005@redhat.com> On 03/15/2012 10:36 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> Can you spot the bug in this test code? >> >> try: >> do_invalid_operation() >> except ExpectedError: >> pass >> >> >> Our test suite had several of those. >> Nose provides nice tools, `raises` (a decorator) and `assert_raises` (a >> context manager) that make checking expected exceptions a lot easier and >> less error-prone. This patch makes our tests use them. >> >> If you didn't catch it, the error is that the test will pass when no >> exception is raised. Some of our tests handled that by adding an `else: >> assert False`, or an `assert False` at the end of the try block. >> For consistency, the patch switches these correct ones to >> raises/assert_raises as well. >> >> I've also uncovered and fixed a few test bugs that were hidden by this. >> > > > test_1a_automountmap_add_indirect() was failing, checking for the wrong > exception. Silly me. Thanks for catching this. > I also suggest using @raises for clarity in another spot. Here are my > suggested changes: > Attaching updated patch. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0024-02-Use-nose-tools-to-check-for-exceptions.patch Type: text/x-patch Size: 27500 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 16 13:07:37 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 09:07:37 -0400 Subject: [Freeipa-devel] [PATCHES] 0016-17 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F62F308.9000604@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F62F308.9000604@redhat.com> Message-ID: <4F633B19.8090707@redhat.com> Jan Cholasta wrote: > On 29.2.2012 15:50, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> Patch 16 defers validation & conversion until after >>>>> {add,del,set}attr is >>>>> processed, so that we don't search for an integer in a list of strings >>>>> (this caused ticket #2405), and so that the end result of these >>>>> operations is validated (#2407). >>>>> >>>>> >>>>> Patch 17 makes these options honor params marked no_create and >>>>> no_update. >>>>> >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2405 >>>>> https://fedorahosted.org/freeipa/ticket/2407 >>>>> https://fedorahosted.org/freeipa/ticket/2408 >>>> >>>> NACK on Patch 17 which breaks patch 16. >>> >>> How is patch 16 broken? It works for me. >> >> My point is they rely on one another, IMHO, so without 17 the reported >> problem still exists. >> >>> >>>> *attr is specifically made to be powerful. We don't want to arbitrarily >>>> block updating certain values. >>> >>> Noted >>> >>>> Not having patch 17 means that the problem reported in 2408 still >>>> occurs. It should probably check both the schema and the param to >>>> determine if something can have multiple values and reject that way. >>> >>> I see the problem now: the certificate subject base is defined as a >>> multi-value attribute in the LDAP schema. If it's changed to >>> single-value the existing validation should catch it. >>> >>> Also, most of the config attributes should probably be required in the >>> schema. Am I right? >>> >>> I'm a newbie here; what do I need to do when changing the schema? Is >>> there a patch that does something similar I could use as an example? >>> >> >> The framework should be able to impose its own single-value will as >> well. If a Param is designated as single-value the *attr should honor it. > > Is that so? Isn't *attr supposed to allow the user to modify attributes > at LDAP level, i.e. skip the usual framework constraints? If we make rules around an attribute they should be honored. If we have not then all bets are off. *attr was never really made to manage those attributes that IPA knows about, despite most of the testing being around that. It was to provide a way to manage things we don't support yet. rob From pviktori at redhat.com Fri Mar 16 13:14:56 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Mar 2012 14:14:56 +0100 Subject: [Freeipa-devel] [PATCHES] 0016-17 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F633B19.8090707@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F62F308.9000604@redhat.com> <4F633B19.8090707@redhat.com> Message-ID: <4F633CD0.8020103@redhat.com> I may be taking things out of context, but I see this: On 03/16/2012 02:07 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 29.2.2012 15:50, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: .. snip .. >>>>>> >>>>>> Patch 17 makes these options honor params marked no_create and >>>>>> no_update. >>>>>> .. snip .. >>>> >>>>> *attr is specifically made to be powerful. We don't want to >>>>> arbitrarily >>>>> block updating certain values. .. versus .. >>>> >>>> I see the problem now: the certificate subject base is defined as a >>>> multi-value attribute in the LDAP schema. If it's changed to >>>> single-value the existing validation should catch it. >>>> .. snip .. >>> >>> The framework should be able to impose its own single-value will as >>> well. If a Param is designated as single-value the *attr should honor >>> it. >> >> Is that so? Isn't *attr supposed to allow the user to modify attributes >> at LDAP level, i.e. skip the usual framework constraints? > > If we make rules around an attribute they should be honored. If we have > not then all bets are off. > > *attr was never really made to manage those attributes that IPA knows > about, despite most of the testing being around that. It was to provide > a way to manage things we don't support yet. which strikes me as inconsistent. -- Petr? From jcholast at redhat.com Fri Mar 16 13:24:51 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 16 Mar 2012 14:24:51 +0100 Subject: [Freeipa-devel] [PATCHES] 0016-17 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F633CD0.8020103@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F62F308.9000604@redhat.com> <4F633B19.8090707@redhat.com> <4F633CD0.8020103@redhat.com> Message-ID: <4F633F23.8040405@redhat.com> On 16.3.2012 14:14, Petr Viktorin wrote: > I may be taking things out of context, but I see this: > > On 03/16/2012 02:07 PM, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 29.2.2012 15:50, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: > .. snip .. >>>>>>> >>>>>>> Patch 17 makes these options honor params marked no_create and >>>>>>> no_update. >>>>>>> > .. snip .. >>>>> >>>>>> *attr is specifically made to be powerful. We don't want to >>>>>> arbitrarily >>>>>> block updating certain values. > > .. versus .. > >>>>> >>>>> I see the problem now: the certificate subject base is defined as a >>>>> multi-value attribute in the LDAP schema. If it's changed to >>>>> single-value the existing validation should catch it. >>>>> > .. snip .. >>>> >>>> The framework should be able to impose its own single-value will as >>>> well. If a Param is designated as single-value the *attr should honor >>>> it. >>> >>> Is that so? Isn't *attr supposed to allow the user to modify attributes >>> at LDAP level, i.e. skip the usual framework constraints? >> >> If we make rules around an attribute they should be honored. If we have >> not then all bets are off. >> >> *attr was never really made to manage those attributes that IPA knows >> about, despite most of the testing being around that. It was to provide >> a way to manage things we don't support yet. > > > which strikes me as inconsistent. > Yes, exactly. -- Jan Cholasta From rcritten at redhat.com Fri Mar 16 13:34:54 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 09:34:54 -0400 Subject: [Freeipa-devel] [PATCHES] 0016-17 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F633CD0.8020103@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F62F308.9000604@redhat.com> <4F633B19.8090707@redhat.com> <4F633CD0.8020103@redhat.com> Message-ID: <4F63417E.9030801@redhat.com> Petr Viktorin wrote: > I may be taking things out of context, but I see this: > > On 03/16/2012 02:07 PM, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 29.2.2012 15:50, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: > .. snip .. >>>>>>> >>>>>>> Patch 17 makes these options honor params marked no_create and >>>>>>> no_update. >>>>>>> > .. snip .. >>>>> >>>>>> *attr is specifically made to be powerful. We don't want to >>>>>> arbitrarily >>>>>> block updating certain values. > > .. versus .. > >>>>> >>>>> I see the problem now: the certificate subject base is defined as a >>>>> multi-value attribute in the LDAP schema. If it's changed to >>>>> single-value the existing validation should catch it. >>>>> > .. snip .. >>>> >>>> The framework should be able to impose its own single-value will as >>>> well. If a Param is designated as single-value the *attr should honor >>>> it. >>> >>> Is that so? Isn't *attr supposed to allow the user to modify attributes >>> at LDAP level, i.e. skip the usual framework constraints? >> >> If we make rules around an attribute they should be honored. If we have >> not then all bets are off. >> >> *attr was never really made to manage those attributes that IPA knows >> about, despite most of the testing being around that. It was to provide >> a way to manage things we don't support yet. > > > which strikes me as inconsistent. > The original patch read to me that you were creating a new class of parameters that could not be updated via *attr. IMHO that was going too far. Some constraints are required. We don't want someone doing: ipa user-add --first=Super --last=Bad superbad --setattr uidnumber=0 Similarly we impose a certain view of the data to fit our purposes. The right solution in this case is to change the schema of ipaCertificateSubjectBase. But think about it. What does it mean if someone can add multiple values to parameters that IPA otherwise considers single-value? Undefined. I don't think it is unreasonable to enforce the parameter's single value. A user can always use ldapmodify if they really need to set that second value. rob From pviktori at redhat.com Fri Mar 16 13:53:21 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Mar 2012 14:53:21 +0100 Subject: [Freeipa-devel] [PATCHES] 0016-17 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F63417E.9030801@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F62F308.9000604@redhat.com> <4F633B19.8090707@redhat.com> <4F633CD0.8020103@redhat.com> <4F63417E.9030801@redhat.com> Message-ID: <4F6345D1.8040603@redhat.com> On 03/16/2012 02:34 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> I may be taking things out of context, but I see this: >> >> On 03/16/2012 02:07 PM, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 29.2.2012 15:50, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >> .. snip .. >>>>>>>> >>>>>>>> Patch 17 makes these options honor params marked no_create and >>>>>>>> no_update. >>>>>>>> >> .. snip .. >>>>>> >>>>>>> *attr is specifically made to be powerful. We don't want to >>>>>>> arbitrarily >>>>>>> block updating certain values. >> >> .. versus .. >> >>>>>> >>>>>> I see the problem now: the certificate subject base is defined as a >>>>>> multi-value attribute in the LDAP schema. If it's changed to >>>>>> single-value the existing validation should catch it. >>>>>> >> .. snip .. >>>>> >>>>> The framework should be able to impose its own single-value will as >>>>> well. If a Param is designated as single-value the *attr should honor >>>>> it. >>>> >>>> Is that so? Isn't *attr supposed to allow the user to modify attributes >>>> at LDAP level, i.e. skip the usual framework constraints? >>> >>> If we make rules around an attribute they should be honored. If we have >>> not then all bets are off. >>> >>> *attr was never really made to manage those attributes that IPA knows >>> about, despite most of the testing being around that. It was to provide >>> a way to manage things we don't support yet. >> >> >> which strikes me as inconsistent. >> > > The original patch read to me that you were creating a new class of > parameters that could not be updated via *attr. IMHO that was going too > far. Not creating a new class, just using what's already marked no_update. > Some constraints are required. We don't want someone doing: > > ipa user-add --first=Super --last=Bad superbad --setattr uidnumber=0 > > Similarly we impose a certain view of the data to fit our purposes. > > The right solution in this case is to change the schema of > ipaCertificateSubjectBase. But think about it. What does it mean if > someone can add multiple values to parameters that IPA otherwise > considers single-value? Undefined. I don't think it is unreasonable to > enforce the parameter's single value. A user can always use ldapmodify > if they really need to set that second value. I thought *attr was supposed to have the power of ldapmodify (for IPA-managed entries)? Anyway, you're right that this should be changed in the schema. But maybe since the checking should be done at the LDAP server, we shouldn't need to put another checking layer here (more code, more corner cases, more bugs). Alternatively, just disable *attr for known attributes. The users can always use ldapmodify if they know what they're doing, and if it's not possible with normal IPA commands it's a case where they do need to know what they're doing (and by having to use ldapmodify, be warned that they're on their own). -- Petr? From pviktori at redhat.com Fri Mar 16 14:18:04 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Mar 2012 15:18:04 +0100 Subject: [Freeipa-devel] [PATCH] 0016 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F624FE1.2080000@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F4E4586.2070805@redhat.com> <4F4F46C9.6030804@redhat.com> <4F624FE1.2080000@redhat.com> Message-ID: <4F634B9C.6030903@redhat.com> On 03/15/2012 09:24 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 02/29/2012 04:34 PM, Petr Viktorin wrote: >>> On 02/29/2012 03:50 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> Patch 16 defers validation & conversion until after >>>>>>> {add,del,set}attr is >>>>>>> processed, so that we don't search for an integer in a list of >>>>>>> strings >>>>>>> (this caused ticket #2405), and so that the end result of these >>>>>>> operations is validated (#2407). >>>>>>> >>>>>>> >>>>>>> Patch 17 makes these options honor params marked no_create and >>>>>>> no_update. >>>>>>> >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/2405 >>>>>>> https://fedorahosted.org/freeipa/ticket/2407 >>>>>>> https://fedorahosted.org/freeipa/ticket/2408 >>>>>> >>>>>> NACK on Patch 17 which breaks patch 16. >>>>> >>>>> How is patch 16 broken? It works for me. >>>> >>>> My point is they rely on one another, IMHO, so without 17 the reported >>>> problem still exists. >>>> >>>>> >>>>>> *attr is specifically made to be powerful. We don't want to >>>>>> arbitrarily >>>>>> block updating certain values. >>>>> >>>>> Noted >>>>> >>>>>> Not having patch 17 means that the problem reported in 2408 still >>>>>> occurs. It should probably check both the schema and the param to >>>>>> determine if something can have multiple values and reject that way. >>>>> >>>>> I see the problem now: the certificate subject base is defined as a >>>>> multi-value attribute in the LDAP schema. If it's changed to >>>>> single-value the existing validation should catch it. >>>>> >>>>> Also, most of the config attributes should probably be required in the >>>>> schema. Am I right? >>>>> >>>>> I'm a newbie here; what do I need to do when changing the schema? Is >>>>> there a patch that does something similar I could use as an example? >>>>> >>>> >>>> The framework should be able to impose its own single-value will as >>>> well. If a Param is designated as single-value the *attr should honor >>>> it. >>> >>> Here is the updated patch. >>> Since *attr is powerful enough to modify 'no_update' Params, which >>> CRUDUpdate forgets about, I need to check the params of the LDAPObject >>> itself. >>> >>>> Updating schema is a bit of a nasty business right now. See >>>> 10-selinuxusermap.update for an example. >>> >>> I'll leave schema changes for after the release, then. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Attached patch includes tests. Note that the test depends on my patches >> 12-13, which make ipasearchrecordslimit required. > > I gather that this eliminates the need for patch 17? It seems to work > as-is. Yes. Patch 17 made *attr honor no_create and no_update, which you said is not desired behavior. > The patch doesn't apply because of an encoding change Martin made recently. > > It does seem to do the right thing though. > > rob Attaching rebased patch. This deletes Martin's change, but unless I tested wrong, his bug (https://fedorahosted.org/freeipa/ticket/2418) stays fixed. The tests in my patch should apply to that ticket as well. In another fork of this thread, there's discussion if this approach is good at all. Maybe we're overengineering a corner case here. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0016-04-Defer-conversion-and-validation-until-after-add-del-.patch Type: text/x-patch Size: 7603 bytes Desc: not available URL: From pvoborni at redhat.com Fri Mar 16 14:41:13 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 16 Mar 2012 15:41:13 +0100 Subject: [Freeipa-devel] [PATCH] 107 Content is no more overwritten by error message In-Reply-To: <4F5FC230.40207@redhat.com> References: <4F5A0299.2060006@redhat.com> <4F5FC230.40207@redhat.com> Message-ID: <4F635109.1050600@redhat.com> On 03/13/2012 10:54 PM, Endi Sukma Dewata wrote: > On 3/9/2012 7:16 AM, Petr Vobornik wrote: >> When an error which caused calling of report_error occur, the content of >> a facet got replaced by error message. There was no way how to force the >> facet to recreate its content and the facet became unusable. >> >> This patch creates a container for an error message. On error, >> report_error writes its content to error container, content container is >> hidden and error container is shown. Older comment in a code suggested >> to move the error message to facet's footer. A message in a footer could >> be missed by the user and on top of that a footer is sometimes used by >> various facet and we would have to solve the same problem again. >> >> From experience the cause of an error is usually a missing pkey in a >> path. Therefore error information suggests user to navigate to top >> level. It causes to load default facets with default values so errors in >> navigation state shouldn't happen. >> >> Facet content is displayed back on facet_show. If user tries to display >> same object as before facet's need_update() would return false, >> therefore need_update was modified to always return true if error is >> displayed. >> >> Also it may be possible to display facet content on refresh success. I >> tried to avoid that because it would require putting show_content calls >> to various success handlers or load methods. It would add one more thing >> developer needs to think of when overriding refresh or load method. >> >> Reproduction: >> 1) display any nested entity - ie DNS record >> 2) delete its parent pkey from path - &dnszone-pkey=example.com >> 3) reload the page with this path >> >> https://fedorahosted.org/freeipa/ticket/2449 > > In the ticket I added 2 more scenarios to reproduce the problem. So we > have 3 possible cases: > 1. invalid UI state > 2. non-existent entry > 3. server down > > For case #1, the patch provides a much better message, but I think > ideally if some parameters are missing from the URL (e.g. the parent > pkey) it should be detected by the UI before sending the request to the > server. This probably should be addressed in a separate ticket. See the > note below about the error message. > > For case #2, the patch fixes the issue by clearing up the error message. > This works on all entities except users because the user details page > uses a batch operation to get the data and it doesn't handle > non-existent users properly. I think this is an existing and separate > issue. > > For case #3, the patch will show a message saying that the UI got into > an invalid state, which is actually not the case here. Also, returning > to the main page or reloading the page wouldn't solve the problem either. > > So for this ticket I think it would be better to show a more generic > error message, something like this: Reworked. > > An error has occured (IPA Error 3007) > > 'idnsname' is required > > Please try the following options: > * Refresh the page. (see note below) > * Return to the main page and retry the operation. We are talking about main page. What is it? Identity/Users? Navigation code operates also with currently displayed facet. So when I now navigate to '#' (empty state) it won't have to be Identity/Users. The good part is that it navigates to page in a branch where user was operating. > * Reload the browser. > If the problem persists please contact the system administrator. > > Each of the above options could be made into a link that does the > mentioned operation. > > It would be great if we can use the Refresh button to clear the error > message. If this requires significant effort we probably can remove this > option from the message above and add it in a separate ticket. The patch is quite short. I was more concerned about the fact that when overriding stuff, developer would have to think about one more thing. The UI is getting more and more complex. But it might not be as a big problem as I originally thought. I put the call to refresh success handler, mainly because report_error is in error handler, and these handlers aren't overridden often. Attached as separate patch. > > One more thing, this may not be a problem now, but the error_container > uses both facet-content and facet-error CSS classes. I understand this > is done to avoid code duplication, but this also means the facet will > have 2 facet-contents. CSS classes can be used for decorative or > structural purposes or both, so we need to make sure decorative changes > will not affect it structurally. One solution is to duplicate the CSS > code from facet-content into facet-error. Another solution is to use a > separate decorative class that are added into both facet-content and > facet-error elements. > It is little bit more difficult. If I look at it structurally the error div is facet-content too. So the facet has two contents - proper and error. Is it OK? Does it break some design principle. If so, would it be better to have separate error_facet? I think it is not good to have two contents but current implementation is not ready for separate error_facet - navigation code might protest. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0106-1-Content-is-no-more-overwritten-by-error-message.patch Type: text/x-patch Size: 9663 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0111-Show_content-on-refresh-success.patch Type: text/x-patch Size: 3127 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 16 17:28:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 13:28:43 -0400 Subject: [Freeipa-devel] [PATCH] 0016 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F634B9C.6030903@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F4E4586.2070805@redhat.com> <4F4F46C9.6030804@redhat.com> <4F624FE1.2080000@redhat.com> <4F634B9C.6030903@redhat.com> Message-ID: <4F63784B.4020009@redhat.com> Petr Viktorin wrote: > On 03/15/2012 09:24 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 02/29/2012 04:34 PM, Petr Viktorin wrote: >>>> On 02/29/2012 03:50 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> Patch 16 defers validation & conversion until after >>>>>>>> {add,del,set}attr is >>>>>>>> processed, so that we don't search for an integer in a list of >>>>>>>> strings >>>>>>>> (this caused ticket #2405), and so that the end result of these >>>>>>>> operations is validated (#2407). >>>>>>>> >>>>>>>> >>>>>>>> Patch 17 makes these options honor params marked no_create and >>>>>>>> no_update. >>>>>>>> >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/2405 >>>>>>>> https://fedorahosted.org/freeipa/ticket/2407 >>>>>>>> https://fedorahosted.org/freeipa/ticket/2408 >>>>>>> >>>>>>> NACK on Patch 17 which breaks patch 16. >>>>>> >>>>>> How is patch 16 broken? It works for me. >>>>> >>>>> My point is they rely on one another, IMHO, so without 17 the reported >>>>> problem still exists. >>>>> >>>>>> >>>>>>> *attr is specifically made to be powerful. We don't want to >>>>>>> arbitrarily >>>>>>> block updating certain values. >>>>>> >>>>>> Noted >>>>>> >>>>>>> Not having patch 17 means that the problem reported in 2408 still >>>>>>> occurs. It should probably check both the schema and the param to >>>>>>> determine if something can have multiple values and reject that way. >>>>>> >>>>>> I see the problem now: the certificate subject base is defined as a >>>>>> multi-value attribute in the LDAP schema. If it's changed to >>>>>> single-value the existing validation should catch it. >>>>>> >>>>>> Also, most of the config attributes should probably be required in >>>>>> the >>>>>> schema. Am I right? >>>>>> >>>>>> I'm a newbie here; what do I need to do when changing the schema? Is >>>>>> there a patch that does something similar I could use as an example? >>>>>> >>>>> >>>>> The framework should be able to impose its own single-value will as >>>>> well. If a Param is designated as single-value the *attr should honor >>>>> it. >>>> >>>> Here is the updated patch. >>>> Since *attr is powerful enough to modify 'no_update' Params, which >>>> CRUDUpdate forgets about, I need to check the params of the LDAPObject >>>> itself. >>>> >>>>> Updating schema is a bit of a nasty business right now. See >>>>> 10-selinuxusermap.update for an example. >>>> >>>> I'll leave schema changes for after the release, then. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Attached patch includes tests. Note that the test depends on my patches >>> 12-13, which make ipasearchrecordslimit required. >> >> I gather that this eliminates the need for patch 17? It seems to work >> as-is. > > Yes. Patch 17 made *attr honor no_create and no_update, which you said > is not desired behavior. > >> The patch doesn't apply because of an encoding change Martin made >> recently. >> >> It does seem to do the right thing though. >> >> rob > > Attaching rebased patch. > This deletes Martin's change, but unless I tested wrong, his bug > (https://fedorahosted.org/freeipa/ticket/2418) stays fixed. The tests in > my patch should apply to that ticket as well. > > In another fork of this thread, there's discussion if this approach is > good at all. Maybe we're overengineering a corner case here. > Found another issue, a very subtle one. When using *attr and an exception occurs where the param name would appear we want the name passed in to be used. For example: $ ipa pwpolicy-mod --setattr=krbpwdmaxfailure=xyz With this patch it will return: ipa: ERROR: invalid 'maxfail': must be an integer It should return: ipa: ERROR: invalid 'krbpwdmaxfailure': must be an integer The encoding problem does still exist too: $ ipa config-mod --setattr ipamigrationenabled=false ipa: ERROR: ipaMigrationEnabled: value #0 invalid per syntax: Invalid syntax. rob From rcritten at redhat.com Fri Mar 16 17:33:21 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 13:33:21 -0400 Subject: [Freeipa-devel] [PATCH] 0016 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F63784B.4020009@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F4E4586.2070805@redhat.com> <4F4F46C9.6030804@redhat.com> <4F624FE1.2080000@redhat.com> <4F634B9C.6030903@redhat.com> <4F63784B.4020009@redhat.com> Message-ID: <4F637961.4050805@redhat.com> Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/15/2012 09:24 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 02/29/2012 04:34 PM, Petr Viktorin wrote: >>>>> On 02/29/2012 03:50 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>>>> Patch 16 defers validation & conversion until after >>>>>>>>> {add,del,set}attr is >>>>>>>>> processed, so that we don't search for an integer in a list of >>>>>>>>> strings >>>>>>>>> (this caused ticket #2405), and so that the end result of these >>>>>>>>> operations is validated (#2407). >>>>>>>>> >>>>>>>>> >>>>>>>>> Patch 17 makes these options honor params marked no_create and >>>>>>>>> no_update. >>>>>>>>> >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/2405 >>>>>>>>> https://fedorahosted.org/freeipa/ticket/2407 >>>>>>>>> https://fedorahosted.org/freeipa/ticket/2408 >>>>>>>> >>>>>>>> NACK on Patch 17 which breaks patch 16. >>>>>>> >>>>>>> How is patch 16 broken? It works for me. >>>>>> >>>>>> My point is they rely on one another, IMHO, so without 17 the >>>>>> reported >>>>>> problem still exists. >>>>>> >>>>>>> >>>>>>>> *attr is specifically made to be powerful. We don't want to >>>>>>>> arbitrarily >>>>>>>> block updating certain values. >>>>>>> >>>>>>> Noted >>>>>>> >>>>>>>> Not having patch 17 means that the problem reported in 2408 still >>>>>>>> occurs. It should probably check both the schema and the param to >>>>>>>> determine if something can have multiple values and reject that >>>>>>>> way. >>>>>>> >>>>>>> I see the problem now: the certificate subject base is defined as a >>>>>>> multi-value attribute in the LDAP schema. If it's changed to >>>>>>> single-value the existing validation should catch it. >>>>>>> >>>>>>> Also, most of the config attributes should probably be required in >>>>>>> the >>>>>>> schema. Am I right? >>>>>>> >>>>>>> I'm a newbie here; what do I need to do when changing the schema? Is >>>>>>> there a patch that does something similar I could use as an example? >>>>>>> >>>>>> >>>>>> The framework should be able to impose its own single-value will as >>>>>> well. If a Param is designated as single-value the *attr should honor >>>>>> it. >>>>> >>>>> Here is the updated patch. >>>>> Since *attr is powerful enough to modify 'no_update' Params, which >>>>> CRUDUpdate forgets about, I need to check the params of the LDAPObject >>>>> itself. >>>>> >>>>>> Updating schema is a bit of a nasty business right now. See >>>>>> 10-selinuxusermap.update for an example. >>>>> >>>>> I'll leave schema changes for after the release, then. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> Attached patch includes tests. Note that the test depends on my patches >>>> 12-13, which make ipasearchrecordslimit required. >>> >>> I gather that this eliminates the need for patch 17? It seems to work >>> as-is. >> >> Yes. Patch 17 made *attr honor no_create and no_update, which you said >> is not desired behavior. >> >>> The patch doesn't apply because of an encoding change Martin made >>> recently. >>> >>> It does seem to do the right thing though. >>> >>> rob >> >> Attaching rebased patch. >> This deletes Martin's change, but unless I tested wrong, his bug >> (https://fedorahosted.org/freeipa/ticket/2418) stays fixed. The tests in >> my patch should apply to that ticket as well. >> >> In another fork of this thread, there's discussion if this approach is >> good at all. Maybe we're overengineering a corner case here. >> > > Found another issue, a very subtle one. > > When using *attr and an exception occurs where the param name would > appear we want the name passed in to be used. > > For example: > > $ ipa pwpolicy-mod --setattr=krbpwdmaxfailure=xyz > > With this patch it will return: > ipa: ERROR: invalid 'maxfail': must be an integer > > It should return: > ipa: ERROR: invalid 'krbpwdmaxfailure': must be an integer On second thought, this may not be related... > > The encoding problem does still exist too: > > $ ipa config-mod --setattr ipamigrationenabled=false > ipa: ERROR: ipaMigrationEnabled: value #0 invalid per syntax: Invalid > syntax. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Fri Mar 16 17:35:20 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Mar 2012 18:35:20 +0100 Subject: [Freeipa-devel] [PATCH] 0016 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F637961.4050805@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F4E4586.2070805@redhat.com> <4F4F46C9.6030804@redhat.com> <4F624FE1.2080000@redhat.com> <4F634B9C.6030903@redhat.com> <4F63784B.4020009@redhat.com> <4F637961.4050805@redhat.com> Message-ID: <4F6379D8.1050602@redhat.com> On 03/16/2012 06:33 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/15/2012 09:24 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 02/29/2012 04:34 PM, Petr Viktorin wrote: >>>>>> On 02/29/2012 03:50 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >>>>>>>>> Petr Viktorin wrote: >>>>>>>>>> Patch 16 defers validation & conversion until after >>>>>>>>>> {add,del,set}attr is >>>>>>>>>> processed, so that we don't search for an integer in a list of >>>>>>>>>> strings >>>>>>>>>> (this caused ticket #2405), and so that the end result of these >>>>>>>>>> operations is validated (#2407). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Patch 17 makes these options honor params marked no_create and >>>>>>>>>> no_update. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2405 >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2407 >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2408 >>>>>>>>> >>>>>>>>> NACK on Patch 17 which breaks patch 16. >>>>>>>> >>>>>>>> How is patch 16 broken? It works for me. >>>>>>> >>>>>>> My point is they rely on one another, IMHO, so without 17 the >>>>>>> reported >>>>>>> problem still exists. >>>>>>> >>>>>>>> >>>>>>>>> *attr is specifically made to be powerful. We don't want to >>>>>>>>> arbitrarily >>>>>>>>> block updating certain values. >>>>>>>> >>>>>>>> Noted >>>>>>>> >>>>>>>>> Not having patch 17 means that the problem reported in 2408 still >>>>>>>>> occurs. It should probably check both the schema and the param to >>>>>>>>> determine if something can have multiple values and reject that >>>>>>>>> way. >>>>>>>> >>>>>>>> I see the problem now: the certificate subject base is defined as a >>>>>>>> multi-value attribute in the LDAP schema. If it's changed to >>>>>>>> single-value the existing validation should catch it. >>>>>>>> >>>>>>>> Also, most of the config attributes should probably be required in >>>>>>>> the >>>>>>>> schema. Am I right? >>>>>>>> >>>>>>>> I'm a newbie here; what do I need to do when changing the >>>>>>>> schema? Is >>>>>>>> there a patch that does something similar I could use as an >>>>>>>> example? >>>>>>>> >>>>>>> >>>>>>> The framework should be able to impose its own single-value will as >>>>>>> well. If a Param is designated as single-value the *attr should >>>>>>> honor >>>>>>> it. >>>>>> >>>>>> Here is the updated patch. >>>>>> Since *attr is powerful enough to modify 'no_update' Params, which >>>>>> CRUDUpdate forgets about, I need to check the params of the >>>>>> LDAPObject >>>>>> itself. >>>>>> >>>>>>> Updating schema is a bit of a nasty business right now. See >>>>>>> 10-selinuxusermap.update for an example. >>>>>> >>>>>> I'll leave schema changes for after the release, then. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> Attached patch includes tests. Note that the test depends on my >>>>> patches >>>>> 12-13, which make ipasearchrecordslimit required. >>>> >>>> I gather that this eliminates the need for patch 17? It seems to work >>>> as-is. >>> >>> Yes. Patch 17 made *attr honor no_create and no_update, which you said >>> is not desired behavior. >>> >>>> The patch doesn't apply because of an encoding change Martin made >>>> recently. >>>> >>>> It does seem to do the right thing though. >>>> >>>> rob >>> >>> Attaching rebased patch. >>> This deletes Martin's change, but unless I tested wrong, his bug >>> (https://fedorahosted.org/freeipa/ticket/2418) stays fixed. The tests in >>> my patch should apply to that ticket as well. >>> >>> In another fork of this thread, there's discussion if this approach is >>> good at all. Maybe we're overengineering a corner case here. >>> >> >> Found another issue, a very subtle one. >> >> When using *attr and an exception occurs where the param name would >> appear we want the name passed in to be used. >> >> For example: >> >> $ ipa pwpolicy-mod --setattr=krbpwdmaxfailure=xyz >> >> With this patch it will return: >> ipa: ERROR: invalid 'maxfail': must be an integer >> >> It should return: >> ipa: ERROR: invalid 'krbpwdmaxfailure': must be an integer > > On second thought, this may not be related... This is https://fedorahosted.org/freeipa/ticket/1418, I'll see if it makes sense to fix it here. > >> >> The encoding problem does still exist too: >> >> $ ipa config-mod --setattr ipamigrationenabled=false >> ipa: ERROR: ipaMigrationEnabled: value #0 invalid per syntax: Invalid >> syntax. >> Will fix. -- Petr? From pviktori at redhat.com Fri Mar 16 19:01:08 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Mar 2012 20:01:08 +0100 Subject: [Freeipa-devel] [PATCH] 0016 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F6379D8.1050602@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F4E4586.2070805@redhat.com> <4F4F46C9.6030804@redhat.com> <4F624FE1.2080000@redhat.com> <4F634B9C.6030903@redhat.com> <4F63784B.4020009@redhat.com> <4F637961.4050805@redhat.com> <4F6379D8.1050602@redhat.com> Message-ID: <4F638DF4.4060602@redhat.com> On 03/16/2012 06:35 PM, Petr Viktorin wrote: > On 03/16/2012 06:33 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 03/15/2012 09:24 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 02/29/2012 04:34 PM, Petr Viktorin wrote: >>>>>>> On 02/29/2012 03:50 PM, Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>> Patch 16 defers validation & conversion until after >>>>>>>>>>> {add,del,set}attr is >>>>>>>>>>> processed, so that we don't search for an integer in a list of >>>>>>>>>>> strings >>>>>>>>>>> (this caused ticket #2405), and so that the end result of these >>>>>>>>>>> operations is validated (#2407). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Patch 17 makes these options honor params marked no_create and >>>>>>>>>>> no_update. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2405 >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2407 >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2408 >>>>>>>>>> >>>>>>>>>> NACK on Patch 17 which breaks patch 16. >>>>>>>>> >>>>>>>>> How is patch 16 broken? It works for me. >>>>>>>> >>>>>>>> My point is they rely on one another, IMHO, so without 17 the >>>>>>>> reported >>>>>>>> problem still exists. >>>>>>>> >>>>>>>>> >>>>>>>>>> *attr is specifically made to be powerful. We don't want to >>>>>>>>>> arbitrarily >>>>>>>>>> block updating certain values. >>>>>>>>> >>>>>>>>> Noted >>>>>>>>> >>>>>>>>>> Not having patch 17 means that the problem reported in 2408 still >>>>>>>>>> occurs. It should probably check both the schema and the param to >>>>>>>>>> determine if something can have multiple values and reject that >>>>>>>>>> way. >>>>>>>>> >>>>>>>>> I see the problem now: the certificate subject base is defined >>>>>>>>> as a >>>>>>>>> multi-value attribute in the LDAP schema. If it's changed to >>>>>>>>> single-value the existing validation should catch it. >>>>>>>>> >>>>>>>>> Also, most of the config attributes should probably be required in >>>>>>>>> the >>>>>>>>> schema. Am I right? >>>>>>>>> >>>>>>>>> I'm a newbie here; what do I need to do when changing the >>>>>>>>> schema? Is >>>>>>>>> there a patch that does something similar I could use as an >>>>>>>>> example? >>>>>>>>> >>>>>>>> >>>>>>>> The framework should be able to impose its own single-value will as >>>>>>>> well. If a Param is designated as single-value the *attr should >>>>>>>> honor >>>>>>>> it. >>>>>>> >>>>>>> Here is the updated patch. >>>>>>> Since *attr is powerful enough to modify 'no_update' Params, which >>>>>>> CRUDUpdate forgets about, I need to check the params of the >>>>>>> LDAPObject >>>>>>> itself. >>>>>>> >>>>>>>> Updating schema is a bit of a nasty business right now. See >>>>>>>> 10-selinuxusermap.update for an example. >>>>>>> >>>>>>> I'll leave schema changes for after the release, then. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>>> Attached patch includes tests. Note that the test depends on my >>>>>> patches >>>>>> 12-13, which make ipasearchrecordslimit required. >>>>> >>>>> I gather that this eliminates the need for patch 17? It seems to work >>>>> as-is. >>>> >>>> Yes. Patch 17 made *attr honor no_create and no_update, which you said >>>> is not desired behavior. >>>> >>>>> The patch doesn't apply because of an encoding change Martin made >>>>> recently. >>>>> >>>>> It does seem to do the right thing though. >>>>> >>>>> rob >>>> >>>> Attaching rebased patch. >>>> This deletes Martin's change, but unless I tested wrong, his bug >>>> (https://fedorahosted.org/freeipa/ticket/2418) stays fixed. The >>>> tests in >>>> my patch should apply to that ticket as well. >>>> >>>> In another fork of this thread, there's discussion if this approach is >>>> good at all. Maybe we're overengineering a corner case here. >>>> >>> >>> Found another issue, a very subtle one. >>> >>> When using *attr and an exception occurs where the param name would >>> appear we want the name passed in to be used. >>> >>> For example: >>> >>> $ ipa pwpolicy-mod --setattr=krbpwdmaxfailure=xyz >>> >>> With this patch it will return: >>> ipa: ERROR: invalid 'maxfail': must be an integer >>> >>> It should return: >>> ipa: ERROR: invalid 'krbpwdmaxfailure': must be an integer >> >> On second thought, this may not be related... > > This is https://fedorahosted.org/freeipa/ticket/1418, I'll see if it > makes sense to fix it here. Okay, this is a different problem. A quick grep of ConversionError in parameters.py reveals that all of the "wrong datatype" errors are raised with the raw parameter name. Other errors are raised with either that or the cli_name or they auto-detect. I don't think they follow some rule in this. Furthermore, our test suite doesn't check exception arguments. Sounds like a major cleanup coming up here... >> >>> >>> The encoding problem does still exist too: >>> >>> $ ipa config-mod --setattr ipamigrationenabled=false >>> ipa: ERROR: ipaMigrationEnabled: value #0 invalid per syntax: Invalid >>> syntax. >>> > > Will fix. > Fixed in the attached update, which encodes the value. I was surprised to find that config_mod.params['ipamigrationenabled'].attribute is True, while config_mod.obj.params['ipamigrationenabled'].attribute is False (and so its encode() method does nothing). That's because 'attribute' is only set when the params are cloned from the LDAPObject to the CRUD method. Is there a reason behind this, or is it just that it was easier to do? For this case it means that params marked no_update will not be encoded properly -- getting to a working encode() would require either setting 'attribute' on the parent object or some ugly hackery. --- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0016-05-Defer-conversion-and-validation-until-after-add-del-.patch Type: text/x-patch Size: 9148 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 16 21:19:30 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 17:19:30 -0400 Subject: [Freeipa-devel] [PATCH] 989 import plugins on context, not in_server Message-ID: <4F63AE62.2050709@redhat.com> in_server controls how messages are dispatched. We should import on context. This prevents the error message "session memcached servers not running" in ipa-ldap-updater and ipa-replica-manage. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-989-in-server.patch Type: text/x-diff Size: 1160 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 16 21:23:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 17:23:38 -0400 Subject: [Freeipa-devel] [PATCH] 990 attribute name in exceptions Message-ID: <4F63AF5A.4050005@redhat.com> When using *attr we should return the param.name of in the exception and when using a cli option we should return param.cli_name. This didn't work consistently in the framework. This is a bit of a kludge, catching exceptions and re-raising them, but it is a less invasive way of doing it. I added some examples of things to test in the ticket. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-990-attribute.patch Type: text/x-diff Size: 5899 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 16 23:13:59 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 16 Mar 2012 18:13:59 -0500 Subject: [Freeipa-devel] [PATCH] 349 Fixed boot.ldif permission. Message-ID: <4F63C937.4030301@redhat.com> The server installation failed on F17 due to permission problem. The /var/lib/dirsrv/boot.ldif was previously owned and only readable by root. It is now owned by DS user dirsrv. Ticket #2544 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0349-Fixed-boot.ldif-permission.patch Type: text/x-patch Size: 1417 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 19 08:38:31 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Mar 2012 09:38:31 +0100 Subject: [Freeipa-devel] [PATCH] 987 Don't allow IPA master hosts and services to be disabled In-Reply-To: <4F633222.2020903@redhat.com> References: <4F62595D.6070000@redhat.com> <4F632DAF.7050307@redhat.com> <4F633222.2020903@redhat.com> Message-ID: <1332146311.24427.7.camel@balmora.brq.redhat.com> On Fri, 2012-03-16 at 08:29 -0400, Rob Crittenden wrote: > Petr Viktorin wrote: > > On 03/15/2012 10:04 PM, Rob Crittenden wrote: > >> diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py > >> index > >> 9562ff98729ead6ac9e56d504f6ee0a7c0ca377a..f3c89a0fc5e3f00ed7f132dbff2510d89bc7370d > >> 100644 > >> --- a/ipalib/plugins/baseldap.py > >> +++ b/ipalib/plugins/baseldap.py > >> @@ -887,12 +877,29 @@ last, after all sets and adds."""), > >> # normalize all values > >> changedattrs = setattrs | addattrs | delattrs > >> for attr in changedattrs: > >> - # remove duplicite and invalid values > >> - entry_attrs[attr] = list(set([val for val in entry_attrs[attr] if > >> val])) > >> - if not entry_attrs[attr]: > >> - entry_attrs[attr] = None > >> - elif isinstance(entry_attrs[attr], (tuple, list)) and > >> len(entry_attrs[attr]) == 1: > >> - entry_attrs[attr] = entry_attrs[attr][0] > >> + if attr in self.obj.params: > >> + # convert single-value params to scalars > >> + # Need to use the LDAPObject's params, not self's, because the > >> + # CRUD classes filter their disallowed parameters out. > >> + # Yet {set,add,del}attr are powerful enough to change these > >> + # (e.g. Config's ipacertificatesubjectbase) > >> + if not self.obj.params[attr].multivalue: > >> + if len(entry_attrs[attr]) == 1: > >> + entry_attrs[attr] = entry_attrs[attr][0] > >> + elif not entry_attrs[attr]: > >> + entry_attrs[attr] = None > >> + else: > >> + raise errors.OnlyOneValueAllowed(attr=attr) > >> + # validate and convert params > >> + entry_attrs[attr] = self.obj.params[attr](entry_attrs[attr]) > >> + else: > >> + # unknown attribute: remove duplicite and invalid values > >> + entry_attrs[attr] = list(set([val for val in entry_attrs[attr] if > >> val])) > >> + if not entry_attrs[attr]: > >> + entry_attrs[attr] = None > >> + elif isinstance(entry_attrs[attr], (tuple, list)) and > >> len(entry_attrs[attr]) == 1: > >> + entry_attrs[attr] = entry_attrs[attr][0] > >> + > > > > You've included an unrelated patch (my 0016). > > > > That's what I get for mixing my review and dev branch. Correct patch > attached. > > rob I still think this is not the one. It somehow got squashed with Petr3's *attr patch. Martin From pviktori at redhat.com Mon Mar 19 09:11:23 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 19 Mar 2012 10:11:23 +0100 Subject: [Freeipa-devel] [PATCH] 990 attribute name in exceptions In-Reply-To: <4F63AF5A.4050005@redhat.com> References: <4F63AF5A.4050005@redhat.com> Message-ID: <4F66F83B.2080405@redhat.com> On 03/16/2012 10:23 PM, Rob Crittenden wrote: > When using *attr we should return the param.name of in the exception and > when using a cli option we should return param.cli_name. This didn't > work consistently in the framework. > > This is a bit of a kludge, catching exceptions and re-raising them, but > it is a less invasive way of doing it. > > I added some examples of things to test in the ticket. > > rob > > (name, error) = err.strerror.split(':') > raise errors.ConversionError(name=attr, error=error) AFAIU this will break when the error message is translated. Why not just use err.kw['error']? -- Petr? From jcholast at redhat.com Mon Mar 19 13:02:51 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 19 Mar 2012 14:02:51 +0100 Subject: [Freeipa-devel] [PATCH] 70 Parse zone indices in IPv6 addresses in CheckedIPAddress Message-ID: <4F672E7B.1050103@redhat.com> https://fedorahosted.org/freeipa/ticket/2138 Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-70-ipv6-zone-index.patch Type: text/x-patch Size: 2120 bytes Desc: not available URL: From jcholast at redhat.com Mon Mar 19 13:34:41 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 19 Mar 2012 14:34:41 +0100 Subject: [Freeipa-devel] [PATCH] 989 import plugins on context, not in_server In-Reply-To: <4F63AE62.2050709@redhat.com> References: <4F63AE62.2050709@redhat.com> Message-ID: <4F6735F1.6030508@redhat.com> On 16.3.2012 22:19, Rob Crittenden wrote: > in_server controls how messages are dispatched. We should import on > context. > > This prevents the error message "session memcached servers not running" > in ipa-ldap-updater and ipa-replica-manage. > > rob > ACK. Honza -- Jan Cholasta From pspacek at redhat.com Mon Mar 19 13:34:41 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 19 Mar 2012 14:34:41 +0100 Subject: [Freeipa-devel] DNS/bind-dyndb-ldap development plans Message-ID: <4F6735F1.9060704@redhat.com> Hello list, there are several big features, that are missing in IPA DNS/plugin now. So we have to triage "big features" for next plugin development. In short - there is a list of biggest features: - DNSSEC (Domain Name System Security Extensions) support - IDN (Internationalized Domain Names) support - DNS test suite - Push dynamic database API to upstream - More flexible/BIND equivalent record format - "Never ending stories" about code quality etc. All details for each big item is below. BIND LDAP plugin Trac contains a lot of minor things + placeholders for some big features. URL: https://fedorahosted.org/bind-dyndb-ldap/report/3 DNSSEC (Domain Name System Security Extensions) support ------------------------------------------------------- There are some problems to be solved. After discussion with Adam I think it is doable. It requires some effort, but IMHO it is crucial feature for future. BIND supports DNSSEC from RHEL5. Fedora 17 will have client side support. There should not be any interoperability problem with DNSSEC client & not-DNSSEC-aware server (i.e. current IPA). https://fedorahosted.org/bind-dyndb-ldap/ticket/56 IDN (Internationalized Domain Names) support -------------------------------------------- Non ASCII domain names are encoded to ASCII strings. Theoretically it IS supported now in plugin, from plugin point of view it is nothing special. Another side is support for encoding/decoding strings in all our utilities, documentation and testing. Nowadays it's supported in DNS system from top-level and it's usable. The Question: Is there any user of this? I'm not really sure if somebody really uses IDN. But people with non-latin alphabet will probably have another opinion :-) https://fedorahosted.org/bind-dyndb-ldap/ticket/58 DNS test suite -------------- We don't have any test suite now. Everything is tested manually, usually with dig. (Same situation is there with BIND package.) Several open source DNS tests are around on Internet. All of them are partial and they are usually unmaintained. Test them, select best pieces, write what will be missing and combine it to our DNS test suite. It would be better to start separate "dnstest" project or something similar. It can start from simple packaging of selected tools for Fedora and then start to integrate them to own test suite. Our client interface is plain DNS protocol, so it can be reused for BIND or any other DNS server. Push dynamic database API to upstream ------------------------------------- I got detailed information from Adam. Situation is better than I knew a week ago during meeting. Basically, ISC can accept current API, but there are some requirements: - small code clean-up (not a big thing) - complete documentation (of course) - some sort of API tests - example driver with *BSD* license, GPL is not acceptable Really simple driver is acceptable (without any dynamic things), so I think it is doable. I think it will be better to push API to upstream after deep DNSSEC inspection and implementation design, some problems can arise... More flexible/BIND equivalent record format ------------------------------------------- Current record format in LDAP is less powerful than BIND's. Generally, each record can have own TTL value, see RFC1035 http://tools.ietf.org/html/rfc1035 section 5.1. We allow only single value per name, so it's not possible to have e.g. single name with long-term A record and short term LOC record. It probably leads to some performance degradation in some special cases, but generally it's not a problem. I think it's very-long-term "nice to have". (It is good to remember to this problem in meantime.) Problem is, that this change will affect LDAP scheme and whole DNS UI, so it's very problematic. Never ending stories (in progress, of course :-) -------------------- - improve error handling - improve configuration (local overriding etc.) - stabilize persistent search - performance optimization Thanks for you patience and sorry for long mail. Petr^2 Spacek From simo at redhat.com Mon Mar 19 13:42:02 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2012 09:42:02 -0400 Subject: [Freeipa-devel] DNS/bind-dyndb-ldap development plans In-Reply-To: <4F6735F1.9060704@redhat.com> References: <4F6735F1.9060704@redhat.com> Message-ID: <1332164522.9238.349.camel@willson.li.ssimo.org> On Mon, 2012-03-19 at 14:34 +0100, Petr Spacek wrote: > Hello list, > > there are several big features, that are missing in IPA DNS/plugin now. > So we have to triage "big features" for next plugin development. > > In short - there is a list of biggest features: > - DNSSEC (Domain Name System Security Extensions) support > - IDN (Internationalized Domain Names) support > - DNS test suite > - Push dynamic database API to upstream > - More flexible/BIND equivalent record format > - "Never ending stories" about code quality etc. > > All details for each big item is below. BIND LDAP plugin Trac contains a > lot of minor things + placeholders for some big features. > URL: https://fedorahosted.org/bind-dyndb-ldap/report/3 > > > DNSSEC (Domain Name System Security Extensions) support > ------------------------------------------------------- > There are some problems to be solved. After discussion with Adam I think > it is doable. It requires some effort, but IMHO it is crucial feature > for future. > > BIND supports DNSSEC from RHEL5. Fedora 17 will have client side > support. There should not be any interoperability problem with DNSSEC > client & not-DNSSEC-aware server (i.e. current IPA). > > https://fedorahosted.org/bind-dyndb-ldap/ticket/56 This seems material for F18 maybe ? > IDN (Internationalized Domain Names) support > -------------------------------------------- > Non ASCII domain names are encoded to ASCII strings. Theoretically it IS > supported now in plugin, from plugin point of view it is nothing special. > Another side is support for encoding/decoding strings in all our > utilities, documentation and testing. > > Nowadays it's supported in DNS system from top-level and it's usable. > > The Question: Is there any user of this? I'm not really sure if somebody > really uses IDN. But people with non-latin alphabet will probably have > another opinion :-) > > https://fedorahosted.org/bind-dyndb-ldap/ticket/58 Isn't this a matter of just having the UI compute the right value to store in the plugin ? I do not think we want to do on the fly conversions within the plugin, would be very inefficient. > DNS test suite > -------------- > We don't have any test suite now. Everything is tested manually, usually > with dig. (Same situation is there with BIND package.) > > Several open source DNS tests are around on Internet. All of them are > partial and they are usually unmaintained. Test them, select best > pieces, write what will be missing and combine it to our DNS test suite. > > It would be better to start separate "dnstest" project or something > similar. It can start from simple packaging of selected tools for Fedora > and then start to integrate them to own test suite. > > Our client interface is plain DNS protocol, so it can be reused for BIND > or any other DNS server. We have the need of getting a better DNS library in our ipa python modules, maybe writing tests using that library should be part of the work of replacing what we currently use. If we do it right we can make most tests non-ipa specific so that they can be used to test the plugin as a standalone component. > Push dynamic database API to upstream > ------------------------------------- > I got detailed information from Adam. Situation is better than I knew a > week ago during meeting. > Basically, ISC can accept current API, but there are some requirements: > - small code clean-up (not a big thing) > - complete documentation (of course) > - some sort of API tests > - example driver with *BSD* license, GPL is not acceptable > > Really simple driver is acceptable (without any dynamic things), so I > think it is doable. > > I think it will be better to push API to upstream after deep DNSSEC > inspection and implementation design, some problems can arise... I think this should have a very high priority. > More flexible/BIND equivalent record format > ------------------------------------------- > Current record format in LDAP is less powerful than BIND's. Generally, > each record can have own TTL value, see RFC1035 > http://tools.ietf.org/html/rfc1035 section 5.1. > We allow only single value per name, so it's not possible to have e.g. > single name with long-term A record and short term LOC record. > > It probably leads to some performance degradation in some special cases, > but generally it's not a problem. I think it's very-long-term "nice to > have". (It is good to remember to this problem in meantime.) > > Problem is, that this change will affect LDAP scheme and whole DNS UI, > so it's very problematic. Nice to have :-) We also would need to find a way to make this either optional or make it w/o breaking the schema, I would defer at this stage. > Never ending stories (in progress, of course :-) > -------------------- > - improve error handling > - improve configuration (local overriding etc.) > - stabilize persistent search > - performance optimization > > > > Thanks for you patience and sorry for long mail. Thanks for bringing this up, excellent summary. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Mar 19 13:54:24 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Mar 2012 09:54:24 -0400 Subject: [Freeipa-devel] DNS/bind-dyndb-ldap development plans In-Reply-To: <1332164522.9238.349.camel@willson.li.ssimo.org> References: <4F6735F1.9060704@redhat.com> <1332164522.9238.349.camel@willson.li.ssimo.org> Message-ID: <4F673A90.8070406@redhat.com> On 03/19/2012 09:42 AM, Simo Sorce wrote: > On Mon, 2012-03-19 at 14:34 +0100, Petr Spacek wrote: >> Hello list, >> >> there are several big features, that are missing in IPA DNS/plugin now. >> So we have to triage "big features" for next plugin development. >> >> In short - there is a list of biggest features: >> - DNSSEC (Domain Name System Security Extensions) support >> - IDN (Internationalized Domain Names) support >> - DNS test suite >> - Push dynamic database API to upstream >> - More flexible/BIND equivalent record format >> - "Never ending stories" about code quality etc. >> >> All details for each big item is below. BIND LDAP plugin Trac contains a >> lot of minor things + placeholders for some big features. >> URL: https://fedorahosted.org/bind-dyndb-ldap/report/3 >> >> >> DNSSEC (Domain Name System Security Extensions) support >> ------------------------------------------------------- >> There are some problems to be solved. After discussion with Adam I think >> it is doable. It requires some effort, but IMHO it is crucial feature >> for future. >> >> BIND supports DNSSEC from RHEL5. Fedora 17 will have client side >> support. There should not be any interoperability problem with DNSSEC >> client & not-DNSSEC-aware server (i.e. current IPA). >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/56 > This seems material for F18 maybe ? Yes this is a priority for RHEL7. I will add to PRD. F18 should be the upstream target. >> IDN (Internationalized Domain Names) support >> -------------------------------------------- >> Non ASCII domain names are encoded to ASCII strings. Theoretically it IS >> supported now in plugin, from plugin point of view it is nothing special. >> Another side is support for encoding/decoding strings in all our >> utilities, documentation and testing. >> >> Nowadays it's supported in DNS system from top-level and it's usable. >> >> The Question: Is there any user of this? I'm not really sure if somebody >> really uses IDN. But people with non-latin alphabet will probably have >> another opinion :-) >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/58 > Isn't this a matter of just having the UI compute the right value to > store in the plugin ? I do not think we want to do on the fly > conversions within the plugin, would be very inefficient. I am not sure this is a priority. Let us wait until asked. > >> DNS test suite >> -------------- >> We don't have any test suite now. Everything is tested manually, usually >> with dig. (Same situation is there with BIND package.) >> >> Several open source DNS tests are around on Internet. All of them are >> partial and they are usually unmaintained. Test them, select best >> pieces, write what will be missing and combine it to our DNS test suite. >> >> It would be better to start separate "dnstest" project or something >> similar. It can start from simple packaging of selected tools for Fedora >> and then start to integrate them to own test suite. >> >> Our client interface is plain DNS protocol, so it can be reused for BIND >> or any other DNS server. > We have the need of getting a better DNS library in our ipa python > modules, maybe writing tests using that library should be part of the > work of replacing what we currently use. > If we do it right we can make most tests non-ipa specific so that they > can be used to test the plugin as a standalone component. Makes sense to do. > >> Push dynamic database API to upstream >> ------------------------------------- >> I got detailed information from Adam. Situation is better than I knew a >> week ago during meeting. >> Basically, ISC can accept current API, but there are some requirements: >> - small code clean-up (not a big thing) >> - complete documentation (of course) >> - some sort of API tests >> - example driver with *BSD* license, GPL is not acceptable >> >> Really simple driver is acceptable (without any dynamic things), so I >> think it is doable. >> >> I think it will be better to push API to upstream after deep DNSSEC >> inspection and implementation design, some problems can arise... > I think this should have a very high priority. Can you explain this? What API we are talking about? > >> More flexible/BIND equivalent record format >> ------------------------------------------- >> Current record format in LDAP is less powerful than BIND's. Generally, >> each record can have own TTL value, see RFC1035 >> http://tools.ietf.org/html/rfc1035 section 5.1. >> We allow only single value per name, so it's not possible to have e.g. >> single name with long-term A record and short term LOC record. >> >> It probably leads to some performance degradation in some special cases, >> but generally it's not a problem. I think it's very-long-term "nice to >> have". (It is good to remember to this problem in meantime.) >> >> Problem is, that this change will affect LDAP scheme and whole DNS UI, >> so it's very problematic. > Nice to have :-) > We also would need to find a way to make this either optional or make it > w/o breaking the schema, I would defer at this stage. > Open an RFE in BZ if it does not exist and let us leave it there for now. >> Never ending stories (in progress, of course :-) >> -------------------- >> - improve error handling >> - improve configuration (local overriding etc.) >> - stabilize persistent search >> - performance optimization >> >> >> >> Thanks for you patience and sorry for long mail. > Thanks for bringing this up, excellent summary. > Indeed! Thanks! > 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 Mar 19 14:02:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 10:02:33 -0400 Subject: [Freeipa-devel] [PATCH] 990 attribute name in exceptions In-Reply-To: <4F66F83B.2080405@redhat.com> References: <4F63AF5A.4050005@redhat.com> <4F66F83B.2080405@redhat.com> Message-ID: <4F673C79.3000507@redhat.com> Petr Viktorin wrote: > On 03/16/2012 10:23 PM, Rob Crittenden wrote: >> When using *attr we should return the param.name of in the exception and >> when using a cli option we should return param.cli_name. This didn't >> work consistently in the framework. >> >> This is a bit of a kludge, catching exceptions and re-raising them, but >> it is a less invasive way of doing it. >> >> I added some examples of things to test in the ticket. >> >> rob >> > > > (name, error) = err.strerror.split(':') > > raise errors.ConversionError(name=attr, error=error) > > AFAIU this will break when the error message is translated. Why not just > use err.kw['error']? > Because the attribute name needs to get pulled out of it. rob From pvoborni at redhat.com Mon Mar 19 14:05:04 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 19 Mar 2012 15:05:04 +0100 Subject: [Freeipa-devel] [PATCH] 112 Added mac address to host page Message-ID: <4F673D10.6010205@redhat.com> Part of support for ether maps. https://fedorahosted.org/freeipa/ticket/2548 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0112-Added-mac-address-to-host-page.patch Type: text/x-patch Size: 4703 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 19 14:17:56 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 10:17:56 -0400 Subject: [Freeipa-devel] [PATCH] 987 Don't allow IPA master hosts and services to be disabled In-Reply-To: <1332146311.24427.7.camel@balmora.brq.redhat.com> References: <4F62595D.6070000@redhat.com> <4F632DAF.7050307@redhat.com> <4F633222.2020903@redhat.com> <1332146311.24427.7.camel@balmora.brq.redhat.com> Message-ID: <4F674014.4000601@redhat.com> Martin Kosek wrote: > On Fri, 2012-03-16 at 08:29 -0400, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/15/2012 10:04 PM, Rob Crittenden wrote: >>>> diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py >>>> index >>>> 9562ff98729ead6ac9e56d504f6ee0a7c0ca377a..f3c89a0fc5e3f00ed7f132dbff2510d89bc7370d >>>> 100644 >>>> --- a/ipalib/plugins/baseldap.py >>>> +++ b/ipalib/plugins/baseldap.py >>>> @@ -887,12 +877,29 @@ last, after all sets and adds."""), >>>> # normalize all values >>>> changedattrs = setattrs | addattrs | delattrs >>>> for attr in changedattrs: >>>> - # remove duplicite and invalid values >>>> - entry_attrs[attr] = list(set([val for val in entry_attrs[attr] if >>>> val])) >>>> - if not entry_attrs[attr]: >>>> - entry_attrs[attr] = None >>>> - elif isinstance(entry_attrs[attr], (tuple, list)) and >>>> len(entry_attrs[attr]) == 1: >>>> - entry_attrs[attr] = entry_attrs[attr][0] >>>> + if attr in self.obj.params: >>>> + # convert single-value params to scalars >>>> + # Need to use the LDAPObject's params, not self's, because the >>>> + # CRUD classes filter their disallowed parameters out. >>>> + # Yet {set,add,del}attr are powerful enough to change these >>>> + # (e.g. Config's ipacertificatesubjectbase) >>>> + if not self.obj.params[attr].multivalue: >>>> + if len(entry_attrs[attr]) == 1: >>>> + entry_attrs[attr] = entry_attrs[attr][0] >>>> + elif not entry_attrs[attr]: >>>> + entry_attrs[attr] = None >>>> + else: >>>> + raise errors.OnlyOneValueAllowed(attr=attr) >>>> + # validate and convert params >>>> + entry_attrs[attr] = self.obj.params[attr](entry_attrs[attr]) >>>> + else: >>>> + # unknown attribute: remove duplicite and invalid values >>>> + entry_attrs[attr] = list(set([val for val in entry_attrs[attr] if >>>> val])) >>>> + if not entry_attrs[attr]: >>>> + entry_attrs[attr] = None >>>> + elif isinstance(entry_attrs[attr], (tuple, list)) and >>>> len(entry_attrs[attr]) == 1: >>>> + entry_attrs[attr] = entry_attrs[attr][0] >>>> + >>> >>> You've included an unrelated patch (my 0016). >>> >> >> That's what I get for mixing my review and dev branch. Correct patch >> attached. >> >> rob > > I still think this is not the one. It somehow got squashed with Petr3's > *attr patch. > > Martin > Ok, was a little more careful this time. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-987-2-masterdisable.patch Type: text/x-diff Size: 6285 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 19 14:28:04 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Mar 2012 15:28:04 +0100 Subject: [Freeipa-devel] DNS/bind-dyndb-ldap development plans In-Reply-To: <4F673A90.8070406@redhat.com> References: <4F6735F1.9060704@redhat.com> <1332164522.9238.349.camel@willson.li.ssimo.org> <4F673A90.8070406@redhat.com> Message-ID: <1332167284.24427.29.camel@balmora.brq.redhat.com> On Mon, 2012-03-19 at 09:54 -0400, Dmitri Pal wrote: > On 03/19/2012 09:42 AM, Simo Sorce wrote: > > On Mon, 2012-03-19 at 14:34 +0100, Petr Spacek wrote: > >> Hello list, > >> > >> there are several big features, that are missing in IPA DNS/plugin now. > >> So we have to triage "big features" for next plugin development. > >> > >> In short - there is a list of biggest features: > >> - DNSSEC (Domain Name System Security Extensions) support > >> - IDN (Internationalized Domain Names) support > >> - DNS test suite > >> - Push dynamic database API to upstream > >> - More flexible/BIND equivalent record format > >> - "Never ending stories" about code quality etc. > >> > >> All details for each big item is below. BIND LDAP plugin Trac contains a > >> lot of minor things + placeholders for some big features. > >> URL: https://fedorahosted.org/bind-dyndb-ldap/report/3 > >> > >> > >> DNSSEC (Domain Name System Security Extensions) support > >> ------------------------------------------------------- > >> There are some problems to be solved. After discussion with Adam I think > >> it is doable. It requires some effort, but IMHO it is crucial feature > >> for future. > >> > >> BIND supports DNSSEC from RHEL5. Fedora 17 will have client side > >> support. There should not be any interoperability problem with DNSSEC > >> client & not-DNSSEC-aware server (i.e. current IPA). > >> > >> https://fedorahosted.org/bind-dyndb-ldap/ticket/56 > > This seems material for F18 maybe ? > > Yes this is a priority for RHEL7. I will add to PRD. F18 should be the > upstream target. Exactly. I also think it would be also a nice Fedora 18 feature. Fedora 17 introduces "DNSSEC on Workstations", so Fedora 18 would be a good time to add a support for FreeIPA DNS servers as well. > > >> IDN (Internationalized Domain Names) support > >> -------------------------------------------- > >> Non ASCII domain names are encoded to ASCII strings. Theoretically it IS > >> supported now in plugin, from plugin point of view it is nothing special. > >> Another side is support for encoding/decoding strings in all our > >> utilities, documentation and testing. > >> > >> Nowadays it's supported in DNS system from top-level and it's usable. > >> > >> The Question: Is there any user of this? I'm not really sure if somebody > >> really uses IDN. But people with non-latin alphabet will probably have > >> another opinion :-) > >> > >> https://fedorahosted.org/bind-dyndb-ldap/ticket/58 > > Isn't this a matter of just having the UI compute the right value to > > store in the plugin ? I do not think we want to do on the fly > > conversions within the plugin, would be very inefficient. Simo, I suppose you mean that encoding unicode<->punycode in bind-dyndb-ldap plugin would be inefficient. I can agree with that. I think our DNS plugin (CLI and WebUI) should simply do the encoding/decoding from unicode to punycode, bind-dyndb-ldap will then just pass the data to bind. > > I am not sure this is a priority. Let us wait until asked. +1. This may need some designing before we implement it and also we would need to define a scope of IDN support in the entire FreeIPA. Whether to implement it just for DNS resolution or also for other parts where we process hostnames. > > > >> DNS test suite > >> -------------- > >> We don't have any test suite now. Everything is tested manually, usually > >> with dig. (Same situation is there with BIND package.) > >> > >> Several open source DNS tests are around on Internet. All of them are > >> partial and they are usually unmaintained. Test them, select best > >> pieces, write what will be missing and combine it to our DNS test suite. > >> > >> It would be better to start separate "dnstest" project or something > >> similar. It can start from simple packaging of selected tools for Fedora > >> and then start to integrate them to own test suite. > >> > >> Our client interface is plain DNS protocol, so it can be reused for BIND > >> or any other DNS server. > > We have the need of getting a better DNS library in our ipa python > > modules, maybe writing tests using that library should be part of the > > work of replacing what we currently use. > > If we do it right we can make most tests non-ipa specific so that they > > can be used to test the plugin as a standalone component. > > Makes sense to do. > > > > >> Push dynamic database API to upstream > >> ------------------------------------- > >> I got detailed information from Adam. Situation is better than I knew a > >> week ago during meeting. > >> Basically, ISC can accept current API, but there are some requirements: > >> - small code clean-up (not a big thing) > >> - complete documentation (of course) > >> - some sort of API tests > >> - example driver with *BSD* license, GPL is not acceptable > >> > >> Really simple driver is acceptable (without any dynamic things), so I > >> think it is doable. > >> > >> I think it will be better to push API to upstream after deep DNSSEC > >> inspection and implementation design, some problems can arise... > > I think this should have a very high priority. > > Can you explain this? What API we are talking about? AFAIU, this is an API for bind name server for dynamic loading of database backends (like bind-dyndb-ldap). We need this patch in bind in order to be able to use bind-dyndb-ldap with bind. For a long time it was not accepted upstream, but was just bundled as a patch in Fedora (RHEL). > > > > >> More flexible/BIND equivalent record format > >> ------------------------------------------- > >> Current record format in LDAP is less powerful than BIND's. Generally, > >> each record can have own TTL value, see RFC1035 > >> http://tools.ietf.org/html/rfc1035 section 5.1. > >> We allow only single value per name, so it's not possible to have e.g. > >> single name with long-term A record and short term LOC record. > >> > >> It probably leads to some performance degradation in some special cases, > >> but generally it's not a problem. I think it's very-long-term "nice to > >> have". (It is good to remember to this problem in meantime.) > >> > >> Problem is, that this change will affect LDAP scheme and whole DNS UI, > >> so it's very problematic. > > Nice to have :-) > > We also would need to find a way to make this either optional or make it > > w/o breaking the schema, I would defer at this stage. > > > > Open an RFE in BZ if it does not exist and let us leave it there for now. > > >> Never ending stories (in progress, of course :-) > >> -------------------- > >> - improve error handling > >> - improve configuration (local overriding etc.) > >> - stabilize persistent search > >> - performance optimization > >> > >> > >> > >> Thanks for you patience and sorry for long mail. > > Thanks for bringing this up, excellent summary. > > > > Indeed! Thanks! > > > Simo. > > > > Yup, Petr, thanks for posting this. It is important to set our course as soon as possible so that we can manage to pass the deadlines. Martin From dpal at redhat.com Mon Mar 19 14:33:15 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Mar 2012 10:33:15 -0400 Subject: [Freeipa-devel] DNS/bind-dyndb-ldap development plans In-Reply-To: <1332167284.24427.29.camel@balmora.brq.redhat.com> References: <4F6735F1.9060704@redhat.com> <1332164522.9238.349.camel@willson.li.ssimo.org> <4F673A90.8070406@redhat.com> <1332167284.24427.29.camel@balmora.brq.redhat.com> Message-ID: <4F6743AB.5040900@redhat.com> On 03/19/2012 10:28 AM, Martin Kosek wrote: > AFAIU, this is an API for bind name server for dynamic loading of > database backends (like bind-dyndb-ldap). We need this patch in bind in > order to be able to use bind-dyndb-ldap with bind. For a long time it > was not accepted upstream, but was just bundled as a patch in Fedora > (RHEL). > Ah! Ok. Yes then the answer: "whenever we can make it happen". -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Mon Mar 19 14:38:54 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Mar 2012 15:38:54 +0100 Subject: [Freeipa-devel] [PATCH] 989 import plugins on context, not in_server In-Reply-To: <4F6735F1.6030508@redhat.com> References: <4F63AE62.2050709@redhat.com> <4F6735F1.6030508@redhat.com> Message-ID: <1332167934.24427.30.camel@balmora.brq.redhat.com> On Mon, 2012-03-19 at 14:34 +0100, Jan Cholasta wrote: > On 16.3.2012 22:19, Rob Crittenden wrote: > > in_server controls how messages are dispatched. We should import on > > context. > > > > This prevents the error message "session memcached servers not running" > > in ipa-ldap-updater and ipa-replica-manage. > > > > rob > > > > ACK. > > Honza > Pushed to master, ipa-2-2. Martin From pviktori at redhat.com Mon Mar 19 15:09:20 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 19 Mar 2012 16:09:20 +0100 Subject: [Freeipa-devel] [PATCH] 990 attribute name in exceptions In-Reply-To: <4F673C79.3000507@redhat.com> References: <4F63AF5A.4050005@redhat.com> <4F66F83B.2080405@redhat.com> <4F673C79.3000507@redhat.com> Message-ID: <4F674C20.7010203@redhat.com> On 03/19/2012 03:02 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/16/2012 10:23 PM, Rob Crittenden wrote: >>> When using *attr we should return the param.name of in the exception and >>> when using a cli option we should return param.cli_name. This didn't >>> work consistently in the framework. >>> >>> This is a bit of a kludge, catching exceptions and re-raising them, but >>> it is a less invasive way of doing it. >>> >>> I added some examples of things to test in the ticket. >>> >>> rob >>> >> >> > (name, error) = err.strerror.split(':') >> > raise errors.ConversionError(name=attr, error=error) >> >> AFAIU this will break when the error message is translated. Why not just >> use err.kw['error']? >> > > Because the attribute name needs to get pulled out of it. > > rob No, you're ignoring the attribute name. Anyway, even the English error messages are 'invalid %(name)r: %(error)s', so "name" part starts with 'invalid ', and the "error" part starts with an extra space. You've also based this on an old version of my patch 0016, which is not ACKed yet. Maybe it's better to wait until that gets in. -- Petr? From mkosek at redhat.com Mon Mar 19 15:10:16 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Mar 2012 16:10:16 +0100 Subject: [Freeipa-devel] [PATCH] 987 Don't allow IPA master hosts and services to be disabled In-Reply-To: <4F674014.4000601@redhat.com> References: <4F62595D.6070000@redhat.com> <4F632DAF.7050307@redhat.com> <4F633222.2020903@redhat.com> <1332146311.24427.7.camel@balmora.brq.redhat.com> <4F674014.4000601@redhat.com> Message-ID: <1332169816.24427.31.camel@balmora.brq.redhat.com> On Mon, 2012-03-19 at 10:17 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Fri, 2012-03-16 at 08:29 -0400, Rob Crittenden wrote: > >> Petr Viktorin wrote: > >>> On 03/15/2012 10:04 PM, Rob Crittenden wrote: > >>>> diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py > >>>> index > >>>> 9562ff98729ead6ac9e56d504f6ee0a7c0ca377a..f3c89a0fc5e3f00ed7f132dbff2510d89bc7370d > >>>> 100644 > >>>> --- a/ipalib/plugins/baseldap.py > >>>> +++ b/ipalib/plugins/baseldap.py > >>>> @@ -887,12 +877,29 @@ last, after all sets and adds."""), > >>>> # normalize all values > >>>> changedattrs = setattrs | addattrs | delattrs > >>>> for attr in changedattrs: > >>>> - # remove duplicite and invalid values > >>>> - entry_attrs[attr] = list(set([val for val in entry_attrs[attr] if > >>>> val])) > >>>> - if not entry_attrs[attr]: > >>>> - entry_attrs[attr] = None > >>>> - elif isinstance(entry_attrs[attr], (tuple, list)) and > >>>> len(entry_attrs[attr]) == 1: > >>>> - entry_attrs[attr] = entry_attrs[attr][0] > >>>> + if attr in self.obj.params: > >>>> + # convert single-value params to scalars > >>>> + # Need to use the LDAPObject's params, not self's, because the > >>>> + # CRUD classes filter their disallowed parameters out. > >>>> + # Yet {set,add,del}attr are powerful enough to change these > >>>> + # (e.g. Config's ipacertificatesubjectbase) > >>>> + if not self.obj.params[attr].multivalue: > >>>> + if len(entry_attrs[attr]) == 1: > >>>> + entry_attrs[attr] = entry_attrs[attr][0] > >>>> + elif not entry_attrs[attr]: > >>>> + entry_attrs[attr] = None > >>>> + else: > >>>> + raise errors.OnlyOneValueAllowed(attr=attr) > >>>> + # validate and convert params > >>>> + entry_attrs[attr] = self.obj.params[attr](entry_attrs[attr]) > >>>> + else: > >>>> + # unknown attribute: remove duplicite and invalid values > >>>> + entry_attrs[attr] = list(set([val for val in entry_attrs[attr] if > >>>> val])) > >>>> + if not entry_attrs[attr]: > >>>> + entry_attrs[attr] = None > >>>> + elif isinstance(entry_attrs[attr], (tuple, list)) and > >>>> len(entry_attrs[attr]) == 1: > >>>> + entry_attrs[attr] = entry_attrs[attr][0] > >>>> + > >>> > >>> You've included an unrelated patch (my 0016). > >>> > >> > >> That's what I get for mixing my review and dev branch. Correct patch > >> attached. > >> > >> rob > > > > I still think this is not the one. It somehow got squashed with Petr3's > > *attr patch. > > > > Martin > > > > Ok, was a little more careful this time. > > rob Yup, its much better now. ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Mon Mar 19 15:34:29 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Mar 2012 16:34:29 +0100 Subject: [Freeipa-devel] [PATCH] 0024 Fix expected exception checking in tests In-Reply-To: <4F633916.4070005@redhat.com> References: <4F5A306B.9090001@redhat.com> <4F6260EA.6080308@redhat.com> <4F633916.4070005@redhat.com> Message-ID: <1332171269.24427.32.camel@balmora.brq.redhat.com> On Fri, 2012-03-16 at 13:59 +0100, Petr Viktorin wrote: > On 03/15/2012 10:36 PM, Rob Crittenden wrote: > > Petr Viktorin wrote: > >> Can you spot the bug in this test code? > >> > >> try: > >> do_invalid_operation() > >> except ExpectedError: > >> pass > >> > >> > >> Our test suite had several of those. > >> Nose provides nice tools, `raises` (a decorator) and `assert_raises` (a > >> context manager) that make checking expected exceptions a lot easier and > >> less error-prone. This patch makes our tests use them. > >> > >> If you didn't catch it, the error is that the test will pass when no > >> exception is raised. Some of our tests handled that by adding an `else: > >> assert False`, or an `assert False` at the end of the try block. > >> For consistency, the patch switches these correct ones to > >> raises/assert_raises as well. > >> > >> I've also uncovered and fixed a few test bugs that were hidden by this. > >> > > > > > > test_1a_automountmap_add_indirect() was failing, checking for the wrong > > exception. > > Silly me. Thanks for catching this. > > > I also suggest using @raises for clarity in another spot. Here are my > > suggested changes: > > > > Attaching updated patch. > ACK. Pushed to master, ipa-2-2. Martin From edewata at redhat.com Mon Mar 19 15:46:57 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 19 Mar 2012 10:46:57 -0500 Subject: [Freeipa-devel] [PATCH] 109 Fixed rpm build warning - extension.js listed twice In-Reply-To: <4F61F422.10701@redhat.com> References: <4F60ADC0.1090202@redhat.com> <4F61F422.10701@redhat.com> Message-ID: <4F6754F1.7040402@redhat.com> On 3/15/2012 8:52 AM, Petr Vobornik wrote: > Attached updated patch with totally different approach (thanks Endi). > > This patch moves extension.js to new directory: 'ext'. Ext directory > should serve as a place for user extensions. > > It eliminated the problem. ACK. -- Endi S. Dewata From edewata at redhat.com Mon Mar 19 15:47:32 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 19 Mar 2012 10:47:32 -0500 Subject: [Freeipa-devel] [PATCH] 107 Content is no more overwritten by error message In-Reply-To: <4F635109.1050600@redhat.com> References: <4F5A0299.2060006@redhat.com> <4F5FC230.40207@redhat.com> <4F635109.1050600@redhat.com> Message-ID: <4F675514.8090705@redhat.com> ACK 106-1 and 111. See comments below. On 3/16/2012 9:41 AM, Petr Vobornik wrote: > On 03/13/2012 10:54 PM, Endi Sukma Dewata wrote: >> In the ticket I added 2 more scenarios to reproduce the problem. So we >> have 3 possible cases: >> 1. invalid UI state >> 2. non-existent entry >> 3. server down >> >> For case #1, the patch provides a much better message, but I think >> ideally if some parameters are missing from the URL (e.g. the parent >> pkey) it should be detected by the UI before sending the request to the >> server. This probably should be addressed in a separate ticket. See the >> note below about the error message. >> >> For case #2, the patch fixes the issue by clearing up the error message. >> This works on all entities except users because the user details page >> uses a batch operation to get the data and it doesn't handle >> non-existent users properly. I think this is an existing and separate >> issue. >> >> For case #3, the patch will show a message saying that the UI got into >> an invalid state, which is actually not the case here. Also, returning >> to the main page or reloading the page wouldn't solve the problem either. >> >> So for this ticket I think it would be better to show a more generic >> error message, something like this: > > Reworked. >> >> An error has occured (IPA Error 3007) >> >> 'idnsname' is required Do you think it would look better if the message is formatted like this: An error has occured IPA Error 3007: 'idnsname' is required Or use the error as the title (without 'An error has occured'): IPA Error 3007 'idnsname' is required It's up to you. Feel free to change it before push if you want. >> Please try the following options: >> * Refresh the page. (see note below) >> * Return to the main page and retry the operation. > We are talking about main page. What is it? Identity/Users? Navigation > code operates also with currently displayed facet. So when I now > navigate to '#' (empty state) it won't have to be Identity/Users. The > good part is that it navigates to page in a branch where user was > operating. Right, the 'main page' isn't really defined, so the user might try all possible 'main pages' until it works again (which is not necessarily a bad thing). Not sure if we should use the term 'search/list page', it might not apply to all cases. At least the link helps reduce the confusion. >> * Reload the browser. >> If the problem persists please contact the system administrator. >> >> Each of the above options could be made into a link that does the >> mentioned operation. >> >> It would be great if we can use the Refresh button to clear the error >> message. If this requires significant effort we probably can remove this >> option from the message above and add it in a separate ticket. > > The patch is quite short. I was more concerned about the fact that when > overriding stuff, developer would have to think about one more thing. > The UI is getting more and more complex. But it might not be as a big > problem as I originally thought. I put the call to refresh success > handler, mainly because report_error is in error handler, and these > handlers aren't overridden often. Attached as separate patch. OK. The refresh/load/reset/update is one area that still needs cleanup. >> One more thing, this may not be a problem now, but the error_container >> uses both facet-content and facet-error CSS classes. I understand this >> is done to avoid code duplication, but this also means the facet will >> have 2 facet-contents. CSS classes can be used for decorative or >> structural purposes or both, so we need to make sure decorative changes >> will not affect it structurally. One solution is to duplicate the CSS >> code from facet-content into facet-error. Another solution is to use a >> separate decorative class that are added into both facet-content and >> facet-error elements. >> > It is little bit more difficult. If I look at it structurally the error > div is facet-content too. So the facet has two contents - proper and > error. Is it OK? Does it break some design principle. If so, would it be > better to have separate error_facet? > > I think it is not good to have two contents but current implementation > is not ready for separate error_facet - navigation code might protest. My original concern was suppose someone uses jQuery to search for facet-content he might find 2 elements. But maybe not since only one of them is enabled, I haven't verified it. I think this is OK for now. We'll revisit the code if it becomes a problem. One more thing, try shutting down slapd and load the UI. After closing the error dialog the page will show the same error message, but it isn't nicely formatted. I think it should show the same message like above probably with reloading the browser as the only option. Or the refresh option too if we show the Refresh button. This can be fixed separately. -- Endi S. Dewata From edewata at redhat.com Mon Mar 19 15:47:37 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 19 Mar 2012 10:47:37 -0500 Subject: [Freeipa-devel] [PATCH] 112 Added mac address to host page In-Reply-To: <4F673D10.6010205@redhat.com> References: <4F673D10.6010205@redhat.com> Message-ID: <4F675519.4060905@redhat.com> On 3/19/2012 9:05 AM, Petr Vobornik wrote: > Part of support for ether maps. > > https://fedorahosted.org/freeipa/ticket/2548 ACK. -- Endi S. Dewata From mkosek at redhat.com Mon Mar 19 15:59:32 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Mar 2012 16:59:32 +0100 Subject: [Freeipa-devel] [PATCH] 227-228 Add last missing bits in new bind-dyndb-ldap In-Reply-To: <4F5F1962.6050707@redhat.com> References: <1330604359.4451.18.camel@balmora.brq.redhat.com> <1331132781.22847.4.camel@balmora.brq.redhat.com> <4F5E3C1E.9060501@redhat.com> <4F5F1962.6050707@redhat.com> Message-ID: <1332172772.24427.37.camel@balmora.brq.redhat.com> On Tue, 2012-03-13 at 10:54 +0100, Petr Spacek wrote: > On 03/12/2012 07:10 PM, Rob Crittenden wrote: > > Martin Kosek wrote: > >> On Thu, 2012-03-01 at 13:19 +0100, Martin Kosek wrote: > >>> These 2 patches changes the DNS API to support the last missing bits in > >>> new bind-dyndb-ldap: > >>> > >>> 1) Both global and per-zone forwarders now support a conditional custom > >>> port (with format "IP_ADDRESS PORT") > >>> 2) Missing global configuration options have been added: > >>> * idnsforwardpolicy: Default policy for conditional forwarding > >>> * idnsallowsyncptr: Allow globaly PTR synchronization for dynamic > >>> updates > >>> * idnszonerefresh: Default interval between regular polls of the > >>> name server for new DNS zones > >>> > >>> Before these patches are pushed, I will just have to update the minimal > >>> bind-dyndb-ldap version (it has not been built yet) which have a full > >>> support for these. > >>> > >>> Martin > >> > >> New version of bind-dyndb-ldap has been released, attaching a rebased > >> patch with fixed bind-dyndb-ldap version in spec file. > >> > >> I also fixed the forwarder format, it should be "$IP port $PORT", not > >> "$IP $PORT" as it was in a previous version of the patch. I tested this > >> new format with bind-dyndb-ldap it forwards the queries properly. > >> > >> Unfortunately, fixed version of bind have not been released yet, i.e. > >> bind will crash if forwarders are defined both in named.conf and LDAP > >> global configuration (dnsconfig-mod). > >> > >> Martin > > > > The patch itself looks ok, just a couple of general concerns: > > > > 1. By default dnsconfig-show displays nothing. This is a little > > disconcerting. I don't believe we show empty attributes anywhere else, > > not sure if we should make an exception here or show some other message, > > perhaps a varying summary? > > > > 2. I don't think there is a lot we can do but this still conflicts with > > the file-based configuration. For example, someone can add a forwarder > > and caused named to not restart the next time because there is also one > > defined in named.conf. I'd almost prefer that one win rather than the > > daemon not start at all. But for our purposes people may get confused > > because they don't see the forwarders they configured at install time > > and merely managing this list can break your name server at some > > undetermined future point. > > > > rob > > This problem is in BZ https://bugzilla.redhat.com/show_bug.cgi?id=795414 . > > Patch for this is ON_QA in RHEL6 and will be pushed to Fedora at some > point this week. (This Adam said yesterday on IRC.) > > Current solution prefers value from LDAP before local configuration. > > Petr^2 Spacek > The fix for this BZ has been backported to Fedora 16 and released to updates-testing: https://admin.fedoraproject.org/updates/FEDORA-2012-4091/bind-9.8.2-0.4.rc2.fc16 Attaching a patch which properly forbids conflicts with older versions of bind. The new bind should no longer crash when a configuration options like forwarders is defined both in LDAP and named.conf. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-227-3-allow-port-numbers-for-idnsforwarders.patch Type: text/x-patch Size: 3642 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-228-3-add-missing-global-options-in-dnsconfig.patch Type: text/x-patch Size: 4704 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 19 16:25:57 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Mar 2012 17:25:57 +0100 Subject: [Freeipa-devel] [PATCH] 15 Confusing default user groups In-Reply-To: <4F565247.2050105@redhat.com> References: <4F565247.2050105@redhat.com> Message-ID: <1332174357.24427.47.camel@balmora.brq.redhat.com> On Tue, 2012-03-06 at 19:07 +0100, Ondrej Hamada wrote: > https://fedorahosted.org/freeipa/ticket/2354 > > There was added '(fallback)' string in the automember plugin labels > referring to automember default groups to point out, that the users are > already members of default group specified in IPA config, thus the > default group specified in automember will be additional one - a > fallback group. Hm, looks ok. Though I would also like some second opinion for this change. I think naming it simply "Fallback Group" would be better, but we cannot change the API at this stage and rename the parameter. So this change is a good compromise so far, IMO. I found few issues though: 1) The label of default group parameter in automember has not been updated, i.e. the following command still shows the old name: # ipa automember-default-group-show --type=group Default Group: cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com 2) I think we could fix few issues in docstrings since we touch these strings anyway: a) Typo in doc - label=_('Default Group'), - doc=_('Default group for entires to land'), + label=_('Default (fallback) Group'), + doc=_('Default (fallback) group for entires to land'), b) Non-translatable strings: - entry_attrs['automemberdefaultgroup'] = u'No default group set' + entry_attrs['automemberdefaultgroup'] = u'No default (fallback) group set' - entry_attrs['automemberdefaultgroup'] = u'No default group set' + entry_attrs['automemberdefaultgroup'] = u'No default (fallback) group set' Martin From simo at redhat.com Mon Mar 19 16:46:39 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2012 12:46:39 -0400 Subject: [Freeipa-devel] DNS/bind-dyndb-ldap development plans In-Reply-To: <1332167284.24427.29.camel@balmora.brq.redhat.com> References: <4F6735F1.9060704@redhat.com> <1332164522.9238.349.camel@willson.li.ssimo.org> <4F673A90.8070406@redhat.com> <1332167284.24427.29.camel@balmora.brq.redhat.com> Message-ID: <1332175599.9238.419.camel@willson.li.ssimo.org> On Mon, 2012-03-19 at 15:28 +0100, Martin Kosek wrote: > > >> IDN (Internationalized Domain Names) support > > >> -------------------------------------------- > > >> Non ASCII domain names are encoded to ASCII strings. > Theoretically it IS > > >> supported now in plugin, from plugin point of view it is nothing > special. > > >> Another side is support for encoding/decoding strings in all our > > >> utilities, documentation and testing. > > >> > > >> Nowadays it's supported in DNS system from top-level and it's > usable. > > >> > > >> The Question: Is there any user of this? I'm not really sure if > somebody > > >> really uses IDN. But people with non-latin alphabet will probably > have > > >> another opinion :-) > > >> > > >> https://fedorahosted.org/bind-dyndb-ldap/ticket/58 > > > Isn't this a matter of just having the UI compute the right value > to > > > store in the plugin ? I do not think we want to do on the fly > > > conversions within the plugin, would be very inefficient. > > Simo, I suppose you mean that encoding unicode<->punycode in > bind-dyndb-ldap plugin would be inefficient. I can agree with that. I > think our DNS plugin (CLI and WebUI) should simply do the > encoding/decoding from unicode to punycode, bind-dyndb-ldap will then > just pass the data to bind. Yes this is what I mean and would like to see. > > I am not sure this is a priority. Let us wait until asked. > > +1. This may need some designing before we implement it and also we > would need to define a scope of IDN support in the entire FreeIPA. > Whether to implement it just for DNS resolution or also for other > parts > where we process hostnames. Yes we may need this elsewhere, one key place we need to deal with this is kerberos. Currently it is undefined what the format should be for fqdns that want to use non ascii characters and laegly depends on what is storage in the kdc, except that we do not know what clients would do. At the last Kerberos Consortium Conference we also asked Microsoft what they do, in order to avoid making non-interoperable choice. MS people there didn't know for sure but they thought that in their Krb implementation utf8 names may be used an not punycode. So before we move forward we need to make a comprehensive research and possibly file bugs against upstream krb5 if it turns out the MIT client libraries or the MIT KDC need to smarten up somehow to handle IDN names. W/o making this type of research all we will obtain is broken hosts I would guess. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Mon Mar 19 17:56:19 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 19 Mar 2012 18:56:19 +0100 Subject: [Freeipa-devel] [PATCH] 109 Fixed rpm build warning - extension.js listed twice In-Reply-To: <4F6754F1.7040402@redhat.com> References: <4F60ADC0.1090202@redhat.com> <4F61F422.10701@redhat.com> <4F6754F1.7040402@redhat.com> Message-ID: <4F677343.8090009@redhat.com> On 03/19/2012 04:46 PM, Endi Sukma Dewata wrote: > On 3/15/2012 8:52 AM, Petr Vobornik wrote: >> Attached updated patch with totally different approach (thanks Endi). >> >> This patch moves extension.js to new directory: 'ext'. Ext directory >> should serve as a place for user extensions. >> >> It eliminated the problem. > > ACK. > Pushed to master, ipa-2-2. -- Petr Vobornik From pvoborni at redhat.com Mon Mar 19 18:06:57 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 19 Mar 2012 19:06:57 +0100 Subject: [Freeipa-devel] [PATCH] 107 Content is no more overwritten by error message In-Reply-To: <4F675514.8090705@redhat.com> References: <4F5A0299.2060006@redhat.com> <4F5FC230.40207@redhat.com> <4F635109.1050600@redhat.com> <4F675514.8090705@redhat.com> Message-ID: <4F6775C1.40303@redhat.com> On 03/19/2012 04:47 PM, Endi Sukma Dewata wrote: > ACK 106-1 and 111. See comments below. Pushed to master, ipa-2-2. > On 3/16/2012 9:41 AM, Petr Vobornik wrote: >> On 03/13/2012 10:54 PM, Endi Sukma Dewata wrote: >>> In the ticket I added 2 more scenarios to reproduce the problem. So we >>> have 3 possible cases: >>> 1. invalid UI state >>> 2. non-existent entry >>> 3. server down >>> >>> For case #1, the patch provides a much better message, but I think >>> ideally if some parameters are missing from the URL (e.g. the parent >>> pkey) it should be detected by the UI before sending the request to the >>> server. This probably should be addressed in a separate ticket. See the >>> note below about the error message. >>> >>> For case #2, the patch fixes the issue by clearing up the error message. >>> This works on all entities except users because the user details page >>> uses a batch operation to get the data and it doesn't handle >>> non-existent users properly. I think this is an existing and separate >>> issue. >>> >>> For case #3, the patch will show a message saying that the UI got into >>> an invalid state, which is actually not the case here. Also, returning >>> to the main page or reloading the page wouldn't solve the problem >>> either. >>> >>> So for this ticket I think it would be better to show a more generic >>> error message, something like this: >> >> Reworked. >>> >>> An error has occured (IPA Error 3007) >>> >>> 'idnsname' is required > > Do you think it would look better if the message is formatted like this: > > An error has occured > > IPA Error 3007: 'idnsname' is required I'm indecisive between this and implemented. > > Or use the error as the title (without 'An error has occured'): > > IPA Error 3007 > > 'idnsname' is required > With ["Unknown error","error"] it looks cryptic. > It's up to you. Feel free to change it before push if you want. --> I haven't changed it. > >>> Please try the following options: >>> * Refresh the page. (see note below) >>> * Return to the main page and retry the operation. >> We are talking about main page. What is it? Identity/Users? Navigation >> code operates also with currently displayed facet. So when I now >> navigate to '#' (empty state) it won't have to be Identity/Users. The >> good part is that it navigates to page in a branch where user was >> operating. > > Right, the 'main page' isn't really defined, so the user might try all > possible 'main pages' until it works again (which is not necessarily a > bad thing). Not sure if we should use the term 'search/list page', it > might not apply to all cases. At least the link helps reduce the confusion. > >>> * Reload the browser. >>> If the problem persists please contact the system administrator. >>> >>> Each of the above options could be made into a link that does the >>> mentioned operation. >>> >>> It would be great if we can use the Refresh button to clear the error >>> message. If this requires significant effort we probably can remove this >>> option from the message above and add it in a separate ticket. >> >> The patch is quite short. I was more concerned about the fact that when >> overriding stuff, developer would have to think about one more thing. >> The UI is getting more and more complex. But it might not be as a big >> problem as I originally thought. I put the call to refresh success >> handler, mainly because report_error is in error handler, and these >> handlers aren't overridden often. Attached as separate patch. > > OK. The refresh/load/reset/update is one area that still needs cleanup. > >>> One more thing, this may not be a problem now, but the error_container >>> uses both facet-content and facet-error CSS classes. I understand this >>> is done to avoid code duplication, but this also means the facet will >>> have 2 facet-contents. CSS classes can be used for decorative or >>> structural purposes or both, so we need to make sure decorative changes >>> will not affect it structurally. One solution is to duplicate the CSS >>> code from facet-content into facet-error. Another solution is to use a >>> separate decorative class that are added into both facet-content and >>> facet-error elements. >>> >> It is little bit more difficult. If I look at it structurally the error >> div is facet-content too. So the facet has two contents - proper and >> error. Is it OK? Does it break some design principle. If so, would it be >> better to have separate error_facet? >> >> I think it is not good to have two contents but current implementation >> is not ready for separate error_facet - navigation code might protest. > > My original concern was suppose someone uses jQuery to search for > facet-content he might find 2 elements. But maybe not since only one of > them is enabled, I haven't verified it. I think this is OK for now. > We'll revisit the code if it becomes a problem. What about ids? ie: id="entity_name-facet_name-content_name" > > One more thing, try shutting down slapd and load the UI. After closing > the error dialog the page will show the same error message, but it isn't > nicely formatted. I think it should show the same message like above > probably with reloading the browser as the only option. Or the refresh > option too if we show the Refresh button. This can be fixed separately. > -- Petr Vobornik From rcritten at redhat.com Mon Mar 19 18:43:22 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 14:43:22 -0400 Subject: [Freeipa-devel] [PATCH] 990 attribute name in exceptions In-Reply-To: <4F674C20.7010203@redhat.com> References: <4F63AF5A.4050005@redhat.com> <4F66F83B.2080405@redhat.com> <4F673C79.3000507@redhat.com> <4F674C20.7010203@redhat.com> Message-ID: <4F677E4A.5060603@redhat.com> Petr Viktorin wrote: > On 03/19/2012 03:02 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/16/2012 10:23 PM, Rob Crittenden wrote: >>>> When using *attr we should return the param.name of in the exception >>>> and >>>> when using a cli option we should return param.cli_name. This didn't >>>> work consistently in the framework. >>>> >>>> This is a bit of a kludge, catching exceptions and re-raising them, but >>>> it is a less invasive way of doing it. >>>> >>>> I added some examples of things to test in the ticket. >>>> >>>> rob >>>> >>> >>> > (name, error) = err.strerror.split(':') >>> > raise errors.ConversionError(name=attr, error=error) >>> >>> AFAIU this will break when the error message is translated. Why not just >>> use err.kw['error']? >>> >> >> Because the attribute name needs to get pulled out of it. >> >> rob > > No, you're ignoring the attribute name. > Anyway, even the English error messages are 'invalid %(name)r: > %(error)s', so "name" part starts with 'invalid ', and the "error" part > starts with an extra space. The error gets re-raised so there is no dup "invalid". I'll grant you the extra space though. What this does is catch something like 'invalid maxfail: something bad', split out the attribute/error and re-raise use the attribute name we want. > You've also based this on an old version of my patch 0016, which is not > ACKed yet. Maybe it's better to wait until that gets in. > It isn't dependent upon your patch, I may just have had it still applied when I did this. From mkosek at redhat.com Mon Mar 19 19:17:56 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Mar 2012 20:17:56 +0100 Subject: [Freeipa-devel] [PATCH] 990 attribute name in exceptions In-Reply-To: <4F677E4A.5060603@redhat.com> References: <4F63AF5A.4050005@redhat.com> <4F66F83B.2080405@redhat.com> <4F673C79.3000507@redhat.com> <4F674C20.7010203@redhat.com> <4F677E4A.5060603@redhat.com> Message-ID: <1332184676.2215.2.camel@priserak> On Mon, 2012-03-19 at 14:43 -0400, Rob Crittenden wrote: > Petr Viktorin wrote: > > On 03/19/2012 03:02 PM, Rob Crittenden wrote: > >> Petr Viktorin wrote: > >>> On 03/16/2012 10:23 PM, Rob Crittenden wrote: > >>>> When using *attr we should return the param.name of in the exception > >>>> and > >>>> when using a cli option we should return param.cli_name. This didn't > >>>> work consistently in the framework. > >>>> > >>>> This is a bit of a kludge, catching exceptions and re-raising them, but > >>>> it is a less invasive way of doing it. > >>>> > >>>> I added some examples of things to test in the ticket. > >>>> > >>>> rob > >>>> > >>> > >>> > (name, error) = err.strerror.split(':') > >>> > raise errors.ConversionError(name=attr, error=error) > >>> > >>> AFAIU this will break when the error message is translated. Why not just > >>> use err.kw['error']? > >>> > >> > >> Because the attribute name needs to get pulled out of it. > >> > >> rob > > > > No, you're ignoring the attribute name. > > Anyway, even the English error messages are 'invalid %(name)r: > > %(error)s', so "name" part starts with 'invalid ', and the "error" part > > starts with an extra space. > > The error gets re-raised so there is no dup "invalid". I'll grant you > the extra space though. > > What this does is catch something like 'invalid maxfail: something bad', > split out the attribute/error and re-raise use the attribute name we want. I think this is what Petr wanted to point out - you can access the attributes passed to our PublicErrors directly, i.e. you don't have to parse it from its string representation: >>> from ipalib import errors >>> x = errors.ValidationError(name='foo', error=u'Invalid value!') >>> print str(x) invalid 'foo': Invalid value! >>> x.name 'foo' >>> x.error u'Invalid value!' Martin From edewata at redhat.com Mon Mar 19 19:31:16 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 19 Mar 2012 14:31:16 -0500 Subject: [Freeipa-devel] [PATCH] 107 Content is no more overwritten by error message In-Reply-To: <4F6775C1.40303@redhat.com> References: <4F5A0299.2060006@redhat.com> <4F5FC230.40207@redhat.com> <4F635109.1050600@redhat.com> <4F675514.8090705@redhat.com> <4F6775C1.40303@redhat.com> Message-ID: <4F678984.5090202@redhat.com> On 3/19/2012 1:06 PM, Petr Vobornik wrote: >>>> One more thing, this may not be a problem now, but the error_container >>>> uses both facet-content and facet-error CSS classes. I understand this >>>> is done to avoid code duplication, but this also means the facet will >>>> have 2 facet-contents. CSS classes can be used for decorative or >>>> structural purposes or both, so we need to make sure decorative changes >>>> will not affect it structurally. One solution is to duplicate the CSS >>>> code from facet-content into facet-error. Another solution is to use a >>>> separate decorative class that are added into both facet-content and >>>> facet-error elements. >>>> >>> It is little bit more difficult. If I look at it structurally the error >>> div is facet-content too. So the facet has two contents - proper and >>> error. Is it OK? Does it break some design principle. If so, would it be >>> better to have separate error_facet? >>> >>> I think it is not good to have two contents but current implementation >>> is not ready for separate error_facet - navigation code might protest. >> >> My original concern was suppose someone uses jQuery to search for >> facet-content he might find 2 elements. But maybe not since only one of >> them is enabled, I haven't verified it. I think this is OK for now. >> We'll revisit the code if it becomes a problem. > > What about ids? ie: id="entity_name-facet_name-content_name" I'd rather not use ID if possible. The ID will be long, harder to use and maintain. Another possibility is to move facet-error into facet-content, but I'm not sure it will help address the problem. -- Endi S. Dewata From rcritten at redhat.com Mon Mar 19 19:41:11 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 15:41:11 -0400 Subject: [Freeipa-devel] [PATCH] 990 attribute name in exceptions In-Reply-To: <1332184676.2215.2.camel@priserak> References: <4F63AF5A.4050005@redhat.com> <4F66F83B.2080405@redhat.com> <4F673C79.3000507@redhat.com> <4F674C20.7010203@redhat.com> <4F677E4A.5060603@redhat.com> <1332184676.2215.2.camel@priserak> Message-ID: <4F678BD7.3070106@redhat.com> Martin Kosek wrote: > On Mon, 2012-03-19 at 14:43 -0400, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/19/2012 03:02 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 03/16/2012 10:23 PM, Rob Crittenden wrote: >>>>>> When using *attr we should return the param.name of in the exception >>>>>> and >>>>>> when using a cli option we should return param.cli_name. This didn't >>>>>> work consistently in the framework. >>>>>> >>>>>> This is a bit of a kludge, catching exceptions and re-raising them, but >>>>>> it is a less invasive way of doing it. >>>>>> >>>>>> I added some examples of things to test in the ticket. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>>> (name, error) = err.strerror.split(':') >>>>>> raise errors.ConversionError(name=attr, error=error) >>>>> >>>>> AFAIU this will break when the error message is translated. Why not just >>>>> use err.kw['error']? >>>>> >>>> >>>> Because the attribute name needs to get pulled out of it. >>>> >>>> rob >>> >>> No, you're ignoring the attribute name. >>> Anyway, even the English error messages are 'invalid %(name)r: >>> %(error)s', so "name" part starts with 'invalid ', and the "error" part >>> starts with an extra space. >> >> The error gets re-raised so there is no dup "invalid". I'll grant you >> the extra space though. >> >> What this does is catch something like 'invalid maxfail: something bad', >> split out the attribute/error and re-raise use the attribute name we want. > > I think this is what Petr wanted to point out - you can access the > attributes passed to our PublicErrors directly, i.e. you don't have to > parse it from its string representation: > >>>> from ipalib import errors >>>> x = errors.ValidationError(name='foo', error=u'Invalid value!') >>>> print str(x) > invalid 'foo': Invalid value! >>>> x.name > 'foo' >>>> x.error > u'Invalid value!' > > Martin > Of course, can't believe I missed that. Rebased against ipa-2-2. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-990-2-attribute.patch Type: text/x-diff Size: 5471 bytes Desc: not available URL: From pspacek at redhat.com Mon Mar 19 20:36:38 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 19 Mar 2012 21:36:38 +0100 Subject: [Freeipa-devel] DNS/bind-dyndb-ldap development plans In-Reply-To: <1332167284.24427.29.camel@balmora.brq.redhat.com> References: <4F6735F1.9060704@redhat.com> <1332164522.9238.349.camel@willson.li.ssimo.org> <4F673A90.8070406@redhat.com> <1332167284.24427.29.camel@balmora.brq.redhat.com> Message-ID: <4F6798D6.5020907@redhat.com> On 03/19/2012 03:28 PM, Martin Kosek wrote: > On Mon, 2012-03-19 at 09:54 -0400, Dmitri Pal wrote: >> On 03/19/2012 09:42 AM, Simo Sorce wrote: >>> On Mon, 2012-03-19 at 14:34 +0100, Petr Spacek wrote: >>>> Hello list, >>>> >>>> there are several big features, that are missing in IPA DNS/plugin now. >>>> So we have to triage "big features" for next plugin development. >>>> >>>> In short - there is a list of biggest features: >>>> - DNSSEC (Domain Name System Security Extensions) support >>>> - IDN (Internationalized Domain Names) support >>>> - DNS test suite >>>> - Push dynamic database API to upstream >>>> - More flexible/BIND equivalent record format >>>> - "Never ending stories" about code quality etc. >>>> >>>> All details for each big item is below. BIND LDAP plugin Trac contains a >>>> lot of minor things + placeholders for some big features. >>>> URL: https://fedorahosted.org/bind-dyndb-ldap/report/3 >>>> >>>> >>>> DNSSEC (Domain Name System Security Extensions) support >>>> ------------------------------------------------------- >>>> There are some problems to be solved. After discussion with Adam I think >>>> it is doable. It requires some effort, but IMHO it is crucial feature >>>> for future. >>>> >>>> BIND supports DNSSEC from RHEL5. Fedora 17 will have client side >>>> support. There should not be any interoperability problem with DNSSEC >>>> client& not-DNSSEC-aware server (i.e. current IPA). >>>> >>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/56 >>> This seems material for F18 maybe ? >> >> Yes this is a priority for RHEL7. I will add to PRD. F18 should be the >> upstream target. > > Exactly. I also think it would be also a nice Fedora 18 feature. Fedora > 17 introduces "DNSSEC on Workstations", so Fedora 18 would be a good > time to add a support for FreeIPA DNS servers as well. I definitely agree. >>>> IDN (Internationalized Domain Names) support >>>> -------------------------------------------- >>>> Non ASCII domain names are encoded to ASCII strings. Theoretically it IS >>>> supported now in plugin, from plugin point of view it is nothing special. >>>> Another side is support for encoding/decoding strings in all our >>>> utilities, documentation and testing. >>>> >>>> Nowadays it's supported in DNS system from top-level and it's usable. >>>> >>>> The Question: Is there any user of this? I'm not really sure if somebody >>>> really uses IDN. But people with non-latin alphabet will probably have >>>> another opinion :-) >>>> >>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/58 >>> Isn't this a matter of just having the UI compute the right value to >>> store in the plugin ? I do not think we want to do on the fly >>> conversions within the plugin, would be very inefficient. > > Simo, I suppose you mean that encoding unicode<->punycode in > bind-dyndb-ldap plugin would be inefficient. I can agree with that. I > think our DNS plugin (CLI and WebUI) should simply do the > encoding/decoding from unicode to punycode, bind-dyndb-ldap will then > just pass the data to bind. > >> >> I am not sure this is a priority. Let us wait until asked. > > +1. This may need some designing before we implement it and also we > would need to define a scope of IDN support in the entire FreeIPA. > Whether to implement it just for DNS resolution or also for other parts > where we process hostnames. I also agree with postponing. Simo is right, it's not about plugin, but about UI and other parts as Kerberos etc. I not mentioned it clearly, sorry. >>>> DNS test suite >>>> -------------- >>>> We don't have any test suite now. Everything is tested manually, usually >>>> with dig. (Same situation is there with BIND package.) >>>> >>>> Several open source DNS tests are around on Internet. All of them are >>>> partial and they are usually unmaintained. Test them, select best >>>> pieces, write what will be missing and combine it to our DNS test suite. >>>> >>>> It would be better to start separate "dnstest" project or something >>>> similar. It can start from simple packaging of selected tools for Fedora >>>> and then start to integrate them to own test suite. >>>> >>>> Our client interface is plain DNS protocol, so it can be reused for BIND >>>> or any other DNS server. >>> We have the need of getting a better DNS library in our ipa python >>> modules, maybe writing tests using that library should be part of the >>> work of replacing what we currently use. >>> If we do it right we can make most tests non-ipa specific so that they >>> can be used to test the plugin as a standalone component. >> >> Makes sense to do. I can't imagine IPA-only DNS test other than simple DNS queries and nsupdate. Do you have any other example? I think we use plain DNS/DNSSEC, the rest is only about our DNS records. For this reason I propose to design DNS testing "framework" as totally IPA independent. I can imagine this "framework" as more or less integrated set of existing tools with some scripting support. Then we can implement testing scripts ("IPA test suite") for all IPA-related records and other things. IMHO main focus has to be put on trying-out of existing frameworks and integrating them together, not developing something big from scratch. My candidates for deeper exploration: http://www.zonecheck.fr/ http://www.tahi.org/dns/ (low level DNS tests) http://www.dnspython.org/ (scripting to glue all thinks together) We can share this framework with other DNS guys (e.g. Adam :-) and work together on improvements. I think they will be happy with this kind of tool. BTW: Which Python DNS library was selected as substitute for IPA? DNS Python (www.dnspython.org)? >>>> Push dynamic database API to upstream >>>> ------------------------------------- >>>> I got detailed information from Adam. Situation is better than I knew a >>>> week ago during meeting. >>>> Basically, ISC can accept current API, but there are some requirements: >>>> - small code clean-up (not a big thing) >>>> - complete documentation (of course) >>>> - some sort of API tests >>>> - example driver with *BSD* license, GPL is not acceptable >>>> >>>> Really simple driver is acceptable (without any dynamic things), so I >>>> think it is doable. >>>> >>>> I think it will be better to push API to upstream after deep DNSSEC >>>> inspection and implementation design, some problems can arise... >>> I think this should have a very high priority. >> >> Can you explain this? What API we are talking about? > > AFAIU, this is an API for bind name server for dynamic loading of > database backends (like bind-dyndb-ldap). We need this patch in bind in > order to be able to use bind-dyndb-ldap with bind. For a long time it > was not accepted upstream, but was just bundled as a patch in Fedora > (RHEL). > >> >>> >>>> More flexible/BIND equivalent record format >>>> ------------------------------------------- >>>> Current record format in LDAP is less powerful than BIND's. Generally, >>>> each record can have own TTL value, see RFC1035 >>>> http://tools.ietf.org/html/rfc1035 section 5.1. >>>> We allow only single value per name, so it's not possible to have e.g. >>>> single name with long-term A record and short term LOC record. >>>> >>>> It probably leads to some performance degradation in some special cases, >>>> but generally it's not a problem. I think it's very-long-term "nice to >>>> have". (It is good to remember to this problem in meantime.) >>>> >>>> Problem is, that this change will affect LDAP scheme and whole DNS UI, >>>> so it's very problematic. >>> Nice to have :-) >>> We also would need to find a way to make this either optional or make it >>> w/o breaking the schema, I would defer at this stage. >>> >> >> Open an RFE in BZ if it does not exist and let us leave it there for now. ACK >>>> Never ending stories (in progress, of course :-) >>>> -------------------- >>>> - improve error handling >>>> - improve configuration (local overriding etc.) >>>> - stabilize persistent search >>>> - performance optimization >>>> >>>> >>>> >>>> Thanks for you patience and sorry for long mail. >>> Thanks for bringing this up, excellent summary. >>> >> >> Indeed! Thanks! >> >>> Simo. >>> >> >> > > Yup, Petr, thanks for posting this. It is important to set our course as > soon as possible so that we can manage to pass the deadlines. > > Martin Petr^2 Spacek From mkosek at redhat.com Tue Mar 20 08:10:37 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Mar 2012 09:10:37 +0100 Subject: [Freeipa-devel] [PATCH] 990 attribute name in exceptions In-Reply-To: <4F678BD7.3070106@redhat.com> References: <4F63AF5A.4050005@redhat.com> <4F66F83B.2080405@redhat.com> <4F673C79.3000507@redhat.com> <4F674C20.7010203@redhat.com> <4F677E4A.5060603@redhat.com> <1332184676.2215.2.camel@priserak> <4F678BD7.3070106@redhat.com> Message-ID: <1332231037.20122.1.camel@balmora.brq.redhat.com> On Mon, 2012-03-19 at 15:41 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Mon, 2012-03-19 at 14:43 -0400, Rob Crittenden wrote: > >> Petr Viktorin wrote: > >>> On 03/19/2012 03:02 PM, Rob Crittenden wrote: > >>>> Petr Viktorin wrote: > >>>>> On 03/16/2012 10:23 PM, Rob Crittenden wrote: > >>>>>> When using *attr we should return the param.name of in the exception > >>>>>> and > >>>>>> when using a cli option we should return param.cli_name. This didn't > >>>>>> work consistently in the framework. > >>>>>> > >>>>>> This is a bit of a kludge, catching exceptions and re-raising them, but > >>>>>> it is a less invasive way of doing it. > >>>>>> > >>>>>> I added some examples of things to test in the ticket. > >>>>>> > >>>>>> rob > >>>>>> > >>>>> > >>>>>> (name, error) = err.strerror.split(':') > >>>>>> raise errors.ConversionError(name=attr, error=error) > >>>>> > >>>>> AFAIU this will break when the error message is translated. Why not just > >>>>> use err.kw['error']? > >>>>> > >>>> > >>>> Because the attribute name needs to get pulled out of it. > >>>> > >>>> rob > >>> > >>> No, you're ignoring the attribute name. > >>> Anyway, even the English error messages are 'invalid %(name)r: > >>> %(error)s', so "name" part starts with 'invalid ', and the "error" part > >>> starts with an extra space. > >> > >> The error gets re-raised so there is no dup "invalid". I'll grant you > >> the extra space though. > >> > >> What this does is catch something like 'invalid maxfail: something bad', > >> split out the attribute/error and re-raise use the attribute name we want. > > > > I think this is what Petr wanted to point out - you can access the > > attributes passed to our PublicErrors directly, i.e. you don't have to > > parse it from its string representation: > > > >>>> from ipalib import errors > >>>> x = errors.ValidationError(name='foo', error=u'Invalid value!') > >>>> print str(x) > > invalid 'foo': Invalid value! > >>>> x.name > > 'foo' > >>>> x.error > > u'Invalid value!' > > > > Martin > > > > Of course, can't believe I missed that. > > Rebased against ipa-2-2. > > rob Yeah, this one is much better. ACK, pushed to master, ipa-2-2. Martin From pviktori at redhat.com Tue Mar 20 09:54:56 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 20 Mar 2012 10:54:56 +0100 Subject: [Freeipa-devel] [PATCH] 0016 Fixes for{add, set, del}attr with managed attributes In-Reply-To: <4F638DF4.4060602@redhat.com> References: <4F4B6648.1070209@redhat.com> <4F4BFDB7.7030501@redhat.com> <4F4E2655.2010207@redhat.com> <4F4E3B2F.3040609@redhat.com> <4F4E4586.2070805@redhat.com> <4F4F46C9.6030804@redhat.com> <4F624FE1.2080000@redhat.com> <4F634B9C.6030903@redhat.com> <4F63784B.4020009@redhat.com> <4F637961.4050805@redhat.com> <4F6379D8.1050602@redhat.com> <4F638DF4.4060602@redhat.com> Message-ID: <4F6853F0.7030007@redhat.com> On 03/16/2012 08:01 PM, Petr Viktorin wrote: > On 03/16/2012 06:35 PM, Petr Viktorin wrote: >> On 03/16/2012 06:33 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 03/15/2012 09:24 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 02/29/2012 04:34 PM, Petr Viktorin wrote: >>>>>>>> On 02/29/2012 03:50 PM, Rob Crittenden wrote: >>>>>>>>> Petr Viktorin wrote: >>>>>>>>>> On 02/27/2012 11:03 PM, Rob Crittenden wrote: >>>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>>> Patch 16 defers validation & conversion until after >>>>>>>>>>>> {add,del,set}attr is >>>>>>>>>>>> processed, so that we don't search for an integer in a list of >>>>>>>>>>>> strings >>>>>>>>>>>> (this caused ticket #2405), and so that the end result of these >>>>>>>>>>>> operations is validated (#2407). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Patch 17 makes these options honor params marked no_create and >>>>>>>>>>>> no_update. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2405 >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2407 >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2408 >>>>>>>>>>> >>>>>>>>>>> NACK on Patch 17 which breaks patch 16. >>>>>>>>>> >>>>>>>>>> How is patch 16 broken? It works for me. >>>>>>>>> >>>>>>>>> My point is they rely on one another, IMHO, so without 17 the >>>>>>>>> reported >>>>>>>>> problem still exists. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> *attr is specifically made to be powerful. We don't want to >>>>>>>>>>> arbitrarily >>>>>>>>>>> block updating certain values. >>>>>>>>>> >>>>>>>>>> Noted >>>>>>>>>> >>>>>>>>>>> Not having patch 17 means that the problem reported in 2408 >>>>>>>>>>> still >>>>>>>>>>> occurs. It should probably check both the schema and the >>>>>>>>>>> param to >>>>>>>>>>> determine if something can have multiple values and reject that >>>>>>>>>>> way. >>>>>>>>>> >>>>>>>>>> I see the problem now: the certificate subject base is defined >>>>>>>>>> as a >>>>>>>>>> multi-value attribute in the LDAP schema. If it's changed to >>>>>>>>>> single-value the existing validation should catch it. >>>>>>>>>> >>>>>>>>>> Also, most of the config attributes should probably be >>>>>>>>>> required in >>>>>>>>>> the >>>>>>>>>> schema. Am I right? >>>>>>>>>> >>>>>>>>>> I'm a newbie here; what do I need to do when changing the >>>>>>>>>> schema? Is >>>>>>>>>> there a patch that does something similar I could use as an >>>>>>>>>> example? >>>>>>>>>> >>>>>>>>> >>>>>>>>> The framework should be able to impose its own single-value >>>>>>>>> will as >>>>>>>>> well. If a Param is designated as single-value the *attr should >>>>>>>>> honor >>>>>>>>> it. >>>>>>>> >>>>>>>> Here is the updated patch. >>>>>>>> Since *attr is powerful enough to modify 'no_update' Params, which >>>>>>>> CRUDUpdate forgets about, I need to check the params of the >>>>>>>> LDAPObject >>>>>>>> itself. >>>>>>>> >>>>>>>>> Updating schema is a bit of a nasty business right now. See >>>>>>>>> 10-selinuxusermap.update for an example. >>>>>>>> >>>>>>>> I'll leave schema changes for after the release, then. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>>> Attached patch includes tests. Note that the test depends on my >>>>>>> patches >>>>>>> 12-13, which make ipasearchrecordslimit required. >>>>>> >>>>>> I gather that this eliminates the need for patch 17? It seems to work >>>>>> as-is. >>>>> >>>>> Yes. Patch 17 made *attr honor no_create and no_update, which you said >>>>> is not desired behavior. >>>>> >>>>>> The patch doesn't apply because of an encoding change Martin made >>>>>> recently. >>>>>> >>>>>> It does seem to do the right thing though. >>>>>> >>>>>> rob >>>>> >>>>> Attaching rebased patch. >>>>> This deletes Martin's change, but unless I tested wrong, his bug >>>>> (https://fedorahosted.org/freeipa/ticket/2418) stays fixed. The >>>>> tests in >>>>> my patch should apply to that ticket as well. >>>>> >>>>> In another fork of this thread, there's discussion if this approach is >>>>> good at all. Maybe we're overengineering a corner case here. >>>>> >>>> >>>> Found another issue, a very subtle one. >>>> >>>> When using *attr and an exception occurs where the param name would >>>> appear we want the name passed in to be used. >>>> >>>> For example: >>>> >>>> $ ipa pwpolicy-mod --setattr=krbpwdmaxfailure=xyz >>>> >>>> With this patch it will return: >>>> ipa: ERROR: invalid 'maxfail': must be an integer >>>> >>>> It should return: >>>> ipa: ERROR: invalid 'krbpwdmaxfailure': must be an integer >>> >>> On second thought, this may not be related... >> >> This is https://fedorahosted.org/freeipa/ticket/1418, I'll see if it >> makes sense to fix it here. > > Okay, this is a different problem. A quick grep of ConversionError in > parameters.py reveals that all of the "wrong datatype" errors are raised > with the raw parameter name. > Other errors are raised with either that or the cli_name or they > auto-detect. I don't think they follow some rule in this. > > Furthermore, our test suite doesn't check exception arguments. Sounds > like a major cleanup coming up here... > >>> >>>> >>>> The encoding problem does still exist too: >>>> >>>> $ ipa config-mod --setattr ipamigrationenabled=false >>>> ipa: ERROR: ipaMigrationEnabled: value #0 invalid per syntax: Invalid >>>> syntax. >>>> >> >> Will fix. >> > > Fixed in the attached update, which encodes the value. > > I was surprised to find that > config_mod.params['ipamigrationenabled'].attribute is True, while > config_mod.obj.params['ipamigrationenabled'].attribute is False (and so > its encode() method does nothing). That's because 'attribute' is only > set when the params are cloned from the LDAPObject to the CRUD method. > Is there a reason behind this, or is it just that it was easier to do? > > For this case it means that params marked no_update will not be encoded > properly -- getting to a working encode() would require either setting > 'attribute' on the parent object or some ugly hackery. > > > > --- > Petr? > Rebased to current master. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0016-06-Defer-conversion-and-validation-until-after-add-del-.patch Type: text/x-patch Size: 9585 bytes Desc: not available URL: From marco.pizzoli at gmail.com Tue Mar 20 11:44:43 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Tue, 20 Mar 2012 12:44:43 +0100 Subject: [Freeipa-devel] FreeIPA beta1: SELinux prohibits memcached Message-ID: Hi guys, I don't know if you already know this, but in my logs I can find this: Mar 20 12:14:47 freeipa01 setroubleshoot: SELinux is preventing /usr/bin/memcached from create access on the sock_file ipa_memcached. For complete SELinux messages. run sealert -l 85b51f4e-3f2e-4e7d-819f-1efb04836de3 I'm running: [root at freeipa01 ipa]# rpm -qa|grep freeipa freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 freeipa-client-2.1.90.rc1-0.fc16.x86_64 freeipa-server-2.1.90.rc1-0.fc16.x86_64 freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 freeipa-python-2.1.90.rc1-0.fc16.x86_64 HTH Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at radicore.se Tue Mar 20 12:00:03 2012 From: lars at radicore.se (=?ISO-8859-1?Q?Lars_Sj=F6str=F6m?=) Date: Tue, 20 Mar 2012 13:00:03 +0100 Subject: [Freeipa-devel] [PATCH] Try to reacquire keytab file if host already joined Message-ID: Hello fellow devs, I have a proposed patch for ticket #2106 (https://fedorahosted.org/freeipa/ticket/2106) if return code is 13 (Host already joined) of ipa-join command the host will try to reacquire the keytab file. Feedback appreciated! Cheers, Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Try-to-reacquire-keytab-file-if-host-already-joined.patch Type: text/x-patch Size: 3161 bytes Desc: not available URL: From mkosek at redhat.com Tue Mar 20 12:02:50 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Mar 2012 13:02:50 +0100 Subject: [Freeipa-devel] FreeIPA beta1: SELinux prohibits memcached In-Reply-To: References: Message-ID: <1332244970.20122.11.camel@balmora.brq.redhat.com> On Tue, 2012-03-20 at 12:44 +0100, Marco Pizzoli wrote: > Hi guys, > I don't know if you already know this, but in my logs I can find this: > > > Mar 20 12:14:47 freeipa01 setroubleshoot: SELinux is > preventing /usr/bin/memcached from create access on the sock_file > ipa_memcached. For complete SELinux messages. run sealert -l > 85b51f4e-3f2e-4e7d-819f-1efb04836de3 > > > I'm running: > > > [root at freeipa01 ipa]# rpm -qa|grep freeipa > freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 > freeipa-client-2.1.90.rc1-0.fc16.x86_64 > freeipa-server-2.1.90.rc1-0.fc16.x86_64 > freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 > freeipa-python-2.1.90.rc1-0.fc16.x86_64 > > > HTH > Marco Hello Marco, there is a SELinux policy where this issue is fixed: https://admin.fedoraproject.org/updates/FEDORA-2012-2733/selinux-policy-3.10.0-80.fc16 Its still in updates-testing though. This is an appropriate BZ: https://bugzilla.redhat.com/show_bug.cgi?id=783592 It requires "httpd_manage_ipa" SELinux boolean to be set, upstream FreeIPA bits already sets it automatically during installation. Martin From marco.pizzoli at gmail.com Tue Mar 20 12:14:39 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Tue, 20 Mar 2012 13:14:39 +0100 Subject: [Freeipa-devel] FreeIPA beta1: SELinux prohibits memcached In-Reply-To: <1332244970.20122.11.camel@balmora.brq.redhat.com> References: <1332244970.20122.11.camel@balmora.brq.redhat.com> Message-ID: Hi Martin, On Tue, Mar 20, 2012 at 1:02 PM, Martin Kosek wrote: > On Tue, 2012-03-20 at 12:44 +0100, Marco Pizzoli wrote: > > Hi guys, > > I don't know if you already know this, but in my logs I can find this: > > > > > > Mar 20 12:14:47 freeipa01 setroubleshoot: SELinux is > > preventing /usr/bin/memcached from create access on the sock_file > > ipa_memcached. For complete SELinux messages. run sealert -l > > 85b51f4e-3f2e-4e7d-819f-1efb04836de3 > > > > > > I'm running: > > > > > > [root at freeipa01 ipa]# rpm -qa|grep freeipa > > freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 > > freeipa-client-2.1.90.rc1-0.fc16.x86_64 > > freeipa-server-2.1.90.rc1-0.fc16.x86_64 > > freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 > > freeipa-python-2.1.90.rc1-0.fc16.x86_64 > > > > > > HTH > > Marco > > Hello Marco, > > there is a SELinux policy where this issue is fixed: > > https://admin.fedoraproject.org/updates/FEDORA-2012-2733/selinux-policy-3.10.0-80.fc16 > > Its still in updates-testing though. This is an appropriate BZ: > https://bugzilla.redhat.com/show_bug.cgi?id=783592 Thanks for your answer. Just to be aligned, actually it's not still available on the updates-testing channel too. I see on the cli that I cannot update to that release and by looking at the link you posted I see it has still to be pushed -> current state: pending. Thanks again Marco > > > It requires "httpd_manage_ipa" SELinux boolean to be set, upstream > FreeIPA bits already sets it automatically during installation. > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Mar 20 12:28:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Mar 2012 13:28:49 +0100 Subject: [Freeipa-devel] FreeIPA beta1: SELinux prohibits memcached In-Reply-To: References: <1332244970.20122.11.camel@balmora.brq.redhat.com> Message-ID: <1332246529.20122.14.camel@balmora.brq.redhat.com> On Tue, 2012-03-20 at 13:14 +0100, Marco Pizzoli wrote: > Hi Martin, > > On Tue, Mar 20, 2012 at 1:02 PM, Martin Kosek > wrote: > On Tue, 2012-03-20 at 12:44 +0100, Marco Pizzoli wrote: > > Hi guys, > > I don't know if you already know this, but in my logs I can > find this: > > > > > > Mar 20 12:14:47 freeipa01 setroubleshoot: SELinux is > > preventing /usr/bin/memcached from create access on the > sock_file > > ipa_memcached. For complete SELinux messages. run sealert -l > > 85b51f4e-3f2e-4e7d-819f-1efb04836de3 > > > > > > I'm running: > > > > > > [root at freeipa01 ipa]# rpm -qa|grep freeipa > > freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 > > freeipa-client-2.1.90.rc1-0.fc16.x86_64 > > freeipa-server-2.1.90.rc1-0.fc16.x86_64 > > freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 > > freeipa-python-2.1.90.rc1-0.fc16.x86_64 > > > > > > HTH > > Marco > > > Hello Marco, > > there is a SELinux policy where this issue is fixed: > https://admin.fedoraproject.org/updates/FEDORA-2012-2733/selinux-policy-3.10.0-80.fc16 > > Its still in updates-testing though. This is an appropriate > BZ: > https://bugzilla.redhat.com/show_bug.cgi?id=783592 > > > Thanks for your answer. > Just to be aligned, actually it's not still available on the > updates-testing channel too. > I see on the cli that I cannot update to that release and by looking > at the link you posted I see it has still to be pushed -> current > state: pending. > > > Thanks again > Marco You are right, its not there yet. You can just download and install fixed RPM from koji (there is a link on Fedora update file), but it is of course a SElinux policy version without proper community testing. I tried it and it worked for me, no AVC raised. Martin From pviktori at redhat.com Tue Mar 20 12:39:41 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 20 Mar 2012 13:39:41 +0100 Subject: [Freeipa-devel] [PATCH] 0019 Check expected error messages in tests Message-ID: <4F687A8D.6020508@redhat.com> This patch adds checking error messages, not just types, to the XML-RPC tests. The checking is still somewhat hackish, since XML-RPC doesn't give us structured error info, but it should protect against regressions on issues like whether we put name or cli_name in a ValidationError. https://fedorahosted.org/freeipa/ticket/2549 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0029-Fix-expected-error-messages-in-tests.patch Type: text/x-patch Size: 61541 bytes Desc: not available URL: From simo at redhat.com Tue Mar 20 12:44:21 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 20 Mar 2012 08:44:21 -0400 Subject: [Freeipa-devel] [PATCH] Try to reacquire keytab file if host already joined In-Reply-To: References: Message-ID: <1332247461.9238.615.camel@willson.li.ssimo.org> On Tue, 2012-03-20 at 13:00 +0100, Lars Sj?str?m wrote: > Hello fellow devs, > > I have a proposed patch for ticket #2106 > (https://fedorahosted.org/freeipa/ticket/2106) > > if return code is 13 (Host already joined) of ipa-join command the > host will try to reacquire the keytab file. > > Feedback appreciated! Hi Lars, at the very least this should be conditional and be allowed only when an override flag is passed. The reason we punt here is that you may be trying to join a machine with the same name of an already joined and working machine by mistake. We do not want to void that other machine credentials unless the admin wants to force it. Simo. -- Simo Sorce * Red Hat, Inc * New York From lars at radicore.se Tue Mar 20 13:11:27 2012 From: lars at radicore.se (=?ISO-8859-1?Q?Lars_Sj=F6str=F6m?=) Date: Tue, 20 Mar 2012 14:11:27 +0100 Subject: [Freeipa-devel] [PATCH] Try to reacquire keytab file if host already joined In-Reply-To: <1332247461.9238.615.camel@willson.li.ssimo.org> References: <1332247461.9238.615.camel@willson.li.ssimo.org> Message-ID: Hi, Understood! Would it be ok to add an optional flag then? like --reacquire ? like so: # run only if force and reacquire is set if options.force and options.reacquire: # try to fetch keytab... Cheers, Lars Den 20 mars 2012 13:44 skrev Simo Sorce : > On Tue, 2012-03-20 at 13:00 +0100, Lars Sj?str?m wrote: >> Hello fellow devs, >> >> I have a proposed patch for ticket #2106 >> (https://fedorahosted.org/freeipa/ticket/2106) >> >> if return code is 13 (Host already joined) of ipa-join command the >> host will try to reacquire the keytab file. >> >> Feedback appreciated! > > Hi Lars, at the very least this should be conditional and be allowed > only when an override flag is passed. The reason we punt here is that > you may be trying to join a machine with the same name of an already > joined and working machine by mistake. > We do not want to void that other machine credentials unless the admin > wants to force it. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > -- Lars Sj?str?m Senior Consultant / Owner Radicore AB Mobile:?+46 (0)703 021502 Email:?lars at radicore.se Web:?http://www.radicore.se From rcritten at redhat.com Tue Mar 20 14:27:18 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Mar 2012 10:27:18 -0400 Subject: [Freeipa-devel] [PATCH] 227-228 Add last missing bits in new bind-dyndb-ldap In-Reply-To: <1332172772.24427.37.camel@balmora.brq.redhat.com> References: <1330604359.4451.18.camel@balmora.brq.redhat.com> <1331132781.22847.4.camel@balmora.brq.redhat.com> <4F5E3C1E.9060501@redhat.com> <4F5F1962.6050707@redhat.com> <1332172772.24427.37.camel@balmora.brq.redhat.com> Message-ID: <4F6893C6.1080709@redhat.com> Martin Kosek wrote: > On Tue, 2012-03-13 at 10:54 +0100, Petr Spacek wrote: >> On 03/12/2012 07:10 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On Thu, 2012-03-01 at 13:19 +0100, Martin Kosek wrote: >>>>> These 2 patches changes the DNS API to support the last missing bits in >>>>> new bind-dyndb-ldap: >>>>> >>>>> 1) Both global and per-zone forwarders now support a conditional custom >>>>> port (with format "IP_ADDRESS PORT") >>>>> 2) Missing global configuration options have been added: >>>>> * idnsforwardpolicy: Default policy for conditional forwarding >>>>> * idnsallowsyncptr: Allow globaly PTR synchronization for dynamic >>>>> updates >>>>> * idnszonerefresh: Default interval between regular polls of the >>>>> name server for new DNS zones >>>>> >>>>> Before these patches are pushed, I will just have to update the minimal >>>>> bind-dyndb-ldap version (it has not been built yet) which have a full >>>>> support for these. >>>>> >>>>> Martin >>>> >>>> New version of bind-dyndb-ldap has been released, attaching a rebased >>>> patch with fixed bind-dyndb-ldap version in spec file. >>>> >>>> I also fixed the forwarder format, it should be "$IP port $PORT", not >>>> "$IP $PORT" as it was in a previous version of the patch. I tested this >>>> new format with bind-dyndb-ldap it forwards the queries properly. >>>> >>>> Unfortunately, fixed version of bind have not been released yet, i.e. >>>> bind will crash if forwarders are defined both in named.conf and LDAP >>>> global configuration (dnsconfig-mod). >>>> >>>> Martin >>> >>> The patch itself looks ok, just a couple of general concerns: >>> >>> 1. By default dnsconfig-show displays nothing. This is a little >>> disconcerting. I don't believe we show empty attributes anywhere else, >>> not sure if we should make an exception here or show some other message, >>> perhaps a varying summary? >>> >>> 2. I don't think there is a lot we can do but this still conflicts with >>> the file-based configuration. For example, someone can add a forwarder >>> and caused named to not restart the next time because there is also one >>> defined in named.conf. I'd almost prefer that one win rather than the >>> daemon not start at all. But for our purposes people may get confused >>> because they don't see the forwarders they configured at install time >>> and merely managing this list can break your name server at some >>> undetermined future point. >>> >>> rob >> >> This problem is in BZ https://bugzilla.redhat.com/show_bug.cgi?id=795414 . >> >> Patch for this is ON_QA in RHEL6 and will be pushed to Fedora at some >> point this week. (This Adam said yesterday on IRC.) >> >> Current solution prefers value from LDAP before local configuration. >> >> Petr^2 Spacek >> > > The fix for this BZ has been backported to Fedora 16 and released to > updates-testing: > https://admin.fedoraproject.org/updates/FEDORA-2012-4091/bind-9.8.2-0.4.rc2.fc16 > > Attaching a patch which properly forbids conflicts with older versions > of bind. The new bind should no longer crash when a configuration > options like forwarders is defined both in LDAP and named.conf. > > Martin ACK to both From mkosek at redhat.com Tue Mar 20 14:41:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Mar 2012 15:41:19 +0100 Subject: [Freeipa-devel] [PATCH] 227-228 Add last missing bits in new bind-dyndb-ldap In-Reply-To: <4F6893C6.1080709@redhat.com> References: <1330604359.4451.18.camel@balmora.brq.redhat.com> <1331132781.22847.4.camel@balmora.brq.redhat.com> <4F5E3C1E.9060501@redhat.com> <4F5F1962.6050707@redhat.com> <1332172772.24427.37.camel@balmora.brq.redhat.com> <4F6893C6.1080709@redhat.com> Message-ID: <1332254479.20122.20.camel@balmora.brq.redhat.com> On Tue, 2012-03-20 at 10:27 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Tue, 2012-03-13 at 10:54 +0100, Petr Spacek wrote: > >> On 03/12/2012 07:10 PM, Rob Crittenden wrote: > >>> Martin Kosek wrote: > >>>> On Thu, 2012-03-01 at 13:19 +0100, Martin Kosek wrote: > >>>>> These 2 patches changes the DNS API to support the last missing bits in > >>>>> new bind-dyndb-ldap: > >>>>> > >>>>> 1) Both global and per-zone forwarders now support a conditional custom > >>>>> port (with format "IP_ADDRESS PORT") > >>>>> 2) Missing global configuration options have been added: > >>>>> * idnsforwardpolicy: Default policy for conditional forwarding > >>>>> * idnsallowsyncptr: Allow globaly PTR synchronization for dynamic > >>>>> updates > >>>>> * idnszonerefresh: Default interval between regular polls of the > >>>>> name server for new DNS zones > >>>>> > >>>>> Before these patches are pushed, I will just have to update the minimal > >>>>> bind-dyndb-ldap version (it has not been built yet) which have a full > >>>>> support for these. > >>>>> > >>>>> Martin > >>>> > >>>> New version of bind-dyndb-ldap has been released, attaching a rebased > >>>> patch with fixed bind-dyndb-ldap version in spec file. > >>>> > >>>> I also fixed the forwarder format, it should be "$IP port $PORT", not > >>>> "$IP $PORT" as it was in a previous version of the patch. I tested this > >>>> new format with bind-dyndb-ldap it forwards the queries properly. > >>>> > >>>> Unfortunately, fixed version of bind have not been released yet, i.e. > >>>> bind will crash if forwarders are defined both in named.conf and LDAP > >>>> global configuration (dnsconfig-mod). > >>>> > >>>> Martin > >>> > >>> The patch itself looks ok, just a couple of general concerns: > >>> > >>> 1. By default dnsconfig-show displays nothing. This is a little > >>> disconcerting. I don't believe we show empty attributes anywhere else, > >>> not sure if we should make an exception here or show some other message, > >>> perhaps a varying summary? > >>> > >>> 2. I don't think there is a lot we can do but this still conflicts with > >>> the file-based configuration. For example, someone can add a forwarder > >>> and caused named to not restart the next time because there is also one > >>> defined in named.conf. I'd almost prefer that one win rather than the > >>> daemon not start at all. But for our purposes people may get confused > >>> because they don't see the forwarders they configured at install time > >>> and merely managing this list can break your name server at some > >>> undetermined future point. > >>> > >>> rob > >> > >> This problem is in BZ https://bugzilla.redhat.com/show_bug.cgi?id=795414 . > >> > >> Patch for this is ON_QA in RHEL6 and will be pushed to Fedora at some > >> point this week. (This Adam said yesterday on IRC.) > >> > >> Current solution prefers value from LDAP before local configuration. > >> > >> Petr^2 Spacek > >> > > > > The fix for this BZ has been backported to Fedora 16 and released to > > updates-testing: > > https://admin.fedoraproject.org/updates/FEDORA-2012-4091/bind-9.8.2-0.4.rc2.fc16 > > > > Attaching a patch which properly forbids conflicts with older versions > > of bind. The new bind should no longer crash when a configuration > > options like forwarders is defined both in LDAP and named.conf. > > > > Martin > > ACK to both > Thanks. Pushed to master, ipa-2-2. Martin From simo at redhat.com Tue Mar 20 16:22:34 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 20 Mar 2012 12:22:34 -0400 Subject: [Freeipa-devel] [PATCH] 489 Fix coverity issues Message-ID: <1332260554.9238.636.camel@willson.li.ssimo.org> There is one memory leak in case of an unlikely error condition, most others are just changes to silence coverity where we know that the condition cannot really happen. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-489-1-Fix-memleak-and-silence-Coverity-defects.patch Type: text/x-patch Size: 3399 bytes Desc: not available URL: From pvoborni at redhat.com Tue Mar 20 16:43:03 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Mar 2012 17:43:03 +0100 Subject: [Freeipa-devel] [PATCH] 102-103 UI part of 'Add last missing bits in new bind-dyndb-ldap' In-Reply-To: <4F598723.8060200@redhat.com> References: <4F578861.6090900@redhat.com> <4F598723.8060200@redhat.com> Message-ID: <4F68B397.6020901@redhat.com> On 03/09/2012 05:29 AM, Endi Sukma Dewata wrote: > ACK. There are some minor issues. Pushed to master, ipa-2-2. > > On 3/7/2012 10:10 AM, Petr Vobornik wrote: >> 1) Add support of new options in dnsconfig >> >> dnsconfig was extended of new attributes, so reflecting it in UI. >> >> New attributes: >> * idnsForwardPolicy >> * idnsAllowSyncPTR >> * idnsZoneRefresh >> >> https://fedorahosted.org/freeipa/ticket/2489 > > If you click the idnsallowsyncptr checkbox and click again to return to > the original value, it will still show the undo button. > >> 2) DNS forwarder's value can consist of IP address and a port. >> >> The syntax is ' port '. A new validator was created >> for this purpose. It is based on IP address validator. > > The validator is rather strict, it allows exactly a single space between > the words. If someone mistakenly type an additional space, the > validation error could be confusing because two adjacent spaces are > sometimes not very obvious. I think either the UI or the server (or > both) should normalize the space. Another option is to use separate > fields for the IP address and the port in the multivalued field: > > Global forwarders: [192.168.1.1 ] port [80 ] Delete > Add > -- Petr Vobornik From pvoborni at redhat.com Tue Mar 20 16:43:22 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Mar 2012 17:43:22 +0100 Subject: [Freeipa-devel] [PATCH] 112 Added mac address to host page In-Reply-To: <4F675519.4060905@redhat.com> References: <4F673D10.6010205@redhat.com> <4F675519.4060905@redhat.com> Message-ID: <4F68B3AA.9080904@redhat.com> On 03/19/2012 04:47 PM, Endi Sukma Dewata wrote: > On 3/19/2012 9:05 AM, Petr Vobornik wrote: >> Part of support for ether maps. >> >> https://fedorahosted.org/freeipa/ticket/2548 > > ACK. > Pushed to master, ipa-2-2. -- Petr Vobornik From jcholast at redhat.com Tue Mar 20 16:48:45 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 20 Mar 2012 17:48:45 +0100 Subject: [Freeipa-devel] [PATCH] 71 Propagate SIGINT to child process in ipautil.run Message-ID: <4F68B4ED.4040001@redhat.com> Propagate SIGINT to child process in ipautil.run. Wait for the child process to terminate before continuing. Do cleanup on KeyboardInterrupt rather than in custom SIGINT handler in ipa-replica-conncheck. https://fedorahosted.org/freeipa/ticket/2127 Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-71-propagate-sigint.patch Type: text/x-patch Size: 3544 bytes Desc: not available URL: From pviktori at redhat.com Tue Mar 20 17:02:06 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 20 Mar 2012 18:02:06 +0100 Subject: [Freeipa-devel] [PATCH] 0015 Only split CSV strings once In-Reply-To: <4F632A28.9060608@redhat.com> References: <4F464D59.2020601@redhat.com> <4F62491A.7080105@redhat.com> <4F632A28.9060608@redhat.com> Message-ID: <4F68B80E.9040404@redhat.com> On 03/16/2012 12:55 PM, Petr Viktorin wrote: > On 03/15/2012 08:55 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> https://fedorahosted.org/freeipa/ticket/2227 (Unable to add certain sudo >>> commands to groups). What an interesting bug to get :) >>> >>> >>> One problem with our CSV splitting is that it's not idempotent >>> (baskslashes are "eaten" when there are escaped commas), but when we >>> forward a call it gets done on both the client and the server. The >>> attached patch fixes that in a somewhat hacky way. It's not a complete >>> fix for the issue though, for that I need to ask what to do. >>> >>> >>> Some Params use the CSV format when we just need a list of >>> comma-separated values. Our flavor of CSV does escaping in two different >>> ways. This is pretty bad for predictability, least-surprise, >>> documentation, ... >>> >>> To recap, the two ways are escaping (escaped commas are ignored, >>> backslashes also need to be escaped) and quoting (values are optionally >>> enclosed in double quotes, to include a '"' in a quoted string, use >>> '""'). >>> Escaping is good because users are used to it, but currently literal >>> backslashes need to be doubled, making multivalue syntax different from >>> single-value syntax, even if there are no commas in the value. >>> Quoting is weird, but complete by itself so it doesn't also need >>> escaping. >>> >>> Do we need to use both? Is this documented somewhere? Some of our tests >>> check only for one, some assume the other. Users are probably even more >>> confused. >>> >>> >>> If we only keep one of those, the fix for #2227 should be quite easy. >>> If not (backwards compatibility), we need to document this properly, >>> test all the corner cases, and fix the UI to handle CSV escaping. >>> Since it's subtly broken in lots of places, maybe it's best to break >>> backwards compatibility and go for a simple solution now. >>> >>> Anyway, if I want to do a proper fix, CSV handling should be only done >>> on the client. Unfortunately turning off CSV handling in the server will >>> break the UI, which at places uses `join(',')` (no escaping commas, no >>> single place to change it), even though it can just send a list. >> >> I'm with Honza, not too keen on the _forwarded_call part. I'd rather you >> do a mix of comparing self.env.in_server and whether the value is a >> basestring to determine if we need to split it. > > This was a hack necessary because the WebUI relied on server-side > splitting (in a few cases, and it did not escape correctly). Now that > Petr Vobornik's patch 99 is in, it is unnecessary. > This discussion thread has an updated patch (0015-03); what I'm > attaching now builds on top of that to add several new changes in tests. > To summarize it: the splitting is only done in the client; from the RPC > call on no CSV magic is involved at all. > > Please tell me your reasons for basestring checking. I think it's > entirely unnecessary and just adds complexity. > In the rest of the framework a string, as a parameter value, has the > same effect as a list of that one string. Why break this? > We are concerned about the API here, not the command line. Shortcuts to > save the user's keystrokes in the common case should *not* win over > predictability and making sure the easier way is the correct, robust way > to do it. Compare -- with basestring checking: > > some_command(arg=escape_commas(some_string)) > - is correct > > some_command(arg=[some_string]) > - is also correct > > some_command(arg=some_string) > - is WRONG because the string is not escaped > - but is the easiest solution! > > The problem is much worse because it is subtle: it only affects values > with commas and backslashes, so *the wrong solution would work* in most > of the cases. > And I can assure you plugin writers *would* pick the wrong way if it > would usually work. Our own web UI had examples. > > Contrast to my proposed behavior: > some_command(arg=some_string) > - is correct > > some_command(arg=[some_string]) > - is also correct > > some_command(arg=escape_commas(some_string)) > - is wrong, but doesn't make much sense because at this level you don't > have to worry about CSV at all > > Basestring checking would add unnecessary complexity for both us *and* > the plugin writer. The only case it would make it easier for the plugin > writer is if the plugin took CSV values ?-- but why force a random > format, tailored for our specific frontend, into RPC clients? > > The client should translate the command line into a RPC call. There's no > reason to arbitrarily expect the server to do part of the job. > > >> I'm not sure why this is broken out of normalize. Isn't this normalizing >> the incoming values into something more sane? > > "Normalization" implies it's an idempotent operation, which CSV > splitting is not (at least its current incarnation, without the > basestring checking): > r"a,b\,c" splits to ["a", "b,c"] which splits to ["a", "b", "c"] > > Just to make things clear: freeipa-pviktori-0015-04 is the latest version of this patch. It's complemented by freeipa-pviktori-0021-03 which adds the tests for this (and other things) (but contains one more refactor). If and when that's all reviewed and pushed, I'd like to discuss freeipa-pviktori-0018 (Simplify CSV escaping syntax). I'm not saying my solution there is perfect, but the flavor of Python's CSV parsing we're using now is quite quirky. It would be nice to get the syntax right, or at least better, while we're fixing this from a totally-broken state. Later there'll be backwards compatibility problems. But, don't let that hold back this patch. -- Petr? From rcritten at redhat.com Tue Mar 20 19:42:48 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Mar 2012 15:42:48 -0400 Subject: [Freeipa-devel] [PATCH] Try to reacquire keytab file if host already joined In-Reply-To: References: <1332247461.9238.615.camel@willson.li.ssimo.org> Message-ID: <4F68DDB8.7090908@redhat.com> Lars Sj?str?m wrote: > Hi, > > Understood! Would it be ok to add an optional flag then? > like --reacquire ? > > like so: > # run only if force and reacquire is set > if options.force and options.reacquire: > # try to fetch keytab... > > Cheers, > Lars That sounds reasonable. In what case would you want to re-enroll a host without disabling it first? rob > > Den 20 mars 2012 13:44 skrev Simo Sorce: >> On Tue, 2012-03-20 at 13:00 +0100, Lars Sj?str?m wrote: >>> Hello fellow devs, >>> >>> I have a proposed patch for ticket #2106 >>> (https://fedorahosted.org/freeipa/ticket/2106) >>> >>> if return code is 13 (Host already joined) of ipa-join command the >>> host will try to reacquire the keytab file. >>> >>> Feedback appreciated! >> >> Hi Lars, at the very least this should be conditional and be allowed >> only when an override flag is passed. The reason we punt here is that >> you may be trying to join a machine with the same name of an already >> joined and working machine by mistake. >> We do not want to void that other machine credentials unless the admin >> wants to force it. >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> > > > From rcritten at redhat.com Tue Mar 20 21:08:17 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Mar 2012 17:08:17 -0400 Subject: [Freeipa-devel] [PATCH] 0015 Only split CSV strings once In-Reply-To: <4F68B80E.9040404@redhat.com> References: <4F464D59.2020601@redhat.com> <4F62491A.7080105@redhat.com> <4F632A28.9060608@redhat.com> <4F68B80E.9040404@redhat.com> Message-ID: <4F68F1C1.6090507@redhat.com> Petr Viktorin wrote: > On 03/16/2012 12:55 PM, Petr Viktorin wrote: >> On 03/15/2012 08:55 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> https://fedorahosted.org/freeipa/ticket/2227 (Unable to add certain >>>> sudo >>>> commands to groups). What an interesting bug to get :) >>>> >>>> >>>> One problem with our CSV splitting is that it's not idempotent >>>> (baskslashes are "eaten" when there are escaped commas), but when we >>>> forward a call it gets done on both the client and the server. The >>>> attached patch fixes that in a somewhat hacky way. It's not a complete >>>> fix for the issue though, for that I need to ask what to do. >>>> >>>> >>>> Some Params use the CSV format when we just need a list of >>>> comma-separated values. Our flavor of CSV does escaping in two >>>> different >>>> ways. This is pretty bad for predictability, least-surprise, >>>> documentation, ... >>>> >>>> To recap, the two ways are escaping (escaped commas are ignored, >>>> backslashes also need to be escaped) and quoting (values are optionally >>>> enclosed in double quotes, to include a '"' in a quoted string, use >>>> '""'). >>>> Escaping is good because users are used to it, but currently literal >>>> backslashes need to be doubled, making multivalue syntax different from >>>> single-value syntax, even if there are no commas in the value. >>>> Quoting is weird, but complete by itself so it doesn't also need >>>> escaping. >>>> >>>> Do we need to use both? Is this documented somewhere? Some of our tests >>>> check only for one, some assume the other. Users are probably even more >>>> confused. >>>> >>>> >>>> If we only keep one of those, the fix for #2227 should be quite easy. >>>> If not (backwards compatibility), we need to document this properly, >>>> test all the corner cases, and fix the UI to handle CSV escaping. >>>> Since it's subtly broken in lots of places, maybe it's best to break >>>> backwards compatibility and go for a simple solution now. >>>> >>>> Anyway, if I want to do a proper fix, CSV handling should be only done >>>> on the client. Unfortunately turning off CSV handling in the server >>>> will >>>> break the UI, which at places uses `join(',')` (no escaping commas, no >>>> single place to change it), even though it can just send a list. >>> >>> I'm with Honza, not too keen on the _forwarded_call part. I'd rather you >>> do a mix of comparing self.env.in_server and whether the value is a >>> basestring to determine if we need to split it. >> >> This was a hack necessary because the WebUI relied on server-side >> splitting (in a few cases, and it did not escape correctly). Now that >> Petr Vobornik's patch 99 is in, it is unnecessary. >> This discussion thread has an updated patch (0015-03); what I'm >> attaching now builds on top of that to add several new changes in tests. >> To summarize it: the splitting is only done in the client; from the RPC >> call on no CSV magic is involved at all. >> >> Please tell me your reasons for basestring checking. I think it's >> entirely unnecessary and just adds complexity. >> In the rest of the framework a string, as a parameter value, has the >> same effect as a list of that one string. Why break this? >> We are concerned about the API here, not the command line. Shortcuts to >> save the user's keystrokes in the common case should *not* win over >> predictability and making sure the easier way is the correct, robust way >> to do it. Compare -- with basestring checking: >> >> some_command(arg=escape_commas(some_string)) >> - is correct >> >> some_command(arg=[some_string]) >> - is also correct >> >> some_command(arg=some_string) >> - is WRONG because the string is not escaped >> - but is the easiest solution! >> >> The problem is much worse because it is subtle: it only affects values >> with commas and backslashes, so *the wrong solution would work* in most >> of the cases. >> And I can assure you plugin writers *would* pick the wrong way if it >> would usually work. Our own web UI had examples. >> >> Contrast to my proposed behavior: >> some_command(arg=some_string) >> - is correct >> >> some_command(arg=[some_string]) >> - is also correct >> >> some_command(arg=escape_commas(some_string)) >> - is wrong, but doesn't make much sense because at this level you don't >> have to worry about CSV at all >> >> Basestring checking would add unnecessary complexity for both us *and* >> the plugin writer. The only case it would make it easier for the plugin >> writer is if the plugin took CSV values ?-- but why force a random >> format, tailored for our specific frontend, into RPC clients? >> >> The client should translate the command line into a RPC call. There's no >> reason to arbitrarily expect the server to do part of the job. >> >> >>> I'm not sure why this is broken out of normalize. Isn't this normalizing >>> the incoming values into something more sane? >> >> "Normalization" implies it's an idempotent operation, which CSV >> splitting is not (at least its current incarnation, without the >> basestring checking): >> r"a,b\,c" splits to ["a", "b,c"] which splits to ["a", "b", "c"] >> >> > > Just to make things clear: freeipa-pviktori-0015-04 is the latest > version of this patch. > It's complemented by freeipa-pviktori-0021-03 which adds the tests for > this (and other things) (but contains one more refactor). > > > If and when that's all reviewed and pushed, I'd like to discuss > freeipa-pviktori-0018 (Simplify CSV escaping syntax). I'm not saying my > solution there is perfect, but the flavor of Python's CSV parsing we're > using now is quite quirky. It would be nice to get the syntax right, or > at least better, while we're fixing this from a totally-broken state. > Later there'll be backwards compatibility problems. > But, don't let that hold back this patch. > I'm still not completely convinced. This patch looks ok and I'm sold on client side only parsing but this doesn't actually fix any of the CSV bugs we have open. I'd like to evaluate this in more context. I think the simplest fix is to drop escapechar processing in the csvreader and have users quote strings with commas instead, this is how I originally intended it to work. The UI won't have to do anything special since it will already be split and it isn't a lot to ask to put quotes around a value on the CLI. This is my proposed fix on top of your patch: diff --git a/ipalib/parameters.py b/ipalib/parameters.py index 80b175d..ec6020e 100644 --- a/ipalib/parameters.py +++ b/ipalib/parameters.py @@ -702,7 +702,7 @@ class Param(ReadOnly): # csv.py doesn't do Unicode; encode temporarily as UTF-8: csv_reader = csv.reader(self.__utf_8_encoder(unicode_csv_data), dialect=dialect, - delimiter=self.csv_separator, escapechar='\\', + delimiter=self.csv_separator, quotechar='"', skipinitialspace=self.csv_skipspace, **kwargs) for row in csv_reader: With this change: - all the self-tests pass - https://fedorahosted.org/freeipa/ticket/2417 is fixed - https://fedorahosted.org/freeipa/ticket/2227 is fixed I tested with: $ ipa sudocmdgroup-add-member test --sudocmd='/bin/chown -R apache\:developers /var/www/*/shared/log' $ ipa role-add-privilege --privileges='"u,r stuff"' test rob From rcritten at redhat.com Tue Mar 20 21:34:59 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Mar 2012 17:34:59 -0400 Subject: [Freeipa-devel] [PATCH] 985 no longer shell escape for pkisilent Message-ID: <4F68F803.4040500@redhat.com> pkisilent now shell escapes its arguments so we no longer need to do so, and in fact, if we do it ends up with double-escaping breaking all installs of IPA with a dogtag CA. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-985-2-shellescape.patch Type: text/x-diff Size: 2262 bytes Desc: not available URL: From lars at radicore.se Tue Mar 20 22:16:02 2012 From: lars at radicore.se (=?ISO-8859-1?Q?Lars_Sj=F6str=F6m?=) Date: Tue, 20 Mar 2012 23:16:02 +0100 Subject: [Freeipa-devel] [PATCH] Try to reacquire keytab file if host already joined In-Reply-To: <4F68DDB8.7090908@redhat.com> References: <1332247461.9238.615.camel@willson.li.ssimo.org> <4F68DDB8.7090908@redhat.com> Message-ID: > Lars Sj?str?m wrote: >> >> Hi, >> >> Understood! Would it be ok to add an optional flag then? >> like --reacquire ? >> >> like so: >> # run only if force and reacquire is set >> if options.force and options.reacquire: >> ? # try to fetch keytab... >> >> Cheers, >> Lars > > > That sounds reasonable. In what case would you want to re-enroll a host > without disabling it first? One use case is where you for instance reinstall your OS a lot (in a automated fashion), the client will not have any traces left of the IPA client config which means the client can't unenroll it self easily. If you know you're reinstalling a lot one would put ipa-client-install with the re-acquire flag set to let the client try to repair it self. One could always skip the the ipa-client-install command and script around the ipa* commands, but I would prefer to have it supported by ipa-client-install. Would that make any sense? :) Cheers, Lars > > rob > > >> >> Den 20 mars 2012 13:44 skrev Simo Sorce: >>> >>> On Tue, 2012-03-20 at 13:00 +0100, Lars Sj?str?m wrote: >>>> >>>> Hello fellow devs, >>>> >>>> I have a proposed patch for ticket #2106 >>>> (https://fedorahosted.org/freeipa/ticket/2106) >>>> >>>> if return code is 13 (Host already joined) of ipa-join command the >>>> host will try to reacquire the keytab file. >>>> >>>> Feedback appreciated! >>> >>> >>> Hi Lars, at the very least this should be conditional and be allowed >>> only when an override flag is passed. The reason we punt here is that >>> you may be trying to join a machine with the same name of an already >>> joined and working machine by mistake. >>> We do not want to void that other machine credentials unless the admin >>> wants to force it. >>> >>> Simo. >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >> >> >> > -- Lars Sj?str?m Senior Consultant / Owner Radicore AB Mobile:?+46 (0)703 021502 Email:?lars at radicore.se Web:?http://www.radicore.se From rcritten at redhat.com Wed Mar 21 02:58:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Mar 2012 22:58:26 -0400 Subject: [Freeipa-devel] [PATCH] 991/992 fix migration issues Message-ID: <4F6943D2.2060005@redhat.com> Fix a couple of issues found with migration. I made a second patch just to keep things separate even though its just a one-liner. 991 fixes a problem where we have attributes which point to other entries and these weren't being migrated. This is things like secretary and manager. This was actually causing things to blow up badly. 992 makes the primary key lower-case to match the rest of IPA. I've attached an LDIF with a couple of users to demonstrate the fix. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-991-migration.patch Type: text/x-diff Size: 3821 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-992-migration.patch Type: text/x-diff Size: 1038 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: migrate.ldif URL: From mkosek at redhat.com Wed Mar 21 08:57:22 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Mar 2012 09:57:22 +0100 Subject: [Freeipa-devel] [PATCH] 240 Fix LDAP effective rights control with python-ldap 2.4.x Message-ID: <1332320242.4333.1.camel@balmora.brq.redhat.com> Test instructions are attached to the ticket. --- The new version of python-ldap changed the way it created LDAPv3 extended controls. The API used in 2.4.x can no longer be used because it does not send the bind DN with effective rights control and LDAP server thus rejects it. This patch implements the new API in a backward compatible way so that it works both with python-ldap versions 2.3.x and 2.4.x. https://fedorahosted.org/freeipa/ticket/2565 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-240-fix-ldap-ger.patch Type: text/x-patch Size: 2486 bytes Desc: not available URL: From jcholast at redhat.com Wed Mar 21 09:01:46 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 21 Mar 2012 10:01:46 +0100 Subject: [Freeipa-devel] [PATCH] 985 no longer shell escape for pkisilent In-Reply-To: <4F68F803.4040500@redhat.com> References: <4F68F803.4040500@redhat.com> Message-ID: <4F6998FA.207@redhat.com> On 20.3.2012 22:34, Rob Crittenden wrote: > pkisilent now shell escapes its arguments so we no longer need to do so, > and in fact, if we do it ends up with double-escaping breaking all > installs of IPA with a dogtag CA. > > rob > ACK. Honza -- Jan Cholasta From mkosek at redhat.com Wed Mar 21 09:11:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Mar 2012 10:11:11 +0100 Subject: [Freeipa-devel] [PATCH] 985 no longer shell escape for pkisilent In-Reply-To: <4F6998FA.207@redhat.com> References: <4F68F803.4040500@redhat.com> <4F6998FA.207@redhat.com> Message-ID: <1332321071.4333.2.camel@balmora.brq.redhat.com> On Wed, 2012-03-21 at 10:01 +0100, Jan Cholasta wrote: > On 20.3.2012 22:34, Rob Crittenden wrote: > > pkisilent now shell escapes its arguments so we no longer need to do so, > > and in fact, if we do it ends up with double-escaping breaking all > > installs of IPA with a dogtag CA. > > > > rob > > > > ACK. > > Honza > Pushed to master, ipa-2-2. Martin From jcholast at redhat.com Wed Mar 21 09:16:53 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 21 Mar 2012 10:16:53 +0100 Subject: [Freeipa-devel] [PATCH] 240 Fix LDAP effective rights control with python-ldap 2.4.x In-Reply-To: <1332320242.4333.1.camel@balmora.brq.redhat.com> References: <1332320242.4333.1.camel@balmora.brq.redhat.com> Message-ID: <4F699C85.80505@redhat.com> On 21.3.2012 09:57, Martin Kosek wrote: > Test instructions are attached to the ticket. > --- > The new version of python-ldap changed the way it created LDAPv3 > extended controls. The API used in 2.4.x can no longer be used > because it does not send the bind DN with effective rights > control and LDAP server thus rejects it. > > This patch implements the new API in a backward compatible way > so that it works both with python-ldap versions 2.3.x and 2.4.x. > > https://fedorahosted.org/freeipa/ticket/2565 > IMO it would be nicer to handle things on module import rather than on each get effective rights request: @@ -42,7 +42,6 @@ import ldap as _ldap from ldap.ldapobject import SimpleLDAPObject import ldap.filter as _ldap_filter import ldap.sasl as _ldap_sasl -from ldap.controls import LDAPControl # for backward compatibility from ldap.functions import explode_dn from ipalib.dn import DN @@ -56,6 +55,14 @@ from ipalib.crud import CrudBackend from ipalib.encoder import Encoder, encode_args, decode_retval from ipalib.request import context +try: + from ldap.controls.simple import GetEffectiveRightsControl +except ImportError: + from ldap.controls import LDAPControl + class GetEffectiveRightsControl(LDAPControl): + def __init__(critical, value): + super(GetEffectiveRightsControl, self).__init__('1.3.6.1.4.1.42.2.27.9.5.2', critical, value) + # Group Member types MEMBERS_ALL = 0 MEMBERS_DIRECT = 1 @@ -871,7 +878,7 @@ class ldap2(CrudBackend, Encoder): """ principal = getattr(context, 'principal') (binddn, attrs) = self.find_entry_by_attr("krbprincipalname", principal, "krbPrincipalAux") - sctrl = [LDAPControl("1.3.6.1.4.1.42.2.27.9.5.2", True, "dn: " + binddn.encode('UTF-8'))] + sctrl = [GetEffectiveRightsControl(True, "dn: " + binddn.encode('UTF-8'))] self.conn.set_option(_ldap.OPT_SERVER_CONTROLS, sctrl) (dn, attrs) = self.get_entry(dn, entry_attrs) # remove the control so subsequent operations don't include GER Honza -- Jan Cholasta From mkosek at redhat.com Wed Mar 21 09:49:07 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Mar 2012 10:49:07 +0100 Subject: [Freeipa-devel] [PATCH] 240 Fix LDAP effective rights control with python-ldap 2.4.x In-Reply-To: <4F699C85.80505@redhat.com> References: <1332320242.4333.1.camel@balmora.brq.redhat.com> <4F699C85.80505@redhat.com> Message-ID: <1332323347.4333.5.camel@balmora.brq.redhat.com> On Wed, 2012-03-21 at 10:16 +0100, Jan Cholasta wrote: > On 21.3.2012 09:57, Martin Kosek wrote: > > Test instructions are attached to the ticket. > > --- > > The new version of python-ldap changed the way it created LDAPv3 > > extended controls. The API used in 2.4.x can no longer be used > > because it does not send the bind DN with effective rights > > control and LDAP server thus rejects it. > > > > This patch implements the new API in a backward compatible way > > so that it works both with python-ldap versions 2.3.x and 2.4.x. > > > > https://fedorahosted.org/freeipa/ticket/2565 > > > > IMO it would be nicer to handle things on module import rather than on > each get effective rights request: > > @@ -42,7 +42,6 @@ import ldap as _ldap > from ldap.ldapobject import SimpleLDAPObject > import ldap.filter as _ldap_filter > import ldap.sasl as _ldap_sasl > -from ldap.controls import LDAPControl > # for backward compatibility > from ldap.functions import explode_dn > from ipalib.dn import DN > @@ -56,6 +55,14 @@ from ipalib.crud import CrudBackend > from ipalib.encoder import Encoder, encode_args, decode_retval > from ipalib.request import context > > +try: > + from ldap.controls.simple import GetEffectiveRightsControl > +except ImportError: > + from ldap.controls import LDAPControl > + class GetEffectiveRightsControl(LDAPControl): > + def __init__(critical, value): > + super(GetEffectiveRightsControl, > self).__init__('1.3.6.1.4.1.42.2.27.9.5.2', critical, value) > + > # Group Member types > MEMBERS_ALL = 0 > MEMBERS_DIRECT = 1 > @@ -871,7 +878,7 @@ class ldap2(CrudBackend, Encoder): > """ > principal = getattr(context, 'principal') > (binddn, attrs) = self.find_entry_by_attr("krbprincipalname", > principal, "krbPrincipalAux") > - sctrl = [LDAPControl("1.3.6.1.4.1.42.2.27.9.5.2", True, "dn: " > + binddn.encode('UTF-8'))] > + sctrl = [GetEffectiveRightsControl(True, "dn: " + > binddn.encode('UTF-8'))] > self.conn.set_option(_ldap.OPT_SERVER_CONTROLS, sctrl) > (dn, attrs) = self.get_entry(dn, entry_attrs) > # remove the control so subsequent operations don't include GER > > Honza > I agree, this approach is better. I updated the patch based on your input. It just needed some more love as LDAPControl is an old-style Python class and I also silenced pylint when python-ldap 2.3.x is installed. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-240-2-fix-ldap-ger.patch Type: text/x-patch Size: 2545 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 21 12:51:47 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Mar 2012 13:51:47 +0100 Subject: [Freeipa-devel] [PATCH] 241 Fix precallback validators in DNS plugin Message-ID: <1332334307.4333.6.camel@balmora.brq.redhat.com> DNS plugin contains several RR type record validators run in pre_callback which cannot be used as standard param validator as it needs more data and resources that standard validators provide. However, the precallback validators are not run for DNS records created by new structured options and thus an invalid value may slip in. This patch moves the execution of these precallback validators _after_ the processing of structured DNS options. It also cleans them up a little and makes them more robust. https://fedorahosted.org/freeipa/ticket/2550 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-241-fix-precallback-validators-in-dns-plugin.patch Type: text/x-patch Size: 7596 bytes Desc: not available URL: From pviktori at redhat.com Wed Mar 21 14:28:21 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 21 Mar 2012 15:28:21 +0100 Subject: [Freeipa-devel] [PATCH] 0015 Only split CSV strings once In-Reply-To: <4F68F1C1.6090507@redhat.com> References: <4F464D59.2020601@redhat.com> <4F62491A.7080105@redhat.com> <4F632A28.9060608@redhat.com> <4F68B80E.9040404@redhat.com> <4F68F1C1.6090507@redhat.com> Message-ID: <4F69E585.1070108@redhat.com> On 03/20/2012 10:08 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/16/2012 12:55 PM, Petr Viktorin wrote: >>> On 03/15/2012 08:55 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> https://fedorahosted.org/freeipa/ticket/2227 (Unable to add certain >>>>> sudo >>>>> commands to groups). What an interesting bug to get :) >>>>> >>>>> >>>>> One problem with our CSV splitting is that it's not idempotent >>>>> (baskslashes are "eaten" when there are escaped commas), but when we >>>>> forward a call it gets done on both the client and the server. The >>>>> attached patch fixes that in a somewhat hacky way. It's not a complete >>>>> fix for the issue though, for that I need to ask what to do. >>>>> >>>>> >>>>> Some Params use the CSV format when we just need a list of >>>>> comma-separated values. Our flavor of CSV does escaping in two >>>>> different >>>>> ways. This is pretty bad for predictability, least-surprise, >>>>> documentation, ... >>>>> >>>>> To recap, the two ways are escaping (escaped commas are ignored, >>>>> backslashes also need to be escaped) and quoting (values are >>>>> optionally >>>>> enclosed in double quotes, to include a '"' in a quoted string, use >>>>> '""'). >>>>> Escaping is good because users are used to it, but currently literal >>>>> backslashes need to be doubled, making multivalue syntax different >>>>> from >>>>> single-value syntax, even if there are no commas in the value. >>>>> Quoting is weird, but complete by itself so it doesn't also need >>>>> escaping. >>>>> >>>>> Do we need to use both? Is this documented somewhere? Some of our >>>>> tests >>>>> check only for one, some assume the other. Users are probably even >>>>> more >>>>> confused. >>>>> >>>>> >>>>> If we only keep one of those, the fix for #2227 should be quite easy. >>>>> If not (backwards compatibility), we need to document this properly, >>>>> test all the corner cases, and fix the UI to handle CSV escaping. >>>>> Since it's subtly broken in lots of places, maybe it's best to break >>>>> backwards compatibility and go for a simple solution now. >>>>> >>>>> Anyway, if I want to do a proper fix, CSV handling should be only done >>>>> on the client. Unfortunately turning off CSV handling in the server >>>>> will >>>>> break the UI, which at places uses `join(',')` (no escaping commas, no >>>>> single place to change it), even though it can just send a list. >>>> >>>> I'm with Honza, not too keen on the _forwarded_call part. I'd rather >>>> you >>>> do a mix of comparing self.env.in_server and whether the value is a >>>> basestring to determine if we need to split it. >>> >>> This was a hack necessary because the WebUI relied on server-side >>> splitting (in a few cases, and it did not escape correctly). Now that >>> Petr Vobornik's patch 99 is in, it is unnecessary. >>> This discussion thread has an updated patch (0015-03); what I'm >>> attaching now builds on top of that to add several new changes in tests. >>> To summarize it: the splitting is only done in the client; from the RPC >>> call on no CSV magic is involved at all. >>> >>> Please tell me your reasons for basestring checking. I think it's >>> entirely unnecessary and just adds complexity. >>> In the rest of the framework a string, as a parameter value, has the >>> same effect as a list of that one string. Why break this? >>> We are concerned about the API here, not the command line. Shortcuts to >>> save the user's keystrokes in the common case should *not* win over >>> predictability and making sure the easier way is the correct, robust way >>> to do it. Compare -- with basestring checking: >>> >>> some_command(arg=escape_commas(some_string)) >>> - is correct >>> >>> some_command(arg=[some_string]) >>> - is also correct >>> >>> some_command(arg=some_string) >>> - is WRONG because the string is not escaped >>> - but is the easiest solution! >>> >>> The problem is much worse because it is subtle: it only affects values >>> with commas and backslashes, so *the wrong solution would work* in most >>> of the cases. >>> And I can assure you plugin writers *would* pick the wrong way if it >>> would usually work. Our own web UI had examples. >>> >>> Contrast to my proposed behavior: >>> some_command(arg=some_string) >>> - is correct >>> >>> some_command(arg=[some_string]) >>> - is also correct >>> >>> some_command(arg=escape_commas(some_string)) >>> - is wrong, but doesn't make much sense because at this level you don't >>> have to worry about CSV at all >>> >>> Basestring checking would add unnecessary complexity for both us *and* >>> the plugin writer. The only case it would make it easier for the plugin >>> writer is if the plugin took CSV values ?-- but why force a random >>> format, tailored for our specific frontend, into RPC clients? >>> >>> The client should translate the command line into a RPC call. There's no >>> reason to arbitrarily expect the server to do part of the job. >>> >>> >>>> I'm not sure why this is broken out of normalize. Isn't this >>>> normalizing >>>> the incoming values into something more sane? >>> >>> "Normalization" implies it's an idempotent operation, which CSV >>> splitting is not (at least its current incarnation, without the >>> basestring checking): >>> r"a,b\,c" splits to ["a", "b,c"] which splits to ["a", "b", "c"] >>> >>> >> >> Just to make things clear: freeipa-pviktori-0015-04 is the latest >> version of this patch. >> It's complemented by freeipa-pviktori-0021-03 which adds the tests for >> this (and other things) (but contains one more refactor). >> >> >> If and when that's all reviewed and pushed, I'd like to discuss >> freeipa-pviktori-0018 (Simplify CSV escaping syntax). I'm not saying my >> solution there is perfect, but the flavor of Python's CSV parsing we're >> using now is quite quirky. It would be nice to get the syntax right, or >> at least better, while we're fixing this from a totally-broken state. >> Later there'll be backwards compatibility problems. >> But, don't let that hold back this patch. >> > > I'm still not completely convinced. This patch looks ok and I'm sold on > client side only parsing but this doesn't actually fix any of the CSV > bugs we have open. > > I'd like to evaluate this in more context. > > I think the simplest fix is to drop escapechar processing in the > csvreader and have users quote strings with commas instead, this is how > I originally intended it to work. The UI won't have to do anything > special since it will already be split and it isn't a lot to ask to put > quotes around a value on the CLI. > > This is my proposed fix on top of your patch: > > diff --git a/ipalib/parameters.py b/ipalib/parameters.py > index 80b175d..ec6020e 100644 > --- a/ipalib/parameters.py > +++ b/ipalib/parameters.py > @@ -702,7 +702,7 @@ class Param(ReadOnly): > # csv.py doesn't do Unicode; encode temporarily as UTF-8: > csv_reader = csv.reader(self.__utf_8_encoder(unicode_csv_data), > dialect=dialect, > - delimiter=self.csv_separator, escapechar='\\', > + delimiter=self.csv_separator, quotechar='"', > skipinitialspace=self.csv_skipspace, > **kwargs) > for row in csv_reader: > > With this change: > - all the self-tests pass > - https://fedorahosted.org/freeipa/ticket/2417 is fixed > - https://fedorahosted.org/freeipa/ticket/2227 is fixed > > I tested with: > > $ ipa sudocmdgroup-add-member test --sudocmd='/bin/chown -R > apache\:developers /var/www/*/shared/log' > > $ ipa role-add-privilege --privileges='"u,r stuff"' test > > rob Yes, that works well. ACK on your change; here it is squashed in. https://fedorahosted.org/freeipa/ticket/2402 can wait for 3.0, then? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0015-05-Only-split-CSV-in-the-client.patch Type: text/x-patch Size: 14514 bytes Desc: not available URL: From ohamada at redhat.com Wed Mar 21 14:38:16 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Wed, 21 Mar 2012 15:38:16 +0100 Subject: [Freeipa-devel] [PATCH] 19 Search allowed attributes in superior objectclasses Message-ID: <4F69E7D8.8040004@redhat.com> https://fedorahosted.org/freeipa/ticket/2293 This patch fixes regression caused by patch for ticket #2293. The function get_allowed_attributes was searching only through the specified objectclasses but not through their superior objectclasses. This patch adds such behaviour by recursive call of get_allowed_attributes on the superior objectclasses. Test case that revealed the regression was added into the unit-tests. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-19-Search-allowed-attributes-in-superior-objectclasses.patch Type: text/x-patch Size: 3334 bytes Desc: not available URL: From pviktori at redhat.com Wed Mar 21 14:46:02 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 21 Mar 2012 15:46:02 +0100 Subject: [Freeipa-devel] [PATCH] 0021 Add CLI tests In-Reply-To: <4F632BDD.1000608@redhat.com> References: <4F575A01.1060501@redhat.com> <4F5E5A22.1010109@redhat.com> <4F5F2E39.2020301@redhat.com> <4F632BDD.1000608@redhat.com> Message-ID: <4F69E9AA.4040509@redhat.com> On 03/16/2012 01:02 PM, Petr Viktorin wrote: > On 03/13/2012 12:23 PM, Petr Viktorin wrote: >> On 03/12/2012 09:18 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> Most of the tests we have check if the server does the right thing with >>>> XML-RPC calls. How the commandline is converted to command arguments, >>>> including interactive prompting, is untested. >>>> This patch adds some tests in this area. To do that I had to break up >>>> cli.run into more manageable pieces, and initialize the CLI plugins in >>>> test mode. >>>> >>>> Also I added nose's --nocapture option to the make-test script. With >>>> this it's possible to use pdb.set_trace() to drop into a debugger while >>>> running the tests. >>>> >>>> >>>> I went ahead and added a test for ticket 2484, fixed in Martin's patch >>>> 231 (Ignore case in yes/no prompts). >>>> >>> >>> John had done similar work with --nocapture a while back but it is still >>> pending. Perhaps we can merge his changes in with yours, they look >>> largely overlapping. His patch is [PATCH 54/54] ticet 2135 - enhance >>> make-test for debugging >>> >>> rob >> >> I guess it'll be better to make that a separate patch, then. This >> updated patch doesn't contain the make-test change. >> > > Updating the patch to also test the CSV splitting in my patch 0015.04 > > > > Update for quoting only, no backslashes, in CSV -- following Rob's suggestion on the CSV patch. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0021-04-Add-CLI-parsing-tests.patch Type: text/x-patch Size: 9303 bytes Desc: not available URL: From dpal at redhat.com Wed Mar 21 15:08:25 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 21 Mar 2012 11:08:25 -0400 Subject: [Freeipa-devel] [PATCH] Try to reacquire keytab file if host already joined In-Reply-To: References: <1332247461.9238.615.camel@willson.li.ssimo.org> <4F68DDB8.7090908@redhat.com> Message-ID: <4F69EEE9.90007@redhat.com> On 03/20/2012 06:16 PM, Lars Sj?str?m wrote: >> Lars Sj?str?m wrote: >>> Hi, >>> >>> Understood! Would it be ok to add an optional flag then? >>> like --reacquire ? >>> >>> like so: >>> # run only if force and reacquire is set >>> if options.force and options.reacquire: >>> # try to fetch keytab... >>> >>> Cheers, >>> Lars >> >> That sounds reasonable. In what case would you want to re-enroll a host >> without disabling it first? > One use case is where you for instance reinstall your OS a lot (in a > automated fashion), the client will not have any traces left of the > IPA client config which means the client can't unenroll it self > easily. If you know you're reinstalling a lot one would put > ipa-client-install with the re-acquire flag set to let the client try > to repair it self. > > One could always skip the the ipa-client-install command and script > around the ipa* commands, but I would prefer to have it supported by > ipa-client-install. > > Would that make any sense? :) Let us define the problem namespace first and see what the scenarios are. We do not need to implement all the scenarios but knowing them would be helpful to define what the right combination of flags should be exposed. 1) Client is not enrolled, no host entry or host entry exists and admin has rights to provision or it is a bulk enrollment using OTP 2) Client is completely re-installed, nothing on server changed yet 3) Client was enrolled, so has a key but it is corrupt or for other reason is invalid or completely missing but server has the old key 4) Client is enrolled by host entry was removed 5) Client is enrolled by host entry was recreated The cases 1 & 2 are new installs. The 1 should just go through (assuming permissions are correct). 2 will fail and you need to provide --force flag to force the client Cases 3-5 are more a repair use cases. 3 & 5 would fail without the --force but should succeed with the --force Use case 4 would go through as is with just a repair flag My point is that the relation between the flags is different depending upon what is going on the server. So it seems (I do not know the code but) that logic should be if no repair if no force enroll as new else force overwrite do full client config else if no force enroll as new else force overwrite do client config sanity check (instead of fill reconfig) Something like... > Cheers, > Lars > >> rob >> >> >>> Den 20 mars 2012 13:44 skrev Simo Sorce: >>>> On Tue, 2012-03-20 at 13:00 +0100, Lars Sj?str?m wrote: >>>>> Hello fellow devs, >>>>> >>>>> I have a proposed patch for ticket #2106 >>>>> (https://fedorahosted.org/freeipa/ticket/2106) >>>>> >>>>> if return code is 13 (Host already joined) of ipa-join command the >>>>> host will try to reacquire the keytab file. >>>>> >>>>> Feedback appreciated! >>>> >>>> Hi Lars, at the very least this should be conditional and be allowed >>>> only when an override flag is passed. The reason we punt here is that >>>> you may be trying to join a machine with the same name of an already >>>> joined and working machine by mistake. >>>> We do not want to void that other machine credentials unless the admin >>>> wants to force it. >>>> >>>> Simo. >>>> >>>> -- >>>> Simo Sorce * Red Hat, Inc * New York >>>> >>> >>> > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Mar 21 15:12:03 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 21 Mar 2012 11:12:03 -0400 Subject: [Freeipa-devel] [PATCH] 0015 Only split CSV strings once In-Reply-To: <4F69E585.1070108@redhat.com> References: <4F464D59.2020601@redhat.com> <4F62491A.7080105@redhat.com> <4F632A28.9060608@redhat.com> <4F68B80E.9040404@redhat.com> <4F68F1C1.6090507@redhat.com> <4F69E585.1070108@redhat.com> Message-ID: <4F69EFC3.6000202@redhat.com> On 03/21/2012 10:28 AM, Petr Viktorin wrote: > On 03/20/2012 10:08 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/16/2012 12:55 PM, Petr Viktorin wrote: >>>> On 03/15/2012 08:55 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/2227 (Unable to add certain >>>>>> sudo >>>>>> commands to groups). What an interesting bug to get :) >>>>>> >>>>>> >>>>>> One problem with our CSV splitting is that it's not idempotent >>>>>> (baskslashes are "eaten" when there are escaped commas), but when we >>>>>> forward a call it gets done on both the client and the server. The >>>>>> attached patch fixes that in a somewhat hacky way. It's not a >>>>>> complete >>>>>> fix for the issue though, for that I need to ask what to do. >>>>>> >>>>>> >>>>>> Some Params use the CSV format when we just need a list of >>>>>> comma-separated values. Our flavor of CSV does escaping in two >>>>>> different >>>>>> ways. This is pretty bad for predictability, least-surprise, >>>>>> documentation, ... >>>>>> >>>>>> To recap, the two ways are escaping (escaped commas are ignored, >>>>>> backslashes also need to be escaped) and quoting (values are >>>>>> optionally >>>>>> enclosed in double quotes, to include a '"' in a quoted string, use >>>>>> '""'). >>>>>> Escaping is good because users are used to it, but currently literal >>>>>> backslashes need to be doubled, making multivalue syntax different >>>>>> from >>>>>> single-value syntax, even if there are no commas in the value. >>>>>> Quoting is weird, but complete by itself so it doesn't also need >>>>>> escaping. >>>>>> >>>>>> Do we need to use both? Is this documented somewhere? Some of our >>>>>> tests >>>>>> check only for one, some assume the other. Users are probably even >>>>>> more >>>>>> confused. >>>>>> >>>>>> >>>>>> If we only keep one of those, the fix for #2227 should be quite >>>>>> easy. >>>>>> If not (backwards compatibility), we need to document this properly, >>>>>> test all the corner cases, and fix the UI to handle CSV escaping. >>>>>> Since it's subtly broken in lots of places, maybe it's best to break >>>>>> backwards compatibility and go for a simple solution now. >>>>>> >>>>>> Anyway, if I want to do a proper fix, CSV handling should be only >>>>>> done >>>>>> on the client. Unfortunately turning off CSV handling in the server >>>>>> will >>>>>> break the UI, which at places uses `join(',')` (no escaping >>>>>> commas, no >>>>>> single place to change it), even though it can just send a list. >>>>> >>>>> I'm with Honza, not too keen on the _forwarded_call part. I'd rather >>>>> you >>>>> do a mix of comparing self.env.in_server and whether the value is a >>>>> basestring to determine if we need to split it. >>>> >>>> This was a hack necessary because the WebUI relied on server-side >>>> splitting (in a few cases, and it did not escape correctly). Now that >>>> Petr Vobornik's patch 99 is in, it is unnecessary. >>>> This discussion thread has an updated patch (0015-03); what I'm >>>> attaching now builds on top of that to add several new changes in >>>> tests. >>>> To summarize it: the splitting is only done in the client; from the >>>> RPC >>>> call on no CSV magic is involved at all. >>>> >>>> Please tell me your reasons for basestring checking. I think it's >>>> entirely unnecessary and just adds complexity. >>>> In the rest of the framework a string, as a parameter value, has the >>>> same effect as a list of that one string. Why break this? >>>> We are concerned about the API here, not the command line. >>>> Shortcuts to >>>> save the user's keystrokes in the common case should *not* win over >>>> predictability and making sure the easier way is the correct, >>>> robust way >>>> to do it. Compare -- with basestring checking: >>>> >>>> some_command(arg=escape_commas(some_string)) >>>> - is correct >>>> >>>> some_command(arg=[some_string]) >>>> - is also correct >>>> >>>> some_command(arg=some_string) >>>> - is WRONG because the string is not escaped >>>> - but is the easiest solution! >>>> >>>> The problem is much worse because it is subtle: it only affects values >>>> with commas and backslashes, so *the wrong solution would work* in >>>> most >>>> of the cases. >>>> And I can assure you plugin writers *would* pick the wrong way if it >>>> would usually work. Our own web UI had examples. >>>> >>>> Contrast to my proposed behavior: >>>> some_command(arg=some_string) >>>> - is correct >>>> >>>> some_command(arg=[some_string]) >>>> - is also correct >>>> >>>> some_command(arg=escape_commas(some_string)) >>>> - is wrong, but doesn't make much sense because at this level you >>>> don't >>>> have to worry about CSV at all >>>> >>>> Basestring checking would add unnecessary complexity for both us *and* >>>> the plugin writer. The only case it would make it easier for the >>>> plugin >>>> writer is if the plugin took CSV values ?-- but why force a random >>>> format, tailored for our specific frontend, into RPC clients? >>>> >>>> The client should translate the command line into a RPC call. >>>> There's no >>>> reason to arbitrarily expect the server to do part of the job. >>>> >>>> >>>>> I'm not sure why this is broken out of normalize. Isn't this >>>>> normalizing >>>>> the incoming values into something more sane? >>>> >>>> "Normalization" implies it's an idempotent operation, which CSV >>>> splitting is not (at least its current incarnation, without the >>>> basestring checking): >>>> r"a,b\,c" splits to ["a", "b,c"] which splits to ["a", "b", "c"] >>>> >>>> >>> >>> Just to make things clear: freeipa-pviktori-0015-04 is the latest >>> version of this patch. >>> It's complemented by freeipa-pviktori-0021-03 which adds the tests for >>> this (and other things) (but contains one more refactor). >>> >>> >>> If and when that's all reviewed and pushed, I'd like to discuss >>> freeipa-pviktori-0018 (Simplify CSV escaping syntax). I'm not saying my >>> solution there is perfect, but the flavor of Python's CSV parsing we're >>> using now is quite quirky. It would be nice to get the syntax right, or >>> at least better, while we're fixing this from a totally-broken state. >>> Later there'll be backwards compatibility problems. >>> But, don't let that hold back this patch. >>> >> >> I'm still not completely convinced. This patch looks ok and I'm sold on >> client side only parsing but this doesn't actually fix any of the CSV >> bugs we have open. >> >> I'd like to evaluate this in more context. >> >> I think the simplest fix is to drop escapechar processing in the >> csvreader and have users quote strings with commas instead, this is how >> I originally intended it to work. The UI won't have to do anything >> special since it will already be split and it isn't a lot to ask to put >> quotes around a value on the CLI. >> >> This is my proposed fix on top of your patch: >> >> diff --git a/ipalib/parameters.py b/ipalib/parameters.py >> index 80b175d..ec6020e 100644 >> --- a/ipalib/parameters.py >> +++ b/ipalib/parameters.py >> @@ -702,7 +702,7 @@ class Param(ReadOnly): >> # csv.py doesn't do Unicode; encode temporarily as UTF-8: >> csv_reader = csv.reader(self.__utf_8_encoder(unicode_csv_data), >> dialect=dialect, >> - delimiter=self.csv_separator, escapechar='\\', >> + delimiter=self.csv_separator, quotechar='"', >> skipinitialspace=self.csv_skipspace, >> **kwargs) >> for row in csv_reader: >> >> With this change: >> - all the self-tests pass >> - https://fedorahosted.org/freeipa/ticket/2417 is fixed >> - https://fedorahosted.org/freeipa/ticket/2227 is fixed >> >> I tested with: >> >> $ ipa sudocmdgroup-add-member test --sudocmd='/bin/chown -R >> apache\:developers /var/www/*/shared/log' >> >> $ ipa role-add-privilege --privileges='"u,r stuff"' test >> >> rob > > Yes, that works well. ACK on your change; here it is squashed in. > > https://fedorahosted.org/freeipa/ticket/2402 can wait for 3.0, then? Is it risky to take it in? > > > _______________________________________________ > 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 pviktori at redhat.com Wed Mar 21 15:21:07 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 21 Mar 2012 16:21:07 +0100 Subject: [Freeipa-devel] [PATCH] 0015 Only split CSV strings once In-Reply-To: <4F69EFC3.6000202@redhat.com> References: <4F464D59.2020601@redhat.com> <4F62491A.7080105@redhat.com> <4F632A28.9060608@redhat.com> <4F68B80E.9040404@redhat.com> <4F68F1C1.6090507@redhat.com> <4F69E585.1070108@redhat.com> <4F69EFC3.6000202@redhat.com> Message-ID: <4F69F1E3.6070505@redhat.com> On 03/21/2012 04:12 PM, Dmitri Pal wrote: > On 03/21/2012 10:28 AM, Petr Viktorin wrote: >> On 03/20/2012 10:08 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 03/16/2012 12:55 PM, Petr Viktorin wrote: >>>>> On 03/15/2012 08:55 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/2227 (Unable to add certain >>>>>>> sudo >>>>>>> commands to groups). What an interesting bug to get :) >>>>>>> >>>>>>> >>>>>>> One problem with our CSV splitting is that it's not idempotent >>>>>>> (baskslashes are "eaten" when there are escaped commas), but when we >>>>>>> forward a call it gets done on both the client and the server. The >>>>>>> attached patch fixes that in a somewhat hacky way. It's not a >>>>>>> complete >>>>>>> fix for the issue though, for that I need to ask what to do. >>>>>>> >>>>>>> >>>>>>> Some Params use the CSV format when we just need a list of >>>>>>> comma-separated values. Our flavor of CSV does escaping in two >>>>>>> different >>>>>>> ways. This is pretty bad for predictability, least-surprise, >>>>>>> documentation, ... >>>>>>> >>>>>>> To recap, the two ways are escaping (escaped commas are ignored, >>>>>>> backslashes also need to be escaped) and quoting (values are >>>>>>> optionally >>>>>>> enclosed in double quotes, to include a '"' in a quoted string, use >>>>>>> '""'). >>>>>>> Escaping is good because users are used to it, but currently literal >>>>>>> backslashes need to be doubled, making multivalue syntax different >>>>>>> from >>>>>>> single-value syntax, even if there are no commas in the value. >>>>>>> Quoting is weird, but complete by itself so it doesn't also need >>>>>>> escaping. >>>>>>> >>>>>>> Do we need to use both? Is this documented somewhere? Some of our >>>>>>> tests >>>>>>> check only for one, some assume the other. Users are probably even >>>>>>> more >>>>>>> confused. >>>>>>> >>>>>>> >>>>>>> If we only keep one of those, the fix for #2227 should be quite >>>>>>> easy. >>>>>>> If not (backwards compatibility), we need to document this properly, >>>>>>> test all the corner cases, and fix the UI to handle CSV escaping. >>>>>>> Since it's subtly broken in lots of places, maybe it's best to break >>>>>>> backwards compatibility and go for a simple solution now. >>>>>>> >>>>>>> Anyway, if I want to do a proper fix, CSV handling should be only >>>>>>> done >>>>>>> on the client. Unfortunately turning off CSV handling in the server >>>>>>> will >>>>>>> break the UI, which at places uses `join(',')` (no escaping >>>>>>> commas, no >>>>>>> single place to change it), even though it can just send a list. >>>>>> >>>>>> I'm with Honza, not too keen on the _forwarded_call part. I'd rather >>>>>> you >>>>>> do a mix of comparing self.env.in_server and whether the value is a >>>>>> basestring to determine if we need to split it. >>>>> >>>>> This was a hack necessary because the WebUI relied on server-side >>>>> splitting (in a few cases, and it did not escape correctly). Now that >>>>> Petr Vobornik's patch 99 is in, it is unnecessary. >>>>> This discussion thread has an updated patch (0015-03); what I'm >>>>> attaching now builds on top of that to add several new changes in >>>>> tests. >>>>> To summarize it: the splitting is only done in the client; from the >>>>> RPC >>>>> call on no CSV magic is involved at all. >>>>> >>>>> Please tell me your reasons for basestring checking. I think it's >>>>> entirely unnecessary and just adds complexity. >>>>> In the rest of the framework a string, as a parameter value, has the >>>>> same effect as a list of that one string. Why break this? >>>>> We are concerned about the API here, not the command line. >>>>> Shortcuts to >>>>> save the user's keystrokes in the common case should *not* win over >>>>> predictability and making sure the easier way is the correct, >>>>> robust way >>>>> to do it. Compare -- with basestring checking: >>>>> >>>>> some_command(arg=escape_commas(some_string)) >>>>> - is correct >>>>> >>>>> some_command(arg=[some_string]) >>>>> - is also correct >>>>> >>>>> some_command(arg=some_string) >>>>> - is WRONG because the string is not escaped >>>>> - but is the easiest solution! >>>>> >>>>> The problem is much worse because it is subtle: it only affects values >>>>> with commas and backslashes, so *the wrong solution would work* in >>>>> most >>>>> of the cases. >>>>> And I can assure you plugin writers *would* pick the wrong way if it >>>>> would usually work. Our own web UI had examples. >>>>> >>>>> Contrast to my proposed behavior: >>>>> some_command(arg=some_string) >>>>> - is correct >>>>> >>>>> some_command(arg=[some_string]) >>>>> - is also correct >>>>> >>>>> some_command(arg=escape_commas(some_string)) >>>>> - is wrong, but doesn't make much sense because at this level you >>>>> don't >>>>> have to worry about CSV at all >>>>> >>>>> Basestring checking would add unnecessary complexity for both us *and* >>>>> the plugin writer. The only case it would make it easier for the >>>>> plugin >>>>> writer is if the plugin took CSV values ?-- but why force a random >>>>> format, tailored for our specific frontend, into RPC clients? >>>>> >>>>> The client should translate the command line into a RPC call. >>>>> There's no >>>>> reason to arbitrarily expect the server to do part of the job. >>>>> >>>>> >>>>>> I'm not sure why this is broken out of normalize. Isn't this >>>>>> normalizing >>>>>> the incoming values into something more sane? >>>>> >>>>> "Normalization" implies it's an idempotent operation, which CSV >>>>> splitting is not (at least its current incarnation, without the >>>>> basestring checking): >>>>> r"a,b\,c" splits to ["a", "b,c"] which splits to ["a", "b", "c"] >>>>> >>>>> >>>> >>>> Just to make things clear: freeipa-pviktori-0015-04 is the latest >>>> version of this patch. >>>> It's complemented by freeipa-pviktori-0021-03 which adds the tests for >>>> this (and other things) (but contains one more refactor). >>>> >>>> >>>> If and when that's all reviewed and pushed, I'd like to discuss >>>> freeipa-pviktori-0018 (Simplify CSV escaping syntax). I'm not saying my >>>> solution there is perfect, but the flavor of Python's CSV parsing we're >>>> using now is quite quirky. It would be nice to get the syntax right, or >>>> at least better, while we're fixing this from a totally-broken state. >>>> Later there'll be backwards compatibility problems. >>>> But, don't let that hold back this patch. >>>> >>> >>> I'm still not completely convinced. This patch looks ok and I'm sold on >>> client side only parsing but this doesn't actually fix any of the CSV >>> bugs we have open. >>> >>> I'd like to evaluate this in more context. >>> >>> I think the simplest fix is to drop escapechar processing in the >>> csvreader and have users quote strings with commas instead, this is how >>> I originally intended it to work. The UI won't have to do anything >>> special since it will already be split and it isn't a lot to ask to put >>> quotes around a value on the CLI. >>> >>> This is my proposed fix on top of your patch: >>> >>> diff --git a/ipalib/parameters.py b/ipalib/parameters.py >>> index 80b175d..ec6020e 100644 >>> --- a/ipalib/parameters.py >>> +++ b/ipalib/parameters.py >>> @@ -702,7 +702,7 @@ class Param(ReadOnly): >>> # csv.py doesn't do Unicode; encode temporarily as UTF-8: >>> csv_reader = csv.reader(self.__utf_8_encoder(unicode_csv_data), >>> dialect=dialect, >>> - delimiter=self.csv_separator, escapechar='\\', >>> + delimiter=self.csv_separator, quotechar='"', >>> skipinitialspace=self.csv_skipspace, >>> **kwargs) >>> for row in csv_reader: >>> >>> With this change: >>> - all the self-tests pass >>> - https://fedorahosted.org/freeipa/ticket/2417 is fixed >>> - https://fedorahosted.org/freeipa/ticket/2227 is fixed >>> >>> I tested with: >>> >>> $ ipa sudocmdgroup-add-member test --sudocmd='/bin/chown -R >>> apache\:developers /var/www/*/shared/log' >>> >>> $ ipa role-add-privilege --privileges='"u,r stuff"' test >>> >>> rob >> >> Yes, that works well. ACK on your change; here it is squashed in. >> >> https://fedorahosted.org/freeipa/ticket/2402 can wait for 3.0, then? > > Is it risky to take it in? > That issue can be solved by feeding individual lines to the CSV reader, and concatenating all lines into the output. I don't think it's too risky, but of course it is riskier than just changing a parser argument. Plus it's a minor issue. Rob? diff --git a/ipalib/parameters.py b/ipalib/parameters.py index 2b07c8f..f509ca5 100644 --- a/ipalib/parameters.py +++ b/ipalib/parameters.py @@ -732,14 +732,15 @@ class Param(ReadOnly): if self.csv: if type(value) not in (tuple, list): value = (value,) - newval = () + newval = [] for v in value: if isinstance(v, basestring): - csvreader = self.__unicode_csv_reader([unicode(v)]) - newval += tuple(csvreader.next()) #pylint: disable=E1101 + lines = unicode(v).splitlines() + for row in self.__unicode_csv_reader(lines): + newval.extend(row) else: - newval += (v,) - return newval + newval.append(v) + return tuple(newval) else: return value -- Petr? From mkosek at redhat.com Wed Mar 21 15:58:16 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Mar 2012 16:58:16 +0100 Subject: [Freeipa-devel] [PATCH] 242 Harden raw record processing in DNS plugin Message-ID: <1332345496.4333.9.camel@balmora.brq.redhat.com> Few test cases are attached to the ticket. This patch depends on my patch 241. --- There were cases where DNS plugin was too tolerant in a raw DNS record option (---rec option. This patch hardens the processing and returns error in both described cases to make the processes clearer and more robust. All these use cases were also covered by new unit tests. https://fedorahosted.org/freeipa/ticket/2551 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-242-harden-raw-record-processing-in-dns-plugin.patch Type: text/x-patch Size: 7959 bytes Desc: not available URL: From rcritten at redhat.com Wed Mar 21 17:14:09 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 21 Mar 2012 13:14:09 -0400 Subject: [Freeipa-devel] [PATCH] 0015 Only split CSV strings once In-Reply-To: <4F69F1E3.6070505@redhat.com> References: <4F464D59.2020601@redhat.com> <4F62491A.7080105@redhat.com> <4F632A28.9060608@redhat.com> <4F68B80E.9040404@redhat.com> <4F68F1C1.6090507@redhat.com> <4F69E585.1070108@redhat.com> <4F69EFC3.6000202@redhat.com> <4F69F1E3.6070505@redhat.com> Message-ID: <4F6A0C61.8060801@redhat.com> Petr Viktorin wrote: > On 03/21/2012 04:12 PM, Dmitri Pal wrote: >> On 03/21/2012 10:28 AM, Petr Viktorin wrote: >>> On 03/20/2012 10:08 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 03/16/2012 12:55 PM, Petr Viktorin wrote: >>>>>> On 03/15/2012 08:55 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> https://fedorahosted.org/freeipa/ticket/2227 (Unable to add certain >>>>>>>> sudo >>>>>>>> commands to groups). What an interesting bug to get :) >>>>>>>> >>>>>>>> >>>>>>>> One problem with our CSV splitting is that it's not idempotent >>>>>>>> (baskslashes are "eaten" when there are escaped commas), but >>>>>>>> when we >>>>>>>> forward a call it gets done on both the client and the server. The >>>>>>>> attached patch fixes that in a somewhat hacky way. It's not a >>>>>>>> complete >>>>>>>> fix for the issue though, for that I need to ask what to do. >>>>>>>> >>>>>>>> >>>>>>>> Some Params use the CSV format when we just need a list of >>>>>>>> comma-separated values. Our flavor of CSV does escaping in two >>>>>>>> different >>>>>>>> ways. This is pretty bad for predictability, least-surprise, >>>>>>>> documentation, ... >>>>>>>> >>>>>>>> To recap, the two ways are escaping (escaped commas are ignored, >>>>>>>> backslashes also need to be escaped) and quoting (values are >>>>>>>> optionally >>>>>>>> enclosed in double quotes, to include a '"' in a quoted string, use >>>>>>>> '""'). >>>>>>>> Escaping is good because users are used to it, but currently >>>>>>>> literal >>>>>>>> backslashes need to be doubled, making multivalue syntax different >>>>>>>> from >>>>>>>> single-value syntax, even if there are no commas in the value. >>>>>>>> Quoting is weird, but complete by itself so it doesn't also need >>>>>>>> escaping. >>>>>>>> >>>>>>>> Do we need to use both? Is this documented somewhere? Some of our >>>>>>>> tests >>>>>>>> check only for one, some assume the other. Users are probably even >>>>>>>> more >>>>>>>> confused. >>>>>>>> >>>>>>>> >>>>>>>> If we only keep one of those, the fix for #2227 should be quite >>>>>>>> easy. >>>>>>>> If not (backwards compatibility), we need to document this >>>>>>>> properly, >>>>>>>> test all the corner cases, and fix the UI to handle CSV escaping. >>>>>>>> Since it's subtly broken in lots of places, maybe it's best to >>>>>>>> break >>>>>>>> backwards compatibility and go for a simple solution now. >>>>>>>> >>>>>>>> Anyway, if I want to do a proper fix, CSV handling should be only >>>>>>>> done >>>>>>>> on the client. Unfortunately turning off CSV handling in the server >>>>>>>> will >>>>>>>> break the UI, which at places uses `join(',')` (no escaping >>>>>>>> commas, no >>>>>>>> single place to change it), even though it can just send a list. >>>>>>> >>>>>>> I'm with Honza, not too keen on the _forwarded_call part. I'd rather >>>>>>> you >>>>>>> do a mix of comparing self.env.in_server and whether the value is a >>>>>>> basestring to determine if we need to split it. >>>>>> >>>>>> This was a hack necessary because the WebUI relied on server-side >>>>>> splitting (in a few cases, and it did not escape correctly). Now that >>>>>> Petr Vobornik's patch 99 is in, it is unnecessary. >>>>>> This discussion thread has an updated patch (0015-03); what I'm >>>>>> attaching now builds on top of that to add several new changes in >>>>>> tests. >>>>>> To summarize it: the splitting is only done in the client; from the >>>>>> RPC >>>>>> call on no CSV magic is involved at all. >>>>>> >>>>>> Please tell me your reasons for basestring checking. I think it's >>>>>> entirely unnecessary and just adds complexity. >>>>>> In the rest of the framework a string, as a parameter value, has the >>>>>> same effect as a list of that one string. Why break this? >>>>>> We are concerned about the API here, not the command line. >>>>>> Shortcuts to >>>>>> save the user's keystrokes in the common case should *not* win over >>>>>> predictability and making sure the easier way is the correct, >>>>>> robust way >>>>>> to do it. Compare -- with basestring checking: >>>>>> >>>>>> some_command(arg=escape_commas(some_string)) >>>>>> - is correct >>>>>> >>>>>> some_command(arg=[some_string]) >>>>>> - is also correct >>>>>> >>>>>> some_command(arg=some_string) >>>>>> - is WRONG because the string is not escaped >>>>>> - but is the easiest solution! >>>>>> >>>>>> The problem is much worse because it is subtle: it only affects >>>>>> values >>>>>> with commas and backslashes, so *the wrong solution would work* in >>>>>> most >>>>>> of the cases. >>>>>> And I can assure you plugin writers *would* pick the wrong way if it >>>>>> would usually work. Our own web UI had examples. >>>>>> >>>>>> Contrast to my proposed behavior: >>>>>> some_command(arg=some_string) >>>>>> - is correct >>>>>> >>>>>> some_command(arg=[some_string]) >>>>>> - is also correct >>>>>> >>>>>> some_command(arg=escape_commas(some_string)) >>>>>> - is wrong, but doesn't make much sense because at this level you >>>>>> don't >>>>>> have to worry about CSV at all >>>>>> >>>>>> Basestring checking would add unnecessary complexity for both us >>>>>> *and* >>>>>> the plugin writer. The only case it would make it easier for the >>>>>> plugin >>>>>> writer is if the plugin took CSV values ?-- but why force a random >>>>>> format, tailored for our specific frontend, into RPC clients? >>>>>> >>>>>> The client should translate the command line into a RPC call. >>>>>> There's no >>>>>> reason to arbitrarily expect the server to do part of the job. >>>>>> >>>>>> >>>>>>> I'm not sure why this is broken out of normalize. Isn't this >>>>>>> normalizing >>>>>>> the incoming values into something more sane? >>>>>> >>>>>> "Normalization" implies it's an idempotent operation, which CSV >>>>>> splitting is not (at least its current incarnation, without the >>>>>> basestring checking): >>>>>> r"a,b\,c" splits to ["a", "b,c"] which splits to ["a", "b", "c"] >>>>>> >>>>>> >>>>> >>>>> Just to make things clear: freeipa-pviktori-0015-04 is the latest >>>>> version of this patch. >>>>> It's complemented by freeipa-pviktori-0021-03 which adds the tests for >>>>> this (and other things) (but contains one more refactor). >>>>> >>>>> >>>>> If and when that's all reviewed and pushed, I'd like to discuss >>>>> freeipa-pviktori-0018 (Simplify CSV escaping syntax). I'm not >>>>> saying my >>>>> solution there is perfect, but the flavor of Python's CSV parsing >>>>> we're >>>>> using now is quite quirky. It would be nice to get the syntax >>>>> right, or >>>>> at least better, while we're fixing this from a totally-broken state. >>>>> Later there'll be backwards compatibility problems. >>>>> But, don't let that hold back this patch. >>>>> >>>> >>>> I'm still not completely convinced. This patch looks ok and I'm sold on >>>> client side only parsing but this doesn't actually fix any of the CSV >>>> bugs we have open. >>>> >>>> I'd like to evaluate this in more context. >>>> >>>> I think the simplest fix is to drop escapechar processing in the >>>> csvreader and have users quote strings with commas instead, this is how >>>> I originally intended it to work. The UI won't have to do anything >>>> special since it will already be split and it isn't a lot to ask to put >>>> quotes around a value on the CLI. >>>> >>>> This is my proposed fix on top of your patch: >>>> >>>> diff --git a/ipalib/parameters.py b/ipalib/parameters.py >>>> index 80b175d..ec6020e 100644 >>>> --- a/ipalib/parameters.py >>>> +++ b/ipalib/parameters.py >>>> @@ -702,7 +702,7 @@ class Param(ReadOnly): >>>> # csv.py doesn't do Unicode; encode temporarily as UTF-8: >>>> csv_reader = csv.reader(self.__utf_8_encoder(unicode_csv_data), >>>> dialect=dialect, >>>> - delimiter=self.csv_separator, escapechar='\\', >>>> + delimiter=self.csv_separator, quotechar='"', >>>> skipinitialspace=self.csv_skipspace, >>>> **kwargs) >>>> for row in csv_reader: >>>> >>>> With this change: >>>> - all the self-tests pass >>>> - https://fedorahosted.org/freeipa/ticket/2417 is fixed >>>> - https://fedorahosted.org/freeipa/ticket/2227 is fixed >>>> >>>> I tested with: >>>> >>>> $ ipa sudocmdgroup-add-member test --sudocmd='/bin/chown -R >>>> apache\:developers /var/www/*/shared/log' >>>> >>>> $ ipa role-add-privilege --privileges='"u,r stuff"' test >>>> >>>> rob >>> >>> Yes, that works well. ACK on your change; here it is squashed in. >>> >>> https://fedorahosted.org/freeipa/ticket/2402 can wait for 3.0, then? >> >> Is it risky to take it in? >> > > > That issue can be solved by feeding individual lines to the CSV reader, > and concatenating all lines into the output. I don't think it's too > risky, but of course it is riskier than just changing a parser argument. > Plus it's a minor issue. > > Rob? > > > diff --git a/ipalib/parameters.py b/ipalib/parameters.py > index 2b07c8f..f509ca5 100644 > --- a/ipalib/parameters.py > +++ b/ipalib/parameters.py > @@ -732,14 +732,15 @@ class Param(ReadOnly): > if self.csv: > if type(value) not in (tuple, list): > value = (value,) > - newval = () > + newval = [] > for v in value: > if isinstance(v, basestring): > - csvreader = self.__unicode_csv_reader([unicode(v)]) > - newval += tuple(csvreader.next()) #pylint: disable=E1101 > + lines = unicode(v).splitlines() > + for row in self.__unicode_csv_reader(lines): > + newval.extend(row) > else: > - newval += (v,) > - return newval > + newval.append(v) > + return tuple(newval) > else: > return value This approach seems ok, can you submit it as a formal patch review? I think this is probably acceptable as-is but the probability of someone actually doing the type paste to generate this problem is probably pretty low :-) ACK on 0015-05. Pushed to master and ipa-2-2 rob From pviktori at redhat.com Thu Mar 22 08:40:15 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Mar 2012 09:40:15 +0100 Subject: [Freeipa-devel] [PATCH] 0030 Allow multi-line CSV parameters Message-ID: <4F6AE56F.1060203@redhat.com> Feed individual lines of input into the CSV parser, and include all lines in the output. https://fedorahosted.org/freeipa/ticket/2402 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0030-Allow-multi-line-CSV-values.patch Type: text/x-patch Size: 1450 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 22 10:30:23 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Mar 2012 11:30:23 +0100 Subject: [Freeipa-devel] [PATCH] 991/992 fix migration issues In-Reply-To: <4F6943D2.2060005@redhat.com> References: <4F6943D2.2060005@redhat.com> Message-ID: <1332412223.10439.14.camel@balmora.brq.redhat.com> On Tue, 2012-03-20 at 22:58 -0400, Rob Crittenden wrote: > Fix a couple of issues found with migration. I made a second patch just > to keep things separate even though its just a one-liner. > > 991 fixes a problem where we have attributes which point to other > entries and these weren't being migrated. This is things like secretary > and manager. This was actually causing things to blow up badly. > > 992 makes the primary key lower-case to match the rest of IPA. > > I've attached an LDIF with a couple of users to demonstrate the fix. > > rob 1) This is not very Pythonic: + for ind in xrange(len(entry_attrs[attr])): + value = entry_attrs[attr][ind] This would be better: + for ind,value in enumerate(entry_attrs[attr]): 2) 992 lowers uid of users group, but you leave updated DNs un-normalized, we may want to lower them as well: # ayaz_kreiger, users, accounts, idm.lab.bos.redhat.com dn: uid=ayaz_kreiger,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=co m uid: ayaz_kreiger ... manager: uid=Mollee_Weisenberg,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=re dhat,dc=com manager: cn=Doesnot Exist,ou=People,dc=greyoak,dc=com ... 3) We still crash if the DN does not exist (see above) and thus we don't normalize it: # ipa user-show ayaz_kreiger --allipa: ERROR: an internal error has occurred I think we should use the change that came up when I was reviewing Petr3's sudo patch: diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py index cf5d8d20eb27a0342f064086e0ee9d85c78c5bae..8f03a09827bd0ee6a08e594617ad8d4dff2b467b 100644 --- a/ipalib/plugins/baseldap.py +++ b/ipalib/plugins/baseldap.py @@ -487,7 +487,15 @@ class LDAPObject(Object): pass # DN object assures we're returning a decoded (unescaped) value dn = DN(dn) - return dn[self.primary_key.name] + try: + return dn[self.primary_key.name] + except KeyError: + # The primary key is not in the DN. + # This shouldn't happen, but we don't want a "show" command to + # crash. + # Just return the entire DN, it's all we have if the entry + # doesn't exist + return unicode(dn) 4) (minor) In function get_dn_syntax: - if obj is None, the function will return None -> contradicts with the help - I would name the function "is_dn_syntax" since we don't return DN syntax Martin From abokovoy at redhat.com Thu Mar 22 13:22:56 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Mar 2012 15:22:56 +0200 Subject: [Freeipa-devel] [PATCH] fix selinux configuration for httpd instance Message-ID: <20120322132256.GD14086@redhat.com> Hi, attached patch fixes the problem I see with master (and ipa-2-2): 2012-03-22T10:58:34Z DEBUG args=/usr/sbin/setsebool -P httpd_can_network_connect=true httpd_manage_ipa=true 2012-03-22T10:58:34Z DEBUG stdout= 2012-03-22T10:58:34Z DEBUG stderr=setsebool: illegal value true httpd_manage_ipa=true for boolean httpd_can_network_connect -- / Alexander Bokovoy -------------- next part -------------- >From d56f6bda52212b6638c6d0189ecab09b72d8b104 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 22 Mar 2012 15:18:01 +0200 Subject: [PATCH] When changing multiple booleans with setsebool, pass each of them separately. Fixes SELinux configuration for ipa-server-install with selinux-policy 3.10.0-104.fc17. --- ipaserver/install/httpinstance.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ipaserver/install/httpinstance.py b/ipaserver/install/httpinstance.py index 60d5604..e46d4ed 100644 --- a/ipaserver/install/httpinstance.py +++ b/ipaserver/install/httpinstance.py @@ -129,8 +129,10 @@ class HTTPInstance(service.Service): # together so it is speedier. if vars: bools = [var + "=true" for var in vars] + args = ["/usr/sbin/setsebool", "-P"] + args.extend(bools); try: - ipautil.run(["/usr/sbin/setsebool", "-P", ' '.join(bools)]) + ipautil.run(args) except: self.print_msg(selinux_warning % dict(var=','.join(vars))) -- 1.7.9.3 From pviktori at redhat.com Thu Mar 22 14:19:41 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Mar 2012 15:19:41 +0100 Subject: [Freeipa-devel] [PATCH] 988 fix host test In-Reply-To: <4F625984.2090903@redhat.com> References: <4F625984.2090903@redhat.com> Message-ID: <4F6B34FD.2020407@redhat.com> On 03/15/2012 10:05 PM, Rob Crittenden wrote: > A test to make sure hosts can be renamed using setattr is using an > invalid hostname so the host_mod will never get hit. > > rob > ACK -- Petr? From pviktori at redhat.com Thu Mar 22 14:31:32 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Mar 2012 15:31:32 +0100 Subject: [Freeipa-devel] [PATCH] fix selinux configuration for httpd instance In-Reply-To: <20120322132256.GD14086@redhat.com> References: <20120322132256.GD14086@redhat.com> Message-ID: <4F6B37C4.4020606@redhat.com> On 03/22/2012 02:22 PM, Alexander Bokovoy wrote: > Hi, > > attached patch fixes the problem I see with master (and ipa-2-2): > > 2012-03-22T10:58:34Z DEBUG args=/usr/sbin/setsebool -P > httpd_can_network_connect=true httpd_manage_ipa=true > 2012-03-22T10:58:34Z DEBUG stdout= > 2012-03-22T10:58:34Z DEBUG stderr=setsebool: illegal value true > httpd_manage_ipa=true for boolean httpd_can_network_connect > I just ran into this too. The patch works fine, ACK -- Petr? From rcritten at redhat.com Thu Mar 22 14:57:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 22 Mar 2012 10:57:20 -0400 Subject: [Freeipa-devel] [PATCH] 988 fix host test In-Reply-To: <4F6B34FD.2020407@redhat.com> References: <4F625984.2090903@redhat.com> <4F6B34FD.2020407@redhat.com> Message-ID: <4F6B3DD0.4000806@redhat.com> Petr Viktorin wrote: > On 03/15/2012 10:05 PM, Rob Crittenden wrote: >> A test to make sure hosts can be renamed using setattr is using an >> invalid hostname so the host_mod will never get hit. >> >> rob >> > > ACK > > pushed to master and ipa-2-2 From pspacek at redhat.com Thu Mar 22 15:27:13 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Mar 2012 16:27:13 +0100 Subject: [Freeipa-devel] [PATCH] 0013 Fix SOA record update Message-ID: <4F6B44D1.2060502@redhat.com> Hello, this patch fixes wrong SOA updates during DNS zone dynamic update (via nsupdate). It fixes LDAP plugin part of BZ: https://bugzilla.redhat.com/show_bug.cgi?id=805871 Incorrect SOA serial number format after IPA installation has to be solved in IPA install scripts. Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0013-Fix-SOA-record-update.patch Type: text/x-patch Size: 2065 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 22 15:30:15 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Mar 2012 16:30:15 +0100 Subject: [Freeipa-devel] [PATCH] 241 Fix precallback validators in DNS plugin In-Reply-To: <1332334307.4333.6.camel@balmora.brq.redhat.com> References: <1332334307.4333.6.camel@balmora.brq.redhat.com> Message-ID: <4F6B4587.2060709@redhat.com> On 03/21/2012 01:51 PM, Martin Kosek wrote: > DNS plugin contains several RR type record validators run in > pre_callback which cannot be used as standard param validator > as it needs more data and resources that standard validators > provide. However, the precallback validators are not run for > DNS records created by new structured options and thus an invalid > value may slip in. > > This patch moves the execution of these precallback validators > _after_ the processing of structured DNS options. It also cleans > them up a little and makes them more robust. > > https://fedorahosted.org/freeipa/ticket/2550 > Functionally, the patch works fine. Since you're cleaning up, I have some nitpicks, but ACK if you disagree. Consider if instead of: rtype_cb = '_%s_pre_callback' % rtype if hasattr(self.obj, rtype_cb): getattr(self.obj, rtype_cb)(ldap, dn, entry_attrs, *keys, **options) this wouldn't be more readable: rtype_cb = getattr(self.obj, '_%s_pre_callback' % rtype, None) if rtype_cb: rtype_cb(ldap, dn, entry_attrs, *keys, **options) and since the block appears twice now, make it a method. Also, since is_ns_rec_resolvable raises an exception rather than returning a bool, it should probably be renamed to something like check_ns_rec_resolvable. -- Petr? From mkosek at redhat.com Thu Mar 22 15:35:07 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Mar 2012 16:35:07 +0100 Subject: [Freeipa-devel] [PATCH] 71 Propagate SIGINT to child process in ipautil.run In-Reply-To: <4F68B4ED.4040001@redhat.com> References: <4F68B4ED.4040001@redhat.com> Message-ID: <1332430507.2466.2.camel@balmora.brq.redhat.com> On Tue, 2012-03-20 at 17:48 +0100, Jan Cholasta wrote: > Propagate SIGINT to child process in ipautil.run. > > Wait for the child process to terminate before continuing. > > Do cleanup on KeyboardInterrupt rather than in custom SIGINT handler in > ipa-replica-conncheck. > > https://fedorahosted.org/freeipa/ticket/2127 > > Honza This looks and works OK, I have just one minor issue. Isn't the extra p.wait() you added to the standard run() path redundant? p.communicate() should do the job of waiting until the child process terminates. + try: + p = subprocess.Popen(args, stdin=p_in, stdout=p_out, stderr=p_err, + close_fds=True, env=env) + stdout,stderr = p.communicate(stdin) + stdout,stderr = str(stdout), str(stderr) # Make pylint happy + p.wait() + except KeyboardInterrupt: Martin From mkosek at redhat.com Thu Mar 22 15:53:07 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Mar 2012 16:53:07 +0100 Subject: [Freeipa-devel] [PATCH] 241 Fix precallback validators in DNS plugin In-Reply-To: <4F6B4587.2060709@redhat.com> References: <1332334307.4333.6.camel@balmora.brq.redhat.com> <4F6B4587.2060709@redhat.com> Message-ID: <1332431587.2466.4.camel@balmora.brq.redhat.com> On Thu, 2012-03-22 at 16:30 +0100, Petr Viktorin wrote: > On 03/21/2012 01:51 PM, Martin Kosek wrote: > > DNS plugin contains several RR type record validators run in > > pre_callback which cannot be used as standard param validator > > as it needs more data and resources that standard validators > > provide. However, the precallback validators are not run for > > DNS records created by new structured options and thus an invalid > > value may slip in. > > > > This patch moves the execution of these precallback validators > > _after_ the processing of structured DNS options. It also cleans > > them up a little and makes them more robust. > > > > https://fedorahosted.org/freeipa/ticket/2550 > > > > Functionally, the patch works fine. > Since you're cleaning up, I have some nitpicks, but ACK if you disagree. > > > Consider if instead of: > > rtype_cb = '_%s_pre_callback' % rtype > if hasattr(self.obj, rtype_cb): > getattr(self.obj, rtype_cb)(ldap, dn, entry_attrs, *keys, **options) > > this wouldn't be more readable: > > rtype_cb = getattr(self.obj, '_%s_pre_callback' % rtype, None) > if rtype_cb: > rtype_cb(ldap, dn, entry_attrs, *keys, **options) > > and since the block appears twice now, make it a method. > > Also, since is_ns_rec_resolvable raises an exception rather than > returning a bool, it should probably be renamed to something like > check_ns_rec_resolvable. > These are good ideas, please check the attached patch. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-241-2-fix-precallback-validators-in-dns-plugin.patch Type: text/x-patch Size: 8176 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 22 16:16:23 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Mar 2012 17:16:23 +0100 Subject: [Freeipa-devel] [PATCH] 19 Search allowed attributes in superior objectclasses In-Reply-To: <4F69E7D8.8040004@redhat.com> References: <4F69E7D8.8040004@redhat.com> Message-ID: <1332432983.2466.6.camel@balmora.brq.redhat.com> On Wed, 2012-03-21 at 15:38 +0100, Ondrej Hamada wrote: > https://fedorahosted.org/freeipa/ticket/2293 > > This patch fixes regression caused by patch for ticket #2293. The > function get_allowed_attributes was searching only through the specified > objectclasses but not through their superior objectclasses. This patch > adds such behaviour by recursive call of get_allowed_attributes on the > superior objectclasses. > > Test case that revealed the regression was added into the unit-tests. ACK, nice solution. Pushed to master, ipa-2-2. Martin From pviktori at redhat.com Thu Mar 22 16:19:47 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Mar 2012 17:19:47 +0100 Subject: [Freeipa-devel] [PATCH] 241 Fix precallback validators in DNS plugin In-Reply-To: <1332431587.2466.4.camel@balmora.brq.redhat.com> References: <1332334307.4333.6.camel@balmora.brq.redhat.com> <4F6B4587.2060709@redhat.com> <1332431587.2466.4.camel@balmora.brq.redhat.com> Message-ID: <4F6B5123.3080103@redhat.com> On 03/22/2012 04:53 PM, Martin Kosek wrote: > On Thu, 2012-03-22 at 16:30 +0100, Petr Viktorin wrote: >> On 03/21/2012 01:51 PM, Martin Kosek wrote: >>> DNS plugin contains several RR type record validators run in >>> pre_callback which cannot be used as standard param validator >>> as it needs more data and resources that standard validators >>> provide. However, the precallback validators are not run for >>> DNS records created by new structured options and thus an invalid >>> value may slip in. >>> >>> This patch moves the execution of these precallback validators >>> _after_ the processing of structured DNS options. It also cleans >>> them up a little and makes them more robust. >>> >>> https://fedorahosted.org/freeipa/ticket/2550 >>> >> >> Functionally, the patch works fine. >> Since you're cleaning up, I have some nitpicks, but ACK if you disagree. >> >> >> Consider if instead of: >> >> rtype_cb = '_%s_pre_callback' % rtype >> if hasattr(self.obj, rtype_cb): >> getattr(self.obj, rtype_cb)(ldap, dn, entry_attrs, *keys, **options) >> >> this wouldn't be more readable: >> >> rtype_cb = getattr(self.obj, '_%s_pre_callback' % rtype, None) >> if rtype_cb: >> rtype_cb(ldap, dn, entry_attrs, *keys, **options) >> >> and since the block appears twice now, make it a method. >> >> Also, since is_ns_rec_resolvable raises an exception rather than >> returning a bool, it should probably be renamed to something like >> check_ns_rec_resolvable. >> > > These are good ideas, please check the attached patch. > > Martin ACK -- Petr? From mkosek at redhat.com Thu Mar 22 16:28:24 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Mar 2012 17:28:24 +0100 Subject: [Freeipa-devel] [PATCH] 241 Fix precallback validators in DNS plugin In-Reply-To: <4F6B5123.3080103@redhat.com> References: <1332334307.4333.6.camel@balmora.brq.redhat.com> <4F6B4587.2060709@redhat.com> <1332431587.2466.4.camel@balmora.brq.redhat.com> <4F6B5123.3080103@redhat.com> Message-ID: <1332433704.2466.7.camel@balmora.brq.redhat.com> On Thu, 2012-03-22 at 17:19 +0100, Petr Viktorin wrote: > On 03/22/2012 04:53 PM, Martin Kosek wrote: > > On Thu, 2012-03-22 at 16:30 +0100, Petr Viktorin wrote: > >> On 03/21/2012 01:51 PM, Martin Kosek wrote: > >>> DNS plugin contains several RR type record validators run in > >>> pre_callback which cannot be used as standard param validator > >>> as it needs more data and resources that standard validators > >>> provide. However, the precallback validators are not run for > >>> DNS records created by new structured options and thus an invalid > >>> value may slip in. > >>> > >>> This patch moves the execution of these precallback validators > >>> _after_ the processing of structured DNS options. It also cleans > >>> them up a little and makes them more robust. > >>> > >>> https://fedorahosted.org/freeipa/ticket/2550 > >>> > >> > >> Functionally, the patch works fine. > >> Since you're cleaning up, I have some nitpicks, but ACK if you disagree. > >> > >> > >> Consider if instead of: > >> > >> rtype_cb = '_%s_pre_callback' % rtype > >> if hasattr(self.obj, rtype_cb): > >> getattr(self.obj, rtype_cb)(ldap, dn, entry_attrs, *keys, **options) > >> > >> this wouldn't be more readable: > >> > >> rtype_cb = getattr(self.obj, '_%s_pre_callback' % rtype, None) > >> if rtype_cb: > >> rtype_cb(ldap, dn, entry_attrs, *keys, **options) > >> > >> and since the block appears twice now, make it a method. > >> > >> Also, since is_ns_rec_resolvable raises an exception rather than > >> returning a bool, it should probably be renamed to something like > >> check_ns_rec_resolvable. > >> > > > > These are good ideas, please check the attached patch. > > > > Martin > > ACK > Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Thu Mar 22 16:34:38 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Mar 2012 17:34:38 +0100 Subject: [Freeipa-devel] [PATCH] 489 Fix coverity issues In-Reply-To: <1332260554.9238.636.camel@willson.li.ssimo.org> References: <1332260554.9238.636.camel@willson.li.ssimo.org> Message-ID: <1332434078.2466.8.camel@balmora.brq.redhat.com> On Tue, 2012-03-20 at 12:22 -0400, Simo Sorce wrote: > There is one memory leak in case of an unlikely error condition, most > others are just changes to silence coverity where we know that the > condition cannot really happen. > > Simo. ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Thu Mar 22 16:38:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Mar 2012 17:38:00 +0100 Subject: [Freeipa-devel] [PATCH] 242 Harden raw record processing in DNS plugin In-Reply-To: <1332345496.4333.9.camel@balmora.brq.redhat.com> References: <1332345496.4333.9.camel@balmora.brq.redhat.com> Message-ID: <1332434280.2466.10.camel@balmora.brq.redhat.com> On Wed, 2012-03-21 at 16:58 +0100, Martin Kosek wrote: > Few test cases are attached to the ticket. > This patch depends on my patch 241. > --- > There were cases where DNS plugin was too tolerant in a raw DNS > record option (-- DNS record parts options in dnsrecord-mod operations for some > record without specifying the record that should be updated. It > also ignored DNS record parts in dnsrecord-add operation when the > raw DNS record value was already set via ---rec option. > > This patch hardens the processing and returns error in both > described cases to make the processes clearer and more robust. > > All these use cases were also covered by new unit tests. > > https://fedorahosted.org/freeipa/ticket/2551 > My patch 241 was pushed, attaching a rebased patch 242 that applies cleanly to ipa-2-2 branch. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-242-2-harden-raw-record-processing-in-dns-plugin.patch Type: text/x-patch Size: 8004 bytes Desc: not available URL: From ohamada at redhat.com Thu Mar 22 16:41:06 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Thu, 22 Mar 2012 17:41:06 +0100 Subject: [Freeipa-devel] [PATCH] 15 Confusing default user groups In-Reply-To: <1332174357.24427.47.camel@balmora.brq.redhat.com> References: <4F565247.2050105@redhat.com> <1332174357.24427.47.camel@balmora.brq.redhat.com> Message-ID: <4F6B5622.2090409@redhat.com> On 03/19/2012 05:25 PM, Martin Kosek wrote: > On Tue, 2012-03-06 at 19:07 +0100, Ondrej Hamada wrote: >> https://fedorahosted.org/freeipa/ticket/2354 >> >> There was added '(fallback)' string in the automember plugin labels >> referring to automember default groups to point out, that the users are >> already members of default group specified in IPA config, thus the >> default group specified in automember will be additional one - a >> fallback group. > Hm, looks ok. Though I would also like some second opinion for this > change. I think naming it simply "Fallback Group" would be better, but > we cannot change the API at this stage and rename the parameter. So this > change is a good compromise so far, IMO. > > I found few issues though: > > 1) The label of default group parameter in automember has not been > updated, i.e. the following command still shows the old name: > > # ipa automember-default-group-show --type=group > Default Group: > cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > > 2) I think we could fix few issues in docstrings since we touch these > strings anyway: > > a) Typo in doc > > - label=_('Default Group'), > - doc=_('Default group for entires to land'), > + label=_('Default (fallback) Group'), > + doc=_('Default (fallback) group for entires to land'), > > b) Non-translatable strings: > > - entry_attrs['automemberdefaultgroup'] = u'No default group > set' > + entry_attrs['automemberdefaultgroup'] = u'No default > (fallback) group set' > > > - entry_attrs['automemberdefaultgroup'] = u'No default group > set' > + entry_attrs['automemberdefaultgroup'] = u'No default > (fallback) group set' > > Martin > fixed Ondra -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-15-2-Confusing-default-user-groups.patch Type: text/x-patch Size: 7107 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 22 17:01:39 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Mar 2012 18:01:39 +0100 Subject: [Freeipa-devel] [PATCH] 242 Harden raw record processing in DNS plugin In-Reply-To: <1332434280.2466.10.camel@balmora.brq.redhat.com> References: <1332345496.4333.9.camel@balmora.brq.redhat.com> <1332434280.2466.10.camel@balmora.brq.redhat.com> Message-ID: <4F6B5AF3.9090609@redhat.com> On 03/22/2012 05:38 PM, Martin Kosek wrote: > On Wed, 2012-03-21 at 16:58 +0100, Martin Kosek wrote: >> Few test cases are attached to the ticket. >> This patch depends on my patch 241. >> --- >> There were cases where DNS plugin was too tolerant in a raw DNS >> record option (--> DNS record parts options in dnsrecord-mod operations for some >> record without specifying the record that should be updated. It >> also ignored DNS record parts in dnsrecord-add operation when the >> raw DNS record value was already set via ---rec option. >> >> This patch hardens the processing and returns error in both >> described cases to make the processes clearer and more robust. >> >> All these use cases were also covered by new unit tests. >> >> https://fedorahosted.org/freeipa/ticket/2551 >> > > My patch 241 was pushed, attaching a rebased patch 242 that applies > cleanly to ipa-2-2 branch. > > Martin > > ACK -- Petr? From pvoborni at redhat.com Thu Mar 22 17:50:24 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 22 Mar 2012 18:50:24 +0100 Subject: [Freeipa-devel] [PATCHES] 113-114 Facet expiration flag Message-ID: <4F6B6660.1020104@redhat.com> The effort was split to two patches. See patch descriptions. Notes: Case #7 (automatic: an open facet should automatically refresh itself when it expires) I don't want to implement because I think it can cause havoc ie: refresh when user is editing. Also I was thinking about splitting needs_update to two methods: needs_update and state_changed. State changed would compare current state with old state. It would be called from needs_update. This way we don't have to override needs_update and just define various state_changed for different facets. Also I'm thinking about adding paging state comparison to search facet (the page should recognize the change itself ie when other facet redirects to certain page (bad example?)). What do you think? https://fedorahosted.org/freeipa/ticket/2075 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0113-Facet-expiration-flag.patch Type: text/x-patch Size: 10492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0114-Inter-facet-expiration.patch Type: text/x-patch Size: 15180 bytes Desc: not available URL: From jdennis at redhat.com Thu Mar 22 18:02:14 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 22 Mar 2012 14:02:14 -0400 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test Message-ID: <4F6B6926.9060108@redhat.com> [resending because I originally sent this to the wrong list] This addresses tickets 2044 and 1958. Ticket 2044 was on my short list but the code had already been written for ticket 1958 (validation of substitution variables). It had been sitting in my home directory waiting for integration so since the original 2044 ticket required me to update test_i18n.py it seemed like a perfect opportunity to get ticket 1958 done as well, it only added 2 hours of additional work. Summary: In the install/po directory you can now do this: % make test % make validate Details (aside from what is in the commit message): Also attached (to prevent line wrapping) is an example of validating the Spanish translation. It gives a good example of the type of errors it's capable of finding. This is not abstract, mistakes like these caused us to throw errors in different locales and since we normally test only with English it's important to assure the other languages do not cause Python errors. We should consider adding the i18n validation to our top level validation logic so don't allow problems to creep in (our original non-translated strings are checked too and are just as capable of having errors as the translated strings). When I ran the validation on our complete set of files a lot of errors were reported for ipalib/plugins/hbactest.py:27 msgid has whitespace between $ and variable in '$ ipa ' This is due to a doc string with shell command examples, the $ is the shell prompt. The validation code looks for $ followed by a word token (these are template substitutions). We have a lot of variable and template substitutions in our strings, any of which could be malformed and cause serious run-time problems. I don't know of any way to have the validation logic ignore the use of $ as a shell prompt without adding a special case exception. Since shell prompts are rarity in strings my suggestion would be to pick a different shell prompt character, something other than $ and be done with the issue and not try to over-engineer the validation logic. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: example1.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0066-Replace-broken-i18n-shell-test-with-Python-test.patch Type: text/x-patch Size: 24639 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 22 18:32:05 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Mar 2012 19:32:05 +0100 Subject: [Freeipa-devel] [PATCH] 242 Harden raw record processing in DNS plugin In-Reply-To: <4F6B5AF3.9090609@redhat.com> References: <1332345496.4333.9.camel@balmora.brq.redhat.com> <1332434280.2466.10.camel@balmora.brq.redhat.com> <4F6B5AF3.9090609@redhat.com> Message-ID: <1332441125.2207.2.camel@priserak> On Thu, 2012-03-22 at 18:01 +0100, Petr Viktorin wrote: > On 03/22/2012 05:38 PM, Martin Kosek wrote: > > On Wed, 2012-03-21 at 16:58 +0100, Martin Kosek wrote: > >> Few test cases are attached to the ticket. > >> This patch depends on my patch 241. > >> --- > >> There were cases where DNS plugin was too tolerant in a raw DNS > >> record option (-- >> DNS record parts options in dnsrecord-mod operations for some > >> record without specifying the record that should be updated. It > >> also ignored DNS record parts in dnsrecord-add operation when the > >> raw DNS record value was already set via ---rec option. > >> > >> This patch hardens the processing and returns error in both > >> described cases to make the processes clearer and more robust. > >> > >> All these use cases were also covered by new unit tests. > >> > >> https://fedorahosted.org/freeipa/ticket/2551 > >> > > > > My patch 241 was pushed, attaching a rebased patch 242 that applies > > cleanly to ipa-2-2 branch. > > > > Martin > > > > > > > ACK > Pushed to master, ipa-2-2. Martin From pviktori at redhat.com Thu Mar 22 18:59:08 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Mar 2012 19:59:08 +0100 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F6B5AF2.9070009@redhat.com> References: <4F6B5AF2.9070009@redhat.com> Message-ID: <4F6B767C.4000301@redhat.com> On 03/22/2012 06:01 PM, John Dennis wrote: > This addresses tickets 2044 and 1958. Ticket 2044 was on my short list > but the code had already been written for ticket 1958 (validation of > substitution variables). It had been sitting in my home directory > waiting for integration so since the original 2044 ticket required me to > update test_i18n.py it seemed like a perfect opportunity to get ticket > 1958 done as well, it only added 2 hours of additional work. This is great! > Summary: > > In the install/po directory you can now do this: > > % make test > % make validate > > Details (aside from what is in the commit message): > > Also attached (to prevent line wrapping) is an example of validating the > Spanish translation. It gives a good example of the type of errors it's > capable of finding. This is not abstract, mistakes like these caused us > to throw errors in different locales and since we normally test only > with English it's important to assure the other languages do not cause > Python errors. > > We should consider adding the i18n validation to our top level > validation logic so don't allow problems to creep in (our original > non-translated strings are checked too and are just as capable of having > errors as the translated strings). Errors in English strings should be caught by regular tests. But yes, if we ship translations in the repo, the main test suite should check them. (If it doesn't take minutes to run). > When I ran the validation on our complete set of files a lot of errors > were reported for > > ipalib/plugins/hbactest.py:27 > msgid has whitespace between $ and variable in '$ ipa ' > > This is due to a doc string with shell command examples, the $ > is the shell prompt. The validation code looks for $ followed by a word > token (these are template substitutions). We have a lot of variable and > template substitutions in our strings, any of which could be malformed > and cause serious run-time problems. I don't know of any way to have the > validation logic ignore the use of $ as a shell prompt without adding a > special case exception. Since shell prompts are rarity in strings my > suggestion would be to pick a different shell prompt character, > something other than $ and be done with the issue and not try to > over-engineer the validation logic. No need to test this case -- if there's whitespace, it's not a shell substitution. If it's wrong in English, we should notice. If it's wrong in another language, it should be caught by checking if the translation contains all necessary substitutions. (In fact, all these syntax tests are redundant. But they do make nice error messages.) > Some of the option parsing code is reinventing the wheel a bit. The rest of the project uses optparse.OptionParser, it'd be nice to switch to that. Particularly the global config dict is a bad idea. Don't assume all of this will only ever run as a script. Give the constants their own variables (and advertise that they're constants, as per http://www.python.org/dev/peps/pep-0008/#constants). In validate_substitutions_match, you may be over-validating. Why does a given substitution need to appear the same number of times in both strings? Making sure translators include all needed info is nice, but outside of that, give them some freedom. A nice sanity test I've seen in Qt is checking if the original and translation strings end in the same punctuation ('.', '?', '!', ':'). Would it make sense to implement that? I saw some style issues, e.g.: - in places such as this: > raise ValueError("Translated string \"%s\" minus the first & last character is not equal to msgid \"%s\"" % \ > (translated.encode('utf-8'), msgid)) line continuation backslashes are unnecessary inside parentheses. Also you can mix single and double quotes to avoid backslashes in strings. - {'':'', '(':')', '{':'}'} should have spaces after the colons - in entry_seperator = '-' * page_width there's too much whitespace All of this is quite a lot of nontrivial code; some tests for the validation itself would be nice. All in all, nice work! I hope I don't sound too negative, I really like where this is going. -- Petr? From pviktori at redhat.com Thu Mar 22 19:11:45 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Mar 2012 20:11:45 +0100 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F6B6926.9060108@redhat.com> References: <4F6B6926.9060108@redhat.com> Message-ID: <4F6B7971.5080107@redhat.com> On 03/22/2012 07:02 PM, John Dennis wrote: > [resending because I originally sent this to the wrong list] > > This addresses tickets 2044 and 1958. Ticket 2044 was on my short list > but the code had already been written for ticket 1958 (validation of > substitution variables). It had been sitting in my home directory > waiting for integration so since the original 2044 ticket required me to > update test_i18n.py it seemed like a perfect opportunity to get ticket > 1958 done as well, it only added 2 hours of additional work. > > Summary: > > In the install/po directory you can now do this: > > % make test > % make validate > > Details (aside from what is in the commit message): > > Also attached (to prevent line wrapping) is an example of validating the > Spanish translation. It gives a good example of the type of errors it's > capable of finding. This is not abstract, mistakes like these caused us > to throw errors in different locales and since we normally test only > with English it's important to assure the other languages do not cause > Python errors. > > We should consider adding the i18n validation to our top level > validation logic so don't allow problems to creep in (our original > non-translated strings are checked too and are just as capable of having > errors as the translated strings). > > When I ran the validation on our complete set of files a lot of errors > were reported for > > ipalib/plugins/hbactest.py:27 > msgid has whitespace between $ and variable in '$ ipa ' > > This is due to a doc string with shell command examples, the $ > is the shell prompt. The validation code looks for $ followed by a word > token (these are template substitutions). We have a lot of variable and > template substitutions in our strings, any of which could be malformed > and cause serious run-time problems. I don't know of any way to have the > validation logic ignore the use of $ as a shell prompt without adding a > special case exception. Since shell prompts are rarity in strings my > suggestion would be to pick a different shell prompt character, > something other than $ and be done with the issue and not try to > over-engineer the validation logic. > > One more nitpick: Please add the generated po file & locale directory to .gitignore -- Petr? From rcritten at redhat.com Thu Mar 22 19:17:16 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 22 Mar 2012 15:17:16 -0400 Subject: [Freeipa-devel] [PATCH] 991/992 fix migration issues In-Reply-To: <1332412223.10439.14.camel@balmora.brq.redhat.com> References: <4F6943D2.2060005@redhat.com> <1332412223.10439.14.camel@balmora.brq.redhat.com> Message-ID: <4F6B7ABC.5040402@redhat.com> Martin Kosek wrote: > On Tue, 2012-03-20 at 22:58 -0400, Rob Crittenden wrote: >> Fix a couple of issues found with migration. I made a second patch just >> to keep things separate even though its just a one-liner. >> >> 991 fixes a problem where we have attributes which point to other >> entries and these weren't being migrated. This is things like secretary >> and manager. This was actually causing things to blow up badly. >> >> 992 makes the primary key lower-case to match the rest of IPA. >> >> I've attached an LDIF with a couple of users to demonstrate the fix. >> >> rob > > > 1) This is not very Pythonic: > + for ind in xrange(len(entry_attrs[attr])): > + value = entry_attrs[attr][ind] > > This would be better: > + for ind,value in enumerate(entry_attrs[attr]): > > 2) 992 lowers uid of users group, but you leave updated DNs > un-normalized, we may want to lower them as well: > > # ayaz_kreiger, users, accounts, idm.lab.bos.redhat.com > dn: uid=ayaz_kreiger,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=co > m > uid: ayaz_kreiger > ... > manager: uid=Mollee_Weisenberg,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=re > dhat,dc=com > manager: cn=Doesnot Exist,ou=People,dc=greyoak,dc=com > ... > > 3) We still crash if the DN does not exist (see above) and thus we don't > normalize it: > # ipa user-show ayaz_kreiger --allipa: ERROR: an internal error has > occurred > > I think we should use the change that came up when I was reviewing > Petr3's sudo patch: > diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py > index cf5d8d20eb27a0342f064086e0ee9d85c78c5bae..8f03a09827bd0ee6a08e594617ad8d4dff2b467b 100644 > --- a/ipalib/plugins/baseldap.py > +++ b/ipalib/plugins/baseldap.py > @@ -487,7 +487,15 @@ class LDAPObject(Object): > pass > # DN object assures we're returning a decoded (unescaped) value > dn = DN(dn) > - return dn[self.primary_key.name] > + try: > + return dn[self.primary_key.name] > + except KeyError: > + # The primary key is not in the DN. > + # This shouldn't happen, but we don't want a "show" command to > + # crash. > + # Just return the entire DN, it's all we have if the entry > + # doesn't exist > + return unicode(dn) > > 4) (minor) In function get_dn_syntax: > - if obj is None, the function will return None -> contradicts with the help > - I would name the function "is_dn_syntax" since we don't return DN syntax > > Martin > For 4 I added a None check. I only want this to return True/False. I don't want to get too clever and try to see if the value is a dn if we don't have schema for it. Updated patch atached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-991-2-migration.patch Type: text/x-diff Size: 4712 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 22 19:21:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 22 Mar 2012 15:21:03 -0400 Subject: [Freeipa-devel] [PATCH] 993 disable UPG for migration Message-ID: <4F6B7B9F.4080105@redhat.com> We don't want to create private groups automatically for migrated users, there could be namespace overlap (and race conditions prevent us from trying to check in advance). Check the sanity of groups in general, warn if the group for the gidnumber doesn't exist at least on the remote server. Fill in the user's shell as well. This will migrate users that are non-POSIX on the remote server. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-993-migration.patch Type: text/x-diff Size: 6569 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 22 20:51:17 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Mar 2012 21:51:17 +0100 Subject: [Freeipa-devel] [PATCH] 991/992 fix migration issues In-Reply-To: <4F6B7ABC.5040402@redhat.com> References: <4F6943D2.2060005@redhat.com> <1332412223.10439.14.camel@balmora.brq.redhat.com> <4F6B7ABC.5040402@redhat.com> Message-ID: <1332449477.17691.0.camel@priserak> On Thu, 2012-03-22 at 15:17 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Tue, 2012-03-20 at 22:58 -0400, Rob Crittenden wrote: > >> Fix a couple of issues found with migration. I made a second patch just > >> to keep things separate even though its just a one-liner. > >> > >> 991 fixes a problem where we have attributes which point to other > >> entries and these weren't being migrated. This is things like secretary > >> and manager. This was actually causing things to blow up badly. > >> > >> 992 makes the primary key lower-case to match the rest of IPA. > >> > >> I've attached an LDIF with a couple of users to demonstrate the fix. > >> > >> rob > > > > > > 1) This is not very Pythonic: > > + for ind in xrange(len(entry_attrs[attr])): > > + value = entry_attrs[attr][ind] > > > > This would be better: > > + for ind,value in enumerate(entry_attrs[attr]): > > > > 2) 992 lowers uid of users group, but you leave updated DNs > > un-normalized, we may want to lower them as well: > > > > # ayaz_kreiger, users, accounts, idm.lab.bos.redhat.com > > dn: uid=ayaz_kreiger,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=co > > m > > uid: ayaz_kreiger > > ... > > manager: uid=Mollee_Weisenberg,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=re > > dhat,dc=com > > manager: cn=Doesnot Exist,ou=People,dc=greyoak,dc=com > > ... > > > > 3) We still crash if the DN does not exist (see above) and thus we don't > > normalize it: > > # ipa user-show ayaz_kreiger --allipa: ERROR: an internal error has > > occurred > > > > I think we should use the change that came up when I was reviewing > > Petr3's sudo patch: > > diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py > > index cf5d8d20eb27a0342f064086e0ee9d85c78c5bae..8f03a09827bd0ee6a08e594617ad8d4dff2b467b 100644 > > --- a/ipalib/plugins/baseldap.py > > +++ b/ipalib/plugins/baseldap.py > > @@ -487,7 +487,15 @@ class LDAPObject(Object): > > pass > > # DN object assures we're returning a decoded (unescaped) value > > dn = DN(dn) > > - return dn[self.primary_key.name] > > + try: > > + return dn[self.primary_key.name] > > + except KeyError: > > + # The primary key is not in the DN. > > + # This shouldn't happen, but we don't want a "show" command to > > + # crash. > > + # Just return the entire DN, it's all we have if the entry > > + # doesn't exist > > + return unicode(dn) > > > > 4) (minor) In function get_dn_syntax: > > - if obj is None, the function will return None -> contradicts with the help > > - I would name the function "is_dn_syntax" since we don't return DN syntax > > > > Martin > > > > For 4 I added a None check. I only want this to return True/False. I > don't want to get too clever and try to see if the value is a dn if we > don't have schema for it. > > Updated patch atached. > > rob ACK. Pushed to master, ipa-2-2. Martin From jdennis at redhat.com Thu Mar 22 21:13:39 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 22 Mar 2012 17:13:39 -0400 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F6B767C.4000301@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> Message-ID: <4F6B9603.1070805@redhat.com> On 03/22/2012 02:59 PM, Petr Viktorin wrote: > On 03/22/2012 06:01 PM, John Dennis wrote: >> This addresses tickets 2044 and 1958. Ticket 2044 was on my short list >> but the code had already been written for ticket 1958 (validation of >> substitution variables). It had been sitting in my home directory >> waiting for integration so since the original 2044 ticket required me to >> update test_i18n.py it seemed like a perfect opportunity to get ticket >> 1958 done as well, it only added 2 hours of additional work. > > This is great! > >> Summary: >> >> In the install/po directory you can now do this: >> >> % make test >> % make validate >> >> Details (aside from what is in the commit message): >> >> Also attached (to prevent line wrapping) is an example of validating the >> Spanish translation. It gives a good example of the type of errors it's >> capable of finding. This is not abstract, mistakes like these caused us >> to throw errors in different locales and since we normally test only >> with English it's important to assure the other languages do not cause >> Python errors. >> >> We should consider adding the i18n validation to our top level >> validation logic so don't allow problems to creep in (our original >> non-translated strings are checked too and are just as capable of having >> errors as the translated strings). > > Errors in English strings should be caught by regular tests. But yes, if > we ship translations in the repo, the main test suite should check them. > (If it doesn't take minutes to run). > >> When I ran the validation on our complete set of files a lot of errors >> were reported for >> >> ipalib/plugins/hbactest.py:27 >> msgid has whitespace between $ and variable in '$ ipa ' >> >> This is due to a doc string with shell command examples, the $ >> is the shell prompt. The validation code looks for $ followed by a word >> token (these are template substitutions). We have a lot of variable and >> template substitutions in our strings, any of which could be malformed >> and cause serious run-time problems. I don't know of any way to have the >> validation logic ignore the use of $ as a shell prompt without adding a >> special case exception. Since shell prompts are rarity in strings my >> suggestion would be to pick a different shell prompt character, >> something other than $ and be done with the issue and not try to >> over-engineer the validation logic. > > No need to test this case -- if there's whitespace, it's not a shell > substitution. > If it's wrong in English, we should notice. Unfortunately reality is different, people make mistakes. In fact I've already had to fix a mistake like this previously. To the best of my knowledge we currently do not have anything which validates substitutions in the source code. There is actually very little difference in between pot files and po files. The syntax checker was originally written to validate po files, the po files derive from the pot file. If we can prevent errors from creeping into the pot file before each translator copies the error into their respective po file we've saved both ourselves and the translators work. So it makes sense to me to run the syntax checks on the pot file as well. > If it's wrong in another > language, it should be caught by checking if the translation contains > all necessary substitutions. In fact that is exactly one of the checks which are performed. But the check depends on it being correct in the pot file. If it's wrong in the pot file too we'll miss the error, another reason to validate the pot file as well. > (In fact, all these syntax tests are redundant. But they do make nice > error messages.) I don't understand how they are redundant. >> > > Some of the option parsing code is reinventing the wheel a bit. The rest > of the project uses optparse.OptionParser, it'd be nice to switch to that. > Particularly the global config dict is a bad idea. Don't assume all of > this will only ever run as a script. Give the constants their own > variables (and advertise that they're constants, as per > http://www.python.org/dev/peps/pep-0008/#constants). O.K. I can change how options are parsed (although getopt is a standard Python module). I can also modify how the parameters are stored but to my mind it makes perfect sense to have them be part of a configuration block (dict). If this code were ever used outside this script passing a config dict to control it would seem to make sense. Plus the idea was at some point we might want a command line option to change one of them, the approach is flexible in that regard. > > > In validate_substitutions_match, you may be over-validating. Why does a > given substitution need to appear the same number of times in both > strings? Making sure translators include all needed info is nice, but > outside of that, give them some freedom. O.K. good point, appearing the same number of times might be too restrictive. > > A nice sanity test I've seen in Qt is checking if the original and > translation strings end in the same punctuation ('.', '?', '!', ':'). > Would it make sense to implement that? I'm not sure about that, I'm not a linguist but different languages use different punctuation and order things differently. I'd rather leave that to the translator to get right. These checks are not designed to assure a translation is linguistically correct, rather their prime indent is to assure they are programatically correct. What we don't want is to throw exceptions at run time for a particular language because the translator mangled what is essentially program variables. I've chased down these run time problems more than once in both IPA and Dogtag (Certificate Server). I've seen cases where the entire application aborts because of a bad translation, we really want to catch those problems up front because our normal test procedures won't. > > > I saw some style issues, e.g.: > - in places such as this: > > raise ValueError("Translated string \"%s\" minus the first& last > character is not equal to msgid \"%s\"" % \ > > (translated.encode('utf-8'), msgid)) > > line continuation backslashes are unnecessary inside parentheses. > Also you can mix single and double quotes to avoid backslashes in strings. > - {'':'', '(':')', '{':'}'} should have spaces after the colons > - in entry_seperator = '-' * page_width there's too much whitespace Yes, all good style issues, I'll fix them. > > All of this is quite a lot of nontrivial code; some tests for the > validation itself would be nice. Agreed, but I'm not sure adding more work to this is appropriate. I suspect both Rob and Dmitri would suggest time is better spent elsewhere. > > > All in all, nice work! I hope I don't sound too negative, I really like > where this is going. > Thank you and thank you for a though review. I'll update the patch shortly to address the issues you raised. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu Mar 22 21:21:50 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 22 Mar 2012 17:21:50 -0400 Subject: [Freeipa-devel] [PATCH] 994 set nsslapd-minssf-exclude-rootdse Message-ID: <4F6B97EE.1090306@redhat.com> If minssf is set in configuration and this is not set then clients won't be able to detect the available namingContexts, defaultNamingContext, capabilities, etc. This was requested by the SSSD team. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-994-minssf.patch Type: text/x-diff Size: 1944 bytes Desc: not available URL: From jdennis at redhat.com Thu Mar 22 21:32:36 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 22 Mar 2012 17:32:36 -0400 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F6B767C.4000301@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> Message-ID: <4F6B9A74.2070500@redhat.com> On 03/22/2012 02:59 PM, Petr Viktorin wrote: > Some of the option parsing code is reinventing the wheel a bit. The rest > of the project uses optparse.OptionParser, it'd be nice to switch to that. Are you aware that optparse is deprecated in Python? argparse replaces it but is only available in Python >= 2.7 so that's not an option (no pun intended) I suppose I could convert to optparse for project consistency even if it's deprecated. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu Mar 22 22:04:12 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 22 Mar 2012 18:04:12 -0400 Subject: [Freeipa-devel] [PATCH] 240 Fix LDAP effective rights control with python-ldap 2.4.x In-Reply-To: <1332323347.4333.5.camel@balmora.brq.redhat.com> References: <1332320242.4333.1.camel@balmora.brq.redhat.com> <4F699C85.80505@redhat.com> <1332323347.4333.5.camel@balmora.brq.redhat.com> Message-ID: <4F6BA1DC.9030000@redhat.com> Martin Kosek wrote: > On Wed, 2012-03-21 at 10:16 +0100, Jan Cholasta wrote: >> On 21.3.2012 09:57, Martin Kosek wrote: >>> Test instructions are attached to the ticket. >>> --- >>> The new version of python-ldap changed the way it created LDAPv3 >>> extended controls. The API used in 2.4.x can no longer be used >>> because it does not send the bind DN with effective rights >>> control and LDAP server thus rejects it. >>> >>> This patch implements the new API in a backward compatible way >>> so that it works both with python-ldap versions 2.3.x and 2.4.x. >>> >>> https://fedorahosted.org/freeipa/ticket/2565 >>> >> >> IMO it would be nicer to handle things on module import rather than on >> each get effective rights request: >> >> @@ -42,7 +42,6 @@ import ldap as _ldap >> from ldap.ldapobject import SimpleLDAPObject >> import ldap.filter as _ldap_filter >> import ldap.sasl as _ldap_sasl >> -from ldap.controls import LDAPControl >> # for backward compatibility >> from ldap.functions import explode_dn >> from ipalib.dn import DN >> @@ -56,6 +55,14 @@ from ipalib.crud import CrudBackend >> from ipalib.encoder import Encoder, encode_args, decode_retval >> from ipalib.request import context >> >> +try: >> + from ldap.controls.simple import GetEffectiveRightsControl >> +except ImportError: >> + from ldap.controls import LDAPControl >> + class GetEffectiveRightsControl(LDAPControl): >> + def __init__(critical, value): >> + super(GetEffectiveRightsControl, >> self).__init__('1.3.6.1.4.1.42.2.27.9.5.2', critical, value) >> + >> # Group Member types >> MEMBERS_ALL = 0 >> MEMBERS_DIRECT = 1 >> @@ -871,7 +878,7 @@ class ldap2(CrudBackend, Encoder): >> """ >> principal = getattr(context, 'principal') >> (binddn, attrs) = self.find_entry_by_attr("krbprincipalname", >> principal, "krbPrincipalAux") >> - sctrl = [LDAPControl("1.3.6.1.4.1.42.2.27.9.5.2", True, "dn: " >> + binddn.encode('UTF-8'))] >> + sctrl = [GetEffectiveRightsControl(True, "dn: " + >> binddn.encode('UTF-8'))] >> self.conn.set_option(_ldap.OPT_SERVER_CONTROLS, sctrl) >> (dn, attrs) = self.get_entry(dn, entry_attrs) >> # remove the control so subsequent operations don't include GER >> >> Honza >> > > I agree, this approach is better. I updated the patch based on your > input. It just needed some more love as LDAPControl is an old-style > Python class and I also silenced pylint when python-ldap 2.3.x is > installed. > > Martin ACK, pushed to master and ipa-2-2 From jdennis at redhat.com Fri Mar 23 06:00:27 2012 From: jdennis at redhat.com (John Dennis) Date: Fri, 23 Mar 2012 02:00:27 -0400 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F6B767C.4000301@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> Message-ID: <4F6C117B.1090807@redhat.com> New patch attached which addresses Petr's review comments. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0066-1-Replace-broken-i18n-shell-test-with-Python-test.patch Type: text/x-patch Size: 25521 bytes Desc: not available URL: From abokovoy at redhat.com Fri Mar 23 08:21:05 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 23 Mar 2012 10:21:05 +0200 Subject: [Freeipa-devel] [PATCH] fix selinux configuration for httpd instance In-Reply-To: <4F6B37C4.4020606@redhat.com> References: <20120322132256.GD14086@redhat.com> <4F6B37C4.4020606@redhat.com> Message-ID: <20120323082105.GE14086@redhat.com> On Thu, 22 Mar 2012, Petr Viktorin wrote: >On 03/22/2012 02:22 PM, Alexander Bokovoy wrote: >>Hi, >> >>attached patch fixes the problem I see with master (and ipa-2-2): >> >>2012-03-22T10:58:34Z DEBUG args=/usr/sbin/setsebool -P >>httpd_can_network_connect=true httpd_manage_ipa=true >>2012-03-22T10:58:34Z DEBUG stdout= >>2012-03-22T10:58:34Z DEBUG stderr=setsebool: illegal value true >>httpd_manage_ipa=true for boolean httpd_can_network_connect >> > >I just ran into this too. The patch works fine, ACK Thanks. Pushed to master, ipa-2-2. -- / Alexander Bokovoy From pspacek at redhat.com Fri Mar 23 08:59:02 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Mar 2012 09:59:02 +0100 Subject: [Freeipa-devel] [PATCH] 0014 Fix crash on reload without any zones Message-ID: <4F6C3B56.7020604@redhat.com> Hello, this patch fixes crash on reload/halt. Current code will crash if no zones were loaded from LDAP (because of connection error or bad DN in config). There is no BZ/ticket for this issue. Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0014-Fix-crash-on-reload-without-any-zones.patch Type: text/x-patch Size: 1045 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 23 09:12:27 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Mar 2012 10:12:27 +0100 Subject: [Freeipa-devel] [PATCH] 993 disable UPG for migration In-Reply-To: <4F6B7B9F.4080105@redhat.com> References: <4F6B7B9F.4080105@redhat.com> Message-ID: <1332493947.17059.24.camel@balmora.brq.redhat.com> On Thu, 2012-03-22 at 15:21 -0400, Rob Crittenden wrote: > We don't want to create private groups automatically for migrated users, > there could be namespace overlap (and race conditions prevent us from > trying to check in advance). > > Check the sanity of groups in general, warn if the group for the > gidnumber doesn't exist at least on the remote server. > > Fill in the user's shell as well. > > This will migrate users that are non-POSIX on the remote server. > > rob This patch fixes the problem of creating UPGs for migrated users, but there are several parts which confused me. 1) Confusing defaults + if 'def_group_gid' in ctx: + entry_attrs.setdefault('gidnumber', ctx['def_group_gid']) This statement seems redundant, because the account either is posix and has both uidnumber and gidnumber or it is non-posix and does not have any. Now, we don't touch gidNumber for posix user, and non-posix users are made posix with this statement: + # migrated user is not already POSIX, make it so + if 'uidnumber' not in entry_attrs: + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] 2) Missing UPG When UPG is disabled, the following statement will result in a user with a GID pointing to non-existent group. + # migrated user is not already POSIX, make it so + if 'uidnumber' not in entry_attrs: + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] We may want to run ldap.has_upg() and report a add this user to "failed users" with appropriate error. 3) Check for GID The patch implements a check if a group with the gidNumber exists on a remote LDAP server and the result is a warning: - (g_dn, g_attrs) = ldap.get_entry(ctx['def_group_dn'], ['gidnumber']) + (remote_dn, remote_entry) = ds_ldap.find_entry_by_attr( + 'gidnumber', entry_attrs['gidnumber'][0], 'posixgroup', [''], + search_bases['group'] + ) I have few (minor-ish) questions there: a) Is the warning in a apache log enough? Maybe it should be included in migrate-ds output. b) This will be a one more remote LDAP call for every user, we may want to optimize it with something like that: valid_gids = [] if user.gidnumber not in valid_gids: run the check in remote LDAP valid_gids.append(user.gidnumber) That would save us 999 LDAP queries for 1000 migrated with the same primary group. 4) Extraneous Warning: When non-posix user is migrated and thus we make it a posix user, we still produce a warning for non-existent group: [Fri Mar 23 04:21:36 2012] [error] ipa: WARNING: Migrated user's GID number 999 does not point to a known group. 5) Extraneous LDAP call Isn't the following call to LDAP to get a description redundant? We already have the description in entry_attrs. + (dn, desc_attr) = ldap.get_entry(dn, ['description']) + entry_attrs.update(desc_attr) + if 'description' in entry_attrs and NO_UPG_MAGIC in entry_attrs['description']: Martin From mkosek at redhat.com Fri Mar 23 09:17:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Mar 2012 10:17:49 +0100 Subject: [Freeipa-devel] [PATCH] 0014 Fix crash on reload without any zones In-Reply-To: <4F6C3B56.7020604@redhat.com> References: <4F6C3B56.7020604@redhat.com> Message-ID: <1332494269.17059.27.camel@balmora.brq.redhat.com> On Fri, 2012-03-23 at 09:59 +0100, Petr Spacek wrote: > Hello, > > this patch fixes crash on reload/halt. Current code will crash if no > zones were loaded from LDAP (because of connection error or bad DN in > config). > > There is no BZ/ticket for this issue. > > Petr^2 Spacek This one may be related: https://bugzilla.redhat.com/show_bug.cgi?id=802375 This is a bug for psearch, but I know that shanks reproduced the crash when psearch was disabled as well. Martin From pspacek at redhat.com Fri Mar 23 09:24:17 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Mar 2012 10:24:17 +0100 Subject: [Freeipa-devel] [PATCH] 0014 Fix crash on reload without any zones In-Reply-To: <1332494269.17059.27.camel@balmora.brq.redhat.com> References: <4F6C3B56.7020604@redhat.com> <1332494269.17059.27.camel@balmora.brq.redhat.com> Message-ID: <4F6C4141.8000809@redhat.com> On 03/23/2012 10:17 AM, Martin Kosek wrote: > On Fri, 2012-03-23 at 09:59 +0100, Petr Spacek wrote: >> Hello, >> >> this patch fixes crash on reload/halt. Current code will crash if no >> zones were loaded from LDAP (because of connection error or bad DN in >> config). >> >> There is no BZ/ticket for this issue. >> >> Petr^2 Spacek > > This one may be related: > > https://bugzilla.redhat.com/show_bug.cgi?id=802375 > > This is a bug for psearch, but I know that shanks reproduced the crash > when psearch was disabled as well. > > Martin BZ 802375 is definitely different issue. (I now it, because I fixed both issues :-) Petr^2 Spacek From mkosek at redhat.com Fri Mar 23 09:33:37 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Mar 2012 10:33:37 +0100 Subject: [Freeipa-devel] [PATCH] 234 Avoid deleting DNS zone when a context is reused In-Reply-To: <1331215056.11911.1.camel@balmora.brq.redhat.com> References: <1331215056.11911.1.camel@balmora.brq.redhat.com> Message-ID: <1332495217.17059.29.camel@balmora.brq.redhat.com> On Thu, 2012-03-08 at 14:57 +0100, Martin Kosek wrote: > When dnsrecord-del pre_callback detects that the record does > not contain any records, it set a flag to connection context > and deletes the record object later. However, when more > dnsrecord-del share the same context (and this is the case of > "ipa-replica-manage del $MASTER" DNS cleanup), it may reuse > a positive flag from previous dnsrecord-del command and delete > the root DNS zone record and thus effectively delete the zone. > > This patch makes sure that this flag is always initialized to > sane value in dnsrecord-del pre_callback to make sure that the DNS > zone is not deleted. It also fixes pre_callback function definition > to prevent adding attrs_list to "keys" parameter and thus confuse > developers. > > https://fedorahosted.org/freeipa/ticket/2503 Sending a rebased patch which applies to current ipa-2-2. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-234-2-avoid-deleting-dns-zone-when-a-context-is-reused.patch Type: text/x-patch Size: 2693 bytes Desc: not available URL: From jcholast at redhat.com Fri Mar 23 09:43:06 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 23 Mar 2012 10:43:06 +0100 Subject: [Freeipa-devel] [PATCH] 71 Propagate SIGINT to child process in ipautil.run In-Reply-To: <1332430507.2466.2.camel@balmora.brq.redhat.com> References: <4F68B4ED.4040001@redhat.com> <1332430507.2466.2.camel@balmora.brq.redhat.com> Message-ID: <4F6C45AA.6090106@redhat.com> On 22.3.2012 16:35, Martin Kosek wrote: > On Tue, 2012-03-20 at 17:48 +0100, Jan Cholasta wrote: >> Propagate SIGINT to child process in ipautil.run. >> >> Wait for the child process to terminate before continuing. >> >> Do cleanup on KeyboardInterrupt rather than in custom SIGINT handler in >> ipa-replica-conncheck. >> >> https://fedorahosted.org/freeipa/ticket/2127 >> >> Honza > > This looks and works OK, I have just one minor issue. Isn't the extra > p.wait() you added to the standard run() path redundant? p.communicate() > should do the job of waiting until the child process terminates. > > + try: > + p = subprocess.Popen(args, stdin=p_in, stdout=p_out, > stderr=p_err, > + close_fds=True, env=env) > + stdout,stderr = p.communicate(stdin) > + stdout,stderr = str(stdout), str(stderr) # Make pylint happy > + p.wait() > + except KeyboardInterrupt: > You are of course right, I guess I should read documentation more carefully. > Martin > Also, SIGINT is already propagated to the child process, we just need to wait for it to terminate. Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-71.1-propagate-sigint.patch Type: text/x-patch Size: 3435 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 23 09:59:42 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 23 Mar 2012 10:59:42 +0100 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F6B9603.1070805@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> <4F6B9603.1070805@redhat.com> Message-ID: <4F6C498E.3040907@redhat.com> On 03/22/2012 10:13 PM, John Dennis wrote: > On 03/22/2012 02:59 PM, Petr Viktorin wrote: >> On 03/22/2012 06:01 PM, John Dennis wrote: .. snip .. >> >>> When I ran the validation on our complete set of files a lot of errors >>> were reported for >>> >>> ipalib/plugins/hbactest.py:27 >>> msgid has whitespace between $ and variable in '$ ipa ' >>> >>> This is due to a doc string with shell command examples, the $ >>> is the shell prompt. The validation code looks for $ followed by a word >>> token (these are template substitutions). We have a lot of variable and >>> template substitutions in our strings, any of which could be malformed >>> and cause serious run-time problems. I don't know of any way to have the >>> validation logic ignore the use of $ as a shell prompt without adding a >>> special case exception. Since shell prompts are rarity in strings my >>> suggestion would be to pick a different shell prompt character, >>> something other than $ and be done with the issue and not try to >>> over-engineer the validation logic. >> >> No need to test this case -- if there's whitespace, it's not a shell >> substitution. >> If it's wrong in English, we should notice. > > Unfortunately reality is different, people make mistakes. In fact I've > already had to fix a mistake like this previously. To the best of my > knowledge we currently do not have anything which validates > substitutions in the source code. > > There is actually very little difference in between pot files and po > files. The syntax checker was originally written to validate po files, > the po files derive from the pot file. If we can prevent errors from > creeping into the pot file before each translator copies the error into > their respective po file we've saved both ourselves and the translators > work. So it makes sense to me to run the syntax checks on the pot file > as well. > The problem is that the messages are validated as if anything that looks like a substitution would be substituted, regardless of actual usage. There can be false positives, requiring workarounds just to make the tests pass. Having to use a non-obvious shell prompt is a good example. I'd like to keep the potential false positives to a minimum. Shell substitution with a "bare" variable doesn't even occur in our messages. I haven't seen $(var) either. Are these really necessary? You can't catch all possible cases where an exception might be raised. For example I can add '%,' or even an extra '%s' into a string, which the validator won't catch. For this reason I'd prefer, for English, beefing up regular tests rather than running heuristic validation after the context is lost. >> If it's wrong in another >> language, it should be caught by checking if the translation contains >> all necessary substitutions. > > In fact that is exactly one of the checks which are performed. But the > check depends on it being correct in the pot file. If it's wrong in the > pot file too we'll miss the error, another reason to validate the pot > file as well. >> (In fact, all these syntax tests are redundant. But they do make nice >> error messages.) > > I don't understand how they are redundant. My reasoning was that English should be validated by other tests, and translations by checking if the same substitutions occur. But I'm willing to accept that the existing tests aren't adequate. >>> >> >> Some of the option parsing code is reinventing the wheel a bit. The rest >> of the project uses optparse.OptionParser, it'd be nice to switch to >> that. >> Particularly the global config dict is a bad idea. Don't assume all of >> this will only ever run as a script. Give the constants their own >> variables (and advertise that they're constants, as per >> http://www.python.org/dev/peps/pep-0008/#constants). > > O.K. I can change how options are parsed (although getopt is a standard > Python module). I can also modify how the parameters are stored but to > my mind it makes perfect sense to have them be part of a configuration > block (dict). If this code were ever used outside this script passing a > config dict to control it would seem to make sense. Plus the idea was at > some point we might want a command line option to change one of them, > the approach is flexible in that regard. Optparse is also a standard module, and although deprecated, it's much better than getopt for this purpose. OptionParser gives you an "options" object that you can pass around, exactly as you describe -- except it's not a global variable, so e.g. changing things won't affect subsequent runs. About optparse deprecation -- the reason to deprecate it was that its API isn't very extensible, but since we don't extend it we might as well continue with it for now. The switch is relatively straightforward if/when we want to do it. Argparse is not standard in Python <=2.6, so we'd need another external dependency if we want to use it. >> In validate_substitutions_match, you may be over-validating. Why does a >> given substitution need to appear the same number of times in both >> strings? Making sure translators include all needed info is nice, but >> outside of that, give them some freedom. > > O.K. good point, appearing the same number of times might be too > restrictive. > >> >> A nice sanity test I've seen in Qt is checking if the original and >> translation strings end in the same punctuation ('.', '?', '!', ':'). >> Would it make sense to implement that? > > I'm not sure about that, I'm not a linguist but different languages use > different punctuation and order things differently. I'd rather leave > that to the translator to get right. > > These checks are not designed to assure a translation is linguistically > correct, rather their prime indent is to assure they are programatically > correct. What we don't want is to throw exceptions at run time for a > particular language because the translator mangled what is essentially > program variables. I've chased down these run time problems more than > once in both IPA and Dogtag (Certificate Server). I've seen cases where > the entire application aborts because of a bad translation, we really > want to catch those problems up front because our normal test procedures > won't. Right, I understand the scope now. This is better left as Transifex warnings, if they have those. >> I saw some style issues, e.g.: >> - in places such as this: >> > raise ValueError("Translated string \"%s\" minus the first& last >> character is not equal to msgid \"%s\"" % \ >> > (translated.encode('utf-8'), msgid)) >> >> line continuation backslashes are unnecessary inside parentheses. >> Also you can mix single and double quotes to avoid backslashes in >> strings. >> - {'':'', '(':')', '{':'}'} should have spaces after the colons After colons only, not before {'': '', '(': ')', '{': '}'} >> - in entry_seperator = '-' * page_width there's too much whitespace > > Yes, all good style issues, I'll fix them. > >> >> All of this is quite a lot of nontrivial code; some tests for the >> validation itself would be nice. > > Agreed, but I'm not sure adding more work to this is appropriate. I > suspect both Rob and Dmitri would suggest time is better spent elsewhere. I suspect otherwise, there was a push for better testing recently. Better ask them directly, though. >> All in all, nice work! I hope I don't sound too negative, I really like >> where this is going. >> > > Thank you and thank you for a though review. I'll update the patch > shortly to address the issues you raised. > More nitpicks: Please add the generated files to .gitignore > print >>sys.stderr, "ERROR: you may not select -c or -t when validating substitutions" Why not? Wouldn't it make sense to run all the tests at once? If -s is given with no arguments, could it validate all .po files in the translation directory? -- Petr? From mkosek at redhat.com Fri Mar 23 10:00:12 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Mar 2012 11:00:12 +0100 Subject: [Freeipa-devel] [PATCH] 71 Propagate SIGINT to child process in ipautil.run In-Reply-To: <4F6C45AA.6090106@redhat.com> References: <4F68B4ED.4040001@redhat.com> <1332430507.2466.2.camel@balmora.brq.redhat.com> <4F6C45AA.6090106@redhat.com> Message-ID: <1332496812.17059.32.camel@balmora.brq.redhat.com> On Fri, 2012-03-23 at 10:43 +0100, Jan Cholasta wrote: > On 22.3.2012 16:35, Martin Kosek wrote: > > On Tue, 2012-03-20 at 17:48 +0100, Jan Cholasta wrote: > >> Propagate SIGINT to child process in ipautil.run. > >> > >> Wait for the child process to terminate before continuing. > >> > >> Do cleanup on KeyboardInterrupt rather than in custom SIGINT handler in > >> ipa-replica-conncheck. > >> > >> https://fedorahosted.org/freeipa/ticket/2127 > >> > >> Honza > > > > This looks and works OK, I have just one minor issue. Isn't the extra > > p.wait() you added to the standard run() path redundant? p.communicate() > > should do the job of waiting until the child process terminates. > > > > + try: > > + p = subprocess.Popen(args, stdin=p_in, stdout=p_out, > > stderr=p_err, > > + close_fds=True, env=env) > > + stdout,stderr = p.communicate(stdin) > > + stdout,stderr = str(stdout), str(stderr) # Make pylint happy > > + p.wait() > > + except KeyboardInterrupt: > > > > You are of course right, I guess I should read documentation more carefully. > > > Martin > > > > Also, SIGINT is already propagated to the child process, we just need to > wait for it to terminate. Yeah, with p.wait() there is also no left-over in a form of zombie process. > > Updated patch attached. > > Honza > ACK. Pushed to master, ipa-2-2. Martin From atkac at redhat.com Fri Mar 23 10:58:24 2012 From: atkac at redhat.com (Adam Tkac) Date: Fri, 23 Mar 2012 11:58:24 +0100 Subject: [Freeipa-devel] [PATCH] 0013 Fix SOA record update In-Reply-To: <4F6B44D1.2060502@redhat.com> References: <4F6B44D1.2060502@redhat.com> Message-ID: <4F6C5750.7090505@redhat.com> On 03/22/2012 04:27 PM, Petr Spacek wrote: > Hello, Hello, > > this patch fixes wrong SOA updates during DNS zone dynamic update (via > nsupdate). > > It fixes LDAP plugin part of BZ: > https://bugzilla.redhat.com/show_bug.cgi?id=805871 Good catch, the patch looks fine for me, please check my comments and then push it. Regards, Adam > > Incorrect SOA serial number format after IPA installation has to be > solved in IPA install scripts. > > Petr^2 Spacek > > bind-dyndb-ldap-pspacek-0013-Fix-SOA-record-update.patch > > > From f40423b30a0d62dcef9ba4962e4b3d2ece1a0ded Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 22 Mar 2012 16:15:56 +0100 > Subject: [PATCH] Fix SOA record update. Signed-off-by: Petr Spacek > > > --- > src/ldap_helper.c | 15 ++++++++++++--- > 1 files changed, 12 insertions(+), 3 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 971d90f..bbdb388 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -47,6 +47,7 @@ > #include > #include > #include > +#include > > #include > #define LDAP_DEPRECATED 1 > @@ -2167,6 +2168,7 @@ static isc_result_t > modify_soa_record(ldap_connection_t *ldap_conn, const char *zone_dn, > dns_rdata_t *rdata) > { > + isc_result_t result; > isc_mem_t *mctx = ldap_conn->mctx; > dns_rdata_soa_t soa; > LDAPMod change[5]; > @@ -2175,13 +2177,16 @@ modify_soa_record(ldap_connection_t *ldap_conn, const char *zone_dn, > NULL > }; > > +/* all values in SOA record are isc_uint32_t, i.e. max. 2^32-1 */ > +#define MAX_SOANUM_LENGTH 10 What about defining this to 11? After that you can omit "+ 1" additions below. > #define SET_LDAP_MOD(index, name) \ > change[index].mod_op = LDAP_MOD_REPLACE; \ > change[index].mod_type = "idnsSOA" #name; \ > change[index].mod_values = alloca(2 * sizeof(char *)); \ > - change[index].mod_values[0] = alloca(sizeof(soa.name) + 1); \ > + change[index].mod_values[0] = alloca((MAX_SOANUM_LENGTH + 1)*sizeof(char)); \ Although this is correct, I don't think that "*sizeof(char)" is needed, please remove it. > change[index].mod_values[1] = NULL; \ > - snprintf(change[index].mod_values[0], sizeof(soa.name) + 1, "%d", soa.name) > + CHECK(isc_string_printf(change[index].mod_values[0], \ > + (MAX_SOANUM_LENGTH + 1)*sizeof(char), "%u", soa.name)); Ditto. > > dns_rdata_tostruct(rdata, (void *)&soa, mctx); > > @@ -2193,8 +2198,12 @@ modify_soa_record(ldap_connection_t *ldap_conn, const char *zone_dn, > > dns_rdata_freestruct((void *)&soa); > > - return ldap_modify_do(ldap_conn, zone_dn, changep, ISC_FALSE); > + result = ldap_modify_do(ldap_conn, zone_dn, changep, ISC_FALSE); > + > +cleanup: > + return result; > > +#undef MAX_SOANUM_LENGTH > #undef SET_LDAP_MOD > } > From atkac at redhat.com Fri Mar 23 11:25:40 2012 From: atkac at redhat.com (Adam Tkac) Date: Fri, 23 Mar 2012 12:25:40 +0100 Subject: [Freeipa-devel] [PATCH] 0014 Fix crash on reload without any zones In-Reply-To: <4F6C3B56.7020604@redhat.com> References: <4F6C3B56.7020604@redhat.com> Message-ID: <4F6C5DB4.2000007@redhat.com> On 03/23/2012 09:59 AM, Petr Spacek wrote: > Hello, > > this patch fixes crash on reload/halt. Current code will crash if no > zones were loaded from LDAP (because of connection error or bad DN in > config). > > There is no BZ/ticket for this issue. This patch is fine and fixes https://bugzilla.redhat.com/show_bug.cgi?id=805814 Before you push it, please add comment to code that there still might be issues with the RUNTIME_CHECK when nodechain_first returns ISC_R_NOMEMORY. Regards, Adam > > Petr^2 Spacek > > bind-dyndb-ldap-pspacek-0014-Fix-crash-on-reload-without-any-zones.patch > > > From 4f10354d7dcff6bff7421cc4594ec06da32da765 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 23 Mar 2012 09:50:44 +0100 > Subject: [PATCH] Fix crash on reload without any zones. Signed-off-by: Petr > Spacek > > --- > src/ldap_helper.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 971d90f..e9ed7ca 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -504,9 +504,10 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > rbt = zr_get_rbt(ldap_inst->zone_register); > > result = dns_rbtnodechain_first(&chain, rbt, NULL, NULL); > - RUNTIME_CHECK(result == ISC_R_SUCCESS || result == DNS_R_NEWORIGIN); > + RUNTIME_CHECK(result == ISC_R_SUCCESS || result == DNS_R_NEWORIGIN > + || result == ISC_R_NOTFOUND); > > - while (result != ISC_R_NOMORE) { > + while (result != ISC_R_NOMORE&& result != ISC_R_NOTFOUND) { > dns_fixedname_t name; > dns_fixedname_init(&name); > result = dns_rbtnodechain_current(&chain, NULL, From pspacek at redhat.com Fri Mar 23 11:38:36 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Mar 2012 12:38:36 +0100 Subject: [Freeipa-devel] [PATCH] 0014 Fix crash on reload without any zones In-Reply-To: <4F6C5DB4.2000007@redhat.com> References: <4F6C3B56.7020604@redhat.com> <4F6C5DB4.2000007@redhat.com> Message-ID: <4F6C60BC.4030605@redhat.com> On 03/23/2012 12:25 PM, Adam Tkac wrote: > On 03/23/2012 09:59 AM, Petr Spacek wrote: >> Hello, >> >> this patch fixes crash on reload/halt. Current code will crash if no >> zones were loaded from LDAP (because of connection error or bad DN in >> config). >> >> There is no BZ/ticket for this issue. > > This patch is fine and fixes > https://bugzilla.redhat.com/show_bug.cgi?id=805814 > > Before you push it, please add comment to code that there still might be > issues with the RUNTIME_CHECK when nodechain_first returns ISC_R_NOMEMORY. > > Regards, Adam Comment added, pushed to master. https://fedorahosted.org/bind-dyndb-ldap/changeset/f35661ac8fd7fe3a778ad95fc5135bf332230453 Note: BZ 805814 was reported after patch was sent to list :-) >> Petr^2 Spacek >> >> bind-dyndb-ldap-pspacek-0014-Fix-crash-on-reload-without-any-zones.patch >> >> >> From 4f10354d7dcff6bff7421cc4594ec06da32da765 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Fri, 23 Mar 2012 09:50:44 +0100 >> Subject: [PATCH] Fix crash on reload without any zones. Signed-off-by: >> Petr >> Spacek >> >> --- >> src/ldap_helper.c | 5 +++-- >> 1 files changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/src/ldap_helper.c b/src/ldap_helper.c >> index 971d90f..e9ed7ca 100644 >> --- a/src/ldap_helper.c >> +++ b/src/ldap_helper.c >> @@ -504,9 +504,10 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) >> rbt = zr_get_rbt(ldap_inst->zone_register); >> >> result = dns_rbtnodechain_first(&chain, rbt, NULL, NULL); >> - RUNTIME_CHECK(result == ISC_R_SUCCESS || result == DNS_R_NEWORIGIN); >> + RUNTIME_CHECK(result == ISC_R_SUCCESS || result == DNS_R_NEWORIGIN >> + || result == ISC_R_NOTFOUND); >> >> - while (result != ISC_R_NOMORE) { >> + while (result != ISC_R_NOMORE&& result != ISC_R_NOTFOUND) { >> dns_fixedname_t name; >> dns_fixedname_init(&name); >> result = dns_rbtnodechain_current(&chain, NULL, > -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0014-Fix-crash-on-reload-without-any-zones.patch Type: text/x-patch Size: 1305 bytes Desc: not available URL: From pspacek at redhat.com Fri Mar 23 12:18:11 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Mar 2012 13:18:11 +0100 Subject: [Freeipa-devel] [PATCH] 0013 Fix SOA record update In-Reply-To: <4F6C5750.7090505@redhat.com> References: <4F6B44D1.2060502@redhat.com> <4F6C5750.7090505@redhat.com> Message-ID: <4F6C6A03.4030001@redhat.com> On 03/23/2012 11:58 AM, Adam Tkac wrote: > On 03/22/2012 04:27 PM, Petr Spacek wrote: >> this patch fixes wrong SOA updates during DNS zone dynamic update (via >> nsupdate). >> >> It fixes LDAP plugin part of BZ: >> https://bugzilla.redhat.com/show_bug.cgi?id=805871 > > Good catch, the patch looks fine for me, please check my comments and > then push it. > > Regards, Adam >> >> Incorrect SOA serial number format after IPA installation has to be >> solved in IPA install scripts. >> >> Petr^2 Spacek >> >> bind-dyndb-ldap-pspacek-0013-Fix-SOA-record-update.patch >> +#define MAX_SOANUM_LENGTH 10 > What about defining this to 11? After that you can omit "+ 1" additions > below. (10 + 1) applied. >> - change[index].mod_values[0] = alloca(sizeof(soa.name) + 1); \ >> + change[index].mod_values[0] = alloca((MAX_SOANUM_LENGTH + >> 1)*sizeof(char)); \ > Although this is correct, I don't think that "*sizeof(char)" is needed, > please remove it. I'm probably too paranoid :-) Recommended changes applied, pushed to master. https://fedorahosted.org/bind-dyndb-ldap/changeset/709e352e52141eac346139666483b5c5f5acd713 Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0013-Fix-SOA-record-update.patch Type: text/x-patch Size: 2033 bytes Desc: not available URL: From sbose at redhat.com Fri Mar 23 12:52:34 2012 From: sbose at redhat.com (Sumit Bose) Date: Fri, 23 Mar 2012 13:52:34 +0100 Subject: [Freeipa-devel] [PATCH] 18 Add external domain extop DS plugin Message-ID: <20120323125234.GU2301@localhost.localdomain> Hi, these two patches introduce a new extended operation to the IPA server which can be used by clients in the IPA domain to obtain information about users and groups from trusted domains. Currently this exop is used by the sssd sub-domain patch to map user names from a trusted AD domain to a SID and back. There is also some code for other kind of requests which might become useful in future, e.g. with trusted IPA domain. I added some unit test and added check for the check unit test framework for C (http://check.sourceforge.net/) which is used by sssd as well. I modified the spec file that the test is run during the build of the packages. I hope this is ok. The patches depend on the idmap library patch which was ACKed recently on sssd-devel and as mentioned before the sub-domain patches on sssd-devel can only be fully tested with an IPA server which has these patches applied. Since Alexander is currently rewriting parts of the ipa-adtrust-install utility I stand back from adding activation code for the exop to ipa-adtrust-install and will send a patch when Alexander's changes are available. So currently extdom-extop-conf.ldif has to be loaded manually after replacing $SUFFIX to activate the new exop. bye, Sumit -------------- next part -------------- From ff00f23bde3615287aec9de789f00831d417b2d8 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 12 Dec 2011 11:32:06 +0100 Subject: [PATCH 1/2] Add configure check for C Unit-Test framework check The framework can be found at http://check.sourceforge.net. --- daemons/configure.ac | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/daemons/configure.ac b/daemons/configure.ac index deaa47358445fa552f5a9b53c9b65a9550b71d9e..547c907f3c6327507e7b01f7642c7db4a7409391 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -240,6 +240,16 @@ PKG_CHECK_MODULES([SAMBAUTIL], [samba-util]) SAMBA40EXTRA_LIBPATH="-L`$PKG_CONFIG --variable=libdir samba-util`/samba" AC_SUBST(SAMBA40EXTRA_LIBPATH) +dnl --------------------------------------------------------------------------- +dnl - Check for check unit test framework http://check.sourceforge.net/ +dnl --------------------------------------------------------------------------- +PKG_CHECK_MODULES([CHECK], [check >= 0.9.5], [have_check=1], [have_check=]) +if test x$have_check = x; then + AC_MSG_WARN([Without the 'CHECK' library, you will be unable to run all tests in the 'make check' suite]) +else + AC_CHECK_HEADERS([check.h],,AC_MSG_ERROR([Could not find CHECK headers])) +fi +AM_CONDITIONAL([HAVE_CHECK], [test x$have_check != x]) dnl --------------------------------------------------------------------------- dnl - Set the data install directory since we don't use pkgdatadir -- 1.7.6 -------------- next part -------------- From 1fa39217d2875460793800312cd769bae5f2c084 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 30 Nov 2011 13:29:10 +0100 Subject: [PATCH 2/2] Add external domain extop DS plugin This extop can be used by clients of the IPA domain, e.g. sssd, to retrieve data from trusted external domains. It can be used e.g. to map Windows SIDs to user or groups names and back. --- daemons/configure.ac | 7 + daemons/ipa-slapi-plugins/Makefile.am | 1 + .../ipa-slapi-plugins/ipa-extdom-extop/Makefile.am | 74 +++ .../ipa-extdom-extop/extdom-extop-conf.ldif | 16 + .../ipa-extdom-extop/ipa_extdom.h | 153 ++++++ .../ipa-extdom-extop/ipa_extdom_common.c | 498 ++++++++++++++++++++ .../ipa-extdom-extop/ipa_extdom_extop.c | 236 +++++++++ .../ipa-extdom-extop/ipa_extdom_tests.c | 203 ++++++++ freeipa.spec.in | 8 + 9 files changed, 1196 insertions(+), 0 deletions(-) create mode 100644 daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am create mode 100644 daemons/ipa-slapi-plugins/ipa-extdom-extop/README create mode 100644 daemons/ipa-slapi-plugins/ipa-extdom-extop/extdom-extop-conf.ldif create mode 100644 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h create mode 100644 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c create mode 100644 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c create mode 100644 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_tests.c diff --git a/daemons/configure.ac b/daemons/configure.ac index 547c907f3c6327507e7b01f7642c7db4a7409391..cc66b0137c00aca4b5dcce3d5e0bc81927a19052 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -238,6 +238,7 @@ PKG_CHECK_MODULES([NDRNBT], [ndr_nbt]) PKG_CHECK_MODULES([NDR], [ndr]) PKG_CHECK_MODULES([SAMBAUTIL], [samba-util]) SAMBA40EXTRA_LIBPATH="-L`$PKG_CONFIG --variable=libdir samba-util`/samba" +PKG_CHECK_MODULES([WBCLIENT], [wbclient]) AC_SUBST(SAMBA40EXTRA_LIBPATH) dnl --------------------------------------------------------------------------- @@ -251,6 +252,11 @@ else fi AM_CONDITIONAL([HAVE_CHECK], [test x$have_check != x]) +dnl -- dirsrv is needed for the extdom unit tests -- +PKG_CHECK_MODULES([DIRSRV], [dirsrv]) +dnl -- sss_idmap is needed by the extdom exop -- +PKG_CHECK_MODULES([SSSIDMAP], [sss_idmap]) + dnl --------------------------------------------------------------------------- dnl - Set the data install directory since we don't use pkgdatadir dnl --------------------------------------------------------------------------- @@ -320,6 +326,7 @@ AC_CONFIG_FILES([ ipa-slapi-plugins/ipa-enrollment/Makefile ipa-slapi-plugins/ipa-lockout/Makefile ipa-slapi-plugins/ipa-pwd-extop/Makefile + ipa-slapi-plugins/ipa-extdom-extop/Makefile ipa-slapi-plugins/ipa-winsync/Makefile ipa-slapi-plugins/ipa-version/Makefile ipa-slapi-plugins/ipa-uuid/Makefile diff --git a/daemons/ipa-slapi-plugins/Makefile.am b/daemons/ipa-slapi-plugins/Makefile.am index 29b985e69424c9f2ce453ea3607cdb0e936bcce2..01b8bc330bb9525b54ac3e0493e311d2cafb64e7 100644 --- a/daemons/ipa-slapi-plugins/Makefile.am +++ b/daemons/ipa-slapi-plugins/Makefile.am @@ -6,6 +6,7 @@ SUBDIRS = \ ipa-lockout \ ipa-modrdn \ ipa-pwd-extop \ + ipa-extdom-extop \ ipa-uuid \ ipa-version \ ipa-winsync \ diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am new file mode 100644 index 0000000000000000000000000000000000000000..39eac722143c718c13337990689d00f1d48d9435 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am @@ -0,0 +1,74 @@ +NULL = + +PLUGIN_COMMON_DIR=../common + +INCLUDES = \ + -I. \ + -I$(srcdir) \ + -I$(PLUGIN_COMMON_DIR) \ + -I$(KRB5_UTIL_DIR) \ + -I$(COMMON_BER_DIR) \ + -DPREFIX=\""$(prefix)"\" \ + -DBINDIR=\""$(bindir)"\" \ + -DLIBDIR=\""$(libdir)"\" \ + -DLIBEXECDIR=\""$(libexecdir)"\" \ + -DDATADIR=\""$(datadir)"\" \ + $(AM_CFLAGS) \ + $(LDAP_CFLAGS) \ + $(WBCLIENT_CFLAGS) \ + $(WARN_CFLAGS) \ + $(SSSIDMAP_CFLAGS) \ + $(NULL) + +plugindir = $(libdir)/dirsrv/plugins +plugin_LTLIBRARIES = \ + libipa_extdom_extop.la \ + $(NULL) + +libipa_extdom_extop_la_SOURCES = \ + ipa_extdom_extop.c \ + ipa_extdom_common.c \ + $(NULL) + +libipa_extdom_extop_la_LDFLAGS = -avoid-version + +libipa_extdom_extop_la_LIBADD = \ + $(LDAP_LIBS) \ + $(WBCLIENT_LIBS) \ + $(SSSIDMAP_LIBS) \ + $(NULL) + +if HAVE_CHECK +TESTS = extdom_tests +check_PROGRAMS = extdom_tests +endif + +extdom_tests_SOURCES = \ + ipa_extdom_tests.c \ + ipa_extdom_common.c \ + $(NULL) +extdom_tests_CFLAGS = $(CHECK_CFLAGS) +extdom_tests_LDFLAGS = \ + -rpath $(shell pkg-config --libs-only-L dirsrv | sed -e 's/-L//') \ + $(NULL) +extdom_tests_LDADD = \ + $(CHECK_LIBS) \ + $(LDAP_LIBS) \ + $(WBCLIENT_LIBS) \ + $(DIRSRV_LIBS) \ + $(SSSIDMAP_LIBS) \ + $(NULL) + +appdir = $(IPA_DATA_DIR) +app_DATA = \ + extdom-extop-conf.ldif \ + $(NULL) + +EXTRA_DIST = \ + README \ + $(app_DATA) \ + $(NULL) + +MAINTAINERCLEANFILES = \ + *~ \ + Makefile.in diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/README b/daemons/ipa-slapi-plugins/ipa-extdom-extop/README new file mode 100644 index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/extdom-extop-conf.ldif b/daemons/ipa-slapi-plugins/ipa-extdom-extop/extdom-extop-conf.ldif new file mode 100644 index 0000000000000000000000000000000000000000..ec51ed26f127410901972053c86a49930d217d82 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/extdom-extop-conf.ldif @@ -0,0 +1,16 @@ +dn: cn=ipa_extdom_extop,cn=plugins,cn=config +changetype: add +objectclass: top +objectclass: nsSlapdPlugin +objectclass: extensibleObject +cn: ipa_extdom_extop +nsslapd-pluginpath: libipa_extdom_extop +nsslapd-plugininitfunc: ipa_extdom_init +nsslapd-plugintype: extendedop +nsslapd-pluginenabled: on +nsslapd-pluginid: ipa_extdom_extop +nsslapd-pluginversion: 1.0 +nsslapd-pluginvendor: RedHat +nsslapd-plugindescription: Support resolving IDs in trusted domains to names and back +nsslapd-plugin-depends-on-type: database +nsslapd-basedn: $SUFFIX diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h new file mode 100644 index 0000000000000000000000000000000000000000..bcb3f16ed45d7d36237f95794481377d5306605e --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h @@ -0,0 +1,153 @@ +/** BEGIN COPYRIGHT BLOCK + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see . + * + * Additional permission under GPLv3 section 7: + * + * In the following paragraph, "GPL" means the GNU General Public + * License, version 3 or any later version, and "Non-GPL Code" means + * code that is governed neither by the GPL nor a license + * compatible with the GPL. + * + * You may link the code of this Program with Non-GPL Code and convey + * linked combinations including the two, provided that such Non-GPL + * Code only links to the code of this Program through those well + * defined interfaces identified in the file named EXCEPTION found in + * the source code files (the "Approved Interfaces"). The files of + * Non-GPL Code may instantiate templates or use macros or inline + * functions from the Approved Interfaces without causing the resulting + * work to be covered by the GPL. Only the copyright holders of this + * Program may make changes or additions to the list of Approved + * Interfaces. + * + * Authors: + * Sumit Bose + * + * Copyright (C) 2011 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT BLOCK **/ + +#ifndef _IPA_EXTDOM_H_ +#define _IPA_EXTDOM_H_ + +#ifdef HAVE_CONFIG_H +# include +#endif + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include + +#include + + +#define IPA_EXTDOM_PLUGIN_NAME "ipa-extdom-extop" +#define IPA_EXTDOM_FEATURE_DESC "IPA EXTDOM ID mapper" +#define IPA_EXTDOM_PLUGIN_DESC "IPA EXTDOM ID mapper Extended Operation plugin" + +#define IPA_PLUGIN_NAME IPA_EXTDOM_PLUGIN_NAME + +enum input_types { + INP_SID = 1, + INP_NAME, + INP_POSIX_UID, + INP_POSIX_GID +}; + +enum request_types { + REQ_SIMPLE = 1, + REQ_FULL +}; + +enum response_types { + RESP_SID = 1, + RESP_NAME, + RESP_USER, + RESP_GROUP +}; + +struct extdom_req { + enum input_types input_type; + enum request_types request_type; + union { + char *sid; + struct { + char *domain_name; + char *object_name; + } name; + struct { + char *domain_name; + uid_t uid; + } posix_uid; + struct { + char *domain_name; + gid_t gid; + } posix_gid; + } data; +}; + +struct extdom_res { + enum response_types response_type; + union { + char *sid; + struct { + const char *domain_name; + const char *object_name; + } name; + struct { + const char *domain_name; + const char *user_name; + uid_t uid; + gid_t gid; + } user; + struct { + const char *domain_name; + const char *group_name; + gid_t gid; + } group; + } data; +}; + +struct ipa_extdom_ctx { + Slapi_ComponentId *plugin_id; + char *base_dn; +}; + +struct domain_info { + char *flat_name; + char *sid; + char *guid; + struct sss_idmap_ctx *idmap_ctx; +}; + +int parse_request_data(struct berval *req_val, struct extdom_req **_req); +int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, + struct extdom_res **res); +int create_response(struct extdom_req *req, struct domain_info *domain_info, + const char *domain_name, + const char *name, struct wbcDomainSid *sid, + enum wbcSidType name_type, struct extdom_res **_res); +int pack_response(struct extdom_res *res, struct berval **ret_val); +#endif /* _IPA_EXTDOM_H_ */ diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c new file mode 100644 index 0000000000000000000000000000000000000000..0fdc97e94c10a4704e1ce11d7822e5660eb93749 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -0,0 +1,498 @@ +/** BEGIN COPYRIGHT BLOCK + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see . + * + * Additional permission under GPLv3 section 7: + * + * In the following paragraph, "GPL" means the GNU General Public + * License, version 3 or any later version, and "Non-GPL Code" means + * code that is governed neither by the GPL nor a license + * compatible with the GPL. + * + * You may link the code of this Program with Non-GPL Code and convey + * linked combinations including the two, provided that such Non-GPL + * Code only links to the code of this Program through those well + * defined interfaces identified in the file named EXCEPTION found in + * the source code files (the "Approved Interfaces"). The files of + * Non-GPL Code may instantiate templates or use macros or inline + * functions from the Approved Interfaces without causing the resulting + * work to be covered by the GPL. Only the copyright holders of this + * Program may make changes or additions to the list of Approved + * Interfaces. + * + * Authors: + * Sumit Bose + * + * Copyright (C) 2011 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT BLOCK **/ + +#ifndef _GNU_SOURCE +#define _GNU_SOURCE 1 /* for asprintf() */ +#endif + +#include +#include + +#include "ipa_extdom.h" +#include "util.h" + +int parse_request_data(struct berval *req_val, struct extdom_req **_req) +{ + BerElement *ber = NULL; + ber_tag_t tag; + ber_int_t input_type; + ber_int_t request_type; + ber_int_t id; + struct extdom_req *req; + +/* We expect the following request: + * ExtdomRequestValue ::= SEQUENCE { + * inputType ENUMERATED { + * sid (1), + * name (2), + * posix uid (3), + * posix gid (3) + * }, + * requestType ENUMERATED { + * simple (1), + * full (2) + * }, + * data InputData + * } + * + * InputData ::= CHOICE { + * sid OCTET STRING, + * name NameDomainData + * uid PosixUid, + * gid PosixGid + * } + * + * NameDomainData ::= SEQUENCE { + * domain_name OCTET STRING, + * object_name OCTET STRING + * } + * + * PosixUid ::= SEQUENCE { + * domain_name OCTET STRING, + * uid INTEGER + * } + * + * PosixGid ::= SEQUENCE { + * domain_name OCTET STRING, + * gid INTEGER + * } + */ + + if (req_val == NULL || req_val->bv_val == NULL || req_val->bv_len == 0) { + return LDAP_PROTOCOL_ERROR; + } + + ber = ber_init(req_val); + if (ber == NULL) { + return LDAP_PROTOCOL_ERROR; + } + + tag = ber_scanf(ber, "{ee", &input_type, &request_type); + if (tag == LBER_ERROR) { + ber_free(ber, 1); + return LDAP_PROTOCOL_ERROR; + } + + req = calloc(sizeof(struct extdom_req), 1); + if (req == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + req->input_type = input_type; + req->request_type = request_type; + + switch (req->input_type) { + case INP_NAME: + tag = ber_scanf(ber, "{aa}}", &req->data.name.domain_name, + &req->data.name.object_name); + break; + case INP_SID: + tag = ber_scanf(ber, "a}", &req->data.sid); + break; + case INP_POSIX_UID: + tag = ber_scanf(ber, "{ai}}", &req->data.posix_uid.domain_name, + &id); + req->data.posix_uid.uid = (uid_t) id; + break; + case INP_POSIX_GID: + tag = ber_scanf(ber, "{ai}}", &req->data.posix_gid.domain_name, + &id); + req->data.posix_gid.gid = (gid_t) id; + break; + default: + ber_free(ber, 1); + return LDAP_PROTOCOL_ERROR; + } + ber_free(ber, 1); + if (tag == LBER_ERROR) { + return LDAP_PROTOCOL_ERROR; + } + + *_req = req; + + return LDAP_SUCCESS; +} + +static void free_domain_info(struct domain_info *domain_info) +{ + if (domain_info == NULL) { + return; + } + + sss_idmap_free(domain_info->idmap_ctx); + slapi_ch_free((void **) &domain_info->guid); + slapi_ch_free((void **) &domain_info->sid); + slapi_ch_free((void **) &domain_info->flat_name); + free(domain_info); +} + +/* TODO: A similar call is used in ipa_cldap_netlogon.c, maybe a candidate for + * a common library */ +static int get_domain_info(struct ipa_extdom_ctx *ctx, const char *domain_name, + struct domain_info **_domain_info) +{ + struct domain_info *domain_info = NULL; + Slapi_PBlock *pb = NULL; + Slapi_Entry **e = NULL; + char *filter = NULL; + int ret; + enum idmap_error_code err; + struct sss_idmap_range range; + + pb = slapi_pblock_new(); + if (pb == NULL) { + return ENOMEM; + } + + ret = asprintf(&filter, "(&(|(cn=%s)(ipaNTTrustPartner=%s)(ipaNTFlatName=%s))(objectclass=ipaNTTrustedDomain))", + domain_name, domain_name, domain_name); + if (ret == -1) { + ret = ENOMEM; + goto done; + } + + slapi_search_internal_set_pb(pb, ctx->base_dn, + LDAP_SCOPE_SUBTREE, filter, + NULL, 0, NULL, NULL, ctx->plugin_id, 0); + + slapi_search_internal_pb(pb); + slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_RESULT, &ret); + + if (ret != EOK) { + ret = ENOENT; + goto done; + } + + slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, &e); + if (!e || !e[0] || e[1]) { + /* no matches or too many matches */ + ret = ENOENT; + goto done; + } + + domain_info = calloc(1, sizeof(struct domain_info)); + if (domain_info == NULL) { + ret = ENOMEM; + goto done; + } + + domain_info->guid = slapi_entry_attr_get_charptr(e[0], "ipaNTDomainGUID"); + domain_info->sid = slapi_entry_attr_get_charptr(e[0], + "ipaNTSecurityIdentifier"); + domain_info->flat_name = slapi_entry_attr_get_charptr(e[0], + "ipaNTFlatName"); + + /* TODO: read range from LDAP server */ + range.min = 200000; + range.max = 400000; + + err = sss_idmap_init(NULL, NULL, NULL, &domain_info->idmap_ctx); + if (err == IDMAP_SUCCESS) { + err = sss_idmap_add_domain(domain_info->idmap_ctx, domain_name, + domain_info->sid, &range); + } + if (err != IDMAP_SUCCESS) { + free_domain_info(domain_info); + ret = EFAULT; + goto done; + } + + *_domain_info = domain_info; + + ret = 0; + +done: + slapi_free_search_results_internal(pb); + slapi_pblock_destroy(pb); + free(filter); + return ret; + +} + +int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, + struct extdom_res **res) +{ + wbcErr werr; + int ret; + struct wbcDomainSid sid; + char *domain_name; + char *name; + enum wbcSidType name_type; + struct domain_info *domain_info = NULL; + + ret = get_domain_info(ctx, req->data.name.domain_name, &domain_info); + if (ret != 0) { + return LDAP_OPERATIONS_ERROR; + } + + switch (req->input_type) { + case INP_SID: + werr = wbcStringToSid(req->data.sid, &sid); + if (!WBC_ERROR_IS_OK(werr)) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + werr = wbcLookupSid(&sid, &domain_name, &name, &name_type); + if (!WBC_ERROR_IS_OK(werr)) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = create_response(req, domain_info, domain_name, name, &sid, + name_type, res); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + break; + case INP_NAME: + werr = wbcLookupName(domain_info->flat_name, + req->data.name.object_name, &sid, &name_type); + if (!WBC_ERROR_IS_OK(werr)) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + ret = create_response(req, domain_info, req->data.name.domain_name, + req->data.name.object_name, &sid, name_type, + res); + if (ret != 0) { + ret = LDAP_OPERATIONS_ERROR; + goto done; + } + + break; + default: + ret = LDAP_PROTOCOL_ERROR; + goto done; + } + + ret = LDAP_SUCCESS; + +done: + free_domain_info(domain_info); + + return ret; +} + +int create_response(struct extdom_req *req, struct domain_info *domain_info, + const char *domain_name, + const char *name, struct wbcDomainSid *sid, + enum wbcSidType name_type, struct extdom_res **_res) +{ + int ret = EFAULT; + int len; + struct extdom_res *res; + uint32_t id; + enum idmap_error_code err; + char sid_str[WBC_SID_STRING_BUFLEN + 1]; + + res = malloc(sizeof(struct extdom_res)); + if (res == NULL) { + return ENOMEM; + } + + switch (req->request_type) { + case REQ_SIMPLE: + switch (req->input_type) { + case INP_SID: + res->response_type = RESP_NAME; + res->data.name.domain_name = domain_name; + res->data.name.object_name = name; + break; + case INP_NAME: + res->response_type = RESP_SID; + + len = wbcSidToStringBuf(sid, sid_str, + WBC_SID_STRING_BUFLEN); + if (len + 1 > WBC_SID_STRING_BUFLEN) { + ret = EINVAL; + goto done; + } + + res->data.sid = sid_str; + break; + default: + ret = EINVAL; + goto done; + } + break; + case REQ_FULL: + len = wbcSidToStringBuf(sid, sid_str, WBC_SID_STRING_BUFLEN); + if (len + 1 > WBC_SID_STRING_BUFLEN) { + ret = EINVAL; + goto done; + } + + err = sss_idmap_sid_to_unix(domain_info->idmap_ctx, sid_str, &id); + if (err != IDMAP_SUCCESS) { + ret = EINVAL; + goto done; + } + switch (name_type) { + case WBC_SID_NAME_USER: + res->response_type = RESP_USER; + res->data.user.domain_name = domain_name; + res->data.user.user_name = name; + + res->data.user.uid = (uid_t) id; + + /* We use MPGs for external users */ + res->data.user.gid = (gid_t) id; + break; + case WBC_SID_NAME_DOM_GRP: + res->response_type = RESP_GROUP; + res->data.group.domain_name = domain_name; + res->data.group.group_name = name; + + res->data.group.gid = (gid_t) id; + break; + default: + ret = EINVAL; + goto done; + } + break; + default: + ret = EINVAL; + goto done; + } + + ret = 0; + +done: + if (ret == 0) { + *_res = res; + } else { + free(res); + } + + return ret; +} + +int pack_response(struct extdom_res *res, struct berval **ret_val) +{ + BerElement *ber = NULL; + int ret; + +/* We send to follwing response: + * ExtdomResponseValue ::= SEQUENCE { + * responseType ENUMERATED { + * sid (1), + * name (2), + * posix_user (3), + * posix_group (4) + * }, + * data OutputData + * } + * + * OutputData ::= CHOICE { + * sid OCTET STRING, + * name NameDomainData, + * user PosixUser, + * group PosixGroup + * } + * + * NameDomainData ::= SEQUENCE { + * domain_name OCTET STRING, + * object_name OCTET STRING + * } + * + * PosixUser ::= SEQUENCE { + * domain_name OCTET STRING, + * user_name OCTET STRING, + * uid INTEGER + * gid INTEGER + * } + * + * PosixGroup ::= SEQUENCE { + * domain_name OCTET STRING, + * group_name OCTET STRING, + * gid INTEGER + * } + */ + + ber = ber_alloc_t( LBER_USE_DER ); + if (ber == NULL) { + return LDAP_OPERATIONS_ERROR; + } + + switch (res->response_type) { + case RESP_SID: + ret = ber_printf(ber,"{es}", res->response_type, res->data.sid); + break; + case RESP_NAME: + ret = ber_printf(ber,"{e{ss}}", res->response_type, + res->data.name.domain_name, + res->data.name.object_name); + break; + case RESP_USER: + ret = ber_printf(ber,"{e{ssii}}", res->response_type, + res->data.user.domain_name, + res->data.user.user_name, + res->data.user.uid, + res->data.user.gid); + break; + case RESP_GROUP: + ret = ber_printf(ber,"{e{ssi}}", res->response_type, + res->data.group.domain_name, + res->data.group.group_name, + res->data.group.gid); + break; + default: + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + ret = ber_flatten(ber, ret_val); + if (ret == -1) { + ber_free(ber, 1); + return LDAP_OPERATIONS_ERROR; + } + + ber_free(ber, 1); + + return LDAP_SUCCESS; +} diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c new file mode 100644 index 0000000000000000000000000000000000000000..cf2db333ad57940dc06c3bdb6990b6548ffc0040 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c @@ -0,0 +1,236 @@ +/** BEGIN COPYRIGHT BLOCK + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see . + * + * Additional permission under GPLv3 section 7: + * + * In the following paragraph, "GPL" means the GNU General Public + * License, version 3 or any later version, and "Non-GPL Code" means + * code that is governed neither by the GPL nor a license + * compatible with the GPL. + * + * You may link the code of this Program with Non-GPL Code and convey + * linked combinations including the two, provided that such Non-GPL + * Code only links to the code of this Program through those well + * defined interfaces identified in the file named EXCEPTION found in + * the source code files (the "Approved Interfaces"). The files of + * Non-GPL Code may instantiate templates or use macros or inline + * functions from the Approved Interfaces without causing the resulting + * work to be covered by the GPL. Only the copyright holders of this + * Program may make changes or additions to the list of Approved + * Interfaces. + * + * Authors: + * Sumit Bose + * + * Copyright (C) 2011 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT BLOCK **/ + +#include "ipa_extdom.h" +#include "util.h" + +#define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" + +Slapi_PluginDesc ipa_extdom_plugin_desc = { + IPA_EXTDOM_FEATURE_DESC, + "FreeIPA project", + "FreeIPA/1.0", + IPA_EXTDOM_PLUGIN_DESC +}; + +static char *ipa_extdom_oid_list[] = { + EXOP_EXTDOM_OID, + NULL +}; + +static char *ipa_extdom_name_list[] = { + IPA_EXTDOM_PLUGIN_DESC, + NULL +}; + +static int ipa_extdom_start(Slapi_PBlock *pb) +{ + return LDAP_SUCCESS; +} + +static int ipa_extdom_extop(Slapi_PBlock *pb) +{ + char *oid = NULL; + char *err_msg = NULL; + int rc; + int ret; + struct berval *req_val = NULL; + struct berval *ret_val = NULL; + struct extdom_req *req = NULL; + struct extdom_res *res = NULL; + struct ipa_extdom_ctx *ctx; + + ret = slapi_pblock_get(pb, SLAPI_EXT_OP_REQ_OID, &oid); + if (ret != 0) { + rc = LDAP_OPERATIONS_ERROR; + err_msg = "Could not get OID value from request.\n"; + goto done; + } + LOG("Received extended operation request with OID %s\n", oid); + + if (strcasecmp(oid, EXOP_EXTDOM_OID) != 0) { + return SLAPI_PLUGIN_EXTENDED_NOT_HANDLED; + } + + ret = slapi_pblock_get(pb, SLAPI_EXT_OP_REQ_VALUE, &req_val); + if (ret != 0) { + rc = LDAP_UNWILLING_TO_PERFORM; + err_msg = "Missing request data.\n"; + goto done; + } + + ret = slapi_pblock_get(pb, SLAPI_PLUGIN_PRIVATE, &ctx); + if (ret != 0) { + rc = LDAP_OPERATIONS_ERROR; + err_msg = "Missing plugin context.\n"; + goto done; + } + + ret = parse_request_data(req_val, &req); + if (ret != LDAP_SUCCESS) { + rc = LDAP_UNWILLING_TO_PERFORM; + err_msg = "Cannot parse request data.\n"; + goto done; + } + + ret = handle_request(ctx, req, &res); + if (ret != LDAP_SUCCESS) { + rc = LDAP_OPERATIONS_ERROR; + err_msg = "Failed to handle the request.\n"; + goto done; + } + + ret = pack_response(res, &ret_val); + if (ret != LDAP_SUCCESS) { + rc = LDAP_OPERATIONS_ERROR; + err_msg = "Failed to pack the response.\n"; + goto done; + } + + ret = slapi_pblock_set(pb, SLAPI_EXT_OP_RET_OID, EXOP_EXTDOM_OID); + if (ret != 0) { + rc = LDAP_OPERATIONS_ERROR; + err_msg = "Failed to set the OID for the response.\n"; + goto done; + } + + ret = slapi_pblock_set( pb, SLAPI_EXT_OP_RET_VALUE, ret_val); + if (ret != 0) { + rc = LDAP_OPERATIONS_ERROR; + err_msg = "Failed to set the value for the response.\n"; + goto done; + } + + rc = LDAP_SUCCESS; + +done: + free(req); + free(res); + if (err_msg != NULL) { + LOG(err_msg); + } + slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL); + return SLAPI_PLUGIN_EXTENDED_SENT_RESULT; +} + +static int ipa_extdom_init_ctx(Slapi_PBlock *pb, struct ipa_extdom_ctx **_ctx) +{ + struct ipa_extdom_ctx *ctx; + Slapi_Entry *e; + int ret; + + ctx = calloc(1, sizeof(struct ipa_extdom_ctx)); + if (!ctx) { + return LDAP_OPERATIONS_ERROR; + } + + ret = slapi_pblock_get(pb, SLAPI_PLUGIN_IDENTITY, &ctx->plugin_id); + if ((ret != 0) || (NULL == ctx->plugin_id)) { + LOG_FATAL("Could not get identity or identity was NULL\n"); + if (ret == 0) { + ret = -1; + } + goto done; + } + + slapi_pblock_get(pb, SLAPI_PLUGIN_CONFIG_ENTRY, &e); + if (!e) { + LOG_FATAL("Plugin configuration not found!\n"); + return -1; + } + + ctx->base_dn = slapi_entry_attr_get_charptr(e, "nsslapd-basedn"); + if (!ctx->base_dn) { + LOG_FATAL("Base DN not found in plugin configuration not found!\n"); + return -1; + } + + +done: + if (ret) { + free(ctx); + } else { + *_ctx = ctx; + } + return ret; +} + +int ipa_extdom_init(Slapi_PBlock *pb) +{ + int ret; + struct ipa_extdom_ctx *extdom_ctx; + + ret = ipa_extdom_init_ctx(pb, &extdom_ctx); + if (ret) { + LOG_FATAL("Failed ot initialize external domain extended operation.\n"); + /* do not cause DS to stop, simply do nothing */ + return 0; + } + + ret = slapi_pblock_set(pb, SLAPI_PLUGIN_VERSION, SLAPI_PLUGIN_VERSION_01); + if (!ret) { + ret = slapi_pblock_set(pb, SLAPI_PLUGIN_DESCRIPTION, + (void *)&ipa_extdom_plugin_desc); + } + if (!ret) { + ret = slapi_pblock_set(pb, SLAPI_PLUGIN_START_FN, + (void *)ipa_extdom_start); + } + if (!ret) { + ret = slapi_pblock_set(pb, SLAPI_PLUGIN_EXT_OP_OIDLIST, + ipa_extdom_oid_list); + } + if (!ret) { + ret = slapi_pblock_set(pb, SLAPI_PLUGIN_EXT_OP_NAMELIST, + ipa_extdom_name_list); + } + if (!ret) { + ret = slapi_pblock_set(pb, SLAPI_PLUGIN_EXT_OP_FN, + (void *)ipa_extdom_extop); + } + if (!ret) { + ret = slapi_pblock_set(pb, SLAPI_PLUGIN_PRIVATE, extdom_ctx); + } + if (ret) { + LOG("Failed to set plug-in version, function, and OID.\n" ); + return -1; + } + + return 0; +} diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_tests.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_tests.c new file mode 100644 index 0000000000000000000000000000000000000000..acb6ae2844eafe938a293a964efa2afe31e32b9e --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_tests.c @@ -0,0 +1,203 @@ +/** BEGIN COPYRIGHT BLOCK + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see . + * + * Additional permission under GPLv3 section 7: + * + * In the following paragraph, "GPL" means the GNU General Public + * License, version 3 or any later version, and "Non-GPL Code" means + * code that is governed neither by the GPL nor a license + * compatible with the GPL. + * + * You may link the code of this Program with Non-GPL Code and convey + * linked combinations including the two, provided that such Non-GPL + * Code only links to the code of this Program through those well + * defined interfaces identified in the file named EXCEPTION found in + * the source code files (the "Approved Interfaces"). The files of + * Non-GPL Code may instantiate templates or use macros or inline + * functions from the Approved Interfaces without causing the resulting + * work to be covered by the GPL. Only the copyright holders of this + * Program may make changes or additions to the list of Approved + * Interfaces. + * + * Authors: + * Sumit Bose + * + * Copyright (C) 2011 Red Hat, Inc. + * All rights reserved. + * END COPYRIGHT BLOCK **/ + +#include + +#include "ipa_extdom.h" +#include "util.h" + +char req_sid[] = {0x30, 0x11, 0x0a, 0x01, 0x01, 0x0a, 0x01, 0x01, 0x04, 0x09, \ + 0x53, 0x2d, 0x31, 0x2d, 0x32, 0x2d, 0x33, 0x2d, 0x34}; +char req_nam[] = {0x30, 0x16, 0x0a, 0x01, 0x02, 0x0a, 0x01, 0x01, 0x30, 0x0e, \ + 0x04, 0x06, 0x44, 0x4f, 0x4d, 0x41, 0x49, 0x4e, 0x04, 0x04, \ + 0x74, 0x65, 0x73, 0x74}; +char req_uid[] = {0x30, 0x14, 0x0a, 0x01, 0x03, 0x0a, 0x01, 0x01, 0x30, 0x0c, \ + 0x04, 0x06, 0x44, 0x4f, 0x4d, 0x41, 0x49, 0x4e, 0x02, 0x02, \ + 0x30, 0x39}; +char req_gid[] = {0x30, 0x15, 0x0a, 0x01, 0x04, 0x0a, 0x01, 0x01, 0x30, 0x0d, \ + 0x04, 0x06, 0x44, 0x4f, 0x4d, 0x41, 0x49, 0x4e, 0x02, 0x03, \ + 0x00, 0xd4, 0x31}; + +char res_sid[] = {0x30, 0x0e, 0x0a, 0x01, 0x01, 0x04, 0x09, 0x53, 0x2d, 0x31, \ + 0x2d, 0x32, 0x2d, 0x33, 0x2d, 0x34}; +char res_nam[] = {0x30, 0x13, 0x0a, 0x01, 0x02, 0x30, 0x0e, 0x04, 0x06, 0x44, \ + 0x4f, 0x4d, 0x41, 0x49, 0x4e, 0x04, 0x04, 0x74, 0x65, 0x73, \ + 0x74}; +char res_uid[] = {0x30, 0x17, 0x0a, 0x01, 0x03, 0x30, 0x12, 0x04, 0x06, 0x44, \ + 0x4f, 0x4d, 0x41, 0x49, 0x4e, 0x04, 0x04, 0x74, 0x65, 0x73, \ + 0x74, 0x02, 0x02, 0x30, 0x39}; +char res_gid[] = {0x30, 0x1e, 0x0a, 0x01, 0x04, 0x30, 0x19, 0x04, 0x06, 0x44, \ + 0x4f, 0x4d, 0x41, 0x49, 0x4e, 0x04, 0x0a, 0x74, 0x65, 0x73, \ + 0x74, 0x5f, 0x67, 0x72, 0x6f, 0x75, 0x70, 0x02, 0x03, 0x00, \ + 0xd4, 0x31}; + +#define TEST_SID "S-1-2-3-4" +#define TEST_DOMAIN_NAME "DOMAIN" + +START_TEST(test_encode) +{ + int ret; + struct extdom_res res; + struct berval *resp_val; + + res.response_type = RESP_SID; + res.data.sid = TEST_SID; + + ret = pack_response(&res, &resp_val); + + fail_unless(ret == LDAP_SUCCESS, "pack_response() failed."); + fail_unless(sizeof(res_sid) == resp_val->bv_len && + memcmp(res_sid, resp_val->bv_val, resp_val->bv_len) == 0, + "Unexpected BER blob."); + ber_memfree(resp_val); + + res.response_type = RESP_NAME; + res.data.name.domain_name = TEST_DOMAIN_NAME; + res.data.name.object_name = "test"; + + ret = pack_response(&res, &resp_val); + + fail_unless(ret == LDAP_SUCCESS, "pack_response() failed."); + fail_unless(sizeof(res_nam) == resp_val->bv_len && + memcmp(res_nam, resp_val->bv_val, resp_val->bv_len) == 0, + "Unexpected BER blob."); + ber_memfree(resp_val); +} +END_TEST + +START_TEST(test_decode) +{ + struct berval req_val; + struct extdom_req *req; + int ret; + + req_val.bv_val = req_sid; + req_val.bv_len = sizeof(req_sid); + + ret = parse_request_data(&req_val, &req); + + fail_unless(ret == LDAP_SUCCESS, "parse_request_data() failed."); + fail_unless(req->input_type == INP_SID, + "parse_request_data() returned unexpected input type"); + fail_unless(req->request_type == REQ_SIMPLE, + "parse_request_data() returned unexpected request type"); + fail_unless(strcmp(req->data.sid, "S-1-2-3-4") == 0, + "parse_request_data() returned unexpected sid"); + free(req); + + req_val.bv_val = req_nam; + req_val.bv_len = sizeof(req_nam); + + ret = parse_request_data(&req_val, &req); + + fail_unless(ret == LDAP_SUCCESS, + "parse_request_data() failed."); + fail_unless(req->input_type == INP_NAME, + "parse_request_data() returned unexpected input type"); + fail_unless(req->request_type == REQ_SIMPLE, + "parse_request_data() returned unexpected request type"); + fail_unless(strcmp(req->data.name.domain_name, "DOMAIN") == 0, + "parse_request_data() returned unexpected domain name"); + fail_unless(strcmp(req->data.name.object_name, "test") == 0, + "parse_request_data() returned unexpected object name"); + free(req); + + req_val.bv_val = req_uid; + req_val.bv_len = sizeof(req_uid); + + ret = parse_request_data(&req_val, &req); + + fail_unless(ret == LDAP_SUCCESS, + "parse_request_data() failed."); + fail_unless(req->input_type == INP_POSIX_UID, + "parse_request_data() returned unexpected input type"); + fail_unless(req->request_type == REQ_SIMPLE, + "parse_request_data() returned unexpected request type"); + fail_unless(strcmp(req->data.posix_uid.domain_name, "DOMAIN") == 0, + "parse_request_data() returned unexpected domain name"); + fail_unless(req->data.posix_uid.uid == 12345, + "parse_request_data() returned unexpected uid [%d]", + req->data.posix_uid.uid); + free(req); + + req_val.bv_val = req_gid; + req_val.bv_len = sizeof(req_gid); + + ret = parse_request_data(&req_val, &req); + + fail_unless(ret == LDAP_SUCCESS, + "parse_request_data() failed."); + fail_unless(req->input_type == INP_POSIX_GID, + "parse_request_data() returned unexpected input type"); + fail_unless(req->request_type == REQ_SIMPLE, + "parse_request_data() returned unexpected request type"); + fail_unless(strcmp(req->data.posix_gid.domain_name, "DOMAIN") == 0, + "parse_request_data() returned unexpected domain name"); + fail_unless(req->data.posix_gid.gid == 54321, + "parse_request_data() returned unexpected gid [%d]", + req->data.posix_gid.gid); + free(req); +} +END_TEST + +Suite * ipa_extdom_suite(void) +{ + Suite *s = suite_create("IPA extdom"); + + TCase *tc_core = tcase_create("Core"); + tcase_add_test(tc_core, test_decode); + tcase_add_test(tc_core, test_encode); + /* TODO: add test for create_response() */ + suite_add_tcase(s, tc_core); + + return s; +} + +int main(void) +{ + int number_failed; + + Suite *s = ipa_extdom_suite (); + SRunner *sr = srunner_create (s); + srunner_run_all (sr, CK_VERBOSE); + number_failed = srunner_ntests_failed (sr); + srunner_free (sr); + + return (number_failed == 0) ? EXIT_SUCCESS : EXIT_FAILURE; +} diff --git a/freeipa.spec.in b/freeipa.spec.in index 08ad79d87e8c0a17f959b9b7fac618d18632d88e..72f3ceef6fb3605f5bf7e4bc6d41bc591f0c6710 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -76,6 +76,9 @@ BuildRequires: pylint BuildRequires: libipa_hbac-python BuildRequires: python-memcached BuildRequires: sssd >= 1.8.0 +BuildRequires: check >= 0.9.5 +BuildRequires: libwbclient-devel +BuildRequires: libsss_idmap-devel %description IPA is an integrated solution to provide centrally managed Identity (machine, @@ -298,6 +301,7 @@ make IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} all cd selinux # This isn't multi-process make capable yet make all +cd ../daemons ; make check %else make IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} client %endif @@ -324,6 +328,7 @@ make client-install DESTDIR=%{buildroot} # Remove .la files from libtool - we don't want to package # these files rm %{buildroot}/%{plugin_dir}/libipa_pwd_extop.la +rm %{buildroot}/%{plugin_dir}/libipa_extdom_extop.la rm %{buildroot}/%{plugin_dir}/libipa_enrollment_extop.la rm %{buildroot}/%{plugin_dir}/libipa_winsync.la rm %{buildroot}/%{plugin_dir}/libipa_repl_version.la @@ -590,6 +595,7 @@ fi %dir %{_usr}/share/ipa/updates/ %{_usr}/share/ipa/updates/* %attr(755,root,root) %{plugin_dir}/libipa_pwd_extop.so +%attr(755,root,root) %{plugin_dir}/libipa_extdom_extop.so %attr(755,root,root) %{plugin_dir}/libipa_enrollment_extop.so %attr(755,root,root) %{plugin_dir}/libipa_winsync.so %attr(755,root,root) %{plugin_dir}/libipa_repl_version.so @@ -677,6 +683,8 @@ fi %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt %changelog +* Wed Mar 19 2012 Sumit Bose - 2.99.0-24 +- Add extdom extop plugin * Wed Mar 19 2012 Martin Kosek - 2.99.0-23 - Set min for bind-dyndb-ldap and bind to pick up new features and bug fixes -- 1.7.6 From dpal at redhat.com Fri Mar 23 13:35:47 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 23 Mar 2012 09:35:47 -0400 Subject: [Freeipa-devel] [PATCH] 18 Add external domain extop DS plugin In-Reply-To: <20120323125234.GU2301@localhost.localdomain> References: <20120323125234.GU2301@localhost.localdomain> Message-ID: <4F6C7C33.2000302@redhat.com> On 03/23/2012 08:52 AM, Sumit Bose wrote: > Hi, > > these two patches introduce a new extended operation to the IPA server > which can be used by clients in the IPA domain to obtain information > about users and groups from trusted domains. Currently this exop is used > by the sssd sub-domain patch to map user names from a trusted AD domain > to a SID and back. There is also some code for other kind of requests > which might become useful in future, e.g. with trusted IPA domain. Are the mappings cached on the SSSD side? > I added some unit test and added check for the check unit test framework > for C (http://check.sourceforge.net/) which is used by sssd as well. I > modified the spec file that the test is run during the build of the > packages. I hope this is ok. > > The patches depend on the idmap library patch which was ACKed recently > on sssd-devel and as mentioned before the sub-domain patches on > sssd-devel can only be fully tested with an IPA server which has these > patches applied. > > Since Alexander is currently rewriting parts of the ipa-adtrust-install > utility I stand back from adding activation code for the exop to > ipa-adtrust-install and will send a patch when Alexander's changes are > available. So currently extdom-extop-conf.ldif has to be loaded manually > after replacing $SUFFIX to activate the new exop. > > bye, > Sumit > > > _______________________________________________ > 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 pviktori at redhat.com Fri Mar 23 14:34:38 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 23 Mar 2012 15:34:38 +0100 Subject: [Freeipa-devel] [PATCH] 234 Avoid deleting DNS zone when a context is reused In-Reply-To: <1332495217.17059.29.camel@balmora.brq.redhat.com> References: <1331215056.11911.1.camel@balmora.brq.redhat.com> <1332495217.17059.29.camel@balmora.brq.redhat.com> Message-ID: <4F6C89FE.7060602@redhat.com> On 03/23/2012 10:33 AM, Martin Kosek wrote: > On Thu, 2012-03-08 at 14:57 +0100, Martin Kosek wrote: >> When dnsrecord-del pre_callback detects that the record does >> not contain any records, it set a flag to connection context >> and deletes the record object later. However, when more >> dnsrecord-del share the same context (and this is the case of >> "ipa-replica-manage del $MASTER" DNS cleanup), it may reuse >> a positive flag from previous dnsrecord-del command and delete >> the root DNS zone record and thus effectively delete the zone. >> >> This patch makes sure that this flag is always initialized to >> sane value in dnsrecord-del pre_callback to make sure that the DNS >> zone is not deleted. It also fixes pre_callback function definition >> to prevent adding attrs_list to "keys" parameter and thus confuse >> developers. >> >> https://fedorahosted.org/freeipa/ticket/2503 > > Sending a rebased patch which applies to current ipa-2-2. > > Martin > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This fixes the issue. ACK. It would be nice to have a comment hinting at what the del_all flag does. The option with the same name makes it somewhat unclear. -- Petr? From pviktori at redhat.com Fri Mar 23 15:01:29 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 23 Mar 2012 16:01:29 +0100 Subject: [Freeipa-devel] [PATCH] 0014 Add final debug message in installers In-Reply-To: <4F61C4BC.60809@redhat.com> References: <4F44B860.9050809@redhat.com> <4F4BB48C.7010200@redhat.com> <1330535684.32367.30.camel@balmora.brq.redhat.com> <4F4E728C.2070109@redhat.com> <4F4F5363.4030408@redhat.com> <4F61C4BC.60809@redhat.com> Message-ID: <4F6C9049.3030507@redhat.com> On 03/15/2012 11:30 AM, Petr Viktorin wrote: > On 03/01/2012 11:45 AM, Petr Viktorin wrote: >> On 02/29/2012 07:46 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On Mon, 2012-02-27 at 17:51 +0100, Petr Viktorin wrote: >>>>> On 02/22/2012 10:41 AM, Petr Viktorin wrote: >>>>>> This fixes https://fedorahosted.org/freeipa/ticket/2071 (Add final >>>>>> debug >>>>>> message in installers). The try/except blocks at the end of >>>>>> installers/management scripts are replaced by a call to a common >>>>>> function, which includes the final message. >>>>>> >>>>>> Obviously the installers still need some more love. This is as far >>>>>> as I >>>>>> got before Martin stopped me, saying I shouldn't change too much >>>>>> before >>>>>> a release :) >>>>>> >>>>>> >>>>>> If it's still too many changes to test, I could just wrap the >>>>>> blocks in >>>>>> some `with add_final_message` block for now, and resubmit this patch >>>>>> after the release. >>>>>> >>>>>> >>>> >>>> Yeah, this is exactly the kind of changes that can have yet-unseen >>>> consequences and I don't like pushing this close to the release. >>>> >>>> The original ticket just asks for a debug message when the install >>>> script ends. If possible, I would really prefer to have some low-risk >>>> patch adding just those and leave install script refactoring for next >>>> big release, like 3.x. Rob, what's your opinion on this? >>>> >>>> Martin >>>> >>> >>> Yes, I agree. Simpler is better at this point. >>> >>> rob >> >> This patch simply wraps the try blocks in a context that logs the final >> result. >> Most of the changes are indentation; diff with -w to see the additions. >> >> Not sure if this would count as an update or a new patch... >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Rebased against current master. > > > Rebased again. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0014-05-Add-final-debug-message-in-installers.patch Type: text/x-patch Size: 30070 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 23 15:14:17 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Mar 2012 16:14:17 +0100 Subject: [Freeipa-devel] [PATCH] 234 Avoid deleting DNS zone when a context is reused In-Reply-To: <4F6C89FE.7060602@redhat.com> References: <1331215056.11911.1.camel@balmora.brq.redhat.com> <1332495217.17059.29.camel@balmora.brq.redhat.com> <4F6C89FE.7060602@redhat.com> Message-ID: <1332515657.17059.40.camel@balmora.brq.redhat.com> On Fri, 2012-03-23 at 15:34 +0100, Petr Viktorin wrote: > On 03/23/2012 10:33 AM, Martin Kosek wrote: > > On Thu, 2012-03-08 at 14:57 +0100, Martin Kosek wrote: > >> When dnsrecord-del pre_callback detects that the record does > >> not contain any records, it set a flag to connection context > >> and deletes the record object later. However, when more > >> dnsrecord-del share the same context (and this is the case of > >> "ipa-replica-manage del $MASTER" DNS cleanup), it may reuse > >> a positive flag from previous dnsrecord-del command and delete > >> the root DNS zone record and thus effectively delete the zone. > >> > >> This patch makes sure that this flag is always initialized to > >> sane value in dnsrecord-del pre_callback to make sure that the DNS > >> zone is not deleted. It also fixes pre_callback function definition > >> to prevent adding attrs_list to "keys" parameter and thus confuse > >> developers. > >> > >> https://fedorahosted.org/freeipa/ticket/2503 > > > > Sending a rebased patch which applies to current ipa-2-2. > > > > Martin > > > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > This fixes the issue. ACK. > It would be nice to have a comment hinting at what the del_all flag > does. The option with the same name makes it somewhat unclear. > It has the very same meaning as the --del-all option - record is deleted. But I added a comment describing the effect of this flag to make it more clear. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Fri Mar 23 15:35:59 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Mar 2012 16:35:59 +0100 Subject: [Freeipa-devel] [PATCH] 243 Fix default SOA serial format Message-ID: <1332516959.17059.43.camel@balmora.brq.redhat.com> This patch is needed for correct SOA serial updates by nsupdate, which are being fixed in: https://bugzilla.redhat.com/show_bug.cgi?id=805871 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-243-fix-default-soa-serial-format.patch Type: text/x-patch Size: 1024 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 23 15:39:41 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Mar 2012 11:39:41 -0400 Subject: [Freeipa-devel] [PATCH] 243 Fix default SOA serial format In-Reply-To: <1332516959.17059.43.camel@balmora.brq.redhat.com> References: <1332516959.17059.43.camel@balmora.brq.redhat.com> Message-ID: <4F6C993D.5060800@redhat.com> Martin Kosek wrote: > This patch is needed for correct SOA serial updates by nsupdate, which > are being fixed in: > > https://bugzilla.redhat.com/show_bug.cgi?id=805871 > > Martin ACK From pviktori at redhat.com Fri Mar 23 15:47:30 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 23 Mar 2012 16:47:30 +0100 Subject: [Freeipa-devel] [PATCH] 18 Typos in FreeIPA messages In-Reply-To: <4F608FF2.5080102@redhat.com> References: <4F608FF2.5080102@redhat.com> Message-ID: <4F6C9B12.104@redhat.com> On 03/14/2012 01:32 PM, Ondrej Hamada wrote: > https://fedorahosted.org/freeipa/ticket/2526 > > Rebased patch sent by Yuri Chornoivan (yurchor at ukr.net). Fixes 'occured' > and 'commond' typos in FreeIPA messages. > > Longtitude/Longitude typo was already corrected in patch for ticket > #2382 . > > -- > Regards, > > Ondrej Hamada > FreeIPA team > jabber:ohama at jabbim.cz > IRC: ohamada ACK. Sorry this took so long. -- Petr? From mkosek at redhat.com Fri Mar 23 15:56:40 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Mar 2012 16:56:40 +0100 Subject: [Freeipa-devel] [PATCH] 243 Fix default SOA serial format In-Reply-To: <4F6C993D.5060800@redhat.com> References: <1332516959.17059.43.camel@balmora.brq.redhat.com> <4F6C993D.5060800@redhat.com> Message-ID: <1332518200.26102.0.camel@balmora.brq.redhat.com> On Fri, 2012-03-23 at 11:39 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > This patch is needed for correct SOA serial updates by nsupdate, which > > are being fixed in: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=805871 > > > > Martin > > ACK Pushed to master, ipa-2-2. Martin From sbose at redhat.com Fri Mar 23 15:57:46 2012 From: sbose at redhat.com (Sumit Bose) Date: Fri, 23 Mar 2012 16:57:46 +0100 Subject: [Freeipa-devel] [PATCH] 18 Add external domain extop DS plugin In-Reply-To: <4F6C7C33.2000302@redhat.com> References: <20120323125234.GU2301@localhost.localdomain> <4F6C7C33.2000302@redhat.com> Message-ID: <20120323155746.GA4354@localhost.localdomain> On Fri, Mar 23, 2012 at 09:35:47AM -0400, Dmitri Pal wrote: > On 03/23/2012 08:52 AM, Sumit Bose wrote: > > Hi, > > > > these two patches introduce a new extended operation to the IPA server > > which can be used by clients in the IPA domain to obtain information > > about users and groups from trusted domains. Currently this exop is used > > by the sssd sub-domain patch to map user names from a trusted AD domain > > to a SID and back. There is also some code for other kind of requests > > which might become useful in future, e.g. with trusted IPA domain. > > Are the mappings cached on the SSSD side? Yes in the sense that the whole user entry, which is the result of the mapping, is cached on the SSSD side. > > > I added some unit test and added check for the check unit test framework > > for C (http://check.sourceforge.net/) which is used by sssd as well. I > > modified the spec file that the test is run during the build of the > > packages. I hope this is ok. > > > > The patches depend on the idmap library patch which was ACKed recently > > on sssd-devel and as mentioned before the sub-domain patches on > > sssd-devel can only be fully tested with an IPA server which has these > > patches applied. > > > > Since Alexander is currently rewriting parts of the ipa-adtrust-install > > utility I stand back from adding activation code for the exop to > > ipa-adtrust-install and will send a patch when Alexander's changes are > > available. So currently extdom-extop-conf.ldif has to be loaded manually > > after replacing $SUFFIX to activate the new exop. I forgot to mention that for the time being winbind has to be started on the IPA server as well. For stability reasons the exop does not try to connect to the remote servers itself, but uses a local winbind instance to get to data (one of the positive side effects is that the mapping is cached by winbind, so that it is available to all clients in the IPA domain, even if the connection to the remote server is down). The plan is to replace winbind with a daemon of our own, but since winbind does what we need without extra configuration this is very low priority. I will the add the automatic startup of winbind in the patch which activated the exop. For now it has to be started manually. bye, Sumit > > > > bye, > > Sumit > > > > > > _______________________________________________ > > 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 mkosek at redhat.com Fri Mar 23 16:01:15 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Mar 2012 17:01:15 +0100 Subject: [Freeipa-devel] [PATCH] 18 Typos in FreeIPA messages In-Reply-To: <4F6C9B12.104@redhat.com> References: <4F608FF2.5080102@redhat.com> <4F6C9B12.104@redhat.com> Message-ID: <1332518475.26102.1.camel@balmora.brq.redhat.com> On Fri, 2012-03-23 at 16:47 +0100, Petr Viktorin wrote: > On 03/14/2012 01:32 PM, Ondrej Hamada wrote: > > https://fedorahosted.org/freeipa/ticket/2526 > > > > Rebased patch sent by Yuri Chornoivan (yurchor at ukr.net). Fixes 'occured' > > and 'commond' typos in FreeIPA messages. > > > > Longtitude/Longitude typo was already corrected in patch for ticket > > #2382 . > > > > -- > > Regards, > > > > Ondrej Hamada > > FreeIPA team > > jabber:ohama at jabbim.cz > > IRC: ohamada > > > ACK. Sorry this took so long. > > Pushed to master, ipa-2-2. Martin From dpal at redhat.com Fri Mar 23 16:08:22 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 23 Mar 2012 12:08:22 -0400 Subject: [Freeipa-devel] [PATCH] 18 Add external domain extop DS plugin In-Reply-To: <20120323155746.GA4354@localhost.localdomain> References: <20120323125234.GU2301@localhost.localdomain> <4F6C7C33.2000302@redhat.com> <20120323155746.GA4354@localhost.localdomain> Message-ID: <4F6C9FF6.3070908@redhat.com> On 03/23/2012 11:57 AM, Sumit Bose wrote: > On Fri, Mar 23, 2012 at 09:35:47AM -0400, Dmitri Pal wrote: >> On 03/23/2012 08:52 AM, Sumit Bose wrote: >>> Hi, >>> >>> these two patches introduce a new extended operation to the IPA server >>> which can be used by clients in the IPA domain to obtain information >>> about users and groups from trusted domains. Currently this exop is used >>> by the sssd sub-domain patch to map user names from a trusted AD domain >>> to a SID and back. There is also some code for other kind of requests >>> which might become useful in future, e.g. with trusted IPA domain. >> Are the mappings cached on the SSSD side? > Yes in the sense that the whole user entry, which is the result of the > mapping, is cached on the SSSD side. > And it is already done or planned, tracked? >>> I added some unit test and added check for the check unit test framework >>> for C (http://check.sourceforge.net/) which is used by sssd as well. I >>> modified the spec file that the test is run during the build of the >>> packages. I hope this is ok. >>> >>> The patches depend on the idmap library patch which was ACKed recently >>> on sssd-devel and as mentioned before the sub-domain patches on >>> sssd-devel can only be fully tested with an IPA server which has these >>> patches applied. >>> >>> Since Alexander is currently rewriting parts of the ipa-adtrust-install >>> utility I stand back from adding activation code for the exop to >>> ipa-adtrust-install and will send a patch when Alexander's changes are >>> available. So currently extdom-extop-conf.ldif has to be loaded manually >>> after replacing $SUFFIX to activate the new exop. > I forgot to mention that for the time being winbind has to be started on > the IPA server as well. For stability reasons the exop does not try to > connect to the remote servers itself, but uses a local winbind instance > to get to data (one of the positive side effects is that the mapping is > cached by winbind, so that it is available to all clients in the IPA > domain, even if the connection to the remote server is down). The plan > is to replace winbind with a daemon of our own, but since winbind does > what we need without extra configuration this is very low priority. > > I will the add the automatic startup of winbind in the patch which > activated the exop. For now it has to be started manually. > > bye, > Sumit > >>> bye, >>> Sumit >>> >>> >>> _______________________________________________ >>> 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 sbose at redhat.com Fri Mar 23 16:29:57 2012 From: sbose at redhat.com (Sumit Bose) Date: Fri, 23 Mar 2012 17:29:57 +0100 Subject: [Freeipa-devel] [PATCH] 18 Add external domain extop DS plugin In-Reply-To: <4F6C9FF6.3070908@redhat.com> References: <20120323125234.GU2301@localhost.localdomain> <4F6C7C33.2000302@redhat.com> <20120323155746.GA4354@localhost.localdomain> <4F6C9FF6.3070908@redhat.com> Message-ID: <20120323162957.GB4354@localhost.localdomain> On Fri, Mar 23, 2012 at 12:08:22PM -0400, Dmitri Pal wrote: > On 03/23/2012 11:57 AM, Sumit Bose wrote: > > On Fri, Mar 23, 2012 at 09:35:47AM -0400, Dmitri Pal wrote: > >> On 03/23/2012 08:52 AM, Sumit Bose wrote: > >>> Hi, > >>> > >>> these two patches introduce a new extended operation to the IPA server > >>> which can be used by clients in the IPA domain to obtain information > >>> about users and groups from trusted domains. Currently this exop is used > >>> by the sssd sub-domain patch to map user names from a trusted AD domain > >>> to a SID and back. There is also some code for other kind of requests > >>> which might become useful in future, e.g. with trusted IPA domain. > >> Are the mappings cached on the SSSD side? > > Yes in the sense that the whole user entry, which is the result of the > > mapping, is cached on the SSSD side. > > > And it is already done or planned, tracked? It is in the sub-domain patches Jan send recently to sssd-devel. bye, Sumit > > > >>> I added some unit test and added check for the check unit test framework > >>> for C (http://check.sourceforge.net/) which is used by sssd as well. I > >>> modified the spec file that the test is run during the build of the > >>> packages. I hope this is ok. > >>> > >>> The patches depend on the idmap library patch which was ACKed recently > >>> on sssd-devel and as mentioned before the sub-domain patches on > >>> sssd-devel can only be fully tested with an IPA server which has these > >>> patches applied. > >>> > >>> Since Alexander is currently rewriting parts of the ipa-adtrust-install > >>> utility I stand back from adding activation code for the exop to > >>> ipa-adtrust-install and will send a patch when Alexander's changes are > >>> available. So currently extdom-extop-conf.ldif has to be loaded manually > >>> after replacing $SUFFIX to activate the new exop. > > I forgot to mention that for the time being winbind has to be started on > > the IPA server as well. For stability reasons the exop does not try to > > connect to the remote servers itself, but uses a local winbind instance > > to get to data (one of the positive side effects is that the mapping is > > cached by winbind, so that it is available to all clients in the IPA > > domain, even if the connection to the remote server is down). The plan > > is to replace winbind with a daemon of our own, but since winbind does > > what we need without extra configuration this is very low priority. > > > > I will the add the automatic startup of winbind in the patch which > > activated the exop. For now it has to be started manually. > > > > bye, > > Sumit > > > >>> bye, > >>> Sumit > >>> > >>> > >>> _______________________________________________ > >>> 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/ > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Fri Mar 23 17:04:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Mar 2012 13:04:43 -0400 Subject: [Freeipa-devel] [PATCH] 995 update min version of 389-ds-base Message-ID: <4F6CAD2B.8040703@redhat.com> Set new minimum version of 389-ds-base to fix db corruption during upgrade problem. This patch is against 2.2. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-995-dbupgrade.patch Type: text/x-diff Size: 1353 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 23 19:10:09 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 23 Mar 2012 20:10:09 +0100 Subject: [Freeipa-devel] [PATCH] 0031 Add missing BuildRequires Message-ID: <4F6CCA91.4050409@redhat.com> Since our build process runs pylint, we need all Python dependencies installed at RPM creation time. This adds python-lxml and python-pyasn1 to BuildRequires. https://fedorahosted.org/freeipa/ticket/2538 Including patches for both master and ipa-2-2. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0031-Add-missing-BuildRequires.patch Type: text/x-patch Size: 1298 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa2.2-pviktori-0031-Add-missing-BuildRequires.patch Type: text/x-patch Size: 1296 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 23 19:11:59 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Mar 2012 15:11:59 -0400 Subject: [Freeipa-devel] [PATCH] 995 update min version of 389-ds-base In-Reply-To: <4F6CAD2B.8040703@redhat.com> References: <4F6CAD2B.8040703@redhat.com> Message-ID: <4F6CCAFF.3090008@redhat.com> Rob Crittenden wrote: > Set new minimum version of 389-ds-base to fix db corruption during > upgrade problem. > > This patch is against 2.2. Corrected changelog entry. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-995-2-dbupgrade.patch Type: text/x-diff Size: 3790 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 23 19:12:34 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Mar 2012 15:12:34 -0400 Subject: [Freeipa-devel] [PATCH] 996 fix unit tests Message-ID: <4F6CCB22.5040305@redhat.com> A few unit tests were failing due to new type enforcement and comman support. Unit tests are passing 100% for me with this. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-996-tests.patch Type: text/x-diff Size: 3790 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 23 19:15:10 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 23 Mar 2012 20:15:10 +0100 Subject: [Freeipa-devel] [PATCH] 995 update min version of 389-ds-base In-Reply-To: <4F6CCAFF.3090008@redhat.com> References: <4F6CAD2B.8040703@redhat.com> <4F6CCAFF.3090008@redhat.com> Message-ID: <4F6CCBBE.5010709@redhat.com> On 03/23/2012 08:11 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Set new minimum version of 389-ds-base to fix db corruption during >> upgrade problem. >> >> This patch is against 2.2. > > Corrected changelog entry. > You've attached a different patch. -- Petr? From abokovoy at redhat.com Fri Mar 23 19:59:22 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 23 Mar 2012 21:59:22 +0200 Subject: [Freeipa-devel] [PATCH] 0031 Add missing BuildRequires In-Reply-To: <4F6CCA91.4050409@redhat.com> References: <4F6CCA91.4050409@redhat.com> Message-ID: <20120323195922.GA3500@redhat.com> On Fri, 23 Mar 2012, Petr Viktorin wrote: >Since our build process runs pylint, we need all Python dependencies >installed at RPM creation time. >This adds python-lxml and python-pyasn1 to BuildRequires. > >https://fedorahosted.org/freeipa/ticket/2538 > >Including patches for both master and ipa-2-2. ACK. -- / Alexander Bokovoy From rcritten at redhat.com Fri Mar 23 20:36:15 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Mar 2012 16:36:15 -0400 Subject: [Freeipa-devel] [PATCH] 995 update min version of 389-ds-base In-Reply-To: <4F6CCBBE.5010709@redhat.com> References: <4F6CAD2B.8040703@redhat.com> <4F6CCAFF.3090008@redhat.com> <4F6CCBBE.5010709@redhat.com> Message-ID: <4F6CDEBF.9090205@redhat.com> Petr Viktorin wrote: > On 03/23/2012 08:11 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Set new minimum version of 389-ds-base to fix db corruption during >>> upgrade problem. >>> >>> This patch is against 2.2. >> >> Corrected changelog entry. >> > > You've attached a different patch. Sigh, fixed now. TGIF. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-995-2-dbupgrade.patch Type: text/x-diff Size: 1615 bytes Desc: not available URL: From jdennis at redhat.com Fri Mar 23 21:33:54 2012 From: jdennis at redhat.com (John Dennis) Date: Fri, 23 Mar 2012 17:33:54 -0400 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F6C117B.1090807@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> <4F6C117B.1090807@redhat.com> Message-ID: <4F6CEC42.2050702@redhat.com> Attached is is a new patch addressing Petr's review comment as well as some sample output for illustration purposes (I suggest you review the example.txt). Rather than wading through a log of dialog in the previous emails let me address Petr's issues and how I addressed them. The option parsing is totally reworked (see example.txt). Not only is optparse being used, but the options have been simplified and appear in groups. The script can do a variety of different things so you must specify the mode you want it to run in. I don't see an obvious candidate for a default mode, plus most users will run it as a make target anyway obviating the need to specify any command line options. I logically divided the validation checks, one for checking the English source strings (pot file) and one for checking the translations (po files). These represent two of the three possible modes of operations. Petr's has said several times that he would prefer the English sources strings be checked by other tests. I presume he is referring to the unit tests, but we do not have any such unit test nor are we likely to (at least not for string validation). The reason is you have to have available the set of strings from the sources which have been marked for translation. It's a somewhat complicated process to produce that set of strings and that logic are part of the install/po area, namely the generation of the pot file. This is the only logical place I can see for performing tests and/or validation on (translatable) source strings. I do not envision the validation ever being part of a unit test, it is functionally very different. There is a good argument for generating a new pot file and validating it on every code check-in. This patch does not do that, instead it's done when the pot file is generated manually, but it would be trival to add that feature once this framework is in place. However a good case could be made for the gettext test currently implemented in test_i18n.py being invoked as a unit test but there would be some structural work needed to make that happen (e.g. assuring the test mo file is generated and pointed to and calling things through IPA Gettext classes and having the framework run in the context of that locale). But we've never had a failure in that area yet so I'd be inclined to defer that at the moment, open a new ticket to integrate the gettext test in test_i18n.py with the test_text.py in the unit tests and consider that a separate work item so as not let it interfere with getting this committed. Being able to run the gettext test in the translation directory is valuable none-the-less. It would be better if it were fully integrated with our Gettext classes in text.py but that is best left as another task. By dividing the validation checks between the pot file and po files I think I addressed the majority of Petr's concerns over the validation of source strings. Petr also alluded Transifex errors as if Transifex would somehow catch the translation problems, but no such error checking exists (actually I'm considering giving this code to upstream Transifex, they're entirely Python based and they might find parts of it useful) But wait there's more ... Some of the validations were producing false positives because the validator could not determine whether some uses of $ and % were valid or mangled syntax. So I added a pedantic flag. It's off by default and skips checking for errors which are unlikely to be present and are difficult to check. You can run the validation with --pedantic as a safeguard and interpret the results. I thought this was preferred to removing the ability to perform the checks whatsoever. I also added a --show-strings flag so along with a error message and location it will output the offending string(s). This if off by default for brevity purposes but is useful for those having to make fixes or just to better understand the nature of the error. I tried to make the error output a bit less verbose with better formatting. I updated .gitignore to ignore the generated test files. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: example.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0066-2-Replace-broken-i18n-shell-test-with-Python-test.patch Type: text/x-patch Size: 31792 bytes Desc: not available URL: From ohamada at redhat.com Fri Mar 23 22:05:55 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Fri, 23 Mar 2012 23:05:55 +0100 Subject: [Freeipa-devel] [PATCH] 996 fix unit tests In-Reply-To: <4F6CCB22.5040305@redhat.com> References: <4F6CCB22.5040305@redhat.com> Message-ID: <4F6CF3C3.3070303@redhat.com> On 03/23/2012 08:12 PM, Rob Crittenden wrote: > A few unit tests were failing due to new type enforcement and comman > support. > > Unit tests are passing 100% for me with this. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel You were faster. Works for me. ACK -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- An HTML attachment was scrubbed... URL: From ohamada at redhat.com Fri Mar 23 22:10:28 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Fri, 23 Mar 2012 23:10:28 +0100 Subject: [Freeipa-devel] [PATCH] 16 Netgroup nisdomain and hosts validation In-Reply-To: <1331795633.27127.3.camel@balmora.brq.redhat.com> References: <4F58B9A8.2000508@redhat.com> <1331307242.26839.24.camel@balmora.brq.redhat.com> <4F60BF41.3000301@redhat.com> <1331795633.27127.3.camel@balmora.brq.redhat.com> Message-ID: <4F6CF4D4.5020906@redhat.com> On 03/15/2012 08:13 AM, Martin Kosek wrote: > On Wed, 2012-03-14 at 16:54 +0100, Ondrej Hamada wrote: >> On 03/09/2012 04:34 PM, Martin Kosek wrote: >>> On Thu, 2012-03-08 at 14:52 +0100, Ondrej Hamada wrote: >>>> Netgroup nisdomain and hosts validation >>>> >>>> nisdomain validation: >>>> Added pattern to the 'nisdomain' parameter to validate the specified >>>> nisdomain name. According to most common use cases the same patter as >>>> for netgroup should fit. Unit-tests added. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2447 >>>> >>>> hosts validation: >>>> Added precallback to netgroup_add_member. It validates the specified >>>> hostnames and raises ValidationError exception for invalid hostnames. >>>> Unit-test added. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2448 >>> I checked the host validation part and it could be improved. Issue >>> described in #2447 (you have switched the ticket IDs) affects all >>> objects that allow external hosts, users, ..., i.e. those who call >>> add_external_post_callback in their post_callback. >>> >>> Should we fix all of these when we deal with this issue? Otherwise user >>> could do something like this: >>> # ipa sudorule-add-user foo --users=a+b >>> Rule name: foo >>> Enabled: TRUE >>> External User: a+b >>> >>> We could create a similar function called add_external_pre_callback() >>> and pass it attribute name and validating function (which would be >>> common with the linked object). It would then do the validation for all >>> these affected objects consistently and without redundant code. >>> >>> I didn't liked much the implemented pre_callback anyway >>> >>> + def pre_callback(self, ldap, dn, found, not_found, *keys, >>> **options): >>> + # validate entered hostnames >>> + if 'host' in options: >>> + invalid_hostnames=[] >>> + for hostname in options['host']: >>> + try: >>> + validate_hostname(hostname, False) >>> + except ValueError: >>> + invalid_hostnames.append(hostname) >>> + if invalid_hostnames: >>> + raise errors.ValidationError(name='host', >>> error='hostnames:\"%s\" contain invalid characters' % >>> ','.join(invalid_hostnames)) >>> + return dn >>> >>> I would rather raise the ValidationError with the first invalid hostname >>> and tell what's wrong (function validate_hostname tells it to you). If >>> you go with the proposed approach, you wouldn't have to deal with >>> formatting error messages, you would just raise the one returned by the >>> validator shared with the linked LDAP object (hostname, user, ...). >>> >>> Martin >> external_pre_callback function seems as a good idea, but there is a >> problem how to get the validators for various LDAP objects. For the >> hostname we already have one in ipalib.utils, but for the uid or group >> name we use only patterns specified in the parameter objects. >> >> Below I propose solution how to use the already defined parameter >> objects for validation (the only problem is that I have to assume, that >> it is always the first parameter in takes_params). Do you think this is >> a good approach? > I think the approach is OK, it can just be much improved in order to get > rid of the hardcoded parts. See comments below. > >> def add_external_pre_callback(memberattr, membertype, externalattr, >> ldap, dn, found, not_found, *keys, **options): >> """ >> Pre callback to validate external members. >> """ >> if membertype in options: >> validator = api.Object[membertype].takes_params[0] > You can use api.Object[membertype].params[memberattr] > >> for value in options[membertype]: >> try: >> validator(value) >> except errors.ValidationError as e: >> error_msg = e[(e.find(':')+1):] > You don't have to parse error message, you can just use e.name or > e.error right from the caught ValidationError. > >> raise errors.ValidationError(name=membertype, >> error=e[e.find(':')+1:]) >> return dn >> > nisdomain validation: Added pattern to the 'nisdomain' parameter to validate the specified nisdomain name. According to most common use cases the same pattern as for netgroup should fit. Unit-tests added. https://fedorahosted.org/freeipa/ticket/2448 'add_external_pre_callback' function was created to allow validation of all external members. Validation is based on usage of objects primary key parameter. The 'add_external_pre_callback' fucntion has to be called directly from in the 'pre_callback' function. This change affects netgroup, hbacrule and sudorule commands. Special validator is used only for hostname, the validator requires fully qualified domain name and enables the hostnames to contain underscores. Unit-tests added. https://fedorahosted.org/freeipa/ticket/2447 -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-16-2-Netgroup-nisdomain-and-hosts-validation.patch Type: text/x-patch Size: 26208 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 26 07:35:53 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 Mar 2012 09:35:53 +0200 Subject: [Freeipa-devel] [PATCH] 996 fix unit tests In-Reply-To: <4F6CF3C3.3070303@redhat.com> References: <4F6CCB22.5040305@redhat.com> <4F6CF3C3.3070303@redhat.com> Message-ID: <1332747353.6363.24.camel@balmora.brq.redhat.com> On Fri, 2012-03-23 at 23:05 +0100, Ondrej Hamada wrote: > On 03/23/2012 08:12 PM, Rob Crittenden wrote: > > A few unit tests were failing due to new type enforcement and comman > > support. > > > > Unit tests are passing 100% for me with this. > > > > rob > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > You were faster. Works for me. > > ACK Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Mon Mar 26 07:39:50 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 Mar 2012 09:39:50 +0200 Subject: [Freeipa-devel] [PATCH] 0031 Add missing BuildRequires In-Reply-To: <20120323195922.GA3500@redhat.com> References: <4F6CCA91.4050409@redhat.com> <20120323195922.GA3500@redhat.com> Message-ID: <1332747590.6363.25.camel@balmora.brq.redhat.com> On Fri, 2012-03-23 at 21:59 +0200, Alexander Bokovoy wrote: > On Fri, 23 Mar 2012, Petr Viktorin wrote: > >Since our build process runs pylint, we need all Python dependencies > >installed at RPM creation time. > >This adds python-lxml and python-pyasn1 to BuildRequires. > > > >https://fedorahosted.org/freeipa/ticket/2538 > > > >Including patches for both master and ipa-2-2. > > ACK. > Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Mon Mar 26 07:51:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 Mar 2012 09:51:49 +0200 Subject: [Freeipa-devel] [PATCH] 995 update min version of 389-ds-base In-Reply-To: <4F6CDEBF.9090205@redhat.com> References: <4F6CAD2B.8040703@redhat.com> <4F6CCAFF.3090008@redhat.com> <4F6CCBBE.5010709@redhat.com> <4F6CDEBF.9090205@redhat.com> Message-ID: <1332748309.6363.26.camel@balmora.brq.redhat.com> On Fri, 2012-03-23 at 16:36 -0400, Rob Crittenden wrote: > Petr Viktorin wrote: > > On 03/23/2012 08:11 PM, Rob Crittenden wrote: > >> Rob Crittenden wrote: > >>> Set new minimum version of 389-ds-base to fix db corruption during > >>> upgrade problem. > >>> > >>> This patch is against 2.2. > >> > >> Corrected changelog entry. > >> > > > > You've attached a different patch. > > Sigh, fixed now. > > TGIF. > > rob > ACK. Rebaed for ipa-2-2/master branch and pushed to master, ipa-2-2. Martin From pviktori at redhat.com Mon Mar 26 08:24:01 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 Mar 2012 10:24:01 +0200 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F6CEC42.2050702@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> <4F6C117B.1090807@redhat.com> <4F6CEC42.2050702@redhat.com> Message-ID: <4F7027A1.7060006@redhat.com> On 03/23/2012 10:33 PM, John Dennis wrote: > Attached is is a new patch addressing Petr's review comment as well as > some sample output for illustration purposes (I suggest you review the > example.txt). > > Rather than wading through a log of dialog in the previous emails let me > address Petr's issues and how I addressed them. > > The option parsing is totally reworked (see example.txt). Not only is > optparse being used, but the options have been simplified and appear in > groups. The script can do a variety of different things so you must > specify the mode you want it to run in. I don't see an obvious candidate > for a default mode, plus most users will run it as a make target anyway > obviating the need to specify any command line options. > > I logically divided the validation checks, one for checking the English > source strings (pot file) and one for checking the translations (po > files). These represent two of the three possible modes of operations. > > Petr's has said several times that he would prefer the English sources > strings be checked by other tests. I presume he is referring to the unit > tests, but we do not have any such unit test nor are we likely to (at > least not for string validation). The reason is you have to have > available the set of strings from the sources which have been marked for > translation. It's a somewhat complicated process to produce that set of > strings and that logic are part of the install/po area, namely the > generation of the pot file. This is the only logical place I can see for > performing tests and/or validation on (translatable) source strings. I > do not envision the validation ever being part of a unit test, it is > functionally very different. There is a good argument for generating a > new pot file and validating it on every code check-in. This patch does > not do that, instead it's done when the pot file is generated manually, > but it would be trival to add that feature once this framework is in place. > > However a good case could be made for the gettext test currently > implemented in test_i18n.py being invoked as a unit test but there would > be some structural work needed to make that happen (e.g. assuring the > test mo file is generated and pointed to and calling things through IPA > Gettext classes and having the framework run in the context of that > locale). But we've never had a failure in that area yet so I'd be > inclined to defer that at the moment, open a new ticket to integrate the > gettext test in test_i18n.py with the test_text.py in the unit tests and > consider that a separate work item so as not let it interfere with > getting this committed. Being able to run the gettext test in the > translation directory is valuable none-the-less. It would be better if > it were fully integrated with our Gettext classes in text.py but that is > best left as another task. > > By dividing the validation checks between the pot file and po files I > think I addressed the majority of Petr's concerns over the validation of > source strings. Petr also alluded Transifex errors as if Transifex would > somehow catch the translation problems, but no such error checking > exists (actually I'm considering giving this code to upstream Transifex, > they're entirely Python based and they might find parts of it useful) > > But wait there's more ... > > Some of the validations were producing false positives because the > validator could not determine whether some uses of $ and % were valid or > mangled syntax. So I added a pedantic flag. It's off by default and > skips checking for errors which are unlikely to be present and are > difficult to check. You can run the validation with --pedantic as a > safeguard and interpret the results. I thought this was preferred to > removing the ability to perform the checks whatsoever. > > I also added a --show-strings flag so along with a error message and > location it will output the offending string(s). This if off by default > for brevity purposes but is useful for those having to make fixes or > just to better understand the nature of the error. > > I tried to make the error output a bit less verbose with better formatting. > > I updated .gitignore to ignore the generated test files. > Great! Just two issues now. According to the style guide, we do allow %s in a string iff it only appears once. The reason for named substitutions is that the word order can be changed, providing context is just secondary. Why does the checker report messages with a single %s as errors? You've removed test_lang from Makefile.in, but test and .PHONY still mention it. -- Petr? From pviktori at redhat.com Mon Mar 26 11:11:40 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 Mar 2012 13:11:40 +0200 Subject: [Freeipa-devel] [PATCH] 0027 Use valid argument names in tests In-Reply-To: <4F60C123.3040203@redhat.com> References: <4F60C123.3040203@redhat.com> Message-ID: <4F704EEC.8070407@redhat.com> On 03/14/2012 05:02 PM, Petr Viktorin wrote: > This patch depends on my patch 0024 (but I can rebase if it needs to be > pushed earlied). > > It fixes some of the test bugs that would be found by a fix for > https://fedorahosted.org/freeipa/ticket/2509 (Unknown Command arguments > are allowed (and ignored)). > > As you can see it's quite easy, without validation, to use a wrong name > for an argument. > > Unfortunately, some of our plugins (automount, dns, delegation, > permission, selfservice) take advantage of the current sloppy > validation, so they'll need some untangling for 3.x to make them more > robust and testable. For now I'm just touching the tests, so we don't > get new bugs in production code. > Rebased onto current master -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0027-01-Use-valid-argument-names-in-tests.patch Type: text/x-patch Size: 8094 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 26 12:29:21 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 Mar 2012 14:29:21 +0200 Subject: [Freeipa-devel] [PATCH] 994 set nsslapd-minssf-exclude-rootdse In-Reply-To: <4F6B97EE.1090306@redhat.com> References: <4F6B97EE.1090306@redhat.com> Message-ID: <1332764961.6363.67.camel@balmora.brq.redhat.com> On Thu, 2012-03-22 at 17:21 -0400, Rob Crittenden wrote: > If minssf is set in configuration and this is not set then clients won't > be able to detect the available namingContexts, defaultNamingContext, > capabilities, etc. > > This was requested by the SSSD team. > > rob ACK. Works fine - RootDSE is not accessible even with lower SSF than minSSF. Martin From mkosek at redhat.com Mon Mar 26 12:31:05 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 Mar 2012 14:31:05 +0200 Subject: [Freeipa-devel] [PATCH] 994 set nsslapd-minssf-exclude-rootdse In-Reply-To: <1332764961.6363.67.camel@balmora.brq.redhat.com> References: <4F6B97EE.1090306@redhat.com> <1332764961.6363.67.camel@balmora.brq.redhat.com> Message-ID: <1332765065.6363.69.camel@balmora.brq.redhat.com> On Mon, 2012-03-26 at 14:29 +0200, Martin Kosek wrote: > On Thu, 2012-03-22 at 17:21 -0400, Rob Crittenden wrote: > > If minssf is set in configuration and this is not set then clients won't > > be able to detect the available namingContexts, defaultNamingContext, > > capabilities, etc. > > > > This was requested by the SSSD team. > > > > rob > > ACK. Works fine - RootDSE is not accessible even with lower SSF than > minSSF. > > Martin > ... and pushed to master, ipa-2-2. Martin From simo at redhat.com Mon Mar 26 12:37:41 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 26 Mar 2012 08:37:41 -0400 Subject: [Freeipa-devel] [PATCH] 994 set nsslapd-minssf-exclude-rootdse In-Reply-To: <1332764961.6363.67.camel@balmora.brq.redhat.com> References: <4F6B97EE.1090306@redhat.com> <1332764961.6363.67.camel@balmora.brq.redhat.com> Message-ID: <1332765461.22628.0.camel@willson.li.ssimo.org> On Mon, 2012-03-26 at 14:29 +0200, Martin Kosek wrote: > On Thu, 2012-03-22 at 17:21 -0400, Rob Crittenden wrote: > > If minssf is set in configuration and this is not set then clients won't > > be able to detect the available namingContexts, defaultNamingContext, > > capabilities, etc. > > > > This was requested by the SSSD team. > > > > rob > > ACK. Works fine - RootDSE is not accessible even with lower SSF than I hope you meant *now* :-) > minSSF. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Mon Mar 26 12:42:51 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 Mar 2012 14:42:51 +0200 Subject: [Freeipa-devel] [PATCH] 994 set nsslapd-minssf-exclude-rootdse In-Reply-To: <1332765461.22628.0.camel@willson.li.ssimo.org> References: <4F6B97EE.1090306@redhat.com> <1332764961.6363.67.camel@balmora.brq.redhat.com> <1332765461.22628.0.camel@willson.li.ssimo.org> Message-ID: <1332765771.6363.71.camel@balmora.brq.redhat.com> On Mon, 2012-03-26 at 08:37 -0400, Simo Sorce wrote: > On Mon, 2012-03-26 at 14:29 +0200, Martin Kosek wrote: > > On Thu, 2012-03-22 at 17:21 -0400, Rob Crittenden wrote: > > > If minssf is set in configuration and this is not set then clients won't > > > be able to detect the available namingContexts, defaultNamingContext, > > > capabilities, etc. > > > > > > This was requested by the SSSD team. > > > > > > rob > > > > ACK. Works fine - RootDSE is not accessible even with lower SSF than > > I hope you meant *now* :-) The answer is "yes" of course - I should type slower :-) > > > minSSF. > > > > Martin > > From jcholast at redhat.com Mon Mar 26 13:47:50 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 26 Mar 2012 15:47:50 +0200 Subject: [Freeipa-devel] [PATCH] 72 Fix uses of O=REALM instead of the configured certificate subject base Message-ID: <4F707386.1060805@redhat.com> https://fedorahosted.org/freeipa/ticket/2521 Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-72-certificate-subject-base.patch Type: text/x-patch Size: 7054 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 26 14:15:07 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 10:15:07 -0400 Subject: [Freeipa-devel] [PATCH] 72 Fix uses of O=REALM instead of the configured certificate subject base In-Reply-To: <4F707386.1060805@redhat.com> References: <4F707386.1060805@redhat.com> Message-ID: <4F7079EB.2040404@redhat.com> Jan Cholasta wrote: > https://fedorahosted.org/freeipa/ticket/2521 > > Honza You can still set a custom subject base for selfsign installations so you need a special case in valid_issuer(). I wonder if this comparison should be case insensitive too. It may also be an optimization to cache the base in subject_base(). It can't change after install time so it should be valid the entire lifetime of the server. rob From mkosek at redhat.com Mon Mar 26 14:44:07 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 Mar 2012 16:44:07 +0200 Subject: [Freeipa-devel] [PATCH] 42-3 Add CleanRUV Task to ipa-replica-manage del In-Reply-To: <1B46CFF1-10A1-4FC4-84A3-0DC6F12B1849@citrixonline.com> References: <9F1E9A8C-EB82-4F21-8717-9DD6FB1F4820@citrixonline.com> <1B46CFF1-10A1-4FC4-84A3-0DC6F12B1849@citrixonline.com> Message-ID: <1332773047.6363.87.camel@balmora.brq.redhat.com> On Wed, 2012-02-29 at 07:10 +0000, JR Aquino wrote: > On Feb 28, 2012, at 10:44 AM, JR Aquino wrote: > > > > > > > On Feb 24, 2012, at 3:09 PM, JR Aquino wrote: > > > >> ipa-replica-manage del causes tombstone entries to remain in 389 DS. This has proven to be problematic. > >> We can automatically perform the cleanup task at the deletion time to minimize orphans and ghosts in the directory. > >> > >> This patch runs the cleanruv action on all masters following a delete. > >> https://fedorahosted.org/freeipa/ticket/2303 > > > > Rebased and corrected patch attached > > NACK > > Testing turned up a missed case for handling an exception during --force. > > Corrected patch attached Hello JR, I reviewed and tested your patch and have few comments. 1) It needs rebasing, otherwise indentation of this block is weird: + # Get list of Masters + dn = 'cn=masters,cn=ipa,cn=etc,%s' % thisrepl.suffix + res = thisrepl.conn.search_s(dn, ldap.SCOPE_ONELEVEL) + master_names = [] + for entry in res: + master_names.append(entry.cn) + if force_del: - dn = 'cn=masters,cn=ipa,cn=etc,%s' % thisrepl.suffix - res = thisrepl.conn.search_s(dn, ldap.SCOPE_ONELEVEL) - replica_names = [] - for entry in res: - replica_names.append(entry.cn) + replica_names = master_names We don't need to set replica_names in the "for" loop (i.e. for each master). master_names array creation could be created with a simpler construct: master_names = [ entry.cn for entry in res ] 2) Error message improvement When I tried to remove replica agreement and one of the replicas (vm-062.idm.lab.bos.redhat.com) was down, Clean RUV task on this replica failed as expected but I never get a message about which replica it was: # ipa-replica-manage del vm-071.idm.lab.bos.redhat.com Deleting a master is irreversible. To reconnect to the remote master you will need to prepare a new replica file and re-install. Continue to delete? [no]: y Deleted replication agreement from 'vm-022.idm.lab.bos.redhat.com' to 'vm-071.idm.lab.bos.redhat.com' Deleted replication agreement from 'vm-115.idm.lab.bos.redhat.com' to 'vm-071.idm.lab.bos.redhat.com' Cleaned RUV entry for 'vm-071.idm.lab.bos.redhat.com' on 'vm-022.idm.lab.bos.redhat.com' Cleaned RUV entry for 'vm-071.idm.lab.bos.redhat.com' on 'vm-115.idm.lab.bos.redhat.com' {'desc': "Can't contact LDAP server"} Please refer to http://directory.fedoraproject.org/wiki/Howto:CLEANRUV for manual cleanup. I just got: {'desc': "Can't contact LDAP server"} Please refer to http://directory.fedoraproject.org/wiki/Howto:CLEANRUV for manual cleanup. I would expect a more explaining error, something like: Error: Can't contact LDAP server Failed to clean RUV entry for 'vm-071.idm.lab.bos.redhat.com' on 'vm-062.idm.lab.bos.redhat.com': Please refer to http://directory.fedoraproject.org/wiki/Howto:CLEANRUV for manual cleanup. 3) Redundant exception I this this try..except statement is redundant as you don't perform anything in the except part: + try: + repl1 = replication.ReplicationManager(realm, replica1, dirman_passwd) + + replica_dn = repl1.replica_dn() + + attr = 'CLEANRUV%s' % delrepl_id + mod = [(ldap.MOD_REPLACE, 'nsds5task', attr)] + repl1.conn.modify_s(replica_dn, mod) + + except Exception, e: + raise e 4) Bad tombstone replication When I started the replica that was down during RUV cleanup, tombstone was replicated again to all replicas. This would mean that manual CleanRUV would have to be run on _all_ replicas again and not just the one that was down. Are we OK with this? If yes, then it would be nice to mention this information in the error message. Martin From rcritten at redhat.com Mon Mar 26 14:54:45 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 10:54:45 -0400 Subject: [Freeipa-devel] [PATCH] 0014 Add final debug message in installers In-Reply-To: <4F6C9049.3030507@redhat.com> References: <4F44B860.9050809@redhat.com> <4F4BB48C.7010200@redhat.com> <1330535684.32367.30.camel@balmora.brq.redhat.com> <4F4E728C.2070109@redhat.com> <4F4F5363.4030408@redhat.com> <4F61C4BC.60809@redhat.com> <4F6C9049.3030507@redhat.com> Message-ID: <4F708335.7030400@redhat.com> Petr Viktorin wrote: > On 03/15/2012 11:30 AM, Petr Viktorin wrote: >> On 03/01/2012 11:45 AM, Petr Viktorin wrote: >>> On 02/29/2012 07:46 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On Mon, 2012-02-27 at 17:51 +0100, Petr Viktorin wrote: >>>>>> On 02/22/2012 10:41 AM, Petr Viktorin wrote: >>>>>>> This fixes https://fedorahosted.org/freeipa/ticket/2071 (Add final >>>>>>> debug >>>>>>> message in installers). The try/except blocks at the end of >>>>>>> installers/management scripts are replaced by a call to a common >>>>>>> function, which includes the final message. >>>>>>> >>>>>>> Obviously the installers still need some more love. This is as far >>>>>>> as I >>>>>>> got before Martin stopped me, saying I shouldn't change too much >>>>>>> before >>>>>>> a release :) >>>>>>> >>>>>>> >>>>>>> If it's still too many changes to test, I could just wrap the >>>>>>> blocks in >>>>>>> some `with add_final_message` block for now, and resubmit this patch >>>>>>> after the release. >>>>>>> >>>>>>> >>>>> >>>>> Yeah, this is exactly the kind of changes that can have yet-unseen >>>>> consequences and I don't like pushing this close to the release. >>>>> >>>>> The original ticket just asks for a debug message when the install >>>>> script ends. If possible, I would really prefer to have some low-risk >>>>> patch adding just those and leave install script refactoring for next >>>>> big release, like 3.x. Rob, what's your opinion on this? >>>>> >>>>> Martin >>>>> >>>> >>>> Yes, I agree. Simpler is better at this point. >>>> >>>> rob >>> >>> This patch simply wraps the try blocks in a context that logs the final >>> result. >>> Most of the changes are indentation; diff with -w to see the additions. >>> >>> Not sure if this would count as an update or a new patch... >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Rebased against current master. >> >> >> > > Rebased again. Some minor compliants. If you abort the installation you get this somewhat unnerving error: Continue to configure the system with these values? [no]: ipa : ERROR ipa-server-install failed, SystemExit: Installation aborted Installation aborted ipa-ldap-updater is the same: # ipa-ldap-updater [2012-03-26T14:53:41Z ipa] : ipa-ldap-updater failed, SystemExit: IPA is not configured on this system. IPA is not configured on this system. and ipa-upgradeconfig $ ipa-upgradeconfig [2012-03-26T14:54:05Z ipa] : ipa-upgradeconfig failed, SystemExit: You must be root to run this script. You must be root to run this script. I'm guessing that the issue is that the log file isn't opened yet. It would be nice if the logging would be confined to just the log. When uninstalling you get the message 'ipa-server-install successful'. This is a little odd as well. rob From rcritten at redhat.com Mon Mar 26 15:14:50 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 11:14:50 -0400 Subject: [Freeipa-devel] [PATCH] 0027 Use valid argument names in tests In-Reply-To: <4F704EEC.8070407@redhat.com> References: <4F60C123.3040203@redhat.com> <4F704EEC.8070407@redhat.com> Message-ID: <4F7087EA.5070105@redhat.com> Petr Viktorin wrote: > On 03/14/2012 05:02 PM, Petr Viktorin wrote: >> This patch depends on my patch 0024 (but I can rebase if it needs to be >> pushed earlied). >> >> It fixes some of the test bugs that would be found by a fix for >> https://fedorahosted.org/freeipa/ticket/2509 (Unknown Command arguments >> are allowed (and ignored)). >> >> As you can see it's quite easy, without validation, to use a wrong name >> for an argument. >> >> Unfortunately, some of our plugins (automount, dns, delegation, >> permission, selfservice) take advantage of the current sloppy >> validation, so they'll need some untangling for 3.x to make them more >> robust and testable. For now I'm just touching the tests, so we don't >> get new bugs in production code. >> > > Rebased onto current master ACK, pushed to master and ipa-2-2. rob From jcholast at redhat.com Mon Mar 26 15:28:52 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 26 Mar 2012 17:28:52 +0200 Subject: [Freeipa-devel] [PATCH] 72 Fix uses of O=REALM instead of the configured certificate subject base In-Reply-To: <4F7079EB.2040404@redhat.com> References: <4F707386.1060805@redhat.com> <4F7079EB.2040404@redhat.com> Message-ID: <4F708B34.3080106@redhat.com> On 26.3.2012 16:15, Rob Crittenden wrote: > Jan Cholasta wrote: >> https://fedorahosted.org/freeipa/ticket/2521 >> >> Honza > > You can still set a custom subject base for selfsign installations so > you need a special case in valid_issuer(). For selfsign installations, the issuer is always "CN=REALM Certificate Authority", no matter what is set in the subject base, so no special case is needed. > I wonder if this comparison > should be case insensitive too. I think the DN class already takes care of this. > > It may also be an optimization to cache the base in subject_base(). It > can't change after install time so it should be valid the entire > lifetime of the server. What if someone does $ ipa config-mod --setattr ipacertificatesubjectbase='O=Something' ? > > rob Honza -- Jan Cholasta From jgalipea at redhat.com Mon Mar 26 15:30:07 2012 From: jgalipea at redhat.com (Jenny Galipeau) Date: Mon, 26 Mar 2012 11:30:07 -0400 Subject: [Freeipa-devel] [PATCH] 72 Fix uses of O=REALM instead of the configured certificate subject base In-Reply-To: <4F708B34.3080106@redhat.com> References: <4F707386.1060805@redhat.com> <4F7079EB.2040404@redhat.com> <4F708B34.3080106@redhat.com> Message-ID: <4F708B7F.8080600@redhat.com> On 03/26/2012 11:28 AM, Jan Cholasta wrote: > On 26.3.2012 16:15, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> https://fedorahosted.org/freeipa/ticket/2521 >>> >>> Honza >> >> You can still set a custom subject base for selfsign installations so >> you need a special case in valid_issuer(). > > For selfsign installations, the issuer is always "CN=REALM Certificate > Authority", no matter what is set in the subject base, so no special > case is needed. > >> I wonder if this comparison >> should be case insensitive too. > > I think the DN class already takes care of this. > >> >> It may also be an optimization to cache the base in subject_base(). It >> can't change after install time so it should be valid the entire >> lifetime of the server. > > What if someone does > > $ ipa config-mod --setattr ipacertificatesubjectbase='O=Something' > > ? :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: ipaconfig-mod_setattr ipacertificatesubjectbase positive :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: Set ipapwdexpadvnotify to OU=Bogus :: [ PASS ] :: ipacertificatesubjectbase successfully changed. :: [ LOG ] :: Duration: 3s :: [ LOG ] :: Assertions: 2 good, 0 bad :: [ PASS ] :: RESULT: ipaconfig-mod_setattr ipacertificatesubjectbase positive It works ... should we be getting an error?? > >> >> rob > > Honza > -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ From pviktori at redhat.com Mon Mar 26 15:35:22 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 Mar 2012 17:35:22 +0200 Subject: [Freeipa-devel] [PATCH] 0014 Add final debug message in installers In-Reply-To: <4F708335.7030400@redhat.com> References: <4F44B860.9050809@redhat.com> <4F4BB48C.7010200@redhat.com> <1330535684.32367.30.camel@balmora.brq.redhat.com> <4F4E728C.2070109@redhat.com> <4F4F5363.4030408@redhat.com> <4F61C4BC.60809@redhat.com> <4F6C9049.3030507@redhat.com> <4F708335.7030400@redhat.com> Message-ID: <4F708CBA.9000608@redhat.com> On 03/26/2012 04:54 PM, Rob Crittenden wrote: > > Some minor compliants. Ideally, there would be a routine that sets up the logging and handles command-line arguments in some uniform way (which is also needed before logging setup to detect ipa-server-install --uninstall). The original patch did the common logging setup, and I hacked around the install/uninstall problem too. I guess I overdid it when I simplified the patch. I'm somewhat confused about the scope, so bear with me as I clarify what you mean. > If you abort the installation you get this somewhat unnerving error: > > Continue to configure the system with these values? [no]: > ipa : ERROR ipa-server-install failed, SystemExit: Installation aborted > Installation aborted > > ipa-ldap-updater is the same: > > # ipa-ldap-updater > [2012-03-26T14:53:41Z ipa] : ipa-ldap-updater failed, SystemExit: > IPA is not configured on this system. > IPA is not configured on this system. > > and ipa-upgradeconfig > > $ ipa-upgradeconfig > [2012-03-26T14:54:05Z ipa] : ipa-upgradeconfig failed, SystemExit: > You must be root to run this script. > > > You must be root to run this script. > > I'm guessing that the issue is that the log file isn't opened yet. > > It would be nice if the logging would be confined to just the log. If I understand you correctly, the code should check if logging has been configured already, and if not, skip displaying the message? > When uninstalling you get the message 'ipa-server-install successful'. > This is a little odd as well. ipa-server-install is the name of the command. Wontfix for now, unless you disagree strongly. -- Petr? From jdennis at redhat.com Mon Mar 26 15:49:27 2012 From: jdennis at redhat.com (John Dennis) Date: Mon, 26 Mar 2012 11:49:27 -0400 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F7027A1.7060006@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> <4F6C117B.1090807@redhat.com> <4F6CEC42.2050702@redhat.com> <4F7027A1.7060006@redhat.com> Message-ID: <4F709007.4060305@redhat.com> On 03/26/2012 04:24 AM, Petr Viktorin wrote: > Great! Just two issues now. > > According to the style guide, we do allow %s in a string iff it only > appears once. The reason for named substitutions is that the word order > can be changed, providing context is just secondary. > Why does the checker report messages with a single %s as errors? Good catch, I should have known better, I believe I was the one who wrote that section in the style guide, so I should have known better (or remembered better). Fixed. > You've removed test_lang from Makefile.in, but test and .PHONY still > mention it. Also fixed. Updated patch attached. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0066-3-Replace-broken-i18n-shell-test-with-Python-test.patch Type: text/x-patch Size: 32666 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 26 16:40:49 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 Mar 2012 18:40:49 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Check expected error messages in tests In-Reply-To: <4F687A8D.6020508@redhat.com> References: <4F687A8D.6020508@redhat.com> Message-ID: <4F709C11.1070800@redhat.com> On 03/20/2012 01:39 PM, Petr Viktorin wrote: > This patch adds checking error messages, not just types, to the XML-RPC > tests. > The checking is still somewhat hackish, since XML-RPC doesn't give us > structured error info, but it should protect against regressions on > issues like whether we put name or cli_name in a ValidationError. > > https://fedorahosted.org/freeipa/ticket/2549 > Updated and rebased to current master. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0029-01-Fix-expected-error-messages-in-tests.patch Type: text/x-patch Size: 68342 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 26 17:11:32 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 26 Mar 2012 19:11:32 +0200 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F709007.4060305@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> <4F6C117B.1090807@redhat.com> <4F6CEC42.2050702@redhat.com> <4F7027A1.7060006@redhat.com> <4F709007.4060305@redhat.com> Message-ID: <4F70A344.4050304@redhat.com> On 03/26/2012 05:49 PM, John Dennis wrote: > On 03/26/2012 04:24 AM, Petr Viktorin wrote: >> Great! Just two issues now. >> >> According to the style guide, we do allow %s in a string iff it only >> appears once. The reason for named substitutions is that the word order >> can be changed, providing context is just secondary. >> Why does the checker report messages with a single %s as errors? > > Good catch, I should have known better, I believe I was the one who > wrote that section in the style guide, so I should have known better (or > remembered better). Fixed. > >> You've removed test_lang from Makefile.in, but test and .PHONY still >> mention it. > > Also fixed. > > Updated patch attached. > Just a one-liner: The docstring of validate_anonymous_substitutions isn't up to par ??? there's a missing quote, extra ?a?, and the '%s occurred' has no context. I suggest: We do not permit multiple anonymous substitutions in translation strings (e.g. '%s') because they do not allow translators to reorder the wording. Instead keyword substitutions should be used when there are more than one. ACK if that's fixed -- Petr? From rcritten at redhat.com Mon Mar 26 17:40:37 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 13:40:37 -0400 Subject: [Freeipa-devel] [PATCH] 72 Fix uses of O=REALM instead of the configured certificate subject base In-Reply-To: <4F708B7F.8080600@redhat.com> References: <4F707386.1060805@redhat.com> <4F7079EB.2040404@redhat.com> <4F708B34.3080106@redhat.com> <4F708B7F.8080600@redhat.com> Message-ID: <4F70AA15.60001@redhat.com> Jenny Galipeau wrote: > On 03/26/2012 11:28 AM, Jan Cholasta wrote: >> On 26.3.2012 16:15, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> https://fedorahosted.org/freeipa/ticket/2521 >>>> >>>> Honza >>> >>> You can still set a custom subject base for selfsign installations so >>> you need a special case in valid_issuer(). >> >> For selfsign installations, the issuer is always "CN=REALM Certificate >> Authority", no matter what is set in the subject base, so no special >> case is needed. >> >>> I wonder if this comparison >>> should be case insensitive too. >> >> I think the DN class already takes care of this. >> >>> >>> It may also be an optimization to cache the base in subject_base(). It >>> can't change after install time so it should be valid the entire >>> lifetime of the server. >> >> What if someone does >> >> $ ipa config-mod --setattr ipacertificatesubjectbase='O=Something' >> >> ? > > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > :: [ LOG ] :: ipaconfig-mod_setattr ipacertificatesubjectbase positive > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > > :: [ PASS ] :: Set ipapwdexpadvnotify to OU=Bogus > :: [ PASS ] :: ipacertificatesubjectbase successfully changed. > :: [ LOG ] :: Duration: 3s > :: [ LOG ] :: Assertions: 2 good, 0 bad > :: [ PASS ] :: RESULT: ipaconfig-mod_setattr ipacertificatesubjectbase positive > > > It works ... should we be getting an error?? Yes, it should fail. I thought there was already a bug open on it, though maybe we just removed the option from -mod. rob From jgalipea at redhat.com Mon Mar 26 19:04:10 2012 From: jgalipea at redhat.com (Jenny Galipeau) Date: Mon, 26 Mar 2012 15:04:10 -0400 Subject: [Freeipa-devel] [PATCH] 72 Fix uses of O=REALM instead of the configured certificate subject base In-Reply-To: <4F70AA15.60001@redhat.com> References: <4F707386.1060805@redhat.com> <4F7079EB.2040404@redhat.com> <4F708B34.3080106@redhat.com> <4F708B7F.8080600@redhat.com> <4F70AA15.60001@redhat.com> Message-ID: <4F70BDAA.6040902@redhat.com> On 03/26/2012 01:40 PM, Rob Crittenden wrote: > Jenny Galipeau wrote: >> On 03/26/2012 11:28 AM, Jan Cholasta wrote: >>> On 26.3.2012 16:15, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> https://fedorahosted.org/freeipa/ticket/2521 >>>>> >>>>> Honza >>>> >>>> You can still set a custom subject base for selfsign installations so >>>> you need a special case in valid_issuer(). >>> >>> For selfsign installations, the issuer is always "CN=REALM Certificate >>> Authority", no matter what is set in the subject base, so no special >>> case is needed. >>> >>>> I wonder if this comparison >>>> should be case insensitive too. >>> >>> I think the DN class already takes care of this. >>> >>>> >>>> It may also be an optimization to cache the base in subject_base(). It >>>> can't change after install time so it should be valid the entire >>>> lifetime of the server. >>> >>> What if someone does >>> >>> $ ipa config-mod --setattr ipacertificatesubjectbase='O=Something' >>> >>> ? >> >> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >> >> :: [ LOG ] :: ipaconfig-mod_setattr ipacertificatesubjectbase >> positive >> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >> >> >> :: [ PASS ] :: Set ipapwdexpadvnotify to OU=Bogus >> :: [ PASS ] :: ipacertificatesubjectbase successfully changed. >> :: [ LOG ] :: Duration: 3s >> :: [ LOG ] :: Assertions: 2 good, 0 bad >> :: [ PASS ] :: RESULT: ipaconfig-mod_setattr >> ipacertificatesubjectbase positive >> >> >> It works ... should we be getting an error?? > > Yes, it should fail. I thought there was already a bug open on it, > though maybe we just removed the option from -mod. > > rob > Okay, I will log a bug. Will we are on this subject ... :-) Why is there option --certificate for host-add and service-add? You can not add a certificate if it doesn't match the expected issuer and assume you are doing that by checking issuer DN, based on the errror message. You can't add a service unless the host exists ... I am just not seeing the use case(s) for this! -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ From rcritten at redhat.com Mon Mar 26 19:49:56 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 15:49:56 -0400 Subject: [Freeipa-devel] [PATCH] 0029 Check expected error messages in tests In-Reply-To: <4F709C11.1070800@redhat.com> References: <4F687A8D.6020508@redhat.com> <4F709C11.1070800@redhat.com> Message-ID: <4F70C864.5050107@redhat.com> Petr Viktorin wrote: > On 03/20/2012 01:39 PM, Petr Viktorin wrote: >> This patch adds checking error messages, not just types, to the XML-RPC >> tests. >> The checking is still somewhat hackish, since XML-RPC doesn't give us >> structured error info, but it should protect against regressions on >> issues like whether we put name or cli_name in a ValidationError. >> >> https://fedorahosted.org/freeipa/ticket/2549 >> > > Updated and rebased to current master. NACK automember wrongly was testing for non-existent users rather than automember rules but those should still be tested IMHO, perhaps with both types. There is also some inconsistency. In host you use substitution to set the hostname in the error: '%s: host not found' % fqdn1 but in others (group, hostgroup for example) the name is hardcoded. I also noticed that some reasons are unicode and others are not. rob From rcritten at redhat.com Mon Mar 26 20:17:14 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 16:17:14 -0400 Subject: [Freeipa-devel] [PATCH] 72 Fix uses of O=REALM instead of the configured certificate subject base In-Reply-To: <4F708B34.3080106@redhat.com> References: <4F707386.1060805@redhat.com> <4F7079EB.2040404@redhat.com> <4F708B34.3080106@redhat.com> Message-ID: <4F70CECA.4040700@redhat.com> Jan Cholasta wrote: > On 26.3.2012 16:15, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> https://fedorahosted.org/freeipa/ticket/2521 >>> >>> Honza >> >> You can still set a custom subject base for selfsign installations so >> you need a special case in valid_issuer(). > > For selfsign installations, the issuer is always "CN=REALM Certificate > Authority", no matter what is set in the subject base, so no special > case is needed. > >> I wonder if this comparison >> should be case insensitive too. > > I think the DN class already takes care of this. > >> >> It may also be an optimization to cache the base in subject_base(). It >> can't change after install time so it should be valid the entire >> lifetime of the server. > > What if someone does > > $ ipa config-mod --setattr ipacertificatesubjectbase='O=Something' Ok, you're right about the issuer and DN case insensitivity, so we're good there. I think that caching is still a good idea. We'll handle the immutable subjectbase as a separate problem. This is really pretty minor and isn't a show stopper, you just have to revert it and things work again. rob From rcritten at redhat.com Mon Mar 26 20:27:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 16:27:29 -0400 Subject: [Freeipa-devel] [PATCH] 15 Confusing default user groups In-Reply-To: <4F6B5622.2090409@redhat.com> References: <4F565247.2050105@redhat.com> <1332174357.24427.47.camel@balmora.brq.redhat.com> <4F6B5622.2090409@redhat.com> Message-ID: <4F70D131.8090909@redhat.com> Ondrej Hamada wrote: > On 03/19/2012 05:25 PM, Martin Kosek wrote: >> On Tue, 2012-03-06 at 19:07 +0100, Ondrej Hamada wrote: >>> https://fedorahosted.org/freeipa/ticket/2354 >>> >>> There was added '(fallback)' string in the automember plugin labels >>> referring to automember default groups to point out, that the users are >>> already members of default group specified in IPA config, thus the >>> default group specified in automember will be additional one - a >>> fallback group. >> Hm, looks ok. Though I would also like some second opinion for this >> change. I think naming it simply "Fallback Group" would be better, but >> we cannot change the API at this stage and rename the parameter. So this >> change is a good compromise so far, IMO. >> >> I found few issues though: >> >> 1) The label of default group parameter in automember has not been >> updated, i.e. the following command still shows the old name: >> >> # ipa automember-default-group-show --type=group >> Default Group: >> cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >> >> 2) I think we could fix few issues in docstrings since we touch these >> strings anyway: >> >> a) Typo in doc >> >> - label=_('Default Group'), >> - doc=_('Default group for entires to land'), >> + label=_('Default (fallback) Group'), >> + doc=_('Default (fallback) group for entires to land'), >> >> b) Non-translatable strings: >> >> - entry_attrs['automemberdefaultgroup'] = u'No default group >> set' >> + entry_attrs['automemberdefaultgroup'] = u'No default >> (fallback) group set' >> >> >> - entry_attrs['automemberdefaultgroup'] = u'No default group >> set' >> + entry_attrs['automemberdefaultgroup'] = u'No default >> (fallback) group set' >> >> Martin >> > fixed > > Ondra Petr, related to handling in the UI, do you look for the string "No default group set' or just look for a string that isn't a dn? rob From jdennis at redhat.com Mon Mar 26 20:34:52 2012 From: jdennis at redhat.com (John Dennis) Date: Mon, 26 Mar 2012 16:34:52 -0400 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F70A344.4050304@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> <4F6C117B.1090807@redhat.com> <4F6CEC42.2050702@redhat.com> <4F7027A1.7060006@redhat.com> <4F709007.4060305@redhat.com> <4F70A344.4050304@redhat.com> Message-ID: <4F70D2EC.4050203@redhat.com> On 03/26/2012 01:11 PM, Petr Viktorin wrote: > Just a one-liner: The docstring of validate_anonymous_substitutions > isn't up to par ??? there's a missing quote, extra ?a?, and the '%s > occurred' has no context. I suggest: > > We do not permit multiple anonymous substitutions in translation > strings (e.g. '%s') because they do not allow translators to reorder the > wording. Instead keyword substitutions should be used when there are > more than one. > > > ACK if that's fixed Done, patch attached. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0066-4-Replace-broken-i18n-shell-test-with-Python-test.patch Type: text/x-patch Size: 32627 bytes Desc: not available URL: From jdennis at redhat.com Mon Mar 26 20:43:39 2012 From: jdennis at redhat.com (John Dennis) Date: Mon, 26 Mar 2012 16:43:39 -0400 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F70D2EC.4050203@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> <4F6C117B.1090807@redhat.com> <4F6CEC42.2050702@redhat.com> <4F7027A1.7060006@redhat.com> <4F709007.4060305@redhat.com> <4F70A344.4050304@redhat.com> <4F70D2EC.4050203@redhat.com> Message-ID: <4F70D4FB.6030605@redhat.com> On 03/26/2012 04:34 PM, John Dennis wrote: > On 03/26/2012 01:11 PM, Petr Viktorin wrote: >> Just a one-liner: The docstring of validate_anonymous_substitutions >> isn't up to par ??? there's a missing quote, extra ?a?, and the '%s >> occurred' has no context. I suggest: >> >> We do not permit multiple anonymous substitutions in translation >> strings (e.g. '%s') because they do not allow translators to reorder the >> wording. Instead keyword substitutions should be used when there are >> more than one. >> >> >> ACK if that's fixed > > Done, patch attached. Oh, I also meant to add that I've updated the unittest tests/test_ipalib/test_text.py to use the updated test_i18n.py code to exercise the GettextFactory and NGettextFactory classes in our framework. I'll open a new ticket for that along with a patch. With the above the unit tests will exercise at least a portion of translation pipeline in the framework. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Mar 26 20:44:30 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 16:44:30 -0400 Subject: [Freeipa-devel] [PATCHES] 0025-26 Test improvements In-Reply-To: <4F5DE9A6.90704@redhat.com> References: <4F5DE9A6.90704@redhat.com> Message-ID: <4F70D52E.5070101@redhat.com> Petr Viktorin wrote: > Patch 25 fixes errors I found by running pylint on the testsuite. They > were in code that was unused, either by error or because it only runs on > errors. > > Patch 26 adds a test for the batch plugin. In patch 25 the second test_internal_error should really be test_unauthorized_error. I think that is a clearer name. Otherwise looks good. Patch 26 needs a very minor rebase to fix an error caused by improved error code handling: expected = Fuzzy(u"invalid 'gidnumber'.*", , None) got = u"invalid 'gid': Gettext('must be an integer', domain='ipa', localedir=None)" I tested this: diff --git a/tests/test_xmlrpc/test_batch_plugin.py b/tests/test_xmlrpc/test_bat ch_plugin.py index e4280ed..d69bfd9 100644 --- a/tests/test_xmlrpc/test_batch_plugin.py +++ b/tests/test_xmlrpc/test_batch_plugin.py @@ -186,7 +186,7 @@ class test_batch(Declarative): dict(error=u"'params' is required"), dict(error=u"'givenname' is required"), dict(error=u"'description' is required"), - dict(error=Fuzzy(u"invalid 'gidnumber'.*")), + dict(error=Fuzzy(u"invalid 'gid'.*")), ), ), ), rob From rcritten at redhat.com Mon Mar 26 21:07:31 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 17:07:31 -0400 Subject: [Freeipa-devel] [PATCH] 236 Amend permissions for new DNS attributes In-Reply-To: <1331804645.27127.17.camel@balmora.brq.redhat.com> References: <1331804645.27127.17.camel@balmora.brq.redhat.com> Message-ID: <4F70DA93.5090802@redhat.com> Martin Kosek wrote: > New features in bind-dyndb-ldap and IPA DNS plugin pulled new > attributes and objectclasses. ACIs and permissions need to be > updated to allow users with appropriate permissions update > these attributes in LDAP. > > This patch updates the ACI for DNS record updates and adds one > new permission to update global DNS configuration. > > https://fedorahosted.org/freeipa/ticket/2510 ACK, pushed to master and ipa-2-2 rob From rcritten at redhat.com Mon Mar 26 21:43:35 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 17:43:35 -0400 Subject: [Freeipa-devel] [PATCH] 237 Improve user awareness about dnsconfig In-Reply-To: <1331816421.27127.18.camel@balmora.brq.redhat.com> References: <1331816421.27127.18.camel@balmora.brq.redhat.com> Message-ID: <4F70E307.3070602@redhat.com> Martin Kosek wrote: > Global DNS configuration is a nice tool to maintain a common DNS > settings stored in LDAP which are then used for all enrolled IPA > servers. However, the settings stored in LDAP override local > settings in named.conf on DNS servers. > > This patch adds more information about global DNS configuration > options in install scripts and DNS module help. > > https://fedorahosted.org/freeipa/ticket/2525 ACK, pushed to master and ipa-2-2 From pviktori at redhat.com Tue Mar 27 08:23:30 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 27 Mar 2012 10:23:30 +0200 Subject: [Freeipa-devel] [PATCHES] 0025-26 Test improvements In-Reply-To: <4F70D52E.5070101@redhat.com> References: <4F5DE9A6.90704@redhat.com> <4F70D52E.5070101@redhat.com> Message-ID: <4F717902.1060304@redhat.com> On 03/26/2012 10:44 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> Patch 25 fixes errors I found by running pylint on the testsuite. They >> were in code that was unused, either by error or because it only runs on >> errors. >> >> Patch 26 adds a test for the batch plugin. > > In patch 25 the second test_internal_error should really be > test_unauthorized_error. I think that is a clearer name. Otherwise looks > good. > > Patch 26 needs a very minor rebase to fix an error caused by improved > error code handling: > > expected = Fuzzy(u"invalid 'gidnumber'.*", , None) > got = u"invalid 'gid': Gettext('must be an integer', domain='ipa', > localedir=None)" > > I tested this: > > diff --git a/tests/test_xmlrpc/test_batch_plugin.py > b/tests/test_xmlrpc/test_bat > ch_plugin.py > index e4280ed..d69bfd9 100644 > --- a/tests/test_xmlrpc/test_batch_plugin.py > +++ b/tests/test_xmlrpc/test_batch_plugin.py > @@ -186,7 +186,7 @@ class test_batch(Declarative): > dict(error=u"'params' is required"), > dict(error=u"'givenname' is required"), > dict(error=u"'description' is required"), > - dict(error=Fuzzy(u"invalid 'gidnumber'.*")), > + dict(error=Fuzzy(u"invalid 'gid'.*")), > ), > ), > ), > > rob Thank you! Fixed, attaching updated patches. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0025-02-Fix-little-test-errors.patch Type: text/x-patch Size: 3560 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0026-02-Test-the-batch-plugin.patch Type: text/x-patch Size: 10184 bytes Desc: not available URL: From mkosek at redhat.com Tue Mar 27 08:43:36 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Mar 2012 10:43:36 +0200 Subject: [Freeipa-devel] [PATCH] 70 Parse zone indices in IPv6 addresses in CheckedIPAddress In-Reply-To: <4F672E7B.1050103@redhat.com> References: <4F672E7B.1050103@redhat.com> Message-ID: <1332837816.9937.20.camel@balmora.brq.redhat.com> On Mon, 2012-03-19 at 14:02 +0100, Jan Cholasta wrote: > https://fedorahosted.org/freeipa/ticket/2138 > > Honza > This will work, I just think that a documentation of this issue can be improved. 1) A short comment in the following part explaining why do we partition by % would clarify it for non-IPv6 experts + except netaddr.AddrFormatError: <<< + addr = str(addr).partition('%')[0] + addr = netaddr.IPAddress(addr, flags=self.netaddr_ip_flags) + if addr.version != 6: 2) Patch comment can be improved as well Thanks, Martin From pviktori at redhat.com Tue Mar 27 09:04:17 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 27 Mar 2012 11:04:17 +0200 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F70D2EC.4050203@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> <4F6C117B.1090807@redhat.com> <4F6CEC42.2050702@redhat.com> <4F7027A1.7060006@redhat.com> <4F709007.4060305@redhat.com> <4F70A344.4050304@redhat.com> <4F70D2EC.4050203@redhat.com> Message-ID: <4F718291.9080105@redhat.com> On 03/26/2012 10:34 PM, John Dennis wrote: > On 03/26/2012 01:11 PM, Petr Viktorin wrote: >> Just a one-liner: The docstring of validate_anonymous_substitutions >> isn't up to par ??? there's a missing quote, extra ?a?, and the '%s >> occurred' has no context. I suggest: >> >> We do not permit multiple anonymous substitutions in translation >> strings (e.g. '%s') because they do not allow translators to reorder the >> wording. Instead keyword substitutions should be used when there are >> more than one. >> >> >> ACK if that's fixed > > Done, patch attached. > ACK -- Petr? From jcholast at redhat.com Tue Mar 27 09:50:40 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 27 Mar 2012 11:50:40 +0200 Subject: [Freeipa-devel] [PATCH] 70 Parse zone indices in IPv6 addresses in CheckedIPAddress In-Reply-To: <1332837816.9937.20.camel@balmora.brq.redhat.com> References: <4F672E7B.1050103@redhat.com> <1332837816.9937.20.camel@balmora.brq.redhat.com> Message-ID: <4F718D70.9050205@redhat.com> On 27.3.2012 10:43, Martin Kosek wrote: > On Mon, 2012-03-19 at 14:02 +0100, Jan Cholasta wrote: >> https://fedorahosted.org/freeipa/ticket/2138 >> >> Honza >> > > This will work, I just think that a documentation of this issue can be > improved. > > 1) A short comment in the following part explaining why do we partition > by % would clarify it for non-IPv6 experts > > + except netaddr.AddrFormatError: > <<< > + addr = str(addr).partition('%')[0] > + addr = netaddr.IPAddress(addr, flags=self.netaddr_ip_flags) > + if addr.version != 6: > > 2) Patch comment can be improved as well > > Thanks, > Martin > Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-70.1-ipv6-zone-index.patch Type: text/x-patch Size: 2543 bytes Desc: not available URL: From mkosek at redhat.com Tue Mar 27 10:04:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Mar 2012 12:04:19 +0200 Subject: [Freeipa-devel] [PATCH] 70 Parse zone indices in IPv6 addresses in CheckedIPAddress In-Reply-To: <4F718D70.9050205@redhat.com> References: <4F672E7B.1050103@redhat.com> <1332837816.9937.20.camel@balmora.brq.redhat.com> <4F718D70.9050205@redhat.com> Message-ID: <1332842659.9937.29.camel@balmora.brq.redhat.com> On Tue, 2012-03-27 at 11:50 +0200, Jan Cholasta wrote: > On 27.3.2012 10:43, Martin Kosek wrote: > > On Mon, 2012-03-19 at 14:02 +0100, Jan Cholasta wrote: > >> https://fedorahosted.org/freeipa/ticket/2138 > >> > >> Honza > >> > > > > This will work, I just think that a documentation of this issue can be > > improved. > > > > 1) A short comment in the following part explaining why do we partition > > by % would clarify it for non-IPv6 experts > > > > + except netaddr.AddrFormatError: > > <<< > > + addr = str(addr).partition('%')[0] > > + addr = netaddr.IPAddress(addr, flags=self.netaddr_ip_flags) > > + if addr.version != 6: > > > > 2) Patch comment can be improved as well > > > > Thanks, > > Martin > > > > Updated patch attached. > > Honza > ACK. Pushed to master, ipa-2-2. Martin From pvoborni at redhat.com Tue Mar 27 10:39:15 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 27 Mar 2012 12:39:15 +0200 Subject: [Freeipa-devel] [PATCH] 15 Confusing default user groups In-Reply-To: <4F70D131.8090909@redhat.com> References: <4F565247.2050105@redhat.com> <1332174357.24427.47.camel@balmora.brq.redhat.com> <4F6B5622.2090409@redhat.com> <4F70D131.8090909@redhat.com> Message-ID: <4F7198D3.9090700@redhat.com> On 03/26/2012 10:27 PM, Rob Crittenden wrote: > Ondrej Hamada wrote: >> On 03/19/2012 05:25 PM, Martin Kosek wrote: >>> On Tue, 2012-03-06 at 19:07 +0100, Ondrej Hamada wrote: >>>> https://fedorahosted.org/freeipa/ticket/2354 >>>> >>>> There was added '(fallback)' string in the automember plugin labels >>>> referring to automember default groups to point out, that the users are >>>> already members of default group specified in IPA config, thus the >>>> default group specified in automember will be additional one - a >>>> fallback group. >>> Hm, looks ok. Though I would also like some second opinion for this >>> change. I think naming it simply "Fallback Group" would be better, but >>> we cannot change the API at this stage and rename the parameter. So this >>> change is a good compromise so far, IMO. >>> >>> I found few issues though: >>> >>> 1) The label of default group parameter in automember has not been >>> updated, i.e. the following command still shows the old name: >>> >>> # ipa automember-default-group-show --type=group >>> Default Group: >>> cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>> >>> 2) I think we could fix few issues in docstrings since we touch these >>> strings anyway: >>> >>> a) Typo in doc >>> >>> - label=_('Default Group'), >>> - doc=_('Default group for entires to land'), >>> + label=_('Default (fallback) Group'), >>> + doc=_('Default (fallback) group for entires to land'), >>> >>> b) Non-translatable strings: >>> >>> - entry_attrs['automemberdefaultgroup'] = u'No default group >>> set' >>> + entry_attrs['automemberdefaultgroup'] = u'No default >>> (fallback) group set' >>> >>> >>> - entry_attrs['automemberdefaultgroup'] = u'No default group >>> set' >>> + entry_attrs['automemberdefaultgroup'] = u'No default >>> (fallback) group set' >>> >>> Martin >>> >> fixed >> >> Ondra > > Petr, related to handling in the UI, do you look for the string "No > default group set' or just look for a string that isn't a dn? > > rob We are checking if the string looks like dn - if it contains 'cn='. If not, we consider it as an error message. -- Petr Vobornik From mkosek at redhat.com Tue Mar 27 11:06:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Mar 2012 13:06:00 +0200 Subject: [Freeipa-devel] [PATCH] 244 Fix dnsrecord-del interactive mode Message-ID: <1332846360.9937.30.camel@balmora.brq.redhat.com> User was not able to select multiple values in dnsrecord-del interactive mode. https://fedorahosted.org/freeipa/ticket/2581 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-244-fix-dnsrecord-del-interactive-mode.patch Type: text/x-patch Size: 1027 bytes Desc: not available URL: From jcholast at redhat.com Tue Mar 27 11:09:58 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 27 Mar 2012 13:09:58 +0200 Subject: [Freeipa-devel] [PATCH] 72 Fix uses of O=REALM instead of the configured certificate subject base In-Reply-To: <4F70CECA.4040700@redhat.com> References: <4F707386.1060805@redhat.com> <4F7079EB.2040404@redhat.com> <4F708B34.3080106@redhat.com> <4F70CECA.4040700@redhat.com> Message-ID: <4F71A006.509@redhat.com> On 26.3.2012 22:17, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 26.3.2012 16:15, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> https://fedorahosted.org/freeipa/ticket/2521 >>>> >>>> Honza >>> >>> You can still set a custom subject base for selfsign installations so >>> you need a special case in valid_issuer(). >> >> For selfsign installations, the issuer is always "CN=REALM Certificate >> Authority", no matter what is set in the subject base, so no special >> case is needed. >> >>> I wonder if this comparison >>> should be case insensitive too. >> >> I think the DN class already takes care of this. >> >>> >>> It may also be an optimization to cache the base in subject_base(). It >>> can't change after install time so it should be valid the entire >>> lifetime of the server. >> >> What if someone does >> >> $ ipa config-mod --setattr ipacertificatesubjectbase='O=Something' > > Ok, you're right about the issuer and DN case insensitivity, so we're > good there. I think that caching is still a good idea. > > We'll handle the immutable subjectbase as a separate problem. This is > really pretty minor and isn't a show stopper, you just have to revert it > and things work again. > > rob Updated patch attached. Added caching and fixed one more occurence of O=REALM, in make-testcert. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-72.1-certificate-subject-base.patch Type: text/x-patch Size: 7913 bytes Desc: not available URL: From mkosek at redhat.com Tue Mar 27 11:57:47 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Mar 2012 13:57:47 +0200 Subject: [Freeipa-devel] [PATCH] 16 Netgroup nisdomain and hosts validation In-Reply-To: <4F6CF4D4.5020906@redhat.com> References: <4F58B9A8.2000508@redhat.com> <1331307242.26839.24.camel@balmora.brq.redhat.com> <4F60BF41.3000301@redhat.com> <1331795633.27127.3.camel@balmora.brq.redhat.com> <4F6CF4D4.5020906@redhat.com> Message-ID: <1332849467.9937.37.camel@balmora.brq.redhat.com> On Fri, 2012-03-23 at 23:10 +0100, Ondrej Hamada wrote: > On 03/15/2012 08:13 AM, Martin Kosek wrote: > > On Wed, 2012-03-14 at 16:54 +0100, Ondrej Hamada wrote: > >> On 03/09/2012 04:34 PM, Martin Kosek wrote: > >>> On Thu, 2012-03-08 at 14:52 +0100, Ondrej Hamada wrote: > >>>> Netgroup nisdomain and hosts validation > >>>> > >>>> nisdomain validation: > >>>> Added pattern to the 'nisdomain' parameter to validate the specified > >>>> nisdomain name. According to most common use cases the same patter as > >>>> for netgroup should fit. Unit-tests added. > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/2447 > >>>> > >>>> hosts validation: > >>>> Added precallback to netgroup_add_member. It validates the specified > >>>> hostnames and raises ValidationError exception for invalid hostnames. > >>>> Unit-test added. > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/2448 > >>> I checked the host validation part and it could be improved. Issue > >>> described in #2447 (you have switched the ticket IDs) affects all > >>> objects that allow external hosts, users, ..., i.e. those who call > >>> add_external_post_callback in their post_callback. > >>> > >>> Should we fix all of these when we deal with this issue? Otherwise user > >>> could do something like this: > >>> # ipa sudorule-add-user foo --users=a+b > >>> Rule name: foo > >>> Enabled: TRUE > >>> External User: a+b > >>> > >>> We could create a similar function called add_external_pre_callback() > >>> and pass it attribute name and validating function (which would be > >>> common with the linked object). It would then do the validation for all > >>> these affected objects consistently and without redundant code. > >>> > >>> I didn't liked much the implemented pre_callback anyway > >>> > >>> + def pre_callback(self, ldap, dn, found, not_found, *keys, > >>> **options): > >>> + # validate entered hostnames > >>> + if 'host' in options: > >>> + invalid_hostnames=[] > >>> + for hostname in options['host']: > >>> + try: > >>> + validate_hostname(hostname, False) > >>> + except ValueError: > >>> + invalid_hostnames.append(hostname) > >>> + if invalid_hostnames: > >>> + raise errors.ValidationError(name='host', > >>> error='hostnames:\"%s\" contain invalid characters' % > >>> ','.join(invalid_hostnames)) > >>> + return dn > >>> > >>> I would rather raise the ValidationError with the first invalid hostname > >>> and tell what's wrong (function validate_hostname tells it to you). If > >>> you go with the proposed approach, you wouldn't have to deal with > >>> formatting error messages, you would just raise the one returned by the > >>> validator shared with the linked LDAP object (hostname, user, ...). > >>> > >>> Martin > >> external_pre_callback function seems as a good idea, but there is a > >> problem how to get the validators for various LDAP objects. For the > >> hostname we already have one in ipalib.utils, but for the uid or group > >> name we use only patterns specified in the parameter objects. > >> > >> Below I propose solution how to use the already defined parameter > >> objects for validation (the only problem is that I have to assume, that > >> it is always the first parameter in takes_params). Do you think this is > >> a good approach? > > I think the approach is OK, it can just be much improved in order to get > > rid of the hardcoded parts. See comments below. > > > >> def add_external_pre_callback(memberattr, membertype, externalattr, > >> ldap, dn, found, not_found, *keys, **options): > >> """ > >> Pre callback to validate external members. > >> """ > >> if membertype in options: > >> validator = api.Object[membertype].takes_params[0] > > You can use api.Object[membertype].params[memberattr] > > > >> for value in options[membertype]: > >> try: > >> validator(value) > >> except errors.ValidationError as e: > >> error_msg = e[(e.find(':')+1):] > > You don't have to parse error message, you can just use e.name or > > e.error right from the caught ValidationError. > > > >> raise errors.ValidationError(name=membertype, > >> error=e[e.find(':')+1:]) > >> return dn > >> > > > > nisdomain validation: > Added pattern to the 'nisdomain' parameter to validate the specified > nisdomain name. According to most common use cases the same pattern as > for netgroup should fit. Unit-tests added. > > https://fedorahosted.org/freeipa/ticket/2448 > > 'add_external_pre_callback' function was created to allow validation of > all external members. Validation is based on usage of objects primary > key parameter. The 'add_external_pre_callback' fucntion has to be called > directly from in the 'pre_callback' function. This change affects > netgroup, hbacrule and sudorule commands. > > Special validator is used only for hostname, the validator requires > fully qualified > domain name and enables the hostnames to contain underscores. > > Unit-tests added. > > https://fedorahosted.org/freeipa/ticket/2447 > This is better, but I still see few issues: 1) You copied hostname validator instead of extending validate_hostname function in ipalib.util with allow_underscore parameter which is already available in validate_dns_label. Having duplicate functions like this is just wrong and can lead to errors in future. 2) I also wonder if externalHost can contain non-fqdn hosts. In such case, you would just add check_fqdn=False to validate_hostname. Martin From pviktori at redhat.com Tue Mar 27 13:45:49 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 27 Mar 2012 15:45:49 +0200 Subject: [Freeipa-devel] [PATCH] 0029 Check expected error messages in tests In-Reply-To: <4F70C864.5050107@redhat.com> References: <4F687A8D.6020508@redhat.com> <4F709C11.1070800@redhat.com> <4F70C864.5050107@redhat.com> Message-ID: <4F71C48D.3010502@redhat.com> On 03/26/2012 09:49 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/20/2012 01:39 PM, Petr Viktorin wrote: >>> This patch adds checking error messages, not just types, to the XML-RPC >>> tests. >>> The checking is still somewhat hackish, since XML-RPC doesn't give us >>> structured error info, but it should protect against regressions on >>> issues like whether we put name or cli_name in a ValidationError. >>> >>> https://fedorahosted.org/freeipa/ticket/2549 >>> >> >> Updated and rebased to current master. > > NACK > > automember wrongly was testing for non-existent users rather than > automember rules but those should still be tested IMHO, perhaps with > both types. > > There is also some inconsistency. In host you use substitution to set > the hostname in the error: '%s: host not found' % fqdn1 but in others > (group, hostgroup for example) the name is hardcoded. I also noticed > that some reasons are unicode and others are not. > > rob Added tests for automember, made all the reasons unicode, using substitutions when variables are involved. The patch still only updates tests that didn't pass the error message check. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0029-02-Fix-expected-error-messages-in-tests.patch Type: text/x-patch Size: 70457 bytes Desc: not available URL: From mkosek at redhat.com Tue Mar 27 14:00:39 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Mar 2012 16:00:39 +0200 Subject: [Freeipa-devel] [PATCHES] Improve framework parameter validation In-Reply-To: <4F61F557.2040003@redhat.com> References: <4F61C63C.2050006@redhat.com> <4F61CD08.8090905@redhat.com> <4F61EC8D.5050208@redhat.com> <4F61F557.2040003@redhat.com> Message-ID: <1332856839.9937.42.camel@balmora.brq.redhat.com> On Thu, 2012-03-15 at 14:57 +0100, Jan Cholasta wrote: > On 15.3.2012 14:20, Petr Viktorin wrote: > > On 03/15/2012 12:05 PM, Jan Cholasta wrote: > >> On 15.3.2012 11:36, Jan Cholasta wrote: > >>> (this is a continuation of > >>> ) > >>> > >>> > >>> > >>> > >>> Hi, > >>> > >>> the attached patches fix > >>> and : > >>> > >>> [PATCH] Fix the procedure for getting default values of command > >>> parameters. > >>> > >>> The parameters used in default_from of other parameters are now properly > >>> validated before the default_from is called. > >>> > >>> [PATCH] Change parameters to use only default_from for dynamic default > >>> values. > >>> > >>> Replace all occurences of create_default with equivalent default_from > >>> and remove create_default from the framework. This is needed for proper > >>> parameter validation, as there is no way to tell which parameters to > >>> validate prior to calling create_default, because create_default does > >>> not provide information about which parameters are used for generating > >>> the default value. > >>> > >>> Honza > >>> > >> > >> Forgot to remove one FIXME bit in dns.py. Update patch attached. > >> > >> Honza > > > > > > > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > > > index a10960a..61c645d 100644 > > > --- a/ipalib/plugins/dns.py > > > +++ b/ipalib/plugins/dns.py > > > @@ -1528,7 +1528,7 @@ class dnszone(LDAPObject): > > > label=_('SOA serial'), > > > doc=_('SOA record serial number'), > > > minvalue=1, > > > - create_default=_create_zone_serial, > > > + default_from=_create_zone_serial, > > > autofill=True, > > > ), > > > Int('idnssoarefresh', > > > diff --git a/ipalib/plugins/passwd.py b/ipalib/plugins/passwd.py > > > index b26f7e9..9bee314 100644 > > > --- a/ipalib/plugins/passwd.py > > > +++ b/ipalib/plugins/passwd.py > > > @@ -69,7 +69,7 @@ class passwd(Command): > > > label=_('User name'), > > > primary_key=True, > > > autofill=True, > > > - create_default=lambda **kw: util.get_current_principal(), > > > + default_from=lambda: util.get_current_principal(), > > > normalizer=lambda value: normalize_principal(value), > > > ), > > > Password('password', > > > > > > This is just a minor nitpick, but I'd like to know if there's a reason > > behind it: why are you sometimes using lambda and sometimes not? > > I use lambda as a protective measure against accidents caused by adding > optional arguments to the functions used. _create_zone_serial is an > exception to that rule, because it is private to the dns plugin. > > > > > The patch works well here, but I think I'm not the one to ack it. > > > > Honza > The patch looks OK, I found just minor issues. 1) We may want to add some check for wildcards (**kw) in default_from, I guess it would mess with your dependency solver. Some nice error would warn developers that they are doing something bad. 2) Patch 47.4 needs minor rebasing Martin From rcritten at redhat.com Tue Mar 27 14:02:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Mar 2012 10:02:43 -0400 Subject: [Freeipa-devel] [PATCH] 72 Fix uses of O=REALM instead of the configured certificate subject base In-Reply-To: <4F71A006.509@redhat.com> References: <4F707386.1060805@redhat.com> <4F7079EB.2040404@redhat.com> <4F708B34.3080106@redhat.com> <4F70CECA.4040700@redhat.com> <4F71A006.509@redhat.com> Message-ID: <4F71C883.9000406@redhat.com> Jan Cholasta wrote: > On 26.3.2012 22:17, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 26.3.2012 16:15, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> https://fedorahosted.org/freeipa/ticket/2521 >>>>> >>>>> Honza >>>> >>>> You can still set a custom subject base for selfsign installations so >>>> you need a special case in valid_issuer(). >>> >>> For selfsign installations, the issuer is always "CN=REALM Certificate >>> Authority", no matter what is set in the subject base, so no special >>> case is needed. >>> >>>> I wonder if this comparison >>>> should be case insensitive too. >>> >>> I think the DN class already takes care of this. >>> >>>> >>>> It may also be an optimization to cache the base in subject_base(). It >>>> can't change after install time so it should be valid the entire >>>> lifetime of the server. >>> >>> What if someone does >>> >>> $ ipa config-mod --setattr ipacertificatesubjectbase='O=Something' >> >> Ok, you're right about the issuer and DN case insensitivity, so we're >> good there. I think that caching is still a good idea. >> >> We'll handle the immutable subjectbase as a separate problem. This is >> really pretty minor and isn't a show stopper, you just have to revert it >> and things work again. >> >> rob > > Updated patch attached. Added caching and fixed one more occurence of > O=REALM, in make-testcert. > > Honza > ACK, pushed to master and ipa-2-2 From rcritten at redhat.com Tue Mar 27 14:08:16 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Mar 2012 10:08:16 -0400 Subject: [Freeipa-devel] [PATCH 66] Replace broken i18n shell test with Python test In-Reply-To: <4F718291.9080105@redhat.com> References: <4F6B5AF2.9070009@redhat.com> <4F6B767C.4000301@redhat.com> <4F6C117B.1090807@redhat.com> <4F6CEC42.2050702@redhat.com> <4F7027A1.7060006@redhat.com> <4F709007.4060305@redhat.com> <4F70A344.4050304@redhat.com> <4F70D2EC.4050203@redhat.com> <4F718291.9080105@redhat.com> Message-ID: <4F71C9D0.3020002@redhat.com> Petr Viktorin wrote: > On 03/26/2012 10:34 PM, John Dennis wrote: >> On 03/26/2012 01:11 PM, Petr Viktorin wrote: >>> Just a one-liner: The docstring of validate_anonymous_substitutions >>> isn't up to par ??? there's a missing quote, extra ?a?, and the '%s >>> occurred' has no context. I suggest: >>> >>> We do not permit multiple anonymous substitutions in translation >>> strings (e.g. '%s') because they do not allow translators to reorder the >>> wording. Instead keyword substitutions should be used when there are >>> more than one. >>> >>> >>> ACK if that's fixed >> >> Done, patch attached. >> > > ACK > pushed to master and ipa-2-2 From pviktori at redhat.com Tue Mar 27 14:10:38 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 27 Mar 2012 16:10:38 +0200 Subject: [Freeipa-devel] [PATCH] 244 Fix dnsrecord-del interactive mode In-Reply-To: <1332846360.9937.30.camel@balmora.brq.redhat.com> References: <1332846360.9937.30.camel@balmora.brq.redhat.com> Message-ID: <4F71CA5E.7060206@redhat.com> On 03/27/2012 01:06 PM, Martin Kosek wrote: > User was not able to select multiple values in dnsrecord-del > interactive mode. > > https://fedorahosted.org/freeipa/ticket/2581 ACK -- Petr? From jcholast at redhat.com Tue Mar 27 14:30:26 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 27 Mar 2012 16:30:26 +0200 Subject: [Freeipa-devel] [PATCHES] Improve framework parameter validation In-Reply-To: <1332856839.9937.42.camel@balmora.brq.redhat.com> References: <4F61C63C.2050006@redhat.com> <4F61CD08.8090905@redhat.com> <4F61EC8D.5050208@redhat.com> <4F61F557.2040003@redhat.com> <1332856839.9937.42.camel@balmora.brq.redhat.com> Message-ID: <4F71CF02.9020809@redhat.com> On 27.3.2012 16:00, Martin Kosek wrote: > On Thu, 2012-03-15 at 14:57 +0100, Jan Cholasta wrote: >> On 15.3.2012 14:20, Petr Viktorin wrote: >>> On 03/15/2012 12:05 PM, Jan Cholasta wrote: >>>> On 15.3.2012 11:36, Jan Cholasta wrote: >>>>> (this is a continuation of >>>>> ) >>>>> >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> the attached patches fix >>>>> and: >>>>> >>>>> [PATCH] Fix the procedure for getting default values of command >>>>> parameters. >>>>> >>>>> The parameters used in default_from of other parameters are now properly >>>>> validated before the default_from is called. >>>>> >>>>> [PATCH] Change parameters to use only default_from for dynamic default >>>>> values. >>>>> >>>>> Replace all occurences of create_default with equivalent default_from >>>>> and remove create_default from the framework. This is needed for proper >>>>> parameter validation, as there is no way to tell which parameters to >>>>> validate prior to calling create_default, because create_default does >>>>> not provide information about which parameters are used for generating >>>>> the default value. >>>>> >>>>> Honza >>>>> >>>> >>>> Forgot to remove one FIXME bit in dns.py. Update patch attached. >>>> >>>> Honza >>> >>> >>> > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>> > index a10960a..61c645d 100644 >>> > --- a/ipalib/plugins/dns.py >>> > +++ b/ipalib/plugins/dns.py >>> > @@ -1528,7 +1528,7 @@ class dnszone(LDAPObject): >>> > label=_('SOA serial'), >>> > doc=_('SOA record serial number'), >>> > minvalue=1, >>> > - create_default=_create_zone_serial, >>> > + default_from=_create_zone_serial, >>> > autofill=True, >>> > ), >>> > Int('idnssoarefresh', >>> > diff --git a/ipalib/plugins/passwd.py b/ipalib/plugins/passwd.py >>> > index b26f7e9..9bee314 100644 >>> > --- a/ipalib/plugins/passwd.py >>> > +++ b/ipalib/plugins/passwd.py >>> > @@ -69,7 +69,7 @@ class passwd(Command): >>> > label=_('User name'), >>> > primary_key=True, >>> > autofill=True, >>> > - create_default=lambda **kw: util.get_current_principal(), >>> > + default_from=lambda: util.get_current_principal(), >>> > normalizer=lambda value: normalize_principal(value), >>> > ), >>> > Password('password', >>> >>> >>> This is just a minor nitpick, but I'd like to know if there's a reason >>> behind it: why are you sometimes using lambda and sometimes not? >> >> I use lambda as a protective measure against accidents caused by adding >> optional arguments to the functions used. _create_zone_serial is an >> exception to that rule, because it is private to the dns plugin. >> >>> >>> The patch works well here, but I think I'm not the one to ack it. >>> >> >> Honza >> > > The patch looks OK, I found just minor issues. > > 1) We may want to add some check for wildcards (**kw) in default_from, I > guess it would mess with your dependency solver. Some nice error would > warn developers that they are doing something bad. Added the check. > > 2) Patch 47.4 needs minor rebasing Done. > > Martin > Updated patches attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-44.5-parameter-validation.patch Type: text/x-patch Size: 10028 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-47.5-parameter-remove-create-default.patch Type: text/x-patch Size: 13562 bytes Desc: not available URL: From jdennis at redhat.com Tue Mar 27 14:34:54 2012 From: jdennis at redhat.com (John Dennis) Date: Tue, 27 Mar 2012 10:34:54 -0400 Subject: [Freeipa-devel] [PATCH 68] text unit test should validate using installed mo file Message-ID: <4F71D00E.2070907@redhat.com> This patch addresses ticket 2582, see comments in commit message. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0068-text-unit-test-should-validate-using-installed-mo-fi.patch Type: text/x-patch Size: 7748 bytes Desc: not available URL: From mkosek at redhat.com Tue Mar 27 14:42:09 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Mar 2012 16:42:09 +0200 Subject: [Freeipa-devel] [PATCHES] Improve framework parameter validation In-Reply-To: <4F71CF02.9020809@redhat.com> References: <4F61C63C.2050006@redhat.com> <4F61CD08.8090905@redhat.com> <4F61EC8D.5050208@redhat.com> <4F61F557.2040003@redhat.com> <1332856839.9937.42.camel@balmora.brq.redhat.com> <4F71CF02.9020809@redhat.com> Message-ID: <1332859329.9937.68.camel@balmora.brq.redhat.com> On Tue, 2012-03-27 at 16:30 +0200, Jan Cholasta wrote: > On 27.3.2012 16:00, Martin Kosek wrote: > > On Thu, 2012-03-15 at 14:57 +0100, Jan Cholasta wrote: > >> On 15.3.2012 14:20, Petr Viktorin wrote: > >>> On 03/15/2012 12:05 PM, Jan Cholasta wrote: > >>>> On 15.3.2012 11:36, Jan Cholasta wrote: > >>>>> (this is a continuation of > >>>>> ) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> the attached patches fix > >>>>> and: > >>>>> > >>>>> [PATCH] Fix the procedure for getting default values of command > >>>>> parameters. > >>>>> > >>>>> The parameters used in default_from of other parameters are now properly > >>>>> validated before the default_from is called. > >>>>> > >>>>> [PATCH] Change parameters to use only default_from for dynamic default > >>>>> values. > >>>>> > >>>>> Replace all occurences of create_default with equivalent default_from > >>>>> and remove create_default from the framework. This is needed for proper > >>>>> parameter validation, as there is no way to tell which parameters to > >>>>> validate prior to calling create_default, because create_default does > >>>>> not provide information about which parameters are used for generating > >>>>> the default value. > >>>>> > >>>>> Honza > >>>>> > >>>> > >>>> Forgot to remove one FIXME bit in dns.py. Update patch attached. > >>>> > >>>> Honza > >>> > >>> > >>> > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > >>> > index a10960a..61c645d 100644 > >>> > --- a/ipalib/plugins/dns.py > >>> > +++ b/ipalib/plugins/dns.py > >>> > @@ -1528,7 +1528,7 @@ class dnszone(LDAPObject): > >>> > label=_('SOA serial'), > >>> > doc=_('SOA record serial number'), > >>> > minvalue=1, > >>> > - create_default=_create_zone_serial, > >>> > + default_from=_create_zone_serial, > >>> > autofill=True, > >>> > ), > >>> > Int('idnssoarefresh', > >>> > diff --git a/ipalib/plugins/passwd.py b/ipalib/plugins/passwd.py > >>> > index b26f7e9..9bee314 100644 > >>> > --- a/ipalib/plugins/passwd.py > >>> > +++ b/ipalib/plugins/passwd.py > >>> > @@ -69,7 +69,7 @@ class passwd(Command): > >>> > label=_('User name'), > >>> > primary_key=True, > >>> > autofill=True, > >>> > - create_default=lambda **kw: util.get_current_principal(), > >>> > + default_from=lambda: util.get_current_principal(), > >>> > normalizer=lambda value: normalize_principal(value), > >>> > ), > >>> > Password('password', > >>> > >>> > >>> This is just a minor nitpick, but I'd like to know if there's a reason > >>> behind it: why are you sometimes using lambda and sometimes not? > >> > >> I use lambda as a protective measure against accidents caused by adding > >> optional arguments to the functions used. _create_zone_serial is an > >> exception to that rule, because it is private to the dns plugin. > >> > >>> > >>> The patch works well here, but I think I'm not the one to ack it. > >>> > >> > >> Honza > >> > > > > The patch looks OK, I found just minor issues. > > > > 1) We may want to add some check for wildcards (**kw) in default_from, I > > guess it would mess with your dependency solver. Some nice error would > > warn developers that they are doing something bad. > > Added the check. > > > > > 2) Patch 47.4 needs minor rebasing > > Done. > > > > > Martin > > > > Updated patches attached. > > Honza > I think you squashed the change with an incorrect commit. The check should be rather included in patch 44. Martin From jdennis at redhat.com Tue Mar 27 14:58:22 2012 From: jdennis at redhat.com (John Dennis) Date: Tue, 27 Mar 2012 10:58:22 -0400 Subject: [Freeipa-devel] [PATCH 68] text unit test should validate using installed mo file In-Reply-To: <4F71D00E.2070907@redhat.com> References: <4F71D00E.2070907@redhat.com> Message-ID: <4F71D58E.5060507@redhat.com> On 03/27/2012 10:34 AM, John Dennis wrote: > This patch addresses ticket 2582, see comments in commit message. Sorry, the patch I originally posted was incorrect, the work had been done in several commits but I forgot to "squash" them into one commit and patch before posting it. This new patch fixes that mistake. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0068-1-text-unit-test-should-validate-using-installed-mo-fi.patch Type: text/x-patch Size: 12207 bytes Desc: not available URL: From edewata at redhat.com Tue Mar 27 15:36:56 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 27 Mar 2012 10:36:56 -0500 Subject: [Freeipa-devel] [PATCHES] 113-114 Facet expiration flag In-Reply-To: <4F6B6660.1020104@redhat.com> References: <4F6B6660.1020104@redhat.com> Message-ID: <4F71DE98.2050402@redhat.com> On 3/22/2012 12:50 PM, Petr Vobornik wrote: > The effort was split to two patches. See patch descriptions. ACK on both. Nice job. See comments below. > Notes: > Case #7 (automatic: an open facet should automatically refresh itself > when it expires) I don't want to implement because I think it can cause > havoc ie: refresh when user is editing. For details page, automatically refreshing the page still makes sense to avoid overriding newer data with older information. For example you open a user details page to add an email address, but at the same time somebody else added another email address to same user. When you finally save your changes the other email address will be gone. I think there are several options: 1. Don't refresh if the page is dirty (i.e. user is editing the page). 2. Refresh unedited fields only. 3. Load the data even though it's being edited, compare with the cached data. If something's changed alert the user. The user can either revert the changes or continue editing. 4. Use addattr/delattr to modify multi-valued attributes. The chance of this happening is probably small, and the solution won't completely eliminate the risk either, so this is probably lower priority. For search page, there are 2 things that the page keeps in cache: the primary keys and the visible entry details. Currently when you change page it will refresh both, so periodically refreshing the page may not be that important. However ideally we shouldn't need to refresh the primary keys in all page changes because it could be long and most likely unchanged. In this case it makes sense to refresh the primary keys periodically. Probably separate ticket. > Also I was thinking about splitting needs_update to two methods: > needs_update and state_changed. State changed would compare current > state with old state. It would be called from needs_update. This way we > don't have to override needs_update and just define various > state_changed for different facets. Feel free to refactor the methods if you think it's necessary. But before that try to rearrange the current implementations of needs_update() and minimize the amount of code that needs to be moved into state_changed(). > Also I'm thinking about adding > paging state comparison to search facet (the page should recognize the > change itself ie when other facet redirects to certain page (bad > example?)). What do you think? Yes, this would be needed if we decided to keep the primary keys for a longer time like described above. Changing the page should refresh the visible entry details only. -- Endi S. Dewata From mkosek at redhat.com Tue Mar 27 15:41:33 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Mar 2012 17:41:33 +0200 Subject: [Freeipa-devel] [PATCHES] Improve framework parameter validation In-Reply-To: <1332859329.9937.68.camel@balmora.brq.redhat.com> References: <4F61C63C.2050006@redhat.com> <4F61CD08.8090905@redhat.com> <4F61EC8D.5050208@redhat.com> <4F61F557.2040003@redhat.com> <1332856839.9937.42.camel@balmora.brq.redhat.com> <4F71CF02.9020809@redhat.com> <1332859329.9937.68.camel@balmora.brq.redhat.com> Message-ID: <1332862893.26630.1.camel@balmora.brq.redhat.com> On Tue, 2012-03-27 at 16:42 +0200, Martin Kosek wrote: > On Tue, 2012-03-27 at 16:30 +0200, Jan Cholasta wrote: > > On 27.3.2012 16:00, Martin Kosek wrote: > > > On Thu, 2012-03-15 at 14:57 +0100, Jan Cholasta wrote: > > >> On 15.3.2012 14:20, Petr Viktorin wrote: > > >>> On 03/15/2012 12:05 PM, Jan Cholasta wrote: > > >>>> On 15.3.2012 11:36, Jan Cholasta wrote: > > >>>>> (this is a continuation of > > >>>>> ) > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> the attached patches fix > > >>>>> and: > > >>>>> > > >>>>> [PATCH] Fix the procedure for getting default values of command > > >>>>> parameters. > > >>>>> > > >>>>> The parameters used in default_from of other parameters are now properly > > >>>>> validated before the default_from is called. > > >>>>> > > >>>>> [PATCH] Change parameters to use only default_from for dynamic default > > >>>>> values. > > >>>>> > > >>>>> Replace all occurences of create_default with equivalent default_from > > >>>>> and remove create_default from the framework. This is needed for proper > > >>>>> parameter validation, as there is no way to tell which parameters to > > >>>>> validate prior to calling create_default, because create_default does > > >>>>> not provide information about which parameters are used for generating > > >>>>> the default value. > > >>>>> > > >>>>> Honza > > >>>>> > > >>>> > > >>>> Forgot to remove one FIXME bit in dns.py. Update patch attached. > > >>>> > > >>>> Honza > > >>> > > >>> > > >>> > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > > >>> > index a10960a..61c645d 100644 > > >>> > --- a/ipalib/plugins/dns.py > > >>> > +++ b/ipalib/plugins/dns.py > > >>> > @@ -1528,7 +1528,7 @@ class dnszone(LDAPObject): > > >>> > label=_('SOA serial'), > > >>> > doc=_('SOA record serial number'), > > >>> > minvalue=1, > > >>> > - create_default=_create_zone_serial, > > >>> > + default_from=_create_zone_serial, > > >>> > autofill=True, > > >>> > ), > > >>> > Int('idnssoarefresh', > > >>> > diff --git a/ipalib/plugins/passwd.py b/ipalib/plugins/passwd.py > > >>> > index b26f7e9..9bee314 100644 > > >>> > --- a/ipalib/plugins/passwd.py > > >>> > +++ b/ipalib/plugins/passwd.py > > >>> > @@ -69,7 +69,7 @@ class passwd(Command): > > >>> > label=_('User name'), > > >>> > primary_key=True, > > >>> > autofill=True, > > >>> > - create_default=lambda **kw: util.get_current_principal(), > > >>> > + default_from=lambda: util.get_current_principal(), > > >>> > normalizer=lambda value: normalize_principal(value), > > >>> > ), > > >>> > Password('password', > > >>> > > >>> > > >>> This is just a minor nitpick, but I'd like to know if there's a reason > > >>> behind it: why are you sometimes using lambda and sometimes not? > > >> > > >> I use lambda as a protective measure against accidents caused by adding > > >> optional arguments to the functions used. _create_zone_serial is an > > >> exception to that rule, because it is private to the dns plugin. > > >> > > >>> > > >>> The patch works well here, but I think I'm not the one to ack it. > > >>> > > >> > > >> Honza > > >> > > > > > > The patch looks OK, I found just minor issues. > > > > > > 1) We may want to add some check for wildcards (**kw) in default_from, I > > > guess it would mess with your dependency solver. Some nice error would > > > warn developers that they are doing something bad. > > > > Added the check. > > > > > > > > 2) Patch 47.4 needs minor rebasing > > > > Done. > > > > > > > > Martin > > > > > > > Updated patches attached. > > > > Honza > > > > I think you squashed the change with an incorrect commit. The check > should be rather included in patch 44. > > Martin I just noticed it breaks one unit test: ====================================================================== ERROR: Test the `ipalib.parameters.DefaultFrom.__init__` method. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/mkosek/freeipa/tests/test_ipalib/test_parameters.py", line 52, in test_init o = self.cls(callback, *keys) File "/home/mkosek/freeipa/ipalib/parameters.py", line 201, in __init__ raise ValueError("callback: variable-length argument list not allowed") ValueError: callback: variable-length argument list not allowed ---------------------------------------------------------------------- I also think it would be useful to have one test specifically for this new check. Martin From ohamada at redhat.com Tue Mar 27 15:56:37 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Tue, 27 Mar 2012 17:56:37 +0200 Subject: [Freeipa-devel] [PATCH] 16 Netgroup nisdomain and hosts validation In-Reply-To: <1332849467.9937.37.camel@balmora.brq.redhat.com> References: <4F58B9A8.2000508@redhat.com> <1331307242.26839.24.camel@balmora.brq.redhat.com> <4F60BF41.3000301@redhat.com> <1331795633.27127.3.camel@balmora.brq.redhat.com> <4F6CF4D4.5020906@redhat.com> <1332849467.9937.37.camel@balmora.brq.redhat.com> Message-ID: <4F71E335.7010000@redhat.com> On 03/27/2012 01:57 PM, Martin Kosek wrote: > On Fri, 2012-03-23 at 23:10 +0100, Ondrej Hamada wrote: >> On 03/15/2012 08:13 AM, Martin Kosek wrote: >>> On Wed, 2012-03-14 at 16:54 +0100, Ondrej Hamada wrote: >>>> On 03/09/2012 04:34 PM, Martin Kosek wrote: >>>>> On Thu, 2012-03-08 at 14:52 +0100, Ondrej Hamada wrote: >>>>>> Netgroup nisdomain and hosts validation >>>>>> >>>>>> nisdomain validation: >>>>>> Added pattern to the 'nisdomain' parameter to validate the specified >>>>>> nisdomain name. According to most common use cases the same patter as >>>>>> for netgroup should fit. Unit-tests added. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/2447 >>>>>> >>>>>> hosts validation: >>>>>> Added precallback to netgroup_add_member. It validates the specified >>>>>> hostnames and raises ValidationError exception for invalid hostnames. >>>>>> Unit-test added. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/2448 >>>>> I checked the host validation part and it could be improved. Issue >>>>> described in #2447 (you have switched the ticket IDs) affects all >>>>> objects that allow external hosts, users, ..., i.e. those who call >>>>> add_external_post_callback in their post_callback. >>>>> >>>>> Should we fix all of these when we deal with this issue? Otherwise user >>>>> could do something like this: >>>>> # ipa sudorule-add-user foo --users=a+b >>>>> Rule name: foo >>>>> Enabled: TRUE >>>>> External User: a+b >>>>> >>>>> We could create a similar function called add_external_pre_callback() >>>>> and pass it attribute name and validating function (which would be >>>>> common with the linked object). It would then do the validation for all >>>>> these affected objects consistently and without redundant code. >>>>> >>>>> I didn't liked much the implemented pre_callback anyway >>>>> >>>>> + def pre_callback(self, ldap, dn, found, not_found, *keys, >>>>> **options): >>>>> + # validate entered hostnames >>>>> + if 'host' in options: >>>>> + invalid_hostnames=[] >>>>> + for hostname in options['host']: >>>>> + try: >>>>> + validate_hostname(hostname, False) >>>>> + except ValueError: >>>>> + invalid_hostnames.append(hostname) >>>>> + if invalid_hostnames: >>>>> + raise errors.ValidationError(name='host', >>>>> error='hostnames:\"%s\" contain invalid characters' % >>>>> ','.join(invalid_hostnames)) >>>>> + return dn >>>>> >>>>> I would rather raise the ValidationError with the first invalid hostname >>>>> and tell what's wrong (function validate_hostname tells it to you). If >>>>> you go with the proposed approach, you wouldn't have to deal with >>>>> formatting error messages, you would just raise the one returned by the >>>>> validator shared with the linked LDAP object (hostname, user, ...). >>>>> >>>>> Martin >>>> external_pre_callback function seems as a good idea, but there is a >>>> problem how to get the validators for various LDAP objects. For the >>>> hostname we already have one in ipalib.utils, but for the uid or group >>>> name we use only patterns specified in the parameter objects. >>>> >>>> Below I propose solution how to use the already defined parameter >>>> objects for validation (the only problem is that I have to assume, that >>>> it is always the first parameter in takes_params). Do you think this is >>>> a good approach? >>> I think the approach is OK, it can just be much improved in order to get >>> rid of the hardcoded parts. See comments below. >>> >>>> def add_external_pre_callback(memberattr, membertype, externalattr, >>>> ldap, dn, found, not_found, *keys, **options): >>>> """ >>>> Pre callback to validate external members. >>>> """ >>>> if membertype in options: >>>> validator = api.Object[membertype].takes_params[0] >>> You can use api.Object[membertype].params[memberattr] >>> >>>> for value in options[membertype]: >>>> try: >>>> validator(value) >>>> except errors.ValidationError as e: >>>> error_msg = e[(e.find(':')+1):] >>> You don't have to parse error message, you can just use e.name or >>> e.error right from the caught ValidationError. >>> >>>> raise errors.ValidationError(name=membertype, >>>> error=e[e.find(':')+1:]) >>>> return dn >>>> >> nisdomain validation: >> Added pattern to the 'nisdomain' parameter to validate the specified >> nisdomain name. According to most common use cases the same pattern as >> for netgroup should fit. Unit-tests added. >> >> https://fedorahosted.org/freeipa/ticket/2448 >> >> 'add_external_pre_callback' function was created to allow validation of >> all external members. Validation is based on usage of objects primary >> key parameter. The 'add_external_pre_callback' fucntion has to be called >> directly from in the 'pre_callback' function. This change affects >> netgroup, hbacrule and sudorule commands. >> >> Special validator is used only for hostname, the validator requires >> fully qualified >> domain name and enables the hostnames to contain underscores. >> >> Unit-tests added. >> >> https://fedorahosted.org/freeipa/ticket/2447 >> > This is better, but I still see few issues: > > 1) You copied hostname validator instead of extending validate_hostname > function in ipalib.util with allow_underscore parameter which is already > available in validate_dns_label. Having duplicate functions like this is > just wrong and can lead to errors in future. > > 2) I also wonder if externalHost can contain non-fqdn hosts. In such > case, you would just add check_fqdn=False to validate_hostname. > > Martin > corrected patch attached -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-16-3-Netgroup-nisdomain-and-hosts-validation.patch Type: text/x-patch Size: 27131 bytes Desc: not available URL: From mkosek at redhat.com Tue Mar 27 16:04:32 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Mar 2012 18:04:32 +0200 Subject: [Freeipa-devel] [PATCH] 244 Fix dnsrecord-del interactive mode In-Reply-To: <4F71CA5E.7060206@redhat.com> References: <1332846360.9937.30.camel@balmora.brq.redhat.com> <4F71CA5E.7060206@redhat.com> Message-ID: <1332864272.26630.2.camel@balmora.brq.redhat.com> On Tue, 2012-03-27 at 16:10 +0200, Petr Viktorin wrote: > On 03/27/2012 01:06 PM, Martin Kosek wrote: > > User was not able to select multiple values in dnsrecord-del > > interactive mode. > > > > https://fedorahosted.org/freeipa/ticket/2581 > > > ACK > Pushed to master, ipa-2-2. Martin From pviktori at redhat.com Tue Mar 27 17:02:56 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 27 Mar 2012 19:02:56 +0200 Subject: [Freeipa-devel] [PATCH] 0021 Add CLI tests In-Reply-To: <4F69E9AA.4040509@redhat.com> References: <4F575A01.1060501@redhat.com> <4F5E5A22.1010109@redhat.com> <4F5F2E39.2020301@redhat.com> <4F632BDD.1000608@redhat.com> <4F69E9AA.4040509@redhat.com> Message-ID: <4F71F2C0.2070203@redhat.com> Updated with a regression test for https://fedorahosted.org/freeipa/ticket/2581 (Unable to delete all sshfp records interactively) which Martin fixed recently. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0021-05-Add-CLI-parsing-tests.patch Type: text/x-patch Size: 10474 bytes Desc: not available URL: From rcritten at redhat.com Tue Mar 27 17:56:39 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Mar 2012 13:56:39 -0400 Subject: [Freeipa-devel] [PATCH] 997 add client package requires on python-krbV Message-ID: <4F71FF57.3000301@redhat.com> We initialize ipalib in the client installer now so need a Requires on python-krbV. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-997-krbV.patch Type: text/x-patch Size: 1078 bytes Desc: not available URL: From pviktori at redhat.com Tue Mar 27 17:57:25 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 27 Mar 2012 19:57:25 +0200 Subject: [Freeipa-devel] [PATCH 68] text unit test should validate using installed mo file In-Reply-To: <4F71D58E.5060507@redhat.com> References: <4F71D00E.2070907@redhat.com> <4F71D58E.5060507@redhat.com> Message-ID: <4F71FF85.7090102@redhat.com> On 03/27/2012 04:58 PM, John Dennis wrote: [...] > def test_create_translation(): > f = text.create_translation > key = ('foo', None) > @@ -129,6 +45,84 @@ def test_create_translation(): > assert context.__dict__[key] is t > > > +class test_TestLang(object): > + def setUp(self): > + self.tmp_dir = None > + self.saved_lang = None > + > + self.lang = 'xh_ZA' > + self.domain = 'ipa' > + > + self.ipa_i18n_dir = os.path.join(os.path.dirname(__file__), '../../install/po') > + sys.path.insert(0, self.ipa_i18n_dir) To keep the test isolated, I would save sys.path before modifying it, wrap the insert and import in a try block, and restore the path in finally. Or even better, put the common code in an importable package: (most of) test_i18n.py could very well live under tests/. > + try: > + import test_i18n > + except ImportError, e: > + raise nose.SkipTest('cannot import test_i18n: %s') Why would test_i18n not be importable? > + self.pot_basename = '%s.pot' % self.domain > + self.po_basename = '%s.po' % self.lang > + self.mo_basename = '%s.mo' % self.domain > + [...] > + > + result = test_i18n.create_po(self.pot_file, self.po_file, self.mo_file) > + if result: > + raise nose.SkipTest('Unable to create po file "%s"& mo file "%s" from pot file "%s"' % > + (self.po_file, self.mo_file, self.pot_file)) > + > + if not file_exists(self.po_file): > + raise nose.SkipTest('Test po file unavailable, run "make test" in install/po') > + > + if not file_exists(self.mo_file): > + raise nose.SkipTest('Test mo file unavailable, run "make test" in install/po') Maybe it would be better to skip only if the pot file doesn't exist? Is there a reason the PO generation should fail? > + self.po_file_iterate = test_i18n.po_file_iterate Seeing this, I definitely recommend putting po_file_iterate in an importable package. > + def tearDown(self): > + if self.saved_lang is not None: > + os.environ['LANG'] = self.saved_lang > + > + if self.tmp_dir is not None: > + shutil.rmtree(self.tmp_dir) > + [...] One thing I missed in the previous patch: Makefile.in has a big comment near the end that's obsolete now. -- Petr? From simo at redhat.com Tue Mar 27 19:17:06 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 Mar 2012 15:17:06 -0400 Subject: [Freeipa-devel] [PATCH] 490 Fix s4u2proxy handling when a MS-PAC is available Message-ID: <1332875826.22628.51.camel@willson.li.ssimo.org> This patch fixes #2504, the logic to choose the client principal to use was basically reversed, and we ended up using the wrong principal to verify the PAC owner. This patch fixes it. Tested and s4u2proxy keeps working both with and without a PAC attached. It also keeps working with normal TGS requests of course. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-490-1-Fix-MS-PAC-checks-when-using-s4u2proxy.patch Type: text/x-patch Size: 1394 bytes Desc: not available URL: From jdennis at redhat.com Tue Mar 27 20:31:43 2012 From: jdennis at redhat.com (John Dennis) Date: Tue, 27 Mar 2012 16:31:43 -0400 Subject: [Freeipa-devel] [PATCH 68] text unit test should validate using installed mo file In-Reply-To: <4F71FF85.7090102@redhat.com> References: <4F71D00E.2070907@redhat.com> <4F71D58E.5060507@redhat.com> <4F71FF85.7090102@redhat.com> Message-ID: <4F7223AF.7030003@redhat.com> On 03/27/2012 01:57 PM, Petr Viktorin wrote: > Seeing this, I definitely recommend putting po_file_iterate in an > importable package. Of course I considered that. Clearly not any existing top level directory in the tree, those are reserved for what we install and what is "import visible" after installation. Test utility code should not be installed with our normal modules and packages. It has to be importable from both the install/po area and the test area. It can't depend on nosetests setting the import path prior to execution (because only the unit tests are run via nose). So we could create a directory tests/util which hosts utilities used for test code and locate it there. I did consider that, it would be (somewhat) cleaner. But unless I'm missing something someone is going to have to modify the include path prior to importing any test utility code. It just becomes a question of where the file is located. I'd be happy to move the bulk of the logic into tests/util/i18n.py, but to import it the importing code is going to have to add tests/util to the import path, which puts you pretty much back into the original situation, just with a different path (albeit perhaps a more logical cleaner path). -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Mar 27 21:40:41 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Mar 2012 17:40:41 -0400 Subject: [Freeipa-devel] [PATCH] 998 certmonger restarts services on renewal Message-ID: <4F7233D9.2080405@redhat.com> Certmonger will currently automatically renew server certificates but doesn't restart the services so you can still end up with expired certificates if you services never restart. This patch registers are restart command with certmonger so the IPA services will automatically be restarted to get the updated cert. Easy to test. Install IPA then resubmit the current server certs and watch the services restart: # ipa-getcert list Find the ID for either your dirsrv or httpd instance # ipa-getcert resubmit -i Watch /var/log/httpd/error_log or /var/log/dirsrv/slapd-INSTANCE/errors to see the service restart. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-998-certmonger.patch Type: text/x-patch Size: 11142 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 28 06:56:14 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 Mar 2012 08:56:14 +0200 Subject: [Freeipa-devel] [PATCH] 997 add client package requires on python-krbV In-Reply-To: <4F71FF57.3000301@redhat.com> References: <4F71FF57.3000301@redhat.com> Message-ID: <1332917774.9678.4.camel@balmora.brq.redhat.com> On Tue, 2012-03-27 at 13:56 -0400, Rob Crittenden wrote: > We initialize ipalib in the client installer now so need a Requires on > python-krbV. > > rob ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Wed Mar 28 07:11:12 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 Mar 2012 09:11:12 +0200 Subject: [Freeipa-devel] [PATCH] 0021 Add CLI tests In-Reply-To: <4F71F2C0.2070203@redhat.com> References: <4F575A01.1060501@redhat.com> <4F5E5A22.1010109@redhat.com> <4F5F2E39.2020301@redhat.com> <4F632BDD.1000608@redhat.com> <4F69E9AA.4040509@redhat.com> <4F71F2C0.2070203@redhat.com> Message-ID: <1332918672.9678.10.camel@balmora.brq.redhat.com> On Tue, 2012-03-27 at 19:02 +0200, Petr Viktorin wrote: > Updated with a regression test for > https://fedorahosted.org/freeipa/ticket/2581 (Unable to delete all sshfp > records interactively) which Martin fixed recently. > > Thank's for adding a specific test for this I see 2 issues with this patch: 1) DNS tests are not skipped when DNS is not configured: $ ./make-test tests/test_cmdline/test_cli.py test_cli.TestCLIParsing.test_dnsrecord_add ... ok test_cli.TestCLIParsing.test_dnsrecord_del_all ... ERROR test_cli.TestCLIParsing.test_dnsrecord_del_one_by_one ... ERROR test_cli.TestCLIParsing.test_group_add ... ok ... We should rather skip these test as we do in test_dns_plugin.py instead of failing with ERROR. 2) pprint is not needed, its output is not shown anyway as stdout is captured: +import pprint ... + pprint.pprint(kw_got) Martin From pviktori at redhat.com Wed Mar 28 08:19:29 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 Mar 2012 10:19:29 +0200 Subject: [Freeipa-devel] [PATCH] 0021 Add CLI tests In-Reply-To: <1332918672.9678.10.camel@balmora.brq.redhat.com> References: <4F575A01.1060501@redhat.com> <4F5E5A22.1010109@redhat.com> <4F5F2E39.2020301@redhat.com> <4F632BDD.1000608@redhat.com> <4F69E9AA.4040509@redhat.com> <4F71F2C0.2070203@redhat.com> <1332918672.9678.10.camel@balmora.brq.redhat.com> Message-ID: <4F72C991.3070309@redhat.com> On 03/28/2012 09:11 AM, Martin Kosek wrote: > On Tue, 2012-03-27 at 19:02 +0200, Petr Viktorin wrote: >> Updated with a regression test for >> https://fedorahosted.org/freeipa/ticket/2581 (Unable to delete all sshfp >> records interactively) which Martin fixed recently. >> >> > > Thank's for adding a specific test for this I see 2 issues with this > patch: > > 1) DNS tests are not skipped when DNS is not configured: > > $ ./make-test tests/test_cmdline/test_cli.py > test_cli.TestCLIParsing.test_dnsrecord_add ... ok > test_cli.TestCLIParsing.test_dnsrecord_del_all ... ERROR > test_cli.TestCLIParsing.test_dnsrecord_del_one_by_one ... ERROR > test_cli.TestCLIParsing.test_group_add ... ok > ... > > We should rather skip these test as we do in test_dns_plugin.py instead > of failing with ERROR. Good point, I added this. > 2) pprint is not needed, its output is not shown anyway as stdout is > captured: > +import pprint > ... > + pprint.pprint(kw_got) It is shown when the test fails; I found it quite useful when adding new tests. But you're right, it is not needed. Removed. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0021-06-Add-CLI-parsing-tests.patch Type: text/x-patch Size: 10661 bytes Desc: not available URL: From jcholast at redhat.com Wed Mar 28 08:39:01 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 28 Mar 2012 10:39:01 +0200 Subject: [Freeipa-devel] [PATCHES] Improve framework parameter validation In-Reply-To: <1332862893.26630.1.camel@balmora.brq.redhat.com> References: <4F61C63C.2050006@redhat.com> <4F61CD08.8090905@redhat.com> <4F61EC8D.5050208@redhat.com> <4F61F557.2040003@redhat.com> <1332856839.9937.42.camel@balmora.brq.redhat.com> <4F71CF02.9020809@redhat.com> <1332859329.9937.68.camel@balmora.brq.redhat.com> <1332862893.26630.1.camel@balmora.brq.redhat.com> Message-ID: <4F72CE25.4060900@redhat.com> On 27.3.2012 17:41, Martin Kosek wrote: > On Tue, 2012-03-27 at 16:42 +0200, Martin Kosek wrote: >> On Tue, 2012-03-27 at 16:30 +0200, Jan Cholasta wrote: >>> On 27.3.2012 16:00, Martin Kosek wrote: >>>> On Thu, 2012-03-15 at 14:57 +0100, Jan Cholasta wrote: >>>>> On 15.3.2012 14:20, Petr Viktorin wrote: >>>>>> On 03/15/2012 12:05 PM, Jan Cholasta wrote: >>>>>>> On 15.3.2012 11:36, Jan Cholasta wrote: >>>>>>>> (this is a continuation of >>>>>>>> ) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> the attached patches fix >>>>>>>> and: >>>>>>>> >>>>>>>> [PATCH] Fix the procedure for getting default values of command >>>>>>>> parameters. >>>>>>>> >>>>>>>> The parameters used in default_from of other parameters are now properly >>>>>>>> validated before the default_from is called. >>>>>>>> >>>>>>>> [PATCH] Change parameters to use only default_from for dynamic default >>>>>>>> values. >>>>>>>> >>>>>>>> Replace all occurences of create_default with equivalent default_from >>>>>>>> and remove create_default from the framework. This is needed for proper >>>>>>>> parameter validation, as there is no way to tell which parameters to >>>>>>>> validate prior to calling create_default, because create_default does >>>>>>>> not provide information about which parameters are used for generating >>>>>>>> the default value. >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> Forgot to remove one FIXME bit in dns.py. Update patch attached. >>>>>>> >>>>>>> Honza >>>>>> >>>>>> >>>>>> > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py >>>>>> > index a10960a..61c645d 100644 >>>>>> > --- a/ipalib/plugins/dns.py >>>>>> > +++ b/ipalib/plugins/dns.py >>>>>> > @@ -1528,7 +1528,7 @@ class dnszone(LDAPObject): >>>>>> > label=_('SOA serial'), >>>>>> > doc=_('SOA record serial number'), >>>>>> > minvalue=1, >>>>>> > - create_default=_create_zone_serial, >>>>>> > + default_from=_create_zone_serial, >>>>>> > autofill=True, >>>>>> > ), >>>>>> > Int('idnssoarefresh', >>>>>> > diff --git a/ipalib/plugins/passwd.py b/ipalib/plugins/passwd.py >>>>>> > index b26f7e9..9bee314 100644 >>>>>> > --- a/ipalib/plugins/passwd.py >>>>>> > +++ b/ipalib/plugins/passwd.py >>>>>> > @@ -69,7 +69,7 @@ class passwd(Command): >>>>>> > label=_('User name'), >>>>>> > primary_key=True, >>>>>> > autofill=True, >>>>>> > - create_default=lambda **kw: util.get_current_principal(), >>>>>> > + default_from=lambda: util.get_current_principal(), >>>>>> > normalizer=lambda value: normalize_principal(value), >>>>>> > ), >>>>>> > Password('password', >>>>>> >>>>>> >>>>>> This is just a minor nitpick, but I'd like to know if there's a reason >>>>>> behind it: why are you sometimes using lambda and sometimes not? >>>>> >>>>> I use lambda as a protective measure against accidents caused by adding >>>>> optional arguments to the functions used. _create_zone_serial is an >>>>> exception to that rule, because it is private to the dns plugin. >>>>> >>>>>> >>>>>> The patch works well here, but I think I'm not the one to ack it. >>>>>> >>>>> >>>>> Honza >>>>> >>>> >>>> The patch looks OK, I found just minor issues. >>>> >>>> 1) We may want to add some check for wildcards (**kw) in default_from, I >>>> guess it would mess with your dependency solver. Some nice error would >>>> warn developers that they are doing something bad. >>> >>> Added the check. >>> >>>> >>>> 2) Patch 47.4 needs minor rebasing >>> >>> Done. >>> >>>> >>>> Martin >>>> >>> >>> Updated patches attached. >>> >>> Honza >>> >> >> I think you squashed the change with an incorrect commit. The check >> should be rather included in patch 44. I beg to differ, patch 44 changes the way parameter defaults are generated, which is not affected by this change at all. The check is there just to warn developers early if they use default_from in a wrong way (it wouldn't have worked even without the check). This could have happened in patch 47, if I had done a bad job replacing create_default with default_from, so the check belongs there (or into a separate patch). >> >> Martin > > I just noticed it breaks one unit test: > > ====================================================================== > ERROR: Test the `ipalib.parameters.DefaultFrom.__init__` method. > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/home/mkosek/freeipa/tests/test_ipalib/test_parameters.py", line 52, in test_init > o = self.cls(callback, *keys) > File "/home/mkosek/freeipa/ipalib/parameters.py", line 201, in __init__ > raise ValueError("callback: variable-length argument list not allowed") > ValueError: callback: variable-length argument list not allowed > > ---------------------------------------------------------------------- Fixed. > > I also think it would be useful to have one test specifically for this > new check. Added. > > Martin > Updated patches attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-44.6-parameter-validation.patch Type: text/x-patch Size: 10028 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-47.6-parameter-remove-create-default.patch Type: text/x-patch Size: 14263 bytes Desc: not available URL: From pviktori at redhat.com Wed Mar 28 08:40:36 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 Mar 2012 10:40:36 +0200 Subject: [Freeipa-devel] [PATCH 68] text unit test should validate using installed mo file In-Reply-To: <4F7223AF.7030003@redhat.com> References: <4F71D00E.2070907@redhat.com> <4F71D58E.5060507@redhat.com> <4F71FF85.7090102@redhat.com> <4F7223AF.7030003@redhat.com> Message-ID: <4F72CE84.6010407@redhat.com> On 03/27/2012 10:31 PM, John Dennis wrote: > On 03/27/2012 01:57 PM, Petr Viktorin wrote: >> Seeing this, I definitely recommend putting po_file_iterate in an >> importable package. > > Of course I considered that. Clearly not any existing top level > directory in the tree, those are reserved for what we install and what > is "import visible" after installation. > > Test utility code should not be installed with our normal modules and > packages. > > It has to be importable from both the install/po area and the test area. > > It can't depend on nosetests setting the import path prior to execution > (because only the unit tests are run via nose). > > So we could create a directory tests/util which hosts utilities used for > test code and locate it there. I did consider that, it would be > (somewhat) cleaner. > > But unless I'm missing something someone is going to have to modify the > include path prior to importing any test utility code. It just becomes a > question of where the file is located. I'd be happy to move the bulk of > the logic into tests/util/i18n.py, but to import it the importing code > is going to have to add tests/util to the import path, which puts you > pretty much back into the original situation, just with a different path > (albeit perhaps a more logical cleaner path). Can install/po/Makefile just call test_i18n.py from the tests/ tree? It doesn't import any IPA code so there's no need to set sys.path in this case (though there'd have to be a comment saying we depend on this). In the other case, unit tests, the path is already set by Nose. Also the file would have to be renamed so nose doesn't pick it up as a test module. -- Petr? From pviktori at redhat.com Wed Mar 28 08:55:07 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 Mar 2012 10:55:07 +0200 Subject: [Freeipa-devel] [PATCH] 0032 Move DNS test skipping to class setup Message-ID: <4F72D1EB.7020007@redhat.com> Currently, each DNS test case first checks if DNS is configured by creating and deleting a test zone. This takes quite a lot of time. This patch moves the check to the setUpClass method, so the check is only done once for all the tests. On my VM, this makes the DNS plugin tests 50% faster, saving about half a minute for each test run. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0032-Move-DNS-test-skipping-to-class-setup.patch Type: text/x-patch Size: 1101 bytes Desc: not available URL: From sbose at redhat.com Wed Mar 28 09:36:27 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 28 Mar 2012 11:36:27 +0200 Subject: [Freeipa-devel] [PATCH] 490 Fix s4u2proxy handling when a MS-PAC is available In-Reply-To: <1332875826.22628.51.camel@willson.li.ssimo.org> References: <1332875826.22628.51.camel@willson.li.ssimo.org> Message-ID: <20120328093627.GG2369@localhost.localdomain> On Tue, Mar 27, 2012 at 03:17:06PM -0400, Simo Sorce wrote: > This patch fixes #2504, the logic to choose the client principal to use > was basically reversed, and we ended up using the wrong principal to > verify the PAC owner. > > This patch fixes it. Tested and s4u2proxy keeps working both with and > without a PAC attached. > > It also keeps working with normal TGS requests of course. ACK, '--delegate' is not neede anymore. bye, Sumit > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Mar 28 12:06:37 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 Mar 2012 14:06:37 +0200 Subject: [Freeipa-devel] [PATCHES] Improve framework parameter validation In-Reply-To: <4F72CE25.4060900@redhat.com> References: <4F61C63C.2050006@redhat.com> <4F61CD08.8090905@redhat.com> <4F61EC8D.5050208@redhat.com> <4F61F557.2040003@redhat.com> <1332856839.9937.42.camel@balmora.brq.redhat.com> <4F71CF02.9020809@redhat.com> <1332859329.9937.68.camel@balmora.brq.redhat.com> <1332862893.26630.1.camel@balmora.brq.redhat.com> <4F72CE25.4060900@redhat.com> Message-ID: <1332936397.9678.13.camel@balmora.brq.redhat.com> On Wed, 2012-03-28 at 10:39 +0200, Jan Cholasta wrote: > On 27.3.2012 17:41, Martin Kosek wrote: > > On Tue, 2012-03-27 at 16:42 +0200, Martin Kosek wrote: > >> On Tue, 2012-03-27 at 16:30 +0200, Jan Cholasta wrote: > >>> On 27.3.2012 16:00, Martin Kosek wrote: > >>>> On Thu, 2012-03-15 at 14:57 +0100, Jan Cholasta wrote: > >>>>> On 15.3.2012 14:20, Petr Viktorin wrote: > >>>>>> On 03/15/2012 12:05 PM, Jan Cholasta wrote: > >>>>>>> On 15.3.2012 11:36, Jan Cholasta wrote: > >>>>>>>> (this is a continuation of > >>>>>>>> ) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> the attached patches fix > >>>>>>>> and: > >>>>>>>> > >>>>>>>> [PATCH] Fix the procedure for getting default values of command > >>>>>>>> parameters. > >>>>>>>> > >>>>>>>> The parameters used in default_from of other parameters are now properly > >>>>>>>> validated before the default_from is called. > >>>>>>>> > >>>>>>>> [PATCH] Change parameters to use only default_from for dynamic default > >>>>>>>> values. > >>>>>>>> > >>>>>>>> Replace all occurences of create_default with equivalent default_from > >>>>>>>> and remove create_default from the framework. This is needed for proper > >>>>>>>> parameter validation, as there is no way to tell which parameters to > >>>>>>>> validate prior to calling create_default, because create_default does > >>>>>>>> not provide information about which parameters are used for generating > >>>>>>>> the default value. > >>>>>>>> > >>>>>>>> Honza > >>>>>>>> > >>>>>>> > >>>>>>> Forgot to remove one FIXME bit in dns.py. Update patch attached. > >>>>>>> > >>>>>>> Honza > >>>>>> > >>>>>> > >>>>>> > diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py > >>>>>> > index a10960a..61c645d 100644 > >>>>>> > --- a/ipalib/plugins/dns.py > >>>>>> > +++ b/ipalib/plugins/dns.py > >>>>>> > @@ -1528,7 +1528,7 @@ class dnszone(LDAPObject): > >>>>>> > label=_('SOA serial'), > >>>>>> > doc=_('SOA record serial number'), > >>>>>> > minvalue=1, > >>>>>> > - create_default=_create_zone_serial, > >>>>>> > + default_from=_create_zone_serial, > >>>>>> > autofill=True, > >>>>>> > ), > >>>>>> > Int('idnssoarefresh', > >>>>>> > diff --git a/ipalib/plugins/passwd.py b/ipalib/plugins/passwd.py > >>>>>> > index b26f7e9..9bee314 100644 > >>>>>> > --- a/ipalib/plugins/passwd.py > >>>>>> > +++ b/ipalib/plugins/passwd.py > >>>>>> > @@ -69,7 +69,7 @@ class passwd(Command): > >>>>>> > label=_('User name'), > >>>>>> > primary_key=True, > >>>>>> > autofill=True, > >>>>>> > - create_default=lambda **kw: util.get_current_principal(), > >>>>>> > + default_from=lambda: util.get_current_principal(), > >>>>>> > normalizer=lambda value: normalize_principal(value), > >>>>>> > ), > >>>>>> > Password('password', > >>>>>> > >>>>>> > >>>>>> This is just a minor nitpick, but I'd like to know if there's a reason > >>>>>> behind it: why are you sometimes using lambda and sometimes not? > >>>>> > >>>>> I use lambda as a protective measure against accidents caused by adding > >>>>> optional arguments to the functions used. _create_zone_serial is an > >>>>> exception to that rule, because it is private to the dns plugin. > >>>>> > >>>>>> > >>>>>> The patch works well here, but I think I'm not the one to ack it. > >>>>>> > >>>>> > >>>>> Honza > >>>>> > >>>> > >>>> The patch looks OK, I found just minor issues. > >>>> > >>>> 1) We may want to add some check for wildcards (**kw) in default_from, I > >>>> guess it would mess with your dependency solver. Some nice error would > >>>> warn developers that they are doing something bad. > >>> > >>> Added the check. > >>> > >>>> > >>>> 2) Patch 47.4 needs minor rebasing > >>> > >>> Done. > >>> > >>>> > >>>> Martin > >>>> > >>> > >>> Updated patches attached. > >>> > >>> Honza > >>> > >> > >> I think you squashed the change with an incorrect commit. The check > >> should be rather included in patch 44. > > I beg to differ, patch 44 changes the way parameter defaults are > generated, which is not affected by this change at all. The check is > there just to warn developers early if they use default_from in a wrong > way (it wouldn't have worked even without the check). This could have > happened in patch 47, if I had done a bad job replacing create_default > with default_from, so the check belongs there (or into a separate patch). Ok, it makes a sense as well. > > >> > >> Martin > > > > I just noticed it breaks one unit test: > > > > ====================================================================== > > ERROR: Test the `ipalib.parameters.DefaultFrom.__init__` method. > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > > self.test(*self.arg) > > File "/home/mkosek/freeipa/tests/test_ipalib/test_parameters.py", line 52, in test_init > > o = self.cls(callback, *keys) > > File "/home/mkosek/freeipa/ipalib/parameters.py", line 201, in __init__ > > raise ValueError("callback: variable-length argument list not allowed") > > ValueError: callback: variable-length argument list not allowed > > > > ---------------------------------------------------------------------- > > Fixed. > > > > > I also think it would be useful to have one test specifically for this > > new check. > > Added. > > > > > Martin > > > > Updated patches attached. > > Honza > ACK. Pushed to master, ipa-2-2. Martin From mkosek at redhat.com Wed Mar 28 13:27:30 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 Mar 2012 15:27:30 +0200 Subject: [Freeipa-devel] [PATCH] 0021 Add CLI tests In-Reply-To: <4F72C991.3070309@redhat.com> References: <4F575A01.1060501@redhat.com> <4F5E5A22.1010109@redhat.com> <4F5F2E39.2020301@redhat.com> <4F632BDD.1000608@redhat.com> <4F69E9AA.4040509@redhat.com> <4F71F2C0.2070203@redhat.com> <1332918672.9678.10.camel@balmora.brq.redhat.com> <4F72C991.3070309@redhat.com> Message-ID: <1332941250.9678.25.camel@balmora.brq.redhat.com> On Wed, 2012-03-28 at 10:19 +0200, Petr Viktorin wrote: > On 03/28/2012 09:11 AM, Martin Kosek wrote: > > On Tue, 2012-03-27 at 19:02 +0200, Petr Viktorin wrote: > >> Updated with a regression test for > >> https://fedorahosted.org/freeipa/ticket/2581 (Unable to delete all sshfp > >> records interactively) which Martin fixed recently. > >> > >> > > > > Thank's for adding a specific test for this I see 2 issues with this > > patch: > > > > 1) DNS tests are not skipped when DNS is not configured: > > > > $ ./make-test tests/test_cmdline/test_cli.py > > test_cli.TestCLIParsing.test_dnsrecord_add ... ok > > test_cli.TestCLIParsing.test_dnsrecord_del_all ... ERROR > > test_cli.TestCLIParsing.test_dnsrecord_del_one_by_one ... ERROR > > test_cli.TestCLIParsing.test_group_add ... ok > > ... > > > > We should rather skip these test as we do in test_dns_plugin.py instead > > of failing with ERROR. > > Good point, I added this. > > > 2) pprint is not needed, its output is not shown anyway as stdout is > > captured: > > +import pprint > > ... > > + pprint.pprint(kw_got) > > It is shown when the test fails; I found it quite useful when adding new > tests. But you're right, it is not needed. Removed. > > ACK. Pushed to master, ipa-2-2. Martin From rcritten at redhat.com Wed Mar 28 14:13:47 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Mar 2012 10:13:47 -0400 Subject: [Freeipa-devel] [PATCH] 239 Tolerate UDP port failures in conncheck In-Reply-To: <1331891131.27127.23.camel@balmora.brq.redhat.com> References: <1331891131.27127.23.camel@balmora.brq.redhat.com> Message-ID: <4F731C9B.1030709@redhat.com> Martin Kosek wrote: > UDP port checks in ipa-replica-conncheck are too strict. The entire > conncheck fails when UDP ports cannot be verified as open. However, > UDP protocol is unrealiable by its nature and the port can also not > be checked if there is an application already bound to it. This can > happen for example when ipa-replica-conncheck is run as a part of > ipa-ca-install and the replica services are thus already running. > > This patch changes the behavior of UDP port checks. The conncheck > script now rather reports a warning that UDP port cannot be verified > but does not fail the entire test. > > https://fedorahosted.org/freeipa/ticket/2514 ACK, pushed to master and ipa-2-2 From mkosek at redhat.com Wed Mar 28 14:25:53 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 28 Mar 2012 16:25:53 +0200 Subject: [Freeipa-devel] [PATCH] 16 Netgroup nisdomain and hosts validation In-Reply-To: <4F71E335.7010000@redhat.com> References: <4F58B9A8.2000508@redhat.com> <1331307242.26839.24.camel@balmora.brq.redhat.com> <4F60BF41.3000301@redhat.com> <1331795633.27127.3.camel@balmora.brq.redhat.com> <4F6CF4D4.5020906@redhat.com> <1332849467.9937.37.camel@balmora.brq.redhat.com> <4F71E335.7010000@redhat.com> Message-ID: <1332944753.9678.26.camel@balmora.brq.redhat.com> On Tue, 2012-03-27 at 17:56 +0200, Ondrej Hamada wrote: > On 03/27/2012 01:57 PM, Martin Kosek wrote: > > On Fri, 2012-03-23 at 23:10 +0100, Ondrej Hamada wrote: > >> On 03/15/2012 08:13 AM, Martin Kosek wrote: > >>> On Wed, 2012-03-14 at 16:54 +0100, Ondrej Hamada wrote: > >>>> On 03/09/2012 04:34 PM, Martin Kosek wrote: > >>>>> On Thu, 2012-03-08 at 14:52 +0100, Ondrej Hamada wrote: > >>>>>> Netgroup nisdomain and hosts validation > >>>>>> > >>>>>> nisdomain validation: > >>>>>> Added pattern to the 'nisdomain' parameter to validate the specified > >>>>>> nisdomain name. According to most common use cases the same patter as > >>>>>> for netgroup should fit. Unit-tests added. > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/2447 > >>>>>> > >>>>>> hosts validation: > >>>>>> Added precallback to netgroup_add_member. It validates the specified > >>>>>> hostnames and raises ValidationError exception for invalid hostnames. > >>>>>> Unit-test added. > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/2448 > >>>>> I checked the host validation part and it could be improved. Issue > >>>>> described in #2447 (you have switched the ticket IDs) affects all > >>>>> objects that allow external hosts, users, ..., i.e. those who call > >>>>> add_external_post_callback in their post_callback. > >>>>> > >>>>> Should we fix all of these when we deal with this issue? Otherwise user > >>>>> could do something like this: > >>>>> # ipa sudorule-add-user foo --users=a+b > >>>>> Rule name: foo > >>>>> Enabled: TRUE > >>>>> External User: a+b > >>>>> > >>>>> We could create a similar function called add_external_pre_callback() > >>>>> and pass it attribute name and validating function (which would be > >>>>> common with the linked object). It would then do the validation for all > >>>>> these affected objects consistently and without redundant code. > >>>>> > >>>>> I didn't liked much the implemented pre_callback anyway > >>>>> > >>>>> + def pre_callback(self, ldap, dn, found, not_found, *keys, > >>>>> **options): > >>>>> + # validate entered hostnames > >>>>> + if 'host' in options: > >>>>> + invalid_hostnames=[] > >>>>> + for hostname in options['host']: > >>>>> + try: > >>>>> + validate_hostname(hostname, False) > >>>>> + except ValueError: > >>>>> + invalid_hostnames.append(hostname) > >>>>> + if invalid_hostnames: > >>>>> + raise errors.ValidationError(name='host', > >>>>> error='hostnames:\"%s\" contain invalid characters' % > >>>>> ','.join(invalid_hostnames)) > >>>>> + return dn > >>>>> > >>>>> I would rather raise the ValidationError with the first invalid hostname > >>>>> and tell what's wrong (function validate_hostname tells it to you). If > >>>>> you go with the proposed approach, you wouldn't have to deal with > >>>>> formatting error messages, you would just raise the one returned by the > >>>>> validator shared with the linked LDAP object (hostname, user, ...). > >>>>> > >>>>> Martin > >>>> external_pre_callback function seems as a good idea, but there is a > >>>> problem how to get the validators for various LDAP objects. For the > >>>> hostname we already have one in ipalib.utils, but for the uid or group > >>>> name we use only patterns specified in the parameter objects. > >>>> > >>>> Below I propose solution how to use the already defined parameter > >>>> objects for validation (the only problem is that I have to assume, that > >>>> it is always the first parameter in takes_params). Do you think this is > >>>> a good approach? > >>> I think the approach is OK, it can just be much improved in order to get > >>> rid of the hardcoded parts. See comments below. > >>> > >>>> def add_external_pre_callback(memberattr, membertype, externalattr, > >>>> ldap, dn, found, not_found, *keys, **options): > >>>> """ > >>>> Pre callback to validate external members. > >>>> """ > >>>> if membertype in options: > >>>> validator = api.Object[membertype].takes_params[0] > >>> You can use api.Object[membertype].params[memberattr] > >>> > >>>> for value in options[membertype]: > >>>> try: > >>>> validator(value) > >>>> except errors.ValidationError as e: > >>>> error_msg = e[(e.find(':')+1):] > >>> You don't have to parse error message, you can just use e.name or > >>> e.error right from the caught ValidationError. > >>> > >>>> raise errors.ValidationError(name=membertype, > >>>> error=e[e.find(':')+1:]) > >>>> return dn > >>>> > >> nisdomain validation: > >> Added pattern to the 'nisdomain' parameter to validate the specified > >> nisdomain name. According to most common use cases the same pattern as > >> for netgroup should fit. Unit-tests added. > >> > >> https://fedorahosted.org/freeipa/ticket/2448 > >> > >> 'add_external_pre_callback' function was created to allow validation of > >> all external members. Validation is based on usage of objects primary > >> key parameter. The 'add_external_pre_callback' fucntion has to be called > >> directly from in the 'pre_callback' function. This change affects > >> netgroup, hbacrule and sudorule commands. > >> > >> Special validator is used only for hostname, the validator requires > >> fully qualified > >> domain name and enables the hostnames to contain underscores. > >> > >> Unit-tests added. > >> > >> https://fedorahosted.org/freeipa/ticket/2447 > >> > > This is better, but I still see few issues: > > > > 1) You copied hostname validator instead of extending validate_hostname > > function in ipalib.util with allow_underscore parameter which is already > > available in validate_dns_label. Having duplicate functions like this is > > just wrong and can lead to errors in future. > > > > 2) I also wonder if externalHost can contain non-fqdn hosts. In such > > case, you would just add check_fqdn=False to validate_hostname. > > > > Martin > > > corrected patch attached > Yup, its ok now. ACK. Pushed to master, ipa-2-2. Martin From pviktori at redhat.com Wed Mar 28 16:30:50 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 28 Mar 2012 18:30:50 +0200 Subject: [Freeipa-devel] [PATCH] 0022 Use ipauniqueid for the RDN of sudo commands (rebased) In-Reply-To: <4F5F8147.7080306@redhat.com> References: <4F58D6E8.7040202@redhat.com> <1331555217.1491.31.camel@balmora.brq.redhat.com> <4F5DFC4C.1080906@redhat.com> <1331564466.1491.57.camel@balmora.brq.redhat.com> <1331567074.1491.63.camel@balmora.brq.redhat.com> <4F5F8147.7080306@redhat.com> Message-ID: <4F733CBA.3070800@redhat.com> Earlier, someone (I think Alexander?) mentioned off-list that since the sudocmd attribute is case-sensitive, it should be compared as case-sensitive when used in the DN, so this is a directory server bug. I found now that ipalib.dn.AVA.__eq__'s docstring says: The value comparison is also case insensitive because the all [sic] attribute types used in a DN are derived from the 'name' atribute type (OID 2.5.4.41) whose EQUALITY MATCH RULE is caseIgnoreMatch. We do case-insensitive compares on DNs, and there's no easy way to change this (the DN code knows nothing about a particular schema, including case-sensitivity of its attributes). So however DS is supposed to work (I don't have a manual handy), we're pretty much committed to case-insensitive attributes in DNs. -- Petr? From mgregg at redhat.com Wed Mar 28 19:12:40 2012 From: mgregg at redhat.com (Michael Gregg) Date: Wed, 28 Mar 2012 12:12:40 -0700 Subject: [Freeipa-devel] web ui error Message-ID: <4F7362A8.3080201@redhat.com> I am trying to use the webui on a ipa machine I have here and I seem to be unable to make it work properly. I load a browser on the machine and head to the webui, in this case https://ipaqavmc.testrelm.com/ipa/ui I've kinited as admin, and I have run through the browser setup as per the instructions the webui gives me. When the ui is about to load I get a popup that says "internal server error" in /var/log/httd/error_log I get: [Wed Mar 28 15:05:44 2012] [error] [client 10.16.98.180] mod_wsgi (pid=18940): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. [Wed Mar 28 15:05:44 2012] [error] [client 10.16.98.180] Traceback (most recent call last): [Wed Mar 28 15:05:44 2012] [error] [client 10.16.98.180] File "/usr/share/ipa/wsgi.py", line 49, in application [Wed Mar 28 15:05:44 2012] [error] [client 10.16.98.180] return api.Backend.wsgi_dispatch(environ, start_response) [Wed Mar 28 15:05:44 2012] [error] [client 10.16.98.180] File "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 229, in __call__ [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] return self.route(environ, start_response) [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] File "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 241, in route [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] return app(environ, start_response) [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] File "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 792, in __call__ [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] ipa_ccache_name = bind_ipa_ccache(ccache_data) [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] File "/usr/lib/python2.6/site-packages/ipalib/session.py", line 1228, in bind_ipa_ccache [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] dst = open(name, 'w') [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] IOError: [Errno 13] Permission denied: '/var/run/ipa_memcached/krbcc_18940' I'm not sure what is going on. I then set the permissions of /var/run/ipa_memcached to full open: drwxrwxrwx. 2 apache apache 4096 Mar 20 19:02 ipa_memcached Any ideas on what I can do to make the webui work? Michael- From rcritten at redhat.com Wed Mar 28 19:14:15 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Mar 2012 15:14:15 -0400 Subject: [Freeipa-devel] web ui error In-Reply-To: <4F7362A8.3080201@redhat.com> References: <4F7362A8.3080201@redhat.com> Message-ID: <4F736307.60405@redhat.com> Michael Gregg wrote: > > I am trying to use the webui on a ipa machine I have here and I seem to > be unable to make it work properly. > > I load a browser on the machine and head to the webui, in this case > https://ipaqavmc.testrelm.com/ipa/ui > > I've kinited as admin, and I have run through the browser setup as per > the instructions the webui gives me. > > When the ui is about to load I get a popup that says "internal server > error" > > in /var/log/httd/error_log I get: > > [Wed Mar 28 15:05:44 2012] [error] [client 10.16.98.180] mod_wsgi > (pid=18940): Exception occurred processing WSGI script > '/usr/share/ipa/wsgi.py'. > [Wed Mar 28 15:05:44 2012] [error] [client 10.16.98.180] Traceback (most > recent call last): > [Wed Mar 28 15:05:44 2012] [error] [client 10.16.98.180] File > "/usr/share/ipa/wsgi.py", line 49, in application > [Wed Mar 28 15:05:44 2012] [error] [client 10.16.98.180] return > api.Backend.wsgi_dispatch(environ, start_response) > [Wed Mar 28 15:05:44 2012] [error] [client 10.16.98.180] File > "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 229, in > __call__ > [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] return > self.route(environ, start_response) > [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] File > "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 241, in > route > [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] return > app(environ, start_response) > [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] File > "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 792, in > __call__ > [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] ipa_ccache_name > = bind_ipa_ccache(ccache_data) > [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] File > "/usr/lib/python2.6/site-packages/ipalib/session.py", line 1228, in > bind_ipa_ccache > [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] dst = > open(name, 'w') > [Wed Mar 28 15:05:45 2012] [error] [client 10.16.98.180] IOError: [Errno > 13] Permission denied: '/var/run/ipa_memcached/krbcc_18940' > > I'm not sure what is going on. I then set the permissions of > /var/run/ipa_memcached to full open: > drwxrwxrwx. 2 apache apache 4096 Mar 20 19:02 ipa_memcached > > Any ideas on what I can do to make the webui work? > > Michael- See if SELinux is complaining about the file. What version of ipa-server? rob From jdennis at redhat.com Wed Mar 28 19:19:54 2012 From: jdennis at redhat.com (John Dennis) Date: Wed, 28 Mar 2012 15:19:54 -0400 Subject: [Freeipa-devel] web ui error In-Reply-To: <4F7362A8.3080201@redhat.com> References: <4F7362A8.3080201@redhat.com> Message-ID: <4F73645A.1000300@redhat.com> On 03/28/2012 03:12 PM, Michael Gregg wrote: > > I am trying to use the webui on a ipa machine I have here and I seem to > be unable to make it work properly. > > I load a browser on the machine and head to the webui, in this case > https://ipaqavmc.testrelm.com/ipa/ui > > I've kinited as admin, and I have run through the browser setup as per > the instructions the webui gives me. > > When the ui is about to load I get a popup that says "internal server error" > > in /var/log/httd/error_log I get: This is probably an SELinux issue. Try putting the machine in permissive mode and restart ipa. Does the problem go away? If so we've fixed this and you must have old packages, please update. Also, could you do us a favor, when providing tracebacks with long lines it's very hard to read when your mail client wraps the lines, could you please either attach them as a text file or point us to a pastebin? Thanks. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mgregg at redhat.com Wed Mar 28 20:31:15 2012 From: mgregg at redhat.com (Michael Gregg) Date: Wed, 28 Mar 2012 13:31:15 -0700 Subject: [Freeipa-devel] web ui error In-Reply-To: <4F73645A.1000300@redhat.com> References: <4F7362A8.3080201@redhat.com> <4F73645A.1000300@redhat.com> Message-ID: <4F737513.4060505@redhat.com> On 03/28/2012 12:19 PM, John Dennis wrote: > On 03/28/2012 03:12 PM, Michael Gregg wrote: >> >> I am trying to use the webui on a ipa machine I have here and I seem to >> be unable to make it work properly. >> >> I load a browser on the machine and head to the webui, in this case >> https://ipaqavmc.testrelm.com/ipa/ui >> >> I've kinited as admin, and I have run through the browser setup as per >> the instructions the webui gives me. >> >> When the ui is about to load I get a popup that says "internal server >> error" >> >> in /var/log/httd/error_log I get: > > This is probably an SELinux issue. Try putting the machine in > permissive mode and restart ipa. Does the problem go away? If so we've > fixed this and you must have old packages, please update. > > Also, could you do us a favor, when providing tracebacks with long > lines it's very hard to read when your mail client wraps the lines, > could you please either attach them as a text file or point us to a > pastebin? Thanks. > > It was a selinux problem. I'm on ipa-server version: ipa-server-2.2.0-4.el6.x86_64 Maybe I need a newer version? And I'll attach these errors/tracebacks with pastebin attachments in the future. Michael- From rcritten at redhat.com Wed Mar 28 21:28:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Mar 2012 17:28:33 -0400 Subject: [Freeipa-devel] [PATCH] 993 disable UPG for migration In-Reply-To: <1332493947.17059.24.camel@balmora.brq.redhat.com> References: <4F6B7B9F.4080105@redhat.com> <1332493947.17059.24.camel@balmora.brq.redhat.com> Message-ID: <4F738281.3080505@redhat.com> Martin Kosek wrote: > On Thu, 2012-03-22 at 15:21 -0400, Rob Crittenden wrote: >> We don't want to create private groups automatically for migrated users, >> there could be namespace overlap (and race conditions prevent us from >> trying to check in advance). >> >> Check the sanity of groups in general, warn if the group for the >> gidnumber doesn't exist at least on the remote server. >> >> Fill in the user's shell as well. >> >> This will migrate users that are non-POSIX on the remote server. >> >> rob > > This patch fixes the problem of creating UPGs for migrated users, but > there are several parts which confused me. > > 1) Confusing defaults > > + if 'def_group_gid' in ctx: > + entry_attrs.setdefault('gidnumber', ctx['def_group_gid']) > > This statement seems redundant, because the account either is posix and > has both uidnumber and gidnumber or it is non-posix and does not have > any. > > Now, we don't touch gidNumber for posix user, and non-posix users are > made posix with this statement: > > + # migrated user is not already POSIX, make it so > + if 'uidnumber' not in entry_attrs: > + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] > > > 2) Missing UPG > When UPG is disabled, the following statement will result in a user with > a GID pointing to non-existent group. > > + # migrated user is not already POSIX, make it so > + if 'uidnumber' not in entry_attrs: > + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] > > We may want to run ldap.has_upg() and report a add this user to "failed > users" with appropriate error. > > 3) Check for GID > The patch implements a check if a group with the gidNumber exists on a > remote LDAP server and the result is a warning: > > - (g_dn, g_attrs) = ldap.get_entry(ctx['def_group_dn'], ['gidnumber']) > + (remote_dn, remote_entry) = ds_ldap.find_entry_by_attr( > + 'gidnumber', entry_attrs['gidnumber'][0], 'posixgroup', [''], > + search_bases['group'] > + ) > > I have few (minor-ish) questions there: > a) Is the warning in a apache log enough? Maybe it should be included in > migrate-ds output. > b) This will be a one more remote LDAP call for every user, we may want > to optimize it with something like that: > > valid_gids = [] > if user.gidnumber not in valid_gids: > run the check in remote LDAP > valid_gids.append(user.gidnumber) > > That would save us 999 LDAP queries for 1000 migrated with the same > primary group. > > 4) Extraneous Warning: > When non-posix user is migrated and thus we make it a posix user, we > still produce a warning for non-existent group: > > [Fri Mar 23 04:21:36 2012] [error] ipa: WARNING: Migrated user's GID > number 999 does not point to a known group. > > 5) Extraneous LDAP call > > Isn't the following call to LDAP to get a description redundant? We > already have the description in entry_attrs. > > + (dn, desc_attr) = ldap.get_entry(dn, ['description']) > + entry_attrs.update(desc_attr) > + if 'description' in entry_attrs and NO_UPG_MAGIC in > entry_attrs['description']: > > > Martin > I think this covers your concerns. I can't do anything but log warnings at this point in order to maintain backwards compatibility. I looked into returning a warning entry and it blew up in validate_output() on older clients. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-993-2-migration.patch Type: text/x-patch Size: 10263 bytes Desc: not available URL: From rcritten at redhat.com Wed Mar 28 22:20:36 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Mar 2012 18:20:36 -0400 Subject: [Freeipa-devel] [PATCH] 971 detect binary LDAP data In-Reply-To: <4F4F8C28.6050607@redhat.com> References: <4F4B96DE.60805@redhat.com> <1330357665.2718.11.camel@willson.li.ssimo.org> <4F4BA7FD.5040209@redhat.com> <4F4BAB11.3070608@redhat.com> <4F4BB316.3020500@redhat.com> <4F4C43B7.4030601@redhat.com> <4F4C91B8.4040102@redhat.com> <4F4CF689.5030808@redhat.com> <4F4D0889.1090105@redhat.com> <4F4D14FD.70402@redhat.com> <4F4D15E2.6000101@redhat.com> <4F4DEC91.603@redhat.com> <4F4E39EF.5080607@redhat.com> <4F4F8C28.6050607@redhat.com> Message-ID: <4F738EB4.8030802@redhat.com> Jan Cholasta wrote: > On 29.2.2012 15:45, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 28.2.2012 18:58, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> On 28.2.2012 18:02, Petr Viktorin wrote: >>>>>> On 02/28/2012 04:45 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 02/28/2012 04:02 AM, Rob Crittenden wrote: >>>>>>>>> Petr Viktorin wrote: >>>>>>>>>> On 02/27/2012 05:10 PM, Rob Crittenden wrote: >>>>>>>>>>> Rob Crittenden wrote: >>>>>>>>>>>> Simo Sorce wrote: >>>>>>>>>>>>> On Mon, 2012-02-27 at 09:44 -0500, Rob Crittenden wrote: >>>>>>>>>>>>>> We are pretty trusting that the data coming out of LDAP >>>>>>>>>>>>>> matches >>>>>>>>>>>>>> its >>>>>>>>>>>>>> schema but it is possible to stuff non-printable characters >>>>>>>>>>>>>> into >>>>>>>>>>>>>> most >>>>>>>>>>>>>> attributes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've added a sanity checker to keep a value as a python str >>>>>>>>>>>>>> type >>>>>>>>>>>>>> (treated as binary internally). This will result in a base64 >>>>>>>>>>>>>> encoded >>>>>>>>>>>>>> blob be returned to the client. >>>>> >>>>> I don't like the idea of having arbitrary binary data where unicode >>>>> strings are expected. It might cause some unexpected errors (I have a >>>>> feeling that --addattr and/or --delattr and possibly some plugins >>>>> might >>>>> not handle this very well). Wouldn't it be better to just throw away >>>>> the >>>>> value if it's invalid and warn the user? >>>> >>>> This isn't for user input, it is for data stored in LDAP. User's are >>>> going to have no way to provide binary data to us unless they use the >>>> API themselves in which case they have to follow our rules. >>> >>> Well my point was that --addattr and --delattr cause an LDAP search for >>> the given attribute and plugins might get the result of a LDAP search in >>> their post_callback and I'm not sure if they can cope with binary data. >> >> It wouldn't be any different than if we had the value as a unicode. > > Let's see what happens if the mail attribute of a user contains invalid > UTF-8 (ff 62 30 72 6b 65 64): > > $ ipa user-find jdoe > -------------- > 1 user matched > -------------- > User login: jdoe > First name: John > Last name: Doe > Home directory: /home/jdoe > Login shell: /bin/sh > Email address: /2IwcmtlZA== > UID: 526 > GID: 526 > Account disabled: False > Password: False > Kerberos keys available: False > ---------------------------- > Number of entries returned 1 > ---------------------------- > > $ ipa user-mod jdoe --addattr mail=jdoe at example.com > ipa: ERROR: an internal error has occurred > > The internal error is: > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line > 302, in wsgi_execute > result = self.Command[name](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in > __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in > run > return self.execute(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line > 1217, in execute > ldap, dn, entry_attrs, attrs_list, *keys, **options > File "/usr/lib/python2.7/site-packages/ipalib/plugins/user.py", line > 532, in pre_callback > entry_attrs['mail'] = self.obj._normalize_email(entry_attrs['mail']) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/user.py", line > 338, in _normalize_email > norm_email.append(m + u'@' + config['ipadefaultemaildomain'][0]) > UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 0: > invalid start byte > > $ ipa user-mod jdoe --delattr mail=/2IwcmtlZA== > ipa: ERROR: mail does not contain '/2IwcmtlZA==' > > $ ipa user-mod jdoe --delattr mail=`echo 'ff 62 30 72 6b 65 64' | xxd -p > -r` > ipa: ERROR: UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in > position 5: invalid start byte > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1242, in run > sys.exit(api.Backend.cli.run(argv)) > File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1024, in run > kw = self.parse(cmd, argv) > File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1049, in parse > return dict(self.parse_iter(cmd, kw)) > File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1058, in > parse_iter > yield (key, self.Backend.textui.decode(value)) > File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 136, in decode > return value.decode(encoding) > File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode > return codecs.utf_8_decode(input, errors, True) > UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 5: > invalid start byte > ipa: ERROR: an internal error has occurred > > I'm sure there is a lot more places in the code where things will break > when you feed them arbitrary data. > >> >> We treat the python type str as binary data. Anything that is a str gets >> based64 encoded before json or xml-rpc transmission. >> >> The type unicode is considered a "string" and goes in the clear. >> >> We determine what this type should be not from the data but from the >> schema. This is a big assumption. Hopefully this answer's Petr's point >> as well. >> >> We decided long ago that str means Binary and unicode means String. It >> is a bit clumsy perhaps python handles it well. It will be more clear >> when we switch to Python 3.0 and we'll have bytes and str instead as >> types. > > Well, this is all super-obvious and I'm not really sure why do you bring > it up here... > > My concern is that with your approach, you can no longer be sure that an > attribute value is a valid unicode string. This creates a > maintainability burden, as you *always* have to keep in mind that you > first have to check whether the value is valid or not before touching > it. You can easily forget to include the check in new code and there is > a lot of places in old code that need to be changed because of this (as > you can see in the mail example above). > > Let me quote John Dennis > (): > >> I'm very interested in this work. I too have recognized that we have a >> very real structural problem with how we handle the types we use >> internally, especially when it corresponds to an external type and >> requires conversion. In fact we do a remarkably bad job in this area, we >> have conversions which are done ad hoc all over the place. There is no >> well established place for the conversions to occur and it's difficult >> to know at any point in the code what type to expect. > > Your patch adds yet another occurence of "it's difficult to know at any > point in the code what type to expect". IMO this is very bad and we > should not do this at all in new code. > > I'm not sure if just dropping bad values (as I have suggested before) is > the best idea, but IMHO anything is better than letting these bad values > into the bowels of IPA. > >> >>>> We are trusting that the data in LDAP matches its schema. This is just >>>> belt and suspenders verifying that it is the case. >>> >>> Sure, but I still think we should allow any valid unicode data to come >>> from LDAP, not just what is valid in XML-RPC. >> >> This won't affect data coming out of LDAP, only the way it is >> transmitted to the client. > > It will affect the data flowing through IPA, after we get it from LDAP, > before it is transmitted through XML-RPC. > > In other words, I think it is more correct to do this: > > LDAP -> check unicode validity -> (rest of IPA) -> check XML-RPC > validitity -> XML-RPC > > than this: > > LDAP -> check unicode validity -> check XML-RPC validity -> (rest of > IPA) -> XML-RPC > > (Let's keep things isolated please.) > >> >> rob > > Honza > I'm using a much narrower scope. I'm not trying to make it easy to manage non-printable characters, just not blow things up if they exist. Limiting to the XML-RPC supported set is for convenience, these are unprintable characters in any context. This is just a two-fer. Petr was right, I need to encode to unicode before doing this comparison in order to compare invalid unicode characters so I moved that first. I added a very basic unit test. If you're wondering where this data might come from, two ways are via AD sync and migration. Yes, the user will be left in a situation where they'll need to use --setattr or ldapmodify to manage the data in the field. The UI doesn't show the value at all but instead shows [object Object] (no errors in console, not sure where this is coming from). It is possible to highlight this and insert a new value though. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-971-3-binary.patch Type: text/x-patch Size: 3998 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 29 08:36:31 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 29 Mar 2012 10:36:31 +0200 Subject: [Freeipa-devel] [PATCH] 993 disable UPG for migration In-Reply-To: <4F738281.3080505@redhat.com> References: <4F6B7B9F.4080105@redhat.com> <1332493947.17059.24.camel@balmora.brq.redhat.com> <4F738281.3080505@redhat.com> Message-ID: <1333010191.20236.16.camel@balmora.brq.redhat.com> On Wed, 2012-03-28 at 17:28 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Thu, 2012-03-22 at 15:21 -0400, Rob Crittenden wrote: > >> We don't want to create private groups automatically for migrated users, > >> there could be namespace overlap (and race conditions prevent us from > >> trying to check in advance). > >> > >> Check the sanity of groups in general, warn if the group for the > >> gidnumber doesn't exist at least on the remote server. > >> > >> Fill in the user's shell as well. > >> > >> This will migrate users that are non-POSIX on the remote server. > >> > >> rob > > > > This patch fixes the problem of creating UPGs for migrated users, but > > there are several parts which confused me. > > > > 1) Confusing defaults > > > > + if 'def_group_gid' in ctx: > > + entry_attrs.setdefault('gidnumber', ctx['def_group_gid']) > > > > This statement seems redundant, because the account either is posix and > > has both uidnumber and gidnumber or it is non-posix and does not have > > any. > > > > Now, we don't touch gidNumber for posix user, and non-posix users are > > made posix with this statement: > > > > + # migrated user is not already POSIX, make it so > > + if 'uidnumber' not in entry_attrs: > > + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] > > > > > > 2) Missing UPG > > When UPG is disabled, the following statement will result in a user with > > a GID pointing to non-existent group. > > > > + # migrated user is not already POSIX, make it so > > + if 'uidnumber' not in entry_attrs: > > + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] > > > > We may want to run ldap.has_upg() and report a add this user to "failed > > users" with appropriate error. > > > > 3) Check for GID > > The patch implements a check if a group with the gidNumber exists on a > > remote LDAP server and the result is a warning: > > > > - (g_dn, g_attrs) = ldap.get_entry(ctx['def_group_dn'], ['gidnumber']) > > + (remote_dn, remote_entry) = ds_ldap.find_entry_by_attr( > > + 'gidnumber', entry_attrs['gidnumber'][0], 'posixgroup', [''], > > + search_bases['group'] > > + ) > > > > I have few (minor-ish) questions there: > > a) Is the warning in a apache log enough? Maybe it should be included in > > migrate-ds output. > > b) This will be a one more remote LDAP call for every user, we may want > > to optimize it with something like that: > > > > valid_gids = [] > > if user.gidnumber not in valid_gids: > > run the check in remote LDAP > > valid_gids.append(user.gidnumber) > > > > That would save us 999 LDAP queries for 1000 migrated with the same > > primary group. > > > > 4) Extraneous Warning: > > When non-posix user is migrated and thus we make it a posix user, we > > still produce a warning for non-existent group: > > > > [Fri Mar 23 04:21:36 2012] [error] ipa: WARNING: Migrated user's GID > > number 999 does not point to a known group. > > > > 5) Extraneous LDAP call > > > > Isn't the following call to LDAP to get a description redundant? We > > already have the description in entry_attrs. > > > > + (dn, desc_attr) = ldap.get_entry(dn, ['description']) > > + entry_attrs.update(desc_attr) > > + if 'description' in entry_attrs and NO_UPG_MAGIC in > > entry_attrs['description']: > > > > > > Martin > > > > I think this covers your concerns. > > I can't do anything but log warnings at this point in order to maintain > backwards compatibility. I looked into returning a warning entry and it > blew up in validate_output() on older clients. > > rob > This patch is much better and covers my previous concerns. I just find an issue with UPG. It is not created for non-posix users when UPGs are enabled: # echo "Secret123" | ipa migrate-ds ldap://ldap.example.com --with-compat --base-dn="dc=greyoak,dc=com" ----------- migrate-ds: ----------- Migrated: user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg group: ipagroup Failed user: Failed group: ---------- Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. # ipa user-show mnonposix User login: mnonposix First name: Mister Last name: Nonposix Home directory: /home/mnonposix Login shell: /bin/sh UID: 328000195 GID: 328000195 Org. Unit: Product Testing Job Title: Test User Account disabled: False Password: True Member of groups: ipausers Kerberos keys available: False # ipa group-show mnonposix ipa: ERROR: mnonposix: group not found I am also thinking if we need to ask if UPG is enabled for every migrated user - every ldap.has_upg() call means one query to host LDAP. Maybe we should ask just in the beginning and store the setting in "ctx['upg_enabled']. I don't think that anyone needs to switch UPG status during migration process. Martin From pviktori at redhat.com Thu Mar 29 09:20:40 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 29 Mar 2012 11:20:40 +0200 Subject: [Freeipa-devel] [PATCH] 971 detect binary LDAP data In-Reply-To: <4F738EB4.8030802@redhat.com> References: <4F4B96DE.60805@redhat.com> <1330357665.2718.11.camel@willson.li.ssimo.org> <4F4BA7FD.5040209@redhat.com> <4F4BAB11.3070608@redhat.com> <4F4BB316.3020500@redhat.com> <4F4C43B7.4030601@redhat.com> <4F4C91B8.4040102@redhat.com> <4F4CF689.5030808@redhat.com> <4F4D0889.1090105@redhat.com> <4F4D14FD.70402@redhat.com> <4F4D15E2.6000101@redhat.com> <4F4DEC91.603@redhat.com> <4F4E39EF.5080607@redhat.com> <4F4F8C28.6050607@redhat.com> <4F738EB4.8030802@redhat.com> Message-ID: <4F742968.9090704@redhat.com> On 03/29/2012 12:20 AM, Rob Crittenden wrote: > > I'm using a much narrower scope. I'm not trying to make it easy to > manage non-printable characters, just not blow things up if they exist. > Limiting to the XML-RPC supported set is for convenience, these are > unprintable characters in any context. This is just a two-fer. Right. The XML set is a nice compromise when you want to define ?unprintable characters?. > Petr was right, I need to encode to unicode before doing this comparison > in order to compare invalid unicode characters so I moved that first. > > I added a very basic unit test. I suggest the attached additions to the test, to ensure the encoder uses contains_non_printable as it should. (PEP8 nitpicks included) > If you're wondering where this data might come from, two ways are via AD > sync and migration. > > Yes, the user will be left in a situation where they'll need to use > --setattr or ldapmodify to manage the data in the field. The UI doesn't > show the value at all but instead shows [object Object] (no errors in > console, not sure where this is coming from). It is possible to > highlight this and insert a new value though. So basically, we don't allow non-printable characters in text fields. When they're already there, we display weird data but don't blow up. I believe that's fine, as long as it's documented. --setattr won't work: the data won't make it through XML-RPC. (I get Internal Server Error currently) > rob -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: extra-tests.diff Type: text/x-patch Size: 848 bytes Desc: not available URL: From jcholast at redhat.com Thu Mar 29 12:07:52 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 29 Mar 2012 14:07:52 +0200 Subject: [Freeipa-devel] [PATCH] 971 detect binary LDAP data In-Reply-To: <4F738EB4.8030802@redhat.com> References: <4F4B96DE.60805@redhat.com> <1330357665.2718.11.camel@willson.li.ssimo.org> <4F4BA7FD.5040209@redhat.com> <4F4BAB11.3070608@redhat.com> <4F4BB316.3020500@redhat.com> <4F4C43B7.4030601@redhat.com> <4F4C91B8.4040102@redhat.com> <4F4CF689.5030808@redhat.com> <4F4D0889.1090105@redhat.com> <4F4D14FD.70402@redhat.com> <4F4D15E2.6000101@redhat.com> <4F4DEC91.603@redhat.com> <4F4E39EF.5080607@redhat.com> <4F4F8C28.6050607@redhat.com> <4F738EB4.8030802@redhat.com> Message-ID: <4F745098.709@redhat.com> On 29.3.2012 00:20, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 29.2.2012 15:45, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 28.2.2012 18:58, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> On 28.2.2012 18:02, Petr Viktorin wrote: >>>>>>> On 02/28/2012 04:45 PM, Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>>>> On 02/28/2012 04:02 AM, Rob Crittenden wrote: >>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>> On 02/27/2012 05:10 PM, Rob Crittenden wrote: >>>>>>>>>>>> Rob Crittenden wrote: >>>>>>>>>>>>> Simo Sorce wrote: >>>>>>>>>>>>>> On Mon, 2012-02-27 at 09:44 -0500, Rob Crittenden wrote: >>>>>>>>>>>>>>> We are pretty trusting that the data coming out of LDAP >>>>>>>>>>>>>>> matches >>>>>>>>>>>>>>> its >>>>>>>>>>>>>>> schema but it is possible to stuff non-printable characters >>>>>>>>>>>>>>> into >>>>>>>>>>>>>>> most >>>>>>>>>>>>>>> attributes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've added a sanity checker to keep a value as a python str >>>>>>>>>>>>>>> type >>>>>>>>>>>>>>> (treated as binary internally). This will result in a base64 >>>>>>>>>>>>>>> encoded >>>>>>>>>>>>>>> blob be returned to the client. >>>>>> >>>>>> I don't like the idea of having arbitrary binary data where unicode >>>>>> strings are expected. It might cause some unexpected errors (I have a >>>>>> feeling that --addattr and/or --delattr and possibly some plugins >>>>>> might >>>>>> not handle this very well). Wouldn't it be better to just throw away >>>>>> the >>>>>> value if it's invalid and warn the user? >>>>> >>>>> This isn't for user input, it is for data stored in LDAP. User's are >>>>> going to have no way to provide binary data to us unless they use the >>>>> API themselves in which case they have to follow our rules. >>>> >>>> Well my point was that --addattr and --delattr cause an LDAP search for >>>> the given attribute and plugins might get the result of a LDAP >>>> search in >>>> their post_callback and I'm not sure if they can cope with binary data. >>> >>> It wouldn't be any different than if we had the value as a unicode. >> >> Let's see what happens if the mail attribute of a user contains invalid >> UTF-8 (ff 62 30 72 6b 65 64): >> >> $ ipa user-find jdoe >> -------------- >> 1 user matched >> -------------- >> User login: jdoe >> First name: John >> Last name: Doe >> Home directory: /home/jdoe >> Login shell: /bin/sh >> Email address: /2IwcmtlZA== >> UID: 526 >> GID: 526 >> Account disabled: False >> Password: False >> Kerberos keys available: False >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> $ ipa user-mod jdoe --addattr mail=jdoe at example.com >> ipa: ERROR: an internal error has occurred >> >> The internal error is: >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line >> 302, in wsgi_execute >> result = self.Command[name](*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in >> __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in >> run >> return self.execute(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line >> 1217, in execute >> ldap, dn, entry_attrs, attrs_list, *keys, **options >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/user.py", line >> 532, in pre_callback >> entry_attrs['mail'] = self.obj._normalize_email(entry_attrs['mail']) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/user.py", line >> 338, in _normalize_email >> norm_email.append(m + u'@' + config['ipadefaultemaildomain'][0]) >> UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 0: >> invalid start byte >> >> $ ipa user-mod jdoe --delattr mail=/2IwcmtlZA== >> ipa: ERROR: mail does not contain '/2IwcmtlZA==' >> >> $ ipa user-mod jdoe --delattr mail=`echo 'ff 62 30 72 6b 65 64' | xxd -p >> -r` >> ipa: ERROR: UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in >> position 5: invalid start byte >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1242, in run >> sys.exit(api.Backend.cli.run(argv)) >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1024, in run >> kw = self.parse(cmd, argv) >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1049, in >> parse >> return dict(self.parse_iter(cmd, kw)) >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1058, in >> parse_iter >> yield (key, self.Backend.textui.decode(value)) >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 136, in >> decode >> return value.decode(encoding) >> File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode >> return codecs.utf_8_decode(input, errors, True) >> UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 5: >> invalid start byte >> ipa: ERROR: an internal error has occurred >> >> I'm sure there is a lot more places in the code where things will break >> when you feed them arbitrary data. >> >>> >>> We treat the python type str as binary data. Anything that is a str gets >>> based64 encoded before json or xml-rpc transmission. >>> >>> The type unicode is considered a "string" and goes in the clear. >>> >>> We determine what this type should be not from the data but from the >>> schema. This is a big assumption. Hopefully this answer's Petr's point >>> as well. >>> >>> We decided long ago that str means Binary and unicode means String. It >>> is a bit clumsy perhaps python handles it well. It will be more clear >>> when we switch to Python 3.0 and we'll have bytes and str instead as >>> types. >> >> Well, this is all super-obvious and I'm not really sure why do you bring >> it up here... >> >> My concern is that with your approach, you can no longer be sure that an >> attribute value is a valid unicode string. This creates a >> maintainability burden, as you *always* have to keep in mind that you >> first have to check whether the value is valid or not before touching >> it. You can easily forget to include the check in new code and there is >> a lot of places in old code that need to be changed because of this (as >> you can see in the mail example above). >> >> Let me quote John Dennis >> (): >> >> >>> I'm very interested in this work. I too have recognized that we have a >>> very real structural problem with how we handle the types we use >>> internally, especially when it corresponds to an external type and >>> requires conversion. In fact we do a remarkably bad job in this area, we >>> have conversions which are done ad hoc all over the place. There is no >>> well established place for the conversions to occur and it's difficult >>> to know at any point in the code what type to expect. >> >> Your patch adds yet another occurence of "it's difficult to know at any >> point in the code what type to expect". IMO this is very bad and we >> should not do this at all in new code. >> >> I'm not sure if just dropping bad values (as I have suggested before) is >> the best idea, but IMHO anything is better than letting these bad values >> into the bowels of IPA. >> >>> >>>>> We are trusting that the data in LDAP matches its schema. This is just >>>>> belt and suspenders verifying that it is the case. >>>> >>>> Sure, but I still think we should allow any valid unicode data to come >>>> from LDAP, not just what is valid in XML-RPC. >>> >>> This won't affect data coming out of LDAP, only the way it is >>> transmitted to the client. >> >> It will affect the data flowing through IPA, after we get it from LDAP, >> before it is transmitted through XML-RPC. >> >> In other words, I think it is more correct to do this: >> >> LDAP -> check unicode validity -> (rest of IPA) -> check XML-RPC >> validitity -> XML-RPC >> >> than this: >> >> LDAP -> check unicode validity -> check XML-RPC validity -> (rest of >> IPA) -> XML-RPC >> >> (Let's keep things isolated please.) >> >>> >>> rob >> >> Honza >> > > I'm using a much narrower scope. I'm not trying to make it easy to > manage non-printable characters, just not blow things up if they exist. > Limiting to the XML-RPC supported set is for convenience, these are > unprintable characters in any context. This is just a two-fer. The fact the characters are non-printable doesn't really mean anything until they are actually printed. Characters U+007F to U+009F are non-printable as well, yet you treat them as printable in the patch. What makes them so special? > > Petr was right, I need to encode to unicode before doing this comparison > in order to compare invalid unicode characters so I moved that first. > > I added a very basic unit test. > > If you're wondering where this data might come from, two ways are via AD > sync and migration. Slightly unrelated, but is it possible that strings in different encoding than UTF-8 might come from there? > > Yes, the user will be left in a situation where they'll need to use > --setattr or ldapmodify to manage the data in the field. The UI doesn't > show the value at all but instead shows [object Object] (no errors in > console, not sure where this is coming from). It is possible to > highlight this and insert a new value though. > > rob Again, things will break if you let arbitrary binary strings in IPA. Consider this: >>> u'unicode' + '\xffgarbage' Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128) When you do an operation on unicode and str operands, the str operand is first UTF-8 decoded. This will fail if the str operand doesn't contain valid UTF-8, as you can see in the example. There are many places in the code where such operations take place and so far we assumed they won't fail, because there was no way invalid UTF-8 strings could reach them. Your patch changes that, so you have to fix this problem and make sure new code doesn't suffer from it as well. This might turn out to be hard, hence my reluctance to your approach. I might be repeating myself, but IMO printing a warning to the user that a bad value was encountered and ignoring the value in the rest of the framework should work for everyone. By that I mean something like this: $ ipa user-find jdoe ipa: WARNING: invalid 'email' value encountered: 'ff6230726b6564' -------------- 1 user matched -------------- User login: jdoe First name: John Last name: Doe Home directory: /home/jdoe Login shell: /bin/sh UID: 526 GID: 526 Account disabled: False Password: False Kerberos keys available: False ---------------------------- Number of entries returned 1 ---------------------------- Honza -- Jan Cholasta From pvoborni at redhat.com Thu Mar 29 12:24:33 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 29 Mar 2012 14:24:33 +0200 Subject: [Freeipa-devel] [PATCHES] 113-114 Facet expiration flag In-Reply-To: <4F71DE98.2050402@redhat.com> References: <4F6B6660.1020104@redhat.com> <4F71DE98.2050402@redhat.com> Message-ID: <4F745481.9050102@redhat.com> On 03/27/2012 05:36 PM, Endi Sukma Dewata wrote: > On 3/22/2012 12:50 PM, Petr Vobornik wrote: >> The effort was split to two patches. See patch descriptions. > > ACK on both. Nice job. See comments below. Pushed to master, ipa-2-2. See comment below. > >> Notes: >> Case #7 (automatic: an open facet should automatically refresh itself >> when it expires) I don't want to implement because I think it can cause >> havoc ie: refresh when user is editing. > > For details page, automatically refreshing the page still makes sense to > avoid overriding newer data with older information. For example you open > a user details page to add an email address, but at the same time > somebody else added another email address to same user. When you finally > save your changes the other email address will be gone. > > I think there are several options: > 1. Don't refresh if the page is dirty (i.e. user is editing the page). > 2. Refresh unedited fields only. > 3. Load the data even though it's being edited, compare with the cached > data. If something's changed alert the user. The user can either revert > the changes or continue editing. > 4. Use addattr/delattr to modify multi-valued attributes. > > The chance of this happening is probably small, and the solution won't > completely eliminate the risk either, so this is probably lower priority. > > For search page, there are 2 things that the page keeps in cache: the > primary keys and the visible entry details. Currently when you change > page it will refresh both, so periodically refreshing the page may not > be that important. However ideally we shouldn't need to refresh the > primary keys in all page changes because it could be long and most > likely unchanged. In this case it makes sense to refresh the primary > keys periodically. Probably separate ticket. I think options #1 and #2 doesn't solve the problem when user edits something for a very long time (went for a lunch...). #3 seems as a best solution because it covers single valued attrs too, compare to #4. Which is nice, because user can see what other user entered and may find it better :). Ideal would be to check if data changed before each update, but I think it isn't worth the effort. I closed the original ticket and moved this to separate ticket. I used your comment as a description. https://fedorahosted.org/freeipa/ticket/2591 > >> Also I was thinking about splitting needs_update to two methods: >> needs_update and state_changed. State changed would compare current >> state with old state. It would be called from needs_update. This way we >> don't have to override needs_update and just define various >> state_changed for different facets. > > Feel free to refactor the methods if you think it's necessary. But > before that try to rearrange the current implementations of > needs_update() and minimize the amount of code that needs to be moved > into state_changed(). > >> Also I'm thinking about adding >> paging state comparison to search facet (the page should recognize the >> change itself ie when other facet redirects to certain page (bad >> example?)). What do you think? > > Yes, this would be needed if we decided to keep the primary keys for a > longer time like described above. Changing the page should refresh the > visible entry details only. > -- Petr Vobornik From pvoborni at redhat.com Thu Mar 29 12:46:13 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 29 Mar 2012 14:46:13 +0200 Subject: [Freeipa-devel] [PATCH] 115 Reworked netgroup Web UI to allow setting user/host category Message-ID: <4F745995.2060704@redhat.com> This patch is changing netgroup web ui to look more like hbac or sudo rule UI. This change allows to define and display user category, host category and external host. The core of the change is changing member attributes (user, group, host, hostgroup) to use rule_details_widget instead of separate association facets. In host case it also allows to display and add external hosts. https://fedorahosted.org/freeipa/ticket/2578 Note: compare to other plugins (HBAC, Sudo) netgroup plugins doesn't have member attrs in takes_param therefore labels for columns have to be explicitly set. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0115-Reworked-netgroup-Web-UI-to-allow-setting-user-host-.patch Type: text/x-patch Size: 13473 bytes Desc: not available URL: From abokovoy at redhat.com Thu Mar 29 13:30:35 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 29 Mar 2012 16:30:35 +0300 Subject: [Freeipa-devel] [PATCH] (master) Support case-insensitive searches for principals during TGS request processing Message-ID: <20120329133035.GH3500@redhat.com> Hi, Attached patch implements solution for https://fedorahosted.org/freeipa/ticket/1577. With the patch applied to master, FreeIPA will be more forgiving for service principals requested with wrong character case. This is something supported by Active Directory where principals for services are case-insensitive and therefore HTTP/ or http/ point to the same service. In Kerberos LDAP schema, unfortunately, both krbPrincipalName and krbCanonicalName attributes are defined with exact match strategy, therefore, making impossible case-insensitive filtering. The patch solves this problem by introducing an attribute with case-insensitive matching strategy. Since there are several ways to create principals, we hook up at both FreeIPA management framework and KDC database plugin levels to intercept and maintain principal changes. We have decided only support case-insensitive searches for services where this is important and required feature. Services always have krbPrincipalName defined, and ipaKrbPrincipal object class will now be applied in addition to existing ones, to provide ipaKrbPrincipalAlias attribute (which is case-insensitive). Users will not get case-insensitive searches by default, though it is possible to introduce such feature to them as well by adding ipaKrbPrincipal class to the user and taking care of creating/maintaining the alias attribute synchronized with krbPrincipalName. Simo was originally against making case-insensitive aliases for users, though. Here is how it will look and act for services: ------------------------------------------------------------------ [root at m17 ~]# kvno cifs/M17.ipa.Local at IPA.LOCAL cifs/M17.ipa.Local at IPA.LOCAL: kvno = 1 [root at m17 ~]# kvno CIFS/M17.ipa.Local at IPA.LOCAL CIFS/M17.ipa.Local at IPA.LOCAL: kvno = 1 [root at m17 ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at IPA.LOCAL Valid starting Expires Service principal 03/29/12 14:38:57 03/30/12 14:38:55 krbtgt/IPA.LOCAL at IPA.LOCAL 03/29/12 14:39:05 03/30/12 14:38:55 HTTP/m17.ipa.local at IPA.LOCAL 03/29/12 15:00:51 03/30/12 14:38:55 ldap/m17.ipa.local at IPA.LOCAL 03/29/12 15:08:02 03/30/12 14:38:55 krbtgt/IPA.LocAl at IPA.LOCAL 03/29/12 15:08:19 03/30/12 14:38:55 cifs/M17.ipa.Local at IPA.LOCAL 03/29/12 15:08:48 03/30/12 14:38:55 CIFS/M17.ipa.Local at IPA.LOCAL ------------------------------------------------------------------ Please note that case-insensitive realm search is still not supported, even if you enable DNS resolution of realms and KDCs: [root at m17 ~]# kvno cIfS/m17.ipa.local at ipa.LoCaL kvno: Cannot find KDC for requested realm while getting credentials for cIfS/m17.ipa.local at ipa.LoCaL This is due to some krbtgt/realm at REALM searches performed in KDC without allowing for principal aliases and therefore no chance to our case-insensitive searches to kick in. Additional discussion is needed, I think, if we want to support case-insensitive realms. -- / Alexander Bokovoy -------------- next part -------------- >From 7d0c8669df0da44c9056581bd29af3f0abec58d4 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 26 Mar 2012 14:23:42 +0300 Subject: [PATCH 6/9] Perform case-insensitive searches for principals on TGS requests We want to always resolve TGS requests even if the user mistakenly sends a request for a service ticket where the fqdn part contain upper case letters. The actual implementation follows hints set by KDC. When AP_REQ is done, KDC sets KRB5_FLAG_ALIAS_OK and we obey it when looking for principals on TGS requests. https://fedorahosted.org/freeipa/ticket/1577 --- daemons/ipa-kdb/ipa_kdb_principals.c | 73 ++++++++++++++++++++++++---------- install/share/61kerberos-ipav3.ldif | 3 ++ install/share/Makefile.am | 1 + install/updates/10-60basev3.update | 2 + ipalib/plugins/service.py | 7 +++- ipaserver/install/dsinstance.py | 1 + 6 files changed, 65 insertions(+), 22 deletions(-) create mode 100644 install/share/61kerberos-ipav3.ldif diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index 1432619..2e190a1 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -22,6 +22,16 @@ #include "ipa_kdb.h" +/* + * During TGS request search by ipaKrbPrincipalName (case-insensitive) + * and krbPrincipalName (case-sensitive) + */ +#define PRINC_TGS_SEARCH_FILTER "(&(|(objectclass=krbprincipalaux)" \ + "(objectclass=krbprincipal)" \ + "(objectclass=ipakrbprincipal))" \ + "(|(ipakrbprincipalalias=%s)" \ + "(krbprincipalname=%s)))" + #define PRINC_SEARCH_FILTER "(&(|(objectclass=krbprincipalaux)" \ "(objectclass=krbprincipal))" \ "(krbprincipalname=%s))" @@ -29,6 +39,7 @@ static char *std_principal_attrs[] = { "krbPrincipalName", "krbCanonicalName", + "ipaKrbPrincipalAlias", "krbUPEnabled", "krbPrincipalKey", "krbTicketPolicyReference", @@ -73,6 +84,7 @@ static char *std_principal_obj_classes[] = { "krbprincipal", "krbprincipalaux", "krbTicketPolicyAux", + "ipakrbprincipal", NULL }; @@ -636,13 +648,14 @@ done: } static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx, - char *search_expr, + unsigned int flags, + char *principal, LDAPMessage **result) { krb5_error_code kerr; char *src_filter = NULL; - char *esc_search_expr = NULL; - int ret; + char *esc_original_princ = NULL; + int ret, i; if (!ipactx->lcontext) { ret = ipadb_get_connection(ipactx); @@ -654,13 +667,19 @@ static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx, /* escape filter but do not touch '*' as this function accepts * wildcards in names */ - esc_search_expr = ipadb_filter_escape(search_expr, false); - if (!esc_search_expr) { + esc_original_princ = ipadb_filter_escape(principal, false); + if (!esc_original_princ) { kerr = KRB5_KDB_INTERNAL_ERROR; goto done; } - ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_search_expr); + if (flags & KRB5_KDB_FLAG_ALIAS_OK) { + ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER, + esc_original_princ, esc_original_princ); + } else { + ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_original_princ); + } + if (ret == -1) { kerr = KRB5_KDB_INTERNAL_ERROR; goto done; @@ -673,7 +692,7 @@ static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx, done: free(src_filter); - free(esc_search_expr); + free(esc_original_princ); return kerr; } @@ -713,9 +732,12 @@ static krb5_error_code ipadb_find_principal(krb5_context kcontext, /* we need to check for a strict match as a '*' in the name may have * caused the ldap server to return multiple entries */ for (i = 0; vals[i]; i++) { - /* FIXME: use case insensitive compare and tree as alias ?? */ - if (strcmp(vals[i]->bv_val, (*principal)) == 0) { - found = true; + /* KDC will accept aliases when doing TGT lookup (ref_tgt_again in do_tgs_req.c */ + /* Use case-insensitive comparison in such cases */ + if ((flags & KRB5_KDB_FLAG_ALIAS_OK) != 0) { + found = (strcasecmp(vals[i]->bv_val, (*principal)) == 0); + } else { + found = (strcmp(vals[i]->bv_val, (*principal)) == 0); } } @@ -731,11 +753,15 @@ static krb5_error_code ipadb_find_principal(krb5_context kcontext, continue; } - /* FIXME: use case insensitive compare and treat as alias ?? */ - if (strcmp(vals[0]->bv_val, (*principal)) != 0 && - !(flags & KRB5_KDB_FLAG_ALIAS_OK)) { + /* Again, if aliases are accepted by KDC, use case-insensitive comparison */ + if ((flags & KRB5_KDB_FLAG_ALIAS_OK) != 0) { + found = (strcasecmp(vals[0]->bv_val, (*principal)) == 0); + } else { + found = (strcmp(vals[0]->bv_val, (*principal)) == 0); + } + + if (!found) { /* search does not allow aliases */ - found = false; ldap_value_free_len(vals); continue; } @@ -883,7 +909,7 @@ krb5_error_code ipadb_get_principal(krb5_context kcontext, goto done; } - kerr = ipadb_fetch_principals(ipactx, principal, &res); + kerr = ipadb_fetch_principals(ipactx, flags, principal, &res); if (kerr != 0) { goto done; } @@ -1398,6 +1424,11 @@ static krb5_error_code ipadb_entry_to_mods(krb5_context kcontext, if (kerr) { goto done; } + kerr = ipadb_get_ldap_mod_str(imods, "ipaKrbPrincipalAlias", + principal, mod_op); + if (kerr) { + goto done; + } } /* KADM5_PRINC_EXPIRE_TIME */ @@ -1735,13 +1766,13 @@ static krb5_error_code ipadb_add_principal(krb5_context kcontext, goto done; } - kerr = ipadb_entry_to_mods(kcontext, imods, - entry, principal, LDAP_MOD_ADD); + kerr = ipadb_entry_default_attrs(imods); if (kerr != 0) { goto done; } - kerr = ipadb_entry_default_attrs(imods); + kerr = ipadb_entry_to_mods(kcontext, imods, + entry, principal, LDAP_MOD_ADD); if (kerr != 0) { goto done; } @@ -1779,7 +1810,7 @@ static krb5_error_code ipadb_modify_principal(krb5_context kcontext, goto done; } - kerr = ipadb_fetch_principals(ipactx, principal, &res); + kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); if (kerr != 0) { goto done; } @@ -1930,7 +1961,7 @@ krb5_error_code ipadb_delete_principal(krb5_context kcontext, goto done; } - kerr = ipadb_fetch_principals(ipactx, principal, &res); + kerr = ipadb_fetch_principals(ipactx, 0, principal, &res); if (kerr != 0) { goto done; } @@ -1982,7 +2013,7 @@ krb5_error_code ipadb_iterate(krb5_context kcontext, } /* fetch list of principal matching filter */ - kerr = ipadb_fetch_principals(ipactx, match_entry, &res); + kerr = ipadb_fetch_principals(ipactx, 0, match_entry, &res); if (kerr != 0) { goto done; } diff --git a/install/share/61kerberos-ipav3.ldif b/install/share/61kerberos-ipav3.ldif new file mode 100644 index 0000000..dcdaa5d --- /dev/null +++ b/install/share/61kerberos-ipav3.ldif @@ -0,0 +1,3 @@ +dn: cn=schema +attributeTypes: (2.16.840.1.113730.3.8.11.32 NAME 'ipaKrbPrincipalAlias' DESC 'IPA principal alias' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3') +objectClasses: (2.16.840.1.113730.3.8.12.8 NAME 'ipaKrbPrincipal' SUP krbPrincipalAux AUXILIARY MUST ( krbPrincipalName $ ipaKrbPrincipalAlias ) X-ORIGIN 'IPA v3' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 81fd0dc..68c98e0 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -9,6 +9,7 @@ app_DATA = \ 60basev2.ldif \ 60basev3.ldif \ 60ipadns.ldif \ + 61kerberos-ipav3.ldif \ 65ipasudo.ldif \ anonymous-vlv.ldif \ bootstrap-template.ldif \ diff --git a/install/updates/10-60basev3.update b/install/updates/10-60basev3.update index 796eb16..96d012c 100644 --- a/install/updates/10-60basev3.update +++ b/install/updates/10-60basev3.update @@ -4,3 +4,5 @@ add:attributeTypes: ( 2.16.840.1.113730.3.8.11.21 NAME 'ipaAllowToImpersonate' D add:attributeTypes: ( 2.16.840.1.113730.3.8.11.22 NAME 'ipaAllowedTarget' DESC 'Target principals alowed to get a ticket for' SUP distinguishedName X-ORIGIN 'IPA-v3') add:objectClasses: (2.16.840.1.113730.3.8.12.6 NAME 'groupOfPrincipals' SUP top AUXILIARY MUST ( cn ) MAY ( memberPrincipal ) X-ORIGIN 'IPA v3' ) add:objectClasses: (2.16.840.1.113730.3.8.12.7 NAME 'ipaKrb5DelegationACL' SUP groupOfPrincipals STRUCTURAL MAY ( ipaAllowToImpersonate $$ ipaAllowedTarget ) X-ORIGIN 'IPA v3' ) +add:attributeTypes: (2.16.840.1.113730.3.8.11.32 NAME 'ipaKrbPrincipalAlias' DESC 'IPA principal alias' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3') +add:objectClasses: (2.16.840.1.113730.3.8.12.8 NAME 'ipaKrbPrincipal' SUP krbPrincipalAux AUXILIARY MUST ( krbPrincipalName $$ ipaKrbPrincipalAlias ) X-ORIGIN 'IPA v3' ) diff --git a/ipalib/plugins/service.py b/ipalib/plugins/service.py index 7c563b3..d2ddd4e 100644 --- a/ipalib/plugins/service.py +++ b/ipalib/plugins/service.py @@ -221,7 +221,7 @@ class service(LDAPObject): object_name_plural = _('services') object_class = [ 'krbprincipal', 'krbprincipalaux', 'krbticketpolicyaux', 'ipaobject', - 'ipaservice', 'pkiuser' + 'ipaservice', 'pkiuser', 'ipakrbprincipal' ] search_attributes = ['krbprincipalname', 'managedby'] default_attributes = ['krbprincipalname', 'usercertificate', 'managedby'] @@ -293,6 +293,11 @@ class service_add(LDAPCreate): if not 'managedby' in entry_attrs: entry_attrs['managedby'] = hostresult['dn'] + # Enforce ipaKrbPrincipalAlias to aid case-insensitive searches + # as krbPrincipalName/krbCanonicalName are case-sensitive in Kerberos + # schema + entry_attrs['ipakrbprincipalalias'] = keys[-1] + return dn api.register(service_add) diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index e549e13..5d40941 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -359,6 +359,7 @@ class DsInstance(service.Service): "60basev2.ldif", "60basev3.ldif", "60ipadns.ldif", + "61kerberos-ipav3.ldif", "65ipasudo.ldif"): target_fname = schema_dirname(self.serverid) + schema_fname shutil.copyfile(ipautil.SHARE_DIR + schema_fname, target_fname) -- 1.7.9.3 From ohamada at redhat.com Thu Mar 29 13:56:30 2012 From: ohamada at redhat.com (Ondrej Hamada) Date: Thu, 29 Mar 2012 15:56:30 +0200 Subject: [Freeipa-devel] [PATCH] 0030 Allow multi-line CSV parameters In-Reply-To: <4F6AE56F.1060203@redhat.com> References: <4F6AE56F.1060203@redhat.com> Message-ID: <4F746A0E.4000205@redhat.com> On 03/22/2012 09:40 AM, Petr Viktorin wrote: > Feed individual lines of input into the CSV parser, and include all > lines in the output. > > https://fedorahosted.org/freeipa/ticket/2402 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Mar 29 15:27:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Mar 2012 11:27:13 -0400 Subject: [Freeipa-devel] [PATCH] 993 disable UPG for migration In-Reply-To: <1333010191.20236.16.camel@balmora.brq.redhat.com> References: <4F6B7B9F.4080105@redhat.com> <1332493947.17059.24.camel@balmora.brq.redhat.com> <4F738281.3080505@redhat.com> <1333010191.20236.16.camel@balmora.brq.redhat.com> Message-ID: <4F747F51.7060009@redhat.com> Martin Kosek wrote: > On Wed, 2012-03-28 at 17:28 -0400, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Thu, 2012-03-22 at 15:21 -0400, Rob Crittenden wrote: >>>> We don't want to create private groups automatically for migrated users, >>>> there could be namespace overlap (and race conditions prevent us from >>>> trying to check in advance). >>>> >>>> Check the sanity of groups in general, warn if the group for the >>>> gidnumber doesn't exist at least on the remote server. >>>> >>>> Fill in the user's shell as well. >>>> >>>> This will migrate users that are non-POSIX on the remote server. >>>> >>>> rob >>> >>> This patch fixes the problem of creating UPGs for migrated users, but >>> there are several parts which confused me. >>> >>> 1) Confusing defaults >>> >>> + if 'def_group_gid' in ctx: >>> + entry_attrs.setdefault('gidnumber', ctx['def_group_gid']) >>> >>> This statement seems redundant, because the account either is posix and >>> has both uidnumber and gidnumber or it is non-posix and does not have >>> any. >>> >>> Now, we don't touch gidNumber for posix user, and non-posix users are >>> made posix with this statement: >>> >>> + # migrated user is not already POSIX, make it so >>> + if 'uidnumber' not in entry_attrs: >>> + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] >>> >>> >>> 2) Missing UPG >>> When UPG is disabled, the following statement will result in a user with >>> a GID pointing to non-existent group. >>> >>> + # migrated user is not already POSIX, make it so >>> + if 'uidnumber' not in entry_attrs: >>> + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] >>> >>> We may want to run ldap.has_upg() and report a add this user to "failed >>> users" with appropriate error. >>> >>> 3) Check for GID >>> The patch implements a check if a group with the gidNumber exists on a >>> remote LDAP server and the result is a warning: >>> >>> - (g_dn, g_attrs) = ldap.get_entry(ctx['def_group_dn'], ['gidnumber']) >>> + (remote_dn, remote_entry) = ds_ldap.find_entry_by_attr( >>> + 'gidnumber', entry_attrs['gidnumber'][0], 'posixgroup', [''], >>> + search_bases['group'] >>> + ) >>> >>> I have few (minor-ish) questions there: >>> a) Is the warning in a apache log enough? Maybe it should be included in >>> migrate-ds output. >>> b) This will be a one more remote LDAP call for every user, we may want >>> to optimize it with something like that: >>> >>> valid_gids = [] >>> if user.gidnumber not in valid_gids: >>> run the check in remote LDAP >>> valid_gids.append(user.gidnumber) >>> >>> That would save us 999 LDAP queries for 1000 migrated with the same >>> primary group. >>> >>> 4) Extraneous Warning: >>> When non-posix user is migrated and thus we make it a posix user, we >>> still produce a warning for non-existent group: >>> >>> [Fri Mar 23 04:21:36 2012] [error] ipa: WARNING: Migrated user's GID >>> number 999 does not point to a known group. >>> >>> 5) Extraneous LDAP call >>> >>> Isn't the following call to LDAP to get a description redundant? We >>> already have the description in entry_attrs. >>> >>> + (dn, desc_attr) = ldap.get_entry(dn, ['description']) >>> + entry_attrs.update(desc_attr) >>> + if 'description' in entry_attrs and NO_UPG_MAGIC in >>> entry_attrs['description']: >>> >>> >>> Martin >>> >> >> I think this covers your concerns. >> >> I can't do anything but log warnings at this point in order to maintain >> backwards compatibility. I looked into returning a warning entry and it >> blew up in validate_output() on older clients. >> >> rob >> > > This patch is much better and covers my previous concerns. I just find > an issue with UPG. It is not created for non-posix users when UPGs are > enabled: > > # echo "Secret123" | ipa migrate-ds ldap://ldap.example.com > --with-compat --base-dn="dc=greyoak,dc=com" > ----------- > migrate-ds: > ----------- > Migrated: > user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg > group: ipagroup > Failed user: > Failed group: > ---------- > Passwords have been migrated in pre-hashed format. > IPA is unable to generate Kerberos keys unless provided > with clear text passwords. All migrated users need to > login at https://your.domain/ipa/migration/ before they > can use their Kerberos accounts. > > # ipa user-show mnonposix > User login: mnonposix > First name: Mister > Last name: Nonposix > Home directory: /home/mnonposix > Login shell: /bin/sh > UID: 328000195 > GID: 328000195 > Org. Unit: Product Testing > Job Title: Test User > Account disabled: False > Password: True > Member of groups: ipausers > Kerberos keys available: False > > # ipa group-show mnonposix > ipa: ERROR: mnonposix: group not found Yes, I was always disabling UPG. I now allow it when migrating a non-POSIX user. > I am also thinking if we need to ask if UPG is enabled for every > migrated user - every ldap.has_upg() call means one query to host LDAP. > Maybe we should ask just in the beginning and store the setting in > "ctx['upg_enabled']. I don't think that anyone needs to switch UPG > status during migration process. I agree, nice optimization. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-993-3-migration.patch Type: text/x-patch Size: 10424 bytes Desc: not available URL: From pvoborni at redhat.com Thu Mar 29 15:43:32 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 29 Mar 2012 17:43:32 +0200 Subject: [Freeipa-devel] [PATCH] 971 detect binary LDAP data In-Reply-To: <4F738EB4.8030802@redhat.com> References: <4F4B96DE.60805@redhat.com> <1330357665.2718.11.camel@willson.li.ssimo.org> <4F4BA7FD.5040209@redhat.com> <4F4BAB11.3070608@redhat.com> <4F4BB316.3020500@redhat.com> <4F4C43B7.4030601@redhat.com> <4F4C91B8.4040102@redhat.com> <4F4CF689.5030808@redhat.com> <4F4D0889.1090105@redhat.com> <4F4D14FD.70402@redhat.com> <4F4D15E2.6000101@redhat.com> <4F4DEC91.603@redhat.com> <4F4E39EF.5080607@redhat.com> <4F4F8C28.6050607@redhat.com> <4F738EB4.8030802@redhat.com> Message-ID: <4F748324.9010407@redhat.com> On 03/29/2012 12:20 AM, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 29.2.2012 15:45, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 28.2.2012 18:58, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> On 28.2.2012 18:02, Petr Viktorin wrote: >>>>>>> On 02/28/2012 04:45 PM, Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>>>> On 02/28/2012 04:02 AM, Rob Crittenden wrote: >>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>> On 02/27/2012 05:10 PM, Rob Crittenden wrote: >>>>>>>>>>>> Rob Crittenden wrote: >>>>>>>>>>>>> Simo Sorce wrote: >>>>>>>>>>>>>> On Mon, 2012-02-27 at 09:44 -0500, Rob Crittenden wrote: >>>>>>>>>>>>>>> We are pretty trusting that the data coming out of LDAP >>>>>>>>>>>>>>> matches >>>>>>>>>>>>>>> its >>>>>>>>>>>>>>> schema but it is possible to stuff non-printable characters >>>>>>>>>>>>>>> into >>>>>>>>>>>>>>> most >>>>>>>>>>>>>>> attributes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've added a sanity checker to keep a value as a python str >>>>>>>>>>>>>>> type >>>>>>>>>>>>>>> (treated as binary internally). This will result in a base64 >>>>>>>>>>>>>>> encoded >>>>>>>>>>>>>>> blob be returned to the client. >>>>>> >>>>>> I don't like the idea of having arbitrary binary data where unicode >>>>>> strings are expected. It might cause some unexpected errors (I have a >>>>>> feeling that --addattr and/or --delattr and possibly some plugins >>>>>> might >>>>>> not handle this very well). Wouldn't it be better to just throw away >>>>>> the >>>>>> value if it's invalid and warn the user? >>>>> >>>>> This isn't for user input, it is for data stored in LDAP. User's are >>>>> going to have no way to provide binary data to us unless they use the >>>>> API themselves in which case they have to follow our rules. >>>> >>>> Well my point was that --addattr and --delattr cause an LDAP search for >>>> the given attribute and plugins might get the result of a LDAP >>>> search in >>>> their post_callback and I'm not sure if they can cope with binary data. >>> >>> It wouldn't be any different than if we had the value as a unicode. >> >> Let's see what happens if the mail attribute of a user contains invalid >> UTF-8 (ff 62 30 72 6b 65 64): >> >> $ ipa user-find jdoe >> -------------- >> 1 user matched >> -------------- >> User login: jdoe >> First name: John >> Last name: Doe >> Home directory: /home/jdoe >> Login shell: /bin/sh >> Email address: /2IwcmtlZA== >> UID: 526 >> GID: 526 >> Account disabled: False >> Password: False >> Kerberos keys available: False >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> $ ipa user-mod jdoe --addattr mail=jdoe at example.com >> ipa: ERROR: an internal error has occurred >> >> The internal error is: >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line >> 302, in wsgi_execute >> result = self.Command[name](*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 438, in >> __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 696, in >> run >> return self.execute(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line >> 1217, in execute >> ldap, dn, entry_attrs, attrs_list, *keys, **options >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/user.py", line >> 532, in pre_callback >> entry_attrs['mail'] = self.obj._normalize_email(entry_attrs['mail']) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/user.py", line >> 338, in _normalize_email >> norm_email.append(m + u'@' + config['ipadefaultemaildomain'][0]) >> UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 0: >> invalid start byte >> >> $ ipa user-mod jdoe --delattr mail=/2IwcmtlZA== >> ipa: ERROR: mail does not contain '/2IwcmtlZA==' >> >> $ ipa user-mod jdoe --delattr mail=`echo 'ff 62 30 72 6b 65 64' | xxd -p >> -r` >> ipa: ERROR: UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in >> position 5: invalid start byte >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1242, in run >> sys.exit(api.Backend.cli.run(argv)) >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1024, in run >> kw = self.parse(cmd, argv) >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1049, in >> parse >> return dict(self.parse_iter(cmd, kw)) >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1058, in >> parse_iter >> yield (key, self.Backend.textui.decode(value)) >> File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 136, in >> decode >> return value.decode(encoding) >> File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode >> return codecs.utf_8_decode(input, errors, True) >> UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 5: >> invalid start byte >> ipa: ERROR: an internal error has occurred >> >> I'm sure there is a lot more places in the code where things will break >> when you feed them arbitrary data. >> >>> >>> We treat the python type str as binary data. Anything that is a str gets >>> based64 encoded before json or xml-rpc transmission. >>> >>> The type unicode is considered a "string" and goes in the clear. >>> >>> We determine what this type should be not from the data but from the >>> schema. This is a big assumption. Hopefully this answer's Petr's point >>> as well. >>> >>> We decided long ago that str means Binary and unicode means String. It >>> is a bit clumsy perhaps python handles it well. It will be more clear >>> when we switch to Python 3.0 and we'll have bytes and str instead as >>> types. >> >> Well, this is all super-obvious and I'm not really sure why do you bring >> it up here... >> >> My concern is that with your approach, you can no longer be sure that an >> attribute value is a valid unicode string. This creates a >> maintainability burden, as you *always* have to keep in mind that you >> first have to check whether the value is valid or not before touching >> it. You can easily forget to include the check in new code and there is >> a lot of places in old code that need to be changed because of this (as >> you can see in the mail example above). >> >> Let me quote John Dennis >> (): >> >> >>> I'm very interested in this work. I too have recognized that we have a >>> very real structural problem with how we handle the types we use >>> internally, especially when it corresponds to an external type and >>> requires conversion. In fact we do a remarkably bad job in this area, we >>> have conversions which are done ad hoc all over the place. There is no >>> well established place for the conversions to occur and it's difficult >>> to know at any point in the code what type to expect. >> >> Your patch adds yet another occurence of "it's difficult to know at any >> point in the code what type to expect". IMO this is very bad and we >> should not do this at all in new code. >> >> I'm not sure if just dropping bad values (as I have suggested before) is >> the best idea, but IMHO anything is better than letting these bad values >> into the bowels of IPA. >> >>> >>>>> We are trusting that the data in LDAP matches its schema. This is just >>>>> belt and suspenders verifying that it is the case. >>>> >>>> Sure, but I still think we should allow any valid unicode data to come >>>> from LDAP, not just what is valid in XML-RPC. >>> >>> This won't affect data coming out of LDAP, only the way it is >>> transmitted to the client. >> >> It will affect the data flowing through IPA, after we get it from LDAP, >> before it is transmitted through XML-RPC. >> >> In other words, I think it is more correct to do this: >> >> LDAP -> check unicode validity -> (rest of IPA) -> check XML-RPC >> validitity -> XML-RPC >> >> than this: >> >> LDAP -> check unicode validity -> check XML-RPC validity -> (rest of >> IPA) -> XML-RPC >> >> (Let's keep things isolated please.) >> >>> >>> rob >> >> Honza >> > > I'm using a much narrower scope. I'm not trying to make it easy to > manage non-printable characters, just not blow things up if they exist. > Limiting to the XML-RPC supported set is for convenience, these are > unprintable characters in any context. This is just a two-fer. > > Petr was right, I need to encode to unicode before doing this comparison > in order to compare invalid unicode characters so I moved that first. > > I added a very basic unit test. > > If you're wondering where this data might come from, two ways are via AD > sync and migration. > > Yes, the user will be left in a situation where they'll need to use > --setattr or ldapmodify to manage the data in the field. The UI doesn't > show the value at all but instead shows [object Object] (no errors in > console, not sure where this is coming from). It is possible to > highlight this and insert a new value though. "[object Object]" is an output of standard object's toString() method. so when the data are binary they are converted to base64 and JSON looks like this: var foo = { "__base64__": "FOOBAR" } foo.toString() //you get "[object Object]" UI in most cases expects that it will receive simple value (string, number, boolean) or array of simple values or nothing, not an object with base64 string in it. So I should probably file an UI ticket to handle such cases, right? > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Petr Vobornik From simo at redhat.com Thu Mar 29 19:04:42 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 Mar 2012 15:04:42 -0400 Subject: [Freeipa-devel] [PATCH] 993 disable UPG for migration In-Reply-To: <4F747F51.7060009@redhat.com> References: <4F6B7B9F.4080105@redhat.com> <1332493947.17059.24.camel@balmora.brq.redhat.com> <4F738281.3080505@redhat.com> <1333010191.20236.16.camel@balmora.brq.redhat.com> <4F747F51.7060009@redhat.com> Message-ID: <1333047882.22628.160.camel@willson.li.ssimo.org> On Thu, 2012-03-29 at 11:27 -0400, Rob Crittenden wrote: > > This patch is much better and covers my previous concerns. I just > find > > an issue with UPG. It is not created for non-posix users when UPGs > are > > enabled: > > > > # echo "Secret123" | ipa migrate-ds ldap://ldap.example.com > > --with-compat --base-dn="dc=greyoak,dc=com" > > ----------- > > migrate-ds: > > ----------- > > Migrated: > > user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg > > group: ipagroup > > Failed user: > > Failed group: > > ---------- > > Passwords have been migrated in pre-hashed format. > > IPA is unable to generate Kerberos keys unless provided > > with clear text passwords. All migrated users need to > > login at https://your.domain/ipa/migration/ before they > > can use their Kerberos accounts. > > > > # ipa user-show mnonposix > > User login: mnonposix > > First name: Mister > > Last name: Nonposix > > Home directory: /home/mnonposix > > Login shell: /bin/sh > > UID: 328000195 > > GID: 328000195 > > Org. Unit: Product Testing > > Job Title: Test User > > Account disabled: False > > Password: True > > Member of groups: ipausers > > Kerberos keys available: False > > > > # ipa group-show mnonposix > > ipa: ERROR: mnonposix: group not found > > Yes, I was always disabling UPG. I now allow it when migrating a > non-POSIX user. by this you mean you are now transforming a non-POSIX user into a POSIX user ? What happen if someone has both POSIX and non-POSIX users on a server, do you mix them ? I have the feeling we need an explicit flag to convert a non-POSIX user -> POSIX user, because that doesn't look to me like something people want to do by default. Simo. > -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Mar 29 19:11:00 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Mar 2012 15:11:00 -0400 Subject: [Freeipa-devel] [PATCH] 0030 Allow multi-line CSV parameters In-Reply-To: <4F746A0E.4000205@redhat.com> References: <4F6AE56F.1060203@redhat.com> <4F746A0E.4000205@redhat.com> Message-ID: <4F74B3C4.9010507@redhat.com> Ondrej Hamada wrote: > On 03/22/2012 09:40 AM, Petr Viktorin wrote: >> Feed individual lines of input into the CSV parser, and include all >> lines in the output. >> >> https://fedorahosted.org/freeipa/ticket/2402 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK pushed to master and ipa-2-2 From rcritten at redhat.com Thu Mar 29 19:25:49 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Mar 2012 15:25:49 -0400 Subject: [Freeipa-devel] [PATCH] 993 disable UPG for migration In-Reply-To: <1333047882.22628.160.camel@willson.li.ssimo.org> References: <4F6B7B9F.4080105@redhat.com> <1332493947.17059.24.camel@balmora.brq.redhat.com> <4F738281.3080505@redhat.com> <1333010191.20236.16.camel@balmora.brq.redhat.com> <4F747F51.7060009@redhat.com> <1333047882.22628.160.camel@willson.li.ssimo.org> Message-ID: <4F74B73D.2000706@redhat.com> Simo Sorce wrote: > On Thu, 2012-03-29 at 11:27 -0400, Rob Crittenden wrote: >>> This patch is much better and covers my previous concerns. I just >> find >>> an issue with UPG. It is not created for non-posix users when UPGs >> are >>> enabled: >>> >>> # echo "Secret123" | ipa migrate-ds ldap://ldap.example.com >>> --with-compat --base-dn="dc=greyoak,dc=com" >>> ----------- >>> migrate-ds: >>> ----------- >>> Migrated: >>> user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg >>> group: ipagroup >>> Failed user: >>> Failed group: >>> ---------- >>> Passwords have been migrated in pre-hashed format. >>> IPA is unable to generate Kerberos keys unless provided >>> with clear text passwords. All migrated users need to >>> login at https://your.domain/ipa/migration/ before they >>> can use their Kerberos accounts. >>> >>> # ipa user-show mnonposix >>> User login: mnonposix >>> First name: Mister >>> Last name: Nonposix >>> Home directory: /home/mnonposix >>> Login shell: /bin/sh >>> UID: 328000195 >>> GID: 328000195 >>> Org. Unit: Product Testing >>> Job Title: Test User >>> Account disabled: False >>> Password: True >>> Member of groups: ipausers >>> Kerberos keys available: False >>> >>> # ipa group-show mnonposix >>> ipa: ERROR: mnonposix: group not found >> >> Yes, I was always disabling UPG. I now allow it when migrating a >> non-POSIX user. > > by this you mean you are now transforming a non-POSIX user into a POSIX > user ? > > What happen if someone has both POSIX and non-POSIX users on a server, > do you mix them ? The existing POSIX users are migrated as-is, non-POSIX users become full IPA users with UPG. > I have the feeling we need an explicit flag to convert a non-POSIX user > -> POSIX user, because that doesn't look to me like something people > want to do by default. What makes you say that? rob From simo at redhat.com Thu Mar 29 19:27:58 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 Mar 2012 15:27:58 -0400 Subject: [Freeipa-devel] [PATCH] 993 disable UPG for migration In-Reply-To: <4F74B73D.2000706@redhat.com> References: <4F6B7B9F.4080105@redhat.com> <1332493947.17059.24.camel@balmora.brq.redhat.com> <4F738281.3080505@redhat.com> <1333010191.20236.16.camel@balmora.brq.redhat.com> <4F747F51.7060009@redhat.com> <1333047882.22628.160.camel@willson.li.ssimo.org> <4F74B73D.2000706@redhat.com> Message-ID: <1333049278.22628.166.camel@willson.li.ssimo.org> On Thu, 2012-03-29 at 15:25 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2012-03-29 at 11:27 -0400, Rob Crittenden wrote: > >>> This patch is much better and covers my previous concerns. I just > >> find > >>> an issue with UPG. It is not created for non-posix users when UPGs > >> are > >>> enabled: > >>> > >>> # echo "Secret123" | ipa migrate-ds ldap://ldap.example.com > >>> --with-compat --base-dn="dc=greyoak,dc=com" > >>> ----------- > >>> migrate-ds: > >>> ----------- > >>> Migrated: > >>> user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg > >>> group: ipagroup > >>> Failed user: > >>> Failed group: > >>> ---------- > >>> Passwords have been migrated in pre-hashed format. > >>> IPA is unable to generate Kerberos keys unless provided > >>> with clear text passwords. All migrated users need to > >>> login at https://your.domain/ipa/migration/ before they > >>> can use their Kerberos accounts. > >>> > >>> # ipa user-show mnonposix > >>> User login: mnonposix > >>> First name: Mister > >>> Last name: Nonposix > >>> Home directory: /home/mnonposix > >>> Login shell: /bin/sh > >>> UID: 328000195 > >>> GID: 328000195 > >>> Org. Unit: Product Testing > >>> Job Title: Test User > >>> Account disabled: False > >>> Password: True > >>> Member of groups: ipausers > >>> Kerberos keys available: False > >>> > >>> # ipa group-show mnonposix > >>> ipa: ERROR: mnonposix: group not found > >> > >> Yes, I was always disabling UPG. I now allow it when migrating a > >> non-POSIX user. > > > > by this you mean you are now transforming a non-POSIX user into a POSIX > > user ? > > > > What happen if someone has both POSIX and non-POSIX users on a server, > > do you mix them ? > > The existing POSIX users are migrated as-is, non-POSIX users become full > IPA users with UPG. > > > I have the feeling we need an explicit flag to convert a non-POSIX user > > -> POSIX user, because that doesn't look to me like something people > > want to do by default. > > What makes you say that? Well if I had non-POSIX users in my directory they would be some sort of addressbook, and I certainly wouldn't want them converted into posix users in freeipa. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Mar 29 19:54:49 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Mar 2012 15:54:49 -0400 Subject: [Freeipa-devel] [PATCH] 238 Improve automount indirect map error message In-Reply-To: <1331824465.27127.19.camel@balmora.brq.redhat.com> References: <1331824465.27127.19.camel@balmora.brq.redhat.com> Message-ID: <4F74BE09.7030207@redhat.com> Martin Kosek wrote: > When user does not pass a name of parent map in > automountmap-add-indirect command, auto.master is used as > a default. However, when auto.master does not exist in a given > location, we raise NotFound error with a name of a location instead > of a name of the missing automount map. > > https://fedorahosted.org/freeipa/ticket/2387 ACK, pushed to master and ipa-2-2 From rcritten at redhat.com Thu Mar 29 20:18:56 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Mar 2012 16:18:56 -0400 Subject: [Freeipa-devel] [PATCH] 0032 Move DNS test skipping to class setup In-Reply-To: <4F72D1EB.7020007@redhat.com> References: <4F72D1EB.7020007@redhat.com> Message-ID: <4F74C3B0.7020102@redhat.com> Petr Viktorin wrote: > > Currently, each DNS test case first checks if DNS is configured > by creating and deleting a test zone. This takes quite a lot of time. > > This patch moves the check to the setUpClass method, so the check is > only done once for all the tests. > > > > On my VM, this makes the DNS plugin tests 50% faster, saving about half > a minute for each test run. > This fails if the test XML-RPC server is not running. While working on that issue I found a few other places that weren't handling this as well. Here is my working patch on top of yours. rob diff --git a/tests/test_cmdline/test_cli.py b/tests/test_cmdline/test_cli.py index 889aae4..7e40cf0 100644 --- a/tests/test_cmdline/test_cli.py +++ b/tests/test_cmdline/test_cli.py @@ -26,7 +26,11 @@ class TestCLIParsing(object): """Run a command on the server""" if not api.Backend.xmlclient.isconnected(): api.Backend.xmlclient.connect(fallback=False) - api.Command[command_name](**kw) + try: + api.Command[command_name](**kw) + except errors.NetworkError: + raise nose.SkipTest( + '%r: Server not available: %r' % (self.__module__, api.env.xmlr pc_uri)) @contextlib.contextmanager def fake_stdin(self, string_in): diff --git a/tests/test_xmlrpc/test_dns_plugin.py b/tests/test_xmlrpc/test_dns_p lugin.py index 911c773..2d7a6ea 100644 --- a/tests/test_xmlrpc/test_dns_plugin.py +++ b/tests/test_xmlrpc/test_dns_plugin.py @@ -49,6 +49,10 @@ class test_dns(Declarative): @classmethod def setUpClass(cls): + if not api.Backend.xmlclient.isconnected(): + raise nose.SkipTest( + '%r: Server not available: %r' % (cls.__module__, api.env.xmlrp c_uri)) + try: api.Command['dnszone_add'](dnszone1, idnssoamname = dnszone1_mname, diff --git a/tests/test_xmlrpc/xmlrpc_test.py b/tests/test_xmlrpc/xmlrpc_test.py index a7cfb11..c0a43ff 100644 --- a/tests/test_xmlrpc/xmlrpc_test.py +++ b/tests/test_xmlrpc/xmlrpc_test.py @@ -130,6 +130,13 @@ class XMLRPC_test(object): if not api.Backend.xmlclient.isconnected(): api.Backend.xmlclient.connect(fallback=False) + @classmethod + def setUpClass(cls): + if not server_available: + raise nose.SkipTest( + '%r: Server not available: %r' % (cls.__module__, api.env.xmlrp c_uri) + ) + def tearDown(self): """ nose tear-down fixture. From simo at redhat.com Thu Mar 29 21:02:31 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 Mar 2012 17:02:31 -0400 Subject: [Freeipa-devel] [PATCH] (master) Support case-insensitive searches for principals during TGS request processing In-Reply-To: <20120329133035.GH3500@redhat.com> References: <20120329133035.GH3500@redhat.com> Message-ID: <1333054951.22628.169.camel@willson.li.ssimo.org> On Thu, 2012-03-29 at 16:30 +0300, Alexander Bokovoy wrote: > This is due to some krbtgt/realm at REALM searches performed in KDC > without > allowing for principal aliases and therefore no chance to our > case-insensitive searches to kick in. Additional discussion is needed, > I > think, if we want to support case-insensitive realms. > I do not think we want to support case-insensitive realm lookups just yet. So what you have now seem sufficient to me. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Mar 29 21:17:48 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Mar 2012 17:17:48 -0400 Subject: [Freeipa-devel] [PATCH] 0029 Check expected error messages in tests In-Reply-To: <4F71C48D.3010502@redhat.com> References: <4F687A8D.6020508@redhat.com> <4F709C11.1070800@redhat.com> <4F70C864.5050107@redhat.com> <4F71C48D.3010502@redhat.com> Message-ID: <4F74D17C.2010504@redhat.com> Petr Viktorin wrote: > On 03/26/2012 09:49 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/20/2012 01:39 PM, Petr Viktorin wrote: >>>> This patch adds checking error messages, not just types, to the XML-RPC >>>> tests. >>>> The checking is still somewhat hackish, since XML-RPC doesn't give us >>>> structured error info, but it should protect against regressions on >>>> issues like whether we put name or cli_name in a ValidationError. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2549 >>>> >>> >>> Updated and rebased to current master. >> >> NACK >> >> automember wrongly was testing for non-existent users rather than >> automember rules but those should still be tested IMHO, perhaps with >> both types. >> >> There is also some inconsistency. In host you use substitution to set >> the hostname in the error: '%s: host not found' % fqdn1 but in others >> (group, hostgroup for example) the name is hardcoded. I also noticed >> that some reasons are unicode and others are not. >> >> rob > > Added tests for automember, made all the reasons unicode, using > substitutions when variables are involved. > > The patch still only updates tests that didn't pass the error message > check. > I'm seeing three failures that I think are due to recently pushed patches. Otherwise it looks good. rob ====================================================================== FAIL: test_netgroup[1]: netgroup_mod: Try to update non-existent u'netgroup1' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py", line 247, in func = lambda: self.check(nice, **test) File "/home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py", line 260, in check self.check_exception(nice, cmd, args, options, expected) File "/home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py", line 284, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/home/rcrit/redhat/freeipa-beta1/tests/util.py", line 328, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u'netgroup1: netgroup not found' got = u'no such entry' path = () ====================================================================== FAIL: test_netgroup[4]: netgroup_add: Test an invalid nisdomain1 name u'domain1,domain2' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py", line 247, in func = lambda: self.check(nice, **test) File "/home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py", line 260, in check self.check_exception(nice, cmd, args, options, expected) File "/home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py", line 284, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/home/rcrit/redhat/freeipa-beta1/tests/util.py", line 328, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u"invalid 'nisdomainname': may only include letters, numbers, _, - and ." got = u"invalid 'nisdomain': may only include letters, numbers, _, -, and ." path = () ====================================================================== FAIL: test_netgroup[5]: netgroup_add: Test an invalid nisdomain2 name u'+invalidnisdomain' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest self.test(*self.arg) File "/home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py", line 247, in func = lambda: self.check(nice, **test) File "/home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py", line 260, in check self.check_exception(nice, cmd, args, options, expected) File "/home/rcrit/redhat/freeipa-beta1/tests/test_xmlrpc/xmlrpc_test.py", line 284, in check_exception assert_deepequal(expected.strerror, e.strerror) File "/home/rcrit/redhat/freeipa-beta1/tests/util.py", line 328, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. expected = u"invalid 'nisdomainname': may only include letters, numbers, _, - and ." got = u"invalid 'nisdomain': may only include letters, numbers, _, -, and ." path = () From rcritten at redhat.com Thu Mar 29 21:42:46 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Mar 2012 17:42:46 -0400 Subject: [Freeipa-devel] [PATCH] 999 fix failure count interval in kdb backend Message-ID: <4F74D756.3060800@redhat.com> The wrong attribute name was being requested for the failure count interval so it was never being applied. This caused the failure count to never be reset with time. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-999-failurecount.patch Type: text/x-patch Size: 1017 bytes Desc: not available URL: From simo at redhat.com Thu Mar 29 21:59:14 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 Mar 2012 17:59:14 -0400 Subject: [Freeipa-devel] [PATCH] 999 fix failure count interval in kdb backend In-Reply-To: <4F74D756.3060800@redhat.com> References: <4F74D756.3060800@redhat.com> Message-ID: <1333058354.22628.173.camel@willson.li.ssimo.org> On Thu, 2012-03-29 at 17:42 -0400, Rob Crittenden wrote: > The wrong attribute name was being requested for the failure count > interval so it was never being applied. This caused the failure count to > never be reset with time. ACK Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Mar 29 22:03:27 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Mar 2012 18:03:27 -0400 Subject: [Freeipa-devel] [PATCH] 999 fix failure count interval in kdb backend In-Reply-To: <1333058354.22628.173.camel@willson.li.ssimo.org> References: <4F74D756.3060800@redhat.com> <1333058354.22628.173.camel@willson.li.ssimo.org> Message-ID: <4F74DC2F.6020109@redhat.com> Simo Sorce wrote: > On Thu, 2012-03-29 at 17:42 -0400, Rob Crittenden wrote: >> The wrong attribute name was being requested for the failure count >> interval so it was never being applied. This caused the failure count to >> never be reset with time. > > ACK > > Simo. > pushed to master and ipa-2-2 From jdennis at redhat.com Fri Mar 30 00:41:27 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 29 Mar 2012 20:41:27 -0400 Subject: [Freeipa-devel] [PATCH 68] text unit test should validate using installed mo file In-Reply-To: <4F72CE84.6010407@redhat.com> References: <4F71D00E.2070907@redhat.com> <4F71D58E.5060507@redhat.com> <4F71FF85.7090102@redhat.com> <4F7223AF.7030003@redhat.com> <4F72CE84.6010407@redhat.com> Message-ID: <4F750137.9010600@redhat.com> On 03/28/2012 04:40 AM, Petr Viktorin wrote: > Can install/po/Makefile just call test_i18n.py from the tests/ tree? It > doesn't import any IPA code so there's no need to set sys.path in this > case (though there'd have to be a comment saying we depend on this). > In the other case, unit tests, the path is already set by Nose. > Also the file would have to be renamed so nose doesn't pick it up as a > test module. Good idea. I moved test_i18n.py to tests/i18n.py. I was reluctant about moving the file, but that was without merit, it works better this way. I also removed the superfluous comment in Makefile.in you pointed out. When I was exercising the code I noticed the validation code was not treating msgid's from C code correctly (we do have some C code in the client area). That required a much more nuanced parsing the format conversion specifiers to correctly identify what was a positional format specifier vs. an indexed format specifier. The new version of the i18n.py includes the function parse_printf_fmt() and get_prog_langs() to identify the source programming language. Two more patches will follow shortly, one which adds validation when "make lint" is run and a patch to correct the problems it found in the C code strings which did not used indexed format specifiers. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0068-2-text-unit-test-should-validate-using-installed-mo-fi.patch Type: text/x-patch Size: 65605 bytes Desc: not available URL: From jdennis at redhat.com Fri Mar 30 01:36:00 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 29 Mar 2012 21:36:00 -0400 Subject: [Freeipa-devel] [PATCH 69] Use indexed format specifiers in i18n strings Message-ID: <201203300136.q2U1a0E5030640@int-mx12.intmail.prod.int.phx2.redhat.com> Translators need to reorder messages to suit the needs of the target language. The conventional positional format specifiers (e.g. %s %d) do not permit reordering because their order is tied to the ordering of the arguments to the printf function. The fix is to use indexed format specifiers. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0069-Use-indexed-format-specifiers-in-i18n-strings.patch Type: text/x-patch Size: 7244 bytes Desc: not available URL: From jdennis at redhat.com Fri Mar 30 01:45:09 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 29 Mar 2012 21:45:09 -0400 Subject: [Freeipa-devel] [PATCH 70] validate i18n strings when running "make lint" Message-ID: <4F751025.7090204@redhat.com> Translatable strings have certain requirements for proper translation and run time behaviour. We should routinely validate those strings. A recent checkin to install/po/test_i18n.py makes it possible to validate the contents of our current pot file by searching for problematic strings. However, we only occasionally generate a new pot file, far less frequently than translatable strings change in the source base. Just like other checkin's to the source which are tested for correctness we should also validate new or modified translation strings when they are introduced and not accumulate problems to fix at the last minute. This would also raise the awareness of developers as to the requirements for proper string translation. The top level Makefile should be enhanced to create a temporary pot files from the current sources and validate it. We need to use a temporary pot file because we do not want to modify the pot file under source code control and exported to Transifex. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0070-validate-i18n-strings-when-running-make-lint.patch Type: text/x-patch Size: 2207 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 30 06:48:02 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 30 Mar 2012 08:48:02 +0200 Subject: [Freeipa-devel] [PATCH] 993 disable UPG for migration In-Reply-To: <4F747F51.7060009@redhat.com> References: <4F6B7B9F.4080105@redhat.com> <1332493947.17059.24.camel@balmora.brq.redhat.com> <4F738281.3080505@redhat.com> <1333010191.20236.16.camel@balmora.brq.redhat.com> <4F747F51.7060009@redhat.com> Message-ID: <1333090082.2366.1.camel@priserak> On Thu, 2012-03-29 at 11:27 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Wed, 2012-03-28 at 17:28 -0400, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> On Thu, 2012-03-22 at 15:21 -0400, Rob Crittenden wrote: > >>>> We don't want to create private groups automatically for migrated users, > >>>> there could be namespace overlap (and race conditions prevent us from > >>>> trying to check in advance). > >>>> > >>>> Check the sanity of groups in general, warn if the group for the > >>>> gidnumber doesn't exist at least on the remote server. > >>>> > >>>> Fill in the user's shell as well. > >>>> > >>>> This will migrate users that are non-POSIX on the remote server. > >>>> > >>>> rob > >>> > >>> This patch fixes the problem of creating UPGs for migrated users, but > >>> there are several parts which confused me. > >>> > >>> 1) Confusing defaults > >>> > >>> + if 'def_group_gid' in ctx: > >>> + entry_attrs.setdefault('gidnumber', ctx['def_group_gid']) > >>> > >>> This statement seems redundant, because the account either is posix and > >>> has both uidnumber and gidnumber or it is non-posix and does not have > >>> any. > >>> > >>> Now, we don't touch gidNumber for posix user, and non-posix users are > >>> made posix with this statement: > >>> > >>> + # migrated user is not already POSIX, make it so > >>> + if 'uidnumber' not in entry_attrs: > >>> + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] > >>> > >>> > >>> 2) Missing UPG > >>> When UPG is disabled, the following statement will result in a user with > >>> a GID pointing to non-existent group. > >>> > >>> + # migrated user is not already POSIX, make it so > >>> + if 'uidnumber' not in entry_attrs: > >>> + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] > >>> > >>> We may want to run ldap.has_upg() and report a add this user to "failed > >>> users" with appropriate error. > >>> > >>> 3) Check for GID > >>> The patch implements a check if a group with the gidNumber exists on a > >>> remote LDAP server and the result is a warning: > >>> > >>> - (g_dn, g_attrs) = ldap.get_entry(ctx['def_group_dn'], ['gidnumber']) > >>> + (remote_dn, remote_entry) = ds_ldap.find_entry_by_attr( > >>> + 'gidnumber', entry_attrs['gidnumber'][0], 'posixgroup', [''], > >>> + search_bases['group'] > >>> + ) > >>> > >>> I have few (minor-ish) questions there: > >>> a) Is the warning in a apache log enough? Maybe it should be included in > >>> migrate-ds output. > >>> b) This will be a one more remote LDAP call for every user, we may want > >>> to optimize it with something like that: > >>> > >>> valid_gids = [] > >>> if user.gidnumber not in valid_gids: > >>> run the check in remote LDAP > >>> valid_gids.append(user.gidnumber) > >>> > >>> That would save us 999 LDAP queries for 1000 migrated with the same > >>> primary group. > >>> > >>> 4) Extraneous Warning: > >>> When non-posix user is migrated and thus we make it a posix user, we > >>> still produce a warning for non-existent group: > >>> > >>> [Fri Mar 23 04:21:36 2012] [error] ipa: WARNING: Migrated user's GID > >>> number 999 does not point to a known group. > >>> > >>> 5) Extraneous LDAP call > >>> > >>> Isn't the following call to LDAP to get a description redundant? We > >>> already have the description in entry_attrs. > >>> > >>> + (dn, desc_attr) = ldap.get_entry(dn, ['description']) > >>> + entry_attrs.update(desc_attr) > >>> + if 'description' in entry_attrs and NO_UPG_MAGIC in > >>> entry_attrs['description']: > >>> > >>> > >>> Martin > >>> > >> > >> I think this covers your concerns. > >> > >> I can't do anything but log warnings at this point in order to maintain > >> backwards compatibility. I looked into returning a warning entry and it > >> blew up in validate_output() on older clients. > >> > >> rob > >> > > > > This patch is much better and covers my previous concerns. I just find > > an issue with UPG. It is not created for non-posix users when UPGs are > > enabled: > > > > # echo "Secret123" | ipa migrate-ds ldap://ldap.example.com > > --with-compat --base-dn="dc=greyoak,dc=com" > > ----------- > > migrate-ds: > > ----------- > > Migrated: > > user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg > > group: ipagroup > > Failed user: > > Failed group: > > ---------- > > Passwords have been migrated in pre-hashed format. > > IPA is unable to generate Kerberos keys unless provided > > with clear text passwords. All migrated users need to > > login at https://your.domain/ipa/migration/ before they > > can use their Kerberos accounts. > > > > # ipa user-show mnonposix > > User login: mnonposix > > First name: Mister > > Last name: Nonposix > > Home directory: /home/mnonposix > > Login shell: /bin/sh > > UID: 328000195 > > GID: 328000195 > > Org. Unit: Product Testing > > Job Title: Test User > > Account disabled: False > > Password: True > > Member of groups: ipausers > > Kerberos keys available: False > > > > # ipa group-show mnonposix > > ipa: ERROR: mnonposix: group not found > > Yes, I was always disabling UPG. I now allow it when migrating a > non-POSIX user. > > > I am also thinking if we need to ask if UPG is enabled for every > > migrated user - every ldap.has_upg() call means one query to host LDAP. > > Maybe we should ask just in the beginning and store the setting in > > "ctx['upg_enabled']. I don't think that anyone needs to switch UPG > > status during migration process. > > I agree, nice optimization. > > rob This patch is OK, everything worked as expected. We just now need to specify if we want a special option/flag to enable non-posix -> posix user conversion. If not, then ACK. Martin From pviktori at redhat.com Fri Mar 30 10:21:45 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 30 Mar 2012 12:21:45 +0200 Subject: [Freeipa-devel] [PATCH] 0014 Add final debug message in installers In-Reply-To: <4F708CBA.9000608@redhat.com> References: <4F44B860.9050809@redhat.com> <4F4BB48C.7010200@redhat.com> <1330535684.32367.30.camel@balmora.brq.redhat.com> <4F4E728C.2070109@redhat.com> <4F4F5363.4030408@redhat.com> <4F61C4BC.60809@redhat.com> <4F6C9049.3030507@redhat.com> <4F708335.7030400@redhat.com> <4F708CBA.9000608@redhat.com> Message-ID: <4F758939.4060503@redhat.com> On 03/26/2012 05:35 PM, Petr Viktorin wrote: > On 03/26/2012 04:54 PM, Rob Crittenden wrote: >> >> Some minor compliants. > > > Ideally, there would be a routine that sets up the logging and handles > command-line arguments in some uniform way (which is also needed before > logging setup to detect ipa-server-install --uninstall). > The original patch did the common logging setup, and I hacked around the > install/uninstall problem too. > I guess I overdid it when I simplified the patch. > I'm somewhat confused about the scope, so bear with me as I clarify what > you mean. > > >> If you abort the installation you get this somewhat unnerving error: >> >> Continue to configure the system with these values? [no]: >> ipa : ERROR ipa-server-install failed, SystemExit: Installation aborted >> Installation aborted >> >> ipa-ldap-updater is the same: >> >> # ipa-ldap-updater >> [2012-03-26T14:53:41Z ipa] : ipa-ldap-updater failed, SystemExit: >> IPA is not configured on this system. >> IPA is not configured on this system. >> >> and ipa-upgradeconfig >> >> $ ipa-upgradeconfig >> [2012-03-26T14:54:05Z ipa] : ipa-upgradeconfig failed, SystemExit: >> You must be root to run this script. >> >> >> You must be root to run this script. >> >> I'm guessing that the issue is that the log file isn't opened yet. > > >> It would be nice if the logging would be confined to just the log. > > > If I understand you correctly, the code should check if logging has been > configured already, and if not, skip displaying the message? > > >> When uninstalling you get the message 'ipa-server-install successful'. >> This is a little odd as well. > > ipa-server-install is the name of the command. Wontfix for now, unless > you disagree strongly. > > Updated patch: only log if logging has been configured (detected by looking at the root logger's handlers), and changed the message to ?The ipa-server-install command has succeeded/failed?. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0014-06-Add-final-debug-message-in-installers.patch Type: text/x-patch Size: 30294 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 30 11:58:54 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 30 Mar 2012 13:58:54 +0200 Subject: [Freeipa-devel] [PATCH] 0032 Move DNS test skipping to class setup In-Reply-To: <4F74C3B0.7020102@redhat.com> References: <4F72D1EB.7020007@redhat.com> <4F74C3B0.7020102@redhat.com> Message-ID: <4F759FFE.1010303@redhat.com> On 03/29/2012 10:18 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> >> Currently, each DNS test case first checks if DNS is configured >> by creating and deleting a test zone. This takes quite a lot of time. >> >> This patch moves the check to the setUpClass method, so the check is >> only done once for all the tests. >> >> >> >> On my VM, this makes the DNS plugin tests 50% faster, saving about half >> a minute for each test run. >> > > This fails if the test XML-RPC server is not running. While working on > that issue I found a few other places that weren't handling this as > well. Here is my working patch on top of yours. > > rob Thank you! I see the other place is one I added recently. This updated patch includes your diff, and also makes sure a context is created for the DNS test skipping. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0032-02-Move-test-skipping-to-class-setup.patch Type: text/x-patch Size: 3203 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 30 12:57:59 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 30 Mar 2012 14:57:59 +0200 Subject: [Freeipa-devel] [PATCH 68] text unit test should validate using installed mo file In-Reply-To: <4F750137.9010600@redhat.com> References: <4F71D00E.2070907@redhat.com> <4F71D58E.5060507@redhat.com> <4F71FF85.7090102@redhat.com> <4F7223AF.7030003@redhat.com> <4F72CE84.6010407@redhat.com> <4F750137.9010600@redhat.com> Message-ID: <4F75ADD7.4020404@redhat.com> On 03/30/2012 02:41 AM, John Dennis wrote: > On 03/28/2012 04:40 AM, Petr Viktorin wrote: >> Can install/po/Makefile just call test_i18n.py from the tests/ tree? It >> doesn't import any IPA code so there's no need to set sys.path in this >> case (though there'd have to be a comment saying we depend on this). >> In the other case, unit tests, the path is already set by Nose. >> Also the file would have to be renamed so nose doesn't pick it up as a >> test module. > > Good idea. I moved test_i18n.py to tests/i18n.py. I was reluctant about > moving the file, but that was without merit, it works better this way. The downside is that the file now looks like a test utility module. It could use a comment near the imports saying that it's also called as a script, and that it shouldn't import IPA code (this could silently use the system-installed version of IPA, or crash if it's not there). Alternatively, set PYTHONPATH in the Makefile. > I also removed the superfluous comment in Makefile.in you pointed out. > > When I was exercising the code I noticed the validation code was not > treating msgid's from C code correctly (we do have some C code in the > client area). That required a much more nuanced parsing the format > conversion specifiers to correctly identify what was a positional format > specifier vs. an indexed format specifier. The new version of the > i18n.py includes the function parse_printf_fmt() and get_prog_langs() to > identify the source programming language. More non-trivial code without tests. This makes me worry. But, tests for this can be added later I guess. > Two more patches will follow shortly, one which adds validation when > "make lint" is run and a patch to correct the problems it found in the C > code strings which did not used indexed format specifiers. > -- Petr? From rcritten at redhat.com Fri Mar 30 13:05:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Mar 2012 09:05:26 -0400 Subject: [Freeipa-devel] [PATCH] 993 disable UPG for migration In-Reply-To: <1333090082.2366.1.camel@priserak> References: <4F6B7B9F.4080105@redhat.com> <1332493947.17059.24.camel@balmora.brq.redhat.com> <4F738281.3080505@redhat.com> <1333010191.20236.16.camel@balmora.brq.redhat.com> <4F747F51.7060009@redhat.com> <1333090082.2366.1.camel@priserak> Message-ID: <4F75AF96.9010205@redhat.com> Martin Kosek wrote: > On Thu, 2012-03-29 at 11:27 -0400, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Wed, 2012-03-28 at 17:28 -0400, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On Thu, 2012-03-22 at 15:21 -0400, Rob Crittenden wrote: >>>>>> We don't want to create private groups automatically for migrated users, >>>>>> there could be namespace overlap (and race conditions prevent us from >>>>>> trying to check in advance). >>>>>> >>>>>> Check the sanity of groups in general, warn if the group for the >>>>>> gidnumber doesn't exist at least on the remote server. >>>>>> >>>>>> Fill in the user's shell as well. >>>>>> >>>>>> This will migrate users that are non-POSIX on the remote server. >>>>>> >>>>>> rob >>>>> >>>>> This patch fixes the problem of creating UPGs for migrated users, but >>>>> there are several parts which confused me. >>>>> >>>>> 1) Confusing defaults >>>>> >>>>> + if 'def_group_gid' in ctx: >>>>> + entry_attrs.setdefault('gidnumber', ctx['def_group_gid']) >>>>> >>>>> This statement seems redundant, because the account either is posix and >>>>> has both uidnumber and gidnumber or it is non-posix and does not have >>>>> any. >>>>> >>>>> Now, we don't touch gidNumber for posix user, and non-posix users are >>>>> made posix with this statement: >>>>> >>>>> + # migrated user is not already POSIX, make it so >>>>> + if 'uidnumber' not in entry_attrs: >>>>> + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] >>>>> >>>>> >>>>> 2) Missing UPG >>>>> When UPG is disabled, the following statement will result in a user with >>>>> a GID pointing to non-existent group. >>>>> >>>>> + # migrated user is not already POSIX, make it so >>>>> + if 'uidnumber' not in entry_attrs: >>>>> + entry_attrs['uidnumber'] = entry_attrs['gidnumber'] = [999] >>>>> >>>>> We may want to run ldap.has_upg() and report a add this user to "failed >>>>> users" with appropriate error. >>>>> >>>>> 3) Check for GID >>>>> The patch implements a check if a group with the gidNumber exists on a >>>>> remote LDAP server and the result is a warning: >>>>> >>>>> - (g_dn, g_attrs) = ldap.get_entry(ctx['def_group_dn'], ['gidnumber']) >>>>> + (remote_dn, remote_entry) = ds_ldap.find_entry_by_attr( >>>>> + 'gidnumber', entry_attrs['gidnumber'][0], 'posixgroup', [''], >>>>> + search_bases['group'] >>>>> + ) >>>>> >>>>> I have few (minor-ish) questions there: >>>>> a) Is the warning in a apache log enough? Maybe it should be included in >>>>> migrate-ds output. >>>>> b) This will be a one more remote LDAP call for every user, we may want >>>>> to optimize it with something like that: >>>>> >>>>> valid_gids = [] >>>>> if user.gidnumber not in valid_gids: >>>>> run the check in remote LDAP >>>>> valid_gids.append(user.gidnumber) >>>>> >>>>> That would save us 999 LDAP queries for 1000 migrated with the same >>>>> primary group. >>>>> >>>>> 4) Extraneous Warning: >>>>> When non-posix user is migrated and thus we make it a posix user, we >>>>> still produce a warning for non-existent group: >>>>> >>>>> [Fri Mar 23 04:21:36 2012] [error] ipa: WARNING: Migrated user's GID >>>>> number 999 does not point to a known group. >>>>> >>>>> 5) Extraneous LDAP call >>>>> >>>>> Isn't the following call to LDAP to get a description redundant? We >>>>> already have the description in entry_attrs. >>>>> >>>>> + (dn, desc_attr) = ldap.get_entry(dn, ['description']) >>>>> + entry_attrs.update(desc_attr) >>>>> + if 'description' in entry_attrs and NO_UPG_MAGIC in >>>>> entry_attrs['description']: >>>>> >>>>> >>>>> Martin >>>>> >>>> >>>> I think this covers your concerns. >>>> >>>> I can't do anything but log warnings at this point in order to maintain >>>> backwards compatibility. I looked into returning a warning entry and it >>>> blew up in validate_output() on older clients. >>>> >>>> rob >>>> >>> >>> This patch is much better and covers my previous concerns. I just find >>> an issue with UPG. It is not created for non-posix users when UPGs are >>> enabled: >>> >>> # echo "Secret123" | ipa migrate-ds ldap://ldap.example.com >>> --with-compat --base-dn="dc=greyoak,dc=com" >>> ----------- >>> migrate-ds: >>> ----------- >>> Migrated: >>> user: darcee_leeson, ayaz_kreiger, mnonposix, mollee_weisenberg >>> group: ipagroup >>> Failed user: >>> Failed group: >>> ---------- >>> Passwords have been migrated in pre-hashed format. >>> IPA is unable to generate Kerberos keys unless provided >>> with clear text passwords. All migrated users need to >>> login at https://your.domain/ipa/migration/ before they >>> can use their Kerberos accounts. >>> >>> # ipa user-show mnonposix >>> User login: mnonposix >>> First name: Mister >>> Last name: Nonposix >>> Home directory: /home/mnonposix >>> Login shell: /bin/sh >>> UID: 328000195 >>> GID: 328000195 >>> Org. Unit: Product Testing >>> Job Title: Test User >>> Account disabled: False >>> Password: True >>> Member of groups: ipausers >>> Kerberos keys available: False >>> >>> # ipa group-show mnonposix >>> ipa: ERROR: mnonposix: group not found >> >> Yes, I was always disabling UPG. I now allow it when migrating a >> non-POSIX user. >> >>> I am also thinking if we need to ask if UPG is enabled for every >>> migrated user - every ldap.has_upg() call means one query to host LDAP. >>> Maybe we should ask just in the beginning and store the setting in >>> "ctx['upg_enabled']. I don't think that anyone needs to switch UPG >>> status during migration process. >> >> I agree, nice optimization. >> >> rob > > This patch is OK, everything worked as expected. We just now need to > specify if we want a special option/flag to enable non-posix -> posix > user conversion. If not, then ACK. > > Martin > Simo and I had a brief discussion about this in IRC and I'm going to punt on non-POSIX user conversion for now. There could be specific reasons for this, like having a shared user (nss_ldap) or some sort of system user that they don't to be a full POSIX user. Adding a new option this late in 2.2 doesn't seem like a good idea so I'll patch it to simply fail non-POSIX users for now. I've opened a ticket to optionally allow them to be converted. rob From rcritten at redhat.com Fri Mar 30 18:13:33 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Mar 2012 14:13:33 -0400 Subject: [Freeipa-devel] [PATCH] 1000 fix upgrade crash when updating replication agreements Message-ID: <4F75F7CD.5010309@redhat.com> We check existing agreements to see if they are missing memberof in the EXCLUDE list. It would crash if this list wasn't present at all. So we need to catch this and add in the missing exclusions if they aren't there at all. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1000-upgrade.patch Type: text/x-patch Size: 2924 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 30 21:00:37 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Mar 2012 17:00:37 -0400 Subject: [Freeipa-devel] [PATCH] 0014 Add final debug message in installers In-Reply-To: <4F758939.4060503@redhat.com> References: <4F44B860.9050809@redhat.com> <4F4BB48C.7010200@redhat.com> <1330535684.32367.30.camel@balmora.brq.redhat.com> <4F4E728C.2070109@redhat.com> <4F4F5363.4030408@redhat.com> <4F61C4BC.60809@redhat.com> <4F6C9049.3030507@redhat.com> <4F708335.7030400@redhat.com> <4F708CBA.9000608@redhat.com> <4F758939.4060503@redhat.com> Message-ID: <4F761EF5.4050704@redhat.com> Petr Viktorin wrote: > On 03/26/2012 05:35 PM, Petr Viktorin wrote: >> On 03/26/2012 04:54 PM, Rob Crittenden wrote: >>> >>> Some minor compliants. >> >> >> Ideally, there would be a routine that sets up the logging and handles >> command-line arguments in some uniform way (which is also needed before >> logging setup to detect ipa-server-install --uninstall). >> The original patch did the common logging setup, and I hacked around the >> install/uninstall problem too. >> I guess I overdid it when I simplified the patch. >> I'm somewhat confused about the scope, so bear with me as I clarify what >> you mean. >> >> >>> If you abort the installation you get this somewhat unnerving error: >>> >>> Continue to configure the system with these values? [no]: >>> ipa : ERROR ipa-server-install failed, SystemExit: Installation aborted >>> Installation aborted >>> >>> ipa-ldap-updater is the same: >>> >>> # ipa-ldap-updater >>> [2012-03-26T14:53:41Z ipa] : ipa-ldap-updater failed, SystemExit: >>> IPA is not configured on this system. >>> IPA is not configured on this system. >>> >>> and ipa-upgradeconfig >>> >>> $ ipa-upgradeconfig >>> [2012-03-26T14:54:05Z ipa] : ipa-upgradeconfig failed, >>> SystemExit: >>> You must be root to run this script. >>> >>> >>> You must be root to run this script. >>> >>> I'm guessing that the issue is that the log file isn't opened yet. >> > >>> It would be nice if the logging would be confined to just the log. >> >> >> If I understand you correctly, the code should check if logging has been >> configured already, and if not, skip displaying the message? >> >> >>> When uninstalling you get the message 'ipa-server-install successful'. >>> This is a little odd as well. >> >> ipa-server-install is the name of the command. Wontfix for now, unless >> you disagree strongly. >> >> > > Updated patch: only log if logging has been configured (detected by > looking at the root logger's handlers), and changed the message to ?The > ipa-server-install command has succeeded/failed?. Works much better thanks. Just one request. When you created final_log() you show less information than you did in earlier patches. It is nice seeing the SystemExit failure. Can you do something like this (basically cut-n-pasted from v05)? diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils. py index 851b58d..ca82a1b 100644 --- a/ipaserver/install/installutils.py +++ b/ipaserver/install/installutils.py @@ -721,15 +721,15 @@ def script_context(operation_name): # Only log if logging was already configured # TODO: Do this properly (e.g. configure logging before the try/except) if log_mgr.handlers.keys() != ['console']: - root_logger.info(template, operation_name) + root_logger.info(template) try: yield except BaseException, e: if isinstance(e, SystemExit) and (e.code is None or e.code == 0): # Not an error after all - final_log('The %s command was successful') + final_log('The %s command was successful' % operation_name) else: - final_log('The %s command failed') + final_log('%s failed, %s: %s' % (operation_name, type(e).__name__, e)) raise else: final_log('The %s command was successful') This looks like: 2012-03-30T20:56:53Z INFO ipa-dns-install failed, SystemExit: DNS is already configured in this IPA server. rob